Принципы Sharding-Friendly Design

Главный принцип: 1 аккаунт = 1 потенциальный шард

TON шардирует на уровне аккаунтов (контрактов), не внутри контракта. Один контракт = один аккаунт = обработка в одном шарде = последовательно. Чтобы использовать параллелизм TON, нужно разбить state на несколько контрактов.

[NO] Монолит: всё в одном контракте
TokenContract {
  balances: Map<Address, Int>  // 1M entries = 1 shard = bottleneck
}

[OK] Sharded: state распределён
MasterContract { total_supply, metadata }
WalletContract_1 { balance: 100 }   // свой шард
WalletContract_2 { balance: 200 }   // свой шард  
WalletContract_N { balance: 50 }    // свой шард

5 принципов Sharding-Friendly Design

Принцип 1: Разделяй state по ownership

Каждый пользователь владеет своей частью state → каждая часть в отдельном контракте:

Принцип 2: Минимизируй shared state

Shared state (данные, нужные всем) держи минимальным:

Master Contract (shared state — минимум):
  total_supply: Int
  admin: Address
  metadata_url: String

Wallet Contract (per-user state — всё остальное):
  owner: Address
  balance: Int
  pending_transfers: Map

Принцип 3: Deterministic address computation

Адрес дочернего контракта должен быть вычислим без on-chain запроса:

// Адрес Jetton Wallet для конкретного owner вычислим:
wallet_address = hash(wallet_code + initial_data(owner, master))

// Это означает:
// 1. Любой может узнать адрес wallet-а зная owner и master
// 2. Не нужен on-chain lookup (экономия gas)
// 3. Master может проверить "этот wallet мой?" без хранения списка

Принцип 4: Авторизация через code hash

Как Master проверяет, что входящее сообщение от легитимного child-контракта?

Verification pattern:
1. Master знает wallet_code (bytecode child-контракта)
2. Получает сообщение от sender_address
3. Вычисляет: expected_address = hash(wallet_code + init_data(claimed_owner))
4. Проверяет: sender_address == expected_address?
5. Если да — sender является легитимным wallet для claimed_owner

Принцип 5: Idempotent child operations

Операции в child-контрактах должны быть идемпотентными — повторный вызов даёт тот же результат:

[OK] Idempotent:
set_balance(100)  // результат всегда balance=100

[NO] Not idempotent:
add_balance(50)   // первый раз: 100→150, второй: 150→200
                  // replay = double credit!

Когда НЕ шардировать

Sharding — не silver bullet. Trade-offs:

Чтобы решения по sharding-friendly дизайну были основаны на реальной механике сети, полезно понимать, как устроены workchains и shardchains в TON: split/merge логика, hypercube routing, ограничения cross-shard сообщений.