Continuous Execution

Continuous Execution (formerly known as Streaming Asynchronous Execution, or SAE) is a fundamental architectural change that decouples consensus from execution. By allowing these two critical processes to run concurrently, AvalancheGo can achieve significantly higher throughput without sacrificing security guarantees.

Summary

In traditional synchronous execution, a block must be fully executed before it can be accepted by consensus. Continuous Execution introduces a queue upon which consensus is performed, with a concurrent execution stream responsible for clearing the queue and reporting state roots to later consensus rounds.

Key benefits:

• Concurrent processing: Consensus and execution no longer block each other
• Reduced latency: Blocks are accepted faster
• Bursty throughput: Transactions can be eagerly accepted
• Future features: Enables encrypted mempools and real-time VRF

The Problem with Synchronous Execution

In synchronous execution models, the block lifecycle is tightly coupled:

This creates several bottlenecks:

1. Context switching: Nodes constantly switch between consensus and execution work
2. Latency accumulation: Execution time directly adds to block acceptance time
3. Resource contention: CPU-intensive execution competes with network-intensive consensus
4. Stop-the-world events: Database compaction or GC pauses affect both consensus and execution

How Continuous Execution Works

Continuous Execution separates the block lifecycle into distinct phases:

Block Lifecycle

Lightweight Validation

Before accepting a block, validators perform lightweight validation to ensure all transactions can eventually be executed. This validation:

• Checks sender balances against worst-case bounds
• Verifies the maximum required base fee
• Does not execute transactions or compute state

The Execution Queue

Once accepted, blocks enter a FIFO execution queue:

The block executor runs in parallel with consensus, constantly processing blocks from the queue.

Settlement

Executed blocks are settled when a later block includes their execution results. The settlement includes:

• State root: The root hash after executing the block
• Receipt root: Merkle root of all receipts since last settlement

A constant time delay ($\tau$ seconds) ensures that sporadic execution slowdowns are amortized.

Technical Specification

Gas Charging

Continuous Execution introduces a new gas charging formula that accounts for the gas limit:

$$g_C := \max(g_U, g_L / \lambda)$$

Where:

• $g_C$ = gas charged
• $g_U$ = gas used
• $g_L$ = gas limit
• $\lambda$ = limit factor (enforces minimum charge based on limit)

This prevents transactions from reserving large gas limits without paying proportionally.

Block Size Limits

The maximum block size is constrained by the settlement delay:

$$\omega_B := R \cdot \tau \cdot \lambda$$

Where:

• $\omega_B$ = maximum block size (gas)
• $R$ = gas capacity per second
• $\tau$ = settlement delay
• $\lambda$ = limit factor

Queue Size Limits

The execution queue has a maximum size to prevent unbounded growth:

$$\omega_Q := 2 \cdot \omega_B$$

A block is invalid if the queue already holds more than $\omega_Q$ gas when the block is enqueued. The new block itself can take the queue above $\omega_Q$.

Performance Implications

Concurrent Execution Streams

The primary benefit is that "VM time" more closely aligns with wall time:

In synchronous mode, consensus and execution alternate. In Continuous Execution, they overlap, increasing throughput.

Lean Execution Clients

Continuous Execution enables specialized execution-only clients that can:

• Rapidly execute the agreed-upon queue
• Skip expensive Merkle data structure computation
• Provide accelerated receipt issuance

This is valuable for:

• High-frequency trading applications
• Custodial platforms monitoring deposits
• Indexers tracking specific addresses

Amortized Overhead

Irregular events like database compaction are spread across multiple blocks instead of causing individual block delays.

Future Features

Continuous Execution provides a foundation for additional optimizations:

Encrypted Mempools

By performing execution after consensus sequencing, transactions can remain encrypted until their order is finalized. This reduces:

• Front-running attacks
• MEV extraction
• Transaction censorship

Real-Time VRF

Consensus artifacts become available during execution, enabling:

• Verifiable random functions during execution
• Fair on-chain randomness
• Gaming and lottery applications

Implementation

saevm

The reference implementation of Continuous Execution is vms/saevm in AvalancheGo. The C-Chain VM, vms/saevm/cchain, is built on it. The StreVM repository is archived, and its code moved to AvalancheGo.

Integration with AvalancheGo

Continuous Execution integrates with AvalancheGo's existing architecture:

Related Resources

External Links

• ACP-194 Specification
• saevm in AvalancheGo
• ACP-194 Discussion