Skip to content

Releases: Layr-Labs/eigenlayer-middleware

v1.4.0-rc.3: Multichain/MiddlewareV2

22 Jul 18:54
10867bb
Compare
Choose a tag to compare
Pre-release

This release points to the core contract release, v1.7.0-rc.3.

What's Changed

Full Changelog: v1.4.0-rc.0...v1.4.0-rc.3

v1.4.0-rc.0: Multichain/MiddlewareV2

11 Jul 02:38
b88650c
Compare
Choose a tag to compare
Pre-release

v1.4.0 MultiChain/MiddlewareV2

The multichain/middlewareV2 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 AVS Contracts. For more information on the end to end protocol, see our docs, core contract docs, and ELIP-008.

Release Manager

@ypatil12 @eigenmikem

Highlights

This multichain release only introduces new standards and contracts. As a result, there are no breaking changes or deprecations. All new contracts are in the middlewareV2 folder.

🚀 New Features – Highlight major new functionality

  • AVSRegistrar: The primary interface for managing operator registration and deregistration within an AVS. It integrates with core EigenLayer contracts to ensure operators have valid keys and are properly registered in operator sets
  • OperatorTableCalculator: Responsible for calculating stake weights of operator. These stake weights are aggregated and transported using the Eigenlayer Multichain Protocol. In order to utilize the multichain protocol, an AVS MUST deploy an OperatorTableCalculator and register it in the CrossChainRegistry in EigenLayer core. See our core documentation for this process.

🔧 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 to keep operator stakes fresh

Changelog

  • test: ecdsa stake reg/bls sig checker utils PR #500
  • test: table calc PR #499
  • fix: avs registrar as identifier PR #494
  • fix: table calc interface PR #493
  • docs: middlewareV2/multichain PR #489
  • chore: add avs registrar interfaces PR #491
  • chore: remove unused imports PR #490
  • feat: add table calculators PR #488
  • chore: remove interfaces PR #485
  • chore: bump up ecdsa dependency PR #487
  • chore: bump up eigenlayer-contracts dependency PR #486
  • feat: avs registrar PR #484
  • refactor: singleton cv combining ECDSA and BN254 PR #479
  • feat: multichain interfaces PR #477

v1.3.1

08 May 18:46
fd26169
Compare
Choose a tag to compare

Overview
This release represents the middleware contracts release with audit changes.

Breaking Changes:

  • Removed staleStakes from the BLSSignatureChecker

Additional Notes (same as from the v1.3.0 release candidate):
In this release we bumped the openzeppelin dependency to align with the core contracts.

https://github.com/OpenZeppelin/openzeppelin-contracts/tree/release-v4.7 to https://github.com/OpenZeppelin/openzeppelin-contracts/tree/release-v4.9

Between these two releases the EIP712 implementation progressed out of draft status. And had changes to it's storage layout. This contract was used in the RegistryCoordinator (legacy) and was the first contract in the inheritance order. This meant that upgrading to the openzeppelin 4.9 would have resulted in a storage layout shift for upgrading contracts. To remedy this we moved EIP712 to be the last contract in the inheritance order so that it's storage is at the end of the storage layout. This preserves the functionality and keeps the storage layout the same pre and post upgrade.

An AVS that extended the RegistryCoordinator and added storage to the end of the storage layout will also need to make sure that EIP712Upgradeable is the last contract in the inheritance order and verify that it's the last contract in the storage layout. Extra precauction is needed in verifying these storage layout changes

Audit fixes from the release candidate

Full Changelog: v1.3.0...v1.3.1

v1.3.0

09 Apr 13:02
f5adbca
Compare
Choose a tag to compare
v1.3.0 Pre-release
Pre-release

Overview
This release represents the middleware contracts release on top of the frozen core contracts slashing release

Breaking Changes:

  • Removed the registries array that tracked all onchain registries in the RegistryCoordinator
  • The lookahead period for slashable stakes can no longer be set longer than the DEALLOCATION_DELAY in the AllocationManager.sol in the core contracts

** Additional Notes **

In this release we bumped the openzeppelin dependency to align with the core contracts.

https://github.com/OpenZeppelin/openzeppelin-contracts/tree/release-v4.7 to https://github.com/OpenZeppelin/openzeppelin-contracts/tree/release-v4.9

Between these two releases the EIP712 implementation progressed out of draft status. And had changes to it's storage layout. This contract was used in the RegistryCoordinator (legacy) and was the first contract in the inheritance order. This meant that upgrading to the openzeppelin 4.9 would have resulted in a storage layout shift for upgrading contracts. To remedy this we moved EIP712 to be the last contract in the inheritance order so that it's storage is at the end of the storage layout. This preserves the functionality and keeps the storage layout the same pre and post upgrade.

An AVS that extended the RegistryCoordinator and added storage to the end of the storage layout will also need to make sure that EIP712Upgradeable is the last contract in the inheritance order and verify that it's the last contract in the storage layout. Extra precauction is needed in verifying these storage layout changes

What's Changed since the release candidate

New Contributors

Full Changelog: v1.3.0-rc.0...v1.3.0

