Ethereum 2 Sharding

Sharding aims to solve the scalability trilemma (Scalability, Decentralization, Security). It works by splitting up the verification job amongst randomly selected validators that form their own committee. A validator publishes a signature attesting that they did their job, and the other validators verify this signature (e.g. via BLS signature aggregation). This way instead of 10k validators each verifying 100 blocks, they’re mining a few blocks in each committee and verifying the signatures of the 10k validators.

Blocks are broadcast on subnets instead of p2p to all validators. In Big O Notation, the sharded chain’s capacity is O(C^2), growing quadratically (aka quadratic sharding).

We want to have a sharding solution that avoids 51% trust assumptions for validation. Validation problem is two parts: validating computation, and validating data availability. The former relies on either fraud-proofs or zk-snarks. The data availability problem (i.e. “how do you check that 1 MB of data is available without actually trying to download it?”) can be solved via data-availability-sampling which makes it feasible to run data availability checking on every block.

In the case of Ethereum sharding, the near-term plan is to make sharded blocks data-only; that is, the shards are purely a “data availability engine”, and it’s the job of layer-2 rollups to use that secure data space, plus either fraud proofs or ZK-SNARKs, to implement high-throughput secure transaction processing capabilities. However, it’s completely possible to create such a built-in system to add “native” high-throughput execution.

Shard Chains

  • 64 shard chains that users post transactions to
  • When a validator successfully proposes a block in a given slot it gets referenced in the beacon chain via a “crosslink” (a signature signed by the committee). Every shard block creates a crosslink

Communicating Between Shards

Transactions between shards are asynchronous (not atomic), however many transactions could work under this model.

Cross-shard communication could be achieved using a receipt proof concept,

  1. Send a tx to shard M that produces a receipt. The receipt is not saved on chain directly, but the fact that the receipt was generated can be verified via a merkle proof.
  2. Wait for tx to be included on shard M.
  3. On shared N include the merkle proof from shared M.

Further types of cross-shard communication challenges: What is the train-and-hotel problem?.

Notes mentioning this note