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

7 2.1. Блокчейн TON как структура, состоящая из 2D-блокчейнов
2.1.10. Динамическое разделение и объединение шардчейнов (см 2.7). В менее сложной системе может использоваться статический шардинг - например, с использованием первых восьми битов идентификатора account_id для выбора одного из 256 предопределенных шардов.
Важной особенностью блокчейна TON является то, что в нем реализуется динамический шардинг – это означает, что количество шардов не является фиксированным. Вместо этого шард (w, s) можно автоматически разделить на несколько новых шардов (w,s.0) и (w, s.1), если выполняются некоторые формальные условия (по сути, если транзакционная нагрузка на исходный шард достаточно высока в течение продолжительного периода времени). И наоборот, если нагрузка остается слишком низкой в течение некоторого периода времени, шарды (w, s.0) и (w, s.1) могут быть автоматически объединены в исходный шард (w, s).
Изначально для воркчейна w создается только один шард (w, θ). Позже при необходимости он может быть разделен на несколько шардов (см. 2.7.6 и 2.7.8).
2.1.11. Исходный воркчейн или Workchain Zero. Несмотря на то, что в системе может быть создано до 2 32
воркчейнов с соответствующими конкретными правилами и транзакциями, изначально задается только один воркчейн (workchain_ id = 0). Этот воркчейн, называемый Workchain Zero или исходный воркчейн, используется для работы со смарт-контрактами TON и перевода монет TON (см. Приложение). Скорее всего, для большинства приложений потребуется только Workchain Zero. Шардчейны базового воркчейна будут называться исходными шардчейнами.
2.1.12. Интервалы генерации блоков. Ожидается, что новый блок будет генерироваться в каждом шардчейне и мастерчейне примерно раз в пять секунд. Это приведет к разумно малому времени подтверждения транзакции. Новые блоки всех шардчейнов будут генерироваться примерно одновременно; новый блок мастерчейна создается примерно на одну секунду позже, поскольку он должен содержать хэши последних блоков всех шардчейнов.

8 2.1. Блокчейн TON как структура, состоящая из 2D-блокчейнов точки зрения внешнего наблюдателя. Поэтому нет необходимости следить за состоянием всех шардчейнов по отдельности.
2.1.15. Генерация новых блоков валидаторами (см. 2.6). В блокчейне TON используется метод защиты Proof-of-Stake (подтверждение доли, PoS) для создания новых блоков в шардчейнах и мастерчейнах. Это означает, что существует, скажем, до нескольких сотен валидаторов - специальных узлов, которые внесли стейки
(большие количества монет TON) с помощью специальной транзакции мастерчейна, чтобы иметь право на создание и проверку новых блоков.
Затем детерминированным псевдослучайным образом каждому сегменту (w, s) назначается меньшее подмножество валидаторов, которое изменяется примерно каждые 1024 блока. Это подмножество валидаторов предлагает и достигает консенсуса в отношении того, каким будет следующий блок шардчейна, путем сбора подходящих предлагаемых транзакций от клиентов в новые допустимые блоки- кандидаты. Для каждого блока существует псевдослучайно выбранный порядок валидаторов, который позволяет определить, чей блок-кандидат имеет наивысший приоритет для фиксации в каждой очереди.
Валидаторы и другие узлы проверяют действительность предложенных блоков- кандидатов; если валидатор подписывает недопустимый блок-кандидата, он может быть автоматически наказан потерей части своей стейка или всего стейка, либо лишением функций валидатора на некоторое время. После этого валидаторы должны прийти к консенсусу по выбору следующего блока. По сути, это достигается с помощью эффективного протокола консенсуса BFT (задача византийских генералов; см. 2.8.4), подобного PBFT [4] или Honey Badger BFT [11]. При достижении консенсуса создается новый блок, после чего валидаторы делят между собой комиссию за транзакции, включенные в транзакцию, плюс некоторые вновь созданные («отчеканенные») монеты.
Каждый валидатор может быть избран для участия в нескольких подмножествах валидаторов; в этом случае предполагается, что все алгоритмы проверки и согласования будут выполняться параллельно.
После того, как все новые блоки гардчейна были сгенерированы, либо истекло время ожидания, создается новый блок мастерчейна, включая хэши последних блоков всех сегментов шардчейнов. Эта задача реализуется на основе консенсуса BFT всех валидаторов
2
Более подробная информация о подходе TON PoS и соответствующей экономической модели представлена в разделе 2.6.
2.1.16. Форки мастерчейна. Сложность нашей предлагаемой системы «с сильной связью» заключается в том, что переключение на другой форк в мастерчейне почти обязательно потребует переключения на другой форк как минимум в некоторых из шардчейнов.
С другой стороны, до тех пор, пока в мастерчейне нет форков, форки в шардчейне невозможны, поскольку никакие блоки в альтернативных форках шардчейнов не могут стать «эталонными», если их хэши включены в блок мастерчейна.
Общее правило состоит в том, что если блок B’ мастерчейна является предшественником B, то B’ включает хэш HASH(B’w,s) из B’w,s блока шардчейна
(w,s), а B включает хэш HASH(Bw,s), тогда B’w,s должен быть предшественником
Bw,s. В противном случае блок B мастерчейна является невалидным.
Ожидается, что форки мастерчейна будут редким, практически невозможным явлением, поскольку в парадигме ВFT, принятой в блокчейне TON, они могут возникать только в случае некорректного поведения большинства валидаторов (см.
2.6.1 и 2.6.15), что повлечет за собой значительную потерю нарушителями их стейков.
Следовательно, не следует ожидать настоящих форков в шардчейнах. Вместо этого, в

