Зачем блокчейн-разработчику System Design
Проблема: контракт работает — система нет
Типичная ситуация: разработчик написал смарт-контракт, который проходит все тесты. Контракт деплоится в mainnet. И через неделю при росте нагрузки:
- Газ на транзакции стоит в 10 раз больше ожидаемого
- Операции, которые должны быть атомарными, оказываются разорваны по шардам
- Контракт хранит слишком много данных — storage fee съедает баланс
- Пользователи теряют средства из-за race conditions в асинхронных сообщениях
Проблема не в коде контракта. Проблема в архитектуре системы.
Блокчейн != обычный бэкенд
В традиционном web-разработке вы можете откатить деплой, сделать hotfix, перезапустить сервер. В блокчейне каждая транзакция необратима, каждый баг стоит реальных денег, а «перезапустить» контракт невозможно. System Design здесь — это не абстракция для собеседования, а инструмент выживания.
Что такое System Design
System Design — это процесс принятия архитектурных решений о том, как компоненты системы взаимодействуют друг с другом для достижения заданных целей при заданных ограничениях.
Ключевые вопросы System Design:
- Как разделить систему на компоненты? → В TON: как разделить логику между контрактами?
- Как компоненты общаются? → В TON: messages, internal/external, bounce
- Как обеспечить надёжность? → В TON: gas management, error handling, replay protection
- Как масштабироваться? → В TON: sharding-friendly design
- Как обеспечить безопасность? → В TON: attack vectors, access control, upgradeability
Классический SD vs Блокчейн SD
Классический Web SD
Блокчейн SD (TON)
Ключевые отличия
| Аспект | Классический Web | Блокчейн (TON) |
|---|---|---|
| Состояние | Централизованная БД, можно изменить | Распределённый ledger, неизменяемый |
| Откат ошибок | Rollback транзакции, hotfix | Невозможен — только новая транзакция |
| Масштабирование | Горизонтальное (добавить серверы) | Шардирование (разделить контракты) |
| Стоимость | CPU/RAM серверов | Gas за каждую операцию |
| Латентность | Миллисекунды | Секунды (5-6с для TON) |
| Коммуникация | Синхронные вызовы (HTTP/RPC) | Асинхронные сообщения |
| Атомарность | ACID-транзакции | Ограниченная (в рамках одного контракта) |
Ключевой инсайт
В классическом web вы проектируете запрос-ответ системы. В TON вы проектируете акторные системы с асинхронным обменом сообщениями. Это фундаментально другая парадигма, требующая других паттернов проектирования.
Почему именно TON требует отличного SD
TON добавляет уникальные сложности, которых нет в других блокчейнах:
1. Асинхронность
В Ethereum все вызовы контрактов синхронны — вы вызвали функцию другого контракта и сразу получили результат. В TON контракты общаются через асинхронные сообщения. Результат придёт в следующей транзакции, возможно в другом блоке.
Ethereum (синхронный):
ContractA.transfer() → ContractB.receive() → return result → ContractA продолжает
TON (асинхронный):
ContractA → отправил message → закончил транзакцию
↓
ContractB получил message → обработал → отправил ответ
↓
ContractA получил ответ2. Динамическое шардирование
TON автоматически разделяет и объединяет шарды в зависимости от нагрузки. Это значит, что два контракта, которые сейчас в одном шарде, завтра могут оказаться в разных. Это влияет на:
- Стоимость cross-shard сообщений
- Время доставки сообщений
- Гарантии порядка обработки
3. Экономика хранения
В TON вы платите не только за выполнение кода, но и за хранение данных. Контракт с большим состоянием постоянно теряет баланс на storage fee. Если баланс падает до нуля — контракт замораживается.
Если на этом этапе чувствуется нехватка криптографического и блокчейн-фундамента (хеш-функции, подписи, эллиптические кривые, AMM-математика, MEV), его удобно добрать в курсе по основам криптографии и блокчейна.
Crypto Fundamentals: о курсе