Skip to content

Conversation

8sunyuan
Copy link
Contributor

@8sunyuan 8sunyuan commented Jun 2, 2025

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:

After your change, what will change.

Copy link
Collaborator

@ypatil12 ypatil12 left a 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]})));
Copy link
Collaborator

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

Copy link
Contributor Author

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

Copy link
Collaborator

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,
Copy link
Collaborator

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".

Copy link
Contributor Author

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

Copy link
Collaborator

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(
Copy link
Collaborator

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).

Copy link
Contributor Author

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

Copy link
Collaborator

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

Copy link
Collaborator

@ypatil12 ypatil12 left a 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));
Copy link
Collaborator

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

Copy link
Contributor Author

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

Copy link
Collaborator

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

@8sunyuan
Copy link
Contributor Author

8sunyuan commented Jun 4, 2025

Can we add a base IOperatorTableCalculator that the ECDSA & BN254 table calcs implement?

Only interface shared is function calculateOperatorTableBytes, maybe overkill?

}

/// @inheritdoc IBN254TableCalculator
function setLookaheadBlocks(
Copy link
Collaborator

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sounds clean d7ee1d5

@8sunyuan 8sunyuan force-pushed the feat/operator-table-calculator branch from d7ee1d5 to b7b3d29 Compare June 4, 2025 20:20
@ypatil12 ypatil12 force-pushed the feat/operator-table-calculator branch from e39adbc to d32a49a Compare June 4, 2025 23:34
@ypatil12 ypatil12 changed the title feat: operator table contracts feat: bn254 operator table contracts Jun 5, 2025
@ypatil12
Copy link
Collaborator

ypatil12 commented Jun 5, 2025

moved ECDSA: #1443

8sunyuan added a commit that referenced this pull request Jun 5, 2025
<!-- 
    🚨 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`
8sunyuan and others added 10 commits June 5, 2025 19:23
- 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`
@8sunyuan 8sunyuan force-pushed the feat/operator-table-calculator branch from c757a4f to b64f429 Compare June 5, 2025 23:25
@ypatil12
Copy link
Collaborator

ypatil12 commented Jun 6, 2025

LGTM. Will fix the coverage separately

@ypatil12 ypatil12 merged commit 63688df into release-dev/multichain Jun 6, 2025
13 of 14 checks passed
@ypatil12 ypatil12 deleted the feat/operator-table-calculator branch June 6, 2025 01:39
ypatil12 added a commit that referenced this pull request Jun 9, 2025
**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]>
ypatil12 added a commit that referenced this pull request Jun 28, 2025
**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]>
@ypatil12 ypatil12 mentioned this pull request Jul 1, 2025
ypatil12 added a commit that referenced this pull request Jul 1, 2025
**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]>
ypatil12 added a commit that referenced this pull request Jul 1, 2025
# 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)
ypatil12 added a commit that referenced this pull request Jul 7, 2025
**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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants