Merge getPayloadV3 and getBlobsBundleV1#402
Conversation
Co-authored-by: g11tech <develop@g11tech.io>
|
Another option is to encode the transactions in network form, which encodes blobs/proofs/commitments, so you do not need to find which transaction a blob belongs to. Looks a bit cleaner, but may be harder to handle by CLs. Wdyt? |
yes right now CLs don't need to ssz decode any txs as of now, although since ssz is already part of CL and won't be hard to do this But from CL side the current solution (getpayloadv3) is simple enough to not think twice. |
|
@g11tech yes, it definitely moves a bit of complexity of handling blobs from EL to CL. On EL side we have an option to optimize blobs handling by having them as just 3 byte arrays which can be passed to a KZG library for batch verification and to the CL then. But we need to split them and separate them from the transactions when we form blobsbundlev1. |
|
Can |
Good point. There is a pushback from at least Geth team on making Engine API methods accept and return multiple datatypes and be used across multiple forks. I think this worth debating but until that time i would leave this method definition as is and follow the decision when we move this method from experimental to cancun spec. |
As per decision made on EIP-4844 Implementers' Call #20 adds
blobsBundlefield to thegetPayloadV3response getting rid ofblockHashfield inBlobsBundleV1data type and statements enforcing consistency betweengetPayloadV3and correspondinggetBlobsBundleV1calls.