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

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 added some commits Jan 15, 2019

@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

sorpaas added some commits Jan 15, 2019

@axic

This comment has been minimized.

Copy link
Member

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

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@gcolvin

This comment has been minimized.

Copy link
Collaborator

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

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link
Member

commented Jul 2, 2019

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

@sorpaas

This comment has been minimized.

Copy link
Contributor Author

commented Jul 2, 2019

@axic Sorry I missed this. Just added CC0!

@sorpaas sorpaas deleted the sorpaas:sp-account-versioining branch Jul 2, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.