-
Notifications
You must be signed in to change notification settings - Fork 757
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
VM, Tx, Common: Implement EIP3860 "limit and meter initcode" #1619
Conversation
Codecov Report
Flags with carried forward coverage won't be shown. Click here to find out more. |
|
Some reference: Transaction tests for EIP-3860 PR ethereum/tests#1012 |
Ah those are new, thanks @holgerd77 😄 Seems like we can test this now! |
We should also require #1701 here due to the added TransactionTests. Will continue here to see if I can figure out what's causing the tests to fail. |
Updated to latest version, tests pass on |
So would you regard this as ready for review? |
We could do a preliminary review, the problem is that the EIP will most likely get changed (in particular gas costs), so I don't think we should merge it already. |
@jochem-brouwer ah ok, sorry, wasn't aware of that, then let's wait. Just had a look: Go Ethereum PR is also still in a |
@jochem-brouwer which part do you mean? Though in your implementation it seems everything relevant is in the config file (limits and gas costs), so it shouldn't be a big deal. |
@axic This comment: ethereum/tests#990 (comment) The EIP spec (text) would thus get updated, but it seems that the tests already match what "the probable direction EIP spec will go", so in that case nothing would change in this implementation. |
@jochem-brouwer I guess since @axic is one of the EIP authors we can then relatively safely merge here? |
(or: review and merge) |
I just re-read the EIP and noticed that there is a check which I have not yet added (check that a contract creation tx has a calldata payload |
I think the EIP and tests should be in sync now, and the test suite will only be merged once geth merges the code? I do appreciate your work here quite a bit, as any second implementation can unearth questions, just like it did for you @jochem-brouwer. |
Hi @axic, the ethereum/tests PR is currently not in sync with the EIP spec. This line from the EIP:
In those cases, all gas in the frame is consumed, but in ethereum/tests only the gas cost of I also agree with you on the second implementation thing - in fact, I think this should be considered for all EIPs which change execution logic. Second implementations will be a "check" to see if the EIP spec is not ambigous and if you can thus use the self-contained EIP to implement it. I will also start implementing other EIPs which are considered for Shanghai. It is both very fun to implement those, and it is also healthy for the ecosystem to ensure that the EIPs are correct 😄 |
Pinging @gumb0 about this 😬 |
Wait, that is the line from Rationale, it refers to already existing (non-creation-specific) failure cases, and says new failures from this EIP don't do this. (So I believe it should be in sync with tests now) |
Ah right, upon re-reading I agree that it indeed matches the current EIP spec. I do think that the addition of these "3 checks" is a bit confusing though (this lead me to believe I should spend all gas). For clarity it might be better to add a line like "in case the initcode limit is violated when trying to execute CREATE/CREATE2, then only the upfront gas is consumed: this is thus the base cost + memory expansion cost + initcode cost (+ hashing cost (CREATE2)), and 0 is put on the stack". I think the addition of mentioning the cases where all gas is consumed is not necessary and would only lead to confusion. But it might also be my poor reading ability to lead to implement the "wrong" version 😅 |
To test TransactionTests:
(They pass) |
@@ -135,6 +135,16 @@ export default class Transaction extends BaseTransaction<Transaction> { | |||
} | |||
} | |||
|
|||
if (this.common.isActivatedEIP(3860)) { |
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 block is in all three transaction types, the reason is that we do not have access to common in baseTransaction. Adding it in baseTransaction is somewhat hard as especially legacyTransaction has some extra logic to extract chainId.
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.
hm. i don't like how we have to keep duplicating code across the txs classes like this. but thanks for the reasoning why.
would be much better if we always write the code just once. what if we move it to a method inutil.ts
called e.g. checkMaxInitCodeSize()
, then we can just keep the if isActivatedEIP(3860) and call the method inside.
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.
other than that, PR looks great! I'm not sure why the errors don't have any coverage on them though (I'm seeing codecov warnings), i assume the added TransactionTests should cover that. if not maybe we should add a few explicit tests for coverage.
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.
Yep, great suggestion moving it to util
! I also did not like 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.
Addressed this
execResult: { | ||
returnValue: Buffer.alloc(0), | ||
exceptionError: new VmError(ERROR.INITCODE_SIZE_VIOLATION), | ||
gasUsed: message.gasLimit, |
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.
When I read the EIP, it says that if a "create transaction exceeds MAX_INITCODE_SIZE
, transaction is invalid." Does that mean that we do an exceptional abort and consume all gas or that the transaction is just rejected and not included in the block?
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 went ahead and added a new EIP-3860 test file to the api/EIPs
section and added a real basic test to trigger this error so we can bump test coverage.
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.
It is the latter, I remember having the same question and it is answered somewhere, but I cannot find it again 😅 So, the block is invalid if you include such transaction and nodes will reject that broadcasted block.
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.
Latest comments from @ryanio have been addressed, will approve and merge.
Thanks Jochem! 🙂 Cool! 👍
Hmm, codecov is not reporting. 🤔 Will nevertheless merge here. |
Implements https://eips.ethereum.org/EIPS/eip-3860
Requires #1617
Note: EIP is in review but it is likely that some details get changed.
To test:
Another note: the current tests do not match the EIP spec so at this point we cannot test it because the tests are invalid.