v1.4.0-testnet-holesky

18 Mar 19:47
4d63f27
Compare
Choose a tag to compare
Pre-release

Core version bump to maintain compatability with the core testnet holesky release

What's Changed

Full Changelog: v1.3.0-rc.0...v1.4.0-testnet-holesky

v1.3.0-rc.0

18 Mar 19:11
42dccf5
Compare
Choose a tag to compare
v1.3.0-rc.0 Pre-release
Pre-release

Breaking Changes:

  • Removed the registries array that tracked all onchain registries in the RegistryCoordinator
  • The lookahead period for slashable stakes can no longer be set longer than the DEALLOCATION_DELAY in the AllocationManager.sol in the core contracts

** Additional Notes **

In this release we bumped the openzeppelin dependency to align with the core contracts.

https://github.com/OpenZeppelin/openzeppelin-contracts/tree/release-v4.7 to https://github.com/OpenZeppelin/openzeppelin-contracts/tree/release-v4.9

Between these two releases the EIP712 implementation progressed out of draft status. And had changes to it's storage layout. This contract was used in the RegistryCoordinator (legacy) and was the first contract in the inheritance order. This meant that upgrading to the openzeppelin 4.9 would have resulted in a storage layout shift for upgrading contracts. To remedy this we moved EIP712 to be the last contract in the inheritance order so that it's storage is at the end of the storage layout. This preserves the functionality and keeps the storage layout the same pre and post upgrade.

An AVS that extended the RegistryCoordinator and added storage to the end of the storage layout will also need to make sure that EIP712Upgradeable is the last contract in the inheritance order and verify that it's the last contract in the storage layout. Extra precauction is needed in verifying these storage layout changes

What's Changed

New Contributors

Full Changelog: v1.1.1-testnet-slashing...v1.3.0-rc.0

v1.1.1-testnet-slashing

21 Feb 21:55
848032a
Compare
Choose a tag to compare
Pre-release

What's Changed

BREAKING:
New mandatory setup sequence for AVS registration. AVSs MUST set metadata in the allocation manager before:

  • Creating operator sets (createOperatorSets)
  • Registering operators (registerOperator)

Failing to set metadata will cause these operations to revert

BREAKING:
AVS-Registrar Integration

  • A new required callback implementation via supportsAVS(address)
  • A new parameter added to the operator set-based register/deregister interfaces

AVSs must implement the new callback mechanism to establish the AVS-AVSRegistrar relationship and must update their operator set registration/deregistration functions to handle this added parameter

IMPROVEMENTS:
Ejection State Handling

  • Improved the deregistration interactions with the core protocol to be simpler and better handle ejection cases
  • Improved Socket Registry functionality and reliability

PRs

New Contributors

Full Changelog: v1.0.3-testnet-slashing...v1.1.1-testnet-slashing

v1.0.3-testnet-slashing

28 Jan 00:33
11b0061
Compare
Choose a tag to compare
Pre-release

Slashing Release Features and Changes

The code is being released for testnet in an unaudited and untested state and will be entering an audit as we prepare for the mainnet slashing release

Overview

  • ELIPs on Slashing/OperatorSets/UAM
  • EigenLayer UAM integration and removal of dependency on the ServiceManager for proxying calls. #357
    • For existing AVSs that have deployed a ServiceManager, it is highly recommended to set your account identifier in the UAM as the old ServiceManager address even if the contract no longer becomes the entrypoint for calls between the AVS middleware contracts and the core EigenLayer contracts.
    • The current implementation of middleware expects the following setup of UAM.
      • SlashingRegistryCoordinator being able to call
        1. AllocationManager.createOperatorSets
        2. AllocationManager.deregisterFromOperatorSets (for force deregistration)
      • StakeRegistry being able to call
        1. AllocationManager.addStrategiesToOperatorSet
        2. AllocationManager.removeStrategiesFromOperatorSet
      • SlasherBase being able to call
        1. AllocationManager.slashOperator
  • RegistryCoordinator & SlashingRegistryCoordinator #361
    • The RegistryCoordinator now inherits from the SlashingRegistryCoordinator while maintaining backwards compatability of interfaces. Reasoning for this change is detailed below.
    • The RegistryCoordinator has been updated to enable OperatorSet mode. What this means is that newly created quorums will result in calling the AllocationManager to create the respective OperatorSet. This implies a different operator registration/deregistration flow where the RegistryCoordinator implements the IAVSRegistrar interface to support calls from the AllocationManager in the EigenLayer protocol.
    • Newly developing AVSs should ignore the RegistryCoordinator and simply use the SlashingRegistryCoordinator as this by default initializes to OperatorSet mode without the legacy Operator registration/deregistration interfaces.
    • Already deployed AVSs with existing quorums should use the RegistryCoordinator for backwards compatibility of legacy quorums. For existing AVSs who wish to migrate to OperatorSets, they need to first enableOperatorSets() to enable OperatorSet mode and create OperatorSet quorums. They can then call disableM2QuorumRegistration() to begin to deprecate legacy quorum registration. Operators are always allowed to deregister from legacy quorums.
  • SlashingBase and templates are added in /slashers directory. These contracts are meant to be inherited with AVS slashing logic specific to your needs.
  • StakeRegistry reads from the AllocationManager to get slashable stake for newly created StakeType.TOTAL_SLASHABLE quorums.
  • Solidity version bump 0.8.12 -> 0.8.27 as well as custom errors with require checks.
  • Added storage gaps to the EjectionManager contract. This is a breaking change for any deployed contract that has inherited and added additional storage previously.

