Как работает шардирование в TON — гайд 2026

Когда Ethereum обрабатывает 15-30 транзакций в секунду, а TON в пике уверенно держит несколько тысяч TPS — за этим стоит не «более быстрый виртуальный машинный движок». За этим стоит принципиально другая архитектура хранения и обработки состояния. TON изначально проектировался как «бесконечно шардируемая» сеть: число шардов адаптивно меняется под нагрузку. В этой статье разберём, как именно это устроено, зачем нужен masterchain, что такое Catchain и какие компромиссы пользователь и разработчик платят за такую производительность.

Материал — для технически любопытного пользователя и junior-разработчика, который слышал про шарды, но никогда не разбирался, как они живут изнутри.

Иерархия цепей: masterchain → workchain → shardchain

В TON состояние сети организовано в три уровня:

• Masterchain — корневая цепь. Хранит критическую информацию: текущий список валидаторов, конфигурацию сети, хеши последних блоков всех workchains, балансы крупных смарт-контрактов TON Foundation. Masterchain один на всю сеть. Финальность транзакции в masterchain — около 5 секунд.
• Workchain — отдельная сеть со своими правилами (правилами VM, форматом адресов, потенциально даже логикой консенсуса). Сейчас активно используется один workchain — basechain (workchain_id = 0). Архитектурно зарезервировано место под 2^32 workchains, но на практике их пока два: masterchain (id = -1) и basechain (id = 0).
• Shardchain — динамические подцепи внутри workchain. Каждый shardchain отвечает за определённый «префикс» адресного пространства. Под нагрузкой шард может разделиться на два; под низкой нагрузкой два шарда могут слиться обратно.

Можно представить эту схему как дерево: masterchain в корне, ниже workchains, ещё ниже — постоянно перестраивающийся лес shardchains.

Зачем нужен masterchain отдельно

Если бы все балансы и контракты лежали в одной цепочке, мы бы получили Ethereum — один upper bound пропускной способности на всё. Если бы цепочек было много, но не было корневой, мы бы получили мульти-чейн вселенную типа Cosmos, где между сетями нужно ставить мосты. TON выбрал третий путь: одна сеть с одной точкой согласования.

Masterchain выполняет роль «синхронизатора»: каждый блок masterchain ссылается на свежие блоки всех workchains и через них — на все shardchains. Если транзакция включена в shardchain-блок, который ссылается из masterchain-блока, она считается финальной. Это даёт глобальную упорядоченность событий, даже если фактическая обработка происходит параллельно в разных шардах.

Платят за это пропускной способностью самого masterchain: он остаётся узким местом сети. Поэтому в masterchain намеренно не пускают обычные смарт-контракты и пользовательские транзакции — там живут только системные операции, validator-elections, конфигурация.

Динамический split и merge

Главная особенность TON-шардирования — адаптивность. В Ethereum 2.0 или Near число шардов фиксировано. В TON оно меняется в реальном времени:

1. Каждый шард мониторит свою нагрузку (объём газа на блок, длину очереди исходящих сообщений).
2. Если нагрузка стабильно превышает порог в течение нескольких блоков, валидаторы шарда инициируют split: шард делится на два, каждый забирает половину адресного пространства.
3. Если нагрузка падает ниже нижнего порога и в соседнем шарде тоже спокойно, валидаторы инициируют merge: два шарда сливаются в один.

На практике это означает, что TON может масштабироваться горизонтально без хардфорка. В пиковые моменты сеть видела десятки активных шардов; в спокойные часы их может быть всего один-два. Подробные графики «количество шардов во времени» доступны на tonviewer и dton.

Как адреса распределяются по шардам

Адрес контракта в TON — это пара (workchain_id, account_id), где account_id — 256-битное число. Шарды делят адресное пространство по двоичному префиксу account_id. Если в workchain один шард, он отвечает за все возможные account_id. После split один шард забирает префикс 0..., другой — 1.... Следующее разделение даст префиксы 00..., 01..., 10..., 11... и так далее.

Из этого вытекает важное свойство: контракт, единожды развёрнутый по адресу X, всегда живёт в шарде, чей префикс совпадает с началом X. При split-операциях контракт автоматически попадает в нужный «дочерний» шард. Это объясняет, почему адрес TON-контракта детерминирован: он зависит от initial state (init code + init data), а не от того, кто и когда задеплоил.

