The Principle of Backward Compatibility in Ethereum Classic

You can listen to or watch this video here:

Immutability in Ethereum Classic (ETC) means that accounts, balances and smart contracts cannot be modified except by holders of corresponding private keys by entering transactions according to protocol rules.

Immutability and backward compatibility are like two sides of the same coin: Immutability is a feature in space and time, but looking forward, as it promises that things that are done today should not be modified by third parties in the future. Backward compatibility is also a feature in space and time, but looking backward, as it promises that third parties should not break today what users have done in the past.

Space relates to place and geography. It means that anyone, anywhere in the world, should be able to have access permissionlessly and without censorship to their money, smart contracts, and dapps. Time means that accounts, balances, transactions, and dapps entered in the present or the past should be immutable and no changes of the protocol in the future should break them or stop them from working.

Both immutability and backward compatibility are related to the principle of Code Is Law in ETC in that decentralized applications (dapps) should always work as intended and designed, forever.

Thus, immutability and backward compatibility have the same underlying goal: No change.

No change means reduced chances of manipulation and also guarantees that the flow of economic transactions between people and businesses will continue uninterrupted. All this contributes to the reliability of the system on a global scale for a long time.

The problem that the principle of backward compatibility addresses specifically is that when making changes through hard forks, implementing upgrades and fixing things as time passes by, sometimes existing smart contracts break rendering them unusable.

This is a very serious problem.

Imagine applications, agreements, benefactors and beneficiaries depending on continuous streams of cash flows on a highly secure and decentralized system as Ethereum Classic, but when an upgrade is made, then the code powering such affairs breaks and stops working.

From a safety perspective, future upgrades that break backward compatibility are security holes as they may be used as stealth attack vectors, disguised as upgrades and bug fixes, but that really break things. This vulnerability reduces the finality of accounts, balances, transactions, and decentralized applications as the upgrades themselves may be leveraged by bad actors to change or stop things from working.

The use cases that need backward compatibility are decentralized applications, contracts, and agreements that should work for a long time. And "long time" here means decades or even centuries.

Examples of these use cases may be long term publicly traded bonds and debt obligations; long term business contracts and cash flows; legal persons and partnerships represented as DAOs on the blockchain; property registries; bilateral agreements between nations; university, hospital, and other types of endowments; church funds; national treasuries with complex administrative rules; long standing charities; family trusts; inheritance contracts and wills; and even plain and simple multisignature wallets.

Fortunately, there are several efforts in the Ethereum Virtual Machine (EVM) segment of the blockchain industry, where Ethereum Classic is a major player, that have as an objective ensuring long term and reliable backward compatibility.

All these ideas usually revolve around creating versions of the blockchain components to be upgraded and then making smart contracts, accounts, and dapps work with their corresponding versions, regardless of when they were deployed.

Some of the ideas being debated are:

EVM versioning: Setting and identifying a version of the EVM every time there is a change or upgrade so that accounts and smart contracts can use that version. Then, all the future versions of the EVM will be included in the protocol and node software clients so they can be perpetuated in time.

Account versioning: Creating account versions and formats for regular and smart contract accounts that are related to specific EVM versions so they can call that EVM version each time they need to be executed. As all future EVM versions will be hosted on the blockchain, then no accounts or smart contracts would break if these features were added.

EVM Object Format (EOF) upgrade: Similar ideas as the above, and others related to them, are being worked on and tested, and will likely be included in an upgrade, called EOF, that will greatly improve backward compatibility in EVM standard blockchains such as ETC.

Backward compatibility is a very high priority in ETC so any innovation or upgrades that enhance this guarantee will very likely be adopted by the ecosystem.

Thank you for reading this article!

To learn more about ETC please go to: https://ethereumclassic.org