The State of Ethereum 2.0
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
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
Include “Product Context” In Public-Facing Media 6
Provide Clear Avenues For Continued Funding 6
Rigorously Define And Enforce A Formal Standards Process 6
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.
“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:
To determine the current state of the project, we interviewed the researchers and implementers working on the protocol.
We interviewed the following implementation teams via video call:
Each implementation team was asked questions encompassing the following functional areas:
We also interviewed Danny Ryan, one of the core Ethereum Foundation researchers working on the project, via phone.
We now present our findings from the interviews described above. Quotes from individual interviewees are placed in quotation marks, and are reproduced verbatim.
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 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.
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.
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.
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.
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.
Consider James Prestwich’s popular post “What To Expect When ETH’s Expecting.” It includes claims like the following:
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]:
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.
Currently, the narrative around when Ethereum 2.0 will be delivered and what it will look like is somewhat like this:
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]:
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.
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?
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:
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.
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:
Including the above things will go a long way towards returning control of the Ethereum 2.0 narrative to those working on it.
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.
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:
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.
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:
Moloch is positioned to provide support for the ETH 2.0 effort as follows:
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.
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.