Accounting versioning

In the past few months account versioning was a topic of importance due to EIP-615 requiring it. Additionally it could wall off other changes (such as gas changes) to minimize protocol update effects on existing contracts.

There have been a number of proposals for account versioning: EIP-1702, EIP-1707, EIP-1891 as well two auxiliary EIPs EIP-2138 and EIP-2139. All of these proposals were made by @sorpaas.

EIP-1702 was the most reviewed option.

Some of discussion took place on EVM instruction set versioning, and, but mostly it was discussed on the AllCoreDevs gitter channel.

Created this topic here to have a single place to discuss versioning, because tracking all these places became a burden, at least to me.

1 Like

My personal opinion is that account versioning is useful, but it has to be used with great care.

I do see a use case

  • to distinguish between EVM and other bytecode (such as Wasm) or
  • to have different EVM versions when new opcodes are introduced

However locking gas changes into new versions is a double edged sword. On the outset it seems to lock gas changes to new contracts without affecting old ones, but having accounts of different versions interact with each other can easily complicate matters a lot.

Two more issues regarding gas changes locked behind versioning:

  • a reduction of costs cannot be utilised by existing contracts, prompting users to redeploy them, which contributes to state bloat
  • an increase of costs would not affect existing contracts, minimising the intended effect, potentially giving very limited results (one example is repricing SLOAD as per EIP-1884 to reflect the actual workload)

One case where I see account versioning as a “must do” is when backwards incompatible changes are being introduced. I would almost suggest this is the only time a new account version should be considered for introduction.

I see a few places where this would be warranted under the “versioning required” standard

  • introduction of new contract validation rules.
  • prohibition of previously allowed opcodes or constructs
    • such as dynamic jump or dynamic jump from a non-fixed stack value
    • such as invalid opcodes, like you might find in data sections.
  • introduction of a new bytecode, such as eWASM

However we may want to consider “horse trading” version upgrades, such as ones that significantly reduce prices on one set of operations at the cost of raising other sets of operations, such as cheaper precompiles for extremely expensive memory operations. I’m not providing any specific suggestions but am putting it out there as a tool that is available.