TON: бесконечный шардинг и модель акторов

В июле 2024 года Telegram выкатил обновление, и миллионы пользователей обнаружили кнопку Wallet прямо в мессенджере. Без MetaMask, без seed-фраз, без расширений для браузера - просто нажми и отправь криптовалюту. За этой кнопкой стоит TON, блокчейн, спроектированный Николаем Дуровым с нуля так, чтобы каждый аккаунт теоретически мог быть собственным шардом, контракты общались только через асинхронные сообщения, а вся сеть масштабировалась до миллионов транзакций в секунду. Архитектура, которая выглядит как операционная система для блокчейнов, а не просто ещё один Ethereum-killer. Давайте разберём, как это устроено.

• **Telegram Mini Apps** превратили мессенджер с 900+ миллионами пользователей в платформу для Web3-приложений: Notcoin набрал 35 миллионов игроков за месяц, а Hamster Kombat достиг 300 миллионов пользователей - цифры, недостижимые для любого другого блокчейна
• **DeFi на TON** обрабатывает сотни миллионов долларов через DEX-ы (STON.fi, DeDust) с комиссиями менее 0.01, а Tether выпустил USDT на TON как одну из ключевых сетей наряду с Ethereum и Tron
• **Бесконечный шардинг** решает проблему, которую Ethereum отложил на годы: вместо фиксированных 64 шардов TON динамически разделяет и объединяет шарды в зависимости от нагрузки - архитектура, которую Ethereum Danksharding пытается реализовать частично

Предварительные знания

• The Consensus Problem: Why and How

Архитектура TON: Workchains и бесконечный шардинг

Большинство блокчейнов масштабируются одним из двух способов: **вертикально** (мощнее ноды, как Solana) или **горизонтально** через фиксированное число шардов (Ethereum 2.0 планировал 64 шарда). Николай Дуров, сооснователь Telegram и математик по образованию, спроектировал **The Open Network (TON)** с третьим подходом: **бесконечный динамический шардинг**, где количество шардов автоматически адаптируется к нагрузке - теоретически до 2^60 параллельных цепочек. TON - это не один блокчейн. Это **система блокчейнов** с трёхуровневой иерархией: Masterchain, Workchains и Shardchains. Каждый уровень решает свою задачу, и вместе они образуют архитектуру, способную масштабироваться до миллионов транзакций в секунду - по крайней мере, в теории.

**Masterchain** - это корень доверия всей системы. Он хранит конфигурацию сети, набор валидаторов с их stake, и - критически важно - **хеши последних блоков всех shardchains**. Благодаря этому любой участник сети может верифицировать состояние любого шарда, проследив цепочку хешей до Masterchain. Masterchain не обрабатывает пользовательские транзакции - он занят исключительно координацией. **Workchain** - это блокчейн с собственными правилами: формат адреса, виртуальная машина, формат транзакций. Сейчас активен только **Workchain 0** (basechain) - основная цепочка для аккаунтов и смарт-контрактов. Протокол поддерживает до 2^32 workchains, каждый со своими правилами. В будущем можно создать EVM-совместимый workchain, workchain для ZK-вычислений или любой другой специализированной логики.

**Infinite Sharding Paradigm** - это философия, доведённая до предела: в идеале каждый аккаунт мог бы быть собственным шардом. На практике шарды объединяют аккаунты с близкими адресами (общий битовый префикс). Когда нагрузка на шард растёт - он **автоматически разделяется** на два дочерних шарда. Когда нагрузка падает - шарды **сливаются обратно**. Этот процесс полностью автоматический и управляется валидаторами на уровне протокола. Но шардинг создаёт проблему: как аккаунт в шарде A может отправить сообщение аккаунту в шарде B? TON решает это через **Instant Hypercube Routing** - маршрутизацию сообщений через гиперкуб. Если шардов N, то сообщение достигает любого шарда за O(log N) хопов, передаваясь через промежуточные шарды, у которых адресный префикс постепенно «сближается» с целевым.

**Текущее состояние шардинга.** На март 2026 в TON mainnet активен только один Workchain 0 с динамическим шардингом. Большую часть времени сеть работает с 1-4 шардами, разделяясь при всплесках нагрузки (например, минт NFT-коллекций). Полный потенциал бесконечного шардинга ещё не был протестирован в продакшне на масштабе тысяч шардов. Тем не менее, архитектура спроектирована с запасом - и в этом ключевое отличие TON от блокчейнов, которые добавляют шардинг поверх существующей архитектуры.

TVM и модель акторов