Migration Guide

For StakeRegistry Users

  1. Update imports for new interfaces to import structs from IStakeRegistryTypes:

    • Replace StakeUpdate with IStakeRegistryTypes.StakeUpdate
    • Replace StrategyParams with IStakeRegistryTypes.StrategyParams
    • Replace StakeType with IStakeRegistryTypes.StakeType
  2. Update stake tracking functionality:

    • Support for both delegated and slashable stake types per quorum
    • New stake history tracking with block number indexing
    • Stake weight calculation with strategy multipliers
  3. Handle new quorum initialization:

    • initializeDelegatedStakeQuorum for total delegated stake tracking
    • initializeSlashableStakeQuorum for slashable stake with lookahead period
    • Strategy params and minimum stake requirements per quorum
  4. Implement new stake query features:

    • Get stake at specific block numbers and indices
    • Query stake history length and updates
    • Get current and historical total stake per quorum
    • Support for strategy params management

For ISocketUpdater Users

  1. Remove all usage of ISocketUpdater interface
  2. Update socket update functionality to use IRegistryCoordinator
  3. Update event listeners to use OperatorSocketUpdate from IRegistryCoordinatorEvents

For ECDSAStakeRegistry Users

  1. Update imports for now interfaces:
    • ECDSAStakeRegistryStorage
    • IECDSAStakeRegistry
    • IECDSAStakeRegistryTypes
  2. Rename any calls to getLastestOperatorSigningKey to getLatestOperatorSigningKey
  3. Update type references:
    • Replace Quorum with IECDSAStakeRegistryTypes.Quorum
    • Replace StrategyParams with IECDSAStakeRegistryTypes.StrategyParams
  4. Review parameter names in function calls if using explicit naming ie, function({name: param, name2} to ensure they match the new convention

For RegistryCoordinator Users

  1. Update imports for new interfaces to import structs from the IRegistryCoordinatorTypes:

    • Replace OperatorStatus with IRegistryCoordinatorTypes.OperatorStatus
    • Replace OperatorInfo with IRegistryCoordinatorTypes.OperatorInfo
    • Replace QuorumBitmapUpdate with IRegistryCoordinatorTypes.QuorumBitmapUpdate
    • Replace OperatorSetParam with IRegistryCoordinatorTypes.OperatorSetParam
    • Replace OperatorKickParam with IRegistryCoordinatorTypes.OperatorKickParam
  2. Update operator registration flow:

    • M2 quorum registration checks
    • New operator sets functionality
  3. Handle new registration restrictions:

    • Checks for m2QuorumsDisabled flag
    • Validate operator set mode
  4. Update deregistration logic:

    • M2 quorum-specific checks
  5. Implement new operator set features:

    • Support for enabling/disabling operator sets
    • Handle M2 quorum registration states

For BLSSignatureChecker Users

  1. Update imports for new interfaces to import structs from the IBLSSignatureCheckerTypes:

    • Replace NonSignerInfo with IBLSSignatureCheckerTypes.NonSignerInfo
    • Replace NonSignerStakesAndSignature with IBLSSignatureCheckerTypes.NonSignerStakesAndSignature
    • Replace QuorumStakeTotals with IBLSSignatureCheckerTypes.QuorumStakeTotals
  2. Update event handling:

    • Import events from IBLSSignatureCheckerEvents
    • Update event emissions to match interface definitions

For BLSApkRegistry Users

  1. Update imports for new interfaces to import structs from the IBLSApkRegistryTypes:

    • Replace ApkUpdate with IBLSApkRegistryTypes.ApkUpdate
    • Replace PubkeyRegistrationParams with IBLSApkRegistryTypes.PubkeyRegistrationParams
  2. Update event handling:

    • Import events from IBLSApkRegistryEvents

For IndexRegistry Users

  1. Update imports for new interfaces:
    • IndexRegistry
    • IIndexRegistryEvents
    • IIndexRegistryTypes
  2. Update type references:
    • Replace QuorumUpdate with IIndexRegistryTypes.QuorumUpdate
    • Replace OperatorUpdate with IIndexRegistryTypes.OperatorUpdate

Full Changelog: v0.5.4-mainnet-rewards-v2...v1.0.3-testnet-slashing

v0.5.4-mainnet-rewards-v2

21 Jan 21:55
2475ab8
Compare
Choose a tag to compare

What's Changed

Full Changelog: v0.4.3-mainnet-rewards...v0.5.4-mainnet-rewards-v2

v0.4.3-mainnet-rewards

16 Dec 14:55
512ce73
Compare
Choose a tag to compare

What's Changed

Full Changelog: v0.1.3-mainnet-m2+pragma-change...v0.4.3-mainnet-rewards