kona-engine crate provides a modular execution engine implementation for the OP Stack rollup node. It serves as the bridge between the rollup protocol and the execution layer (EL), managing Engine API interactions through a sophisticated task queue system.
Architecture Overview
The execution engine is built around several key components:- Engine Task Queue: A priority-ordered queue that manages Engine API operations
- Trait Abstractions: Extensible interfaces for tasks, errors, and state management
- Engine Client: HTTP client for communicating with the execution layer
- Actor Integration: Service layer integration through the
EngineActor
Core Trait Abstractions
EngineTaskExt
TheEngineTaskExt trait defines the interface for all engine tasks:
- Atomic operations over the
EngineState - Extensible task implementation for custom operations
- Async execution with proper error handling
EngineTaskError
TheEngineTaskError trait provides sophisticated error handling with severity levels:
Task Queue System
The engine uses a priority-based task queue (a binary heap ordered by theEngineTask Ord implementation) where tasks are ordered according to OP Stack synchronization requirements. Tasks are generic over an EngineClient implementation.
Task Priority (Highest to Lowest)
- Seal - Seals blocks that have finished building (sequencer mode)
- Build - Builds new blocks (sequencer mode)
- Insert - Inserts unsafe blocks from gossip
- Consolidate - Advances safe chain via derivation
- Finalize - Finalizes L2 blocks
SynchronizeTask runs as part of the other tasks whenever the forkchoice state needs to move.
Task Types
SynchronizeTask
Updates the execution layer’s forkchoice state. It is invoked by the other tasks rather than queued directly:- Forkchoice synchronization via
engine_forkchoiceUpdated - EL sync status management
BuildTask
Starts building a new block in sequencer mode, producing a payload ID:engine_forkchoiceUpdated.
SealTask
Seals a block started by aBuildTask, retrieving the payload with version-specific engine_getPayload calls, inserting it, and canonicalizing it:
InsertTask
Inserts payloads (for example unsafe blocks received from gossip) into the execution engine:ConsolidateTask
Advances the safe chain through derivation:BuildTask.
FinalizeTask
Finalizes L2 blocks:Engine State Management
TheEngineState tracks the current state of the execution engine:
EngineSyncState. State updates are communicated through watch channels, enabling reactive programming patterns across the system.
Integration with kona-node
Thekona-node service layer integrates the engine through the EngineActor:
Actor Pattern
TheEngineActor implements the NodeActor trait:
Communication Channels
TheEngineActor receives all state-mutating input through a single inbound request channel of EngineActorRequest messages: payload attributes from derivation, unsafe blocks from gossip, reset requests, finalization requests, and block building requests (sequencer mode only). A separate read-only EngineRpcActor runs as an independent peer and serves engine queries; it shares the engine client and a watch over the engine state and queue length, but is constrained to a read-only subset of the engine client so it cannot reach Engine API mutation methods.
Engine Queries
The engine supports queries for:Usage Patterns
Basic Engine Setup
Adding Tasks
Draining the Queue
Error Handling and Recovery
The engine provides robust error handling through:Severity-Based Recovery
- Temporary errors: Automatically retried
- Critical errors: Propagated to the actor
- Reset errors: Trigger derivation pipeline reset
- Flush errors: Trigger derivation pipeline flush
State Consistency
Tasks operate atomically on theEngineState, ensuring consistency even during error conditions.
Version Support
The engine automatically selects appropriate Engine API versions based on hardfork activation:- Pre-Ecotone (Bedrock, Canyon, Delta): Uses
engine_newPayloadV2andengine_getPayloadV2 - Post-Ecotone: Uses
engine_newPayloadV3andengine_getPayloadV3 - Post-Isthmus: Uses
engine_newPayloadV4andengine_getPayloadV4 - Post-Karst (Osaka): Uses
engine_getPayloadV5(engine_newPayloadandengine_forkchoiceUpdatedstay at their V4/V3 versions)
Metrics and Observability
When themetrics feature is enabled, the engine provides comprehensive metrics for:
- Task execution times
- Error rates by task type
- Engine state transitions
- API call latencies
Extensibility
The trait-based architecture allows for:- Custom task implementations via
EngineTaskExt - Custom error handling via
EngineTaskError - Custom state management extensions
- Testing and mocking support