Roadmap: Async Execution

[MaxResnick]

Overview

This issue tracks the implementation of asynchronous execution on Solana, a major performance enhancement that will allow validators to vote on blocks before completing execution. This change will significantly reduce block confirmation latency and is a prerequisite for future improvements like multiple concurrent proposers and shorter block times.

---

What is Asynchronous Execution?

Currently, Solana validators must fully execute a block before voting on it:

|----- leader broadcasts block -------|
                        |--- validator receives ---|                |-- validator votes --| <- certificate formed
                                   |--- validator executes block ---|

With async execution, validators can vote immediately after receiving the block:

|----- leader broadcasts block -------|
                        |--- validator receives ---||-- validator votes --| <- certificate formed
                               |--- validator executes block ---|

---

Why These Changes Enable Async Execution

The key insight is that validators need to be able to vote on blocks without executing them. This requires:

1. Relaxing constraints that require execution state - Many current protocol violations require knowing the result of execution (e.g., does the fee payer have enough balance?). These must become runtime errors that can be included in blocks.
2. Maintaining consensus on execution - Without BankHash in votes, we need another mechanism to ensure validators agree on execution results (SIMD-0298).

---

Implementation Requirements

Dependencies Status

SIMD	Title	Purpose	PR	Status
SIMD-0159	Relax Precompile Failure Constraint	Allows precompile verification failures to be included as runtime errors	#159	✅ Activated (feature: 9ypxGLzkMxi89eDerRKXWDXe44UY2z4hBig4mDhNq5Dp)
SIMD-0191	Loaded Data Size and Program Account Checks	Validates transaction data requirements pre-execution	#191	✅ Activated (feature: PaymEPK2oqwT9TXAVfadjztH2H6KfLEB9Hhd5Q5frvP)
SIMD-0192	Relax Transaction Account Resolution	Converts ALT resolution failures from protocol violations to runtime errors	#192	🔄 In Review
SIMD-0290	Relax Fee Payer Constraint	Allows invalid fee payers to be included as failed transactions	#290	🔄 In Review
SIMD-0295	Relax CU Limit Overage	Creates "skipped blocks" for CU overages instead of rejecting blocks	#295	🔄 In Review
SIMD-0297	Relax Invalid Nonced Transactions Constraint	Converts nonce failures from block failures to transaction failures	#297	🔄 In Review
SIMD-0298	Add Parent Bank Hash to Block Header	Maintains consensus on execution by including parent BankHash	#298	🔄 In Review
SIMD-0301	Remove BankHash from Votes	Final step - removes BankHash from vote messages	#301	🔄 In Review

Related Work

• SIMD-0307 (#307) - Adds block footer with metadata (producer timestamp, user agent) for monitoring and diagnostics. Not a direct dependency but enhances block structure.

---

Key Concepts

Protocol Violations vs Runtime Errors

• Protocol Violations: Errors that invalidate the entire block (current behavior for many constraints).
• Runtime Errors: Errors that cause individual transaction failure but allow block inclusion.

The relaxation SIMDs (0192, 0290, 0295, 0297) convert various protocol violations into runtime errors, allowing validators to vote without knowing execution results.

Specific Relaxations

1. SIMD-0192: Address lookup tables don't need to be resolved - transactions with invalid ALTs can be included and fail at runtime.
2. SIMD-0290: Fee payer balance doesn't need to be checked - transactions without sufficient fees can be included (but don't execute).
3. SIMD-0295: Blocks exceeding CU limits become "skipped blocks" - committed but with no state changes.
4. SIMD-0297: Invalid nonces become transaction failures instead of block failures.

Maintaining Execution Consensus

• SIMD-0298: Adds parent BankHash to the block header, ensuring validators still reach consensus on execution (just one slot delayed).
• SIMD-0301: Finally removes BankHash from votes, completing the async execution transition.

---

Progress Summary

• Completed: 2/8 (25%) - Precompile and data validation foundations.
• In Review: 6/8 (75%) - Constraint relaxations and final implementation.

---

Timeline & Activation

• Target: Activation with or after Alpenglow.
• All prerequisites must be satisfied before SIMD-0301 activation.
• May require coordinated feature flag activation if not ready for Alpenglow.

---

Impact

Benefits

• ✅ Significant reduction in block confirmation latency.
• ✅ Enables future enhancements (concurrent proposers, shorter block times).

Considerations

• ⚠️ Consensus-breaking changes requiring coordinated validator updates.
• ⚠️ Transactions may fail silently in skipped blocks or due to relaxed constraints.
• ⚠️ Tooling (explorers, etc.) must handle new failure modes.
• ℹ️ No direct impact on app developers, but they should be aware of new failure modes.

---

Security Notes

• Consensus on execution is maintained through parent BankHash.

---

Tracking

This issue will be updated as SIMDs progress through review and activation. Each SIMD represents a critical piece of the async execution implementation, with SIMD-0301 serving as the final activation switch.