Remove blob signing #369
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,37 +1,36 @@ | ||
| Deneb: | ||
| KZGProofs: | ||
| type: array | ||
| items: | ||
| $ref: '../primitive.yaml#/KZGProof' | ||
| minItems: 0 | ||
| maxItems: 4096 | ||
|
|
||
| Blobs: | ||
| type: array | ||
| items: | ||
| $ref: "../primitive.yaml#/Blob" | ||
| minItems: 0 | ||
| maxItems: 4096 | ||
|
|
||
| BlockContents: | ||
| type: object | ||
| description: "The required object for block production according to the Deneb CL spec." | ||
| properties: | ||
| block: | ||
| $ref: "./block.yaml#/Deneb/BeaconBlock" | ||
| kzg_proofs: | ||
|
There was a problem hiding this comment. if we are assuming statelessness, are we requiring here for the beacon to build inclusion proofs for the blobs before transmitting them (since this is what validator is fetching) There was a problem hiding this comment. The validator can compute them on its own, the inclusion proof can be computed solely from There was a problem hiding this comment. correct however what i was clarifying that since validator publishes signed block contents, the intercepting beacon is would be building the proofs and publishing blocks (which is fine or may be good as well that while validator is signing the beacon can build the proofs and patch them in as validator starts publish flow although just a matter of 20-30ms as such) (this comment is about SignedBlockContents) There was a problem hiding this comment. I was thinking in implementation, a beacon node could start building the inclusion proofs and cache them when it builds a block. But should also have the ability to compute them on the fly (on a cache miss). So in the case where you publish through the BN building the block it'd be faster. There was a problem hiding this comment. It takes milliseconds to compute those Merkle proofs, as they are solely rooted inside There was a problem hiding this comment. right, lodestar will soon be transition to SSZ now lol |
||
| $ref: "#/Deneb/KZGProofs" | ||
| blobs: | ||
| $ref: "#/Deneb/Blobs" | ||
|
|
||
| SignedBlockContents: | ||
| type: object | ||
| description: "The required signed components of block production according to the Deneb CL spec." | ||
| properties: | ||
| signed_block: | ||
| $ref: "./block.yaml#/Deneb/SignedBeaconBlock" | ||
| kzg_proofs: | ||
| $ref: "#/Deneb/KZGProofs" | ||
| blobs: | ||
| $ref: "#/Deneb/Blobs" | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
remove this blockContents too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is where it's a little confusing and asymmetric.
BlockContentsis still used in the unblinded flow, because in order to keep it stateless we need to pass blobs along with the block back and forth. So this endpoint can returnDeneb.BlockContentsorDeneb.BlindedBeaconBlockThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i would prefer a separate call by validator to pull blobs if it plans to reroute the publish since the data transfer is non trivial and will also resolve code spaghetti in the api, to address latency, validator call concurrently pull blobs while its signing the block
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would not meet the requirement for statelessness, as it would be possible for the beacon node to exit between returning the data in this call and a separate request being made for the blobs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure this can be done without reintroducing the state requirement. Potentially we could set up an avenue for BNs to query ELs to check their local mempool for blobs matching a commitment, but I don't think this is really a great solution either. It might be better to mitigate the expense of transferring blob data by preferring SSZ transfer or preferring the blinded flow even when not using an external builder (this does put you at risk of missing a block proposal if you are using fallback between BNs however).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
theoretically, the VC doesn't even need access to the blobs. it can just sign the block and let the blob be handled by the BN, as in, creating the
BlobSidecarfromSignedBeaconBlock+KzgProofs / BlobsThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, it needs access, because the BN that they are sent to may not have the blobs anymore, if they were originally fetched from a different one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
right, thats the idea of statelessness
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
right I think I missed your point. Agree we should deprecate V2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just wanted to mention that keeping the blobs in the unblinded flow response makes it really easy to update our testing tools for the blob p2p scenarios in testnets.