Now, let’s consider security in Ethereum 2.0, by which I mean that it is as hard as possible for attackers to make the network behave in unexpected ways (such as a 51% attack in the PoW protocol).

In Ethereum 2.0, this kind of security comes from having a large pool of validators who are in turn organised into large committees: each signing-off on protocol activities, such as checking data availability and voting to finalise transactions.

The advantages of having a large number of available validators and large committees are several. First, a large validator pool allows more opportunity for decentralisation and therefore diversity of participants, which makes collusion less likely and more difficult. Nonetheless, the threat model assumes that an attacker could potentially end up controlling up to a third of all the validators.

Second, if something that violates the protocol occurs — perhaps finalising two blocks at the same height — it means that many validators must have disobeyed the rules (by voting for two blocks). This behaviour is detectable and the misbehaving group will be punished by having their stakes wiped out. Requiring that a great many validators sign-off on any decision therefore gives strong “economic security”: a lot of money will be lost by the bad actors if they misbehave. This is not the case in proof of work chains: 51% attackers bear only the marginal costs of running their hardware: their ASIC farms don’t burn down.

The third reason is mathematical. If we assume our total pool of validators has up to a third dishonest validators, then, the larger the committees we select from that pool, the less likely it becomes that any single committee will have a majority of dishonest members. To illustrate: say we have 1000 validators, 333 of which are dishonest. If I randomly select a committee with one member, then there is a 33.3% chance that the committee is a dishonest validator. If I randomly select a committee of three members, there is a 25.9% chance that two out of the three are dishonest. Thirteen members gives a 10% chance that a majority is dishonest, and so on. At the other end of the scale, if I select a committee of 667 members then there is a 0% chance that over half are dishonest.

In Ethereum 2.0, an attacker would need to gain a 2/3 majority within a committee to do serious damage. With the chosen minimum committee size of 128, selected from a pool of several thousand validators, there is less than a one-in-a-trillion chance of this happening, even if the attacker manages to control a third of the whole validator pool.

Achieving this design goal enables the widespread use of validator committees within the protocol: basically every protocol action is voted on by committees of randomly selected set of members. These committees are constantly shuffled, in some cases as frequently as every 384 seconds. A cryptographic innovation that has made this possible is the use of BLS aggregate signatures. Basically, committee members can individually sign-off on decisions, and these individual signatures can be combined into a single signature that is easy to verify. Without this capability, the time taken to validate signatures from individual committee members would severely limit the number of validators that could participate in any decision.

Simplicity

To minimize complexity, even at the cost of some losses in efficiency.

Ethereum 2.0 is not a Rube Goldberg machine [image: public domain]

This is, perhaps, the easiest of the goals to justify. Complexity is the enemy of security. To ensure that Ethereum 2.0 always functions as intended, we must be able to reason about its protocols. It must be possible to analyse its behaviours to root out the corner cases and perverse incentives. We should be able to perform formal verification as much as possible.

If you look over the current specification, “simplicity” may not be your first impression. But, simplicity is not just about lines of code, it is primarily about the concepts we are implementing. Any blockchain technology already sits at the intersection of three notoriously tricky disciplines: distributed systems, cryptography and game theory. Even in a relatively straightforward cryptoeconomic system such as Ethereum 1.0, unintended consequences can arise. Gas Token is an example of this: a mechanism designed to reduce the amount of data stored in the blockchain state has resulted in a large increase in data stored. The simpler our protocol, the better we can analyse and defend against oddities like this.

The blockchain world is alive with innovation. It’s a rare day when I don’t hear about an amazing new consensus protocol, a funky new cryptographic primitive, a groovy new cryptoeconomic gadget. By comparison, the design of Ethereum 2.0 can look conservative, although it does in fact embody a tremendous amount of innovation. The conservatism is deliberate: the design must be as simple as it can be.

As an example, there are similarities between the design of Polkadot and the design of Ethereum 2.0. (Which is unsurprising as Gavin Wood did some of the early thinking around Ethereum sharding.) Both are sharded protocols: in Polkadot each shard can run a different protocol, whereas in Ethereum 2.0 every shard runs the same protocol. There are attractions to Polkadot’s heterogeneous design, but in the end, for Ethereum, minimising complexity wins.

The idea is to put only the minimum necessary apparatus into the Ethereum 2.0’s Layer 1, the mission-critical consensus layer, and to push complexity further up the stack. This is one reason why features like identity and privacy are not baked into the protocol. Vitalik’s article, “Layer 1 Should Be Innovative in the Short Term but Less in the Long Term”, is great further reading on this.

Longevity