The State of Ethereum 2.0

Executive Summary        1

Overview        1

Interview Methodology        2

Observations and Potential Consequences        2

Implementation Teams are Committed, But Funding Is A Concern        2

The Spec Continues To Churn, But It’s Getting Better        3

Implementation Teams Do Not Push Back Against Researchers        3

The Definition Of Done Varies From Team To Team        3

What Comes After Ethereum 2.0 Is Unclear For Implementers        4

There Is No Ethereum 2.0 Lead        4

Open Questions        4

What Does The Community Expect?        4

Were Implementers Consulted When Designing The Rollout?        5

Would Making Danny Ryan Official “Ethereum 2.0 Lead” Help?        5

Recommendations        6

Include “Product Context” In Public-Facing Media        6

Provide Clear Avenues For Continued Funding        6

Rigorously Define And Enforce A Formal Standards Process        6

How Kyokan/Moloch Can Help        7

Executive Summary

Research and development of Ethereum 2.0 continues at a rapid pace, with a testnet of the beacon chain scheduled for release in March of this year. However, a number of coordination problems are slowing implementation and the public’s view of what will be delivered and when differs from reality. In this paper, we outline these problems and propose solutions for how Kyokan and the Moloch DAO can help fix them.

Overview

“Ethereum 2.0” refers to a set of specifications that will dramatically improve the performance characteristics of the Ethereum blockchain. As of this writing, it does so by merging and improving upon research from two older specifications: “Casper,” which introduces a proof-of-stake consensus mechanism, and “sharding,” which introduces the splitting of transactions across a number of “shards” secured by the main chain. These specs confer the following benefits to Ethereum users:

  1. Proof-of-stake removes the need to invest in equipment and burn electricity to secure the chain. Furthermore, it improves Ethereum’s finality characteristics by making certain types of 51% attacks dramatically more expensive and reducing reliance upon mining cartels to secure the chain.
  2. Sharding improves the Ethereum network’s maximum transactions per second by orders of magnitude.

To determine the current state of the project, we interviewed the researchers and implementers working on the protocol.

Interview Methodology

We interviewed the following implementation teams via video call:

  • Nimbus (Status)
  • Lodestar (ChainSafe Systems)
  • Artemis (PegaSys)
  • Lighthouse (Sigma Prime)
  • Prysm (Prysmatic)

Each implementation team was asked questions encompassing the following functional areas:

  1. Team status;
  2. Development status;
  3. Roadmap;
  4. Launch considerations;
  5. Dependencies;
  6. Comparisons to other implementation teams; and
  7. Recommendations.

We also interviewed Danny Ryan, one of the core Ethereum Foundation researchers working on the project, via phone.

Observations and Potential Consequences

We now present our findings from the interviews described above. Quotes from individual interviewees are placed in quotation marks, and are reproduced verbatim.

Implementation Teams are Committed, But Funding Is A Concern

We asked each team their likelihood of and under what conditions they would give up development. All of the implementation teams we spoke to were committed to seeing Ethereum 2.0 through to completion as long as funding exists to continue development. This is an important point to underscore, as it implies two things. First, the implementation teams care deeply about shipping Ethereum 2.0, and are willing to weather the frustrations and problems that crop up along the way. Specifically, we received answers such as “We’d be dead before giving up.” and “This is going to happen no matter what.” in response to our questions around what it’d take for them to give up. However, the implementation teams are not immune to market realities. If EF funding dries up, or the larger entities funding individual implementation efforts (e.g., ConsenSys or Status) turn off funding, then there is a possibility that teams will be forced to find other work.

The Spec Continues To Churn, But It’s Getting Better

