What's New in Eth2 - 25 October 2019

Edition 28. Archive. Trouble viewing? Load original.

Ben Edgington (PegaSys, ConsenSys — but views expressed are all my own)

The Composability Edition

Top picks for this time:

• Danny Ryan has posted an eth2 quick update on the ethereum.org blog. Go and read it now.
• Hsiao-Wei has given the Ethereum 2.0 (Serenity) Devs Handbook a major, much needed, update 🎉. Check it out: it's excellent! (See also my own eth2.info.)
• Tom Shaughnessy interviews Vitalik on the new Phase 1 sharding proposals.

Phase 0: The Beacon Chain implementation

Spec updates

Version 0.8.4 was released this week. There are no changes to the core spec.

A more substantial update, 0.9, is expected soon. (Yes, an update to the frozen spec. But we always said we would unfreeze it after the initial round of interop testing.) This will fundamentally be a simplification: taking out for now the hooks for Phase 1 (such as shards and crosslinks, and transfers) while it is still subject to change (see below). On reflection, we should have been a bit more ruthless about YAGNI.

Note that the SSZ specification will be moved out to a new repo where it can be change-controlled more effectively.

Testing

Runtime Verification's implementation of the beacon chain spec in the K framework is complete, and is proving useful by suggesting extra test cases to improve code coverage.

Protolambda is teasing us with previews of his Muskoka test harness for Eth2 clients. It's named after the area in Ontario where we did the Interop retreat.

Sigma Prime is working on a differential fuzzing environment for Eth2 clients. See the dev call meeting notes for more info. They will be contacting each team in the next weeks to get their clients onboarded onto the platform.

The 0.9 spec update has slightly delayed putting up longer lived, multi-client testnets. We'll be making more concrete plans on the next devs call. Meanwhile, the Prysm team is hopeful that one or two other clients may soon be able to sync their testnet.

Other news

Just a reminder about the deployment of the validator staking contract. As per Danny's blog post above, deployment of the contract has been held back pending standardisation of the BLS signature scheme: we could deploy today, but BLS standardisation is worth waiting for. This is unlikely to delay go-live of the beacon chain. On BLS standardisation, Justin informed us on the devs' call that there will be a meeting in November at which the new spec is expected to be signed-off. Meanwhile, there have been some recent updates to work around a patent, among other things.

Finally for Phase 0, I like this comment from Cayman on the Eth2 development process. I've written about this too.

Phase 1: Sharding implementation

One of the big takeaways from DevCon is that a rework of Eth2's sharding model is in the pipeline. Vitalik both published a proposal and hosted a workshop on the changes.

The basic idea is that it would be a huge benefit to crosslink shard blocks at every slot to the beacon chain, rather than once per epoch (64 slots) as in the current design. In this way, cross-shard transactions can occur with only a one slot latency (a few seconds). This does away with a lot of complexity at higher layers aimed at hiding the current high cross-shard latencies. The new design resembles Near Protocol's in some respects.

Unfortunately, cross-linking 1024 shards every slot would place too much load on the beacon chain. Instead, the plan is to reduce the shard count to 64 (initially), while increasing the shard block size by a factor of eight. Overall this gives half the data throughput of the current design, but is still around 1000x the capacity of Eth1. There may also be tweaks to epoch lengths and slot times. This remains a work in progress, but seems to be a fruitful direction to follow.

The podcast linked above is a good place to hear Vitalik explaining the rationale for and impact of all this.

Phase 2: Execution environments

Check out Matt Garnett's sheth, an execution environment for managing shard ether. He's got a bunch of good first issues if you are looking for an entry point into the wonderful world of Eth2 Ph2.

The Phase 2 concept of abstract execution environments opens up a very exciting world of possibilities. How about an ENS EE?

Networking

An outstanding challenge on the networking front is being able to efficiently aggregate attestations to (votes for) shard chain and beacon chain blocks. This will become even more challenging under the new Phase 1 proposal, due to the much decreased time available.

Various approaches are being considered:

• The leading idea for now is "naive aggregation" over a gossip network. Trading off network traffic for aggregation effectiveness needs to be studied, but a strategy something like this could be viable to start with.
• Another method being explored for gossip networks is building ad-hoc structures for assembling aggregations effectively. Finding a cost function for this seems to be hard.
• A different approach is to explicitly structure the network, as in Handel. This is provably extremely efficient, but potentially makes it hard to preserve validators' anonymity.

There is a good discussion on the Sharding Gitter/Discord/Telegram ongoing that explores some of the trade-offs.

In other networking news, Whiteblock is planning to do some LibP2P Gossipsub Benchmarking. Join the (lively) conversation here.

Light Clients

Light clients will be a critical part of the Eth2 infrastructure, but haven't really had the attention they need just yet. Chainsafe is working to fix this, beginning with a monthly Light Client Dev call. Ping @ChainSafeth if you want to be involved.

"But, Eth2 breaks composability! 😱"

Right, let's talk about composability. In recent weeks people have wanted to talk to me about little else.

