Skip to content

Conversation

@kevaundray
Copy link
Contributor

@kevaundray kevaundray commented Sep 2, 2025

Issue Addressed

Adds doc comment

/// Note: from this, one can immediately see that `verified_blobs` and `verified_data_columns`
/// are mutually exclusive. i.e. If we are verifying columns to determine a block's availability
/// we are ignoring the `verified_blobs` field.
pub struct PendingComponents<E: EthSpec> {
Copy link
Contributor Author

@kevaundray kevaundray Sep 2, 2025

Choose a reason for hiding this comment

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

IIUC This structure will work across fork boundaries because a lot of the logic will explicitly handle the different forks at runtime. So merge_blobs if called during peerDAS epoch, will do nothing for example.

If that's correct then I think something like this:

pub enum PendingComponents<E: EthSpec> {
    PostDeneb {
        block_root: Hash256,
        executed_block: Option<DietAvailabilityPendingExecutedBlock<E>>,
        verified_blobs: RuntimeFixedVector<Option<KzgVerifiedBlob<E>>>,
        span: Span,
    },
    
    PostPeerDAS {
        block_root: Hash256,
        executed_block: Option<DietAvailabilityPendingExecutedBlock<E>>,
        verified_data_columns: Vec<KzgVerifiedCustodyDataColumn<E>>,
        reconstruction_started: bool,
        span: Span,
    },

Might express the intentions clearer and then it would be possible to panic if PendingComponents is PostPeerDAS but merge_blobs has been called for example.

Copy link
Member

Choose a reason for hiding this comment

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

Thanks @kevaundray - Agree the above is cleaner, although we may not refactor this further at this stage as we're in the process of redesigning DA checker but we'll keep this in mind, thanks!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah this is great to know -- is there currently a draft branch or doc for this refactor?

Copy link
Member

@jimmygchen jimmygchen left a comment

Choose a reason for hiding this comment

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

Thanks, the added comments look good.

@jimmygchen jimmygchen marked this pull request as ready for review September 9, 2025 06:52
@jimmygchen jimmygchen added the ready-for-merge This PR is ready to merge. label Sep 9, 2025
@jimmygchen
Copy link
Member

@mergify requeue

@mergify
Copy link

mergify bot commented Sep 10, 2025

requeue

✅ The queue state of this pull request has been cleaned. It can be re-embarked automatically

mergify bot added a commit that referenced this pull request Sep 10, 2025
mergify bot added a commit that referenced this pull request Sep 10, 2025
@mergify mergify bot merged commit f71d697 into sigp:unstable Sep 10, 2025
36 of 37 checks passed
PoulavBhowmick03 pushed a commit to PoulavBhowmick03/lighthouse that referenced this pull request Sep 12, 2025
Adds doc comment


  


Co-Authored-By: Kevaundray Wedderburn <[email protected]>

Co-Authored-By: Jimmy Chen <[email protected]>
kevaundray added a commit to kevaundray/lighthouse that referenced this pull request Sep 13, 2025
Adds doc comment


  


Co-Authored-By: Kevaundray Wedderburn <[email protected]>

Co-Authored-By: Jimmy Chen <[email protected]>
jtraglia pushed a commit to jtraglia/lighthouse that referenced this pull request Sep 16, 2025
Adds doc comment


  


Co-Authored-By: Kevaundray Wedderburn <[email protected]>

Co-Authored-By: Jimmy Chen <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ready-for-merge This PR is ready to merge.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants