Update EIP-4788: Bound precompile storage#7178
Conversation
github-actions
bot
added
c-update
|
✅ All reviewers have approved. |
ralexstokes
force-pushed
the
bound-4788-storage
branch
from
7aa0b29 to
50315b6
Compare
ralexstokes
changed the title
ralexstokes
force-pushed
the
bound-4788-storage
branch
2 times, most recently
from
deb13c6 to
4c6e3cb
Compare
djrtwo
left a comment
djrtwo
left a comment
There was a problem hiding this comment.
nice! a bit strange, but I like it
EIPS/eip-4788.md
Outdated
| ``` | ||
|
|
||
| If there is no timestamp stored at the given root, the opcode follows the existing EVM semantics of `sload` returning `0`. | ||
| Alongside the existing gas for calling the precompile, there is an additional gas cost of `G_beacon_root` to reflect the two (2) implicit `SLOAD`s from |
There was a problem hiding this comment.
What do you mean "existing gas"? Do you mean CALL costs? I would be a bit more specific.
Also, is the cost of the SLOAD sufficient because it's dominant or should we estimate the other operations (adds, assignments, etc)
Also, this could be priced cheaper than SLOAD if we just assume these two buffers are held in memory. That said, diverging from treating it just like native code/storage is probably not great for stateless and other things
There was a problem hiding this comment.
Do you mean CALL costs? I would be a bit more specific.
yes, the idea is that as a user I need to CALL the precompile and I want to say on top of whatever existing costs to get to this point in the execution, let's add in some extra gas to reflect the SLOADs, ill make another pass on the language
There was a problem hiding this comment.
Also, is the cost of the SLOAD sufficient because it's dominant or should we estimate the other operations (adds, assignments, etc)
I have not done a rigorous analysis but I think we can safely say the state reads will be the dominant cost here; otherwise there are just a few native operations that should relatively be free
priced cheaper than SLOAD if we just assume these two buffers are held in memory
I wouldn't want to make this assumption unless we got consensus from all EL devs that this was to be expected
ralexstokes
force-pushed
the
bound-4788-storage
branch
from
5c16f91 to
22bd1e5
Compare
ralexstokes
force-pushed
the
bound-4788-storage
branch
from
8a0075b to
c9fbcbd
Compare
eth-bot
changed the title
eth-bot
added
a-review
ralexstokes
force-pushed
the
bound-4788-storage
branch
from
c9fbcbd to
613c665
Compare
ralexstokes
changed the title
|
Also I just realized this (regarding testnets): There is a super ugly edge case here, in which you do not pre-fund the 0x0B address in genesis. In that case, the balance is 0, the nonce is zero, and the code is the empty code hash. The storage however, will be non-empty starting at the fork block. However, this still means that the account is empty as per https://eips.ethereum.org/EIPS/eip-158. This means that if someone calls into 0x0B on the testnet (but does not fund it), then this should cleanup the account after the tx, thus wiping the storage. Not sure if it should be mentioned anywhere in the EIP, since I think most (all?) testnets pre-fund the precompile addresses with 1 wei, but I could imagine this gets messed up in testing setups if they set it up privately 🤔 (It is super weird if you call with tx1 into the contract to get timestamp X, and then call in the same block again into the contract again with timestamp X, and now get a zero result while it was nonzero before 🤔 ) |
|
yeah it sounds like the working knowledge is to pre-fund precompiles to avoid this behavior (cc @MariusVanDerWijden ) I can add a note to the EIP |
eth-bot
left a comment
eth-bot
left a comment
There was a problem hiding this comment.
All Reviewers Have Approved; Performing Automatic Merge...
5 participants
No description provided.