Composability is the "money Lego bricks"¹ thing that has become the killer feature of Eth1: it's the ability to easily plug applications together to create much more powerful applications.

The feature of Eth1 that makes composability easy is that inter-contract calls are both (1) synchronous and (2) atomic: if one part fails, the whole thing gets rolled back. Now, plans for Eth2 involve having asynchronous cross-shard calls. The concern is that this kills the golden goose; it prevents the lego bricks sticking together; it breaks composability.

Does sharding really break composability? No, I don't think so. No more than your multithreaded processor broke your operating system.

For one thing, it is likely that synchronous, atomic transactions will still be available between contracts in the same shard (though not everyone agrees this is the right model).

However, we don't want all applications to end up deployed on the same shard just in case they might need to interact some day. That would undermine sharding completely. Instead, devs will find new ways to do composability with async cross-shard transactions. Much of modern programming has to deal with asynchrony and much of modern programming has to deal with multithreading—and apparently it works! We have primitives, and high-level language constructs, and tooling that helps us deal with this in order to take full advantage of the available power. It will be the same in Eth2. Dan Finlay, again: this is a tooling problem not a composability problem (read the thread). Protolambda suggests there will be some new opportunities for better composability. And Vitalik has a bunch more ideas about how things could work. There is more good reading in this Reddit post and its parent. And Vitalik discusses composability in the podcast linked at the top at around 27m17s in.

Having said all this, there are design choices for protocol developers that can make things like composability more or less easy to achieve at the application level. This is partly the motivation for the proposed changes to Phase 1 outlined above. Under the new proposal, inter-shard communications will generally take a single slot (a few seconds), rather than having to wait a whole epoch (more than 6 minutes). This makes cross-shard composability much more realistic.

Not everybody is convinced, but Vitalik is emphatic: Sharding will NOT break defi composability.

Implementers' call

Call #26 took place on the 24th of October.

• Agenda
• Video
• My quick notes.

Research

Vitalik was in beast mode over DevCon week, publishing not only the new Phase 1 proposal, but no fewer than five ethresear.ch posts as well:

• The eth1 -> eth2 transition. It's a fair while yet before we can seriously get to work on transitioning Eth1 into Eth2 (and switching off proof of work), but Vitalik is already thinking about what the user/dev experience will be like as and when we do this. Tl;dr: relax.
• Partially sharding single-threaded apps: a design pattern. Sharding gives us two kinds of scaling opportunities: scale out and scale up. "Scale out" is running many smaller applications alongside each other, and comes naturally with sharding. "Scale up" is being able to host much larger applications, by running them cross-shard. Vitalik suggests approaches to achieving the latter.
• Two-way bridges between eth1 and eth2. This has stirred up some interesting issues. The current design is that Ether can only move one way: from the proof of work chain to the proof of stake chain, in the form of validator deposits, at least in the first instance. It might be desirable also to allow funds to flow back to the Eth1 chain, sooner rather than later. There are technical challenges to this, which are what Vitalik discusses in this post, not least dealing with the differing initial security levels between the chains. There are development challenges, alluded to by Danny Ryan. And there may be legal issues as well: under what circumstances does a transfer between chains become a taxable event? Does the bridge help to avoid this, or help to promote this? I've heard arguments on both sides. Discussion continues!
• Cross-shard DeFi composability - discussed above.
• On-beacon-chain saved contracts. Discusses a technique and economic model for storing frequently used, common resources on the beacon chain.

Also to be found on ethresear.ch:

• Mikerah 👋 considers the security of the 1-way bridge that onboards validators into Eth2.
• Vitalik: Formalizing and improving eth2’s approach toward finalization of invalid shard blocks.

In other news

• A bunch of videos from DevCon V are now available. I'm too lazy to go through them for you, but there was a lot of great Eth2 stuff going on this year. Take a browse.
• Here are the slides from the excellent two hour Phase 0 deep dive session. I don't think the video is up yet.
• A few more slide decks.
• • Danny Ryan on Eth2 Roadmap and Challenges. Covers the new sharding proposal, execution environments, and the possible two-way bridge. [From Crosslink Taipei].
  • Raul eats his own dog food by putting his Demystifying Gossipsub slides on IPFS (also on GitHub).
  • Justin's Eth2—collaboration culture presentation.
  • Ryuya Nakamura's Analyzing the Security of Casper deck.
  • Alex Stokes on the Finality Gadget.
  • Cayman from Chainsafe on Light Clients.
• An interview with Vitalik on Eth2 at Ethereal Tel Aviv (30 mins).
• Dev updates from Prysm and Lighthouse.
• Hsiao-Wei is doing a poll on how to abbreviate Ethereum 2.0. the winner is... "eth2", currently. (I prefer "Eth2", but that's just because I am old.)

Footnotes

[1] Dear North Americans, the plural of "lego" is never, ever "legos". Please stop it. Thank you.

Follow me on Twitter and/or Peepeth to hear when the next edition is out 🙌.

We also have an RSS feed.