Cells и Bag of Cells

Cells (ячейки) — это атомарная единица данных в TON, подобно тому, как байты являются базовой единицей в обычном программировании. Всё в TON — код контрактов, состояние, сообщения — хранится в виде дерева ячеек. Понимание структуры cells и формата Bag of Cells (BoC) необходимо для эффективной сериализации данных, оптимизации хранения и, как следствие, снижения комиссий за ваши контракты.

В TON все данные хранятся в виде дерева ячеек (tree of cells). Это фундаментальная структура данных, которая определяет, как работает хранение, передача и верификация информации в блокчейне.

Что такое Cell

Cell (ячейка) — атомарная единица данных в TON. Каждая ячейка содержит:

• До 1023 бит данных (не байтов!)
• До 4 ссылок (references) на другие ячейки
• Тип ячейки — один из 5 типов

Ограничения ячейки

Дерево ячеек (Tree of Cells)

Данные, которые не помещаются в одну ячейку, распределяются по дереву через ссылки. Например, состояние смарт-контракта:

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

Каждый смарт-контракт в TON хранится как дерево ячеек:

• Корневая ячейка — содержит метаданные и ссылки на код и данные
• Code cell — скомпилированный TVM-байткод контракта
• Data cell — изменяемое состояние (баланс, переменные)
• Library cell (опционально) — ссылка на общую библиотеку в masterchain

Типы ячеек

TON определяет 5 типов ячеек:

Bag of Cells (BoC)

Bag of Cells (BoC) — формат сериализации деревьев ячеек для передачи по сети и хранения на диске.

Как работает BoC

1. Дерево ячеек линеаризуется — все ячейки складываются в последовательность
2. Ссылки заменяются индексами в этой последовательности
3. Добавляется заголовок с метаданными (количество ячеек, корневые ячейки)
4. Результат сжимается и может быть передан как один блоб данных

Применение BoC

• Транзакции передаются как BoC
• Состояние контрактов хранится как BoC
• Блоки шардчейнов — это BoC
• Код контракта компилируется в BoC

Пример BoC заголовка:
b5ee9c72  -- magic number
01        -- has_crc32
01        -- ref_byte_size
01        -- offset_byte_size
03        -- cell_count = 3
01        -- root_count = 1
00        -- absent_count = 0
...       -- cell data

TON vs Ethereum: Хранение данных

Хеширование ячеек

Каждая ячейка имеет уникальный хеш (SHA-256), вычисляемый из:

1. Типа ячейки
2. Данных ячейки (биты)
3. Хешей всех дочерних ячеек (ссылок)

Это свойство Merkle-дерева: изменение любой ячейки приводит к изменению хешей всех предков до корня. Корневой хеш однозначно определяет всё дерево.

Верификация Merkle-доказательств

Типы ячеек Merkle Proof и Pruned Branch (описанные выше в таблице типов) работают вместе, позволяя проверять данные без скачивания всего дерева состояния. Это основа работы лёгких клиентов в TON.

Структура Merkle Proof

Merkle Proof — это специальная ячейка типа 3 (Exotic, hash_n_level = 0), которая содержит подмножество дерева, достаточное для доказательства конкретного факта:

• Из полного дерева извлекается путь от корневой ячейки до целевой (например, до данных аккаунта)
• Все ветки, не входящие в путь, заменяются ячейками Pruned Branch
• Результат — компактное дерево, сохраняющее хеш-цепочку от корня до цели

Pruned Branch: замена поддерева хешем

Pruned Branch — ячейка типа 1, которая хранит:

• Хеш замещённого поддерева (SHA-256, 256 бит)
• Глубину замещённого поддерева

Pruned Branch занимает минимум места, но содержит всю информацию для проверки целостности. При верификации её хеш сравнивается с ожидаемым — если совпадает, значит замещённое поддерево корректно.

Алгоритм верификации

Верификация Merkle-доказательства выполняется за три шага:

1. Получение proof — лёгкий клиент запрашивает Merkle proof у полной ноды
2. Пересчёт хешей — от целевой (листовой) ячейки вверх до корня: хеш каждой ячейки вычисляется из её данных + хешей дочерних (включая Pruned Branch хеши)
3. Сравнение корня — полученный корневой хеш сравнивается с известным хешем блока masterchain (корень доверия)

Если хеши совпадают — данные подлинные. Если нет — proof невалиден.

Практический пример: проверка баланса

Лёгкий клиент хочет проверить баланс аккаунта:

1. Знает хеш последнего блока masterchain (из сети)
2. Запрашивает у полной ноды proof пути: masterchain block → shard block hash → account state
3. Получает дерево из ~10-15 ячеек (вместо миллионов) — остальные заменены Pruned Branch
4. Пересчитывает хеши от аккаунта до корня
5. Совпадение = баланс верный, без доверия ноде

Частые ошибки

1. Забывают о лимите в 1023 бита данных и 4 ссылки на ячейку: попытка записать больше приведёт к ошибке во время выполнения.
2. Не оптимизируют глубину дерева ячеек, хотя каждый уровень глубины увеличивает стоимость хранения и газ при чтении.
3. Путают биты и байты при работе с cells: ячейка хранит данные в битах, а не в байтах, что требует побитовых операций.
4. Игнорируют формат BoC при взаимодействии с API: многие TON API возвращают данные именно в формате Base64-encoded BoC, который нужно уметь парсить.