Ben Edgington (PegaSys, ConsenSys — but views expressed are all my own)Edition 21. Archive. Trouble viewing? Load original.
Ben Edgington (PegaSys, ConsenSys — but views expressed are all my own)
I know y'all are burnt out from the deluge of Libra tweets the last few days, so here's a bit of balm for the Spirit: A Libra-free safe space where we'll review some of the latest Ethereum 2.0 developments. Forgive me, it's been three months since my last confession.
This will not be comprehensive, there's simply too much going on these days. I'll just take the various snippets I've accumulated over the last weeks and try to organise them into something a little bit coherent.
Let's begin with a development update. It is well known that the delivery of Ethereum 2.0 is planned to be in three distinct phases. The main excitement recently has been in Phase 0 (nearing interoperability of beacon chain clients) and Phase 2 (the beginnings of a model for computation in Ethereum 2.0).
The beacon chain is the co-ordination layer for the whole Ethereum 2.0 system, and likely the most challenging part to deliver. For background, see my beacon chain explainer article.
It was in June last year that the beacon chain was conceived as the future of Ethereum 2.0. Just one year later the phase 0 specification is about to be frozen on June 30th. A brand new blockchain design, with an unprecedented scale of ambition that frankly dwarfs Libra's1, incorporating dozens of significant innovations and insights, with eight client implementations just about ready to go: this is an astonishing community achievement in a single year. Anyone not impressed by this lives in a different universe to mine.
Now that spec update releases are very well tracked and documented I'm not going to go into all the details as I did in previous editions. We're sticking to the big picture today.
With the phase 0 spec nearing stable, the focus now moves on to interoperability between the various Ethereum 2.0 client implementations. There remain eight active teams keeping up with the latest specification. Once the network is live, each of these clients will need to talk to the others to come to agreement about the state of the beacon chain. Each client needs to follow the rules identically: a single incorrect bit results in consensus failure.
With this in mind, we held a workshop in at the excellent Bushwick Generator in Brooklyn, "The Road to Interop". I took a few not very good photos, and for the really keen, there are four hours of video. We more or less followed the agenda here. This was an opportunity to get several of the implementation teams together to plan how we will get our clients to talk coherently to one another. Vitalik kind of hijacked the afternoon with a presentation on his thoughts around Phase 2 (see below). Terence has posted slides from his talk on the architecture and design of the Prysm client.
The next significant planned event is an "Interop Lock-in" around the start of September. The implementation teams will retreat to a remote cabin somewhere in Ontario for the week, only emerging when we have confirmed that all the clients are playing nicely together. Or we've all shot each other.
Jonny Rhea has documented the proposed route to interoperability. (Phew, no firearms involved 😌.)
The ultimate goal is for libp2p to be the peer-to-peer communications protocol underlying the Ethereum 2.0 network. However, as a simplifying step en route to that goal, clients are all implementing the much simpler Hobbits protocol, which Trenton van Epps has written up very nicely. Jonny gave a tweet-form rationale for Hobbits, and posted some bounties to enable each of the teams to get it integrated, courtesy of ConsenSys.
Meanwhile, Whiteblock did some performance testing on libp2p, which Daniel Choi presented at Scaling Ethereum. Their findings raised some questions about the performance of libp2p under some circumstances. However, working with Protocol Labs, some further testing will be done to explore more realistic parameter ranges relevant to Ethereum 2.0.
Another interesting development is the publication of Handel by the PegaSys R&D team: Practical Multi-Signature Aggregation for Large Byzantine Committees. This protocol could dramatically speed up the collection of attestations from validators in Ethereum 2.0, allowing for much larger committee sizes, and potentially, therefore, much faster finality for transactions. This is attractive and we'll be exploring it further.
A huge amount of work is going on in testing at this stage of development. Worth noting is Antoine Toulme's work on the test runner, funded by Moloch DAO, here's a recent progress update, which is well worth a look by client devs.
It's extremely cool that the specification is executable, and all the cross-client test vectors can be generated directly from the written specification. There's also a bunch of work going on to fuzz-test the specification and provide a framework for fuzz-testing the clients, as reflected in the name of the latest release.
Runtime Verification has written up their audit report of the Ethereum 2.0 deposit contract incremental Merkle tree implementation, which is written in Vyper (rather than Solidity). This is a great milestone and paves the way for the deployment of the deposit contract onto the current Ethereum 1.0 chain. For an easier read, our very own Joe Delong has written an explainer and an implementation of the Ethereum 2.0 deposit Merkle tree. Sparse Merkle trees are cool!
Runtime Verification is also going to be making a formal executable specification of the beacon chain in K.
On last week's Eth2 implementers' call, Justin proposed two target dates for deployment stages of the beacon chain:
The genesis event depends on a couple of prerequisites. First, sufficient Eth must be staked in the deposit contract. There used to be a hard target of just over 2 million Ether for this, but this has been removed. However, the target will be something of that order to allow the beacon chain to be started safely.
The second prerequisite is target 3/minimum 2 "production ready" beacon chain clients and validators. There is a great deal of compatibility, optimisation, testing, auditing, hardening, productising, tooling, documenting, and packaging work to be done for all the clients before then, so I'd treat the January 3rd target as somewhat, er, aspirational.
The spec for phase 1 has been a nice oasis of Serenity recently.
It's fair to say that, only a couple of months ago, phase 2 of the Ethereum 2.0 delivery was a dense fog. Phase 2 is the so-called "execution layer" that makes the blockchain useful. It provides for balance transfers, smart contracts and all the good stuff that allows for dapps to be built. But, as recently as the start of April, we had no clear view on what this might look like. Casey Detrio gave a great presentation on the history and status of Phase 2 at the Scaling Ethereum day which is well worth five minutes of your time: Entering 2019... all questions remained open, the design space was still huge, the possibilities were endless, we didn't know where to start.
To break the impasse, Casey posted a provocative proposal on Ethresear.ch, Phase One and Done: eth2 as a data availability engine. Without going into all the details, this unleashed a flood of innovation, and phase 2 has rapidly and thrillingly begun to come into focus.
Vitalik quietly published an initial proposal and a followup, responding to Casey's suggestion. Will Villaneuva from the newly formed ConsenSys Eth2 Phase 2 team (known as Quilt) wrote an explainer to unpack the ideas. Matt Garnett, also of Quilt, wrote up what this might look like concretely. At the Interop day in NYC, Vitalik presented all the latest thinking (video here, but audio is poor), and subsequently with more background at the Scaling Ethereum event in Toronto (video here, followed by presentations on same topic from Will, and then Casey and Alex Beregszaszi).
The gist of the proposal is to minimise the role of the blockchain in executing transactions. In Ethereum 1.0, there is only one way that transactions are executed, which is via the EVM. After executing a block of transactions, the Merkle root of the resulting state is written into the block. In order to run the EVM on the transactions in the block, all the nodes need to store the state (account balances, contract storage, etc.) of the whole blockchain.
The current phase 2 proposal takes this model and generalises it. There can now be several, even many, types of EVM (called execution environments, EEs). An EE is code written in eWASM that runs as an (almost) pure function. This means that an EE does not store any state itself: anything it needs to know has to be provided to it along with the transaction. So, for example, if I want to transfer a token to you, then along with the transaction I need to provide a proof (such as a Merkle branch) of my balance of that token; the EE has no independent idea what my balance is since it does not store anything. Actually, this is not quite true: each EE will store a single 32 byte value that is some sort of digest or accumulator of its current world state (maybe a Merkle root, but this is not prescribed, it could be anything sufficiently secure).
Abstracting out the execution layer in this way allows for the ultimate in flexibility. There could be EEs for zk-Rollups, or ERC20-like tokens, or enterprise-friendly environments, or Plasma, or smart contracts written in Haskell if you like all that lazy functional goodness, or that mimic Libra's Move VM2, or even an EE that runs the EVM, allowing for a near seamless transfer from Eth1 to Eth2. Each EE could have its own replay-protection, or signing scheme, or permissioning requirements: abstraction is power.
The idea is that, for a reasonably large fee (~100s of Eth?), anyone could deploy their own EE to support their own specialised blockchain environment. The Ethereum 2.0 shard chains just focus on the fundamentals: transaction ordering and data availability.
A few questions remain under active discussion: whether to support synchronous calls between EEs, details of how blocks will be assembled and gas fees charged, whether EEs will be permanent or need to have some storage fee payment, what EEs will initially be deployed with Ethereum 2.0 and so on. But this unquestionably seems to me to be the right direction to go in.
If you want to get more into the weeds on all this, you can check out Casey and Alex's Scout repo where they are doing some prototyping of what it could look like, and their Phase 2 execution prototyping engine Ethresear.ch post.
All this might sound rather abstract and alien to those of us more familiar with the concreteness of current EVM execution. Not to worry, accommodating a smooth transition path between Eth1 and Eth2 has become a priority now that there are some interesting ideas around ways to do this effectively. Though some challenges remain, with discussion continuing on Ethresear.ch.
Here are some random bits and pieces I've collected over the last month or so:
Whew - that was long! If you made it this far, treat yourself to some tabs vs spaces 😂 (H/t the great Evan Van Ness - dude, I have no idea how you manage to do this every bloody week. You are a legend.)
[1] I mentioned it once, but I think I got away with it.
(To my global audience: this one's for connoisseurs of 1970s British humour.)
[2] Oops! I did it again.
(Hey, Britney fans!!)
![[Twitter]](img/twitter.svg){kind=small}
![[Peepeth]](img/peepeth.svg){kind=small}
Follow me on Twitter and/or Peepeth to hear when the next edition is out 🙌.
![[RSS]](img/rss.svg){kind=small}
New: We have an RSS feed.