Implement EIP 7002 (withdrawal requests) #3385
Conversation
jochem-brouwer
force-pushed
the
eip-7002-new
branch
from
a22191b
to
1235c60
Compare
jochem-brouwer
added
package: evm
PR state: needs review
and removed
PR state: WIP
labels
|
|
||
| // Note: generatedBlock is now overridden with the new generated block (this is thus block number 3) | ||
| // Ensure there are 2 requests | ||
| assert.ok(generatedBlock!.requests!.length === 2) |
There was a problem hiding this comment.
This is a fantastic test. I didn't even think about being able catch the generated block from teh afterBlock event.
There was a problem hiding this comment.
Yes, actually I want to raise a point about this, isn't the entire point of generate to actually retrieve the generated block (i.e. build the block?). I was somewhat surprised that this block was not returned from runBlock so had to figure out if I would be able to extract it (if that was even possible). So this is something we could take a look at in the future (not part of this PR)
|
Just pushed a commit for the final cleanups, thanks for the review @acolytec3. If you could re-approve (after CI passes) then from my side this is OK to merge 😄 |
There was a problem hiding this comment.
Totally agree with Andrew, this looks fantastic! 🤩
Some comments on docs, but totally and solely on the "would make this even better" level, since I think think this is already so close on the self-readability level that we could even jump over "the last hurdle to perfect" (lol). 😝
One side bonus question:
Would it make sense to also add one test to trigger this behavioral part of the withdrawal request contract? Then we would have all the functionality from the contract "covered"?
Or is this over the top since this is normally only called on the user side?
(would nevertheless be a somewhat nice bonus feature - especially in these early stages - that we would then test the withdrawal request contract itself (to some extend).)
| bigIntToBytes(vm.common.param('vm', 'withdrawalRequestPredeployAddress')), | ||
| 20 | ||
| ) | ||
| const withdrawalsAddress = Address.fromString(bytesToHex(addressBytes)) |
There was a problem hiding this comment.
Can we name this a bit more verbose, I would suggest withdrawalRequestContractAddress?
For withdrawalsAddress imagination can go in various - and sometimes wrong - directions what this could mean (address for sending the withdrawals towards e.g.).
| caller: systemAddress, | ||
| gasLimit: BigInt(1_000_000), | ||
| to: withdrawalsAddress, | ||
| }) |
There was a problem hiding this comment.
Can we document the single steps a bit more, so that the whole code gets a bit easier reproduceable/understandable if one is not so deep into the EIP (any more)? 🙂
So this call basically triggers this part from the EIP, right? (respectively, in more practical terms: trigger withdrawal request contract code execution doing these things as described)
So it would be nice if we have some summary docs here like (to be freely adopted):
// Perform a system call to the withdrawal request contract. This triggers the contract to dequeue withdrawal requests from the queue, update excess withdrawal requests, reset the counter and then return the respective requests from the queue.
``
(Is this an accurate high level description?)| bigIntToBytes(common.param('vm', 'withdrawalRequestPredeployAddress')), | ||
| 20 | ||
| ) | ||
| const withdrawalsAddress = Address.fromString(bytesToHex(addressBytes)) |
There was a problem hiding this comment.
Same here: rename would be nice.
https://eips.ethereum.org/EIPS/eip-7002
Ref: https://github.com/ethereum/EIPs/blob/3b5fcad6b35782f8aaeba7d4ac26004e8fbd720f/EIPS/eip-7002.md