-
Notifications
You must be signed in to change notification settings - Fork 438
feat: bn254 operator table contracts #1429
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
feat: bn254 operator table contracts #1429
Conversation
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.
First pass
totalWeights[j] += weights[i][j]; | ||
} | ||
(BN254.G1Point memory g1Point,) = keyRegistrar.getBN254Key(operatorSet, operators[i]); | ||
operatorInfoLeaves[i] = keccak256(abi.encode(BN254OperatorInfo({pubkey: g1Point, weights: weights[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.
Do we want to encode the leaves with a salt? We do this for rewards. Can be done in a separate PR
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 it for leaf uniqueness? is it necessary when we already enforce global key uniqueness in the keyRegistrar
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.
Let's punt this for now
using BN254 for BN254.G1Point; | ||
|
||
constructor( | ||
IOperatorWeightCalculator _operatorWeightCalculator, |
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.
Thoughts on enabling this to have multiple operator weight calculators? The AVS can then add multiple to this "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.
I think we should try to avoid too many places for configuration as it adds overall complexity for an AVS.
From an AVS perspective.
CrossChainRegistry
- Where OperatorSetConfig is set
- Where OperatorTableCalculator is set. If they want a different kind of scheme then they can just deploy a new OperatorTableCalculator, OperatorWeightCalculator, and then call
OperatorTableCalculator
- Does exactly as specified, calculates the OperatorTable
- Works for ECDSA, BN254 keys
- Utilizes a specific weighting scheme for the operator weights/stake
OperatorWeightCalculator
- Calculates operator weights
- Can be linear, non-linear, ceiling limited, etc
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.
Agreed offline -> we'll have a single OperatorTableCalculator
per operatorSet
* @param strategies The strategies to set the multipliers for | ||
* @param multipliers The multipliers to set for the strategies | ||
*/ | ||
function setStrategyMultipliers( |
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 will end up being the "default" operator weight calculator. In such case, I'm wondering if the protocol should even be setting these multiples for others... my take is NO given the operational load. As such, would we want one that doesn't have multipliers and assumes like-assets (stablecoins, some LSTs).
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 assume that this would be a "default" that AVSs would redeploy and setup themselves for their multipliers. Definitely don't want to be responsible for setting multipliers on behalf of everyone but if you are weighing LSTs for example it has to be updated occasionally. I think this is just part of the set of contracts that AVSs should configure and maintain. wdyt
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.
Issue is Hourglass wants a default implementation, will chat with them tomorrow
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.
Can we add a base IOperatorTableCalculator
that the ECDSA & BN254 table calcs implement?
function calculateOperatorTableBytes( | ||
OperatorSet calldata operatorSet | ||
) external view virtual returns (bytes memory operatorTableBytes) { | ||
return abi.encode(_calculateOperatorTable(operatorSet)); |
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 also encode the OperatorSet.key()
and OpsetConfig
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 assumed the OpsetConfig
would be OperatorSet.key()
would be included in the table generation separately.
So does this mean AVSs can put arbitrary bytes data into their table depending on how they implement this function
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.
Decided offline: the CrossChainRegistry
will handle
Only interface shared is |
} | ||
|
||
/// @inheritdoc IBN254TableCalculator | ||
function setLookaheadBlocks( |
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.
Let's use this as the default implementation, let's just cut this and then use the maximum? We can get rid of the Ownable inheritance as well
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.
sounds clean d7ee1d5
d7ee1d5
to
b7b3d29
Compare
e39adbc
to
d32a49a
Compare
moved ECDSA: #1443 |
<!-- 🚨 ATTENTION! 🚨 This PR template is REQUIRED. PRs not following this format will be closed without review. Requirements: - PR title must follow commit conventions: https://www.conventionalcommits.org/en/v1.0.0/ - Label your PR with the correct type (e.g., 🐛 Bug, ✨ Enhancement, 🧪 Test, etc.) - Provide clear and specific details in each section --> **Motivation:** Testing for #1429 Updates Integration test framework for testing the BN254OperatorTableCalculator **Modifications:** Contracts - Updated `BN254TableCalculator` to have LOOKAHEAD_BLOCKS be immutable Tests - Updated Users (AVS.t.sol, User.t.sol) - IntegrationBase - `_newRandomAVS_WithBN254` - `_newRandomAVS_WithECDSA` - IntegrationDeployer, added multichain contracts although some are missing pending feat PRs to be merged. - ExistingDeploymentParser, added contract addresses **Result:** - Updated Integration test framework for testing the BN254OperatorTableCalculator and other multichain flows - fuzz tests for BN254OperatorTableCalculator in `BN254OperatorSet_CalculateWeights.t.sol`
- removed weight multipliers for now - Removed WeightCalculator and have bit of code dup in both ECDSA and BN254 calculator contracts but does make it simpler with 1 configured contract
**Motivation:** We need tests for the operator table calculator **Modifications:** - Add test scaffold for `operatorTableCalculator` - Update formatting to not have a `src/interfaces/multichain` folder **Result:** Tests for OTC
<!-- 🚨 ATTENTION! 🚨 This PR template is REQUIRED. PRs not following this format will be closed without review. Requirements: - PR title must follow commit conventions: https://www.conventionalcommits.org/en/v1.0.0/ - Label your PR with the correct type (e.g., 🐛 Bug, ✨ Enhancement, 🧪 Test, etc.) - Provide clear and specific details in each section --> **Motivation:** Testing for #1429 Updates Integration test framework for testing the BN254OperatorTableCalculator **Modifications:** Contracts - Updated `BN254TableCalculator` to have LOOKAHEAD_BLOCKS be immutable Tests - Updated Users (AVS.t.sol, User.t.sol) - IntegrationBase - `_newRandomAVS_WithBN254` - `_newRandomAVS_WithECDSA` - IntegrationDeployer, added multichain contracts although some are missing pending feat PRs to be merged. - ExistingDeploymentParser, added contract addresses **Result:** - Updated Integration test framework for testing the BN254OperatorTableCalculator and other multichain flows - fuzz tests for BN254OperatorTableCalculator in `BN254OperatorSet_CalculateWeights.t.sol`
c757a4f
to
b64f429
Compare
LGTM. Will fix the coverage separately |
**Motivation:** Implementing the `BN254TableCalculator contracts`. Currently the calculator weights slashable stake in an operator set by simply adding all the slashable stake together with no multipliers/linear combination calculation involved **Modifications:** Updates and added to interfaces **Result:** Bn254 Table Calc --------- Co-authored-by: Yash Patil <[email protected]>
**Motivation:** Implementing the `BN254TableCalculator contracts`. Currently the calculator weights slashable stake in an operator set by simply adding all the slashable stake together with no multipliers/linear combination calculation involved **Modifications:** Updates and added to interfaces **Result:** Bn254 Table Calc --------- Co-authored-by: Yash Patil <[email protected]>
**Motivation:** Implementing the `BN254TableCalculator contracts`. Currently the calculator weights slashable stake in an operator set by simply adding all the slashable stake together with no multipliers/linear combination calculation involved **Modifications:** Updates and added to interfaces **Result:** Bn254 Table Calc --------- Co-authored-by: Yash Patil <[email protected]>
# v1.7.0 Multi Chain The multichain release enables AVSs to launch their services and make verified Operator outputs available on any EVM chain, meeting their customers where they are. AVSs can specify custom operator weights to be transported to any destination chain. The release has 3 components: 1. Core Contracts 2. AVS Contracts 3. Offchain Infrastructure The below release notes cover Core Contracts. For more information on the end to end protocol, see our [docs](../docs/multichain/README.md) and [ELIP-008](https://github.com/eigenfoundation/ELIPs/blob/main/ELIPs/ELIP-008.md). ## Release Manager @ypatil12 @eigenmikem ## Highlights This multichain release only introduces new standards and contracts. As a result, there are no breaking changes or deprecations. 🚀 New Features Source Chain Contracts - `KeyRegistrar`: Manages cryptographic keys for operators across different operator sets. It supports both ECDSA and BN254 key types and ensures global uniqueness of keys across all operator sets - `CrossChainRegistry`: Enables AVSs to register to have their operator stakes transported to supported destination chains - `ReleaseManager`: Provides a standardized way for AVSs to publish software artifacts (binaries, docker images, etc.) that operators in their operator sets should upgrade to by specified deadlines Destination Chain Contracts - `CertificateVerifier`: Proves the offchain execution of a task, via a Certificate, by the operators of an operatorSet. Two types of key material are supported: ECDSA and BN254 - `OperatorTableUpdater`: Updates operator tables in the `CertificateVerifier` to have tasks validated against up-to-date operator stake weights 🔧 Improvements – Enhancements to existing features. - The multichain protocol has protocol-ized several AVS-deployed contracts, enabling an simpler AVS developer experience. These include: - `KeyRegistrar`: Manages BLS and ECDSA signing keys. AVSs no longer have to deploy a `BLSAPKRegistry` - `CertificateVerifier`: Handles signature verification for BLS and ECDSA keys. AVSs no longer have to deploy a `BLSSignatureChecker` - Offchain Multichain Transport: AVSs no longer have to maintain [avs-sync](https://github.com/Layr-Labs/avs-sync) to keep operator stakes fresh ## Changelog - feat: multichain deploy scripts [PR #1487](#1487) - feat: operator table updater pauser [PR #1501](#1501) - feat: add `publishMetadataURI` [PR #1492](#1492) - refactor: `globalRootConfirmerSet` -> `generator` [PR #1500](#1500) - fix: circular dependency for initial global root update [PR #1499](#1499) - chore: remove stale bindings [PR #1498](#1498) - fix: zero length [PR #1490](#1490) - docs: multichain docs [PR #1488](#1488) - refactor: remove table calculators [PR #1493](#1493) - refactor: `KeyRegistry` unit testing [PR #1482](#1482) - feat: disable root [PR #1481](#1481) - refactor: `ECDSATableCalculator` testing [PR #1479](#1479) - refactor: operators can deregister keys if not slashable [PR #1480](#1480) - refactor: `ECDSACertificateVerifier` testing [PR #1478](#1478) - refactor: `Bn254CertificateVerifierUnitTests` [PR #1476](#1476) - feat: ecdsa table calculator [PR #1473](#1473) - feat: ecdsacv views [PR #1475](#1475) - refactor: `BN254OperatorTableCalculator` [PR #1463](#1463) - feat: add `referenceBlockNumber` [PR #1472](#1472) - feat: release manager [PR #1469](#1469) - feat: ecdsa cert verifier [PR #1470](#1470) - feat: add view function for `getGlobalConfirmerSetReferenceTimestamp` [PR #1471](#1471) - chore: add helper view function [PR #1465](#1465) - chore: add sig digest functions to interface [PR #1464](#1464) - refactor: `CrossChainRegistry` [PR #1457](#1457) - fix: global table update message hash [PR #1460](#1460) - refactor: sig verification into library [PR #1455](#1455) - fix: `OperatorTableUpdater` encoding [PR #1456](#1456) - chore: add latest `referenceTimestamp` to OTC interface [PR #1454](#1454) - chore: bindings [PR #1452](#1452) - feat: add operator table updater to CCR [PR #1451](#1451) - chore: multichain deploy scripts [PR #1449](#1449) - feat: cross chain registry [PR #1439](#1439) - chore: update BN254CertificateVerifier [PR #1447](#1447) - feat: bn254 operator table contracts [PR #1429](#1429) - feat: KeyRegistrar [PR #1421](#1421) - feat: operator table updater [PR #1436](#1436) - feat: bn254 certificate verifier [PR #1431](#1431) - chore: bindings + interface update [PR #1438](#1438) - chore: update multichain interfaces [PR #1433](#1433) - feat: multi chain interfaces [PR #1423](#1423) - docs: update version matrix [PR #1491](#1491) - chore: add multisend parser to scripts directory [PR #1486](#1486) - chore: update eigenpod and eigen impls addresses in holesky and hoodi [PR #1448](#1448)
**Motivation:** Implementing the `BN254TableCalculator contracts`. Currently the calculator weights slashable stake in an operator set by simply adding all the slashable stake together with no multipliers/linear combination calculation involved **Modifications:** Updates and added to interfaces **Result:** Bn254 Table Calc --------- Co-authored-by: Yash Patil <[email protected]>
Motivation:
Implementing the
BN254TableCalculator contracts
. Currently the calculator weights slashable stake in an operator set by simply adding all the slashable stake together with no multipliers/linear combination calculation involvedModifications:
Updates and added to interfaces
Result:
After your change, what will change.