Основы блокчейна

В этом разделе разобраны основные концепции, на которых основана работа транзакций в TON. Вы узнаете, как взаимодействуют аккаунты и смарт-контракты, как сообщения запускают асинхронные транзакции и как мультичейн-структура TON записывает эти транзакции.

Модель выполнения

Актор

Актор — это абстрактная поведенческая модель. Она формализована как вычислительный объект, который реагирует на входящие сообщения, изменяет своё внутреннее состояние, отправляет сообщения другим акторам и создаёт новых. Акторы изолированы: у них нет доступа к состояниям друг друга, они взаимодействуют только сообщениями.

Другими словами:

Актор — независимая сущность со своим состоянием и поведением. Акторы взаимодействуют, обмениваясь сообщениями. Каждый актор может:

• изменять своё состояние
• отправлять сообщения другим акторам
• порождать новых акторов

Модель акторов

Модель акторов — это модель параллельных вычислений, которая описывает систему как набор акторов, взаимодействующих с помощью передачи сообщений.

Ключевые свойства модели:

• изоляция акторов
• асинхронная связь
• любая вычислительная абстракция может быть реализована как актор

Модель используется для точного описания и анализа распределённых систем. Например:

• Электронная почта может быть смоделирована как система акторов: пользователи представлены как акторы, чьими адресами служат адреса электронной почты.
• Веб-сервисы с эндпоинтами (например, SOAP) можно воспринимать как акторов, обрабатывающих сообщения, отправленные на их адреса.

Аккаунт

Аккаунт в TON — это актор, характеризующийся следующими компонентами:

• Свойства аккаунта — общие свойства любого аккаунта: ID, баланс, статус и последняя транзакция (last_tx)
• Данные — данные, зависящие от пользователя
• Код — логика конкретного аккаунта, определяющая его поведение

В TON аккаунты всех типов определяются общим состоянием. Примеры:

• (ID1, 0 TON, nonexist)
• (ID2, 10 TON, uninit, last_tx)
• (ID3, -0.5 TON, frozen)

Смарт-контракт

Смарт-контракт — это аккаунт, чьи код и данные уже развёрнуты в блокчейне в дополнение к его общему состоянию.

Разница между аккаунтом и смарт-контрактом

• Аккаунт — это актор, у которого есть общее состояние (такое как баланс, адрес и статус), а также опционально могут быть код и данные.

Пример: (ID1, 0 TON, nonexist) или (ID2, 2 TON, active, last_tx, data, code)

• Смарт-контракт — это актор с развёрнутыми кодом и данными, которые определяют его поведение.

Пример: (ID2, 2 TON, active, data, code)

Структура сущностей в блокчейне TON

Асинхронность

В TON контракты (акторы) не вызывают друг друга напрямую. Вместо этого они общаются, отправляя сообщения, каждое из которых обрабатывается независимо от других. Всё взаимодействие происходит в виде асинхронной передачи сообщений.

Асинхронность — это свойство коммуникации, которое означает, что сообщение не требуется обрабатывать немедленно. Из этого следуют такие вещи:

1. Немедленный ответ не гарантирован. Получатель может ответ с задержкой или не ответить вовсе.
2. Отправитель не ждёт ответа. После отправки сообщения актор продолжает обрабатывать другие сообщения или задачи, не блокируясь и не ожидая ответа на предыдущее — даже если этот ответ никогда не придёт.
3. Порядок сообщений сохраняется. Все входящие сообщения обрабатываются в порядке их получения. Однако, если сообщение искажено или неполно, его пропускают, и следующее сообщение обрабатывается без задержки.

Это отличается от синхронных моделей, где порядок действий таков: вызов → ожидание ответа → продолжение. В TON результат можно получить только в виде отдельного сообщения — и только если оно явно отправлено.

Сообщение

Сообщение — это набор инструкций, предназначенных для одного актора.

Транзакция

Транзакция представляет собой обновление состояния аккаунта, вызванное входящим сообщением. Она также может создавать одно или несколько исходящих сообщений, в зависимости от логики контракта.

В TON транзакция требуется для обновления состояния аккаунта в ответ на входящее сообщение и, при необходимости, для продолжения взаимодействия с другими аккаунтами с помощью отправки исходящих сообщений.

Асинхронные транзакции

В TON аккаунты взаимодействуют исключительно через сообщения — это основа связи между акторами. Каждое сообщение запускает транзакцию, которая записывает весь контекст: инициирующее сообщение, обновления состояния и любые сгенерированные исходящие сообщения.

Транзакции обрабатываются асинхронно, то есть обновления каждого отдельного аккаунта и обработка сообщений происходят независимо по времени.

Компоновка данных

Структура аккаунта

Ранее мы упоминали, что аккаунт — это актор, которого определяют такие компоненты:

• Свойства аккаунта (ID, баланс, статус, last_tx)
• Данные
• Код

