-
Notifications
You must be signed in to change notification settings - Fork 765
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.
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
EIP-2929: Gas cost increases for state access opcodes #889
Conversation
Codecov Report
Flags with carried forward coverage won't be shown. Click here to find out more. |
packages/vm/lib/evm/opFns.ts
Outdated
|
||
return defaultCost | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a concrete suggestion yet, was just wondering since the list of additional helper functions is getting so long:
Should we restructure opcode-related functionality a bit, a first suggestion would be:
opcodes.ts
->opcodes/(op)codes.ts
opFns.ts
(opcode implementations) ->opcodes/functions.ts
opFns.ts
(all helper functions) ->opcodes/util.ts
Eventually the latter also split up:
opFns.ts
(EIP2929 helper functions) ->opcodes/EIP2929.ts
What do you guys think 🤔 ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@holgerd77 Agree, the helpers alone are starting to be a few hundred lines...
Happy to open that as an issue and self-assign if there's agreement this is the way to go...
Would be a separate PR which we rebase this against eventually?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree to split up this file 😄 , but should be a seperate PR 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, makes sense to keep this separate
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is rebased against the file re-org now...
Above it's suggested that:
Eventually the latter also split up:
- opFns.ts (EIP2929 helper functions) -> opcodes/EIP2929.ts
In 8cdc9b0 have extended this idea and moved updateSstoreGas
out of util
splitting it into it's own EIP files.
Idk - this might be more than was necessary - idea is just to make util
generic and order dynamic gas pricing logic consistently.
Some refunds spec'd by EIP-2200 needed additional adjustments... Made in 62eb4b8, mirroring these geth commits: There's a PR updating state tests for YOLO V2 at ethereum/tests 723 |
@cgewecke thanks for all the updates here 😃 , make sure to remove |
(and optimally also drop a short note, "just" these status changes also have a tendency to be overlooked for some time since there is not notification associated (I would say at least, or is there some associated with this new explicit "Ready for review" feature baked into GitHub)) |
Next step might be to run against the Berlin/YoloV2 tests when they're merged (and see if there are bugs here...) |
What is this the status here? Any updates on the state of agreement regarding this EIP? It might also be good to give this PR a rebase to not loose track with the code base too much. |
Status
Will rebase rn. |
@@ -135,7 +135,7 @@ export default class VM extends AsyncEventEmitter { | |||
|
|||
if (opts.common) { | |||
//EIPs | |||
const supportedEIPs = [2537] | |||
const supportedEIPs = [2537, 2929] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you also add a note on the support of this EIP in the code docs above (line 43, so annoying that GitHub doesn't allow comments on non-changed code parts)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed in e922e1b
Great and thanks for the update! 😄 I would suggest that we review here and merge this in also for the dev release and eventually see if we can harden the implementation during the dev release feedback period. Is this ok? Support for this EIP will be still experimental anyhow. |
Yeah! That's sounds good to me. The other implementations have been stable for a few weeks and we can fix any problems when we update state tests here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have rebased this and integrated the new Address type.
This looks good now, thanks Chris for tackling this and bringing this to the latest state and over the finish line! 😄
Will merge.
@jochem-brouwer yes, definitely, feel free to just do on such cases, always some continued challenge to keep up here with this housekeeping stuff. If people disagree they will likely reopen (doesn't happen too often though anyhow). |
* @param {BN} address | ||
*/ | ||
export function accessAddressEIP2929(runState: RunState, address: Address, baseFee?: number) { | ||
if (!runState._common.eips().includes(2929)) return |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just seeing here that this implementation has also these common.eips().includes()
calls. We should really replace this soon by a method in common also taking the HFs into account. This will otherwise fall onto our feet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(so "soon" means: in the next 1-2 weeks)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wanted to introduce this in the EIP2718 PR, but won't do it as it will get too bloated otherwise. Can you open an issue for this so we don't "forget" it? 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will just prioritize this as the first task I'll do on Monday, so we won't forget then. 😄
EIP-2929
Test cases
Discord discussion of implementation
Ethereum Magicians thread
hyperledger/besu PR
geth PR
PR passes the initial tests written by holiman. May need some additional work when run against the YoloV2 state tests (which remain WIP as of Oct 20, 2020). Where tests are identified as missing below we can defer to the state tests which should include them for free.
Background
"A short-term security improvement to reduce the effectiveness of what is currently the most effective DoS strategy, reducing the theoretical max processing time of a block by ~3x, and also has the effect of being a stepping stone toward bounding stateless witness sizes"
Specification Details
Initialization
Maintain two sets
accessedAddresses
: Set[Address]accessedStorage
: Map[Address --> Set[Bytes32]] .When a transaction execution begins,
accessedStorage
is initialized to emptyaccessedAddresses
is initialized to include:tx.sender
,tx.to
(or the address being created if it is a contract creation transaction)Address Read Costs
When an address is the target of the opcodes listed above, the gas costs are computed as follows:
accessedAddresses
accessedAddresses
For CREATE/2
accessedAddresses
For SELFDESTRUCT
accessedAddresses
accessedAddresses
Storage Read and Store Costs
For SLOAD,
accessedStorage
accessedStorage
For SSTORE
accessedStorage
accessedStorage