Skip to main content
The 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

The EngineTaskExt trait defines the interface for all engine tasks:
This trait enables:
  • Atomic operations over the EngineState
  • Extensible task implementation for custom operations
  • Async execution with proper error handling

EngineTaskError

The EngineTaskError trait provides sophisticated error handling with severity levels:
This allows tasks to signal different recovery strategies based on the error type.

Task Queue System

The engine uses a priority-based task queue (a binary heap ordered by the EngineTask Ord implementation) where tasks are ordered according to OP Stack synchronization requirements. Tasks are generic over an EngineClient implementation.

Task Priority (Highest to Lowest)

  1. Seal - Seals blocks that have finished building (sequencer mode)
  2. Build - Builds new blocks (sequencer mode)
  3. Insert - Inserts unsafe blocks from gossip
  4. Consolidate - Advances safe chain via derivation
  5. Finalize - Finalizes L2 blocks
Forkchoice updates are not a standalone queue entry: the 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:
Handles:
  • Forkchoice synchronization via engine_forkchoiceUpdated
  • EL sync status management

BuildTask

Starts building a new block in sequencer mode, producing a payload ID:
Handles payload building initiation with engine_forkchoiceUpdated.

SealTask

Seals a block started by a BuildTask, 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:
If consolidation fails, the task reverts to payload attribute processing via the BuildTask.

FinalizeTask

Finalizes L2 blocks:

Engine State Management

The EngineState tracks the current state of the execution engine:
The unsafe, safe, and finalized heads live in the nested EngineSyncState. State updates are communicated through watch channels, enabling reactive programming patterns across the system.

Integration with kona-node

The kona-node service layer integrates the engine through the EngineActor:

Actor Pattern

The EngineActor implements the NodeActor trait:

Communication Channels

The EngineActor 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 the EngineState, 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_newPayloadV2 and engine_getPayloadV2
  • Post-Ecotone: Uses engine_newPayloadV3 and engine_getPayloadV3
  • Post-Isthmus: Uses engine_newPayloadV4 and engine_getPayloadV4
  • Post-Karst (Osaka): Uses engine_getPayloadV5 (engine_newPayload and engine_forkchoiceUpdated stay at their V4/V3 versions)

Metrics and Observability

When the metrics 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
This modular design ensures the engine can adapt to future OP Stack protocol changes while maintaining backward compatibility.