Открытая сеть. Открытая сеть по материалам работы дра Николая Дурова 26 июля 2021
 Скачать 0.79 Mb.
|
|
В этом смысле сообщения из ниоткуда или внешние сообщения играют роль кандидатов транзакций, используемых в других системах блокчейна (например, Bitcoin и Ethereum). 2.4.7. Регистрировать сообщения или сообщения в никуда . Точно так же иногда специальное сообщение может быть сгенерировано и направлено в определенную цепочку шардов не для доставки получателю, а для регистрации, чтобы его можно было легко заметить любому, кто получает обновления об этом шарде. Эти протоколированные сообщения могут выводиться в консоль пользователя или инициировать выполнение какого -либо скрипта на сервере o-chain. В этом смысле они представляют внешний вывод суперкомпьютера блокчейна, так же как сообщения из ниоткуда представляют внешний вход суперкомпьютера блокчейна . 2.4.8. Взаимодействие с сервисами o - chain и внешними блокчейнами. Эти внешние входные и выходные сообщения можно использовать для взаимодействия с 31 2.4. Сообщения между шардчейнами сервисы o - chain и другие (внешние) блокчейны, такие как Bitcoin или Ethereum. Можно создавать токены или криптовалюты внутри блокчейна TON, привязанные к биткойнам, эфирам или любым токенам ERC-20, определенным в блокчейне Ethereum, и использовать сообщения из ниоткуда и сообщения в никуда , генерируемые и обрабатываемые скриптами, находящимися на некоторых сторонних серверах o - chain , для реализации необходимого взаимодействия междублокчейн TON и эти внешние блокчейны. 2.4.9. Тело сообщения. Тело сообщения - это просто последовательность байтов, смысл которой определяется только принимающей рабочей цепочкой и / или смарт - контрактом. Для блокчейнов, использующих TON VM, это может быть сериализация любой ячейки TVM, генерируемой автоматически с помощью операции Send (). Такая сериализация получается просто рекурсивной заменой всех ссылок в ячейке виртуальной машины TON на упомянутые ячейки. В конечном итоге появляется строка необработанных байтов , которая обычно предваряется 4-байтовым типом сообщения или конструктором сообщений , используемым для выбора правильного метода получающего смарт -контракта. Другим вариантом было бы использовать TL-сериализованные объекты (см. 2.2.5) в качестве тел сообщений. Это может быть особенно полезно для связи между различными рабочими цепочками, одна или обе из которых не обязательно используют виртуальную машину TON. 2.4.10. Предел газа и другие параметры workchain/VM-speci c. Иногда сообщение должно содержать информацию о пределе газа, цене газа, транзакционных сборах и аналогичных значениях, которые зависят от принимающей рабочей цепочки и имеют отношение только к принимающей рабочей цепочке, но не обязательно к исходной рабочей цепочке. Такие параметры включаются в тело сообщения или перед ним, иногда (в зависимости от рабочей цепочки) со специальными 4-байтовыми префиксами, указывающими на их наличие (что может быть определено TL- схемой; ср. 2.2.5). 2.4.11. Создание сообщений: смарт-контракты и транзакции. Есть два источника новых сообщений. Большинство сообщений создаются во время выполнения smartcontract (через операцию Send() в TON VM), когда некоторый смарт -контракт вызывается для обработки входящего сообщения. В качестве альтернативы сообщения могут приходить извне как внешние сообщения или сообщения из ниоткуда (см. 2.4.6). 13 13 Вышесказанное должно быть буквально верно только для базовой рабочей цепочки и ее шардчейнов; другие рабочие цепи могут предоставлять другие способы создания сообщений. 32 2.4. Сообщения между шардчейнами 2.4.12. Доставка сообщений. Когда сообщение достигает цепочки осколков, содержащей его целевую учетную запись, 14 он доставляется на счет получателя. То,что происходит дальше, зависит от рабочей цепочки; с внешней точки зрения важно, чтобы такое сообщение никогда не могло быть передано дальше из этой цепочки осколков. Для шардчейнов базовой рабочей цепочки доставка заключается в добавлении значения сообщения (за вычетом любых платежей за газ) к балансу получающего счета и, возможно, в последующем вызове метода, зависящего от сообщения, получающего смарт-контракта, если получающий счет является смарт-контрактом. Фактически, смарт-контракт имеет только одну точку входа для обработки всех входящих сообщений, и он должен различать различные типы сообщений, глядя на их первые несколько байтов (например, первые четыре байта, содержащие конструктор TL; ср. 2.2.5). 2.4.13. Доставка сообщения - это транзакция. Поскольку доставка сообщения изменяет состояние учетной записи или смарт-контракта, это специальная транзакция в принимающей цепочке шардов и явно зарегистрирована как таковая. По сути, все транзакции TON Blockchain состоят в доставке одного входящего сообщения на его учетную запись получателя (смарт-контракт), пренебрегая некоторыми незначительными техническими деталями. 2.4.14. Сообщения между экземплярами одного и того же смарт - контракта. Напомним, что смарт-контракт может быть локальным (т. е. находиться в одной цепочке шардов, как и любой обычный аккаунт) или глобальным (т. е. иметь экземпляры во всех шардах или , по крайней мере, во всех шардах до некоторой известной глубины d; ср. 2.3.18). Экземпляры глобального смарт-контракта могут обмениваться специальными сообщениями для передачи информации и ценности друг другу, если это необходимо. В этом случае (непростительный) account_id отправителя становится важным (см. 2.4.4). 2.4.15. Сообщения любому экземпляру смарт-контракта; подстановочные адреса. Иногда сообщение (например, запрос клиента) необходимо доставить в любой экземпляр глобального смарт-контракта, обычно ближайший (если он находится в той же цепочке шардов, что и отправитель, это очевидный кандидат). Один из способов сделать это - использовать подстановочный адрес получателя, причем первым битам d целевого account_id разрешено принимать произвольные значения. На практике обычно устанавливают эти d-биты в те же значения, что и в account_id отправителя . 14 Как вырожденный случай, эта цепочка осколков может совпадать с исходной цепочкой осколков например, если мы работаем внутри рабочей цепочки, которая еще не была разделена. 33 2.4. Сообщения между шардчейнами 2.4.16. Входная очередь отсутствует. Все сообщения, полученные блокчейном (обычно шардчейном; иногда мастерчейном) или, по сути, цепочкой учетных записей, находящейся внутри некоторой шардчейна, немедленно доставляются (т. Е. Обрабатываются принимающей учетной записью). Следовательно, входной очереди как таковой не существует. Вместо этого, если не все сообщения, предназначенные для определенной цепочки шардов,могут быть обработаны из-за ограничений на общий размер блоков и использование газа, некоторые сообщения просто остаются накапливаться в выходных очередях исходных цепочек шардов. 2.4.17. Очереди вывода. С точки зрения парадигмы конечного шардинга (см. 2.1.2), каждая цепочка учетных записей (т. е. Каждая учетная запись) имеет свою собственную очередь вывода, состоящую из всех сообщений, которые она сгенерировала, но еще не доставила их получателям. Конечно, цепочки учетных записей имеют только виртуальное существование; они сгруппированы в цепочки шардов, а цепочка шардов имеет очередь вывода, состоящую из объединения очередей вывода всех учетных записей ,принадлежащих цепочке шардов. Эта очередь вывода shardchain налагает только частичный порядок на свои сообщения-члены. А именно, сообщение, сгенерированное в предыдущем блоке, должно быть доставлено до любого сообщения, сгенерированного в последующем блоке, и любые сообщения , сгенерированные той же учетной записью и имеющие то же назначение, должны быть доставлены в порядке их генерации. 2.4.18. Надежный и быстрый обмен сообщениями между цепочками. Для масштабируемого мультиблокового проекта, такого как TON, крайне важно иметь возможность пересылать и доставлять сообщения между различными шардчейнами (см. 2.1.3), даже если в системе их миллионы. Сообщения должны быть доставлены надежно (т. е. Сообщения не должны быть потеряны или доставлены более одного раза) и быстро. Блокчейн TON достигает этой цели, используя комбинацию двух механизмов маршрутизации сообщений. 2.4.19. Маршрутизация гиперкуба: медленный путь для сообщений с гарантированной доставкой. Блокчейн TON использует маршрутизацию гиперкубов как медленный, но безопасный и надежный способ доставки сообщений из одной цепочки шардов в другую, используя при необходимости несколько промежуточных цепочек шардов для транзита. В противном случае валидаторы любой данной цепочки осколков должны были бы отслеживать состояние (выходные очереди) всех других цепочек осколков, что потребовало бы чрезмерных вычислительных мощностей и пропускной способности сети по мере роста общего количества цепочек осколков, что ограничивало бы масштабируемость системы. Таким образом, невозможно доставить сообщения непосредственно из любого осколка в любой другой. 34 2.4. Сообщения между шардчейнами Вместо этого каждый осколок связан только с осколками, различающимися ровно одной шестнадцатеричной цифрой их идентификаторов (w, s) осколков (см. 2.1.8). Таким образом, все цепочки шардов образуют граф гиперкуба, и сообщения перемещаются по краям этого гиперкуба. Если сообщение отправляется в сегмент, отличный от текущего, одна из шестнадцатеричных цифр (выбранных детерминистически) текущего идентификатора сегмента заменяется соответствующей цифрой целевого осколка, и результирующий идентификатор используется в качестве ближайшего целевого объекта для пересылки сообщения. 15 Основное преимущество маршрутизации гиперкуба заключается в том, что условия валидности блоков подразумевают, что валидаторы, создающие блоки цепочки шардов, должны собирать и обрабатывать сообщения из выходных очередей соседних цепочек шардов под страхом потери своих ставок. Таким образом, можно ожидать, что любое сообщение рано или поздно достигнет конечного пункта назначения; сообщение не может быть потеряно в пути или доставлено дважды. Обратите внимание, что маршрутизация гиперкуба приводит к некоторым дополнительным задержкам и затратам из-за необходимости пересылки сообщений через несколько промежуточных шардчейнов. Однако количество этих промежуточных шардчейнов растет очень медленно, так как логарифм log N (точнее, log 16 N - 1 ) от общего числа цепочек осколков N . Например, если N ≈ 250, то будет не более одного промежуточного перехода; а для N ≈ 4000 шардчейнов-не более двух. С четырьмя промежуточными прыжками мы можем поддерживать до миллиона цепочек осколков. Мы считаем, что это очень маленькая цена за практически неограниченную масштабируемость системы. На самом деле не стоит платить даже эту цену: 2.4.20. Мгновенная маршрутизация гиперкуба: быстрый путь для сообщений. Новая особенность блокчейна TON заключается в том, что он вводит быстрый путь для пересылки сообщений из одной цепочки шардов в любую другую, позволяя в большинстве случаев полностью обойти медленную маршрутизацию гиперкуба 2.4.19 и доставить сообщение в самый следующий блок конечной целевой цепочки шардов. Идея заключается в следующем. Во время медленной маршрутизации гиперкуба сообщение перемещается (в сети) по краям гиперкуба, но оно задерживается (примерно на пять секунд) в каждой промежуточной вершине, чтобы быть зафиксированным в соответствующей цепочке шардов, прежде чем продолжить свое путешествие. Чтобы избежать ненужных задержек, вместо этого можно было бы передать сообщение вместе с подходящим доказательством Меркла по краям гиперкуба без ожидания- 15 Это не обязательно окончательная версия алгоритма, используемого для вычисления следующего перехода для маршрутизации гиперкуба. В частности, шестнадцатеричные цифры могут быть заменены r-битовыми группами, причем r является контролируемым параметром, не обязательно равным четырем. 35 2.4. Сообщения между шардчейнами ing, чтобы зафиксировать его в промежуточных цепочках осколков. Фактически, сетевое сообщение должно быть перенаправлено от валидаторов группы задач (см. 2.6.8) исходного осколка назначенному производителю блоков (см. 2.6.9) группы задач целевого осколка; это может быть сделано непосредственно, не проходя по краям гиперкуба. Когда это сообщение с доказательством Меркля достигает валидаторов (точнее, коллаторов; ср. 2.6.5) дестины используя shardchain, они могут сразу же зафиксировать его в новый блок, не дожидаясь, пока сообщение завершит свое путешествие по медленному пути . Затем подтверждение доставки вместе с подходящим доказательством Меркла отправляется обратно по краям гиперкуба, и оно может быть использовано для остановки перемещения сообщения по медленному пути путем совершения специальной транзакции. Обратите внимание, что этот механизм мгновенной доставки не заменяет медленный , но отказоустойчивый механизм, описанный в 2.4.19. Медленный путь все еще необходим , потому что валидаторы не могут быть наказаны за проигрыш или просто решение не фиксировать сообщения быстрого пути в новые блоки своих блокчейнов. 16 Поэтому оба метода пересылки сообщений выполняются параллельно, и медленный механизм прерывается только в том случае, если доказательство успеха быстрого механизма фиксируется в промежуточной цепочке шардов. 17 2.4.21. Сбор входных сообщений из выходных очередей соседних шардчейнов. Когда предлагается новый блок для шардчейна, некоторые выходные сообщения соседних (в смысле гиперкуба маршрутизации 2.4.19) шардчейнов включаются в новый блок в качестве входных сообщений и немедленно доставляются (т. е. обрабатываются). Существуют определенные правила относительно порядка обработки выходных сообщений этих соседей. По сути, более старое сообщение (поступающее из блока shardchain, ссылающегося на более старый блок masterchain) должен быть доставлен перед любым более новым сообщением; и для сообщений, поступающих из той же соседней цепочки шардов, должен соблюдаться частичный порядок выходной очереди, описанный в 2.4.17. 2.4.22. Удаление сообщений из выходных очередей. Как только сообщение выходной очереди замечается как доставленное соседней цепочкой осколков, оно явно удаляется из выходной очереди специальной транзакцией. 16 Однако у валидаторов есть некоторый стимул сделать это как можно скорее, потому что они смогут собрать все сборы за пересылку, связанные с сообщением, которое еще не было израсходовано на медленном пути. 17 На самом деле, можно временно или навсегда отключить механизм мгновенной доставки- nism полностью, и система будет продолжать работать, хотя и медленнее. 36 2.4. Сообщения между шардчейнами 2.4.23. Предотвращение двойной доставки сообщений. Чтобы предотвратить двойную доставку сообщений, взятых из выходных очередей соседних шардчейнов, каждая шардчейн (точнее, каждая учетная запись-цепочка внутри нее) сохраняет коллекцию недавно доставленных сообщений (или просто их хэшей) как часть своего состояния. Когда замечено, что доставленное сообщение удалено из выходной очереди его исходящей соседней цепочкой шардов (см. 2.4.22), оно также удаляется из коллекции недавно доставленных сообщений. 2.4.24. Переадресация сообщений, предназначенных для других шардчейнов. Маршрутизация гиперкуба (см. 2.4.19) означает, что иногда исходящие сообщения доставляются не в цепочку шардов, содержащую предполагаемого получателя, а в соседнюю цепочку шардов, лежащую на пути гиперкуба к получателю. В этом случае доставка заключается в перемещении входящего сообщения в исходящую очередь. Это явно отражается в блоке как специальная транзакция пересылки, содержащая само сообщение. По сути, это выглядит так, как будто сообщение был получен кем-то внутри цепочки осколков, и в результате было сгенерировано одно идентичное сообщение. 2.4.25. Оплата за пересылку и хранение сообщения. Транзакция пересылки фактически тратит некоторое количество газа (в зависимости от размера пересылаемого сообщения), поэтому плата за газ вычитается из стоимости пересылаемого сообщения от имени валидаторов этой цепочки шардов. Эта плата за пересылку обычно значительно меньше, чем плата за газ, взимаемая при окончательной доставке сообщения получателю, даже если сообщение было переадресовано несколько раз из-за маршрутизации гиперкуба. Кроме того, пока сообщение хранится в очереди вывода некоторого шардчейна, оно является частью глобального состояния шардчейна, поэтому плата за хранение глобальных данных в течение длительного времени может также собираться специальными транзакциями. 2.4.26. Сообщения в мастерчейн и из него. Сообщения могут быть отправлены непосредственно из любой цепочки шардов в мастер-цепочку и наоборот. Однако цены на газ для отправки сообщений и для обработки сообщений в masterchain довольно высоки,поэтому эта возможность будет использоваться только тогда, когда это действительно необходимо , например, валидаторами для внесения своих ставок. В некоторых случаях может быть определен минимальный депозит (прикрепленное значение) для сообщений, отправленных в мастерчейн , который возвращается только в том случае, если сообщение считается действительным принимающей стороной. Сообщения не могут быть автоматически перенаправлены через мастер-цепочку. Сообщение с workchain_id = -1 (-1 является специальным идентификатором workchain_id- 37 2.5. Состояние глобальной цепочки шардов. Философия мешка клеток. cating masterchain) не может быть доставлен в masterchain. В принципе, внутри masterchain можно создать смарт-контракт на пересылку сообщений , но цена его использования будет непомерно высокой. 2.4.27. Сообщения между учетными записями в одной цепочке шардов. В некоторых случаях сообщение генерируется учетной записью, принадлежащей некоторой цепочке шардов, предназначенной для другой учетной записи в той же цепочке шардов. Например, это происходит в новой рабочей цепочке, которая еще не разделена на несколько шардчейнов, потому что нагрузка управляема. Такие сообщения могут накапливаться в выходной очереди цепочки шардов, а затем обрабатываться как входящие сообщения в последующих блоках ( для этой цели любой шард считается соседом самого себя). Однако в большинстве случаев эти сообщения можно доставлять внутри самого исходного блока |