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)
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.