In my article “Why Ethereum Classic Needs a Single and Unified Improvement Proposal Process — ECIP” I laid out the reasons why, as the title reads, I think there needs to be a unified ECIP process in Ethereum Classic (ETC), but the same implied having a single centralized repo location which is not agreeable to some core developers in the community.
After several conversations with Zach Belford, ETC Labs Core engineer, he explained to me the reasons for their preference to work in their own repo called the Ethereum Classic Labs Improvement Proposal process (ECLIP), showed me a very didactic video by Brian Cantril, ex-Sun Microsystems and expert in the open source software industry, where part of their philosophy is well laid out, and proposed to me to consider the Star Improvement Proposal Standard (StarIP) that him and Shane Jonas, also ETC Labs Core engineer, envision for consolidating the Ethereum Classic Improvement Proposal process (ECIP) which has been described by many as cumbersome and thus very inefficient.
I found the idea very innovative and particularly suited for Ethereum Classic’s needs for the following reasons:
1. When consulting about the ECIP matter, Bitcoin core developers who manage the Bitcoin Improvement Proposal process (BIP) and other notable Bitcoiners expressed that it is impossible and somewhat against blockchain ethos to stop others from forking the BIP or ECIP processes, however undesired, because they are permissionless open source systems.
2. Zach, Shane, Stevan Lohja and other ETC Labs Core engineers have expressed they will not use the current ECIP process because they find it constrains their work and they feel uncomfortable with its centralized location and administration.
3. As explained in the video mentioned above, those of us who wish to force the current ECIP process on all core developers may incur in “anti-pattern” behaviors such as “forkaphobia” and “governance-orgy” that may drag ETC’s open source process backwards rather than restoring it (a case in point is reason 2 above).
4. When Zach explained his decentralized StarIP idea, I liked it and we decided to collaborate presenting it as a show of good faith between opposing sides in the debate and because the idea is genuinely innovative.
5. After chatting with Zach, I believe him and the ETC Labs Core team are quite independent from DFG, focused on improving ETC and not capturing the network.
6. As the options ETC has at this point are either to continue to try to force others to use the ECIP and risk further fracture, to continue to work with the ECIP and ECLIPs separate and uncoordinated processes, or to try this innovative and more decentralized StarIP system, I decided to support this last option.
7. As will be seen in the section below, the Star Improvement Proposal Process as applied to the ECIP process in ETC is still a single and unified process as I advocate, the only difference is that the repos for the posting of ECIPs, their discussion and merging are in separated repos of each client development team instead of a centralized one. Also, the process is simplified because “merging” by a single team means “acceptance” or a sort “voting by adoption” for a particular rule change.
8. Power is not granted to any team, even if they have dominant market share with their client implementation, because merging, thus changing rules locally, is not in itself a “protocol change” as node operators and miners still hold the power to adopt, or not, the new version of the client and consensus rules.
Rationale for Supporting the StarIP Standard for the ECIP Process
How Bitcoin’s BIP Process Works Today
As it’s seen in the slide above, the process generally consists of a consensus rule change proposal, a discussion, acceptance or rejection of the proposed change, and finally merging the changes that were accepted. The process before merging into the implementation is sometimes called the “standard” or “protocol” definition and the merging action is called the “implementation”.
The criticism of the BIP process is that both the process and the “reference” implementation are located in a central repository with a few selected and trusted admins who not only move the process forward, but also have the power to admit or remove other admins and members who participate in the process.
Also, the mechanism by which BIPs are accepted or rejected is somewhat subjective as it depends on a few people gauging consensus by reviewing the objections and support for each proposal and not by any other more objective process.
How Ethereum’s EIP Process Works Today
The EIP process is practically identical to the BIP process and has been criticized for the same centralization reasons. The only difference is that the Ethereum yellow paper and the EIPs that are accepted are not only used to update the “official” implementation, but what happens to that implementation serves as the leading case for many other implementations as Ethereum has been much more open to client diversity.
How the Ethereum Classic ECIP Process Works Today
The current ECIP described above is very similar to the EIP process, therefore the BIP process. As it may be seen, ETC also has client diversity, but the same criticism of centralization applies to the ECIP process, which is, in fact, the main reason ETC Labs Core decided to create their parallel ECLIP process.
The Proposed StarIP for the ECIP Process
The proposed StarIP based ECIP process above is decentralized and simplifies the decision making process by having developer teams express their preferences by merging or not merging the proposed changes into their implementations. This is more objective than just reviewing comments in a discussion and guessing consensus by a group of admins.
Additionally, the new ECIP process keeps an efficient identification and tracking system of ECIPs as they will be numbered using the “ECIP” acronym as a prefix, and a hash algorithm number for the title for the suffix. Also, all teams must use the same numbering, pull request and merging format on Github as explained in the Readme file:
All client development teams, the ETC community and the public in general will be able to see all ECIPs, so it’s a transparent process. I think it is very likely that aggregation services will be created to manage this more deconstructed format for ECIPs.
Balance of Power : Node Operators and Miners Ultimately Decide
As described in point 8 of my rationale above, this new improvement proposal process does not necessarily grant undue power to single developer teams with very popular ETC clients (e.g. Parity, which has ~61% market share in the ETC node market). This is because, as described by Luke Dashjr, Bitcoin Core developer, the general process of proposing, discussing and accepting new changes to blockchain protocols in general, and BTC and ETC in particular, is much more ample than just the ECIP and merging mechanism:
As it may be seen in the slide above, the ultimate step of deploying any changes, even if discussed and accepted by all or some developer teams by merging in their own clients, no matter how popular those clients may be, ultimately depends on node operators and miners who actually run the software and rules they select that make the actual live operating network work.
This power by node operators and miners has important implications because they balance such power not only in the ECIP process level but also in the operating network level by:
1. Not deploying rules they don’t agree with.
2. Deploying clients with low node market shares and rejecting others that may have abused their power, even if they had large node market shares.
3. Participating in the rule change preliminary debates and ECIP discussion process per se by expressing their preferences and concerns in advance.
4. Internally rejecting blocks created by some miners and distributed by some nodes who may have adopted undesired consensus rule changes created and pushed by specific teams who may have not gotten much voluntary consensus in the ECIP.
Potential Questions and Objections to This Proposal
Here I list some objections that I have already read in some forums and social media. These and more objections may be discussed and will be answered by the sponsors in the StarIP repo’s issues section on GitHub:
• Search and discovery of ECIPs may be difficult as they are spread across many team’s repos.
• The necessary discussion for each ECIP may be inefficient as teams need to find new changes in other team’s repos.
• Not all BIPs are related to consensus rules, and BIPs are not client-specific. How are informational or procedural ECIPs processed?
• How do we know if all teams will comply with the standard if they can just start ECIPs, debate them internally and just merge them without consulting to anyone else?
• Using voting or majorities is not good for blockchains, but is this a democracy? What happens when people want a change that was only merged by a minority of teams? What if 50% of teams accept and merge an ECIP and the other 50% doesn’t? If an ECIP has more than 50% of teams merging it, does that mean it is forced to the rest of the network participants? [Answer here]
Conclusion
As Ethereum Classic is a decentralized and permissionless blockchain, and the decision making processes for defining its protocol standards and implementations are open source, evidently it becomes difficult and even counterproductive, as seen by recent events, to try to force all developer teams to actually use the same centralized repo for proposing and implementing changes.
However, given that the ETC network is unique because it is a global network of nodes and miners who need to reach the same exact conclusion about the same exact state every 15 seconds, according to the same exact set of rules, it is imperative that all developer teams work under the same improvement proposal standard.
Since the options ETC has are either to possibly fragment itself, continue to work separately with little coordination, or perhaps work in a single and unified ECIP process, using the proposed Star Improvement Proposal Standard, I have decided to support this last initiative.
Code Is Law
