TON Blockchain Architecture
TON Blockchain Architecture — это система хранения и управления данными в блокчейне TON. Архитектура включает организацию данных, механизм разделения данных между аккаунтами и блоками (шардирование), правила проверки и защиты транзакций (условия консенсуса), а также мастерчейн (masterchain), который управляет основными параметрами и координирует работу шардчейнов (shardchain).
Всё является пакетом ячеек
В TON Blockchain все данные представлены как коллекция (пакет) ячеек (bag of cells). Каждая ячейка содержит до 1023 бит данных и до 4 ссылок на другие ячейки. Эти ячейки организованы в деревья или ориентированные ациклические графы (DAGs), что обеспечивает их структурированное хранение и обработку. Все данные блоков и состояния блокчейна сериализуются в ячейки, представляющие значения данных в соответствии со схемами TL-B (Type Language - Binary).
Структура ячейки включает два байта-дескриптора, данные и ссылки на другие ячейки, представленные SHA256-хешами. Это стандартное представление ячеек используется для их сериализации при хранении или передаче данных по сети.
Основные компоненты блока и состояния блокчейна
TON Blockchain использует The Infinite Sharding Paradigm (ISP), где каждый аккаунт рассматривается, как находящийся в своем отдельном аккаунтчейне (accountchain). Виртуальные блоки этих аккаунтчейнов группируются в блоки шардчейна для эффективности. Состояние шардчейна включает состояния всех его аккаунтов, а блок шардчейна состоит из коллекции виртуальных блоков для некоторых аккаунтов.
Блок шардчейна и его состояние делятся на две части: разделённые (split) и неразделённые (non-split). Разделённые части связаны с конкретными аккаунтами, тогда как неразделённые включают данные, такие как описание входящих и исходящих сообщений и заголовок блока.
Компоненты неразделённой части блока шардчейна:
- InMsgDescr: описание всех входящих сообщений.
- OutMsgDescr: описание всех исходящих сообщений.
- Заголовок блока (block header): общая информация, включая хеши и параметры блока.
- OutMsgQueue: очередь недоставленных сообщений, которые удаляются после их включения в соседние шардчейны.
Разделённая часть состояния шардчейна состоит из хешмапа (hashmap), сопоставляющего каждый «определенный» идентификатор аккаунта с состоянием соответствующего аккаунта. Состояние аккаунта включает баланс в Grams, код смарт-контракта, постоянные данные смарт-контракта, статистику использования хранилища, необязательное формальное описание интерфейса и публичная информация пользователя.
Обратите внимание, что в TON Blockchain нет различия между «смарт-контрактом» и «аккаунтом».
Блоки мастерчейна
Блоки и состояние мастерчейна дополняют блоки шардчейна и их состояния. Мастерчейн не делится и не объединяется, обычно имеет одного предшественника, за исключением нулевого блока с начальной конфигурацией.
Условия консенсуса
Важным компонентом структуры блокчейна являются условия консенсуса между данными, хранимыми в блоках. Эти условия обеспечивают правильность и безопасность блокчейна, гарантируя, что данные изменяются только допустимыми способами — в результате транзакций внутри блоков.
Виды условий консенсуса
- Глобальные условия — инварианты, которые действуют на весь блокчейн, такие как гарантии доставки сообщений.
- Внутренние (локальные) условия — условия, наложенные на данные внутри одного блока, например, обработка входящих сообщений в транзакциях.
- Внешние (локальные) условия — условия, касающиеся данных в разных блоках, обычно принадлежащих соседним шардчейнам.
Условия валидности для блока
Все глобальные и локальные условия, касающиеся блока, составляют условия валидности. Блок считается валидным, если он удовлетворяет этим условиям. Ответственность за генерацию и проверку валидности блоков лежит на валидаторах. Если блок не соответствует условиям валидности, он является недействительным.
Логическое время
Логическое время (LT) в TON Blockchain — это неотрицательное 64-битное целое число, назначаемое определенным событиям. Если событие зависит от других событий, его логическое время больше, чем у всех зависимых от него событий. Например, если событие не зависит от предыдущих, его LT равно 0.
TON Blockchain использует логическое время и интервалы для различных компонентов. Например, исходящие сообщения, созданные в транзакции, получают логическое время создания. Это время зависит от предыдущих сообщений и транзакций того же аккаунта. Каждой транзакции присваивается логический временной интервал, а блоки, состоящие из таких транзакций и сообщений, также получают свои интервалы, которые указываются в заголовке блока.
Общее состояние блокчейна
Каждый блок мастерчейна содержит список всех текущих активных шардов и последних блоков для каждого из них. В этом отношении каждый блок мастерчейна определяет соответствующее общее состояние TON Blockchain, так как он фиксирует состояние каждого шардчейна и мастерчейна.
Каждый блок шардчейна содержит хеш последнего блока мастерчейна в своём заголовке. Это означает, что все блоки, указанные в этом блоке мастерчейна и их предшественники, считаются «видимыми» для блока шардчейна. Блок шардчейна должен импортировать сообщения из OutMsgQueue состояний видимых соседних шардчейнов и не может содержать сообщения из «невидимых» блоков, даже если они правильные.
Конфигурируемые параметры и смарт-контракты
В TON Blockchain существуют так называемые конфигурируемые параметры, которые могут быть определенными значениями или смарт-контрактами, находящимися в мастерчейне.
К конфигурируемым параметрам относятся:
- Минимальный взнос для валидаторов.
- Максимальный размер группы валидаторов.
- Максимальное количество блоков, за которые отвечает группа валидаторов.
- Процесс выборов и наказания валидаторов.
- Текущий и следующий набор валидаторов.
- Процесс изменения конфигурируемых параметров.
Конфигурируемые параметры хранятся в постоянных данных специального конфигурационного смарт-контракта, находящегося в мастерчейне. Начальные значения большинства параметров и код фундаментальных смарт-контрактов присутствуют в нулевом блоке мастерчейна, являясь частью начального состояния блокчейна.
Новые смарт-контракты и их адреса
Механизмы создания новых смарт-контрактов и присвоения им адресов, описанные ниже, валидны только для базового воркчейна и мастерчейна. Другие воркчейны могут использовать свои собственные механизмы для этих целей.
Сообщения могут быть отправлены на ранее не упомянутые аккаунты. Если такое сообщение содержит значение, оно создаёт «неинициализированный аккаунт» с балансом, но без кода и данных. Смарт-контракт создаётся путём отправки специального сообщения-конструктора на его адрес. Это сообщение содержит начальный код и данные смарт-контракта. Сообщение-конструктор также обычно должно нести некоторое значение, которое будет переведено на баланс нового смарт-контракта. Минимальный баланс зависит от объёма используемого хранилища.
Смарт-контракты могут автоматически создавать новые смарт-контракты при обработке транзакций. Пользователь может скомпилировать код для нового смарт-контракта, сгенерировать сообщение-конструктор и использовать свой смарт-контракт кошелька для отправки этого сообщения и создания нового смарт-контракта.
Модификация и удаление смарт-контрактов
Постоянные данные смарт-контракта обычно изменяются в результате выполнения кода смарт-контракта в TVM при обработке транзакции, вызванной входящим сообщением. Если код смарт-контракта не предусматривает изменения данных, то данные остаются неизменными. Сам код смарт-контракта может быть изменен только в том случае, если текущий код предусматривает такие изменения.
Смарт-контракт не может быть уничтожен, пока его баланс не станет нулевым или отрицательным. Это может произойти из-за сборов за хранилище или после отправки исходящего сообщения, переводящего почти все средства. Например, пользователь может перевести все средства на другой кошелек или смарт-контракт для обновления.
Когда баланс аккаунта становится отрицательным или меньше определенного минимума, аккаунт замораживается, заменяя его код и данные на 32-байтовый хеш. Хеш сохраняется некоторое время, чтобы позволить владельцу восстановить аккаунт, переведя средства и отправив сообщение с кодом и данными.