9 2.1. Блокчейн TON как структура, состоящая из 2D-блокчейнов случае обнаружения недопустимого блока шардчейна, он будет исправлен с помощью механизма «вертикального блокчейна» (2-блокчейна) (см. 2.1.17), который может достичь этой цели без создания форков «горизонтального блокчейна» (т. е., шардчейна). Тот же механизм можно использовать и для исправления некритических ошибок в блоках мастерчейна.
2.1.17. Исправление неверных блоков шардчейна. Обычно фиксируются только действительные блоки шардчейна, потому что валидаторы, назначенные для шардчейна, должны достичь консенсуса в две трети при решении задачи византийских генералов, прежде чем может быть зафиксирован новый блок. Однако система должна обеспечивать обнаружение ранее зафиксированных недопустимых блоков и их исправление.
Конечно, при обнаружении невалидного блока шардчейна - либо валидатором (не обязательно назначенным для этого шардчейна), либо «фишерменом» (любым узлом системы, сделавшим определенный депозит, чтобы иметь возможность поднимать вопросы о валидности блока; см. 2.6.4) - заявление о невалидности и соответствующие доказательства передаются в мастерчейн, а валидаторы, подписавшие невалидный блок, наказываются потерей части своего стейка и/или временно лишаются права выполнять функции валидатора (последняя мера важна в том случае, если злоумышленник украл закрытые ключи подписи надежного валидатора).
Однако этого недостаточно, потому что общее состояние системы (блокчейна TON) оказывается недопустимым из-за ранее зафиксированного недопустимого блока в шардчейне. Этот недопустимый блок необходимо заменить более новой действующей версией.
В большинстве систем эта задача достигается путем «отката» к последнему блоку перед недопустимым блоком в данном шардчейне и последним блокам, не затронутым сообщениями, передаваемыми из недопустимого блока в каждый из других блокчейнов, а также созданием нового форка из этих блоков. Недостатком этого подхода является то, что внезапно откатывается большое количество корректных и подтвержденных транзакций, и неясно, будут ли они вообще включены в систему позже.
Блокчейн TON решает эту проблему, превращая каждый «блок» каждого шардчейна и мастерчейна («горизонтальные блокчейны») в небольшой блокчейн («вертикальный блокчейн»), содержащий разные версии этого «блока» или их «различия». Обычно вертикальный блокчейн состоит ровно из одного блока, а шардчейн имеет вид классического блокчейна. Однако, как только невалидность блока будет подтверждена и зафиксирована в блоке мастерчейна, к «вертикальному блокчейну» недопустимого блока разрешается добавить новый блок в вертикальном направлении, после чего будет выполнена замена или изменение недопустимого блока. Новый блок генерируется текущим подмножеством валидаторов для рассматриваемого шардчейна.
Для нового «вертикального» блока действуют довольно строгие правила. В частности, если виртуальный «блок цепочки учетных записей» (см. 2.1.2), содержащийся в недопустимом блоке, действителен сам по себе, он должен быть оставлен без изменений со стороны нового вертикального блока.
Как только новый «вертикальный» блок фиксируется поверх недопустимого блока, его хэш публикуется в новом блоке мастерчейна (или, скорее, в новом
«вертикальном» блоке, находящемся над исходным блоком мастерчейна, где был первоначально опубликован хэш недопустимого блока шардчейна),
2
На самом деле, двух третей голосов достаточно для достижения консенсуса, однако система старается собрать как можно больше подписей.

