What’s New in Eth2 - 1 October 2018[1]

Ben Edgington[2] - Latest Editions

This will not be the most interesting read of your life, but it may be useful. It’s just my notes consolidating and tracking spec updates, research progress, design decisions and other interesting discussions from the previous 7 days in the rapidly moving world of Ethereum 2.0. I’m not tracking individual client implementation progress, and I’m only covering things that I think are particularly interesting or useful. Sorry if I missed your thing. I’m aiming to push this out once a week.

The Headlines

  1. Strong progress towards hardware VDF implementation for unbiasable random number generation.
  2. Libp2p will very likely form part of Ethereum 2.0, so is worth implementing in clients now.
  3. Casper proof-of-stake remains a work in progress and updates and changes continue.
  4. Who’d have thought data serialisation was so tricky?
  5. Only minor spec updates during the last week.

Specification updates

The canonical home for the spec has been moved from here to Github to allow for better tracking of updates, although both seem to be up to date.

  • Some numerical factors, variable names and calculations were changed in the rewards calculation.
  • The quadratic penalty quotient formula (the deposit leak for being offline) was fixed.
  • Appendix added with definition of the Blake2 hash function.
  • Bugfix in get_new_shuffling().
  • Definition of an integer square root function, int_sqrt(n), to ensure that all client implementations agree.

Implementers’ call

Notes are up!

Research updates

Looking at changing the fork-choice rule from immediate message driven to latest message driven. See below under Ethresear.ch. Still under analysis.

Possible launch phase for the sharded network: A phase 0 in which every validator validates everything, with very low limits on shard-size.

Work is ongoing on how to efficiently aggregate message attestations, such as a two-layer approach in which the shard networks each aggregate their attestations before broadcasting to the main network.

Lots of news on VDF hardware implementation (more below). Justin’s confidence in the viability of the solution is increasing: now at 75%. Looking at putting together a CPU-only VDF test net by early 2019.

  • The initial Beacon Chain can work with just a RANDAO; the VDF can come later to improve security analysis and provide high-quality randomness to higher layers.

libp2p

My former colleague, Raul Kripalani, joined to present Protocol Labs’ work on a libp2p daemon. This would take care of the low-level libp2p protocol and present a language agnostic higher-level interface via Unix domain sockets. General consensus seems to be that libp2p will certainly be playing some sort of role in Eth2.0 and it’s worth progressing with implementations.

Data serialisation format

Things had been converging on Simple Serialize as an alternative to RLP throughout Ethereum 2.0. However, Alexey Akhunov suggested having different serialisations for the wire protocol and the data hashing protocol. No conclusions!

Ice age?

Ethereum 1.0 has an “ice-age” or “difficulty bomb” that periodically needs a hard fork to reset to prevent the network grinding to a halt. This is intended to “normalise” hard forks and thus allow the opportunity for innovation.

Jacek Sieka (Status) suggested an analogous mechanism in Eth 2.0 to provide a safety net in case it doesn’t work out: if there were no hard-fork to reset it, everyone’s stakes would be refunded on the Eth 1.0 PoW chain. Opinion is divided on this.

Gitter

  • Discussion on whether a re-org on the Ethereum 1.0 PoW chain should trigger a re-org on the Beacon Chain. Seem to be moving away from that idea in favour of just having a long delay before the Beacon Chain trusts PoW chain blocks. Debate about how long a delay is desirable.
  • A clarification that helped me: “the validators that are on a shard (building the shard chain) is independent of the committee that is crosslinking that shard chain into the beacon chain at any given time”.
  • Introduction of possible two-layer network aggregation scheme for attestations. See also the Implementers’ call.
  • Reminder from Hsiao-Wei that the Ethereum Foundation is looking to award grants for BLS12-381 implementations in new languages, leading to discussion of test vectors, signature serialisation and benchmarks.
  • Integer square root discussion.

Ethresear.ch

Randomness

Minimal VDF randomness beacon. Justin Drake lays out a rationale and outline design for using a hardware-based implementation of a verifiable delay function for unbiasable random number generation. This randomness is important both at the protocol level (e.g. selecting committees of validators) and for use by Dapps.

There is some interesting discussion around the “liveness” vs. “safety” aspects of Ethereum 2.0’s design. I hadn’t appreciated until hearing Danny Ryan’s excellent Bitcoin Podcast recently that a design goal of Ethereum is to keep running even if 80-90% of nodes go off-line (the WW3 scenario). Justin goes so far as to say in the comments,

It is natural for general-purpose consensus protocols to favour liveness. (In that sense, Dfinity got it “wrong”.).

Proof-of-stake/Casper

Vitalik identifies a possible issue with the Casper IMD (intermediate message driven) fork choice rule and proposes LMD (latest message driven)[3] GHOST as the resolution. Perhaps a hybrid version will be best.

A tight and intuitive Casper slashing condition A potential simplification of the Casper slashing conditions from the original four, via Vitalik’s two, to a single condition.

An interesting discussion on changing Casper’s “no-surround” rule to a “no-reneging” rule which kind of converges with the above discussion in the end.

A recent paper, Formal Barriers to Longest-Chain Proof-of-Stake Protocols, has caused a bit of a stir. There’s a long-form response from Vitalik, and tweet-form: Casper FFG and CBC are both immune to this.

In other news...

Older than a week, but well worth noting: Danny Ryan’s Bitcoin Podcast is extremely helpful in unpacking some of the rationale behind Ethereum 2.0 and its design goals. At 1.4x speed it isn’t that long :-) Time well spent.

I will be speaking about Ethereum 2.0 in October:

Main sources:

[1] Ethereum 2.0 is a planned upgrade to the existing Ethereum protocol, introducing proof-of-stake and scalability via sharding among other things. It is a work-in-progress, decentralised, distributed R&D programme, and things can change rapidly. Some background.

[2] PegaSys, ConsenSys

[3] Who can keep up with the Casper TLAs?