Zero Knowledge X Danny Ryan - Trent

This post was originally published March 1, 2019 on Medium.

Quick summary of key takeaways from Episode 66.

The Zero Knowledge podcast consistently puts out fantastic content and I recommend checking out their archive. Episode 66 featured Danny Ryan of the Ethereum Foundation and focused mainly what ETH 2.0 will look like and the process to get it to where it is today. If you are able, take the time and listen to the full thing.

I pulled out things I found interesting for others to reference. This writeup assumes general knowledge of the Ethereum ecosystem and blockchains in general. Some of it paraphrases Danny’s words and some is my own commentary. Let’s jump right in!

GUEST BACKGROUND

Danny Ryan is from Louisiana.
He fell into the coordination role somewhat by chance because people found he was the only one to respond to their questions.
ETH 2.0 is acknowledgement that while Ethereum in general is awesome, there is a ton to learn from recent research. Evolution is necessary to remain a viable, system built on best practices.

ETH 1.X

Whether ETH 1.x becomes a shard is really a community question, a research question. Though there are some technical challenges depending on the option.
Option 1: Roll ETH 1.0 into 2.0 once it reached an acceptable stability. (but how?)
Option 1A: 1.x as exceptional shard construction — however, separate rules from other shards and a legacy code base is really bad combination. Also wouldn’t be compatible with forecasted need for state fees.
Option 1B (favored by danny): write EVM interpreter in WASM. deploy as contract on ETH2.0— fork state root into contract and ether balances, then users can interact with 1.0 state by providing “merkel witnesses.” The community could then deprecate maintenance for ETH 1.0 but still interact with the historic state. Stateless nature means there wouldn’t be any issues with state fees.
Option 2: allow legacy chain to operate in perpetuity. At this point there is potential to use ETH 2.0 to finalise 1.0, allowing mining rewards to decrease further.
Option 3: Have mining rewards be a function of how much ETH is left on ETH 1.0
Generally, he thinks there are “promises” that need to be upheld, like an Augur market related to Mars that expires in many years.

ETH 2.0 PREHISTORY

At the beginning of 2018 there were two parallel upgrades under development: Casper FFG and a sharding manager contract. Both would have “enshrined contracts” within the existing ethereum state to manage the complexity of POS logic and maintaining shards.
A lot of work was done on both options, Danny wrote EIP 1011. However, there were serious limitations to making both work on the existing chain. IE rate limiting (tx / sec) >> highly inefficient to process shards >> # of validators is limited >> in turn limits scalability and decentralisation.
The research team also realised that these two “foundational games” might compete with each other for blockspace and economic inputs. There were also roadblocks with EVM inefficiency. In May 2018, there was a turning point.
Some researchers took inspiration from other next efforts, including Dfinity. They needed to “break out of the EVM”, with benefits from more radical decisions.
This blank slate decision allows both the community and economic weight to seed the new chain. The research team can move faster, unencumbered — it’s incredibly difficult to engineer a new design onto a plane in flight.

ETH 2.0 ARCHITECTURE

Existing ETH chain will seed new POS chain that lives and exists in parallel. 1.0 will have a deposit contract (essentially a burn address). This emits a receipt that allows entrance to the beacon chain.
The Beacon chain is the core of ETH 2.0, where: validators exist, rewards and penalties happen, blocks are finalised, shard crosslinks occur, RNG (random number generator) mechanisms live. Danny terms it a “spinechain” User accounts don’t live there, doesn’t have a virtual machine. (here’s an awesome simulation / visualisation I came across!)
Anna asked how close it is to Polkadot’s relay chain. Danny says it is similar: It’s natural in POS systems for validators to congregate. This is where Casper and POS occurs, block justification and finalisation. POW doesn’t need this because RNG happens “extraprotocol”.

SHARD CHAINS

