The Ethereum 2.0 Annotated Specification


  • Phase 0: The beacon chain
  • Phase 1: Shard chains
  • Phase 2: Execution environments
  • SSZ: Simple serialize


Welcome to my project to annotate the Ethereum 2.0 specifications! As the specs have developed and become formalised over time, a lot of the intuition, rationale, explanation and insight has been taken out. This is my attempt to put this back in before it's lost forever.

There are several sources for my comments. First is simply having followed, chronicled, and occasionally participated in the building of Eth2 over a long period. Part of my day job has been working with PegaSys on our Java Eth2 client, now called Teku. Another important source of info is GitHub archaeology (love that "blame" button!). Finally, for stuff that I couldn't figure out by myself, Danny Ryan has been a very patient answerer of questions 🙏

This project is going to take a while. Currently I'm still working through the beacon chain specification for Phase 0, which is the very first part. Check back for regular updates.

When I occasionally refer to "we" or "us" in the comments, I am talking about the wonderful Teku/Artemis Eth2 client development team in PegaSys that first assembled in November 2018 and continues to go from strength to strength.

Ben Edgington

Design goals

The following are the broad design goals for Ethereum 2.0:

  • to minimize complexity, even at the cost of some losses in efficiency
  • to remain live through major network partitions and when very large portions of nodes go offline
  • to select all components such that they are either quantum secure or can be easily swapped out for quantum secure counterparts when available
  • to utilize crypto and design techniques that allow for a large participation of validators in total and per unit time
  • to allow for a typical consumer laptop with O(C) resources to process/validate O(1) shards (including any system level validation such as the beacon chain)

These design goals are taken directly from the front page of the spec repo. There is a slightly different, but completely compatible set of design principles in Vitalik's Serenity Design Rationale.

I've written at length about these goals elsewhere, so I won't repeat myself here.