-
Notifications
You must be signed in to change notification settings - Fork 280
introduce ForkedBlobSidecar
for EIP-7688 Electra period before PeerDAS
#6451
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
Conversation
On `ELECTRA_FORK_EPOCH`, PeerDAS is not yet activated, hence the current mechanism based on `BlobSidecar` is still in use. With EIP-7688, the generalized indices of `BeaconBlockBody` get reindexed, changing the length of the inclusion proof within the `BlobSidecar`. Because network Req/Resp operations allow responses across fork boundaries, this creates the need for a `ForkedBlobSidecar` in that layer, same as already done for `ForkedSignedBeaconBock` for similar reasons. Note: This PR is only needed if PeerDAS is adopted _after_ EIP-7688. If PeerDAS is adopted _before_ EIP-7688, a similar PR may be needed for forked columns. Coincidental `Forked` jank can only be fully avoided if both features activate at the same epoch, actual changes to blobs aside. Delaying EIP-7688 for sole purpose of epoch alignemnt is not worth it.
3a403ba
to
d028bae
Compare
Is this particularly possible now? PeerDAS appears to 100% be in Fulu, so I don't see the scenario where PeerDAS is adopted after EIP-7688, even if EIP-7688 also lands in Fulu. |
I need this branch for 7688 testing, it is marked as draft. |
* track execution requests for builder API * insert the builder execution requests into the shim state transition
nimv2_2 failure is due to CI using incorrect Nim 2.0.6 version |
Integrated into This will eventually be rebased on top of Fulu, making this particular component irrelevant (as Fulu likely transitions away from |
On
ELECTRA_FORK_EPOCH
, PeerDAS is not yet activated, hence the current mechanism based onBlobSidecar
is still in use. With EIP-7688, the generalized indices ofBeaconBlockBody
get reindexed, changing the length of the inclusion proof within theBlobSidecar
. Because network Req/Resp operations allow responses across fork boundaries, this creates the need for aForkedBlobSidecar
in that layer, same as already done forForkedSignedBeaconBock
for similar reasons.Note: This PR is only needed if PeerDAS is adopted after EIP-7688. If PeerDAS is adopted before EIP-7688, a similar PR may be needed for forked columns. Coincidental
Forked
jank can only be fully avoided if both features activate at the same epoch, actual changes to blobs aside. Delaying EIP-7688 for sole purpose of epoch alignemnt is not worth it.