Shards exist outside of the beacon chain. Analogous to ETH 1.0 but there will be 1024 of them running concurrently.
Think of it like a growing tree, starting with the beacon chain as the trunk. Branches growing out are shards, sending water and energy (communications / txs) produced to the other branches via the central trunk. Leaves are addresses. (this seems like a really obvious analogy but I like how intuitive it is. Tell me where it breaks)
Shard chains host accounts, contracts, state and state execution.
Validators (on the beacon chain) are assigned to validate on a specific shard but also provide crosslinking between shards, approximately every 6 minutes. (spider webs or vines transferring kinetic energy?) They sit in small committees, ensuring that data is available between shards and helping to finalise points of the shard chain.
The number of crosslinks you can fit per block is dynamic, depending on the number of validators. With 4 million validators, the expectation is that all shards will be crosslinked to each other every epoch. (every 64 slots, about 6 minutes).
This method of communicating is asynchronous: meaning not occurring at the same time. It’s baked into the base layer. Synchronous calls cannot be included because it “explodes the complexity” in making ETH 2.0 work. Reorganisations on one shard could then lead to cascading reorgs on others. This would increase shard dependencies and increase system fragility.
Alternatives include: synchronous L2 proposals or encumbrances (contracts on different shards both enabled to signal promises that allow an actor to claim an asset once the beacon chain catches up — lol someone audit this explanation).

INTEROPERABILITY

Danny believes that interoperability is inevitable but cannot make a guess as to how many chains will exist. There might be long power tail of chains depending on their usage.
Fredrik asks where interoperability lives within ETH 2.0: would Polkadot link into the Beacon chain or one parachain per shard?

PHASE 1

This phase is where the system adds shard chains and data consensus.
There is also the possibility of finalising the ETH 1.0 chain via ETH 2.0. Requires 1.0 clients to be light clients of 2.0 — this allows the most recent state root to be exposed. That way, clients on 1.0 can make claims about 2.0 data via Layer 2 mechanisms.
There is also a concept of “economic load balancing”, simply meaning that contracts / accounts on expensive shards will eventually self-distribute to less populated shards. This doesn’t guarantee complete homogeneity in shard traffic but will be a strong influence.
“Yanking” might be used to move correctly enabled contracts between shards.
Phase 1 research (shard consensus) is happening concurrent to the regular Phase 0 spec releases.

SPEC EVOLUTION

About 6 months ago the spec transitioned from a research to engineering project.
Research out in the open is a little different — feedback comes earlier in the process and more frequently.
After Casper deprecation it has settled into an iterative process, making things more elegant. Since September the focus has been on fitting together research components in a sane way.
There have been too many teams jumping in last fall — Danny suspects he may have been a little early to signal that. Either way he is very proud of attaining a concrete Phase 0.
Overall, the process was “mild chaos”. Working in isolation at the beginning (on a private document) meant that big decisions could be made quickly. Operating on Github, teams are now been able to dialogue with research as it happens — hardens up the protocol.
Bikeshedding has been an issue (see serialisation discussions). EF does have a leadership position, can make strong suggestions. Danny is beginning to err to ship mode, even though there are smaller optimisations still being suggested by client implementers.
Over time they may introduce a more formalised EIP process for 2.0 development.

CLIENT DEV TEAMS

There is a lot of excitement from the teams. Competition exists where devs are able to optimise for specific user groups (miners, archive nodes, resource constrained devices), API buildouts, validators interfaces, multiple node connections, languages, additional baked in tools.

LOOKING FORWARD

Putting hard release dates are dangerous. Danny expects Beacon Chain to launch in 2019.
Within the next two months there will be viable beacon clients and short-lived testnets. Hopefully this leads to longer-lived testnets. Appreciates the structure of Cosmos’ Game of Stakes. Might be valuable to set up similar adversarial environments and attempt to collude.
Phase 1 is not too complex / difficult. Should follow shortly after, a lot of these efforts are moving in parallel. Working with EWASM team for Phase 2 spec.
Important to note — there is a lot of concrete gains at each Phase / iteration. But it’s equally important to remember that ETH 1.x still exists.

Thanks for reading through, hope you found this rough transcript useful! If you find any inaccuracies shoot me a message here or twitter and I’ll fix it.

If you want to get involved in the Ethereum 2.0 efforts, please check out ethresearch, the sharding gitter room. You can find the hosts Anna and Fredrik on Twitter. ✌️ 🙏