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:

1. Trigger Monitoring: Continuously monitors the blockchain for event, block, and time-based triggers
2. Notification: Notifies the Aggregator when trigger conditions are met
3. EigenLayer Integration: Registers with EigenLayer AVS to participate in the network
4. Secure Communication: Uses BLS signatures to authenticate messages to the Aggregator

Sources:

• operator/operator.go108-156
• operator/worker_loop.go20-137

Operator Architecture#

The Operator component is designed with a modular architecture consisting of the following key components:

Core Components#

1. Worker Loop: The central event processing system that listens for triggers and communicates with the Aggregator

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

3. BLS Signature System: Supports either local key pairs or remote signing via a service

4. Registration Manager: Handles operator registration with EigenLayer AVS

5. Alias Key Manager: Supports using alternative signing keys

Sources:

• operator/operator.go108-156
• operator/worker_loop.go54-65

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:

1. Local Key: Using a local BLS key file
2. Remote Signing: Using a remote signing service (like Cerberus)

Example configuration for remote signing:

Sources:

• operator/operator.go61-106
• operator/operator.go167-176

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:

1. Initializes Trigger Engines: Sets up and starts monitoring for block, event, and time triggers
2. Opens Stream to Aggregator: Establishes a gRPC connection to receive task updates
3. Periodically Pings Aggregator: Sends health checks and updates on monitoring progress
4. Processes Trigger Notifications: Listens for trigger notifications from the engines and forwards them to the Aggregator

Sources:

• operator/worker_loop.go27-137
• operator/worker_loop.go139-219
• operator/worker_loop.go221-262

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:

• operator/worker_loop.go54-71
• operator/worker_loop.go81-132

Registration with EigenLayer#

Before an Operator can start monitoring triggers, it must be registered with the EigenLayer AVS system. This registration process involves:

1. Generating Registration Parameters: Creating necessary signatures and data structures
2. On-chain Registration: Registering the operator with the EigenLayer Registry Coordinator contract
3. 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/registration.go17-24
• operator/registration.go45-80

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:

1. Generate a new ECDSA key pair
2. Import an existing private key
3. 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:

1. Reads the alias key from the provided file
2. Submits a transaction to the APConfig contract declaring the alias
3. 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:

1. Check if an alias is being used
2. Submit a transaction to the APConfig contract to remove the alias

Sources:

• operator/alias.go14-60
• operator/alias.go62-112
• operator/alias.go114-159

Communication with Aggregator#

The Operator communicates with the Aggregator using gRPC. This communication includes:

Authentication#

Messages sent to the Aggregator are authenticated using:

1. The operator's ECDSA private key for RPC authentication
2. BLS signatures for message integrity verification

Message Types#

The Operator sends several types of messages to the Aggregator:

1. Ping Messages: Regular health checks and status updates
2. Trigger Notifications: When a watched condition is detected
3. 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:

1. Establishes a connection with BLS signature authentication
2. Receives task monitoring instructions
3. Updates local trigger engines based on received messages

Sources:

• operator/worker_loop.go139-219
• operator/operator.go448-467
• operator/worker_loop.go221-262

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:

• operator/operator.go507-538

Deployment and Operation#

To run an Operator node:

1. Generate Configuration: Create a YAML configuration file
2. Generate Keys: Create ECDSA and BLS keys
3. Register with EigenLayer: Register the operator with EigenLayer AVS
4. 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:

• operator/operator.go158-165
• operator/operator.go410-446

Feature this wiki to auto refresh weekly