-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
EIP-1702: Generalized Account Versioning Scheme #1702
Conversation
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. |
…ount-versioining
… sp-account-versioining
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. |
@sorpaas this EIP doesn't have a copyright statement. Can you please add one? EIP-1 suggests CC0 - see the |
@sorpaas this EIP still doesn't have a copyright statement. |
@axic Sorry I missed this. Just added CC0! |
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.
Abstract
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.
Motivation
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.