Файл: Аннотация Цель данной работы предоставить первое описание блокчейнплатформы ton (The Open Network) и связанных с ней технологий одноранговых сетей, распределенного хранилища и хостинга..pdf

22 2.3. Состояние блокчейна, учетные записи и хэш-карты
2.3.20. Состояние учетной записи/смарт-контракта. На основании всего вышесказанного мы можем сделать вывод, что состояние учетной записи или смарт- контракта включает следующее:
• Баланс в основной валюте блокчейна
• Баланс в других валютах блокчейна
• Код смарт-контракта (или его хэш)
• Постоянные данные смарт-контракта (или соответствующий хэш Меркла)
• Статистика количества используемых ячеек постоянного хранения и необработанных байтов
• Последний раз (собственно, номер блока мастерчейна), когда была получена оплата за постоянное хранение смарт-контракта
• Открытый ключ, необходимый для перевода валюты и отправки сообщений с этой учетной записи (необязательно; по умолчанию равен самому идентификатору account_id). В некоторых случаях здесь может быть расположен более сложный код проверки подписи, аналогично коду, который используется для выходных данных транзакции биткоина; тогда идентификатор account_id будет равен хэшу этого кода.
• Также в состоянии учетной записи или в какой-либо другой хэш-карте, индексированной учетной записью, необходимо хранить следующие данные:
• Очередь выходных сообщений учетной записи (см. 2.4.17)
• Набор (хэшей) недавно доставленных сообщений (см. 2.4.23)
Не все эти функции действительно необходимы для каждой учетной записи; например, код смарт-контракта нужен только для смарт-контрактов, но не для
«простых» учетных записей. Кроме того, хотя на любой учетной записи должен быть ненулевой баланс в основной валюте (например, монеты TON для мастерчейна и щардчейнов основного воркчейна), на ней могут быть нулевые балансы в других валютах. Чтобы избежать хранения неиспользуемых данных, (во время создания воркчейна) определяется тип суммы-произведения (в зависимости от воркчейна), который использует разные байты тегов (например, конструкторы TL; см. 2.2.5), чтобы различать разные « конструкторы ». В конечном итоге, состояние учетной записи сохраняется как набор ячеек постоянного хранилища TVM.
2.4. Сообщения между шардчейнами
Важным компонентом блокчейна TON является система обмена сообщениями между блокчейнами. Эти блокчейны могут быть шардчейнами одного или разных воркчейнов.
2.4.1. Сообщения, счета и транзакции: общая структура системы. Сообщения отправляются из одной учетной записи в другую. Каждая транзакция включает следующие этапы: учетная запись получает одно сообщение, меняет свое состояние в соответствии с определенными правилами и генерирует несколько (возможно, одно или ноль) новых сообщений для других учетных записей. Каждое сообщение создается и принимается (доставляется) ровно один раз.
Это означает, что сообщения играют в системе фундаментальную роль, сравнимую с ролью учетных записей (смарт-контрактов). С точки зрения парадигмы бесконечного шардинга (см. 2.1.2), каждая учетная запись находится в своей отдельной «цепочке учетных записей», и единственный способ повлиять на состояние какой-либо другой учетной записи - это отправить сообщение.
11
Более дорогая альтернатива - опубликовать такой «глобальный» смарт-контракт в мастерчейне.
12
Это своего рода «широковещательная» функция для всех шардов, и поэтому она должна быть довольно дорогой

23 2.4. Сообщения между шардчейнами
2.4.2. Учетные записи как процессы или субъекты; модель акторов. Можно воспринимать учетные записи (и смарт-контракты) как «процессы» или «акторы», которые могут обрабатывать входящие сообщения, изменять свое внутреннее состояние и в результате генерировать некоторые исходящие сообщения. Это тесно связано с так называемыми моделями акторов, которые используются в таких языках, как Erlang (однако акторы в Erlang обычно называются «процессами»). Поскольку новые акторы (то есть смарт-контракты) также могут быть созданы существующими акторами в результате обработки входящего сообщения, наблюдается практически полное соответствие с моделью акторов.
2.4.3. Получатель сообщения. У любого сообщения есть получатель, который характеризуется идентификатором целевого воркчейна w (предполагается, что по умолчанию он такой же, как идентификатор исходного шардчейна) и учетной записью получателя account_id. Точный формат (т. е. количество битов) account_id зависит от w; однако шард всегда определяется его первыми (наиболее значимыми) 64 битами.
2.4.4. Отправитель сообщения. В большинстве случаев у сообщения есть отправитель, который характеризуется парой (w', account_id'). При наличии такого идентификатора он находится после получателя сообщения и ценности сообщения.
Иногда отправитель не важен, либо это кто-то за пределами блокчейна (то есть не смарт-контракт), поэтому это поле отсутствует.
Обратите внимание, что в модели акторов не требуется, чтобы сообщения имели неявного отправителя. Вместо этого сообщения могут содержать ссылку на актора, которому должен быть отправлен ответ на запрос (обычно совпадает с отправителем).
Однако полезно иметь поле явного не поддающегося подделке отправителя в сообщении в криптовалютной среде, в которой применяется задача византийских генералов.
2.4.5. Стоимость сообщения. Другой важной характеристикой сообщения является его прикрепленная стоимость в одной или нескольких криптовалютах, поддерживаемых как исходным, так и целевой воркчейном. Стоимость указывается в самом начале сообщения сразу после получателя сообщения; по сути, это список пар
(currency_id, value).
Обратите внимание, что «простые» транзакции стоимости между «простыми» учетными записями - это пустые сообщения с некоторой прикрепленной к ним стоимостью. С другой стороны, немного более сложное тело сообщения может содержать простой текст или двоичный комментарий (например, о цели платежа).
2.4.6. Внешние сообщения или «сообщения из ниоткуда». Некоторые сообщения поступают в систему «из ниоткуда», то есть они не генерируются учетной записью
(смарт-контрактом), находящейся в блокчейне. Наиболее типичный пример - когда пользователь хочет перевести часть средств с контролируемой им учетной записи на другую учетную запись.
В этом случае пользователь отправляет «сообщение из ниоткуда» в свою учетную запись, запрашивая создание сообщения для принимающей учетной записи, содержащего указанное значение. Если это сообщение правильно подписано, учетная запись получает его и генерирует необходимые исходящие сообщения.
Фактически, можно рассматривать «простую» учетную запись как частный случай смарт-контракта с предопределенным кодом. Этот смарт-контракт получает только один тип сообщения. Такое входящее сообщение должно содержать список исходящих сообщений, которые должны быть сгенерированы в результате доставки
(обработки) входящего сообщения, вместе с подписью. Смарт-контракт проверяет подпись и, если она верна, генерирует необходимые сообщения.

