I believe that the process leading to the Istanbul Network Upgrade process has highlighted a tradeoff between ensuring the success of Ethereum 1.x and properly considering all of the EIPs proposed by the Ethereum community.
Even without the 1.x initiatives, Istanbul has more proposed EIPs than any previous Ethereum network upgrade (see this). A significant of the time on the AllCoreDevs calls leading up to both the EIPs submission deadline (May 17th) and client implementation deadline (July 19th
) has been spent discussing these.
Picture from the tweet linked above, showing how big Istanbul (top row) would be relative to previous network upgrades if all proposed EIPs got accepted.
This has the consequence that many of the 1.x initiatives have gotten very little attention in the process and that, as of now, not a single “1.x EIP” has been moved to
Accepted for the Istanbul upgrade. This has led to some frustration about the process, as expressed during the last AllCoreDevs call:
While some of the 1.x initiatives require more work and may not be ready for Istanbul anyways, if nothing in the process changes, we run the risk of arriving at the next network upgrade (April 2020?) and again having a large number of “community EIPs” compared to the amount of “1.x EIPs”.
At the same time, it seems that our current process has also done a poor job of addressing several of these “community EIPs” such as ProgPow, EIP-615, etc., leaving the community members for these initiatives feeling disenfranchised.
While these EIPs offer genuine improvements, they are not on the “1.x critical path” and require a significant resource commitment from EIPs champions, core developers, EIP editors, etc. There is thus a tradeoff between the time and attention spent on these vs. the 1.x initiatives. Judging by how satisfied both sides are with the current process, we have so far handled it poorly.
There are a few proposals about how we may move things forward, and I think we should discuss them in more details here.
Based on this framework, if non-1.x initiatives become more “1.x-ey” and form working groups to move their projects further along before formalizing them into EIPs, they may have a better shot at succeeding, while removing some of the “top of the funnel” burden on EIP editors and core developers. To some extent, ProgPow seems to have done this.
While this is obviously controversial (i.e. Who sets the guidelines? To optimize what? When/how do we change them?), it may be worth trying to prioritize EIPs which are on the 1.x critical path or that are simple to implement and provide high ROI (i.e. chain ID opcode, BLAKE2b precompile, etc.), a.k.a. “quick wins”.
The obvious risk here is that we disenfranchise community members who have EIP proposals that don’t fall in this bucket.
A less radical alternative to #2 may be to have network upgrades that are exclusive to 1.x initiatives as well as “open” network upgrades, which would be open the equivalent of our current process. Again, once caveat being that defining what is OK for these 1.x upgrades would be contentious.
For example, with a 3 month cadence, you could have “open” upgrades more or less as frequently as today, with an additional “1.x” upgrade every 3 months. It could also be possible for 1.x EIPs to be included in the “open” upgrades.
The biggest concerns against such frequent upgrades was the time it takes to understand, implement and test EIPs. Given that most 1.x initiatives are well known and that a fair bit of the work happens in working groups, these would be somewhat mitigated.
Neither of these options feels perfect at the moment, but I believe it’s worth kickstarting a discussion about how we can make rapid progress on the 1.x initiative, keep non 1.x contributors as part of the community and reduce the burden on core developers… which we can think of as the “EIPs Scalability Trilemma”