EIP4844: Add block and sidecar retrival by root #3089
Conversation
|
|
||
| ``` | ||
| ( | ||
| List[SignedBeaconBlockAndBlobsSidecar, MAX_REQUEST_BLOCKS] |
There was a problem hiding this comment.
Should I rename MAX_REQUEST_BLOCKS to include sidecars? I didn't feel strongly about this
There was a problem hiding this comment.
Fine by me. Though another thing is do we wanna tweak the current MAX_REQUEST_BLOCKS value? If a client requests the max and they all contain sidecars, that's a huge amount of data transmitted.
There was a problem hiding this comment.
Unless this is also constrained by the MAX_CHUNK_SIZE.
There was a problem hiding this comment.
I think it is clear as it is
There was a problem hiding this comment.
I do think that we should at least consider MAX_REQUEST_BLOCKS for this and range requests given the size changes. That said, you only MUST respond with 1 in a given request/range so even if the max stays high, clients can down regulate responses and stay to spec
specs/eip4844/p2p-interface.md
Outdated
|
|
||
| Per `context = compute_fork_digest(fork_version, genesis_validators_root)`: | ||
| Clients MUST disable `BeaconBlocksByRoot v2` after `EIP4844_FORK_EPOCH`. |
There was a problem hiding this comment.
what if I want to get a beacon block by root from before the 4844 fork?
seems like we want to keep BeaconBlocksByRootV2 for this purpose or support previous types with the context enum like in the ByRange spec here
There was a problem hiding this comment.
Makes sense. I added back the previous types except for 4844 type
Part of #3088
This PR adds a req-resp RPC for retrieving beacon block and blobs sidecar by root