На практике реальные данные компонуются сложнее, но различие между аккаунтом и смарт-контрактом остаётся тем же. Для описания структур данных в TON используются схемы TL-B. Они определяют, как данные располагаются на уровне битов.

Давайте посмотрим, как определён аккаунт. Его структура состоит из нескольких вложенных объектов:

account_none$0 = Account;
account$1 addr:MsgAddressInt storage_stat:StorageInfo
          storage:AccountStorage = Account;

• Адрес — MsgAddressInt
• Баланс — CurrencyCollection
• Состояние — AccountState, оно определяет поведение аккаунта
• Логическое время последней транзакции аккаунта — last_trans_lt
• Статистика хранилища — StorageInfo

Details

account_none$0 = Account;
account$1 addr:MsgAddressInt storage_stat:StorageInfo
storage:AccountStorage = Account;

account_storage$_ last_trans_lt:uint64
balance:CurrencyCollection state:AccountState
= AccountStorage;

account_uninit$00 = AccountState;
account_active$1 _:StateInit = AccountState;
account_frozen$01 state_hash:bits256 = AccountState;

acc_state_uninit$00 = AccountStatus;
acc_state_frozen$01 = AccountStatus;
acc_state_active$10 = AccountStatus;
acc_state_nonexist$11 = AccountStatus;


_ fixed_prefix_length:(Maybe (## 5)) special:(Maybe TickTock)
code:(Maybe ^Cell) data:(Maybe ^Cell)
library:(Maybe ^Cell) = StateInit;

Давайте проясним, что из этого является свойствами аккаунта, согласно схеме TL-B:

• ID → MsgAddressInt
• Баланс → CurrencyCollection
• Статус → AccountState
• Логическое время последней транзакции (last_trans_lt) — также часть общего состояния

А данные и код определяются в поле состояния: AccountState.

Теперь давайте подробнее рассмотрим свойства аккаунта и то, как они представлены в компоновке данных.

Статус аккаунта

TON определяет такие состояния аккаунта AccountState:

Статус	Код TL-B	Описание
uninit	00	Аккаунт существует, но не содержит кода или данных. У него может быть ненулевой баланс, но он ещё не инициализирован.
frozen	01	Аккаунт заморожен: его код и данные удалены, но хеш предыдущего состояния сохранён. Его нельзя использовать, но можно восстановить. У аккаунта нулевой или отрицательный баланс, либо он не соответствует минимальным требованиям воркчейна.
active	10	Аккаунт включает StateInit, что означает «состояние инициализировано», с развёрнутыми кодом и данными. Это означает, что он уже инициализирован. Это активный смарт-контракт, готовый к обработке входящих сообщений.

account_uninit$00 = AccountState;
account_active$1 _:StateInit = AccountState;
account_frozen$01 state_hash:bits256 = AccountState;

Диаграмма ниже иллюстрирует жизненный цикл аккаунта в блокчейне TON, показывая, как его состояние меняется в различных условиях.

Структура смарт-контракта

Смарт-контракты — это набор обещаний в цифровой форме, включая протоколы, которые регулируют, как стороны выполняют эти обещания.

В TON под смарт-контрактом обычно понимают:

• Программный код, выполняемый в блокчейне и написанный на языке Tolk, FunC или Tact.
• Аккаунт, который реализует бизнес-логику и код контракта.

Техническое определение смарт-контракта в TON — это аккаунт в активном состоянии (AccountState = active), у которого:

• инициализировано поле code в StateInit, содержащее исполняемую логику
• инициализировано поле data в StateInit, хранящее постоянное состояние контракта

Адрес

Адрес в TON — это уникальный идентификатор смарт-контракта, необходимый для взаимодействия между участниками сети. У аккаунта самого по себе есть адрес, но мы полностью определяем адрес для конкретного использования только через смарт-контракт. Он состоит из следующих компонентов:

• ID воркчейна (WorkChain ID) — 32-битное целое число со знаком, указывающее воркчейн, к которому принадлежит аккаунт (например, -1 для мастерчейна, 0 для бейсчейна).
• ID аккаунта (Account ID) — 256-битный хеш структуры StateInit, которая включает инициализированные свойства контракта code, data и, опционально, library.

important

StateInit (сокращение от state initialized) может меняться за время существования контракта. Поле account_id никогда не меняется, потому что это хеш самого первого StateInit, записанного при развёртывании.

Адрес определяется как:

$${Address} := ({workchain_id},{account_id})$$

, где

$${account_id}:= {HASH(StateInit)}$$

Адрес соответствует состоянию контракта при его первичной инициализации, и может быть вычислен даже до развёртывания контракта. Это позволяет использовать адрес заранее — например, для получения токенов или настройки взаимодействий.

Адрес зависит только от StateInit, использованного в момент первого развёртывания контракта. Даже небольшое изменение в полях code, data или library приводило бы к совершенно другому account_id в этом инициализированном состоянии — и, следовательно, к другому адресу.

При этом во время обработки сообщений валидаторы проверяют адрес отправителя — и если он оказывается неверным, они автоматически заменяют его на правильный.

Структура блокчейна

Блокчейн

Блокчейн — это распределённый реестр, состоящий из блоков, в каждом из которых содержится набор данных. Эти блоки криптографически связаны друг с другом через хеши, образуя неизменяемую цепь. Вся эта цепь реплицируется и последовательно поддерживается всеми участниками сети.

AccountChain

AccountChain — это цепочка транзакций, исполненных с одним аккаунтом в блокчейне TON. Она образует линейную последовательность: Tx1 → Tx2 → Tx3 → …, где каждая транзакция ссылается на предыдущую.

Для эффективной обработки и консенсуса транзакции группируют в блоки, например, так: [Tx1 → Tx2] → [Tx3 → Tx4 → Tx5] → [] → [Tx6]. Эти блоки также включают очереди входящих и исходящих сообщений, записывая все события и изменения состояния для аккаунта в течение периода этого блока.

Другими словами, AccountChain — это микро-блокчейн, ограниченный одним аккаунтом. Как и обычный блокчейн, это линейная последовательность транзакций, позволяющая только дописывать данные — но посвящённая только одному аккаунту. Она хранит и упорядочивает всю историю операций и взаимодействий этого аккаунта, обеспечивая прозрачность и отслеживаемость.

На сетевом уровне многие такие цепочки группируются в ShardChain или просто «шард», в который входит набор разных аккаунтов. Эта абстракция поддерживает логическую группировку AccountChains в физической инфраструктуре ShardChain ↔ Валидатор.

Диаграмма ниже представляет графическое представление цепочки AccountChain и её структуры.

ShardChain

Шардчейн (ShardChain), шард — это блокчейн, который группирует несколько AccountChain.

В то время как AccountChain представляет историю транзакций одного аккаунта, шардчейн обрабатывает и хранит данные для группы аккаунтов, у которых совпадает префикс двоичных адресов (например, все адреса, начинающиеся с 0b00101). Шардчейны также облегчают маршрутизацию сообщений между аккаунтами, обеспечивая как доставку, так и порядок: если одно сообщение отправлено раньше другого, оно прибудет первым.

Каждый валидатор отвечает за определённый шардчейн или группу из них, что позволяет сети обрабатывать транзакции одновременно в разных шардах.

Воркчейн

Воркчейн (WorkChain) — это более высокий уровень блокчейна, который группирует различные шардчейны в единую рабочую группу.

В то время как каждый шардчейн управляет набором аккаунтов с общим префиксом двоичного адреса, воркчейн определяет общие правила (вроде расценок газа и конфигурации шардинга), которым должен следовать каждый шард этого воркчейна. Другими словами, он служит областью определённых правил, управляющей своими шардами по одному и тому же протоколу.

TON поддерживает до 2³² воркчейнов, каждый из которых может быть разделён на шардчейны количеством до 2⁶⁰.

В настоящее время в TON работают два воркчейна: бейсчейн (BaseChain) и мастерчейн (MasterChain).

Мастерчейн и бейсчейн

Бейсчейн (BaseChain) — это основная цепочка для исполнения повседневных транзакций и смарт-контрактов. Она оптимизирована для низких комиссий, что делает её подходящей для обычных пользователей и разработчиков.

Мастерчейн (MasterChain) — это основной координирующий блокчейн, состоящий из одного шардчейна. Он содержит:

• параметры протокола
• текущий набор валидаторов и их доли
• цепочки аккаунтов валидаторов
• метаданные обо всех активных воркчейнах и шардчейнах
• хеши последних блоков из всех других цепочек

Затраты на газ в мастерчейне намеренно высоки ради стабильности, приоритизации критических операций и предотвращения спама.

Благодаря иерархической структуре воркчейнов и шардчейнов, TON образует «блокчейн из блокчейнов» — масштабируемую архитектуру, в которой каждая цепочка работает независимо, и все блоки ссылаются на своих предшественников через криптографические хеши.

Тестнет и мейннет

Мейннет (основная сеть)

Мейннет (mainnet) — это активная продакшн-сеть, в которой:

• все транзакции реальны
• используются реальные токены (например, настоящий Toncoin)

Все пользователи и все запущенные в продакшне проекты используют мейннет.

Тестнет (тестовая сеть)

Тестнет (testnet) — это независимая блокчейн-сеть, которая копирует функциональность основной сети, но использует монеты без ценности. В тестнете:

• используются тестовые монеты, не имеющие реальной ценности
• можно безопасно тестировать контракты, транзакции, DApps, проверять ошибки
• блокчейн может быть сброшен или изменён в любое время

Тестнет необходим для безопасной разработки и отладки перед запуском в основную сеть.

Следующий шаг

Вы изучили основы транзакций — теперь давайте посмотрим, что заставляет их происходить.

Узнайте, как сообщения приводят к транзакциям

Was this article useful?