What's New in Eth2 - 26 November 2018
Edition 8. Archive. Trouble viewing? Load original.
Ben Edgington (PegaSys, ConsenSys — but views expressed are all my own)
The No More TODO Edition
Tl;dr — a couple of big rocks have been put in place this week: the elliptic curve for BLS signatures has been specified, and the fork choice rule has been explicitly documented. Slot duration has been reduced to 6 seconds, and there's no more TODO (but only because the "to do" list is now maintained separately in GitHub issues).
Thank you so much to Chih Cheng Liang who made a lovely archive on the Ethereum.org server for these posts to live in 😍.
Any mistakes/typos/omissions in this edition are due to me trying to watch the world chess championships while preparing it. Sorry!
Specification updates
General
Reminder: take a look at the open issues marked RFC and get involved. Currently up for discussion:
Beacon chain specification
- There has been another stealthy update to
SLOT_DURATION. A while ago, the beacon chain block interval (slot duration) was increased from 8 to 16 seconds. It's now been reduced to 6 seconds. This presumably reflects some optimism about the efficiency of BLS signature aggregation. It will likely be tuned as implementations get tested.
- The differing roles of proposer and attester are being clarified. Proposers can be slashed if they are proven to have signed two different proposals for the same slot.
- Speaking of slashing, there is now a mechanism for rewarding those reporting bad behaviour of attesters or proposers: the current proposer receives 1/512 of the offender's deposit. Thus, one of the duties of proposers is to check for bad behaviour by others. This is nice: since only the current proposer receives the reward, it side-steps the usual problem of fault-proofs being front-run by miners.
- The elliptic curve for BLS signature aggregation has been specified as BLS12-381 (it was previously alt_bn255). It is the same curve that ZCash is now using, and was proposed back in May. [Today's fun fact: the team behind BLS signatures (Boneh, Lynn, Shacham) is, mostly, different from the team behind the BLS curves (Barreto, Lynn, Scott).]
- In addition, a
domain parameter has been added to signatures according to whether they are signatures related to beacon chain deposits, attestations, proposals or logout, or operating in shards. This parameter is also dual-purposed to distinguish activity on (planned) network forks. There's a draft spec showing how all this could be implemented.
- The beacon chain fork choice rule has now been properly specified: it is LMD GHOST. This is a significant step forward — the fork choice was one of the big gaps in previous versions.
I previously missed this as it lurks under the innocuous title "Miscellaneous beacon chain changes". There's lots of good discussion in there about possible beacon chain protocol changes.
Finally, the "TODO" list has been removed. Not because everything has been done, I guess, although much of it has. We also lose the completion estimate (was 65% before recent changes).
Shard chains specification
- Vitalik is very pleased with this commit that simplifies shard block handling by fixing the block size at 16KBytes. By comparison, the current PoW Mainnet block size is generally between 15 and 30KB; shards will produce blocks more than twice as rapidly, so a single shard's capacity ought to exceed current Mainnet capacity by a factor of at least two (all else being equal). Again, I expect this parameter to be tuned-up as implementations begin to get tested.
Simple Serialize
- The SSZ spec is explicitly now CC0 (Creative Commons).
- There have been some simplifications to the Merkle hash algorithm introduced last week. Recall that this algorithm takes a list of data items (of the same type) such as hashes and calculates a Merkle tree root hash for them. Each hash in the list could be the hash of a much larger blob of data. The eficiency comes from not having to recalculate a hash if its data blob has not changed. This is potentially much better than serialising the whole state and hashing across all of it every time.
Implementers' call
No call last week. Notes from the 15 November call are available.
Gitter
Most of the last week's noise has been on the All Core Devs Gitter 🙄.
Highlight of the week on the Sharding Gitter (no, the name can't be changed): an excellent clarifying conversation between Jacek and Danny on the work of proposers, and the sizes of committees.
Ethresear.ch
Not on Ethresear.ch, but a research theme nonetheless: my PegaSys colleagues have done some simulations of Sybil attacks on the p2p network with interesting conclusions:
tl;dr: Sybil attacks at the p2p layer are possible on ethv2/sharding. There are multiple ways to mitigate their effects. This post is just there to raise awareness on this subject as a part of the p2p discussions/choices.
Now, from Ethresear.ch:
In other news...
- If you haven't seen it yet, watch it immediately: A Blockchain Holiday Dinner! 😂 Equally applicable to Christmas (or insert appropriate local celebration here).
- Vitalik discusses where the 32 Eth number for staking comes from and other topics around Ethereum 2.0 design.
- The series of Ethereum 2.0 explainers from Status now includes an article on the beacon chain. It nicely complements my blog post from a few weeks ago.
Main sources:
Follow me on Twitter to be notified of updates.