The Ethereum 2.0 spec has experienced a high level of churn over the past year. According to one person we interviewed, the spec has “entirely changed since the middle of last year”  and continues to undergo regular “surgery” as issues are found and ironed out by the research team. Every aspect of the spec is subject to change. For example, until recently the names of important data structures were changing “emergently” - that is, a researcher would update their mental model of what a particular data structure represented, and change the spec accordingly without consideration of the effects that such a change would have on implementation efforts. For example Issue #358, 35 individual fields were renamed, yet the GitHub discussion received no participation from implementers. This has forced implementation teams to redo large swathes of work as the spec shifts under them - leading to frustration, wasted time, and in some cases a reduction of resources allocated to Ethereum 2.0 projects until the spec stabilizes.

There have been several promising developments over the past few weeks to reduce churn. First, according to the research team there is an ongoing effort to start versioning specific areas of the spec in order to make clear which areas are stable enough for implementation and which are still being actively researched (this first release was published the day this report was published for internal review). Second, the research team believes that “changes are slowing down” and that “deep reorgs” of the spec itself should be rarer now. A culture shift is occurring as well: the impact a particular change will have on implementation teams is now considered as part of new spec proposals (see this issue as an example). As a result of these developments, implementation teams unanimously agree that the spec in its current state is implementable.

Implementation Teams Do Not Push Back Against Researchers

Most implementation teams do not push back against the research team. They stated two reasons for this: implementers either feel unqualified to push back, or they feel like the chances of successfully pushing back are too low to warrant doing so. These feelings are reinforced by how the research team describes the changes they have inserted into the spec: changes are usually described “clearly better” and “hard to push back against” given the qualifications of the people proposing the changes. While it is true that some areas of the spec can only be critiqued by a select few individuals, that feeling of “research exclusivity” currently extends to the entire spec as well as overall Ethereum 2.0 plan of execution.

The Definition Of Done Varies From Team To Team

All of the implementers we spoke to are working towards the testnet launch in March. What that launch looks like - and what happens afterwards - varies significantly from team to team. For example, it is unlikely that day one of the testnet will support inter-node peering because the peer protocol specification has not been fully accepted yet. Some teams have inter-node operability as a specific goal of the testnet launch, others do not. As a result, it is difficult to say with clarity what the actual deliverable in March will consist of.

Things become increasingly hazy past the testnet. None of the teams were able to estimate when Phase 2 - that is, the complete Ethereum 2.0 specification including cross-shard operations and EVM - would be mainnet-ready. Since some teams received grant money for the beacon chain specifically, it is likely that implementation teams will need additional funding to complete the spec.

Finally, only one of the teams we interviewed had user adoption - specifically, “100 validators staking using [their] software” - as one of their stated goals. The others were focused on completion of their respectively committed parts of the spec.

What Comes After Ethereum 2.0 Is Unclear For Implementers

Many teams expressed concerns around what comes next for their respective businesses after successfully delivering Ethereum 2.0. None of the teams we spoke to had a clear answer for how they would monetize post-implementation, so securing funding for continued maintenance (particularly if ETH continues to drop in price) is of major concern to implementation teams.

There Is No Ethereum 2.0 Lead

From an organizational perspective, no single person is responsible or accountable for making sure that Ethereum 2.0 lands and lands in a way that matters to the Ethereum community at large. Danny Ryan fills part of this role. He took it upon himself to be the liaison between the implementation and research teams, and his efforts are highly appreciated. Access to Danny isn’t consistent across implementation teams, however - some expressed that they wished that they could have more access to him.

Ethereum 2.0’s Narrative Is Controlled By People Outside The R&D Process

