You can listen to or watch this video here:
Today, October 24th, 2019, there was an Ethereum Classic (ETC) developer call to define the scope and dates of the next hard fork, Agharta. It was decided by rough consensus that the upgrade will include three EIPs included in Ethereum’s Constantinople upgrade, and that it will be executed by mid January of 2020 (the specific block number will be announced soon).
However, the discussion showed it is not a simple task to maintain and upgrade a Turing complete, highly secure base layer blockchain as ETC.
The problem that arose was that a change that was planned for Agharta, called Generalized Account Versioning Scheme (AV), explained in my first article about this upgrade, was excluded from the planned hard fork because it affected “parity” with the Ethereum (ETH) blockchain.
The issue at hand is that AV is an upgrade that seeks to ensure backward compatibility between past smart contracts and future upgrades, or OPCODE additions and changes, in the network, but because Ethereum does not have such feature, it means AV breaks parity between the chains, so the advanced tooling in ETH becomes incompatible in ETC, unless someone maintains them specifically for ETC.
The dilemma that was presented is that the ETC core developer team has to make a tradeoff between backward compatibility, a fundamental principle in secure blockchains, and Ethereum parity, a desired feature that makes it easier and seamless for both ecosystems’ dapps and developers to work on both chains.
The issue would be greatly minimized if resources were dedicated to adapting the tools available in ETH to ETC, but that is not the reality of ETC at this time.
Given the above dilemma, it was decided that the easy changes of the three EIPs in Constantinople will be made, and AV will be postponed.
However, my position, and to minimize disruption of today’s decision, is that I support the decision, but that ETC has to discuss the deeper issues that popped up in the discussion (especially after the call in the ETC Discord) in another call soon. Also, to not leave out extra issues that were ignored in the call, such as ECIP-1043 (DAG size), ECIP-1047 (SHA3 mining algo change), and ECIP-1049 (gas limit reduction).
Proposed Agenda for a Potential Next Call
1. Parity with ETH vs Backward Compatibility
In my opinion backward compatibility is a key guarantee that a base layer, highly secure blockchain must have. Smart contracts in ETC should work for 100 years.
Backward compatibility is a critical feature that enables trust minimization and immutability. Trust minimization, because it eliminates the need for core developers to decide, on an upgrade by upgrade basis, what past stored smart contracts will be compatible or what percentage may break.
Immutability, because it is obvious that if a smart contract has even a minimal risk that it will not function correctly in the foreseeable future, then that code cannot be considered “immutable”.
Therefore, parity, although very important, has to be either achieved by other means after Agharta, or it has to be relegated to a secondary priority as related to backward compatibility going forward.
2. Account Versioning and Versionless EVM
ETC core developer @sorpaas has written the original specifications for backward compatibility using not only AV, but also with what he termed “Versionless EVM”.
These are links he provided to analyze the latter, and should be included in the call:
• Devcon talk: https://slideslive.com/38920010/toward-backward-compatible-ethereum-upgrades
• Slides: https://git.that.world/talks/20191011-compatibility.git/plain/presentation.pdf
• ECIP: https://github.com/ethereumclassic/ECIPs/pull/141
3. Breaking or not Breaking ETH Tooling
As explained above, the main problem of implementing AV is that it would make existing ETH tooling incompatible in ETC. I think it has to be debated whether that is such an important topic as to violate backward compatibility; if it is feasible to request to ETH tooling developers to adapt them to ETC; if ETC can reallocate resources to maintain such tooling; or if the goal of tooling compatibility has to be abandoned altogether as described above.
4. ECIP-1043, ECIP-1047, and ECIP-1049
There were some topics in the agenda that were included, but not addressed (ECIP-1043 and ECIP-1047), and one that was not included in the agenda (ECIP-1049), but had been an important point of discussion in ETC recently.
It would be good and respectful to the authors to include those items in the next call.
5. Forking Frequency
One thing that has been a recurring commentary in ETC is the frequency of hard forks.
Bitcoin’s smaller argument surface increases its social scalability:
“The more functions a currency has, the more things there are to argue over … Bitcoin’s uncompromising focus allows it to serve a broader user base.” — Elaine Ou via Nick Szabo
It seems many in the ecosystem are not sensitive to the risks and argument surface expansion that hard forking frequently creates. It was a known and planned series to do Atlantis, Agharta, and Phoenix, but indefinite and frequent upgrades to the chain are a significant security risk that undermines trust minimization, thus immutability.
Perhaps a long term ideal hard fork frequency, something like once a year max, could be discussed in the next call or on the ETC forums.
6. The Concept That “the Community Decides”
It was mentioned that, in any case, what the community decides has to be done. This means if “parity” is more important to the community then “backward compatibility” has to be postponed.
However, that is not how base layer, secure blockchains work. If there is a set of principles to live by, then those have to be upheld even if the majority of the ecosystem doesn’t like it.
Again, “immutability” is an illusion if basic things as backward compatibility are “decided by the community”. That was the philosophy followed by ETH in 2016 to do theDAO hard fork, which is precisely the reason ETC exists.
There is no such thing as “the community”. If participants have no sensibility to basic principles of security, that mindset must not prevail when implementing change in ETC.
Conclusion: Keeping it Real
Even if blockchain principles should be a certain way as described above, there is, in fact, an unavoidable physical reality in Turing complete blockchains such as ETC: Complexity.
Complexity has the problem that there can be bugs that have to be fixed, and, when fixing them, they can break things, even backward compatibility. An example of this could be an emergency hard fork. However, this is a legitimate case for doing so as catastrophic outcomes need to be averted.
The other problem is that, to make some desired security upgrades and added functionality, there can be instances, intentionally or unintentionally, in which a very small percentage of historic smart contracts, say 0.1% or less, may be broken.
These instances must be minimized as much as possible, but it is also true that applications, IoT, and layer 2 systems developers should follow best practices, and account for these risks when building on top of blockchain technologies.
In other words, they have to build robust software, with conservative and proven designs, in such a way that reduces the risk that future changes will break their functionality.
But, again, this must not free ETC core developers of the task of making the network as backward compatible as possible.
Code Is Law
