" One way to greatly reduce this tradeoff is to find a way to automatically convert version n
EVM code to version n+1
EVM code every time there is an upgrade (not necessarily immediately; perhaps convert when old code is “touched”, and make sure that all version n
code is converted to version n+1
before attempting to implement version n+2
)."
I am afraid that I have to say this is an absolutely terrible idea. Transpiling of bytecode POST DEPLOY? That is such an over-complex approach to something which is a simple maintenance problem.
New opcodes can be added without the need for bumping the EOF version number. Versions only change for non backwards-compatible changes, and those will affect the semantics in a major way anyway.
I’m getting vibes here of:
“What Killed the Linux Desktop”
How is this any worse than the absolute rafts of conditionals in other parts of the protocol (like gas costs)? The EVM is not that complex.
These warts are the cost of backwards compatibility and are only paid once, by the developers who are maintaining this platform to contain the complexity for the benefit of the developers building on top.
It’s exactly the same as the Windows/MacOS example in the Desktop Linux story. No, it isn’t sexy, but that is the cost of building a stable platform. We had exactly the same situation for central tools and libraries at EA. You need to support the union of all the versions and configurations which all of your end users are using. And yeah, that can be a lot of warts and conditionals messing up the simplicity of your beautiful code, but those are the table stakes.
Windows contains patches for specific applications, and patches for bugs in specific hardware. That is why you can still run binaries from decades ago.
Most important libraries have a massive test matrix, but guess what - computers are great at running automated tests. Most of this stuff is massively parallizable. Pay the entry fee.
Windows does not even CLAIM to be immutable, but it is a great example for what is required for the kind of stability we claim to aspire to.
(Incidentally - I think the goal of minimizing/removing introspection is a good one. It is just the post deploy transpiling that I have a major issue with. IMHO you just want to deploy once and you are done. Everything leading into that - smart contact language, compiler code gen, optimizations, etc is baked into that bytecode and you have to live with it).