-
Notifications
You must be signed in to change notification settings - Fork 198
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
V2 Blob Verification #781
V2 Blob Verification #781
Conversation
0x0aa0
commented
Oct 2, 2024
•
edited
Loading
edited
- V2
- consolidates structs into common interface
- moves V1 thresholds to ThresholdRegistry while maintaining DASM interface
- renames RollupUtils to BlobVerificationUtils which implements V2 and batched util for V1
- introduces chain abstract immutable BlobVerifier contract to interact with BlobVerificationUtils
- adds relay registry
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.
few questions
|
||
bytes public quorumConfirmationThresholdPercentages; | ||
|
||
bytes public quorumNumbersRequired; |
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.
is this still necessary? I thought we were going to give flexibility to disperse to any quorums except charging the same amount for dispersing to 1 quorum vs. all required quorums
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.
ya this is still needed for V1 verification
|
||
mapping(uint16 => VersionedBlobParams) public versionedBlobParams; | ||
|
||
SecurityThresholds public defaultSecurityThresholdsV2; |
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.
are we allowing the ability to provide custom security thresholds?
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.
yes you can supply custom security thresholds in V2 verification
* @param blobHeader The blob header to verify | ||
* @param blobVerificationProof The blob verification proof to verify the blob against | ||
*/ | ||
function verifyBlobV1( |
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.
do existing v1 integrations need to update and call this new method or can they continue using the old verify method?
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.
old library will continue to work
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.
curious why we need V1 verifications - anyone calling these functions will do so directly through the Service Manager wrapper (i.e, Verifier contracts in Nitro). Don't see how this enables or helps cross compatibility between V1 <--> V2.
contract EigenDARelayRegistry is IEigenDARelayRegistry, OwnableUpgradeable { | ||
|
||
mapping(uint32 => string) public relayIdToURL; | ||
mapping(address => uint32) public relayAddressToId; |
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.
Curious what's a relay address?
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.
onchain address of a relay, the thinking here is that in the future we may want this mapping to permission updates from relays
return nextRelayKey++; | ||
} | ||
|
||
function getRelayURL(uint32 key) external view returns (string memory) { |
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.
should it check if key < nextRelayKey
?
|
||
/// @notice Returns the blob params for a given blob version | ||
function getBlobParams(uint16 version) external view returns (VersionedBlobParams memory) { | ||
return versionedBlobParams[version]; |
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.
same here, should we check version < nextBlobVersion
?
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.
dont think it is totally necessary to require on the getter
One thing to keep consistent is which uint types represent blob versions/relay keys. Offchain, we use |
@@ -226,6 +242,42 @@ contract EigenDADeployer is DeployOpenEigenLayer { | |||
) | |||
); | |||
|
|||
eigenDAThresholdRegistryImplementation = new EigenDAThresholdRegistry(); | |||
|
|||
VersionedBlobParams[] memory versionedBlobParams = new VersionedBlobParams[](0); |
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.
Does it make sense to hardcode the params for version 0 here if we're going to use the same values across all environments?
_disableInitializers(); | ||
} | ||
|
||
function initialize( |
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.
addd natspec to interfaces and use @inheritdoc
} | ||
|
||
/// @notice Returns the bytes array of quorumAdversaryThresholdPercentages | ||
function quorumConfirmationThresholdPercentages() external view returns (bytes memory) { | ||
return hex"373737"; | ||
return eigenDAThresholdRegistry.quorumConfirmationThresholdPercentages(); | ||
} | ||
|
||
/// @notice Returns the bytes array of quorumsNumbersRequired | ||
function quorumNumbersRequired() external view returns (bytes memory) { |
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.
is this for backwards compatability or?
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.
yes
function getQuorumAdversaryThresholdPercentage( | ||
uint8 quorumNumber | ||
) public view virtual returns (uint8 adversaryThresholdPercentage) { | ||
if(quorumAdversaryThresholdPercentages.length > quorumNumber){ |
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.
we should revert if no?
BatchHeaderV2 calldata batchHeader, | ||
BlobVerificationProofV2 calldata blobVerificationProof, | ||
NonSignerStakesAndSignature calldata nonSignerStakesAndSignature |
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.
on the rollup side we interpret this three element tuple as a certificate type. Is there any benefit to representing the EigenDA certificate type here?
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.
we implicitly use this term across our documentation and integrations - would be nice to have an explicit definition
import {IEigenDARelayRegistry} from "../interfaces/IEigenDARelayRegistry.sol"; | ||
import "../interfaces/IEigenDAStructs.sol"; | ||
|
||
contract EigenDABlobVerifier is IEigenDABlobVerifier { |
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.
In lieu of all the renamings going on - does it make sense to call this contract a BlobVerifier? It's not actually verifying the blob but instead a tuple of different commitments which attest that the blob has been successfully aggregated and dispersed. Verifying the blob makes me think of providing a kzg witness proof generated from the blob and verifying against the data commitment which this contract doesn't do.
* @param blobHeader The blob header to verify | ||
* @param blobVerificationProof The blob verification proof to verify the blob against | ||
*/ | ||
function verifyBlobV1( |
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.
curious why we need V1 verifications - anyone calling these functions will do so directly through the Service Manager wrapper (i.e, Verifier contracts in Nitro). Don't see how this enables or helps cross compatibility between V1 <--> 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.
One comment outside this PR but relevant, shouldn't the reference block number be removed from blob certificate?
@@ -65,7 +70,6 @@ struct BlobVerificationProofV2 { | |||
|
|||
struct BlobCertificate { | |||
BlobHeaderV2 blobHeader; | |||
uint32 referenceBlockNumber; |
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 think it should be removed from Attestation
as well