Architecting a Faster Avalanche: A Deep Dive into Streaming Asynchronous Execution

A new Avalanche Community Proposal (ACP-194) introduces Streaming Asynchronous Execution (SAE), a foundational redesign of the C-Chain's architecture. By decoupling transaction ordering (consensus) from transaction processing (execution), SAE aims to significantly boost throughput, reduce latency, and unlock a new wave of advanced, high-performance applications on Avalanche.

The Current Bottleneck: Synchronous Execution

To understand SAE, it’s helpful to look at the traditional model used by the C-Chain and other EVM-compatible networks. In synchronous execution, every block of transactions follows a strict, linear sequence:

1. Proposed: A validator suggests a new block.

2. Executed: All transactions in the block are fully processed to determine their results.

3. Accepted/Settled: The network validates the block and its execution results, then finalizes it.

This "stop-and-wait" approach means the entire network must wait for the computationally intensive execution step to finish before a block can be finalized by the Snowman consensus protocol. This creates a bottleneck, limiting the C-Chain's overall transaction-per-second (TPS) capacity.The SAE Solution: A Parallel Highway for Transactions

SAE fundamentally redesigns this flow for the C-Chain. It separates the fast work of ordering transactions from the heavy lifting of executing them.

1. Proposed: A block builder suggests a block. Crucially, they do not execute the transactions. They only perform a lightweight check to ensure every transaction can afford its worst-case fee.

2. Accepted: If the check passes, the block is swiftly accepted by consensus and added to a First-In, First-Out (FIFO) execution queue.

3. Executed: A separate, parallel "block executor" process constantly pulls blocks from this queue and runs the transactions.

4. Settled: After a fixed delay (τ, proposed as 5 seconds for the C-Chain), a subsequent block will reference the execution results and permanently record them on the blockchain, settling the transactions.

Essentially, Snowman consensus focuses purely on ordering transactions, while a concurrent stream handles the computation.

Why This Matters for the Avalanche Ecosystem

The benefits of implementing SAE on the C-Chain are substantial:

• Massive Performance Gains: By running consensus and execution in parallel, the network can process more transactions in the same amount of real-world time. This directly increases the C-Chain's gas-per-second capacity.

• Lean, High-Frequency Clients: This architecture allows sophisticated users, like DeFi traders, to run optimized nodes that only execute the queue. They can see transaction results well ahead of final settlement, setting the stage for advanced, high-frequency strategies on Avalanche.

• Future-Proofing the C-Chain: SAE is a prerequisite for advanced features like encrypted mempools to combat front-running and the use of real-time randomness (VRF) during transaction execution, making dApps fairer and more powerful.

Security: Guarantees and Spam Protection

SAE is designed to be as secure as the current system, using two key mechanisms:

1. Worst-Case Validity: The initial check guarantees that a transaction can pay its maximum possible fee. If a sender can cover this cost, they are guaranteed to be able to afford the actual cost when execution occurs. Acceptance guarantees settlement.

2. Queue DoS Protection: To prevent spam, SAE modifies gas charging. A transaction is charged max(gas_used, gas_limit / λ). The ACP proposes λ (lambda) be set to 2. This penalizes users who set gas limits more than double what's needed, making it expensive to clog the network with low-value, high-limit transactions.

What Changes for Avalanche Users and Developers?

For end-users, SAE promises a smoother, faster C-Chain. For developers, the most notable change is how they interact with block data:

Block Field Changes

Because execution results are recorded in a later block, the meaning of several core block header fields will be modified. Fields likely to change include:

• stateRoot

• receiptsRoot

• logsBloom

• gasUsed

JSON RPC API Behavior

The EVM-standard APIs will be preserved, but their behavior will map to the new asynchronous lifecycle.

• eth_getBlockReceipts: This API will still return the receipts corresponding to the block's transactions, not the receipts that happen to be settled in that block. This ensures a consistent and intuitive developer experience.

• Named Blocks: The interpretation of named block parameters will be updated for more precision:

  • pending: The most recently accepted block.

  • latest: The block that was most recently executed.

  • safe and finalized: The block that was most recently settled. Due to the rapid finality guarantees of Snowman consensus, there is no practical distinction between safe and finalized on Avalanche.

Conclusion

Streaming Asynchronous Execution is a sophisticated proposal designed to elevate the C-Chain's capabilities. By re-architecting the core engine while carefully maintaining EVM compatibility and developer experience, SAE aims to solidify Avalanche's position as a leading platform for decentralized applications that demand elite performance and scale.