You can listen to or watch this article here:
As Bitcoin’s Bitcoin Improvement Proposal (BIP) process and Ethereum’s Ethereum Improvement Proposal (EIP) process, Ethereum Classic also has an improvement proposal process called the Ethereum Classic Improvement Proposal (ECIP) process.
The reason why all sound and secure public blockchains, or at least those who claim to be so, have unified improvement processes was stated by Satoshi Nakamoto himself:
I don’t believe a second, compatible implementation of Bitcoin will ever be a good idea. So much of the design depends on all nodes getting exactly identical results in lockstep, that a second implementation would be a menace to the network.
Of course Satoshi was responding to the idea of building a second implementation of the Bitcoin client, but the underlying philosophy of high coordination and alignment of the ruleset is totally applicable to the process of making decisions to change the protocol as well.
So much so, that when Amir Taaki realized this he created the BIP process in 2011.
Amir wrote:
The keywords by Amir Taaki above are: “concise”, “primary mechanism”, “community input”, and “author is responsible for building consensus”.
What I am referring to, here, is that the improvement proposal process in any public blockchain has the same hazards and risks as implementing a new client as Satoshi warned.
As an illustration of this, I will rewrite Satoshi’s phrase, but rewording it to adapt it to refer to the improvement proposal process:
I don’t believe a second, compatible [improvement proposal process] of Bitcoin will ever be a good idea. So much of the design depends on all [clients being built based on the same identical ruleset and] getting exactly identical results in lockstep, that a second [improvement proposal process] would be a menace to the network.
In the case of the Ethereum EIP process description, which follows the example of the BIP process, they took the work of specifying the various (and complex) steps in more detail, which I think shows that any deviations or alternative channels only risk distracting from what should be the focal point of what the actual technical changes and an ensuing functional debate should be.
Needless to say is that, with the amount of steps and focus the ecosystem needs to concentrate and coordinate for sensitive protocol changes, it is entirely plausible that malicious players could use alternative channels, and the fragmentation, confusion, and mental cost they create, to introduce undesired changes and increase the chances of splitting the network.
Attacks using this strategy of fragmentation have been attempted before, some successfully and some not, including Bitcoin Unlimited, Bitcoin XT, Bitcoin Classic, BCH, and BSV. Note that the great majority of these attacks on Bitcoin were done by who were once trusted and friendly community constituents!
The above is true even if the malicious players’ intentions were only to capture the development process without necessarily the intent of splitting or undermining the network itself.
In the case of Ethereum Classic’s ECIP, it is practically identical to that of Ethereum, and by extension that of Bitcoin, therefore pursues the same objectives.
As it can be seen above, the ECIP process of Ethereum Classic is practically identical to that of Ethereum, and it even has the relevant Ethereum EIP’s as part of its base code implementations and changes.
It is important to note as well that the ECIP process in ETC is not a centralization device as some confuse or try to confuse the community about.
That is as a fallacious argument as saying that prompt coordination of core developer teams to fix emergency bugs are a centralization point in blockchain networks.
What people who argue the above don’t understand, or don’t want to understand, is that the incentives that drive developers, miners, and node operators to participate in a blockchain network, following its decentralization rules, are the same incentives that drive them to fix any bugs or solve any emergencies that may undermine such decentralization.
Therefore, blockchain developers swiftly coordinating to solve catastrophic bugs or fix network failures DOES NOT MEAN centralization, in fact it means the opposite: A strong incentive to continue enforcing decentralization.
Exactly the same logic applies to the BIP, EIP, and ECIP processes.
A “bait ball” is a group of fish who instinctively swim to the center of the school to minimize their exposure to predators. The resulting “ball” seems like a top down designed device. However, each is acting individually and selfishly in a decentralized manner, but they seem like a coordinated group, even if there is no centralized authority nor top down leadership.
Finally, the ECIP process is not the only “structured” and “rigid” method there is in the decision making process in ETC. The larger process is much broader and may start a long time before any improvement proposal is even written.
This shows how open the general process is and even gives all participants, technical or not, the chance to contribute and debate.
As Luke Dashjr explained, the BIP document (the ECIP document in the case of ETC) is in practice the third step in the decision making process for changes in the protocol.
Conclusion:
Blockchains are decentralized systems that consist of nodes achieving consensus on the exact same identical rulesets at very frequent intervals on a global scale. The fact that they have to achieve this exact same conclusion does not mean centralization.
To the contrary, this emergent, bottoms up consensus mechanism is absolutely decentralized, each participant voluntarily contributes and accepts the results, and this is called “rough consensus”.
In the same manner, any improvement proposal process of any highly secure blockchain in general, and the ECIP process in Ethereum Classic in particular, must be a single and unified process to minimize misinterpretations, security holes, errors, and even potential attacks.
Code Is Law
