onchain renaming #1154
onchain renaming #1154
Conversation
0x0aa0
commented
Jan 24, 2025
0x0aa0
commented
- BlobVerificationProofV2 -> BlobInclusionInfo
- EigenDABlobVerifier -> EigenDACertVerifier
- verifyBlob() -> verifyDACert()
| BatchHeaderV2 calldata batchHeader, | ||
| BlobVerificationProofV2 calldata blobVerificationProof, | ||
| BlobInclusionInfo calldata blobInclusionInfo, | ||
| NonSignerStakesAndSignature calldata nonSignerStakesAndSignature |
There was a problem hiding this comment.
Could we take this change as an opportunity to create an explicit DACert struct, both onchain and offchain, that would hold these 3 things together? Would canonicalize the name and remove any ambiguities going forward as to what a DACert is.
There was a problem hiding this comment.
Also overall feel like we should keep the SignedBatch semantics, even when transforming the attestation into a NonSignerStakesAndSignature (because that's just a transformation of the exact same information, meant to be consumed by the contract differently).
Perhaps we could use SignedBatch and SignedBatchWithNonsigners or something? And then a DACert would be either {SignedBatch, BlobInclusionInfo} or {SignedBatchWithNonSigners, BlobInclusionInfo} and it would be more obvious that those two things are just one eth_call away, but have the same semantic. Right now people are always confused as to how the 2 verify functions we have are related, because syntactically they look very different.
| bytes32 paymentHeaderHash; | ||
| uint32 salt; |
There was a problem hiding this comment.
Isn't this struct being called BlobHeaderV2 a bit limitating? What if we ever in the future want to also reveal payments onchain? Then we'll have to create another struct with a weird name for that.
Perhaps we could keep BlobHeaderV2 for the full struct to match offchain code, and use a more specific name here for this struct, like BlobHeaderV2WithPaymentHash (there's prob a better name)
|
@samlaf let me know if there's any more outstanding changes needed in this PR. I'll generate bindings and add offchain changes on top of it when we're happy about the onchain updates |
LGTM in this state. The two outstanding convos are nice-to-have but I'm fine to move on without them. |
ian-shim
force-pushed
the
quaq/v2-renaming-onchain
branch
from
1bdfd67 to
3c1093e
Compare
ian-shim
force-pushed
the
quaq/v2-renaming-onchain
branch
from
3c1093e to
5cb20ca
Compare