10 2.1. Блокчейн TON как структура, состоящая из 2D-блокчейнов а изменения распространяются дальше на любые блоки шардчейна, относящиеся к предыдущей версии этого блока (например, блоки, которые получили сообщения от некорректного блока).
Исправление этой проблемы достигается путем фиксации новых «вертикальных» блоков в вертикальных блокчейнах для всех блоков, ранее ссылающихся на
«некорректный» блок. Новые вертикальные блоки будут ссылаться на самые последние (исправленные) версии. Опять же, строгие правила запрещают изменять цепочки учетных записей, которые не были фактически затронуты (т. е. получают те же сообщения, что и в предыдущей версии). Таким образом, исправление некорректного блока создаёт «волны», которые в конечном итоге распространяются к самым недавним блокам всех затронутых шардчейнов; эти изменения также отражены в новых "вертикальных" блока мастерчейна.
Когда «рябь перезаписи истории» достигает самых последних блоков, новые блоки шардчейна генерируются только в одной версии и становятся преемниками только новейших версий блоков. Это означает, что они с самого начала будут содержать ссылки на правильные (самые последние) вертикальные блоки.
Состояние мастерчейна неявно определяет карту, преобразующую хэш первого блока каждого «вертикального» блокчейна в хэш последней версии. Это позволяет клиенту идентифицировать и определять местонахождение любого вертикального блокчейна по хэшу самого первого (и обычно единственного) блока.
2.1.18. Монеты TON и мультивалютные воркчейны. Блокчейн TON поддерживает до 2 32
различных «криптовалют», «монет» или «токенов», которые различаются 32- битным идентификатором currency_id. Новые криптовалюты добавляются с помощью специальных транзакций в мастерчейне. Каждый воркчейн имеет базовую криптовалюту и может иметь несколько дополнительных криптовалют.
Существует одна специальная криптовалюта с идентификатором currency_id = 0, а именно монета TON (см. Приложение A). Это основная криптовалюта исходного блокчейна. Она также используется в качестве комиссии за транзакции и для определения стейков валидаторов.
В принципе, другие воркчейны могут собирать комиссию за транзакции в других токенах. Для этого необходимо предоставить смарт-контракт для автоматического преобразования этих комиссий за транзакции в монеты TON.
2.1.19. Обмен сообщениями и транзакции стоимости. Шардчейны, принадлежащие к одному воркчейну или разным воркчейнам, могут отправлять сообщения друг другу.
Несмотря на то, что точная форма разрешенных сообщений зависит от принимающего воркчейна и принимающей учетной записи (смарт-контракт), существуют некоторые общие поля, которые делают возможным обмен сообщениями между воркчейнами. В частности, к каждому сообщению может быть прикреплена некоторая стоимость в виде определенного количества монет TON и/или других зарегистрированных криптовалют, при условии, что они объявлены принимающим воркчейном как приемлемые криптовалюты.
Самая простая форма такого обмена сообщениями - это перенос стоимости из одной учетной записи (обычно не смарт-контракта) в другую учетную запись.
2.1.20. Виртуальная машина TON. Виртуальная машина TON, также сокращенно
TON VM или TVM, - это виртуальная машина, используемая для выполнения кода смарт-контракта в мастерчейне и в исходном воркчейне. В других воркчейнах могут использоваться другие виртуальные машины вместе с TVM или вместо TVM.
Ниже приведены некоторые особенности виртуальной машины TON. Они обсуждаются далее в 2.3.12, 2.3.14 и других разделах.
•

