Sharding in blockchains

Each shard validates its own accounts independently — that's where the parallelism (and the throughput gain) comes from. But alice → bob needs both shards to agree on the outcome, since neither shard alone holds both balances.

Accounts are grouped into shards by hashing their id — the same deterministic assignment every node computes independently, no coordination needed. Most transactions, like alice → carol, never leave their shard. The interesting case is alice → bob: two different shards each hold half the picture, and neither one alone can tell if the whole transaction is valid.

1. Every account is deterministically assigned to a shard

   $\text{shard}(\text{id}) = \text{toyHash}(\text{id}) \bmod N$ for $N$ shards — the same rule run independently by every node, so nobody has to broadcast "which shard is this account in."

2. Most transactions stay inside one shard

   A transaction from account $a$ to account $b$ is same-shard if $\text{shard}(a) = \text{shard}(b)$, and cross-shard otherwise. Same-shard transactions are cheap: one shard has both balances and can validate the whole thing alone.

3. Throughput scales with shard count

   $\text{throughput}(N) = N \times \text{tps}_{\text{per shard}}$ — this is sharding's entire payoff: shards process their own transactions in parallel, so total capacity grows with $N$ instead of staying fixed.

4. Cross-shard transactions need a relay

   A cross-shard transaction can't be validated by either shard alone — it needs a receipt relayed from the source shard to the destination shard (and typically an acknowledgment back), costing extra messages that a same-shard transaction never pays.

• $N$ — the number of shards; more shards means more parallelism, but also more transactions that cross a boundary.
• relayHops — the extra messages a cross-shard transaction needs beyond a single shard's own validation.

Throughput with 3 shards at 10 tx/s each: 30 tx/s total — but every cross-shard transaction costs extra relay messages that a same-shard one never needs.

Click any two accounts to build a transaction between them and watch whether it settles in one message or needs a relay. The accounts don't move — sharding is a property of where an account already lives, not something a transaction can opt out of.

6 accounts, 3 shards: shard(alice)=1, shard(bob)=0, shard(carol)=1, shard(dave)=1, shard(erin)=0, shard(frank)=2.

1. Group the accounts by shard

   • Shard 0: $\{\texttt{bob}, \texttt{erin}\}$
   • Shard 1: $\{\texttt{alice}, \texttt{carol}, \texttt{dave}\}$
   • Shard 2: $\{\texttt{frank}\}$
2. A same-shard transaction: alice → carol

   Both land in shard 1, so $\text{isCrossShard} = \text{false}$ — one message settles it.

3. A cross-shard transaction: alice → bob

   Shard 1 vs shard 0 — $\text{isCrossShard} = \text{true}$. With 2 relay hops, the total message cost is $1 + 2 = 3$, versus 1 for the same-shard case.

4. Throughput at 10 tx/s per shard

   $\text{throughput}(3) = 3 \times 10 = 30$ tx/s total — triple a single validator group's capacity, as long as most transactions stay inside their own shard.