Catchain: консенсус внутри шарда

Каждый shardchain обслуживает своя подгруппа валидаторов. Их выбирают из общего пула валидаторов на каждый «раунд» (около 18 часов в текущей конфигурации). Подгруппа достигает консенсуса по своим блокам с помощью протокола Catchain — это BFT-консенсус с эстафетной передачей лидерства, оптимизированный для быстрого финалити в группе из 100-200 узлов.

Catchain работает поверх обычной TON-сети узлов. Внутри одного раунда валидаторы шарда обмениваются предложениями блоков, сигнатурами и vote-сообщениями. Когда более 2/3 подписало блок, он считается finalised. Затем результаты «всплывают» в masterchain через ссылки.

Различие с обычным PoS, как в Ethereum: в Ethereum все валидаторы голосуют за один и тот же блок основной цепи. В TON разные подгруппы валидаторов одновременно голосуют за блоки разных шардов. Это и есть параллелизм консенсуса — то, чего у монолитных чейнов нет.

Роли валидаторов и номинаторов

Стать валидатором в TON технически может любой, у кого хватает стейка (текущий минимум — несколько сотен тысяч TON) и подходящего железа. Но в реальности большая часть стейка приходит от номинаторов — обычных держателей TON, которые делегируют свои монеты валидатору через nominator-pool или single-nominator-контракт.

Номинатор не управляет узлом, не отвечает за uptime и не рискует своими ключами. Он только размещает стейк и получает долю награды, минус процент валидатора. Это безопасный путь для пассивного дохода 4-6% годовых в TON (исторически).

Стейкинг через ликвидные провайдеры (Tonstakers, bemo, hipo) делает то же самое, но дополнительно выдаёт держателю «liquid staking token» (stTON, tsTON и т.п.), который можно использовать в DeFi.

Что чувствует пользователь

Шардирование — фоновая магия. Пользователь его напрямую не видит, но ощущает по косвенным признакам:

• Скорость финалити. В обычной транзакции (один шард) — около 5 секунд. Для cross-shard транзакций — 10-20 секунд (нужно дождаться нескольких masterchain-блоков для согласованности).
• Стабильность комиссий. Под пиковой нагрузкой Ethereum газ скачет в 10-100 раз. TON в той же ситуации просто разделяет шард и комиссии остаются почти неизменными.
• Параллельные потоки. Если вы держите 5 jetton, их балансы могут лежать в 5 разных шардах. Обновление одного не блокирует остальные.

Платы за архитектуру: компромиссы для разработчика

Параллелизм даётся не бесплатно. Если вы пишете dApp под TON, придётся принять ряд особенностей:

1. Сообщения между контрактами — асинхронные. Нет аналога Solidity-вызова otherContract.foo() с немедленным возвратом значения. Контракт отправляет сообщение и заканчивает свою транзакцию; ответ придёт в отдельном блоке.
2. Cross-shard задержки. Сообщение между контрактами в разных шардах требует включения в исходящую очередь, передачи через hypercube routing и обработки в принимающем шарде. Это секунды, а не миллисекунды.
3. Atomic-операции — миф. Нельзя в одной транзакции «отнять у A, отдать B, проверить C, откатиться при ошибке». Нужно проектировать многошаговые сценарии с явной компенсацией.
4. Композиция сложнее. Flash loans, как в Ethereum, технически невозможны в исходном виде. Аналоги существуют (например, через DEX-агрегаторы), но требуют другой логики.
5. Тулинг моложе. Hardhat-уровня инфраструктуры в TON пока нет, хотя Blueprint, ACTON Foundry и tact-aware-плагины уверенно догоняют.

Сравнительная таблица: TON vs Ethereum

Чего ждать дальше

В roadmap TON Foundation на 2026-2027 — снижение порога валидатора, развитие cross-shard DeFi-композиции через специализированные «hub-контракты» и оптимизация hypercube routing. Технический долг TON — отсутствие EVM-совместимости — компенсируется появлением мостов типа TAC и Mercurio, но это совсем другая история.

Если хотите глубже разобраться в смежных темах: про jetton-стандарт TEP-74 — почему он именно такой и как взаимодействует с шардами — у нас отдельный материал. Про комиссии и почему они так стабильны — тоже. А полную картину «что такое TON и зачем» — в обзорной статье для новичков.