pectra devnet4: implement pectra devnet4 spec #3706
Conversation
|
Can we use this PR as devnet-4 branch and not merge this until devnet-4 is specced out completely? Ref for further additions: ethereum/execution-spec-tests#832 Devnet-4 spec https://notes.ethereum.org/@ethpandaops/pectra-devnet-4 |
|
yes apparently the address specified in the 7002 eip and in the genesis generator changes don't match in EIP: in genesis generator PR: |
|
ah there's probably an update missing. lemme me clear that up and get back to you! |
|
are you sure @g11tech ? EIP update was merged in: https://github.com/ethereum/EIPs/pull/8890/files#diff-70472fac1debb567783ce13873323261713f3ce488a26a5c3769a9193f4a7e27R521 which is the address we used in the genesis generator: https://github.com/ethpandaops/ethereum-genesis-generator/pull/143/files#diff-e563a01282cd9e2db47dceb99a9337f1f37466f6bfe5d10b376435d51f179f34R114 |
yes i am sure as of the current published EIP :)
as well as latest github file
|
|
I just manually checked the EIP-7002 data, I get this: sender: |
|
@parithosh I just saw that the address got updated again in this commit: ethereum/EIPs@a23be81 In this PR: This changed code, so it also changed the address. (I assume this is included in devnet-4?) |
packages/vm/src/params.ts
Outdated
| @@ -78,7 +78,7 @@ export const paramsVM: ParamsDict = { | |||
| 7002: { | |||
| // config | |||
| systemAddress: '0xfffffffffffffffffffffffffffffffffffffffe', // The system address to perform operations on the withdrawal requests predeploy address | |||
| withdrawalRequestPredeployAddress: '0x00A3ca265EBcb825B45F985A16CEFB49958cE017', // Address of the validator excess address | |||
| withdrawalRequestPredeployAddress: '0x05F27129610CB42103b665629CB5c8C00296AaAa', // Address of the validator excess address | |||
There was a problem hiding this comment.
This is the address of this commit: ethereum/EIPs@1335765
The latest commit (which shows up on eips.ethereum.org) is ethereum/EIPs@a23be81 pointing to 0x0511Ce19514e1298Fba96de582652A016E2CAaAa
There was a problem hiding this comment.
yes @parithosh mentioned there are a few more updates coming through, so we gotta hold on
|
Fixed merge conflicts, if I messed up please rollback to 7cd91a2 |
|
Have updated the PR (have not fixed tests) to reflect these EIP PRs: ethereum/EIPs#8924 I have also added support for the devnet-4 t8ntool interface, can be used to fill ethereum/execution-spec-tests#832 (I got a few filled tests, so the interface works, until I ran in a bug at EEST side). |
|
We can actually get rid of the whole |
Oh, that's a major one we should absolutely do before the releases, can you please (don't need to be long) open a dedicated issue on this so that we do not forget? |
|
The idea was actually to directly do that here :) EDIT: this is also the result of the EIP revamps for the requests, I think this will naturally follow once we integrate it. |
|
Never mind, removing them actually does not sounds like a good idea. The classes are now handy to also directly decode the raw bytes, which is handy for the end-user. |
…n for buildblock and runblock and corresponding requestsroot calcs
…x the test including fixing a logs bloom bug in the generate fields block generation
packages/util/src/request.ts
Outdated
| index: bigIntToHex(this.index), | ||
| } | ||
| export class DepositRequest extends CLRequest<CLRequestType.Deposit> { | ||
| constructor(requestData: Uint8Array) { |
There was a problem hiding this comment.
Is it useful to have these sub classes now since they are functionally identical? Couldn't we just have a CLRequest class and then use the type property to distinguish between them?
packages/util/src/request.ts
Outdated
| export function createCLRequest<T extends CLRequestType>(bytes: Uint8Array): CLRequest<T> { | ||
| switch (bytes[0]) { | ||
| case CLRequestType.Deposit: | ||
| return new DepositRequest(bytes.subarray(1)) as CLRequest<T> |
There was a problem hiding this comment.
As above. Do we really need this? Feels very duplicative.
|
Just merged, thanks a lot all! 😄 👍 |
| @@ -4,7 +4,7 @@ export * from './consensus/index.js' | |||
| export { type BeaconPayloadJSON, executionPayloadFromBeaconPayload } from './from-beacon-payload.js' | |||
| export * from './header/index.js' | |||
| export { | |||
| genRequestsTrieRoot, | |||
| genRequestsRoot, | |||
There was a problem hiding this comment.
Should we call this genRequestsHash ?
There was a problem hiding this comment.
Yep this is actually a better name since it is not a trie root anymore!
|
🎉 |
refrence:
https://notes.ethereum.org/@ethpandaops/pectra-devnet-4