Skip to content
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

Merged
merged 8 commits into from
Apr 2, 2019

Conversation

sorpaas
Copy link
Contributor

@sorpaas sorpaas commented Jan 15, 2019

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.

@sorpaas sorpaas changed the title EIP-xxx: Generalized Account Versioning Scheme EIP-1072: Generalized Account Versioning Scheme Jan 15, 2019
@sorpaas sorpaas changed the title EIP-1072: Generalized Account Versioning Scheme EIP-1702: Generalized Account Versioning Scheme Jan 15, 2019
@axic
Copy link
Member

axic commented Jan 17, 2019

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.

@gcolvin gcolvin merged commit 29f9e18 into ethereum:master Apr 2, 2019
@gcolvin
Copy link
Contributor

gcolvin commented Apr 12, 2019

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.
EDIT: I think I misunderstand how the version field works, so this is unnecessary.

@axic
Copy link
Member

axic commented May 22, 2019

@sorpaas this EIP doesn't have a copyright statement. Can you please add one? EIP-1 suggests CC0 - see the eip-x.md template.

@axic
Copy link
Member

axic commented Jul 2, 2019

@sorpaas this EIP still doesn't have a copyright statement.

@sorpaas
Copy link
Contributor Author

sorpaas commented Jul 2, 2019

@axic Sorry I missed this. Just added CC0!

@sorpaas sorpaas deleted the sp-account-versioining branch July 2, 2019 11:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants