BoC (bag of cells)

BoC (Bag of Cells) — стандартный бинарный формат сериализации произвольного дерева cell в TON. Когда какие-то данные нужно сохранить на диск, передать по сети, отдать API клиенту — они сначала упаковываются в BoC.

Зачем нужен отдельный формат

Cell в TON — это дерево со ссылками. Если просто записывать его как набор байтов в линейном порядке, возникнет несколько проблем:

• Нужно как-то кодировать ссылки на другие cell.
• Если одна cell ссылается на несколько одинаковых дочерних — выгодно дедуплицировать.
• Нужна целостность: получатель должен убедиться, что данные не повреждены.

BoC решает эти задачи компактно и однозначно.

Структура BoC

BoC состоит из нескольких секций:

• Magic number — 4 байта, идентифицирующие формат (b5ee9c72 или вариации).
• Header — флаги (включена ли индексация, есть ли CRC32), число cell в графе, число корневых cell.
• Cell descriptor table — описание каждой cell: тип, длина данных, число ссылок.
• Cell data — собственно содержимое cell-ов.
• References — индексы ссылок (relative offsets в общем массиве).
• CRC32 — опциональная контрольная сумма.

При сериализации все cell упорядочиваются топологически (родители перед потомками — или наоборот, в зависимости от флага), идентичные cell дедуплицируются — каждая встречается в выводе один раз, даже если на неё ссылаются десятки родителей.

Где встречается

• Сообщения в сети. Когда кошелёк подписывает транзакцию — он отдаёт BoC в кошелёк-провайдер (liteserver), тот публикует её в блокчейн.
• TON Storage. Файлы хранятся как BoC в распределённой сети узлов.
• Бэкапы и снэпшоты. Состояние любого контракта можно дампнуть как BoC и восстановить позже.
• API сканеров. TonScan, TonViewer выдают raw transaction data в виде BoC, чтобы клиент мог сам разобрать и проверить.

Размеры

Типичные BoC-объекты в TON:

• Подписанная транзакция перевода TON — ~200-400 байт.
• Транзакция перевода jetton — ~400-800 байт.
• Деплой среднего смарт-контракта — несколько килобайт.
• Целый блок workchain-а — обычно 50-500 KB.

Компактность BoC напрямую влияет на цену хранения в блокчейне (storage fee) и эффективность сети — это одна из причин, почему TON способен на высокий TPS даже при ограниченной полосе пропускания валидаторов.

Кодировки

BoC обычно представляют в трёх формах:

• Binary — сырые байты, как в блокчейне.
• Hex — для копирования в логи и API.
• Base64 — самый частый формат в API и пользовательских интерфейсах. Например, te6cckEBA... — это base64 какой-то BoC.

Все TON SDK (@ton/ton, tonweb, pytoniq, tonsdk) умеют парсить BoC, превращать его в дерево cell, и обратно. Для пользователя BoC — невидимая инфраструктура, но любой разработчик контрактов и интеграций сталкивается с ним постоянно.