Worker Loop
Documentation for Worker Loop in the EigenLayer-AVS system.
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:
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:
- Main Loop (
runWorkLoop
): Orchestrates all activities and processes trigger events. - Message Streaming (
StreamMessages
): Maintains a gRPC connection to receive task updates. - Server Ping (
PingServer
): Periodically checks in with the Aggregator. - Trigger Engines: Monitor different types of conditions (block, event, time).
- Communication Channels: Pass trigger notifications between components.
Sources:
Initialization Process#
When the Operator starts, the Worker Loop initializes all necessary components:
Key initialization steps:
- Scheduler Setup: Creates a gocron scheduler and schedules the
PingServer
task to run every 5 seconds. - RPC Configuration: Sets up RPC connections for blockchain communication.
- Trigger Channel Creation: Creates channels for each trigger type with buffer size of 1000.
- Trigger Engine Initialization: Initializes and starts the block, event, and time trigger engines.
- 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:
Message Streaming#
The StreamMessages
function establishes and maintains a persistent gRPC connection with the Aggregator to receive task updates:
The streaming process involves:
- Authentication: Generating a BLS signature for authentication with the Aggregator.
- Stream Establishment: Creating a
SyncMessages
gRPC stream with the Aggregator. - Message Processing: Continuously receiving and processing messages from the stream.
- Error Handling: Managing disconnections with retry logic (15-second delay).
- 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 monitoringMonitorTaskTrigger
: Adds the task to the appropriate trigger engine based on its type
Sources:
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:
-
Time Trigger: Monitors time-based conditions (cron expressions or fixed times)
- Channel data includes task ID and epoch marker
- Notifies with
TriggerReason_Cron
type
-
Block Trigger: Monitors for specific blockchain blocks
- Channel data includes task ID and block number
- Notifies with
TriggerReason_Block
type
-
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:
Periodic Server Ping#
The Worker Loop schedules a periodic ping to the Aggregator to maintain connection and report status:
The ping operation:
-
Metrics Update: Increments loop counter and adds uptime metrics
-
Authentication: Generates a BLS signature for request authentication
-
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
-
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:
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:
Integration with Trigger Engines#
The Worker Loop integrates with three types of trigger engines, each monitoring different conditions:
Key integration points:
- Task Registration: Tasks received from the Aggregator are registered with the appropriate trigger engine based on the trigger type.
- Task Cancellation: Tasks that are canceled or deleted are removed from monitoring.
- Trigger Notification: Each trigger engine sends notifications to the Worker Loop through dedicated channels when conditions are met.
- 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:
Performance Considerations#
The Worker Loop is designed with performance in mind:
- Buffered Channels: All trigger channels are buffered (size 1000) to prevent blocking.
- Goroutine Separation: The
StreamMessages
function runs in a separate goroutine to avoid blocking the main loop. - Optional Components: The event trigger engine is only enabled if explicitly configured, as it can be resource-intensive.
- 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:
Feature this wiki to auto refresh weekly
Try DeepWiki on your private codebase with Devin