Streaming Asynchronous Execution

Streaming Asynchronous Execution (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. SAE 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 SAE Works

SAE 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

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

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:

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:

Blocks that would exceed this queue size are considered invalid.

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 SAE, they overlap, increasing throughput.

Lean Execution Clients

SAE 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

SAE 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

StreVM

StreVM is the reference implementation of SAE for EVM blocks:

# StreVM is under active development
git clone https://github.com/ava-labs/strevm

Integration with AvalancheGo

SAE integrates with AvalancheGo's existing architecture:

Related Resources

External Links

• ACP-194 Specification
• StreVM Repository
• ACP-194 Discussion