a quiet PR landed in the MultiversX VM today, and it is a good picture of how protocol changes should ship.
mx-chain-vm-go #989: Opcode V2.
what it actually does:
1. the executor now has an opcode version (V1 / V2), picked from a new OpcodeV2Flag
2. V2 whitelists and meters two bulk-memory ops: memory.copy and memory.fill
3. metering is a flat cost plus a per-byte cost, added to gas schedules V3 and V4
4. a nil cost table is rejected — no more silently metering everything at zero
5. when the version or gas schedule changes, both the warm instance cache and the compiled code cache are cleared
6. tests cover metering deltas, memory contents, activation, cache clearing, FFI layout
what it deliberately does not do:
turn the flag on.
activation waits on Wasmer 7 work, the executor management refactor, and the node adding the flag plus the two per-byte costs to its schedules.
that split is the point.
you can merge the metering, the whitelist, the cache rules and the tests weeks before anyone flips the feature. the dangerous part is not the new opcode. it is enabling it with the wrong costs or a stale compiled cache.
V2 also drops legacy exception-handling and reference-type opcodes that do not appear in deployed mainnet contracts. investigated first, then removed from the V2 set. V1 stays as it is.
if you write WASM for MultiversX: nothing changes for you today. when Opcode V2 eventually activates, bulk memory ops become real, priced ops.
It is a PR now, with WAsmer7 and otherr big improvements to come.