feat(archiver): decouple calldata from blob fetching in L1 synchronizer#22472
Draft
spalladino wants to merge 2 commits intomerge-train/spartanfrom
Draft
feat(archiver): decouple calldata from blob fetching in L1 synchronizer#22472spalladino wants to merge 2 commits intomerge-train/spartanfrom
spalladino wants to merge 2 commits intomerge-train/spartanfrom
Conversation
Splits checkpoint retrieval into two phases: first fetch calldata only (header, attestations, archive root), then check if a proposed checkpoint with matching header already exists in the store. If so, skip blob fetching and promote the proposed checkpoint to confirmed. Otherwise, fetch blobs in parallel as before. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
spalladino
added
ci-no-fail-fast
- Move promote to after attestation validation to avoid persisting invalid checkpoints (split into build + persist steps) - Add validateCheckpoint call in promote path - Add archive root comparison to proposed checkpoint match condition - Remove dead retrieveCheckpointsFromRollup and processCheckpointProposedLogs - Pass pendingChainValidationStatus to promote path Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Contributor
Author
|
Got to consider race condition where a proposer pushes their proposed checkpoint to its archiver before the previous checkpoint is checkpointed on L1. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
When the node is a validator that already built a checkpoint locally (via
addProposedBlock+setProposedCheckpoint), the blocks are already in the archiver store. Fetching blobs from the beacon chain is redundant and expensive, especially during sync. This decouples calldata and blob retrieval so we can skip blob fetching when the proposed checkpoint matches.Approach
Split
retrieveCheckpointsFromRollupinto two phases: (1) fetch calldata only (header, attestations, archive root), (2) check the archiver store for a proposed checkpoint with matching header. If found, promote it to confirmed via a fast path. Otherwise, fetch blobs in parallel (sameasyncPool(10, ...)concurrency as before) and store as normal.Changes
CalldataOnlyCheckpointtype,retrieveCheckpointCalldataFromRollup(calldata-only fetch), andfetchBlobsAndBuildPublishedCheckpoint(deferred blob fetch). Existing functions left intact.promoteProposedToCheckpointedmethod that reads existing blocks from store, writes a confirmed checkpoint entry with L1 metadata + attestations, and clears the proposed singleton.promoteProposedToCheckpointed.promoteProposedCheckpointwrapper that handles validation status and tips cache refresh.handleCheckpointsnow partitions calldata checkpoints into promote-vs-fetch-blobs, fetches blobs in parallel for non-matching ones, promotes the matched one, then merges results for validation.Fixes A-877