Infinite Sharding Paradigm

Идея: каждый аккаунт — потенциально свой шард

Infinite Sharding Paradigm (ISP) — ключевая инновация TON. Идея: в идеальном пределе каждый аккаунт мог бы иметь свой шард. Все аккаунты обрабатываются параллельно. Реальность: шарды группируют аккаунты для эффективности, но могут дробиться до любого уровня.

Infinite Sharding Paradigm:

Уровень 0: [весь workchain — один шард]
              ↓ нагрузка растёт
Уровень 1: [шард 0] [шард 1]
              ↓ нагрузка ещё растёт
Уровень 2: [00] [01] [10] [11]
              ↓ ...
Уровень N: каждый аккаунт — свой шард (теоретический предел)

Auto-Split и Auto-Merge

Split (деление шарда)

Когда нагрузка на шард превышает порог — шард автоматически делится на два:

ДО split:
Shard (0,4): обрабатывает аккаунты 0x0... — 0x0F...
  → нагрузка: 1000 tx/блок (порог: 800)

ПОСЛЕ split:
Shard (0,5): аккаунты 0x00... — 0x07...  (500 tx/блок)
Shard (8,5): аккаунты 0x08... — 0x0F...  (500 tx/блок)

Merge (объединение шардов)

Когда нагрузка падает — два соседних шарда объединяются:

ДО merge:
Shard (0,5): 50 tx/блок
Shard (8,5): 30 tx/блок  
  → суммарно 80 tx/блок (порог merge: 100)

ПОСЛЕ merge:
Shard (0,4): 80 tx/блок

WARNING

Для System Design это критично

Split/merge означает, что два контракта, которые сейчас в одном шарде, завтра могут оказаться в разных. Ваша архитектура не должна зависеть от того, в каком шарде находится контракт. Сообщения между контрактами должны быть спроектированы для cross-shard delivery.

Hypercube Routing

Как сообщения доставляются между шардами? TON использует Instant Hypercube Routing — маршрутизацию через гиперкуб.

Проблема: O(N) routing

Если каждый шард связан только с соседями, доставка сообщения из шарда 1 в шард 1000 потребует 999 промежуточных шагов.

Решение: Hypercube topology

Шарды организованы в гиперкуб. Каждый шард имеет прямые связи с шардами, отличающимися на один бит в идентификаторе:

Shard 0000 связан с:
  0001 (1 бит отличается)
  0010 (1 бит)
  0100 (1 бит)
  1000 (1 бит)

Маршрут от 0000 к 1111:
  0000 → 0001 → 0011 → 0111 → 1111
  Всего: 4 хопа (= log2(16) = число бит)

Результат: Сообщение между любыми двумя шардами доставляется за O(log N) хопов, где N — число шардов.

Hypercube Routing: O(log N) доставка

Линейная: O(N)

Full Mesh: O(1)

Hypercube: O(log N)

Validator Groups

Не все валидаторы обрабатывают все шарды. TON разделяет валидаторов на группы:

Masterchain validators — обрабатывают masterchain (все ~350 валидаторов)
Shard validators — подмножество, назначенное на конкретный шард

NOTE

Текущее состояние сети

По данным сети (актуально на момент написания): ~350 активных валидаторов, 667M+ TON в стейке, минимум 300,000 TON для полного валидатора. Сеть активно развивается — проверяйте актуальные данные на tonstat.com.

Design Implications

1. Не полагайтесь на shard locality

Два контракта в одном шарде сегодня — могут быть в разных завтра. Проектируйте коммуникацию как всегда cross-shard.

2. Минимизируйте cross-shard сообщения

Каждое cross-shard сообщение добавляет latency (1 блок на хоп). Для критичных операций (DEX swap) — минимизируйте число сообщений.

3. Sharding-friendly state design

Разбивайте state на мелкие контракты (один контракт = один «account» = один потенциальный шард). Монолитный контракт с 1M пользователей — это bottleneck, который не может быть разделён шардами.

4. Планируйте gas для worst case

Cross-shard сообщения стоят больше, чем intra-shard. Рассчитывайте gas для worst case (все контракты в разных шардах).

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

ОтветAnswer