Ethereum’s history started in November 2013, when Vitalik Buterin made the Ethereum whitepaper public. This was 5 years after Bitcoin was born, in October 2008, when Satoshi Nakamoto published “Bitcoin: A Peer-to-Peer Electronic Cash System”.
It took 5 years to come up with a better blockchain design, with a Turing-complete EVM. Ethereum could do what Bitcoin did and more. However, a big part of Bitcoin’s developer community shuns Ethereum and they forget the technical merits, preferring to bring forth various reasons for why they stick with Bitcoin — from Bitcoin’s anonymous beginnings, Ethereum’s ICO and DAO fork, to various collaboration issues and differences between the two communities. It is also hard to let go of something when a lot of money is involved, and easy to find reasons for staying. But when human incentives and efforts align, research and development happen faster.
We are now 5 years into Ethereum’s timeline. There have been a number of projects claiming that they are better than Ethereum. Still, up until this point, none have surpassed it in terms of the number of users and developers. If Ethereum remains technically superior, there will be little chance for other technologies to do so.
Ethereum’s Future Proof Test
Ethereum’s big test is recognizing and overcoming its own bad habits, as Bitcoin did when Ethereum appeared. The community of developers should look at Ethereum’s competitors and find the technical features that would make them better. And, of course, integrate those features into Ethereum. With its Turing complete expressiveness, Ethereum has high chances to do that successfully. The test itself is not letting non-technical reasons cloud one’s judgment.
Biggest Advantage: R & D Decentralization
Ethereum’s big advantage is its potential and intention to decentralize research and development. This differentiates it from other projects that have a defined core team. Research topics are being discussed openly on ethresear.ch. There are now several, independent teams, that are working on Ethereum 2.0 client implementations. There is an Ethereum Improvement Proposal (EIPs) repository, where anyone can submit proposals for protocol changes, smart contract-based standards, process improvements, etc. Discussions for EIP proposals are also happening on the magicians forum.
We expect the process to be somewhat slower for core-related changes. There are fewer people capable of understanding the inner workings of Ethereum and decentralized systems in general. And even fewer capable of imagining and bringing into existence new scaling or consensus architectures.
However, the process has been very slow for the current Ethereum that we all know and love. And it is high time that Ethereum moves with acceleration. Ethereum 2.0 will be waiting for all the lessons that the current Ethereum has learned.
The innovation cycle is research & development -> analysis -> feedback -> R&D. Developers all around the world are free to research and implement anything on Ethereum. However, for Ethereum to truly benefit from this, the feedback step is crucial. Community feedback is the basis for creating common standards. If the feedback process is slow, Ethereum will not improve fast enough and it runs the risk of eventually being outpaced and obsolete.
Ethereum’s EIP Process
Feedback for the current Ethereum protocol and standards is handled by the EIP process, outlined in EIP-1. In short, anyone can submit a proposal, EIP editors will review that proposal and merge it in the repository as a Draft. There are a couple of steps to be made until it is considered Final, such as gathering community consensus around the proposal, achieving the consensus of core developers and the consensus of Ethereum client teams (for core-related changes).
Currently, there are 8 EIP editors, with different levels of activity, that guard the editorial and technical review process of Drafts and supervise an EIP’s life cycle. They function on a voluntary basis (unpaid) and have to deal with a technically wide range of proposals. There are no procedures defined for how new EIPs get processed or how new editors are appointed and removed. This has the unfortunate effect of leaving EIPs unreviewed for months on end, with no clear deadline or expected outcome. There are no rules to assess an EIP’s priority in the review queue. And usually, the EIPs that do get reviewed are either those written by well-known developers or that have a higher community signal. The EIP author is required to do “marketing” work in order to ensure that his EIP gets the first review.
There are attempts to alleviate the review process by making it easier for editors: removing the requirements to attest the technical soundness of proposals and moving the author’s effort for garnering community interest from the Draft stage to the post-Draft stages. The intended effect is to speed up the time in which EIPs get a unique identifier, making discussions easier.
I think lowering the bar for EIPs, by not ensuring technical soundness, may become an issue. EIP Drafts should have proposals that can actually be implemented, from a technical standpoint. Sure, the editor review should not be opinionated in regards to the actual implementation specs, otherwise, it can lead to bikeshedding over what implementation/specs are better. These are things that will be improved upon in later stages.
My own experience with dType, EIP-1900 prompted me to look into the EIP process more closely. After three months, it hadn’t been reviewed at all. It initially got a few comments on the discussion issue from various interested parties. During this time, I wrote a couple of articles on the matter ( here and here) and shared them on Twitter and Reddit. I have gotten some more reactions to the discussion issue from an EIP editor, only after I wrote about an Ethereum-Libra comparison regarding type systems and how a decentralized type system can help Ethereum surpass Libra. However, my EIP Draft is yet to be merged or fully reviewed.
So, I began by proposing a new, clear responsibility for editors: a maximum period of time in which they must review an EIP after a review request. If that limit is reached, then the bottleneck is clear: there are not enough editors available with the needed skills or interest.
Once the bottleneck was clear, I started writing a process for adding new editors: adding an EIP Editor Criteria to EIP-1. There was no other submitted proposal that tackled this subject, at the point of writing this article. The Ethereum community should voice its feedback on this and start scaling the EIP review process. This is the first step towards a faster and clearer feedback system.
There are applications to become an editor that have been left without a response for months. When you don’t have a process, evaluating these can be hard.
In addition, I am working on a decentralized solution to randomly assign editors to EIPs and keep track of their work. My work, in its very early stages, can be found at https://github.com/loredanacirstea/eip-process.
There is an obvious disadvantage to decentralization: interest and consensus are hard to achieve. And we need consensus on Ethereum’s evolution, as opposed to consensus on standards that benefit only a few Ethereum-based projects. What features do we want and need Ethereum to have?
The EIP system should be revamped today. Its speed should be at least doubled and its process should be very clear.
The question will always be: are we still able to adapt? (or are we Bitcoin?)