идентификатора текущего сегмента

Если сообщение отправляется на сегмент, отличный от текущего, одна из
шестнадцатеричных цифр (выбранная детерминированно) идентификатора текущего сегмента заменяется
соответствующей цифрой целевого сегмента, и полученный
идентификатор используется в качестве ближайшей цели для пересылки сообщения.15
Основное преимущество маршрутизации гиперкуба заключается в том, что условия валидности блоков подразумевают, что валидаторы, создающие блоки цепочки сегментов, должны собирать и
обрабатывать сообщения из выходных очередей соседних цепочек сегментов, под
страхом потери своих ставок. Таким образом, можно ожидать, что любое сообщение
рано или поздно достигнет конечного пункта назначения; сообщение не может быть потеряно в пути или
доставлено дважды.
Обратите внимание, что маршрутизация по гиперкубу приводит к некоторым дополнительным задержкам и затратам из-за необходимости пересылки сообщений через несколько промежуточных цепочек сегментов. Однако число этих промежуточных цепочек осколков
растет очень медленно, так как логарифм логарифма N (точнее, dlog16 Ne − 1) от
общего числа цепочек осколков N. Например, если N ≈ 250, будет не
более одного промежуточного перехода; а для N ≈ 4000 цепочек осколков - не более
двух. С помощью четырех промежуточных переходов мы можем поддерживать до миллиона цепочек осколков. Мы считаем, что это очень небольшая цена за практически неограниченное
масштабируемость системы. На самом деле, не стоит платить даже эту цену:
2.4.20. Мгновенная маршрутизация гиперкуба: быстрый путь для сообщений.
Новой особенностью блокчейна TON является то, что он вводит быстрый путь для
пересылки сообщений из одной цепочки сегментов в любую другую, позволяя в большинстве случаев полностью
обойти медленную маршрутизацию гиперкуба 2.4.19 и доставить
сообщение в самый следующий блок конечной цепочки сегментов назначения.
Идея заключается в следующем. Во время медленной маршрутизации гиперкуба сообщение
перемещается (в сети) по краям гиперкуба, но задерживается
(примерно на пять секунд) в каждой промежуточной вершине, которая должна быть зафиксирована
в соответствующей цепочке осколков, прежде чем продолжить свое путешествие.
Чтобы избежать ненужных задержек, вместо этого можно было бы передать сообщение вместе
с подходящим доказательством Меркла по краям гиперкуба, не дожидаясь 15. Это не обязательно окончательная версия алгоритма, используемого для вычисления следующего перехода
для маршрутизации гиперкуба. В частности, шестнадцатеричные цифры могут быть заменены r-разрядными группами,
причем r является настраиваемым параметром, не обязательно равным четырем.
35
2.4. Сообщения Между Цепочками Сегментов
чтобы зафиксировать его в промежуточных цепочках осколков. Фактически, сетевое сообщение должно быть перенаправлено от валидаторов целевой группы (см. 2.6.
исходного фрагмента назначенному производителю блока (см. 2.6.9) целевой
группы целевого фрагмента; это может быть сделано напрямую, не проходя
по краям гиперкуба. Когда это сообщение с доказательством Меркла
достигает валидаторов (точнее, коллаторов; см. 2.6.5) цепочки сегментов назначения, они могут немедленно зафиксировать его в новом блоке, без
ожидание завершения сообщения по медленному пути . Затем
подтверждение доставки вместе с подходящим доказательством Меркла отправляется обратно по краям
гиперкуба, и оно может быть использовано для остановки перемещения сообщения
по медленному пути путем совершения специальной транзакции.
Обратите внимание, что этот механизм мгновенной доставки не заменяет медленный,
но надежный механизм, описанный в 2.4.19. Медленный путь все еще необходим,
потому что валидаторы не могут быть наказаны за потерю или просто за решение не
передавать сообщения быстрого пути в новые блоки своих блокчейнов.16
Поэтому оба метода пересылки сообщений выполняются параллельно, и
медленный механизм прерывается только в том случае, если доказательство успеха быстрого механизма
зафиксировано в промежуточной цепочке сегментов.17
2.4.21. Сбор входных сообщений из очередей вывода соседних цепочек сегментов. Когда предлагается новый блок для цепочки сегментов, некоторые
выходные сообщения соседних (в смысле гиперкуба маршрутизации 2.4.19) цепочек сегментов включаются в новый блок в качестве входных
сообщений и немедленно доставляются (т.е. обрабатываются). Существуют определенные правила
что касается порядка, в котором должны обрабатываться выходные сообщения этих соседей.
По сути, более старое сообщение (исходящее из блока цепочки фрагментов, ссылающегося на более
старый блок основной цепочки) должно быть доставлено до любого нового сообщения;
а для сообщений, поступающих из одной и той же соседней цепочки сегментов,
необходимо соблюдать частичный порядок очереди вывода, описанный в 2.4.17.
2.4.22. Удаление сообщений из очередей вывода. Как только
обнаруживается, что сообщение очереди вывода было доставлено соседней цепочкой сегментов,
оно явно удаляется из очереди вывода специальной транзакцией.
16 Тем не менее, у валидаторов есть некоторый стимул сделать это как можно скорее, потому что они
смогут собрать все сборы за пересылку, связанные с сообщением, которые еще не
были израсходованы на медленном пути.
17 На самом деле, можно было бы временно или навсегда отключить механизм мгновенной доставки вообще, и система продолжала бы работать, хотя и медленнее.
36
2.4. Сообщения Между Цепочками Сегментов
2.4.23. Предотвращение двойной доставки сообщений. Чтобы предотвратить двойное
доставка сообщений, взятых из выходных очередей соседних цепочек сегментов, каждая цепочка сегментов (точнее, каждая цепочка учетных записей внутри нее) хранит
коллекцию недавно доставленных сообщений (или только их хэши) как часть
своего состояния. Когда обнаруживается, что доставленное сообщение удаляется из очереди вывода его исходной соседней цепочкой сегментов (см. 2.4.22), оно также удаляется
из коллекции недавно доставленных сообщений.
2.4.24. Пересылка сообщений, предназначенных для других цепочек сегментов. Маршрутизация по гиперкубу (см. 2.4.19) означает, что иногда исходящие сообщения
доставляется не в цепочку сегментов, содержащую предполагаемого получателя, а в
соседнюю цепочку сегментов, лежащую на пути гиперкуба к месту назначения. В
этом случае доставка заключается в перемещении входящего сообщения в исходящее
очередь. Это явно отражено в блоке как специальная транзакция пересылки, содержащая само сообщение. По сути, это выглядит так, как если бы сообщение
было получено кем-то внутри цепочки осколков, и в результате было сгенерировано одно идентичное сообщение.
2.4.25. Оплата за пересылку и хранение сообщения. Транзакция пересылки фактически расходует некоторое количество газа (в зависимости от размера пересылаемого
сообщения), поэтому плата за газ вычитается из стоимости пересылаемого
сообщения от имени валидаторов этой цепочки сегментов.
Этот платеж за пересылку обычно значительно меньше, чем плата за газ, взимаемая при окончательной доставке сообщения получателю, даже если
сообщение было переадресовано несколько раз из-за маршрутизации по гиперкубу.
Кроме того, пока сообщение хранится в очереди вывода некоторой цепочки сегментов, оно является частью глобального состояния цепочки сегментов, поэтому плата за хранение
глобальных данных в течение длительного времени может также взиматься специальными транзакциями.
2.4.26. Сообщения в мастер-цепочку и из нее. Сообщения могут быть отправлены
непосредственно из любой цепочки сегментов в мастер-цепочку и наоборот. Однако цены
на газ для отправки сообщений и обработки сообщений в мастер-цепочке довольно высоки, поэтому эта возможность будет использоваться только тогда, когда это действительно необходимо
например, валидаторами для внесения своих ставок. В некоторых случаях может
быть определен минимальный депозит (прилагаемая стоимость) за сообщения, отправленные в
мастер-цепочку, который возвращается только в том случае, если
получающая сторона считает сообщение действительным