Overview#

The Worker Loop is the central operational component of the EigenLayer-AVS Operator. It manages the continuous monitoring of trigger conditions, communicates with the Aggregator service, and handles task notifications. This document explains the Worker Loop's architecture, initialization process, and primary operational flows.

For information about the Operator's registration process with EigenLayer, see Registration and Aliasing. For details on specific trigger implementations, see Trigger Engines.

Sources:

• operator/worker_loop.go24-26

Architecture and Components#

The Worker Loop coordinates several interconnected components to enable operators to monitor events and notify the Aggregator when tasks need to be executed. Below is the high-level architecture:

The Worker Loop consists of these key components:

1. Main Loop (runWorkLoop): Orchestrates all activities and processes trigger events.
2. Message Streaming (StreamMessages): Maintains a gRPC connection to receive task updates.
3. Server Ping (PingServer): Periodically checks in with the Aggregator.
4. Trigger Engines: Monitor different types of conditions (block, event, time).
5. Communication Channels: Pass trigger notifications between components.

Sources:

• operator/worker_loop.go27-137
• operator/operator.go153-155

Initialization Process#

When the Operator starts, the Worker Loop initializes all necessary components:

Key initialization steps:

1. Scheduler Setup: Creates a gocron scheduler and schedules the PingServer task to run every 5 seconds.
2. RPC Configuration: Sets up RPC connections for blockchain communication.
3. Trigger Channel Creation: Creates channels for each trigger type with buffer size of 1000.
4. Trigger Engine Initialization: Initializes and starts the block, event, and time trigger engines.
5. Message Streaming: Starts a goroutine to stream messages from the Aggregator.

The event trigger is optional and only started if explicitly enabled in the configuration.

Sources:

• operator/worker_loop.go30-75

Message Streaming#

The StreamMessages function establishes and maintains a persistent gRPC connection with the Aggregator to receive task updates:

The streaming process involves:

1. Authentication: Generating a BLS signature for authentication with the Aggregator.
2. Stream Establishment: Creating a SyncMessages gRPC stream with the Aggregator.
3. Message Processing: Continuously receiving and processing messages from the stream.
4. Error Handling: Managing disconnections with retry logic (15-second delay).
5. Task Management: Adding or removing tasks from the appropriate trigger engines based on messages.

When processing messages, the function handles different operations based on the MessageOp type:

• CancelTask/DeleteTask: Removes the task from monitoring
• MonitorTaskTrigger: Adds the task to the appropriate trigger engine based on its type

Sources:

• operator/worker_loop.go139-219

Trigger Monitoring and Notification#

The main work loop continuously monitors the trigger channels and notifies the Aggregator when trigger conditions are met:

Each trigger type has specific data associated with it:

1. Time Trigger: Monitors time-based conditions (cron expressions or fixed times)

   • Channel data includes task ID and epoch marker
   • Notifies with TriggerReason_Cron type

2. Block Trigger: Monitors for specific blockchain blocks

   • Channel data includes task ID and block number
   • Notifies with TriggerReason_Block type

3. Event Trigger: Monitors for specific smart contract events

   • Channel data includes task ID, block number, log index, and transaction hash
   • Notifies with TriggerReason_Event type

When a trigger condition is met, the Worker Loop sends a NotifyTriggers RPC call to the Aggregator with the task ID and relevant trigger information.

Sources:

• operator/worker_loop.go77-136

Periodic Server Ping#

The Worker Loop schedules a periodic ping to the Aggregator to maintain connection and report status:

The ping operation:

1. Metrics Update: Increments loop counter and adds uptime metrics

2. Authentication: Generates a BLS signature for request authentication

3. Status Report: Sends status information including:

   • Operator address and ID
   • Signature for verification
   • Operator version
   • IP address and metrics port
   • Current block number and event count

4. Metrics Collection: Records ping success/failure and duration

The ping serves as both a heartbeat and a status reporting mechanism, allowing the Aggregator to track operator health and progress.

Sources:

• operator/worker_loop.go221-262

Error Handling and Reconnection#

The Worker Loop implements robust error handling to maintain continuous operation:

Scenario	Handling Mechanism	Location
Initial connection failure	Retry with 15-second delay	operator/worker_loop.go161-166
Stream disconnection	Return to connection loop with 15-second delay	operator/worker_loop.go174-177
Trigger notification failure	Log error but continue operation	operator/worker_loop.go94-96 110-112 129-131
Metrics server error	Fatal error (exits application)	operator/worker_loop.go132-134

The reconnection process uses the retryConnect method from the Operator to re-establish the gRPC connection with appropriate authentication credentials.

Sources:

• operator/worker_loop.go161-166
• operator/operator.go448-467

Integration with Trigger Engines#

The Worker Loop integrates with three types of trigger engines, each monitoring different conditions:

Key integration points:

1. Task Registration: Tasks received from the Aggregator are registered with the appropriate trigger engine based on the trigger type.
2. Task Cancellation: Tasks that are canceled or deleted are removed from monitoring.
3. Trigger Notification: Each trigger engine sends notifications to the Worker Loop through dedicated channels when conditions are met.
4. Progress Tracking: The Worker Loop reports monitoring progress (current block number, event count) to the Aggregator during pings.

The specific implementation of each trigger engine is detailed in the Trigger Engines documentation.

Sources:

• operator/worker_loop.go53-71
• operator/worker_loop.go181-216

Performance Considerations#

The Worker Loop is designed with performance in mind:

1. Buffered Channels: All trigger channels are buffered (size 1000) to prevent blocking.
2. Goroutine Separation: The StreamMessages function runs in a separate goroutine to avoid blocking the main loop.
3. Optional Components: The event trigger engine is only enabled if explicitly configured, as it can be resource-intensive.
4. Metrics Collection: Performance metrics are collected to monitor the health and efficiency of the Worker Loop.

When implementing or modifying the Worker Loop, consider these performance aspects to maintain efficient operation.

Sources:

• operator/worker_loop.go54-60
• operator/worker_loop.go67-71

Feature this wiki to auto refresh weekly