Problem
broadcastBlock resolves blobs from the node's local cache:
bundle, has := a.blobBundles.Get(common.Bytes48(*commitment))
if !has {
return fmt.Errorf("missing blob bundle for commitment %x", commitment)
}blobBundles is only populated when that node produced the payload, so any beacon node asked to publish a full block it did not build returns 500.
The blobs are already in the request. parseRequestBeaconBlock decodes a DenebSignedBeaconBlock, which carries KZGProofs and Blobs, but postBeaconBlocks passes only block.SignedBlock to broadcastBlock and the rest is dropped.
Impact
Any setup where a validator client publishes to more than one beacon node. The producing node succeeds, the others fail. Only blob-carrying blocks are affected — a block with 0 blobs publishes fine on every node.
Seen on a mainnet validator with two beacon nodes:
Error from beacon node when publishing block: 500 "missing blob bundle for commitment &b80d7d60..."
The block itself was published by the producing node, so this is not currently a missed-block risk. It does mean the second node contributes nothing to blob propagation, and it produces a recurring error in validator client logs.
Expected
Use the blobs and KZG proofs from the request body when present, falling back to the local cache only when they are absent.
Pointers
cl/beacon/handler/block_production.go — broadcastBlock, postBeaconBlocks, parseRequestBeaconBlock- Both the pre-Fulu and Fulu paths do the same cache lookup.
Problem
broadcastBlockresolves blobs from the node's local cache:blobBundlesis only populated when that node produced the payload, so any beacon node asked to publish a full block it did not build returns 500.The blobs are already in the request.
parseRequestBeaconBlockdecodes aDenebSignedBeaconBlock, which carriesKZGProofsandBlobs, butpostBeaconBlockspasses onlyblock.SignedBlocktobroadcastBlockand the rest is dropped.Impact
Any setup where a validator client publishes to more than one beacon node. The producing node succeeds, the others fail. Only blob-carrying blocks are affected — a block with 0 blobs publishes fine on every node.
Seen on a mainnet validator with two beacon nodes:
The block itself was published by the producing node, so this is not currently a missed-block risk. It does mean the second node contributes nothing to blob propagation, and it produces a recurring error in validator client logs.
Expected
Use the blobs and KZG proofs from the request body when present, falling back to the local cache only when they are absent.
Pointers
cl/beacon/handler/block_production.go—broadcastBlock,postBeaconBlocks,parseRequestBeaconBlock