Skip to content

Conversation

@eserilev
Copy link
Member

@eserilev eserilev commented Jan 20, 2026

data columns: https://github.com/ethereum/consensus-specs/blob/master/specs/gloas/p2p-interface.md#modified-datacolumnsidecar

There are some TODOs related to gloas data column gossip verification that should be handled in a separate PR

@michaelsproul
Copy link
Member

Thanks! 🙌

Looks like this would have been a lot of work 🙏

@eserilev eserilev added the ready-for-review The code is ready for review label Jan 20, 2026
/// Stores all received data indices for a given `(ValidatorIndex, Slot)` tuple.
items: HashMap<ProposalKey, HashSet<u64>>,
/// Stores all received data indices for a given `slot`.
items: HashMap<Slot, HashSet<u64>>,
Copy link
Member Author

Choose a reason for hiding this comment

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

Doesn't seem to be a reason why we use ProposalKey instead of Slot. post-gloas data columns no longer have a signed_beacon_block_header field which means we cant easily access the proposer_index

Copy link
Member

Choose a reason for hiding this comment

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

This is for DOS protection - if we use slot, an attacker could produce a column sidecar that passes gossip and prevent other column sidecars from getting processed.

Checking the spec, it looks like we need to use beacon_block_root and index
https://github.com/ethereum/consensus-specs/blob/master/specs/gloas/p2p-interface.md#data_column_sidecar_subnet_id

Copy link
Member Author

Choose a reason for hiding this comment

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

ah okay they key is now block root and slot
42c71c5

@mergify
Copy link

mergify bot commented Jan 20, 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 20, 2026
@eserilev eserilev changed the base branch from gloas-consensus to unstable January 21, 2026 06:50
@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 21, 2026
})
.collect::<Result<Vec<_>, _>>()?;

reconstruct_blobs(&chain.kzg, data_columns, blob_indices, block, &chain.spec).map_err(
Copy link
Member

Choose a reason for hiding this comment

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

reconstruct_blobs() will return error in gloas, because signed_block_header and kzg_commitments_inclusion_proof no longer exists in the Gloas DataColumnSidecar - may be worth adding a TODO here so we don't miss this?

https://github.com/eserilev/lighthouse/blob/f25308822943798a42fff3af8c9a38d04375db3c/beacon_node/beacon_chain/src/kzg_utils.rs#L460-L470

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 d7b692a

@mergify
Copy link

mergify bot commented Jan 21, 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 21, 2026
mergify bot pushed a commit that referenced this pull request Jan 21, 2026
Pulling out consensus type changes from #8677.

This PR covers all type changes for spec 1.7.0-alpha.1 (except for `DataColumnSidecar` changes, which is covered in @eserilev's PR  #8682)


  


Co-Authored-By: Jimmy Chen <jchen.tc@gmail.com>

Co-Authored-By: Michael Sproul <michael@sigmaprime.io>
@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 22, 2026

#[derive(Debug, PartialEq, Clone)]
pub enum Error {
IncorrectStateVariant,
Copy link
Member

Choose a reason for hiding this comment

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

could just add this to DataColumnSidecarError?

bytes: &[u8],
fork_name: ForkName,
) -> Result<Self, ssz::DecodeError> {
if fork_name.gloas_enabled() {
Copy link
Member

Choose a reason for hiding this comment

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

would it be safer to use match here, in the unlikely case if a new variant is added we don't convert into the wrong type here.

SszStaticHandler::<DataColumnSidecarFulu<MinimalEthSpec>, MinimalEthSpec>::fulu_only()
.run();
SszStaticHandler::<DataColumnSidecar<MainnetEthSpec>, MainnetEthSpec>::fulu_and_later()
SszStaticHandler::<DataColumnSidecarFulu<MainnetEthSpec>, MainnetEthSpec>::fulu_only()
Copy link
Member

Choose a reason for hiding this comment

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

should we add Gloas too?

}

pub(crate) fn blobs_known_for_proposal(
pub(crate) fn blobs_known_for_observation_key(
Copy link
Member

Choose a reason for hiding this comment

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

i think we only want to use this new tuple from gloas?

}

pub(crate) fn data_column_known_for_proposal(
pub(crate) fn data_column_known_for_observation_key(
Copy link
Member

Choose a reason for hiding this comment

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

same as above - i think fulu rules remains unchanged

if let Some(observed_columns) = chain_adapter_cloned.data_column_known_for_proposal(
ProposalKey::new(block.message().proposer_index(), block.slot()),
) {
if let Some(observed_columns) = chain_adapter_cloned
Copy link
Member

Choose a reason for hiding this comment

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

we may need separate logic for fulu and gloas here

BlockComponent::DataColumn(column) => match column.value.as_ref() {
DataColumnSidecar::Fulu(column) => column.block_parent_root(),
// TODO(gloas) we don't have a parent root post gloas, not sure what to do here
DataColumnSidecar::Gloas(column) => column.beacon_block_root,
Copy link
Member

Choose a reason for hiding this comment

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

this might actually be correct for lookup but need to confirm - the parent is technically the beacon block root - if we don't know the beacon block root, we'd have to look it up.

Copy link
Member Author

Choose a reason for hiding this comment

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

right, yeah it might be correct. Pawan said he's looking into this as he's working on lookup sync

slasher.accept_block_header(data_colum.signed_block_header());
for data_column in &data_columns {
// TODO(gloas) no block header post-gloas, what should we do here
if let DataColumnSidecar::Fulu(c) = data_column.as_data_column() {
Copy link
Member

Choose a reason for hiding this comment

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

let data_indices = self
.items
.entry(ProposalKey {
.entry(ObservationKey {
Copy link
Member

Choose a reason for hiding this comment

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

ObservationKey may have to be an enum now to support Gloas, and we could pass ObservationKey and leave it to the caller to construct

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.

Nice work!
I haven't finished but I've added comments I have so far - we mainly need to make sure it doesn't impact / change Fulu code path before we merge this, so I think we'll need to retain the ObservedDataSidecars behaviour for Fulu.

@jimmygchen jimmygchen 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 22, 2026
@eserilev
Copy link
Member Author

eserilev commented Jan 22, 2026

I know a new observation key technically affects fulu code paths but it seems like unnecessary overhead to maintain separate code paths for this section of the code. Is there a reason why block root + slot won't work the same as proposer index + slot?

@eserilev
Copy link
Member Author

re: observation key
After talking with jimmy, we're going to keep the fulu code path the same as it currently is

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

Labels

gloas waiting-on-author The reviewer has suggested changes and awaits thier implementation.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants