Special thanks to Sacha Yves Saint-Leger and Joseph Schweitzer for their review.
Sharing is one of the many improvements eth2 makes over eth1. The term was borrowed from database searching, where a fragment refers to a piece of a larger whole. In the context of databases and eth2, sharding means dividing the storage and computation of the entire system into fragments, processing the fragments separately, and combining the results as needed. Specifically, eth2 implements many shard chains, where each shard has similar capabilities to the eth1 chain. This results in massive scaling improvements.
However, there is a lesser known type of partitioning in eth2. One that is arguably more exciting from a protocol design perspective. Enter shared consensus.
Share the consensus
Just as the processing power of the slowest node limits network throughput, the computing resources of a single validator limit the total number of validators that can participate in consensus. Since each additional validator introduces additional work for all other validators in the system, there will come a point where the validator with the fewest resources will no longer be able to participate (because they will no longer be able to track the votes of all other validators). . The solution used by eth2 for this is consensus sharing.
Break it down
Eth2 breaks down time into two durations, slots and epochs.
A slot is the 12-second period in which a new block is supposed to be added to the chain. Blocks are the mechanism by which votes cast by validators are included in the chain in addition to the transactions that actually make the chain useful.
An epoch is composed of 32 slots (6.4 minutes) during which the beacon chain performs all calculations associated with maintaining the chain, including: justifying and finalizing new blocks, and assigning rewards and penalties to validators .
As we mentioned in the first article in this seriesvalidators are organized into committees to do their work. At any given time, each validator is a member of exactly one beacon chain and shard chain committee, and is called upon to attest exactly once per epoch – where an attestation is a vote for a blockchain block of tags that was proposed for a slot.
Eth2’s shared consensus security model is based on the idea that committees are more or less an accurate statistical representation of the overall set of validators.
For example, if we find ourselves in a situation where 33% of the validators in the overall set are malicious, there is a chance that they end up on the same committee. This would be a disaster for our security model.
So we need to find a way to ensure that this cannot happen. In other words, we need a way to guarantee that if 33% of validators are malicious, only about 33% of validators on a committee will be malicious.
It turns out we can achieve this by doing two things:
- Ensure committee assignments are random
- Require a minimum number of validators in each committee
For example, with 128 randomly selected validators per committee, the chance of an attacker with 1/3 of the validators taking control of >2/3 of the committee is extremely low (probability less than 2^-40).
Build it
The votes cast by validators are called certificates. A certificate is made up of many elements, including:
- a vote for the current beacon chain leader
- a vote on which tag block should be justified/finalized
- a vote on the current state of the shard chain
- the signatures of all validators who agree with this vote
By combining as many components as possible into one certificate, the overall efficiency of the system is increased. This is possible because, instead of having to verify the votes and signatures of beacon blocks and shard blocks separately, nodes only need to do the calculation of the attestations to be informed of the status of the tag string and each fragment string.
If each validator produced their own attestation and each attestation had to be verified by every other node, then being an eth2 node would be prohibitively expensive. Enter aggregation.
The attestations are designed to be easily combined, so that if two or more validators have attestations with the same votes, they can be combined by adding the signature fields into a single attestation. This is what we mean by aggregation.
Committees, by their construction, will have votes that are easy to group together because they are assigned to the same shard, and therefore should have the same votes for shard state and beacon chain. This is the mechanism by which eth2 increases the number of validators. By dividing validators into committees, validators only have to worry about their fellow committee members and only need to check very few aggregated attestations from each of the other committees.
Signature aggregation
Eth2 uses BLS signatures – a signature scheme defined over multiple elliptic curves that facilitates aggregation. On the specific curve chosen, the signatures are 96 bytes each.
If 10% of all ETH ends up being staked, then there will be around 350,000 validators on eth2. This means that the value of signatures of an era would be 33.6 megabytes which amounts to ~7.6 gigabytes per day. In this case, all false claims regarding the eth1 state size reached 1TB in 2018 would be true in the case of eth2 in less than 133 days (based on signatures alone).
The trick here is that BLS signatures can be grouped: if Alice produces a signature Aand Bob’s signature is B on the same data, Alice and Bob’s signatures can be stored and verified together by storing only C = A + B. Using signature aggregation, a single signature must be stored and verified for the entire committee. This reduces storage requirements to less than 2 megabytes per day.
In summary,
By separating validators into committees, the effort required to verify eth2 is reduced by several orders of magnitude.
For a node to validate the beacon chain and all shard chains, it only needs to consult the aggregated attestations from each of the committees. This way it can know the state of each shard and the opinions of each validator on which blocks are or are not part of the chain.
The committee mechanism therefore helps eth2 achieve two of the design goals established in the first article: namely that participation in the eth2 network should be possible on a consumer laptop, and that it should strive to be as decentralized as possible by supporting as many validators as possible.
To encrypt, while most Byzantine fault-tolerant proof-of-stake protocols scale to dozens (and in extreme cases, hundreds of validators), eth2 is capable of having hundreds of thousands of validators all contribute to security without compromising latency or throughput.
