Verified, staked on eth2: #3 – Sharding consensus

Special thanks to Sacha Yves Saint-Leger and Joseph Schweitzer for their reviews.

Sharding is one of the many improvements that eth2 has over eth1. The term is borrowed from database studies, where a shard refers to a part of a larger whole. In the context of databases and eth2, sharding means dividing the storage and computation of an entire system into shards, processing the shards separately, and combining the results as needed. In particular, eth2 implements many shard chains, with each shard having similar functionality to the eth1 chain. This improves large-scale scaling.

However, eth2 has a lesser-known type of sharding. From a protocol design perspective, it’s arguably more interesting. Enter the sharded consensus.

Sharding consensus

Just as the processing power of the slowest node limits the throughput of the network, the computing resources of a single validator limits the overall number of validators that can participate in consensus. Each additional validator introduces additional work to all other validators in the system, so there comes a point where the validator with the fewest resources can no longer participate (because it can no longer keep track of the votes of all the other validators). . . The solution eth2 uses for this is: Sharding consensus.

take it apart

Eth2 divides time into two periods: slots and epochs.

A slot is a 12-second time frame during which a new block is expected 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 consists of 32 slots (6.4 minutes), during which the beacon chain performs all computations related to maintaining the chain, including justifying and finalizing new blocks and issuing rewards and penalties to validators.

like we touched First post in this series, Validators are organized into committees to carry out their work. At any time, each validator is a member of exactly one beacon chain and one shard chain committee, and is asked to prove exactly once per epoch. The proof here is a vote on a proposed beacon chain block. slot.

The security model of eth2’s sharding consensus is based on the idea that the committee provides a somewhat accurate statistical representation of the entire set of validators.

For example, if 33% of the validators in the entire set are malicious, there is a chance that they will be on the same committee. This would be disastrous for our security model.

So we need a way to ensure this doesn’t happen. In other words, if 33% of the validators are malicious, we need a way to ensure that only about 33% of the validators in the committee are malicious.

We can achieve this by doing two things:

1. Ensure committee assignments are random
2. Each committee requires a minimum number of validators.

For example, with 128 randomly sampled validators per committee, it is highly unlikely that an attacker with 1/3 of the validators would control more than 2/3 of the committee (Probability less than 2^-40).

build it

The votes cast by a validator are called attestations. The proof consists of various elements, especially:

• Vote on the current beacon chain head
• Votes on which beacon blocks should be justified/confirmed
• Vote on the current state of the shard chain
• Signatures of all validators agreeing to vote in question

By combining as many components as possible into a proof, the overall efficiency of the system is improved. This is possible because, rather than having to separately verify votes and signatures on beacon blocks and shard blocks, nodes only need to perform the math on the proof to obtain information about the state of the beacon chain and all shard chains.

Being an eth2 node would be prohibitively expensive if every validator had to generate their own proof and have every proof verified by every other node. Enter the aggregate.

Proofs are designed to be easily combined so that if two or more verifiers have proofs that get the same votes, they can be combined by adding signature fields together into one proof. This is what aggregation means.

The committee should have equal voting power over both shard state and the beacon chain, as they have easily aggregable votes because they are assigned to the same shard by composition. This is the mechanism by which eth2 scales the number of validators. By splitting validators into committees, validators only care about their fellow committee members and rarely have to check the aggregated proofs of each other committee.

Signature counting

Eth2 uses BLS signatures. A signature scheme defined for multiple elliptic curves suitable for aggregation. For the specific curve selected, the signature is: 96 bytes each.

If 10% of all ETH is staked, there will be ~350,000 validators on eth2. This means that the signature value of an era is: 33.6MB comes to7.6GB Per day. In this case, all false claims regarding the content In 2018, the eth1 state size reached 1TB. For eth2, it will be true in 133 days (based on signatures only).

The secret here is that BLS signatures can be aggregated. Once Alice creates the signature allBob’s signature reads: rain You can store both Alice’s and Bob’s signatures for the same data and verify them together. C = A + B. With signature aggregation, you only need to store and verify one signature for the entire committee. This reduces your storage requirements to less than: 2MB Per day.

to sum up,

By separating validators into committees, the effort required to verify eth2 is reduced by orders of magnitude.

For a node to verify the beacon chain and all shard chains, it only needs to look at the aggregated proofs of each committee. This way, we know the status of every shard and every validator’s opinion about which blocks are part of the chain and which are not.

Therefore, the committee mechanism helps eth2 achieve two design goals: first article: This means that participating in an eth2 network should be possible on a consumer-grade laptop, and we should strive to be as decentralized as possible by supporting as many validators as possible.

To put it in numbers, while most Byzantine fault-tolerant proof-of-stake protocols scale to tens (or hundreds in extreme cases) validators, eth2 can have hundreds of thousands of validators contributing to security without sacrificing latency or throughput. can.