-
Notifications
You must be signed in to change notification settings - Fork 112
Feat: generate parameters for checkSignatures by referencing OperatorStateRetriever on-chain #461
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
Conversation
Co-authored-by: Tomás Grüner <[email protected]>
refactor: import path refactor: rename format: forge fmt
**Motivation:** Computation of the parameters needed for signature verification is typically done through the Eigen go or rust services. However, the rust services are not reliable at the current moment and some projects might want to have signature verifications without having to rely on these services. This PR aims to make the computation of the `NonSignerStakesAndSignature` parameter easier and accessible through implementing it in `OperatorStateRetriever` contract **Modifications:** - added `getNonSignerStakesAndSignature` to `OperatorStateRetriever` - added BN256G2 solidity library dependency **Result:** Computing the data necessary for performing signature verification is more accessible
lgtm! |
1 similar comment
lgtm! |
* @param p The point to check, in G1 | ||
* @return true if the point lies on the curve, false otherwise | ||
*/ | ||
function _isOnCurve( |
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 be a library 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.
ISlashingRegistryCoordinator registryCoordinator, | ||
bytes calldata quorumNumbers, | ||
BN254.G1Point calldata sigma, | ||
address[] calldata operators, |
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 people want to call this with operatorIds, not addresses?
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 highly doubt that they will... we can duplicate this method to add another entrypoint with operator ids though
|
||
// Trim the nonSignerOperatorIds array to the actual count | ||
bytes32[] memory trimmedNonSignerOperatorIds = new bytes32[](nonSignerOperatorsCount); | ||
for (uint256 i = 0; i < nonSignerOperatorsCount; i++) { |
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.
combine this loop and the next
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.
.getQuorumBitmapAtBlockNumberByIndex( | ||
m.signingOperatorIds[i], blockNumber, signingOperatorQuorumBitmapIndices[i] | ||
); | ||
require(signingOperatorQuorumBitmap != 0, OperatorNotRegistered()); |
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 should make sure they intersect with quorumNumbers
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.
address operator = registryCoordinator.getOperatorFromId(operatorIds[i]); | ||
BN254.G1Point memory operatorPk; | ||
(operatorPk.X, operatorPk.Y) = blsApkRegistry.operatorToPubkey(operator); | ||
apk = BN254.plus(apk, operatorPk); |
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.
apk.plus(operatorPk)
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.
fix: make quorumNotCreated tests have valid quorumNumber lists
chore: `BN254.plus` -> `apk.plus`
I opened #469 because I don't have write access to this branch |
About the CI errors: Run if diff --unified pr target; then
Only in pr: BLSSigCheckOperatorStateRetriever.md
Only in pr: BN256G2.md
Error: Differences found between PR and target branch storage layouts
Error: Process completed with exit code 1. |
Also, only now I noticed the commitlint CI check fails. |
Don't worry about the storage issues or CI errors on this one. @rubydusa |
Fixes for BLSSigCheckOperatorStateRetriever
cc @gpsanant for re-review |
* @param p The point to check, in G1 | ||
* @return true if the point lies on the curve, false otherwise | ||
*/ | ||
function isOnCurve( |
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 be part of the BN254.sol library? or was this done due to lack of audit?
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.
Lack of audit, didn't want to change BN254
Motivation:
Computation of the parameters needed for signature verification is typically done through the Eigen go or rust services. However, the rust services are not reliable at the current moment and some projects might want to have signature verifications without having to rely on these services.
This PR aims to make the computation of the NonSignerStakesAndSignature parameter easier and accessible through implementing it in OperatorStateRetriever contract
Modifications:
added getNonSignerStakesAndSignature to OperatorStateRetriever
added BN256G2 solidity library dependency
Result:
Computing the data necessary for performing signature verification is more accessible