24 2.4. Сообщения между шардчейнами
Конечно, есть разница между «сообщениями из ниоткуда» и обычными сообщениями, поскольку «сообщения из ниоткуда» не могут иметь стоимости, и соответственно не могут сами платить за «газ» (то есть за их обработку). Вместо этого они предварительно выполняются с небольшим лимитом газа, прежде чем будет предложено их включение в новый блок шардчейна; если выполнение не удается
(подпись неверна), «сообщение из ниоткуда» считается неверным и отбрасывается.
Если выполнение будет завершено в пределах небольшого лимита газа, сообщение может быть включено в новый блок шардчейна и полностью обработано, при этом оплата за потребленный газ (мощность обработки) будет взиматься со счета получателя. Для «сообщений из ниоткуда» также может быть определена некоторая комиссия за транзакцию, которая снимается со счета получателя сверх платы за газ и перераспределяется между валидаторами.
В этом смысле «сообщения из ниоткуда» или «внешние сообщения» выступают в роли кандидатов на транзакции, используемых в других системах блокчейнов
(например, Биткоин и Эфириум).
2.4.7. Сообщения журнала или «сообщения в никуда». Точно так же иногда может быть сгенерировано специальное сообщение, которое направляется в конкретный шардчейн не для доставки его получателю, а для регистрации в журнале, чтобы это сообщение мог легко заметить любой пользователь, который получает обновления о рассматриваемом шарде. Такие зарегистрированные сообщения могут выводиться на консоль пользователя или запускать выполнение некоторого сценария на сервере вне сети. В этом смысле они представляют собой внешний «выход» «суперкомпьютера с блокчейном», так же как «сообщения из ниоткуда» представляют собой внешний
«вход» «суперкомпьютера с блокчейном».
2.4.8. Взаимодействие с сервисами вне блокчейна и внешними блокчейнами. Эти внешние входные и выходные сообщения могут использоваться для взаимодействия с сервисами вне блокчейна и другими (внешними) блокчейнами, такими как Биткоин или Эфириум.
В блокчейне TON можно создавать токены или криптовалюты, привязанные к биткойну, эфиру или любым токенам ERC-20, определенным в блокчейне Ethereum, и использовать «сообщения из ниоткуда» и «сообщения в никуда», генерируемые и обрабатываемые скриптами, находящимися на сторонних серверах вне блокчейна, чтобы реализовать необходимое взаимодействие между блокчейном TON и этими внешними блокчейнами.

25 2.4. Сообщения между шардчейнами транзакции и аналогичных значениях, которые зависят от принимающего воркчейна и актуальны только для него, но не обязательно для исходного воркчейна. Такие параметры включаются в тело сообщения или перед ним, иногда (в зависимости от воркчейна) со специальными 4-байтовыми префиксами, указывающими на их присутствие (которые могут быть определены с помощью TL-схемы; см. 2.2.5).
2.4.11. Создание сообщений: смарт-контракты и транзакции. Существуют два источника новых сообщений. Большинство сообщений создается во время выполнения смарт-контракта (посредством операции Send() в VM TON), когда для обработки входящего сообщения вызывается какой-либо смарт-контракт. Как вариант, сообщения могут приходить извне как «внешние сообщения» или
«сообщения из ниоткуда» (см. 2.4.6)
13
2.4.12. Доставка сообщений. Когда сообщение достигает шардчейна, содержащего целевую учетную запись, оно «доставляется» в целевую учетную запись
14
Дальнейшие процессы зависят от воркчейна; со стороны важно, чтобы такое сообщение никогда не могло быть переадресовано дальше этого шардчейна.
Для шардчейнов основного воркчейна доставка заключается в добавлении стоимости сообщения (за вычетом любых платежей за газ) к балансу принимающей учетной записи и, возможно, в последующем вызове зависимого от сообщения метода получающего смарт-контракта, если получающая учетная запись является смарт- контрактом. Фактически, смарт-контракт имеет только одну точку входа для обработки всех входящих сообщений, поэтому он должен различать разные типы сообщений путем анализа первых нескольких байтов (например, первые четыре байта, содержащие конструктор TL; см. 2.2.5).
2.4.13. Доставка сообщения как транзакция. Поскольку доставка сообщения изменяет состояние учетной записи или смарт-контракта, этот процесс является особой транзакцией в принимающем шардчейне, которая явно регистрируется как таковая. По сути, без учета некоторых незначительных технических деталей, все транзакции в блокчейне TON представляют собой доставку одного входящего сообщения в принимающую учетную запись (смарт-контракт).
2.4.14. Сообщения между экземплярами одного и того же смарт-контракта.
Напомним, что смарт-контракт может быть локальным (т. е. может находиться в одной шардчейне, как и любая обычная учетная запись) или глобальным (т. е. иметь экземпляры во всех шардах или, по крайней мере, во всех шардах до некоторой известной глубины d; см. 2.3.18). При необходимости экземпляры глобального смарт- контракта могут обмениваться специальными сообщениями между собой для передачи информации и стоимости. В этом случае особенно важным становится (не поддающийся подделке) идентификатор account_id (см. 2.4.4).
2.4.15. Сообщения на любой экземпляр смарт-контракта; адреса с
подстановочными знаками. Иногда сообщение (например, запрос клиента) необходимо доставить в любой экземпляр глобального смарт-контракта, обычно ближайший (если он находится в том же шардчейне, что и отправитель, это очевидный кандидат).
13
Вышеупомянутое должно быть верным только для исходного воркчейна и соответствующих шардчейнов. Другие воркчейны могут предоставлять другие способы создания сообщений.

