Execution
Understand how AvalancheGo executes transactions efficiently, including Continuous Execution and optimized state storage.
AvalancheGo is evolving its execution model to achieve higher throughput and lower latency. This section covers the advanced execution concepts being developed for Avalanche, including decoupled consensus and execution, and optimized state storage.
Status: Continuous Execution runs on the C-Chain. It became active with the Helicon upgrade (Fuji July 28, 2026 and Mainnet September 22, 2026, both at 15:00 UTC). Firewood is an experimental C-Chain state scheme ("state-scheme": "firewood"). The default scheme is hash.
Execution at a Glance
| Concept | Description |
|---|---|
| Continuous Execution | Decouples consensus from execution, allowing both to proceed concurrently |
| Firewood | Compaction-less database optimized for Merkleized blockchain state |
| Optimistic Parallelism | Execute multiple transactions concurrently with conflict detection |
Key Innovations
Decoupled Consensus and Execution
Traditional blockchain execution is synchronous: transactions are executed and their results computed before the block is accepted by consensus. AvalancheGo's Continuous Execution (formerly Streaming Asynchronous Execution) breaks this tight coupling:
This separation enables:
- Higher throughput: Consensus and execution proceed in parallel
- Reduced latency: Blocks are accepted faster
- Better resource utilization: No context switching between consensus and execution
Figure 1 shows the stops of one block, block N. Consensus accepts the block, and its transactions are final at that point. Then the EVM executes the block, and its receipts and logs exist. Later, the header of block N+k records a state root that includes block N. It is the state root after the last block that finished execution, on the gas clock, at least τ before the time of block N+k. The delay τ (tau) is fixed: 5 seconds. The gap k is not fixed: it changes with the block rate and the load on the chain. Finality and the state root are two different things: τ has no effect on finality. The RPC block tags safe and finalized return the last block whose state root is committed (stop 3), not the last accepted block.
Optimized State Storage
Firewood reimagines blockchain state storage by storing Merkle trie nodes directly on disk, eliminating the need for:
- Generic key-value stores (LevelDB, RocksDB)
- Expensive compaction cycles
- Hash-based storage addressing
Why This Matters
For node operators:
- Lower hardware requirements through better resource utilization
- More predictable performance without compaction pauses
- Faster state sync with native trie operations
For developers:
- Higher transaction throughput
- Lower confirmation latency for users
- More consistent block times
For the network:
- Better scalability without sacrificing decentralization
- Improved validator experience
- Foundation for future optimizations (encrypted mempools, VRF)
Explore Further
Continuous Execution
Learn how Continuous Execution decouples consensus from execution for higher throughput
Firewood Database
Discover the compaction-less database optimized for Merkleized state
Related Resources
- ACP-194: Continuous Execution - Formal specification
- saevm - Reference Continuous Execution implementation in AvalancheGo
- Firewood Repository - Database implementation
Is this guide helpful?