CAP-теорема и распределённые системы

CAP-теорема: выбери два из трёх

В 2000 году Eric Brewer сформулировал теорему, которая определяет фундаментальное ограничение любой распределённой системы:

В распределённой системе невозможно одновременно гарантировать все три свойства: Consistency (согласованность), Availability (доступность), и Partition Tolerance (устойчивость к разделению сети).

CAP-теорема

C — Consistency

A — Availability

P — Partition Tolerance

В реальности сетевые разделения неизбежны (P обязательна).
Выбор: CP (согласованность + устойчивость) или AP (доступность + устойчивость)

Почему P неизбежна

В реальном мире сетевые разделения (network partitions) случаются всегда:

Подводные кабели обрезаются
Дата-центры теряют связь
Роутеры падают

Поэтому реальный выбор — между CP и AP:

Тип системы	Выбор	Примеры	Поведение при partition
CP	Consistency + Partition Tolerance	ZooKeeper, MongoDB (strong reads)	Отказывает в обслуживании, пока не восстановится consensus
AP	Availability + Partition Tolerance	Cassandra, DynamoDB	Продолжает работать, но данные могут быть устаревшими

Блокчейн через призму CAP

Блокчейн — это распределённая система, и CAP-теорема к нему полностью применима. Но блокчейн делает уникальный выбор:

Ethereum: Строгий CP

Ethereum выбирает strong consistency: все узлы должны согласиться на одно состояние перед тем, как блок будет принят. Результат:

Все видят одинаковые данные
Медленнее (~12 сек блок), ниже throughput
Если сеть разделилась — побеждает chain с большинством валидаторов

TON: Ослабленная CP с eventual consistency

TON делает более гибкий выбор:

TON: Consistency Model

Intra-shard

Cross-shard

Global (Masterchain)

TIP

Для System Design это значит:

Когда вы проектируете систему из нескольких контрактов на TON, вы должны учитывать, что контракты в разных шардах видят разные версии состояния в один момент времени. Операции, требующие атомарности (например, swap на DEX), нужно проектировать с учётом eventual consistency.

Consensus: как достигается согласие

Consensus — это протокол, по которому узлы распределённой системы договариваются о едином состоянии. Без consensus блокчейн невозможен.

BFT + PoS в TON

TON использует Byzantine Fault Tolerant (BFT) consensus в комбинации с Proof-of-Stake:

Валидаторы стейкают TON (~300,000 TON минимум для полного валидатора)
Collator собирает транзакции в блок-кандидат
Validator set голосует за блок (BFT — выдерживает до ⅓ злонамеренных валидаторов)
Блок финализируется за ~5 секунд

Consensus в TON:

Collator → создаёт block-candidate
              ↓
Validators → голосуют (BFT: 2/3 + 1 голосов достаточно)
              ↓
Block committed → finality (~5 сек)
              ↓
Masterchain → фиксирует hashes всех shardchain блоков

Масштабирование: вертикальное vs горизонтальное

Вертикальное масштабирование (Scale Up)

Увеличить мощность одного узла: больше RAM, быстрее CPU, SSD → NVMe.

В блокчейне: увеличить размер блока (Bitcoin → Bitcoin Cash), увеличить gas limit. Но это увеличивает требования к узлам и снижает децентрализацию.

Горизонтальное масштабирование (Scale Out)

Добавить больше узлов, разделить нагрузку между ними.

В блокчейне: шардирование. TON — единственный блокчейн с динамическим горизонтальным масштабированием (шарды создаются и объединяются автоматически).

Масштабирование: Scale Up vs Scale Out

Scale Up (вертикальное)

1 узел × max мощность

Потолок: hardware limits

Scale Out (горизонтальное)

Shard 1

Shard 2

Shard N

TON: шарды ∞, авто-split/merge

Latency vs Throughput

Два ключевых performance-метрики:

Latency — время обработки одной операции (от отправки до подтверждения)
Throughput — количество операций в секунду (TPS)

Блокчейн	Latency (finality)	Throughput (TPS)	Approach
Bitcoin	~60 мин	~7 TPS	Single chain, PoW
Ethereum	~12 сек	~30 TPS	Single chain, PoS
Solana	~400 мс	~4,000 TPS	Single chain, PoH
TON	~5 сек	~100,000+ TPS	Dynamic sharding

NOTE

Почему TON быстрее Solana при большей латентности?

Solana оптимизирует latency (очень быстрый single chain), но throughput ограничен одним chain. TON оптимизирует throughput через шардирование — каждый шард обрабатывает транзакции параллельно. При росте нагрузки TON создаёт новые шарды, масштабируясь горизонтально.

Для DeFi-приложений 5 секунд latency допустимы, а вот 100,000 TPS — критически важны при массовом adoption.

Связь с последующими модулями

Принципы из этого урока — фундамент для всего курса:

Принцип	Где применяется
CAP и eventual consistency	M03: Actor Model — проектирование для async
Шардирование	M02: TON Architecture, M04: Contract Sharding
Consensus и finality	M07: DeFi Design — ordering, front-running
Latency vs Throughput	M06: Gas Optimization, M10: Payment Channels

Проверка знанийKnowledge check

ОтветAnswer