В Ethereum все смарт-контракты живут в **едином глобальном состоянии**. Когда контракт A вызывает контракт B через `call`, выполнение **синхронное**: контроль переходит в B, B выполняется, возвращает результат в A - всё в рамках одной транзакции. Это удобно, но создаёт проблему: синхронные вызовы несовместимы с шардингом, потому что контракты A и B могут оказаться в разных шардах. **TVM (TON Virtual Machine)** решает эту проблему радикально: каждый смарт-контракт - это **независимый актор**, который общается с другими контрактами **только через асинхронные сообщения**. Никаких синхронных вызовов. Никакого глобального состояния. Каждый контракт - остров с собственным хранилищем, балансом и кодом.

Это фундаментальное отличие. В EVM вы привыкли к атомарности: вызвали `swap()`, он внутри дёрнул `transfer()` и `mint()` - и если что-то пошло не так, всё откатывается. В TVM **нет атомарности между контрактами**. Каждое внутреннее сообщение порождает отдельную транзакцию, которая может быть обработана в другом блоке, в другом шарде, через секунды или минуты после отправки. Это не баг - это осознанный trade-off ради шардинга. Если контракт A в шарде 1 и контракт B в шарде 2, синхронный вызов потребовал бы остановки обоих шардов и ожидания результата. Асинхронные сообщения позволяют каждому шарду работать независимо - ключевое свойство для масштабирования.

**Cells (ячейки)** - базовая структура данных TVM. Всё в TON сериализуется в ячейки: код контрактов, состояние, сообщения, блоки. Ячейка содержит до **1023 бит данных** и до **4 ссылок на другие ячейки**. Это формирует **дерево ячеек (tree of cells)** - направленный ациклический граф (DAG). Для передачи данных используется **Bag of Cells (BoC)** - сериализованное представление дерева. TVM - стековая машина, работающая с этими ячейками. В отличие от EVM, где данные хранятся в 256-битных слотах (mapping key → value), TVM оперирует деревьями ячеек - это более компактно и гибко, но требует другого мышления при разработке.

FunC и Tact: языки смарт-контрактов TON

Написать смарт-контракт для TVM - задача нетривиальная. Исторически TON предлагал **FunC** - низкоуровневый функциональный язык, разработанный Николаем Дуровым. FunC выглядит как C, но ведёт себя как Haskell: чистые функции, явная работа с ячейками, ручное управление газом. Для опытного системного программиста FunC - гибкий инструмент. Для разработчика из мира Solidity - культурный шок. Поэтому в 2023 году появился **Tact** - высокоуровневый язык, вдохновлённый TypeScript и Swift, который компилируется в FunC (а тот - в Fift assembler → TVM bytecode). Tact абстрагирует работу с ячейками, автоматизирует сериализацию и даёт привычный синтаксис message handler-ов.

Разница между FunC и Tact колоссальная. В FunC вы вручную парсите `in_msg_body` через `load_uint(32)`, вручную сериализуете состояние через `begin_cell().store_uint()`, вручную маршрутизируете по operation code. В Tact вы объявляете `message Increment` с полями, пишете `receive(msg: Increment)` - и компилятор генерирует всю сериализацию, десериализацию и маршрутизацию за вас. Tact также поддерживает **traits** - аналог миксинов/интерфейсов: `Ownable` (контроль владельца), `Deployable` (стандартный деплой), `Stoppable` (пауза контракта). Это приближает DX (developer experience) к уровню OpenZeppelin для Solidity.

**Blueprint - build system для TON.** Установка: `npm create ton@latest`. Blueprint предоставляет sandbox для локального тестирования контрактов без запуска ноды (аналог Hardhat Network). Тесты пишутся на TypeScript с Jest, используя `@ton/sandbox` для эмуляции блокчейна. Это позволяет тестировать сложные асинхронные сценарии: отправка сообщений между контрактами, проверка bounce-ов, симуляция таймаутов - всё локально, без testnet.

**Безопасность: специфичные уязвимости TON.** Из-за асинхронной модели появляются классы уязвимостей, не существующие в EVM: 1. **неправильная обработка bounce** - контракт изменил состояние, отправил сообщение, оно bounce-нулось, но состояние не откатилось 2. **атаки через непредвиденные сообщения** - любой может отправить любое сообщение любому контракту 3. **gas drainage** - злоумышленник отправляет сообщение с недостаточным количеством TON, контракт тратит свой баланс на обработку. Разработчик ОБЯЗАН валидировать отправителя, проверять msg_value и корректно обрабатывать все bounce-сценарии.

