Add Distributed Blob Publishing to Fulu networking spec

[jimmygchen]

Add Distributed Blob Publishing to the Fulu networking spec, and move the Deneb getBlobs section to the gossip subsection, since it's related to gossip publishing.

Some additional context I posted in the #peerdas-testing Discord channel, along with the rationale behind why full nodes should also publish their custody columns:

While spec'ing out Distributed Blob Publishing with @pawanjay176, we realised that Lighthouse's full node behaviour may impact data column propagation. Currently, Lighthouse full nodes retrieve EL blobs and compute columns, then import them. They also add these columns to the "gossip seen cache", but full nodes don't attempt to publish them at all.

This hurts propagation because if the node later receives the same columns via gossip, it will IGNORE them as they're already in the seen cache. That means the node doesn’t forward them, effectively halting propagation of those data columns to the rest of the network.

We'll need to change this behaviour so that nodes always attempt to publish columns they haven't seen on their subscribed gossip data column topics - in line with the requirements in this PR: #3864

[dapplion]

Usage of engine_getBlobsV1 directly affects the health of the network as:

• It relaxes bandwidth requirements for proposers: aligns the goal to support solo stakers
• Improves the over network's time to head, resulting in higher head vote accuracy

That's why I suggest we change MAY to SHOULD regarding the usage of this feature

[0x00101010]

Do we still need to publish blob_sidecar after Fulu? My understanding is that after it'll only be data column sidecars?

[jimmygchen]

No we don't need to publsih blob_sidecars after Fulu. This is the deneb specification - I've only moved this section (from RPC to gossip) without modification.

[zilm13]

I've concerns on requiring it from all. If your custody requirement is just 4, it sounds like too much to follow all these rules and spend computation power. I'd bound it to supernodes only.

[zilm13]

Also home staker on ADSL wouldn't be happy to try to publish all DataColumns with 48, 64 etc blobs

[jimmygchen]

Full nodes won't actually send all data columns - they only send data columns on topics they're subscribed to. This is the same behaviour as if you receive a data column via gossip - you'd spend the bandwidth to propagate it to mesh peers.

If the node ever add the columns to the "gossip seen cache" without publishing / forwarding the column, it would stop propagation of the columns to the rest of the network.

re 1st point about computing columns - proofs will no longer be computed in the CL, so this would be a cheap operation, and potentially makes the block available sooner than waiting for columns to arrive from gossip.

[jtraglia]

LGTM, thanks all!

[hangleang]

@jimmygchen i would like clarify on this statement. when full node participate in distributed blob publishing, does the node publish only its custody columns, or plus some extra sampling columns? since full node also subscribe those extra sampling columns subnets, not only custody subnets

[jtraglia]

Hey @hangleang, I can try to help with this. The full node would only publish the data column sidecars to the subnets for which it is custodying, which is determined by get_custody_groups .

[jimmygchen]

Thanks @jtraglia - I realise what I wrote there isn't right for full nodes without validators, the following sentence should be removed / replaced:

specifically, the node’s assigned custody columns.

Because under subnet sampling, a full node without validators would subscribe to 8 column topics but only custody 4 columns - and distributed publishing should apply to all subscribed column topics to make sure columns are propagated accordingly.

[jtraglia]

Oh I see. Then I misunderstood it too 😅 good question @hangleang!

[jimmygchen]

Updated in 43892f0, hope this makes sense:

consensus-specs/specs/fulu/p2p-interface.md

Lines 214 to 217 in 43892f0

	When clients use the local execution layer to retrieve blob and compute data columns, they MUST behave as if the imported `data_column_sidecar` had been received via gossip. In particular, clients MUST:
	* Publish the corresponding `data_column_sidecar` on the `data_column_sidecar_{subnet_id}` topic **if and only if** they are **subscribed** to it, either due to custody requirement or additional sampling.
	* Update gossip rule related data structures (i.e. update the anti-equivocation cache).

[jtraglia]

@fradamt I think would be a good time to add the updated get_data_column_sidecars and get_data_column_sidecars_from_block functions we chatted about on discord.

Reference: https://discord.com/channels/595666850260713488/1252403418941624532/1352668148175737015

[fradamt]

@fradamt I think would be a good time to add the updated get_data_column_sidecars and get_data_column_sidecars_from_block functions we chatted about on discord.

Reference: https://discord.com/channels/595666850260713488/1252403418941624532/1352668148175737015

I decided to add get_data_column_sidecars_from_column_sidecar as well, but feel free to remove it and just leave the other two, I don't have a strong opinion.

[jimmygchen]

The new changes look good! Thanks @jtraglia and @fradamt 🙏

[ralexstokes]

left a comment to consider clarifying some text, but otherwise lgtm