Add EIP: EOF - Prepare for Address Space Extension #8385
Conversation
Update EOF opcodes so addresses are not trimmed during execution, reverting with an exception if the address is invalid.
github-actions
bot
added
c-new
|
✅ All reviewers have approved. |
eth-bot
added
e-consensus
eth-bot
changed the title
EIPS/eip-ase.md
Outdated
|
|
||
| ## Specification | ||
|
|
||
| The `BALANCE` operation, when invoked in code in an EOF container, will reauire the top 12 bytes of |
There was a problem hiding this comment.
An interesting side effect is that this provides a cheap (in terms of codesize, not gas) way of checking that there are no high bits set in a stack item.
There was a problem hiding this comment.
Cheap? It's going to get hit with a cold-account charge on success - https://eips.ethereum.org/EIPS/eip-2929 - and a revert on failure. I thing PUSH1 0x20 SHR ISZERO would be cheaper.
There was a problem hiding this comment.
"cheap" - as in smaller bytecode. i don't think it is that practical unless you have really strong codesize constraints, i'm just pointing out that it's a new side effect.
EIPS/eip-7069.md
Outdated
| 4. Peform (and charge for) memory expansion using `[input_offset, input_size]`. | ||
| 5. If `target_address` is not in the `warm_account_list`, charge `COLD_ACCOUNT_ACCESS - WARM_STORAGE_READ_COST` (2500) gas. | ||
| 6. If `target_address` is not in the state and the call configuration would result in account creation, charge `ACCOUNT_CREATION_COST` (25000) gas. | ||
| 4. Halt with exception if any of the high 96 bits of the `target_address` are set. |
There was a problem hiding this comment.
There is an option to leave EIP-7069 intact, and put this step as an expansion of EXT*CALL logic into the new EIP-7676. The advantage is decoupling EIPs and not leaving this step without its due motivation described in EIP-7069 (or worse, having to reference circularly the EIP-7676).
But I'm not strongly against laying this out like is done now.
There was a problem hiding this comment.
It's the scattering of call across only two EIPs that concerns me. For vanilla validation it's already across multiple, and the rules focus on the operations in those EIPs. But splitting operational steps across EIPs I am concerned will result in implementations overlooking the detail.
|
@axic, @g11tech, @gcolvin, @lightclient, @SamWilsn is there anything keeping this from being merged? |
could you separate out the update from new eip addition please |
|
Will separating out parallel updates be a standard request of all new EIPs? If so, should that be baked into validation checks? |
EIPS/eip-7676.md
Outdated
| Any new operation with an address operand on the stack, or any operation that is un-banned from EOF | ||
| that has an address operand on the stack will have the same behavior as `BALANCE` when validating | ||
| the address operand. |
There was a problem hiding this comment.
| Any new operation with an address operand on the stack, or any operation that is un-banned from EOF | |
| that has an address operand on the stack will have the same behavior as `BALANCE` when validating | |
| the address operand. |
i think we shouldn't do an "auto" scope expansion, either this EIP needs to be edited (before going to final) or new EIPs need to come if any scope expansion needs to be done. for new operation, it should mention it follows this EIP
Still this could be a useful context/direction and could be worthwhile to put in the abstract.
There was a problem hiding this comment.
Moved to backwards compatability section and made it advisory.
yea I guess we should do that. added few nits else should be gtm |
|
Nits addressed. Please merge. |
|
@axic, @g11tech, @gcolvin, @lightclient, @SamWilsn is there anything keeping this from being merged? |
|
approved, not sure why bot isn't working |
|
The commit 1216936 (as a parent of dd54187) contains errors. |
eth-bot
left a comment
eth-bot
left a comment
There was a problem hiding this comment.
All Reviewers Have Approved; Performing Automatic Merge...
|
Not a link but a reference by name. Eth-bot shut that one down quick. How else would you propose acknowledge existing tests and reference implementations? In this case calling out it's specific location seemed warranted because the organization of tests for that case is fairly non-intuitive, and expecting the readers to do a search themselves without signposts moves it in the direction of "trust me bro, tests exist." |
|
We still treat "references by name" as links. It's just easier to detect URLs than vague English 🤣 Interestingly we do allow links to EEST: Lines 151 to 152 in 6a0a792 Would it be useful to consider allowing links to |
10 participants
Update EOF opcodes so addresses are not trimmed during execution,
reverting with an exception if the address is invalid.