We have finally reached the tranquil waters of Ethereum 2.0 (also known as “Serenity”). It's been many years in the making, and it appears we still have some way to go yet.

In fact, coming up with the right wording for the previous sentence was quite a challenge, because Kernel aims for “evergreen” content which will still be accurate and relevant at least a decade from now. As we will shortly see, this is an aspiration we share with the Ethereum 2.0 Design Rationale.

You might wonder, are we saying that we will “still have some way to go” ten years from now? We certainly hope so. The desire for enclosure, for a certain and definitive end state which can be encapsulated as a “product” and consumed by the wider culture is a peculiarly modern phenomenon.

We hope that Ethereum, and networks like it, are never really finished. We hope that people continue tinkering, playing with new ways of relating to one another for as long as there are world machines and people using them to build trust spaces. What is truly fascinating is not finished products to sell, but the ongoing art of making possible:

How does this fit into Kernel?¶

In a way, this is what Kernel has been preparing you for: the continuous iteration which leads to a global, public, decentralized and censorship-resistant computing surface which anyone can use and no-one owns.

What this means for our networked species remains an open question. One thing seems clear: it is an upgrade the likes of which is only seen once in an age. You'll need to recall the arguments made in value and incentives to understand the design rationale for these next few scenes of the human story.

We’ll be taking a close look at Vitalik’s Design Rationale for Ethereum 2.0, which is the move to a Proof-of-Stake network that also greatly increases capacity by using “shards”. Don’t get intimidated by the technical jargon here: this has been included in the syllabus for two primary reasons:

Principled Layers¶

Just as we did for Kernel, Vitalik begins Ethereum 2.0's Design Rationale with a series of core principles:

In our very first note, we made the point that our way of thinking and solving problems always has to do with trade-offs. The trade-off between complexity and functionality is a deep one. Ethereum developers have taken the approach of splitting the network into “layers” in order to make better trade-offs between complexity and the functionality we need to build a global computing fabric that everyone can use.

The core idea is that we keep the “bottom layer” or “Layer 1” as simple as possible: it just processes critical or high-value transactions that require global agreement. This adheres to the first, second, and fourth principle above. Then, we move more complex processes–which cost more to run and may not need everyone in the world to agree on them right now–to other layers further up, often called “Layer 2”.

There are many different kinds of “Layer 2” options, which make different trade-offs depending on what they are optimising. All the complexity gets moved here–and understanding all the different approaches can be daunting–but a diversity of approaches to processing different people’s different needs and use cases is required to give us all “sufficiency”, as well as providing “defence in depth” in a different kind of way.

A Defender's Game¶

Bitcoin was a major innovation - it's almost like time-travelers came back to 2009 and dropped it on an obscure mailing list for us to puzzle over. However, it is not elegant and its consensus algorithm breaks one of the fundamental advantages cryptography provides: adversarial conflict should heavily favor defenders. Seasteads are easier to destroy than build, but an average person’s keys are secure enough to resist even state-level actors.

Proof of Work security can only come from block rewards, and incentives to miners can only come from the risk of losing future block rewards. That is to say, Proof of Work necessarily operates on a logic of massive power incentivized into existence by massive rewards. This is effective, but inefficient. The cost of attack and the cost of defense are at a 1:1 ratio, so there is no defender’s advantage.

Of course, the wise design of penalties can be its own reward.

Consider Amazon's algorithm and how they solved unbounded search by turning everything into a platform, only to find that advertising is intractable to platform solutions. This is because the limited number of top spots on infinite-length shelves, and the crazy amounts of revenue they generate, create a conflict of interest between Amazon and its users. This kind of conflict can only be solved with a protocol, not a platform. However, Proof of Work protocols still have a similar conflict of interests between miners and users. Miners must pay for the massive power they are incentivized to use in securing a Proof of Work network, which creates both (i) consistent forced sellers in any market (miners must sell some amount of the tokens they earn as rewards in order to pay for hardware and power costs) and (ii) skewed incentives around, for instance, block sizes which lead to suboptimal outcomes for users of the network.

Proof of Stake ensures that anyone, even with entry-level hardware and a relatively small amount of ETH, can act as a validator and that the protocol relies on penalties rather than rewards. This means that users and validators are more likely to be the same people, thus reducing conflict. Just as protocols which define and encode what it means to cheat do not need to be trusted, protocols which define and encode penalties are more likely to benefit all their users than protocols which rely on rewards. This is because encoding rewards creates inevitably skewed incentives that only accrue to the subset of network participants who are best placed to game the system.

