EIP-1702: Generalized Account Versioning Scheme

[sorpaas]

Discussion thread for account versioning:

• Base layer: 43-VER / EIP-1702 / ECIP-1040
• Extension for contract creation transaction: 44-VERTXN
• Extension for CREATe and CREATE2: 45-VEROP

[nicksavers]

The format of this proposal is missing a few suggested paragraphs from the [eip-X.md](the https://github.com/ethereum/EIPs/blob/master/eip-X.md) template. Please go over that and add the paragraphs here possible.

[gumb0]

If I understand Alternative Design correctly, it's only init code that has prefix, but not the deployed code. Maybe it's worth to clarify this.

Contract Execution
VM version used in contract execution is determined via calling address (I_a in yellow paper).

This sentence is not quite clear. Does it mean that it's determined by the version field of the executed contract? (I guess the edge case here is DELEGATECALL & CALLCODE, better to clarify which version is used, caller or callee)

[sorpaas]

Does it mean that it's determined by the version field of the executed contract?

Yes. I used I_a in yellow paper to specify that. I think it covers the case for DELEGATECALL/CALLCODE. However, it's indeed debatable whether use another variable would be better (for example, use the version field of the code contract).

[sorpaas]

A note regarding upgradable contract and account versioning (posted on Gitter as well) -- my current conclusion is that upgradable contracts are not affected at all by EIP-1702 variant 1 (or variant 2)!

• If the contract uses the proxy contract pattern, it will not be affected. Deployment of the delegate contract happens through contract creation transaction, which deploys the latest VM version.
• If the contract uses a CREATE opcode internally, then the owner can deploy an upgrade (which will be of the legacy version), and use that upgrade to turn the contract into proxy contract pattern. From this point on, the contract can upgrade its VM version. The only potential drawback is just that it will costs slightly more gas (another DELEGATECALL) and use one more call frame depth, because we turned previously one indirection into double indirection.

[sorpaas]

Just did another update to EIP-1702 -- I'm making the version of the execution frame always the same as the account code's version. That is, when fetching code from an account in state, we always fetch the version field of that account together, and "associate" the version with the code. This should be easier to implement (we just need to change all definition of code into (code, version) tuple), and it should provide more sensible results for DELEGATECALL/CALLCODE.

[holiman]

Is it possible to remove the variants that are not to be implemented?

[sorpaas]

@holiman Done! ethereum#2138 ethereum#2139 ethereum#2140

[sorpaas]

Previously we also discussed (most regarding state rent) of how we should order additional account RLP fields. Now I'm thinking, maybe we can just use 1702's version fields to order all other additional fields -- read version field first, and then interpret all fields after version as defined by that particular version. This will not only allow us to add new fields, but also allow us to remove fields if necessary!

I added this to 1702 spec. Note that this will not require any change for current 1702 implementations, but I think it may help us implement things like state rent in the future.

[gumb0]

You removed Alternative Design, but it's still mentioned in Rationale.

[gumb0]

I've been implementing this in aleth (ethereum/aleth#5640), and one edge case to be aware of is creating with empty init code (both with creation transaction and CREATE/CREATE2). When init code is empty, creation ends with a new account with empty code and nonce = 1. I've decided to leave it with version 0 in this case, regardless of parent's version and LATEST_VERSION, because other accounts with no code - EOAs - don't have version.
Let me know if I'm not right, and better to clarify it in EIP (and this definitely should go to the test cases)

[gumb0]

Another nit for the spec: maybe it's worth pointing out in Contract Execution section, that contracts with version 0 are executed with Petersburg VM.

[sorpaas]

You removed Alternative Design, but it's still mentioned in Rationale.

Fixed in ethereum#2152. Thanks!

When init code is empty, creation ends with a new account with empty code and nonce = 1.

@gumb0 What do you think if in this case, we keep the version of the account to still be the parent account version? I feel this may be more consistent:

• We can have different accounts with the same (empty or non-empty) codeHash but with different account versions already. And I feel the situation better falls in this category.
• VM versioning is expected to handle empty codeHash just like any other code -- it's expected to spin up the required VM of the particular version and attempt to execute the "code". (Of course, in case if code is empty, there're many shortcuts we can take.)
• If the CREATE init code succeeds, then to better fit the current versioning intention, the resulting contract is expected to have the same version as its parent. I feel it's better to have no exceptions, that is, no matter code is empty or not.

Another nit for the spec: maybe it's worth pointing out in Contract Execution section, that contracts with version 0 are executed with Petersburg VM.

I have small worries that people may still want to apply EVM features to version 0 in Istanbul, until we're all used to account versioning. So maybe we want to finalize this in Istanbul meta EIP but not in EIP-1702.

[gumb0]

I think I don't mind either way, it's either slight confusion of having empty code accounts with different versions, or slight confusion of family of contracts not always producing their version.

Version 0 takes less space to store account, but I guess it shouldn't be significant difference here, as it's a rare case anyway.

It might become important to always produce strictly the same version, if at some point your idea about parsing additional fields based on version field is implemented.
(but to me that idea feels like conflating "version of code executor" and "version of account format", so I'm not completely sure it's good)

[sorpaas]

Version 0 takes less space to store account, but I guess it shouldn't be significant difference here, as it's a rare case anyway.

Yeah agreed. I think it won't make much difference in storage size as it's only a corner case.

It might become important to always produce strictly the same version, if at some point your idea about parsing additional fields based on version field is implemented.

I think this may be a good reason to keep empty-code account (note it's not empty account!) of the parent account's version. Consider if we implement state rent via some additional fields with versions, then by using this scheme we can make sure those new empty-code account are garbage collected. However, if we set empty-code account to version zero, then this won't work.

Conflating "version of code executor" and "version of account format"

I don't think this is actually a bad thing. In the contrary, for some EIPs this is strictly needed. Consider EIP-2027, where we keep a contract size counter as an additional field in the account -- the code executor must support contract size counter (by slightly changing behavior of SSTORE) to make the spec work. It's nearly impossible to completely separate them out.

So if it's okay for you, maybe let's keep the current behavior (empty-code account has the same version of parent account)!