Ben Edgington (PegaSys, ConsenSys — but views expressed are all my own)Edition 19. Archive. Trouble viewing? Load original.
Ben Edgington (PegaSys, ConsenSys — but views expressed are all my own)
Loyal readers, please accept my apologies for the lack of news the last month. It's not that nothing has been happening - far from it. I've simply been focused on writing code and attending EthCC, sometimes simultaneously.
It's very difficult to jump back on board the express train that is Ethereum 2.0! So, instead of the usual commit-by-commit summary, I thought I'd do a more long-form, zoomed out review of what's occurring. It is in no way comprehensive, just some things that caught my attention over the last couple of weeks. Sorry if I missed your thing.
Thankfully, the move to versioned releases of the spec at the start of February, along with 🎉 change logs 🎉 has largely made redundant the tracking I was previously doing. It has been an enormous help to us as client developers to have stable versions to target while planning and tracking work, and has made it much easier to keep up with what's changed.
Version 0.5 of the spec has just been released. The planned regular cadence of weekly releases during February was kept nicely, and, as expected, the pace is now slowing.
What are the significant changes since 0.2, which I covered in the last edition?
It is now possible to transfer staking balances between validator accounts (once a validator has stopped validating). This is a temporary measure until Phase 2, after which balances can be withdrawn to shards and transferred there. Until that time, if I make a 32 Ether stake, it is locked within the beacon chain system. Previously there was no way for me to recover my investment, except perhaps to sell my validator private key to somebody, which introduces risks a buyer may not be prepared to take. (Danny explained recently why Ether transfers to the beacon chain are one-way only for now.) With this change, I will be able to sell my Beacon Ether balance to another validator, presumably at some discount to the prevailing Ether price due to the lock-up and risks. Nonetheless, I can exit with funds if I really need to. This is a nice feature that will hopefully encourage more participants to feel comfortable committing to staking. Note that there is some potentially unexpected behaviour to be aware of.
Speaking of unexpected behaviour, the spec has been clarified to state that we will be using Unix time for the beacon nodes. This means that leap seconds may occasionally cause slots to be one second longer or shorter than normal. (Reading the Wikipedia page, I had no idea that leap seconds were so controversial... oops, digression!) There was some useful discussion of this on this week's call (links to start of conversation).
The Great Integer Debate has been "resolved" simply by rebasing the Genesis slot number to 2^32. Imho this is just a perverse way to reintroduce a sign bit: it's now at bit 32 rather than 63, and has the opposite meaning to usual 😐. Perhaps you can tell that I'm a bit disappointed with this: I think we missed an opportunity to put strong bounds on all quantities (not just slot numbers, but validator numbers and balances too) and define rigorous overflow/underflow behaviour that is easily implementable by all clients. I expect this lack of rigour to bite us later in the form of consensus failures due to malicious blocks/attestations.
In more interesting news, a lot of work has been done to make the spec "executable". Things like converting the prose descriptions in epoch processing into Python code. For more on this and rationale, see the implementation section below.
Other recent updates are manifold, but are relatively minor and technical in nature, or straightforward bug fixes, and can be reviewed in the release notes.
There remain a few things to do on the Phase 0 specification. A meta-list of tasks remaining is being maintained on the GitHub. See there for links to info about changing the hash function to SHA256, and standardising the BLS implementation among other things. According to Justin on this week's call, these ought to be complete by v0.6 of the spec.
The Phase 1 specification has come on enormously since I last took a look. It claims to be fundamentally feature-complete
now, and the checklist of remaining tasks for phase 1 is mostly about review and optimisation.
Justin spoke about a nice simplification to the proof of custody game
on this week's implementers' call. This leads to a dramatic reduction in the specification complexity and less communication between clients.
Focus at the moment is on finishing Phase 0 and Phase 1 specifications and implementations. But substantial work continues in the background on Phase 2, in which state (accounts and contracts) are added, and execution engines, along with cross-shard transactions and all that good stuff.
Vitalik has posted a very useful summary of the current state of the art and open questions. I'd really urge you to get involved if any of this interests you!
There are new BLS test vectors available which fix some issues with the serialisation. They all run sweetly against our implementation and should be hitting the official test repo soon.
However, there are plans afoot to standardise BLS implementations across blockchains which may affect what we do (afaics it basically just affects the serialisation/compression format for us). Check out the IETF draft from Dan Boneh et al. for the details.
A big simplification of the SSZ spec has been made. It's now very concise. It seems to be mostly just a rewrite, but there are a few implementation changes.
The hash_tree_root() function is now used everywhere that merkleisation is required in the main spec.
One of the design goals of the Eth2 beacon chain is light-client friendliness
, not least because it is no longer expected that nodes have access to the whole state at all times, but also to support mobile devices and cross-chain bridges.
Vitalik has made substantial progress with specifying light client implementation. He has a pull request to add new two specification documents. First, a Merkle proof implementation, which describes what seems to be a novel "Merkle multi-path" technique. Second, a syncing protocol for light clients.
Beacon node implementations are making rapid progress. Artemis is happily processing blocks in our mock network. We've also been putting a nice shiny front-end on it that other clients should be able to use when done. You can see a pretty call graph too. Parity is working on a testnet of their implementation. Harmony has a simulator. I'm loving the Twitter updates from Jacek, and this one, what does a Beacon node actually do? Status is also exploring scale. But not as much scale yet as Lighthouse, who have run benchmarks with 4 million validators. And so on 😁 — you can consult the various individual client updates for proper updates.
One excellent development is the specification checker. This takes the markdown version of the specification, extracts the constants, structures and functions and runs the whole thing to generate test vectors, after doing some sanity checks. This is brilliant, and could be huge for debugging 🔥 On a very quick scan, the output looks like the newly proposed state transition test format. There are some explanatory notes for this.
In a similar vein, Justin Drake challenged devs to implement the state transition in under 1024 lines of Go code. Predictably, this was won by @protolambda with this implementation.
Matthew Slipper of Kyokan has been leading the work of specifying the wire protocol by which clients will discover each other and communicate. I'm happy to see that discussion on this is quite active as the performance of the peer-to-peer network will strongly impact the overall success or failure of Ethereum 2.0 as a project. Meanwhile, Whiteblock is working on a quick-and-dirty wire protocol implementation designed to facilitate test networks while the finer details are being thrashed out. There is a discussion forum for this. One way or another, it won't be long before clients are talking to each other 😃
In related news, serialisation formats continue to be our favourite thing to argue about. This is a good thread if you enjoy rabbit holes. Piper's summary analysis is excellent.
Now that implementations are converging on complete, a lot of the conversation is around optimising performance. At some point I'll see if I can gather up some of the threads on this; there are a lot of good ideas around. For now, I'll just highlight this solid Gitter thread on tips for walking the block tree, and optimisation tips arising from Sigma Prime/Lighthouse's benchmarking. It was interesting to note Vitalik's resistance on this week's call to benchmarking on high-performance hardware: it is fundamental to the Ethereum 2.0 vision that people are able to participate with reasonable cost, commodity hardware.
The canonical shared test repo has been updated with the beginnings of new state transition tests, along with revised shuffling tests. I'm guessing that the state-tests we generated directly from the specification using the spec_pythonizer tool mentioned above. This is extremely cool. Revised BLS tests are coming soon.
There was a call on March 14th with this agenda, and video here. As usual, we ran out of time, wire protocol things taking the lion's share of the discussion.
A couple of new articles on EthResear.ch.
Justin describes a Bitwise XOR custody scheme for drastic simplification to the proof-of-custody game. Presumably, this what he was was referring to on this week's implementers' call.
My PegaSys colleagues have been thinking about validator self-selection. By total coincidence, this was published on the same day that Protocol Labs requested proposals for such a scheme. This kind of mechanism could be important for validator privacy in Ethereum 2.0.
Planning is underway for an Ethereum 2.0 work day just ahead of EDCON in Sydney. We'll be meeting up on April 9th, during the pre-event hackathon. Info and sign-up sheet here. I'll likely go nocturnal and join remotely, myself.
There wasn't a huge amount of specific Ethereum 2.0 stuff at EthCC in Paris last week. Justin presented a fairly detailed technical walk-through of the beacon chain data structures (video and slides). Mamy of Status gave a talk on testing and simulation, starting with an overview of where we are (video and slides). Eth2 popped up in a few other talks, such as GregTheGreek's, and more controversially in Rick Dudley's, but dedicated Eth2 presentations were few and far between. You can read about why I'm a bit sheepish about this.
Danny has mentioned on the Gitter a forthcoming academic paper on the Ethereum 2.0 Casper implementation. This is very welcome!
The whole economics of being a validator question remains a hot topic. Collin Myers of ConsenSys has published a follow-up to his first analysis on this: Validator Economics of Ethereum 2.0 — Part 2... The Ether Vacuum. In addition, Delphi Digital published a very thorough report on Ethereum's short- and long-term cryptoeconomics, with a tweet-form summary. I haven't digested all of this yet, but it looks like an excellent piece of work on first glance.
Trenton Van Epps has made a nice summary of Danny Ryan's recent excellent ZeroKnowledge podcast. Tom Shaughnessy of the aforementioned Delphi Digital did a Tweet-storm summary of Lane and Preston's talk on Ethereum 1.x and 2.0 for the CoinFund Rabbithole Talks (video and slides).
That's all folks! I'm going to think about doing a general review for a wider audience of where we are in Ethereum 2.0 over the next couple of weeks, so look out for that. Or I might write some code 🤷♂️.
![[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.