merge queue: embarking unstable (cf259e7) and [#9347 + #9383] together#9390
Closed
mergify[bot] wants to merge 18 commits into
Closed
merge queue: embarking unstable (cf259e7) and [#9347 + #9383] together#9390mergify[bot] wants to merge 18 commits into
mergify[bot] wants to merge 18 commits into
Conversation
…oas-post-bid-api
Lookup sync no longer downloads or processes blobs. Block lookups and data-column (custody) lookups are unchanged, and range sync and blob serving (BlobsByRoot responses) are left fully intact. Deneb/electra blocks with blobs now resolve their blob data from the EL rather than via lookup sync; a block lookup for such a block completes on the block alone (ComponentRequests::NotNeeded). Tests that previously supplied blobs through the removed lookup path now make blobs available via the data availability checker, simulating EL provision. Removed: lookup blob request/response/processing path (blob_lookup_request, on_single_blob_response, send_blobs_for_processing, BlobRequestState, BlockProcessType::SingleBlob, SyncRequestId::SingleBlob, send_rpc_blobs / generate_rpc_blobs_process_fn / process_rpc_blobs, blobs_by_root.rs request module).
Blobs are no longer part of the consensus-layer data-availability check for Deneb/Electra; they are sourced from the execution layer (and still stored, served, and range-synced). `make_available` returns `NoData` for pre-PeerDAS blocks instead of waiting for blob sidecars, and `AvailableBlock` construction treats blobs as optional (only custody columns gate availability post-PeerDAS). Tests: removed the blob-EL-simulation scaffolding only needed while blocks waited for blobs; `empty_blobs_into_responses` asserts the block is available without blobs (pinned pre-PeerDAS); deleted `block_in_da_checker_skips_download` (premise gone). electra + fulu network tests pass; make lint-full clean.
Revert non-essential comment changes and drop the obsolete `empty_blobs_into_responses` coupling test (and its now-unused `blobs_id` helper) — it asserted the removed "missing blobs => coupling error" behavior.
The deneb on_block fork_choice vectors invalid_data_unavailable, invalid_wrong_blobs_length and invalid_wrong_proofs_length expect the block to be rejected purely because its blob sidecars are unavailable or have a mismatched length. Lighthouse no longer enforces blob data-availability at the consensus layer for pre-PeerDAS (Deneb/Electra) blocks (blobs are sourced from the EL), so these blocks now import. The provided blobs still pass KZG verification, so distinguish this case (blob_success && block_imported) from genuinely-invalid vectors like invalid_incorrect_proof, which still fail.
Update comments to reflect changes in blob data availability enforcement.
…u) and empty_blobs_into_responses Restore two tests dropped during the blob-lookup deprecation: - block_in_da_checker_skips_download: migrate to new_after_fulu(). The premise (block stays in the da_checker as MissingComponents until its data arrives) no longer holds pre-PeerDAS, where blocks import immediately without blobs, but does hold post-Fulu where custody columns gate availability. Restores the insert_block_to_da_chain_and_assert_missing_componens helper unchanged. - empty_blobs_into_responses: restore the coupling test (plus blobs_id helper and BlobsByRangeRequestId import) asserting that a range request with blocks but no blobs now succeeds, since blobs are no longer required for availability.
Per review feedback, the blob_da_only_invalidity logic is equivalent to simply asserting that a block the spec marks valid must import. valid=false vectors that expect rejection purely due to unavailable/mismatched blobs now import (blobs are sourced from the EL), and we no longer treat that as a failure.
Per review, revert the diagnostic NotNeeded reason for the no-lookup-sync blob branch back to "outside da window".
…mments - fork_choice: keep the original DidntFail message verbatim; only the condition changes (assert valid blocks import, ignore blob-DA failure cases). - coupling test: blobs are not sourced from the EL; drop that claim.
This was referenced Jun 1, 2026
|
|
1 similar comment
|
|
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
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.
🎉 This combination of pull requests has been checked successfully and will be merged soon. 🎉
Branch unstable (cf259e7) and [#9347 + #9383] are embarked together for merge.
This pull request has been created by Mergify to speculatively check the mergeability of [#9347 + #9383].
You don't need to do anything. Mergify will close this pull request automatically when it is complete.
Required conditions of queue rule
defaultfor merge:#approved-reviews-by >= 1[🛡 GitHub branch protection]POST beacon/bidendpoint #9347check-success=local-testnet-successcheck-success=test-suite-successRequired conditions to stay in the queue:
#approved-reviews-by >= 1POST beacon/bidendpoint #9347#approved-reviews-by >= 1[🛡 GitHub branch protection]POST beacon/bidendpoint #9347check-success=license/claPOST beacon/bidendpoint #9347check-success=target-branch-checkPOST beacon/bidendpoint #9347label!=do-not-mergePOST beacon/bidendpoint #9347