Design a Blockchain Sharding Protocol

Problem statement

Design a sharded proof-of-stake blockchain — call it Lattice — that partitions accounts, state, and transaction processing across S parallel shards while a beacon chain provides randomness, validator registry, cross-shard settlement, and economic finality. Every shard processes its own transactions in parallel; cross-shard operations must remain atomic or explicitly compensable; no coalition below one-third of total stake may capture a single shard; and a home node operator must run on partial state, not the entire ledger.

A monolithic chain replicates every transaction on every full node. Ethereum mainnet sustains roughly 13–16 TPS because each of thousands of nodes re-executes the same ~150 transactions per 12-second block. Sharding inverts this: each validator re-executes only its shard's share, so aggregate throughput grows with the validator set instead of being capped by one node's CPU. The price is that trust becomes statistical rather than universal: a user no longer relies on 'every node checked everything' but on 'a randomly sampled committee of 250 validators checked my shard, and the beacon chain cryptographically linked their result into global finality'.

The four sharding dimensions

Network sharding: partitioning the peer-to-peer overlay so nodes only gossip with their shard; without it, bandwidth per node does not fall and sharding is theater.
Transaction sharding: routing each transaction to a deterministic shard (by sender address prefix in Lattice) so shards process disjoint workloads in parallel.
State sharding: each shard stores only its own state trie; this is the dimension that actually reduces hardware requirements for operators.
Computation sharding: execution of contracts happens only in the owning shard; cross-shard calls become message passing, not synchronous calls.

A credible answer separates these four. Many candidates say 'split the database' and implicitly design only transaction sharding while leaving every node downloading every block — which defeats the purpose.

Why this is hard: the trilemma restated

Sharding attacks the scalability vertex of the scalability–security–decentralization trilemma by weakening per-node verification and repairing trust with three mechanisms: (a) random, unpredictable committee assignment from beacon randomness so an adaptive adversary cannot target a shard; (b) cryptographic cross-linking of shard headers into the beacon chain so shard history is fork-choice-bound to global finality; (c) data availability sampling with erasure coding so light clients can verify availability without downloading everything. Remove any one of the three and the design collapses: predictable assignment enables single-shard takeover, missing crosslinks enable shard history rewrites, and missing availability checks enable hidden data that makes state unrecoverable.

Public evidence that sharding works at production scale

Zilliqa's public technical FAQ reports a peak of 2,488 TPS with 3,600 nodes across 6 shards using pBFT inside each shard [[19]]. MultiversX documents 263,000 TPS achieved in a public testnet with 50 shards using adaptive state sharding [[34]]. NEAR shipped Nightshade sharding to mainnet and reports 800–1,000 TPS per shard for simple transfers, scaling linearly with shard count [[26]]. Ethereum itself pivoted from execution shard chains to data-availability sharding (danksharding) with data availability sampling over blobs [[79]]. These are different points in the same design space, and this answer positions Lattice explicitly among them.

What this answer will cover

Shard assignment logic and resharding (FR1), intra-shard BFT consensus plus cross-shard receipt passing (FR2), beacon-chain final settlement and crosslinks (FR3), validator distribution and anti-capture reshuffling (FR4), near-linear TPS scaling with explicit coefficients (NFR1), takeover and double-spend resistance with probability bounds (NFR2), partial-state node operation (NFR3), and governance for adding or retiring shards (NFR4).

Key Highlights

•Sharding has four dimensions — network, transaction, state, computation — and all four must be designed or per-node load does not fall.
•Monolithic Ethereum re-executes every tx on every node (~13–16 TPS); sharding makes throughput grow with validator count.
•Trust becomes statistical: sampled committees of 250 plus beacon crosslinks plus data availability sampling replace universal re-execution.
•Zilliqa measured 2,488 TPS at 3,600 nodes/6 shards; MultiversX reports 263k TPS testnet at 50 shards; NEAR reports 800–1,000 TPS per shard.
•Remove random assignment, crosslinks, or availability sampling and the protocol collapses to a takeover-vulnerable or unverifiable system.