Consider James Prestwich’s popular post “What To Expect When ETH’s Expecting.” It includes claims like the following:

  • “The tools and contracts we’ve written for ETH1.X will likely need to be completely redesigned and rewritten for ETH2.0.”
  • “Phase 1 doesn’t have anything particularly interesting in it. Fundamentally it’s a bootstrapping phase for crosslinking, and the symmetric mechanism by which shards reference the beacon chain. The designers seem confident that these mechanisms will work.”
  • “Interestingly, Phase 0 implementation has happened concurrently with specification. Even today, less than three months from testnet, the Phase 0 specification changes regularly. This implies that future ETH2.0 phases will have extremely high variance in development time. While optimists have told me six months, it is easy to see Phase 1 taking 12–18 months of development after Phase 0 enters testing.”
  • “[Beyond eWASM, EVM2, and storage rent] we don’t know what to expect from Phase 2. It’s still in very early stages of research and includes several major unsolved problems. Given the informal specification and development process, as well as Phase 2’s expanded scope over Phase 1, it doesn’t seem reasonable to suggest that Phase 2 could launch before 2020. Which is to say, while ETH2.0 may launch this year, don’t expect ETH2.0 to support asset transfer or smart contracts until at least 2020.”
  • “We have very little information about ETH2.0’s communication model. We know that it can’t provide cross-shard contract calls without sacrificing almost all scaling benefits. I won’t blame you if you stop reading here, as Phase 4 only has a mind map and a few vague links. A non-obvious consequence of this is that ETH2.0 will not provide significant scaling benefits to complex smart contract systems until Phase 4. Until then, contracts wishing to interact with other contracts must cohabitate a shard and are limited to the speed and scale of that shard.”

These are concrete details about how developers can expect to make use of Ethereum 2.0. The post also includes plenty of technical detail about the spec, but as an Ethereum developer the most relevant information contained therein is about how the spec will impact my work and when to expect scalability improvements. Media created by the implementation teams and the EF, in contrast contrast, tends to focus instead on new research or the completion of specific pieces of the spec. Consider the following outline of Prysmatic’s Development Update #20[1]:

  • Latest Research
  • Phase 0 Validator Client Responsibilities
  • Merged Code, Pull Requests, and Issues
  • State Transition Block Processing E2E Testing Complete
  • State Transition Epoch Processing Integration Complete
  • Implementing Deposit Listener For The Validator Deposit Contract
  • Implementer Validator Deposits Trie
  • Upcoming Work
  • GHOST Fork-Choice Rule for the Ethereum Beacon Chain
  • Full End-to-End Testing of Beacon Chain With Validator Deposits
  • Deprecating Our Solidity Contract to Vyper
  • Creating the Beacon Chain’s Transactions Pool
  • Refactor Validator Client
  • Validator Private Key Management and Other Secrets
  • Misc
  • Ethereum 2.0 Implementers Call Jan 17, 2019
  • Blog Post on Ethereum 2.0 (which includes a link to Prestwich’s post above)

The things that drive Ethereum 2.0’s “narrative” - i.e., when it’ll ship, what it’ll be useful for, and how developers can use it - is driven more by posts like Prestwich’s than Prysmatic’s since the information is more directly relevant to the day-to-day work of Ethereum’s users. We commend the Ethereum 2.0 teams for their commitment to transparency, and obviously want technically-focused updates such as the one above to continue. However, if nobody from the research or implementation teams provides additional context around when Ethereum 2.0 will be ready and what it will look like when it is, others will continue to step in and do it for them. As a result, it will be difficult for correct expectations to be set and lived up to.

Addendum: A conversation of Ethereum community members pointed us towards this high level outline of Ethereum's roadmap prepared by EthHub. The link to the official sharding roadmap, while instructive, isn't as helpful for setting the expectations of platformer developers who want to know what each phase of the spec means for them.

Open Questions

What Does The Community Expect?

Currently, the narrative around when Ethereum 2.0 will be delivered and what it will look like is somewhat like this:

  • Ethereum 2.0 is coming, and will be ready for public use soon.
  • Ethereum 2.0 will be on testnet starting in March.
  • Ethereum 2.0 will solve the majority of Ethereum’s scalability concerns.

Given what we know after talking to both the research team and the implementation teams, it’s clear that delivery of an Ethereum 2.0 implementation with real utility to dApp developers is not feasible for at least another year and a half. From our understanding, the deliverables included in each phase of the Ethereum 2.0 roadmap are as follows[2]:

  • Phase 0: The beacon chain.
  • Phase 1: Shards without the EVM.
  • Phase 2: EVM on shards and cross-shard communication.

