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.

Sign up for GitHub

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

Update EIP-6800: EOFv1 tweaks #8713

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from
+9 −4
Draft

Update EIP-6800: EOFv1 tweaks #8713

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 9 additions & 4 deletions EIPS/eip-6800.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -116,7 +116,7 @@ Instead of a two-layer structure as in the Patricia tree, in the Verkle tree we
| Parameter | Value |
| --------------------- | ------- |
| BASIC_DATA_LEAF_KEY | 0 |
| CODE_KECCAK_LEAF_KEY | 1 |
| CODEHASH_LEAF_KEY | 1 |
| HEADER_STORAGE_OFFSET | 64 |
| CODE_OFFSET | 128 |
| VERKLE_NODE_WIDTH | 256 |
Expand Down Expand Up @@ -158,8 +158,8 @@ def get_tree_key_for_basic_data(address: Address32):
return get_tree_key(address, 0, BASIC_DATA_LEAF_KEY)

# Backwards compatibility for EXTCODEHASH
def get_tree_key_for_code_keccak(address: Address32):
return get_tree_key(address, 0, CODE_KECCAK_LEAF_KEY)
def get_tree_key_for_codehash(address: Address32):
return get_tree_key(address, 0, CODEHASH_LEAF_KEY)
```

An account's `version`, `balance`, `nonce` and `code_size` fields are packed in the value found at `BASIC_DATA_LEAF_KEY`:
Expand All @@ -175,7 +175,12 @@ Bytes `1..4` are reserved for future use.

Note: the code size is stored on 3 bytes. To allow for an extension to 4 bytes without changing the account version is possible, reserved byte #4 should be allocated last.

When any account header field is set, the `version` field is also set to zero. The `code_keccak` and `code_size` fields are set upon contract or EoA creation.
The `code_hash` and `code_size` fields are set upon contract or EoA creation.

`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.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 for reading version and keeping things simple, efficiency/optimizations can be done by client and 200 as you mentioned is quite nominal gas

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

whats your take @jsign ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


#### Code

Expand Down
Loading