A reflection of the EIPIP survey results
The first step in problem-solving is finding what the problems are. A simple way to find problems is to ask the community who’s involved.
We asked stakeholders a set of emotional questions. “What’s your biggest frustrations?” can identify current problems. “What’s your biggest fears?” can identify possible future problems. And, “What do you currently like?” can identify things that shouldn’t be changed.
The final results are almost the same as the survey results shown in May. There were three main categories:
- Decision making
- Capacity for completion
We also found community values for the EIP process:
- Low barrier to entry
- A high bar of acceptance
- Structure and legitimacy
These values guide what to keep in the process. While the problems will serve as a roadmap for progress moving forward.
The survey revealed frustrations. To begin thinking of solutions, we can start by changing those frustrations into questions. Following this format, the roadmap is a series of questions.
Part 1: How can we formalize the decision-making process?
- How can we clarify the EIP process from hard-fork coordination decision-making?
- How can we make decisions less reliant on the Core Dev live calls?
- How can we create finality for EIPs?
- How can we ensure no one single party prevents the launch of an EIP?
- How can we ensure no one single party has the power to launch an EIP?
- How can the community be formally represented in the process?
- How can we ensure proposals have enough exposure to be decided on?
- How can we track/organize community consensus?
- How can we clarify what’s been considered for EIPs and who’s in favor?
- How can we increase represented groups/diversity in the Core Devs?
- How can we keep the EIP process apolitical?
Part 2: How can we increase clarity in the EIP process?
- How can we clarify what steps EIP authors need to take for their EIP to be included in clients?
- Should EIP authors create a reference implementation in a client as a requirement?
- How can we make the EIP process more well known?
- Should EIPs include a list of use cases?
- Should EIPs include a list of pros and cons?
- How can the community track progress for EIPs and who has it implemented?
- How can discussions around EIPs be more easily followed?
- How can we keep the attention away from the process, and towards the technical discussion?
Part 3: How can we increase the capacity to finalize EIPs?
- How can we onboard more EIP editors?
- How can we onboard and assign more EIP champions?
- How can we reduce the backlog?
- How can we reduce the turnaround time?
- How can we organize working groups for different EIP categories?
A Reflection on the Survey
Pursuing a survey open to all stakeholders in the EIP process has helped the EIP working group organize what issues should be worked on. It is successful in this way, paving the way for success for EIPIP.
One thing that can be done differently next time for the EIPIP survey is seeking more understanding of community goals and values. This can be the inclusion of a question, “What are your wants and aspirations with the EIP process?”
Regardless, the EIPIP working group aims to consider responses into what has become the roadmap for EIPIP for the next few months.
The final transitioning mechanism to Ethereum 2.0.
Every time the difficulty bomb became visible, block times went from being constant to starting to grow parabolically. In each of these cases, the clients running Ethereum had to perform a backward-incompatible update, also known as a hard-fork or network update.
Results from collecting feedback from EIP Editors, Authors, and Core Developers on improving the EIP process
In November 2013, the first draft of the Ethereum white-paper was made. In the Ethereum white-paper was the context for the creation of Ethereum, a detailed concept of what Ethereum is, including philosophical principles and higher-level summary, and a higher-level look at the pieces that make an Ethereum client and how they operate.
While the white-paper contains the higher-level concepts for the making of Ethereum, in mid-2014, the Ethereum yellow-paper was released detailing the technical aspects of developing an Ethereum client. The specification of this paper was what client implementors used to create the first versions of Ethereum.
But Ethereum evolved past the initial yellow paper. The main process of how that evolution took place was through an iteration of new proposals called Ethereum Improvement Proposals (EIPs). Ethereum Improvement Proposals as a concept was based on the Bitcoin Improvement Proposal (BIP) created in 2011, which itself was based on the Python Enhancement Proposal (PEP) created in 2000.
In October 2015, the EIP Github repository was created. And following in the steps of Python Enhancement Proposals, EIPs were technical documents akin to specifications.
The EIP process has been the source of various improvements to Ethereum, including the standardization of ERC-20 and ERC-721 tokens, and the organization to many network upgrades to the Etherum network, including Constantinople, Atlantis, and Istanbul to name a few.
The EIP Improvement Process
In January 2020, the first EIP Improvement Process (EIPIP) meeting was held. The EIPIP meetings are a series of meetings intended to bring together experienced developers and experts to facilitate the EIP improvement process. EIPIP was formalized to keep meta conversations about the EIP process separate from the All Core Devs meetings, keeping those meetings focused on reviewing EIPs. The EIPIP group is following Ethereum’s shift towards a new EIP centric process.
As a part of the process for improvement, the EIPIP group is collecting feedback from EIP Editors, EIP Authors, and Core Developers on the current state of the EIP process. Read more about EIP Improvement Process (EIPIP) group and Q1–2020 report.
In the survey, 4 open-ended questions were asked. What do you currently like about the EIP process? What are your current frustrations with the EIP process? What are your current fears with the EIP process? And what are your suggestions for improving the EIP process? The survey results, so far, are the following.
What Currently Works
Currently, what the community likes is that the current EIP process is well defined and structured, focuses on the technical aspects, and has legitimacy. The barrier to entry is low, anyone who wants to take part in the process can. And the process for approving EIPs is democratic, transparent, and allows for a fair and thorough review with a high bar of acceptance.
What Needs Improvement
Problems brought up by the community are as follows:
- How can we keep the EIP process as apolitical?
- How can we create a sense of finality? (Through final approval and rejection.)
- How can we onboard more EIP editors and increase capacity for EIP review?
- How can we ensure champions are allocated for EIPs of value to continue the EIP process to completion?
- How can we become less reliant on live conversations?
- How can we clarify the EIP centric process and hard-fork coordination and how they interact with each other?
- How can we reduce backlogs for EIPs?
- How can we document use cases, community support, and progress for each EIP?
- How can we keep the focus on the EIPs and not the process?
- How can we finalize EIPs that appear to be controversial?
There exist problems, that when solved, solve multiple other problems automatically. These are higher-order problems. From the problems identified thus far from the survey, the higher-level problems are as follows:
“How can we formalize the decision-making process for EIPs?”
With a formal decision-making process for EIPs, the hope is the EIP process can become apolitical, a sense of finality to EIPs can be introduced, and EIPs that are controversial can be finalized in a way that is objective.
Out of all needs, the need for having a formal decision-making process was the most represented in total. By each group, this need was expressed by 50% of Core Developers, 50% of EIP Editors, and 80% of EIP Authors who were not Core Developers or EIP Editors.
“How can we onboard more contributors to the EIP process?”
With more contributors, the capacity for more EIP editors increases, as well as the capacity needed or more EIP champions. With a clear decision-making process and more contributors combined, the EIP backlog would also be reduced.
Out of all needs, the need for onboarding more contributors was the second most represented in total. By each group, this need was expressed by 50% of Core Developers, 50% of EIP Editors, and 40% of EIP Authors who were not Core Developers or EIP Editors.
“How can we increase clarity for the EIP process?”
This final problem is a catch-all for smaller problems. Clarity includes knowing the progress of each EIP that is eligible for inclusion, knowing the use cases for each EIP, knowing at what level of community support each EIP has, and clarifying or formalizing how the EIP centric process and hard-fork coordination interact with one another. A clear process would also result in the focus on EIPs and not the process itself.
Out of all needs, the need for increasing clarity was the third most represented in total. By each group, this need was expressed by 50% of Core Developers, 25% of EIP Editors, and 0% of EIP Authors who were not Core Developers or EIP Editors.
We still need to parse through suggestions on solutions provided by the surveys and survey more stakeholders. You can participate in this survey here. Once sufficient surveys are received to consider sufficient stakeholder input, the EIPIP group will be focused on addressing these issues efficiently. We are committed to making Ethereum the best it can be.