26 2.4. Сообщения между шардчейнами
Один из способов сделать это - использовать «адрес получателя с подстановочными знаками», при этом первым d битам целевого идентификатора account_id разрешено принимать произвольные значения. На практике для этих битов d обычно устанавливаются те же значения, что и в идентификаторе отправителя account_id.
2.4.16. Отсутствие очереди ввода. Все сообщения, полученные блокчейном (обычно шардчейном, иногда мастерчейном) - или, по сути, «цепочкой учетных записей», находящейся внутри определенного шардчейна, - немедленно доставляются (т. е. обрабатываются принимающей учетной записью).
Следовательно, «очередь ввода» как таковая отсутствует. Вместо этого, если из-за ограничений на общий размер блоков и использование газа могут быть обработаны не все сообщения, предназначенные для определенного шардчейна, некоторые сообщения просто накапливаются в очередях вывода исходных шардчейнов.
2.4.17. Очереди вывода. С точки зрения парадигмы бесконечного шардинга (см.
2.1.2), каждая цепочка учетных записей (т. е. каждая учетная запись) имеет свою собственную очередь вывода, состоящую из всех сообщений, которые были в ней сгенерированы, но еще не доставлены получателям. Конечно, цепочки учетных записей существуют только виртуально; они сгруппированы в шардчейны, а шардчейн имеет выходную «очередь», состоящую из очередей вывода всех учетных записей, относящихся к шардчейну.
Эта выходная «очередь» шардчейна обеспечивает только частичный порядок в сообщениях участников шардчейна. А именно, сообщение, сгенерированное в предыдущем блоке, должно быть доставлено до любого сообщения, сгенерированного в последующем блоке, а любые сообщения, сгенерированные той же учетной записью и имеющие то же место назначения, должны быть доставлены в порядке их генерации.
2.4.18. Надежный и быстрый обмен сообщениями между цепями. В масштабируемом проекте с несколькими блокчейнами (таком как TON) чрезвычайно важно иметь возможность пересылать и доставлять сообщения между разными шардчейнами (см. 2.1.3), даже если в системе их миллионы. Необходимо обеспечить надежную (т. е. сообщения не должны теряться или доставляться более одного раза) и быструю доставку сообщений. В блокчейне TON эта цель достигается путем использования комбинации двух механизмов «маршрутизации сообщений».
2.4.19. Маршрутизация в гиперкубе: «медленный путь» для сообщений с
гарантированной доставкой. В блокчейне TON применяется технология
«маршрутизации в гиперкубе» в качестве медленного и одновременно безопасного и надежного способа доставки сообщений из одного шардчейна в другой, причем при необходимости для передачи используется несколько промежуточных шардчейнов. В противном случае валидаторам любого данного шардчейна потребуется отслеживать состояние (очередей вывода) всех других шардчейнов, что потребует непомерно больших вычислительных мощностей и пропускной способности сети по мере роста общего количества шардчейнов и приведет к ограничению масштабируемости. системы. Следовательно, возможность доставлять сообщения напрямую из одного шарда в другой отсутствует. Вместо этого каждый шард «подключен» только к шардам, которые отличаются ровно одной шестнадцатеричной цифрой в идентификаторах (w, s) (см. 2.1.8).
14
В качестве вырожденного случая этот шардчейн может совпадать с исходным шардчейном, например, если операция выполняется внутри воркчейна, который еще не была разделен.