Skip to content

Conversation

@eserilev
Copy link
Member

@eserilev eserilev commented Nov 17, 2025

RpcBlock

Convert RpcBlock into an enum with two variants:

RpcBlock::FullyAvailable

Indicates a fully available RPC block. An RpcBlock of this variant is guaranteed to have all blobs or the columns its required to custody. In the future we could move KZG verification as part of FullyAvailable construction validation logic so that we also have type safety guarntees that KZG verification for the block data is also valid

RpcBlock::BlockOnly

Indicates a maybe available block. No blob/column data has been fetched and we don't check if the block is expected to have any blob data. This variant is mostly used in lookup sync.

When constructing an RpcBlock the arguments provided decide wether its a FullyAvailable or BlocksOnly variant

pub fn new<T>(
        block: Arc<SignedBeaconBlock<E>>,
        block_data: Option<AvailableBlockData<E>>,
        da_checker: Arc<DataAvailabilityChecker<T>>,
        spec: Arc<ChainSpec>,
    ) -> Result<Self, AvailabilityCheckError>

if None is passed in for block_data this indicates a BlocksOnly variant. If a Some value is passed in it will be treated as a FullyAvailable variant. See below for the various block_data variants:

AvailableBlockData

pub enum AvailableBlockData<E: EthSpec> {
    /// Block is pre-Deneb or has zero blobs
    NoData,
    /// Block is post-Deneb, pre-PeerDAS and has more than zero blobs
    Blobs(BlobSidecarList<E>),
    /// Block is post-PeerDAS and has more than zero blobs
    DataColumns(DataColumnSidecarList<E>),
}

When constructing the different variants of AvailableBlockData the following checks are made

  • AvailableBlockData::NoData: no blobs are expected for the associated block
  • AvailableBlockData::Blobs: all expected blobs are present and the block is post-Deneb and pre-PeerDAS
  • AvailableBlockData::DataColumns: all expected data columns for the nodes custody requirements are present

@eserilev eserilev added code-quality ready-for-review The code is ready for review syncing labels Nov 17, 2025
@eserilev eserilev requested a review from ethDreamer November 17, 2025 19:29
@mergify
Copy link

mergify bot commented Nov 17, 2025

Some required checks have failed. Could you please take a look @eserilev? 🙏

@mergify mergify bot added waiting-on-author The reviewer has suggested changes and awaits thier implementation. and removed ready-for-review The code is ready for review labels Nov 17, 2025
@eserilev
Copy link
Member Author

need to fix a few tests but the general idea is here

@eserilev eserilev marked this pull request as ready for review December 1, 2025 15:21
@eserilev eserilev requested a review from jxs as a code owner December 1, 2025 15:21
@eserilev eserilev added ready-for-review The code is ready for review and removed waiting-on-author The reviewer has suggested changes and awaits thier implementation. labels Dec 1, 2025
@mergify
Copy link

mergify bot commented Dec 1, 2025

Some required checks have failed. Could you please take a look @eserilev? 🙏

@mergify mergify bot added waiting-on-author The reviewer has suggested changes and awaits thier implementation. and removed ready-for-review The code is ready for review labels Dec 1, 2025
@mergify mergify bot added ready-for-review The code is ready for review and removed waiting-on-author The reviewer has suggested changes and awaits thier implementation. labels Dec 17, 2025
@mergify
Copy link

mergify bot commented Dec 18, 2025

Some required checks have failed. Could you please take a look @eserilev? 🙏

@mergify mergify bot added waiting-on-author The reviewer has suggested changes and awaits thier implementation. and removed ready-for-review The code is ready for review labels Dec 18, 2025
@mergify mergify bot added ready-for-review The code is ready for review and removed waiting-on-author The reviewer has suggested changes and awaits thier implementation. labels Jan 6, 2026
/// viewed the same as `None` passed in.
pub fn new(
block_root: Option<Hash256>,
pub fn new<T>(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add a comment above specifying when to use Some(block_data) or None

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added comment

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sorry where was this added? can't find it

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

whoops comments are now added: ab54242


#[derive(Debug)]
#[derive(Debug, Clone)]
pub enum AvailableBlockData<E: EthSpec> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

future refactor - move this to block_verification_types

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added TODO

}
}
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

future refactor - move to block_verification_types

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added TODO

// Test that `signature_verify_chain_segment` correctly handles a mix of `FullyAvailable`
// and `BlockOnly` RpcBlocks. This situation should not happen in production
// but this test may help catch potential future regressions.
#[tokio::test]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

flip this test

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

test is flipped

assert_eq!(verified[i].block_root(), *expected_root);
}
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

test for successfully importing blocks without columns (that need them) when past the data availability boundary

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mergify
Copy link

mergify bot commented Jan 8, 2026

Some required checks have failed. Could you please take a look @eserilev? 🙏

@mergify mergify bot added waiting-on-author The reviewer has suggested changes and awaits thier implementation. and removed ready-for-review The code is ready for review labels Jan 8, 2026
@eserilev eserilev added ready-for-review The code is ready for review and removed waiting-on-author The reviewer has suggested changes and awaits thier implementation. labels Jan 8, 2026
Copy link
Member

@pawanjay176 pawanjay176 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really clean! Thanks for fixing this up.
Just minor nits and a question

/// viewed the same as `None` passed in.
pub fn new(
block_root: Option<Hash256>,
pub fn new<T>(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sorry where was this added? can't find it

blobs_available_timestamp: None,
spec: self.spec.clone(),
})
for available_block in available_blocks {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe we can move this to before the kzg verification to avoid expensive verification if the batch doesn't have required data? not super necessary though

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants