Шардинг TON изнутри: как достигается высокий TPS (2026)

TON изначально проектировался как сеть, в которой шардинг — не дополнение к L1, а сама основа архитектуры. В маркетинговых материалах TON Foundation часто звучат «миллионы TPS», в технических постах — рекорд 104 715 TPS из октябрьского теста 2024 года, а в обозревателях вы увидите 40 tx/s. Все три числа правдивы по-своему, но описывают разные миры. Эта статья — попытка пройти по архитектуре сверху вниз, показать, откуда берётся высокий TPS и где у этой схемы реальные пределы.

Архитектура TON: masterchain, workchains, shardchains

Сеть устроена иерархически. На верхнем уровне находится masterchain (идентификатор workchain -1) — служебный блокчейн, который хранит конфигурацию сети, список валидаторов, активные шарды и финализирует состояние всей системы. Masterchain один.

Под ним по спецификации может существовать до 2^32 параллельных workchains — независимых блокчейнов со своими правилами (виртуальной машиной, форматом адресов, правилами комиссий). На практике в mainnet 2026 года активен ровно один workchain — basechain (workchain 0). Именно там живут все привычные пользователю транзакции: переводы TON, jetton’ы, NFT, контракты DEX.

Каждый workchain в свою очередь динамически делится на shardchains. По TON Whitepaper §2 теоретический потолок — 2^60 шардов на workchain. В продакшене масштаб скромнее: длина префикса шарда ограничена 4 битами, то есть в моменте basechain может расщепиться максимум до 16 шардчейнов. Это и есть та «дельта» между маркетинговой и реальной картинкой, о которой мы поговорим ниже.

Принципиальное свойство схемы: каждый контракт живёт ровно в одном шарде, и принадлежность определяется префиксом его account-ID. Когда шард делится надвое, контракты с префиксом 0... остаются в одном дочернем шарде, с префиксом 1... — в другом. Сам адрес не меняется.

Динамический шардинг: split, merge и Infinite Sharding Paradigm

В большинстве шардированных сетей (Near, исторически Ethereum 2.0) количество шардов задаётся протоколом и меняется обновлением. В TON решение принимается на лету. Это и есть Infinite Sharding Paradigm из whitepaper: концептуально каждый аккаунт имеет собственный «virtual blockchain», а реальные шардчейны — это группировки таких аккаунтных цепочек по префиксу.

Логика split/merge:

• Когда загрузка шарда превышает порог, заданный в конфигурации валидаторов, шард делится на два — старший бит префикса становится дополнительным разрядом. Контракты остаются на своих account-ID, но физически обслуживаются разными подмножествами валидаторов.
• Когда нагрузка падает ниже нижнего порога, два соседних шарда сливаются обратно.
• Эти параметры — часть конфигурации сети, они меняются голосованием валидаторов и публично не закреплены в документации одним числом.

Эффект для разработчика: вы пишете контракт, как будто шардинга нет, и не задумываетесь, в каком шарде он окажется. Все детали маршрутизации скрыты в протоколе и реализованы через hypercube routing — схему доставки сообщений между шардами по промежуточным блокам. Подробности — в документации TON и оригинальной Catchain paper.

Цена этой прозрачности — кросс-шард задержка. Сообщение, отправленное контрактом из одного шарда в контракт из другого, не доставляется атомарно в том же блоке: оно сначала фиксируется в исходящем шарде, затем «путешествует» через masterchain, потом принимается в шарде-получателе. До Catchain 2.0 это занимало порядка 12 секунд при работе нескольких шардов; после апреля 2026 года цифра пропорционально уменьшилась, но всё ещё измеряется секундами — обычно 1.2-2 с в зависимости от загрузки.

Реальный TPS, тестовые 104 715 и где между ними правда

Вот что важно держать в голове, когда читаешь любую TPS-метрику TON:

