Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
EIP-1702: Generalized Account Versioning Scheme #1702
This was originally designed for Ethereum Classic around 2017 (ethereumproject/ECIPs#86). As I saw there're some interests in using account versioning on Ethereum, I thought I would just submit an EIP here.
This defines a method of hard forking while maintaining the exact functionality of existing account by allowing multiple versions of the virtual machines to execute in the same block. This is also useful to define future account state structures when we introduce the on-chain WebAssembly virtual machine.
By allowing account versioning, we can execute different virtual machine for contracts created at different times. This allows breaking features to be implemented while making sure existing contracts work as expected.
Note that this specification might not apply to all hard forks. We have emergency hard forks in the past due to network attacks. Whether they should maintain existing account compatibility should be evaluated in individual basis. If the attack can only be executed once against some particular contracts, then the scheme defined here might still be applicable. Otherwise, having a plain emergency hard fork might still be a good idea.
Between the ewasm and geth team we had similar discussions a few months ago, though it wasn't necessarily a version number in the account, rather VM type.
Versioning different VM types in a linear fashiong would mean EVM cannot be updated after for example WebAssembly is enabled.
In the alternative design, I suggest that validation return the version to be placed in the state field. The nice thing about this versioning mechanism is that it knows nothing about the version number. It is entirely for VM communication in the cycle from code deployment, validation and state through execution and code creation.