For developers to derive the same level of utility from Ethereum 2.0 as they did on Ethereum 1.0, phase 2 must be delivered.

Furthermore, for the later phases of Ethereum 2.0’s rollout it is possible that new research will invalidate or otherwise reshape the roadmap profoundly. It is unclear to us whether or not the Ethereum community at large is aware of this. A gap between what the community expects and what is actually delivered could hurt implementation efforts substantially by reinforcing the narrative that Ethereum will not be able to scale and cause new developers to begin exploring other blockchains.

Were Implementers Consulted When Designing The Rollout?

It is unclear to us how much, if any, implementer input was included in the decision to roll out Ethereum 2.0 in phases and what goes into each phase. While we understand the value of a phased deployment process - i.e., that it gives new technology like proof-of-stake time to “burn in” in a quasi-production environment - it stands to reason that the individuals responsible for implementing each phase are some of the most qualified people to design them in the first place. This includes which technology is introduced when, as well as when each phase is set to be delivered. If implementers were not consulted, would the launch of the beacon chain be a good time to reset and bring implementers into the process?

Would Making Danny Ryan Official “Ethereum 2.0 Lead” Help?

Many of the frustrations around Ethereum 2.0 stem from a lack of coordination between the research and implementation teams. The protocol consists of numerous disparate components that must be integrated as part of a plan spanning several years. Until Danny Ryan assumed the role of coordinator, there was no single person to whom both researchers and implementers alike could turn to to oversee that integration. Danny has already demonstrated his value as a lead. His name came up repeatedly during our interviews as someone that implementers would like to see more of, and his efforts on the early versions of the specification show that he is knowledgeable enough as a researcher to oversee the project.

It’s important to be clear about what ‘lead’ means in this context. We are using ‘lead’ to mean the single person who is:

  • Accountable for making sure that Ethereum 2.0 lands.
  • Accessible to all implementation teams and researchers.
  • Empowered with veto authority to act as a tiebreaker for critical decisions.
  • Empowered with delegation authority to make sure that the right people are solving the right problems.

This is most definitely a centralization of control. However, given the role he is already filling empowering Danny with official leadership seems fitting, and could make sure that the entire project is integrated smoothly.

Recommendations

Include “Product Context” In Public-Facing Media

Given the importance of Ethereum 2.0 to the success of the network, clearly communicating what will be delivered and when as well as how to prepare for the release of Ethereum 2.0 is paramount. To make media produced by Ethereum 2.0 teams and researchers more relevant to the community and regain control of the Ethereum 2.0 narrative, we recommend clearly articulating the following things with new public updates:

  1. How the latest update will impact developers.
  2. How roadmap changes might impact Ethereum 2.0’s timeline or roadmap.
  3. Areas where research or product churn is expected.

Including the above things will go a long way towards returning control of the Ethereum 2.0 narrative to those working on it.

Provide Clear Avenues For Continued Funding

We believe that incentivizing long-term, continuous development on Ethereum 2.0 clients is critical to a successful Ethereum 2.0 launch. The source of continued funding for implementation is ambiguous and a source of worry. If the Ethereum Foundation or an alliance of other interested parties pooled money and provided clear funding amounts with associated timelines, it would remove many worries around how client projects will continue to fund maintenance and new features once Ethereum 2.0 is launched.

Rigorously Define And Enforce A Formal Standards Process

The coordination problems inherent to implementing a spec while it is being defined are exacerbated by the lack of a formal standards process. By developing and publishing specifications, the Ethereum Foundation is acting as the de-facto standards body for Ethereum 2.0. As such, defining a formal process through which research can go from proposal to implementable can further reduce the amount of churn around the spec. There are numerous standards bodies from whom the EF can draw examples, however we recommend a variant of ECMA’S TC39 Standards Process. Our reasoning is as follows:

  1. The TC39 process is open, and embraces modern development practices such as pull requests on GitHub that contributors are already familiar with.
  2. The TC39 process bakes acceptance tests and reference implementations into the process itself.
  3. The TC39 process is more digestible and has less overhead than other standards processes.
  4. The TC39 process favors incremental releases of new standards on an set cadence.
  5. The TC39 process has a track record of success. As a result of the TC39 process, the JavaScript ecosystem successfully recovered from 10 years of language stagnation.
  6. Many of Ethereum’s developers come from a JavaScript background, and as such are already familiar with the TC39 process (specifically, proposal “stages”) via Babel.

