Update getHeader and submitBlindedBlock to support blobs (EIP-4844)

jimmygchen commented 1 year ago

Builder spec changes for EIP-4844, separated from PR #58.

Description

`getHeader` changes

Updated ExecutionPayload & BeaconBlockBody types to align with EIP-4844 specs. (Depends on types from this Beacon API PR: https://github.com/ethereum/beacon-APIs/pull/271)
Add blinded_blobs to getHeader response (SignedBuilderBid), so that validators can create signatures over the blinded block and blinded blobs.

`submitBlindedBlock` changes

Endpoint updated to accept SignedBlindedBlockContents after Deneb.
Additionally returns unblinded blobs after Deneb; new type: ExecutionPayloadAndBlobsBundle.
I've modified the response to return blobs_bundle instead of blob_sidecars, as I think it's more consistent with what we get from the EL, and BN should have enough to build the blob sidecars.

I'm currently pointing the beacon-APIs submodule to this PR, as it contains the new SignedBlindedBlockContents type: https://github.com/ethereum/beacon-APIs/pull/302

Moved design diagrams to this HackMD page as it was getting outdated here.

jimmygchen commented 1 year ago

@ralexstokes @0xGabi would you mind reviewing this please? I've addressed all comments from the previous PR. This PR includes changes for EIP-4844 only.

jimmygchen commented 1 year ago

I've replaced all EIP-4844 references with Deneb. The PR for the rename in Beacon API is here: https://github.com/ethereum/beacon-APIs/pull/289

jimmygchen commented 1 year ago

Waiting for the https://github.com/ethereum/beacon-APIs/pull/289 to be merged to pass the build

jimmygchen commented 1 year ago

There is currently a discussion in the below PR regarding blob signing and publishing, and could have an impact on the builder API, I'll come back to this PR once we get more input on the decisison:

https://github.com/ethereum/beacon-APIs/pull/302#issuecomment-1454149870

jimmygchen commented 1 year ago

@metachris @terencechain @g11tech @ralexstokes I've updated this PR to reflect some recent changes - there are quite a few changes to the types, so I've re-written the PR description. Please see above.

Thanks!

metachris commented 1 year ago

Thanks for your efforts @jimmygchen, much appreciated 🙏

We've discussed this PR with the mev-boost maintainers group, and believe a single submitBlindedBlock request would be preferable to requiring multiple API calls.

Since all requests would be required to succeed anyway, it adds several downsides to split up the functionality over multiple API requests.
Not least that the relay is responsible for broadcasting the block before it is allowed to send the payload back to the user. Having multiple API calls will require the relay to accumulate state internally, but at the same time block the response of other API calls until all are received, and the final block is validated, equivocation-checked and broadcast, and then there's still the remaining 1s delay before responding.

Also it may be a preferable approach to not return the payload to the proposer, but have it be the relay responsibility to broadcast the block. Returning the payload is currently delayed by relays, and is problematic due to equivocation attacks, and there has been some discussion recently by core devs about it perhaps being safer to not return the payload on this API.

cc/ @jtraglia @terencechain @ralexstokes @michaelneuder

jimmygchen commented 1 year ago

@metachris the PR is updated to send a single submitBlindedBlock, but diagram was outdated. It's now updated, thanks for pointing this out!

Also it may be a preferable approach to not return the payload to the proposer, but have it be the relay responsibility to broadcast the block. Returning the payload is currently delayed by relays, and is problematic due to equivocation attacks, and there has been some discussion recently by core devs about it perhaps being safer to not return the payload on this API.

Thanks for sharing this - I'll keep an eye on the development!

jimmygchen commented 1 year ago

excellent work and I think this reflects the latest direction around 4844 well

I'd say we move ahead with merging this so we can start prototyping at various places in the mev-boost ecosystem/stack

Thanks @ralexstokes ! I've updated the beacon-API submodule to latest (which contains the deneb types we need in this PR), so I think this should be ready to go from my POV.

There's a pending CL spec PR to update MAX_BLOBS_PER_BLOCK to MAX_BLOB_COMMITMENTS_PER_BLOCK in deneb BeaconBlockBody - I'm happy to update this when the other PR is finalised.

ethereum / builder-specs