Jettons и NFT: стандарты токенов TON

В Ethereum токен ERC-20 - это **один контракт**, который хранит балансы всех держателей в своём storage (mapping `address → balance`). Перевод - это вызов `transfer()` на этом контракте, который меняет две записи в mapping. Просто и аккуратно. В TON такой подход невозможен. Модель акторов означает, что **каждый контракт имеет только своё локальное состояние**. Контракт токена не может хранить балансы миллиона пользователей - это противоречит шардингу (все обращения шли бы в один шард). Решение: **Jetton** - стандарт токенов TON (TEP-74), где **каждый держатель получает свой собственный контракт-кошелёк**.

Трансфер Jetton - это цепочка **асинхронных сообщений**, а не один вызов: 1. Алиса отправляет `transfer` сообщение **своему** Jetton Wallet 2. Jetton Wallet Алисы уменьшает свой баланс и отправляет `internal_transfer` кошельку Боба 3. Jetton Wallet Боба увеличивает свой баланс и (опционально) отправляет `transfer_notification` контракту Боба 4. Jetton Wallet Боба отправляет `excess` сообщение обратно Алисе, возвращая неиспользованный газ Эта цепочка из 3-4 сообщений заменяет один `transfer()` в ERC-20. Сложнее? Да. Но зато каждый кошелёк - отдельный контракт, который может жить в своём шарде. При миллионах держателей трансферы обрабатываются **параллельно** в разных шардах.

**NFT на TON** следует аналогичной модели. NFT Collection - это master-контракт, который хранит метаданные коллекции и деплоит **отдельный контракт для каждого NFT Item**. Каждый NFT - независимый актор со своим owner, content и индексом. При передаче NFT отправляется сообщение самому NFT Item-контракту, который меняет owner. **SBT (Soulbound Tokens)** на TON - это NFT без права передачи. Технически реализуется как NFT Item, который отклоняет `transfer`-сообщения. SBT используются для on-chain подтверждений: KYC-верификация, завершение курса, участие в DAO - токен привязан к адресу навсегда.

**Почему отдельный контракт на каждый кошелёк/NFT - это не расточительство?** В Ethereum деплой нового контракта стоит ~$5-50 в газе. В TON деплой контракта обходится в ~0.05 TON (~$0.15-0.25). Хранение состояния оплачивается через **storage fee** - небольшую плату за каждую ячейку в секунду. Если контракт «заброшен» и его баланс упал до нуля - он автоматически удаляется (freeze → delete). Это экономическая модель, оптимизированная под архитектуру «много маленьких контрактов».

Экосистема TON: от DeFi до Telegram Mini Apps

TON уникален среди блокчейнов одним фактором: **интеграция с Telegram**. Мессенджер с 900+ миллионами пользователей предоставляет TON то, чего не имеет ни один другой L1 - готовую аудиторию и дистрибуцию. Но экосистема TON - это не только Telegram. Это набор децентрализованных сервисов, спроектированных как единая платформа: DNS, Storage, Proxy, Sites и, конечно, DeFi-протоколы.

**TON DNS** - система человекочитаемых доменных имён на блокчейне. Домены `.ton` (например, `alice.ton`) привязываются к адресам кошельков, смарт-контрактам или сайтам через NFT-контракт. Каждый домен - это NFT, который можно продать или передать. В отличие от ENS (Ethereum Name Service), TON DNS интегрирован в протокол на уровне резолверов: кошельки и браузеры резолвят `.ton` адреса нативно. **TON Storage** - децентрализованное хранилище файлов, основанное на технологии, аналогичной BitTorrent. Файлы разбиваются на куски, распределяются по нодам, а torrent-подобные хеши хранятся на блокчейне. Это не IPFS - TON Storage использует собственный протокол RLDP (Reliable Large Datagram Protocol) и интегрирован с TON Sites. **TON Proxy** - анонимизирующий прокси-слой, позволяющий скрывать IP-адрес при взаимодействии с TON сетью. Технически это overlay-сеть поверх ADNL (Abstract Datagram Network Layer) - транспортного протокола TON.

**Telegram Mini Apps (TMA)** - главный growth driver TON. TMA - это обычные веб-приложения (HTML/CSS/JS), которые открываются внутри Telegram и получают доступ к данным пользователя (имя, ID, фото) и его TON-кошельку через **TON Connect**. Пользователю не нужно устанавливать MetaMask, копировать seed-фразы или разбираться в газе - кошелёк встроен в Telegram. **TON Connect** - протокол для подключения кошельков к dApps, аналог WalletConnect в Ethereum. Основной кошелёк - **Tonkeeper** (5+ миллионов установок). TON Connect использует ADNL для безопасной коммуникации между dApp и кошельком, позволяя подписывать транзакции без передачи приватных ключей.

**Валидаторы и стейкинг.** TON использует Proof of Stake с минимальным порогом в **300,000 TON** (~1M+) для запуска валидатора. Это один из самых высоких порогов входа среди L1-блокчейнов. Валидаторы участвуют в выборах каждые ~18 часов, и набор обновляется автоматически. Для пользователей с меньшим количеством TON доступны **Nominator Pools** - контракты для делегирования. Пул объединяет стейк нескольких номинаторов и выбирает валидатора. Награды распределяются пропорционально стейку. **Liquid Staking** (через Tonstakers, bemo) позволяет получить ликвидный токен (tsTON, stTON) в обмен на застейканные TON - аналог stETH в Ethereum.

Итоги

• **Трёхуровневая архитектура** TON (Masterchain → Workchains → Shardchains) обеспечивает динамический шардинг: шарды автоматически разделяются при нагрузке и сливаются при её снижении, теоретически до 2^60 параллельных цепочек. Masterchain - корень доверия, хранящий хеши всех шардов и конфигурацию сети
• **Модель акторов TVM** - фундаментальное отличие от EVM: каждый контракт - независимый актор с локальным состоянием, общение только через асинхронные сообщения. Нет атомарности между контрактами - это цена за совместимость с шардингом, которая требует проектирования в стиле распределённых систем
• **Tact** упрощает разработку для TVM: автоматическая сериализация, message handlers, traits (Ownable, Deployable) - при компиляции в FunC → Fift → TVM bytecode. Blueprint обеспечивает тестирование в sandbox, аналогично Hardhat для Ethereum
• **Jettons и NFT** на TON следуют модели акторов: каждый держатель токена получает собственный контракт-кошелёк (вместо mapping в одном контракте), что обеспечивает параллельную обработку в разных шардах ценой сложности трансфера (цепочка из 3-4 асинхронных сообщений)
• Помните кнопку Wallet в Telegram из начала? За ней стоит не просто интеграция - а целая архитектура, где бесконечный шардинг, модель акторов, отдельные контракты-кошельки и TON Connect работают вместе, чтобы 900 миллионов пользователей могли взаимодействовать с блокчейном, не зная, что это блокчейн

Связанные темы

TON развивает идеи шардинга, моделей вычислений и кросс-чейн коммуникации:

• Solana: Proof of History и параллелизм — TON и Solana - два подхода к масштабированию: TON шардирует состояние между цепочками (горизонтально), Solana параллелит выполнение внутри одной ноды (вертикально через Sealevel)
• Cosmos: IBC и модульный блокчейн — Cosmos и TON оба строят экосистемы из множества цепочек, но по-разному: Cosmos даёт суверенные app-chains с IBC, TON - единую шардированную сеть с Hypercube Routing между шардами
• Ethereum транзакции и EVM — Сравнение EVM (синхронные вызовы, глобальный state) и TVM (асинхронные сообщения, actor model) - ключ к пониманию trade-off между composability и масштабируемостью
• Проблема консенсуса: зачем и как — TON использует вариант BFT-консенсуса с Catchain протоколом, где валидаторы выбираются для каждого шарда - развитие идей классического BFT для мульти-шардной среды

Вопросы для размышления

• Модель акторов TON жертвует атомарностью между контрактами ради масштабируемости через шардинг. EVM жертвует масштабируемостью ради атомарных синхронных вызовов. Можно ли спроектировать систему, которая сохраняет оба свойства, или это фундаментальное ограничение распределённых систем (аналог CAP-теоремы)?
• TON получил огромную аудиторию через Telegram Mini Apps (Notcoin - 35M, Hamster Kombat - 300M). Но большинство этих пользователей пришли за играми и airdrop-ами, а не за децентрализованными финансами. Как вы оцениваете retention этой аудитории - станут ли игроки Hamster Kombat пользователями DeFi, или это метрика тщеславия (vanity metric)?
• Минимальный стейк валидатора TON - 300,000 TON (~1M+), один из самых высоких в индустрии. С одной стороны, это обеспечивает экономическую безопасность: атаковать сеть дорого. С другой - концентрирует валидацию среди крупных игроков. Где проходит оптимальная граница между экономической безопасностью и доступностью валидации?

Связанные уроки

• dist-14-sharding