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 begginings, 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 happens 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 number of users and developers. If Ethereum remains technically superior, there will be little chance for other technologies to do so.
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.
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.
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 a 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 on 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.
https://twitter.com/alexberegszaszi/status/1146196558133760007 There are 151 drafts currently and probably around 80-90 as pending pull requests. How will the "community" review, agree on and finalize ~240 EIPs?
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?)
There have been discussions around improving the process, filtering the EIPs better:here, here.
5y ; -> 2018 ; Libra - similar to Bitcoin as attitude (PR) - Libra has all the chances to become what Ethereum is now for Bitcoin. Unwillingness to recognize the bad patterns of previous generations. Let's change the pattern at the peak governance.
- one main project, that should be number 1 in the hierarchy of all projects
- time to evolve with acceleration -> more editors for EIPs creare -> analiza -> feedback -> creare accelerare -> feedback f rapid + sugestii improvement
- decentralization disadvantage - lack of consensus; we need consensus on Ethereum's evolution
- the EIP system should be revamped today. Its speed should be at least doubled and its process should be very clear. (current speed from proposal to finalized? months)
Are we still able to adapt? (Or are we Bitcoin?)
- editors must be open to EIPs from competing projects
- maybe links to tweets/discussions/videos about small number of editors
- stats - PRs open, PRs with no comments + Axic's tweet
- author responsibilities - Abandoned status
- https://ethereum-magicians.org/t/decentralizing-eip-workflow/1525
Satoshi was anonymous and disappeared, and therefore Bitcoin represents the decentralization spirit better. Vitalik is known and therefore is viewed as leader that can control development and influence Ethereum's community. Vitalik eventually started taking steps back when Ethereum became viable, encouraging other developers and teams to lead. He publicly stated that he wants Ethereum development (core and non-core) to be decentralized.
Bitcoin did not have an ICO, there were no pre-mined BTC and Satoshi's BTC, from the early days, were never spent. Ethereum's ICO is viewed ....
The most recent project launch, that aims to become a global currency and financial infrastructure, is Facebook's Libra. This is one of the main use cases of Ethereum. What differentiates Libra from other attempts is Facebook itself. For the first time, we are looking at a blockchain-like project started by one of the most prominent global companies, with the intent of collaborating with at least 100 other big corporations, forming the Libra Association. For the first time, USA legislators have issued a "cease to implement" warning, until they assess the financial risks. The reason being: Facebook is used by over a quarter of the globe's population and the new financial system could become "too big to fail".
Taking this into account, the Ethereum community should take a close look at what Libra is and will be implementing.