We recommend introducing, at the very least, the concept of “stages” from the TC39 process. For the unfamiliar, TC39 proposals go from stage 0 (“strawman”) to stage 4 (“complete”), after which they are ratified as new standards at an annual meeting of TC39 members. The objective of having proposal stages is to make it extremely clear how ready an individual proposal is for implementation. Furthermore, since test vectors and reference implementations are requirements to transition from one phase to another, dialogue between researchers and implementers is encouraged. While an implementer may not be qualified to comment on the specifics of an individual algorithm, for example, they are qualified to comment on how that algorithm gets implemented. Under TC39, both the research and the implementation would be required to transition from stage 3 to 4.

How Kyokan/Moloch Can Help

Kyokan is a blockchain-native software consultancy based in the bay area. In the past, we have worked with MetaMask, SpankChain, Cosmos, Dfinity, and Uniswap. In addition, we received a grant from the Ethereum Foundation to build an implementation of Plasma MVP, which is currently preparing for mainnet launch. Our team has significant experience shipping production software at prominent consumer and enterprise tech companies.

Moloch is a grant-making DAO / Guild and a radical experiment in voluntary incentive alignment to overcome the "tragedy of the commons". Our objective is to accelerate the development of public Ethereum infrastructure that many teams need but don't want to pay for on their own. By pooling our ETH and ERC20 tokens, ETH investors and teams building on Ethereum can collectively fund open-source work we decide is in our common interest.

Kyokan, with funding from Moloch and others, is positioned to provide support for the ETH 2.0 effort in the following ways:

  • Prepare reports and analysis, like this one, to inform the community of ETH 2.0 progress
  • Evaluate the internal processes of the ETH 2.0 R&D effort
  • Help develop organizational structure as needed
  • Assist in coordinating standards across teams
  • Help plan the development roadmap
  • Provide launch coordination and prepare clients for production release
  • Help with developer recruitment

Moloch is positioned to provide support for the ETH 2.0 effort as follows:

  • Provide additional funding for ETH 2.0 teams
  • Funding key hires to provide cross-team support
  • Funding open-source tools (e.g. testing) to help 2.0 development

Conclusion

The ETH 2.0 effort may be unique, but the challenges it faces are generally what one might expect to observe in an emergently organized R&D effort of 8+ researchers and 50+ developers. With stronger coordination through leadership, a standards process, a well-communicated shared roadmap, and funding security, the ETH 2.0 effort is set to accelerate and meet the expectations of the Ethereum community.

We’re already seeing the beginnings of this acceleration taking place. In December, Vitalik (non-giver of ETH) said “YOLO” and gave a 1000 ETH grants to each of the Prysmatic, Lighthouse, and Lodestar teams. Another prominent ETH investor followed Vitalik and contributed 2,800 ETH to Prysmatic, helping Preston Van Loon leave Google to join the ETH 2.0 effort full-time. As more community members step up to share responsibility for ETH 2.0 delivery, we anticipate even greater results. We’re all in this together.

Disclaimer

Funding for Kyokan’s efforts in preparing this report is anticipated to come from the Moloch DAO, but has also been guaranteed personally by Ameen Soleimani, should there be complications. The report was authored primarily by Matt Slipper and Dan Tsui of Kyokan.


[1] This isn’t limited to Prysmatic specifically - the majority of public-facing media from implementers and researchers alike focuses on the tech. A Prysmatic development update was chosen because Prysmatic has the highest volume of public media.

[2] Note that the phases described on the Sharding Roadmap document are different. The development phases described to us during our interviews indicated that those phases are no longer canonical.