Тест 104 715 TPS, проведённый в октябре 2024 и сертифицированный CertiK, — это верхняя инженерная демонстрация, а не повседневная реальность сети. Что было сделано: команда подняла 256 высокопроизводительных нод в Alibaba Cloud, активировала 512 шардчейнов одновременно, и в течение 10 минут гоняла нагрузку из заранее задеплоенных контрактов. Это не были простые переводы — публикация подчёркивает, что контракты выполняли «complex execution». Воспроизвести можно по репозиторию github.com/ton-blockchain/performance-test.

Почему mainnet выдаёт 40 tx/s, если железо способно на 104K:

1. Количество валидаторов и шардов. В mainnet ~408 валидаторов (chainspect) и обычно 4-8 активных шардов в моменте — не 512.
2. Реальная нагрузка. Среднее число пользователей сети генерирует именно 40 tx/s. Это не предел, это спрос.
3. Геораспределение. Тест шёл в одном датацентре, mainnet распределён по миру, что добавляет задержку консенсуса.
4. Типы транзакций. Реальный mix включает jetton-переводы (более тяжёлые, чем чистые TON-переводы) и взаимодействия с DEX (multi-message сценарии).

Корректная интерпретация: 104 715 TPS — это аргумент в пользу того, что архитектура не упрётся в потолок при росте спроса. Это не утверждение, что прямо сейчас сеть готова принять весь объём VISA.

Catchain 2.0: что изменилось 9 апреля 2026

Catchain 2.0 — крупнейший консенсус-апгрейд TON за всю историю mainnet. Запущен 9 апреля 2026 года. Что произошло:

• Время блока сократилось с ~5 с до ~0.4 с.
• Финализация — с ~10 с до ~0.8 с.
• Пропускная способность выросла примерно в 10 раз на тех же валидаторах.
• Годовая эмиссия выросла с 0.6% до 3.6% — плата за более частые блоки.

Под капотом Catchain — pBFT-производный консенсус с требованием подписей более 2/3 валидаторов. Catchain 2.0 переработал пайплайн: подготовка следующего блока теперь идёт параллельно с верификацией предыдущего, что и даёт основной выигрыш в latency. Технические детали разбираются в блоге TON и в whitepaper.

С точки зрения пользователя главное наблюдаемое изменение — переводы и DeFi-взаимодействия стали ощутимо быстрее. Подтверждение jetton-перевода теперь воспринимается как «мгновенное», а не «через две Mississippi». Для DEX это особенно важно: spread между блоками сократился, арбитраж переместился ближе к CEX-темпу.

Где у этой схемы реальные пределы

Если читать только пресс-релизы, складывается ощущение «бесконечно масштабируемой сети». На практике у архитектуры TON есть конкретные узкие места.

1. Single-account bottleneck. Все транзакции одного контракта обязательно попадают в один шард — иначе схема маршрутизации по префиксу сломается. Это значит, что популярный DEX-пул, юзернейм-аукцион или горячий контракт мини-аппа упирается в TPS одного шарда. Реальный потолок — несколько сотен tx/s на контракт. Архитектурный ответ — разбивать состояние по нескольким контрактам (sharded contracts на уровне приложения), что усложняет разработку.

2. Кросс-шард задержка. Hypercube routing — изящное теоретическое решение, но цена за него — multi-block latency между шардами. До Catchain 2.0 это было ~12 с, теперь ~1.2-2 с, но всё ещё кратно одному блоку. Для UX, рассчитанного на «секунду до подтверждения», это заметно при сложных DeFi-сценариях, где сообщение проходит через 3-4 контракта в разных шардах.

3. Префиксный потолок. Декларативные 2^60 шардов на workchain существуют только в спецификации. Продакшен-параметр ограничивает префикс 4 битами, то есть 16 шардами на basechain. До цифр уровня «миллион TPS» дистанция — несколько обновлений протокола, не флаг в конфиге.

4. Тест против продакшена. 104 715 TPS получили на 256 высокопроизводительных серверах в одном датацентре с заранее подготовленными контрактами. Mainnet — 408 географически распределённых валидаторов с гетерогенным железом и реальной транзакционной смесью. Разница на порядок — это не баг, это разные режимы работы.

5. Инфляция как трейдофф. За 10-кратный рост TPS заплатили 6-кратным ростом эмиссии. Это легитимный выбор, но это выбор, а не «бесплатный» апгрейд.

Сравнение с другими L1 по тем же метрикам помогает откалибровать ожидания:

TON выигрывает у Ethereum L1 по latency и пропускной способности на порядки, у Solana — по финализации (0.8 с против 12.8 с при сопоставимом времени блока), у Aptos — по реальной децентрализации (408 валидаторов против 16). Проигрывает Solana и Aptos в теоретическом и реально достигнутом TPS на одну цепочку, и эта разница в первую очередь архитектурная: монолитные дизайны Solana/Aptos оптимизированы под общий ордеринг, шардированный TON — под параллелизм.

Что в roadmap до 2027

Дуров в начале 2026 года анонсировал инициативу MTONGA (Make TON Great Again) — семишаговый план оптимизации сети. На середину мая 2026 года статус такой:

1. Catchain 2.0 — выполнено 9 апреля 2026.
2. Снижение комиссий примерно в 6 раз — анонсировано, целевая цена jetton-перевода ~$0.0005.
3. Разделение валидаторов и коллаторов. Валидаторы будут наблюдать только masterchain, отдельная роль collator возьмёт на себя предварительную сборку блоков шардчейнов. Идея — снизить требования к hardware валидаторов и параллельно увеличить throughput.
4. Оптимистичная коллация. Коллаторы будут передавать блоки на распространение ещё до валидации, что даёт ещё одну секунду в latency-бюджете.
5. AgenticKit, Rust Node v1, Tolk dev tools. Инструменты для разработчиков и альтернативный клиент ноды на Rust — снижение зависимости от единственной C++ реализации.
6. Новый consensus layer. Замена/эволюция Catchain после v2.0, детали публично не раскрыты.
7. Layer-2 Payment Network + BTC Teleport bridge. Слой быстрых платежей и нативный мост к Bitcoin.

Сроки растянуты на 2026-2027 годы. Самое прагматичное ожидание: до конца 2026 — снижение комиссий и старт работ по collator/validator split; на 2027 — Rust-нода и L2-payment-сеть в production.

Что из этого следует разработчику и пользователю

Если вы строите на TON dApp в 2026 году, разумные допущения:

• Финализация ~0.8 с — закладывайте на UX «почти мгновенно», но не «синхронно».
• Кросс-шард сообщения — не атомарны. Сложные многоконтрактные операции спрятайте за state machine, которая корректно обрабатывает промежуточные состояния.
• Один контракт = один шард. Если ожидаете high-throughput сценарий (массовый airdrop, hot NFT-минт), проектируйте sharded архитектуру на уровне приложения.
• 104 715 TPS — не маркетинговая дубина, а потолок при специальной конфигурации. Закладывайте 100-300 tx/s на контракт как практический ориентир.

Если вы держатель и оцениваете долгосрочное здоровье сети, главные индикаторы — количество валидаторов (сохранится ли распределение после введения collator/validator split), реальная инфляция (не вырастет ли выше анонсированных 3.6%) и развитие L2-payment-слоя, который должен взять на себя массовые микроплатежи и снять нагрузку с L1.

Источники

• TON Whitepaper — оригинальная спецификация архитектуры.
• docs.ton.org/develop/blockchain/shards — техническая документация по шардингу.
• Catchain paper — описание консенсуса.
• chainspect.app/chain/ton — живые метрики TPS и валидаторов.
• github.com/ton-blockchain/performance-test — репозиторий теста 104 715 TPS.
• blog.ton.org — анонсы Catchain 2.0 и MTONGA.