Proving Stake¶

Ethereum 2.0 uses a slashing mechanism where a validator that is detected to have misbehaved can be penalized: in the best case by only about 1%, but in the worst case by up to its entire security deposit. This raises the cost of an attack such that we achieve the defender's advantage described above without creating an incentive for validators to validate each transaction without checking it fully (as this is less expensive computationally).

In the Ethereum 2.0 Design Rationale, Vitalik describes why "Casper the Friendly Finality Gadget" was chosen - it was the simplest Proof of Stake consensus algorithm available at the time - and how other options continue to be explored. He highlights the problem of "supernodes" and why sharding is better: less centralization risk, more censorship resistance, and better long-term scalability. Critically, he then considers the security models of any system we choose, and how it operates not just under the "honest majority" model (where 51% of the validators are assumed to be trustworthy), but also the "uncoordinated rational majority" and "worst-case" models. Assuming the worst case, the question remains:

• Can we force an attacker to have to pay a very high cost to break the chain’s guarantees?
• What guarantees can we unconditionally preserve?

Slashing ensures the first condition, and Vitalik provides a detailed table of the guarantees we can preserve with Proof of Stake systems in this section. In a system designed around penalties, you need to distinguish between various types of validator failure - most of which are benign (like simply being offline) - and only a few of which are genuinely malicious. Critically, it is the trade-off between different penalties which informs how we structure rewards.

Aligning Incentives¶

In Ethereum 2.0, validators must attest to what they believe to be the head of the chain in each epoch, i.e. approximately every 6.5 minutes. If they do so, they earn a base reward, which is split into 5 parts described here. Rather than detailing all of these, we’ll focus here on two critical features of the reward: how it prevents "griefing", and how it is calculated.

Rewards are designed this way only as a result of thinking about how to penalize different kinds of undesirable validator behaviour. Now that we understand this premise, we can check that the rewards fit our requirements by considering the break-even uptime for any validator. It turns out that if everyone else is validating, you need only be online ~44.44% of the time. However, if other validators are offline - say P = 2/3 - then you need to be online ~53.6% of the time.

The incentives ensure that, as more validators go offline, the penalty for doing so is greater, which creates something Vitalik calls an inactivity leak. If the chain fails to finalize for more than 4 epochs, a second penalty component is added which increases quadratically over time. This:

• Penalizes being offline much more heavily in the case where you being offline is actually preventing blocks from being finalized and
• Ensures that if more than 1/3 do go offline, eventually the portion online goes back up to 2/3 because of the declining deposits of the offline validators.

All of this means that we can handle elegantly the penalties for common and benign kinds of validator failures. But what about actual attacks and/or malicious behaviour? If a validator is caught violating the Casper FFG slashing condition, they get penalized by a portion of their deposit equal to three times the portion of validators that were penalized around the same time. The reasoning behind this is:

• A validator misbehaving is only really bad for the network if they misbehave at the same time as many other validators, so it makes sense to punish them more in that case.
• It heavily penalizes actual attacks, but applies very light penalties to single isolated failures that are likely to be honest mistakes.
• It ensures that single validators take on less risk than larger services (in the normal case, a service running several validators would be the only one failing at the same time as themselves).
• It creates a disincentive against everyone joining one single validator pool.

Technicalities¶

Vitalik then discusses some of the technical choices favored in the design, like BLS signatures (which are easy to aggregate) and SSZ (a simpler serialization suite which aligns with the principle of simplicity). If you're interested, we recommend going directly to the Rationale for these details. This twitter thread does an excellent job of providing an overview of the development of Ethereum 2.0 consensus and the associated research if you want more history and detail than can be found in the Design Rationale itself.

The Positive Sum¶

What is Ethereum 2.0? Well, we said it already: our generation's elder game of economic penalties. These penalties are the game mechanics we use to reveal a unique kind of truth: it is possible to build - and asymmetrically defend and maintain - an explicitly prosocial, global, and ownerless system that provably benefits all the people who choose to use it. The benefits of encoding penalties extend to all layers of this game, including our ability to use coordination costs to our advantage.

Welcome. Most of us are friends here. The alternatives are more expensive.

Further resources¶

These few links are intended for those who wish to understand more technicalities and begin developing on, or building tools for, Ethereum 2.0.