Update EIP-6800: EOFv1 tweaks #8713
Conversation
github-actions
bot
added
c-update
|
✅ All reviewers have approved. |
eth-bot
changed the title
| `version` can have two values: | ||
|
|
||
| * `0`, in which case this is a legacy contract. `code_hash` and `code_size` have the meaning they do in legacy contract; | ||
| * `1`, in which case this is an EOFv1 contract. The `code_size` field isn't set, and the `code_hash` leaf isn't created, as these values are known by the client. |
There was a problem hiding this comment.
This has two consequences:
- A new account version is created - if this is a problem, the bit can be set somewhere else
- Values for code hash and size are not set. This is nice because it reduces the amount of computation required, as well as the costs. The drawback is that charging the gas costs for
EXTCODEHASHfor legacy contracts would become even more expensive: one would need to read the basic account data leaf in order to figure out if the code hash leaf should be read.
There was a problem hiding this comment.
I think we should encode in the spec how we differentiate EOFv1 contracts. Specifically saying it is a contract starting with the two bytes 0xEF00 should be sufficient, and will keep design space open for EIP-7702's redirect markers.
There was a problem hiding this comment.
The drawback is that charging the gas costs for EXTCODEHASH for legacy contracts would become even more expensive: one would need to read the basic account data leaf in order to figure out if the code hash leaf should be read.
@gballet, despite charging more gas, I think the current EXTCODEHASH might be violating a principle we decided to hold in the last interop discussion, reg always reading version to be future-proof. As you mentioned, EXTCODEHASH doesn't do that today, and I think it might not be right.
If we end up having to read basic_data, this might indirectly resolve another pending discussion reg gballet/go-ethereum#420 (cc @g11tech)
There was a problem hiding this comment.
ok so I went over the current code, and it would make sense to read the version first, according to our principle. It's "only" another 200 gas compared to just reading the code hash leaf. (Checked with @Amxx, it's not a very common call in any case).
Another approach would be to just recognize the pattern of the code hash, and then decide based on this, what course of action should be taken. It's more efficient, but it seems that it's not worth the effort.
There was a problem hiding this comment.
+1 for reading version and keeping things simple, efficiency/optimizations can be done by client and 200 as you mentioned is quite nominal gas
There was a problem hiding this comment.
yeah but in case of a 7702 contract, you would have to read the version, then the code's first chunk, and then the final slice. This is a bit annoying, because the information stored in the first code slice is redundant with the account version.
There was a problem hiding this comment.
Now, we will eventually need to support another account version and in this case, the value will always have to be read, but is it worth doing that read until we do have another version?
There was a problem hiding this comment.
@g11tech , shared in some other place but also sharing here.
I'm not sure VERSION might be the right place, compared to using some of the reserved bytes in BASIC_DATA. VERSION sounds to me like semantics at the tree level, not account level.
For example, today version=0 is interpreting the 256-slots as BASIC_DATA+CODE_HASH. If tomorrow we want BASIC_DATA+CODE_HASH+SOMETHING_NEW, that would be version=1. Said differently, how to interpret the 256-slots.
For account level stuff, I think we can keep version=0 and use the reserved bytes. We're still using BASIC_DATA bits anyway so the implications of this option reg witness size and similars are the same. My point is mainly around VERSION vs reserved bytes depending on what version means.
|
There has been no activity on this issue for six months. It will be closed in 7 days if there is no new activity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review. |
@gballet check this |
This is a proposal to modify how EOFv1 accounts are stored. A single bit is used to mark an account as an EOFv1 contract. The values returned by
EXTCODECOPY,EXTCODEHASHandEXTCODESIZEare known by just reading this bit, which removes the needs to read the first code chunk.The bit is stored in the
versionfield of the basic account data leaf, effectively creating a new account version.