11 2.1. Блокчейн TON как структура, состоящая из 2D-блокчейнов
• TVM представляет все данные как набор ячеек (TVM) (см. 2.3.14). Каждая ячейка содержит до 128 байтов данных и до 4 ссылок на другие ячейки.
Применение концепции «все есть мешок ячеек» (см. 2.5.14) позволяет TVM работать со всеми данными, относящимися к блокчейну TON, включая блоки и глобальное состояние блокчейна, если это необходимо.
• TVM может работать со значениями произвольных алгебраических типов данных (см. 2.3.12), представленными в виде деревьев или ориентированных ациклических графов из ячеек TVM. Однако виртуальная машина TON не зависит от существования алгебраических типов данных, она просто работает с ячейками.
• TVM имеет встроенную поддержку хэш-карт (см. 2.3.7).
• TVM является стековой вычислительной машиной. В стеке TVM хранятся либо 64-битные целые числа, либо ссылки на ячейки.
• Поддерживаются 64-битные, 128-битные и 256-битные арифметические операции. Все n-битные арифметические операции бывают трех видов: для целых чисел без знака, для целых чисел со знаком и для целых чисел по модулю
2
n
(в последнем случае автоматический контроль переполнения отсутствует).
• TVM обеспечивает преобразование целых чисел без знака и со знаком из n- битн в m-бит для всех 0 ≤ m, n ≤ 256 с контролем переполнения.
• По умолчанию для всех арифметических операций выполняется контроль переполнения, что значительно упрощает разработку смарт-контрактов.
• TVM выполняет арифметические операции «умножить, затем сдвинуть» и
«сдвинуть и разделить» с промежуточными значениями, вычисленными в большем целочисленном типе данных; это упрощает выполнение арифметических операций с фиксированной точкой.
• TVM предлагает поддержку строк битов и строк байтов.
• Присутствует поддержка 256-битное шифрование на основе эллиптических кривых (ECC) для некоторых предопределенных кривых, включая Curve25519.
• Также присутствует поддержка пар Вейля для некоторых эллиптических кривых, необходимая для быстрой реализации zk-SNARK.
• Присутствует поддержка популярных хэш-функций, в том числе SHA256.
• TVM может работать с доказательствами Меркла (см. 5.1.9),
• TVM предлагает поддержку «больших» или «глобальных» смарт-контрактов.
В таких смарт-контрактах должна быть информация о шардинге (см. 2.3.18 и
2.3.16). В обычных (локальных) смарт-контрактах может отсутствовать информация о шардинге.
• TVM поддерживает замыкания.
• На TVM может быть легко реализована машина сокращения графов (spineless tagless G-machine) [13].
В дополнение к «сборке TVM» могут быть разработаны несколько высокоуровневых языков программирования. Все эти языки будут статического типа и будут поддерживать алгебраические типы данных. Мы предполагаем следующие возможности:
• Императивный язык, подобный Java, в котором каждый смарт-контракт похож на отдельный класс.
• Функциональный язык для ленивых вычислений (Haskell).
• Функциональный язык для немедленных вычислений (ML).
2.1.21. Настраиваемые параметры. Важной особенностью блокчейна TON является то, что многие его параметры являются конфигурируемыми. Это означает, что они являются частью состояния мастерчейна и могут быть изменены с помощью определенных транзакций предложения/голосования/результатов в мастерчейне без необходимости форков. Для изменения таких параметров в пользу предложения