Blob Signing APIs

[realbigsean]

I started working on making a spec for this and had some general thoughts and questions:

Blinded blobs by default

I would propose we only support blinded blob communication in block production because blobs aren't interpret-able by the VC and because they are large. It would also save us work with the blinded block flow for the builder API. Full blobs are still accessible here for purposes outside block production.

How should validators get blobs from the BN for signing?

Separate requests

• GET /eth/v1/validator/blobs_sidecar/{slot} with no query params
  • We could maybe still include necessary information to trigger block production (randao, graffiti) in case these requests come out of order but this seems ugly
• Having separate requests leaves open the possibility of inconsistency between block and blobs, so I think we'd have to do some sort of consistency check
• Would maybe need to allow optionally requesting blobs by block root in the event of a consistency issue
• For maximal simplicity we could request the block as normal and follow up with a blobs request by root, but this would be slower

Combined request

• Have a single endpoint for block+blob production that returns something like this:

BlockContents {
    block: BeaconBlock,
    blobs: BlindedBlobsSidecar,
}

• Can we use the existing block endpoint or would this require a new endpoint?
• If it requires a new endpoint we may have to worry about switching to it at the fork, or making it backwards compatible

How should signed blobs be returned to the BN?

Separate requests

• A new endpoint that accepts a single signed blob, a blinded version of the singular blob gossip struct - this lets the BN start publishing to gossip most quickly
  • POST /eth/v1/validator/blinded_blob

Combined request

• have a single block + blobs endpoint accepting some sort of a SignedBlockContents struct
• I think the main benefit here is it would mirror the combined GET endpoint if we go that route, but I don't see the benefit this adds otherwise.

[mcdee]

From my current (vague) understanding of the blobs system there is some blob metadata embedded in the blocks, so the block and associated blobs are tightly coupled. If that's the case then having the combined endpoint for both obtaining data to sign seems reasonable. The GET endpoint could be backwards-compatible by making the blobs optional in the return data structure.

As the items are decoupled, or going to be decoupled, on the p2p layer it makes sense to keep the endpoints for them separate unless the beacon node is going to carry out its own verification of both items in tandem before broadcasting (i.e. if pre-gossip verification of the blob requires information in the block), in which case there wouldn't be any benefit to having them as separate endpoints.

[realbigsean]

there is some blob metadata embedded in the blocks

Yes this is the case, transactions in the block contain references to the blobs so they're tightly linked

unless the beacon node is going to carry out its own verification of both items in tandem before broadcasting

I don't think we'll validate any more than the required gossip conditions before broadcast, and the gossip conditions are being designed so block and blob can each be independently verified (this is the major reason decoupling them generally is advantageous)

[dapplion]

+1 on exposing blinded flow only. Publishing separately nakes sense too

[arnetheduck]

GET /eth/v1/validator/blobs_sidecar/{slot}

this is open to a race here where the head changes between block and blob request