Многослойная архитектура TON
Почему три уровня, а не один
Большинство блокчейнов — это одна цепочка: все транзакции обрабатываются последовательно в одном потоке. Bitcoin, Ethereum (до шардинга), Solana — все работают на одной цепи. Это создаёт bottleneck: производительность ограничена скоростью одного потока.
TON решает эту проблему иерархической архитектурой из трёх уровней:
Роль каждого уровня
| Уровень | Количество | Задача | Аналогия |
|---|---|---|---|
| Masterchain | 1 | Координация, конфигурация, global state | Штаб-квартира компании |
| Workchains | До 2^32 (сейчас 1) | Среда выполнения с правилами | Филиалы с разными правилами |
| Shardchains | До 2^60 на workchain | Параллельная обработка транзакций | Отделы внутри филиала |
Masterchain: координатор сети
Masterchain — единый источник правды для всей сети TON. Он не обрабатывает пользовательские транзакции, а выполняет функции координации:
Что хранит masterchain
Masterchain State:
├── Validator Set (текущие валидаторы + их стейки)
├── Network Config (параметры gas, storage fees, voting)
├── Shard Descriptions (хеши последних блоков каждого шарда)
├── Elector Contract (выборы валидаторов)
├── Config Contract (обновление параметров через голосование)
└── Minter Contract (управление TON supply)Design Decision: зачем отдельный masterchain?
Альтернатива: Хранить конфигурацию и координацию прямо в шардах, как Ethereum.
Проблема: Если конфигурация распределена по шардам, достижение global consensus требует синхронизации всех шардов. При 100+ шардах это становится bottleneck.
Решение TON: Отдельная цепочка для metadata. Masterchain маленький (мало транзакций), но обрабатывается всеми валидаторами. Это обеспечивает:
- Быстрый global consensus (~5 сек)
- Единый snapshot состояния всех шардов
- Проверяемость: любой lite-client может проверить Merkle proof от masterchain до конкретного аккаунта
Design Insight для ваших систем
Паттерн «отдельный координатор» применим не только к блокчейну. В microservices это Service Registry (Consul, etcd). В data engineering — Hive Metastore для Lakehouse. Идея та же: metadata store не обрабатывает данные, а координирует тех, кто обрабатывает.
Workchains: среды выполнения
Workchain — это полноценная блокчейн-среда со своими правилами:
- Свой формат адресов
- Свой virtual machine
- Свои правила gas и storage
- Свой набор системных контрактов
Сейчас активен только Workchain 0 — основная рабочая цепочка TON. Все пользовательские контракты, Jettons, NFT, DeFi — живут здесь.
Зачем нужны дополнительные workchains?
Потенциальные use cases:
- EVM-совместимый workchain — для запуска Ethereum-контрактов на TON
- Privacy workchain — с zk-SNARK транзакциями
- Regulated workchain — для финансовых институтов с KYC
Каждый workchain может иметь другой VM (не TVM), другие gas rules и другие типы аккаунтов. Это даёт TON гибкость, которой нет у single-VM блокчейнов.
Shardchains: параллельная обработка
Shardchains — ядро масштабируемости TON. Каждый шарды:
- Обрабатывает транзакции для группы аккаунтов
- Работает параллельно с другими шардами
- Может автоматически делиться при росте нагрузки
- Может объединяться при снижении нагрузки
Как определяется шард аккаунта
Каждый аккаунт в TON имеет 256-битный адрес. Шард определяется префиксом адреса:
Shard (prefix_len=1):
Shard 0: аккаунты 0x0... — 0x7... (первый бит = 0)
Shard 1: аккаунты 0x8... — 0xF... (первый бит = 1)
Split → Shard (prefix_len=2):
Shard 00: аккаунты 0x0... — 0x3...
Shard 01: аккаунты 0x4... — 0x7...
Shard 10: аккаунты 0x8... — 0xB...
Shard 11: аккаунты 0xC... — 0xF...Критически важно для System Design
Два контракта с похожими адресами (общий prefix) попадают в один шард. Если они часто общаются — это хорошо (intra-shard messages бесплатнее). Если один из них hot (много транзакций) — это плохо (шард перегружен).
При проектировании системы контрактов вы не контролируете, в каком шарде окажется контракт. Но вы контролируете как контракты общаются, и можете проектировать sharding-friendly архитектуру.
Сравнение с другими подходами к масштабированию
| Подход | Блокчейн | Масштабирование | Trade-off |
|---|---|---|---|
| Одна цепь | Bitcoin, Solana | Вертикальное | Ограничено hardware |
| Фиксированные шарды | Ethereum 2.0 (64 шарда) | Горизонтальное, фиксированное | Не адаптируется к нагрузке |
| Динамические шарды | TON | Горизонтальное, адаптивное | Сложность cross-shard |
| L2 rollups | Ethereum (Arbitrum, OP) | Off-chain processing | Trust assumptions, bridge risk |
Если нужен системный нетехнический обзор TON (история, цели, основные подсистемы) до погружения в детали шардирования и actor-model, его удобно прочитать в обзорном уроке курса по TON.
TON: обзор архитектуры