Heartfelt gratitude to Sacha Yves Saint-Leger & Joseph Schweitzer for their evaluation.
Sharding constitutes one of the numerous enhancements that eth2 offers compared to eth1. The concept was taken from database studies where a shard indicates a fragment of a more extensive entity. In the realm of databases and eth2, sharding involves dividing the storage and processing of the entire system into shards, managing the shards individually, and merging the outcomes as required. More specifically, eth2 adopts multiple shard chains, where each shard possesses capabilities akin to the eth1 chain. This leads to significant scalability advancements.
Nonetheless, there exists a lesser-known kind of sharding in eth2. One that could be considered more intriguing from the aspect of protocol architecture. Introducing sharded consensus.
Sharding Consensus
Just as the processing capacity of the slowest node constrains the network’s throughput, the computational assets of a single validator restrict the total number of validators that can engage in consensus. As each supplementary validator adds additional work for every other validator within the network, there will be a threshold where the validator with the fewest resources can no longer participate (due to its inability to track the votes of all other validators). The method eth2 utilizes to address this is sharding consensus.
Breaking it down
Eth2 divides time into two periods, slots and epochs.
A slot corresponds to a 12-second interval during which a new block is anticipated to be added to the chain. Blocks serve as the mechanism through which votes cast by validators are incorporated into the chain alongside the transactions that render the chain functional.
An epoch is made up of 32 slots (6.4 minutes), during which the beacon chain carries out all the calculations required for the maintenance of the chain, including: validating and finalizing new blocks, as well as distributing rewards and penalties to validators.
As mentioned in the initial post of this series, validators are organized into committees to perform their tasks. At any given moment, each validator belongs to exactly one beacon chain and one shard chain committee, and is called upon to make an attestation precisely once per epoch – an attestation being a vote for a beacon chain block proposed for a specific slot.
The security framework of eth2’s sharded consensus is founded on the concept that committees offer a reasonably accurate statistical representation of the complete validator set.
For instance, in a scenario where 33% of validators within the overall set are malicious, there exists a risk that they could be grouped in the same committee. This scenario would pose a significant threat to our security model.
Thus, we require a mechanism to guarantee that this occurrence cannot transpire. In other words, we need a method to ensure that if 33% of validators are malicious, only approximately ~33% of validators in any committee will likewise be malicious.
It turns out we can achieve this through two actions:
- Ensuring committee assignments are randomized
- Mandating a minimum number of validators within each committee
For example, with 128 validators randomly selected for each committee, the likelihood of an attacker with one-third of the validators gaining control over more than two-thirds of the committee is exceedingly small (probability less than 2^-40).
Building it up
Votes submitted by validators are termed attestations. An attestation comprises several components, specifically:
- a vote for the current beacon chain head
- a vote determining which beacon block should be justified/finalized
- a vote concerning the current state of the shard chain
- the signatures of all validators who concur with that vote
By amalgamating as many elements as feasible into an attestation, the overall system’s efficiency is enhanced. This is feasible since, instead of verifying votes and signatures for beacon blocks and shard blocks individually, nodes only need to compute on attestations to remain informed about the state of the beacon chain and each shard chain.
If every validator generated their own attestation and each attestation had to be validated by all other nodes, then operating as an eth2 node would be prohibitively costly. Introducing aggregation.
Attestations are crafted to be easily merged, allowing two or more validators with attestations featuring the same votes to be combined by summing the signature fields into a single attestation. This is what we refer to as aggregation.
Committees, by their design, will have votes that are easily aggregated since they belong to the same shard and thus should hold uniform votes for both the shard state and beacon chain. This is the mechanism through which eth2 enhances the number of validators. By segmenting validators into committees, they only need to consider their fellow committee members and need to check merely a few aggregated attestations from other committees.
Signature aggregation
Eth2 employs BLS signatures – a signature method established over various elliptic curves that is conducive to aggregation. On the selected curve, signatures are 96 bytes each.
If 10% of all ETH is staked, then approximately ~350,000 validators will exist on eth2. This implies that an epoch’s signature load would be 33.6 megabytes, totaling roughly ~7.6 gigabytes daily. In this scenario, all the unfounded claims regarding the eth1 state-size hitting 1TB in 2018 would hold true in less than 133 days for eth2 (based solely on signatures).
The key aspect here is that BLS signatures are combinable: If Alice generates signature A, and Bob produces signature B on identical data, then both Alice’s and Bob’s signatures can be stored and verified collectively by preserving C = A + B. By employing signature aggregation, only one signature is required to be stored and verified for the whole committee. This cuts down the storage needs to less than 2 megabytes daily.
In summary,
By segmenting validators into committees, the effort needed to verify eth2 is decreased by several magnitudes.
For a node to affirm the beacon chain and every shard chain, it is required only to consider the aggregated attestations from each committee. Thus, it can ascertain the status of every shard, as well as every validator’s stance on which blocks are or aren’t part of the chain.
The committee framework consequently aids eth2 in achieving two of the design objectives outlined in the initial article: specifically, that engaging in the eth2 network must be feasible on a consumer-grade laptop, and that it should aim to be as decentralized as possible by accommodating as many validators as feasible.
In numerical terms, while most Byzantine Fault Tolerant Proof of Stake protocols scale to dozens (and in extreme cases, hundreds) of validators, eth2 can support hundreds of thousands of validators all contributing to security without sacrificing latency or throughput.