Operator
The Operator is a key component in the EigenLayer-AVS system that monitors blockchain events, blocks, and time-based triggers.
The Operator is a key component in the EigenLayer-AVS system that monitors blockchain events, blocks, and time-based triggers. It acts as a sentinel that watches for predefined conditions and reports them to the Aggregator for task execution. The Operator component integrates with EigenLayer for distributed validation and ensures secure communication using BLS signatures.
For information about task execution after conditions are detected, see Task Engine and for aggregation of trigger notifications, see Aggregator.
Overview#
The Operator node performs several critical functions in the EigenLayer-AVS architecture:
- Trigger Monitoring: Continuously monitors the blockchain for event, block, and time-based triggers
- Notification: Notifies the Aggregator when trigger conditions are met
- EigenLayer Integration: Registers with EigenLayer AVS to participate in the network
- Secure Communication: Uses BLS signatures to authenticate messages to the Aggregator
Sources:
Operator Architecture#
The Operator component is designed with a modular architecture consisting of the following key components:
Core Components#
-
Worker Loop: The central event processing system that listens for triggers and communicates with the Aggregator
-
Trigger Engines:
- Block Trigger: Monitors for new blocks
- Event Trigger: Monitors for contract events
- Time Trigger: Monitors for time-based triggers (cron and fixed time)
-
BLS Signature System: Supports either local key pairs or remote signing via a service
-
Registration Manager: Handles operator registration with EigenLayer AVS
-
Alias Key Manager: Supports using alternative signing keys
Sources:
Operator Configuration#
The Operator is configured via a YAML configuration file that specifies connection parameters, blockchain endpoints, and feature flags. The main configuration structure is defined in OperatorConfig
.
Key configuration parameters include:
Parameter | Description | Example |
---|---|---|
operator_address | Ethereum address of the operator | 0x123...abc |
avs_registry_coordinator_address | Address of the AVS Registry Coordinator contract | 0x456...def |
eth_rpc_url | Ethereum JSON-RPC endpoint URL | https://ethereum-sepolia.publicnode.com |
eth_ws_url | Ethereum WebSocket endpoint URL | wss://ethereum-sepolia.publicnode.com |
ecdsa_private_key_store_path | Path to ECDSA private key file | /keys/operator.key |
aggregator_server_ip_port_address | gRPC address of the Aggregator | 127.0.0.1:8090 |
bls_private_key_store_path | Path to BLS private key file | /keys/bls.key |
enable_metrics | Whether to enable Prometheus metrics | true |
enabled_features.event_trigger | Whether to enable event trigger monitoring | true |
The configuration supports two modes for BLS signing:
- Local Key: Using a local BLS key file
- Remote Signing: Using a remote signing service (like Cerberus)
Example configuration for remote signing:
Sources:
Worker Loop#
The worker loop is the central processing system of the Operator. It initializes the trigger engines, establishes a connection to the Aggregator, and processes trigger notifications.
The worker loop performs these key functions:
- Initializes Trigger Engines: Sets up and starts monitoring for block, event, and time triggers
- Opens Stream to Aggregator: Establishes a gRPC connection to receive task updates
- Periodically Pings Aggregator: Sends health checks and updates on monitoring progress
- Processes Trigger Notifications: Listens for trigger notifications from the engines and forwards them to the Aggregator
Sources:
Trigger Engines#
The Operator uses three types of trigger engines to monitor different conditions:
Block Trigger Engine#
Monitors for specific block numbers or block intervals. When a target block is reached, it sends a notification through the blockTriggerCh
channel.
Event Trigger Engine#
Monitors blockchain events based on contract addresses, topics, and event signatures. When a matching event is detected, it sends a notification through the eventTriggerCh
channel. This engine is optional and can be disabled in the configuration.
Time Trigger Engine#
Monitors for time-based triggers:
- Cron Triggers: Based on cron expressions for periodic execution
- Fixed Time Triggers: One-time triggers at a specific timestamp
When a time trigger condition is met, it sends a notification through the timeTriggerCh
channel.
Sources:
Registration with EigenLayer#
Before an Operator can start monitoring triggers, it must be registered with the EigenLayer AVS system. This registration process involves:
- Generating Registration Parameters: Creating necessary signatures and data structures
- On-chain Registration: Registering the operator with the EigenLayer Registry Coordinator contract
- Status Verification: Confirming successful registration and obtaining an operator ID
The registration process uses the EigenLayer SDK to register the operator in the specified quorum. By default, operators join quorum number 0.
The RegisterOperatorWithAvs
method handles this registration process, using the operator's ECDSA private key and BLS keypair to generate the necessary signatures.
Sources:
Operator Status and Deregistration#
Operators can check their status and deregister from the AVS if needed:
Status Check#
The Status
command queries on-chain data to provide information about the operator:
- ECDSA address
- BLS public keys (G1 and G2)
- Registration status with the AVS
- Operator ID
Deregistration#
The DeregisterFromAVS
command allows an operator to leave the AVS network by deregistering from the quorum.
Sources:
- operator/registration.go26-33
- operator/registration.go35-42
- operator/registration.go94-117
- operator/registration.go119-141
Alias Key Management#
The Operator supports using alias keys for signing operations. This allows the operator's main address to remain secure while using a different key for day-to-day signing operations.
Creating an Alias Key#
The CreateOrImportAliasKey
function allows operators to:
- Generate a new ECDSA key pair
- Import an existing private key
- Encrypt and store the key using a password
Declaring an Alias#
Once an alias key is created, the operator must declare it on-chain by calling the DeclareAlias
function, which:
- Reads the alias key from the provided file
- Submits a transaction to the APConfig contract declaring the alias
- Associates the alias address with the operator's main address
Removing an Alias#
If an operator wants to stop using an alias, they can call RemoveAlias
to:
- Check if an alias is being used
- Submit a transaction to the APConfig contract to remove the alias
Sources:
Communication with Aggregator#
The Operator communicates with the Aggregator using gRPC. This communication includes:
Authentication#
Messages sent to the Aggregator are authenticated using:
- The operator's ECDSA private key for RPC authentication
- BLS signatures for message integrity verification
Message Types#
The Operator sends several types of messages to the Aggregator:
- Ping Messages: Regular health checks and status updates
- Trigger Notifications: When a watched condition is detected
- Subscription Messages: To receive new tasks to monitor
Stream Connection#
The Operator maintains a persistent gRPC stream with the Aggregator through the StreamMessages
method, which:
- Establishes a connection with BLS signature authentication
- Receives task monitoring instructions
- Updates local trigger engines based on received messages
Sources:
BLS Signatures#
For secure communication, the Operator uses BLS signatures which can be generated in two ways:
Local Key Signing#
When configured with a local BLS key file, the Operator generates signatures directly using the local key pair.
Remote Signing#
Alternatively, the Operator can use a remote signing service (like Cerberus) to generate signatures without storing the private key locally, which provides enhanced security.
The GetSignature
method handles signature generation through either mechanism based on the configuration.
Sources:
Deployment and Operation#
To run an Operator node:
- Generate Configuration: Create a YAML configuration file
- Generate Keys: Create ECDSA and BLS keys
- Register with EigenLayer: Register the operator with EigenLayer AVS
- Start the Operator: Run the operator process with the configuration file
The Operator process will connect to the specified Ethereum nodes and Aggregator, register for task monitoring, and begin watching for triggers based on instructions from the Aggregator.
Sources:
Feature this wiki to auto refresh weekly
Try DeepWiki on your private codebase with Devin