Cells и Bag of Cells
Cells (ячейки) — это атомарная единица данных в TON, подобно тому, как байты являются базовой единицей в обычном программировании. Всё в TON — код контрактов, состояние, сообщения — хранится в виде дерева ячеек. Понимание структуры cells и формата Bag of Cells (BoC) необходимо для эффективной сериализации данных, оптимизации хранения и, как следствие, снижения комиссий за ваши контракты.
В TON все данные хранятся в виде дерева ячеек (tree of cells). Это фундаментальная структура данных, которая определяет, как работает хранение, передача и верификация информации в блокчейне.
Что такое Cell
Cell (ячейка) — атомарная единица данных в TON. Каждая ячейка содержит:
- До 1023 бит данных (не байтов!)
- До 4 ссылок (references) на другие ячейки
- Тип ячейки — один из 5 типов
Ограничения ячейки
| Параметр | Лимит |
|---|---|
| Максимум данных | 1023 бита |
| Максимум ссылок | 4 |
| Типы ячеек | 5 |
| Максимальная глубина дерева | 1024 |
Фиксированный размер ячейки (1023 бита) — не ограничение, а преимущество. Он позволяет эффективно хешировать ячейки и строить доказательства (proofs) без обхода данных произвольного размера.
Дерево ячеек (Tree of Cells)
Данные, которые не помещаются в одну ячейку, распределяются по дереву через ссылки. Например, состояние смарт-контракта:
Структура контракта
Каждый смарт-контракт в TON хранится как дерево ячеек:
- Корневая ячейка — содержит метаданные и ссылки на код и данные
- Code cell — скомпилированный TVM-байткод контракта
- Data cell — изменяемое состояние (баланс, переменные)
- Library cell (опционально) — ссылка на общую библиотеку в masterchain
Типы ячеек
TON определяет 5 типов ячеек:
| Тип | Описание | Применение |
|---|---|---|
| Ordinary | Обычная ячейка | 99% всех ячеек |
| Pruned Branch | Заменяет поддерево хешем | Merkle-доказательства |
| Library | Ссылка на общую библиотеку | Переиспользование кода |
| Merkle Proof | Доказательство включения | Лёгкие клиенты |
| Merkle Update | Доказательство изменения | Обновления состояния |
Pruned Branch ячейки — ключ к масштабируемости. Они позволяют передавать доказательство о части дерева, не скачивая всё дерево. Лёгкий клиент может проверить баланс аккаунта, получив только путь от корня до нужной ячейки.
Bag of Cells (BoC)
Bag of Cells (BoC) — формат сериализации деревьев ячеек для передачи по сети и хранения на диске.
Как работает BoC
- Дерево ячеек линеаризуется — все ячейки складываются в последовательность
- Ссылки заменяются индексами в этой последовательности
- Добавляется заголовок с метаданными (количество ячеек, корневые ячейки)
- Результат сжимается и может быть передан как один блоб данных
Применение 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: Хранение данных
TON vs Ethereum: Модель данных
Ethereum хранит состояние в Modified Merkle Patricia Trie (MPT) — дереве с узлами произвольного размера. TON использует tree of cells с фиксированным лимитом 1023 бит на ячейку и 4 ссылки.
Преимущество TON: фиксированный размер ячеек делает хеширование предсказуемым, а Merkle-доказательства — компактными.
Ethereum State Trie (MPT)Хеширование ячеек
Каждая ячейка имеет уникальный хеш (SHA-256), вычисляемый из:
- Типа ячейки
- Данных ячейки (биты)
- Хешей всех дочерних ячеек (ссылок)
Это свойство 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-доказательства выполняется за три шага:
- Получение proof — лёгкий клиент запрашивает Merkle proof у полной ноды
- Пересчёт хешей — от целевой (листовой) ячейки вверх до корня: хеш каждой ячейки вычисляется из её данных + хешей дочерних (включая Pruned Branch хеши)
- Сравнение корня — полученный корневой хеш сравнивается с известным хешем блока masterchain (корень доверия)
Если хеши совпадают — данные подлинные. Если нет — proof невалиден.
Merkle-доказательства позволяют trustless-верификацию: лёгкий клиент не доверяет ноде, предоставившей proof. Он самостоятельно пересчитывает хеши и сверяет с корнем masterchain. Это делает возможным проверку баланса аккаунта, состояния контракта или факта транзакции без скачивания полного блока.
Практический пример: проверка баланса
Лёгкий клиент хочет проверить баланс аккаунта:
- Знает хеш последнего блока masterchain (из сети)
- Запрашивает у полной ноды proof пути:
masterchain block → shard block hash → account state - Получает дерево из ~10-15 ячеек (вместо миллионов) — остальные заменены Pruned Branch
- Пересчитывает хеши от аккаунта до корня
- Совпадение = баланс верный, без доверия ноде
Частые ошибки
- Забывают о лимите в 1023 бита данных и 4 ссылки на ячейку: попытка записать больше приведёт к ошибке во время выполнения.
- Не оптимизируют глубину дерева ячеек, хотя каждый уровень глубины увеличивает стоимость хранения и газ при чтении.
- Путают биты и байты при работе с cells: ячейка хранит данные в битах, а не в байтах, что требует побитовых операций.
- Игнорируют формат BoC при взаимодействии с API: многие TON API возвращают данные именно в формате Base64-encoded BoC, который нужно уметь парсить.
Проверка знанийПочему ячейка TON ограничена 1023 битами данных и 4 ссылками?
Check Your Understanding
Finished the lesson?
Mark it as complete to track your progress
Войдите чтобы оценить урок