ACP-194 Streaming Asynchronous Execution

[meaghanfitzgerald]

Streaming Asynchronous Execution (SAE) decouples consensus and execution by introducing a (theoretically unbounded) transaction queue upon which consensus is performed. A concurrent execution stream is responsible for clearing the queue and reporting a delayed state root for recording by later rounds of consensus. Validation of transactions to be pushed to the queue is lightweight but guarantees eventual execution.

https://github.com/avalanche-foundation/ACPs/blob/main/ACPs/194-streaming-asynchronous-execution/README.md

[meaghanfitzgerald]

🔊 ACP-194 Developer Community Call

Meeting Date/Time: 05-16-2025, 14:30 UTC (10:30 AM EST)
Meeting Duration: 1 hour
Presenters: Arran Schlosberg, Stephen Buttolph

Purpose of the Meeting

In this meeting, we will discuss ACP-194, which proposes that the execution of transactions included in accepted blocks be decoupled from the process of block acceptance as part of Avalanche’s snowman++ consensus protocol. Implementing such a change would reduce the requirements for performing consensus, meaning block times should decrease and transaction throughput should increase.

Who is invited?

Any protocol developer, ACP author, researcher, or Avalanche community member is invited to attend this meeting. If you have signed up for an ACP in the past, there is no need to fill out the form again.

Links

Sign Up Form: Google Form
Recording posted to YouTube

Preparation Material

Mandatory

ACP-194 ReadMe

Suggested Reading

Asynchronous Execution - Monad
Asynchronous Execution - Solana

Agenda

This call will cover the rationale and planned implementation of ACP-194, including plenty of time for questions and community discussion.

FAQs

Q: What is asynchronous execution?
A: Asynchronous execution is a method where blocks are accepted by consensus before transactions are fully executed. Instead of following the traditional synchronous flow (verification → proposal → execution → block acceptance), the network first confirms that all transactions in a block can pay gas fees. Full execution (including state root updates) is postponed until after block acceptance, reducing redundancy and speeding up block production.

Q: How does asynchronous execution increase transaction throughput?
A: By accepting blocks before execution, nodes no longer need to wait for full transaction execution during consensus. Since consensus no longer requires single-threaded execution, block times decrease significantly. This reduces the total time spent on block-building and consensus, leading to higher transaction throughput.

Q: What is the lifecycle of a transaction in asynchronous execution vs synchronous execution?
A: In synchronous execution, a transaction is:
sequenced (by block proposer), meaning it is included in a block
then executed (by block proposer to produce the output state),
then proposed and propagated to other validators in the network as part of consensus protocol,
then replicated and executed (by all other validators), checking that the output of execution matches the output produced by the proposer node before they vote
and finally considered globally accepted by the network so long as it satisfies consensus and execution logic.
In asynchronous execution, a transaction is:
sequenced (by block proposer), meaning it is included in a block
then undergoes lightweight verification (by block proposer) to ensure it can pay for gas,
then propagated to other validators in the network as part of consensus protocol, where other validators replicate the lightweight verification to confirm block validity, and then vote
considered globally accepted (i.e. guaranteed to eventually be executed),
executed locally by each validator/node
settled and considered canonically executed once the receipt is part of a later-accepted block’s receipt root

Q: With Async Execution, in order to produce a new block, must all transactions be executed and settled by the majority of nodes in the network?
A: No, block production can begin once the latest proposed block was accepted, which does not require transactions to have been executed.

Q: In order to consider a transaction valid and executable, wouldn't all other transactions in the block also need to be processed to detect conflicts (e.g. double spend)?
A: Yes, however, AE only performs a lightweight check instead of full execution. This is due to the difference between transaction validity in consensus and transaction validity in execution. The rules for validity in consensus, governed by the consensus client, do not depend on the rules for validity in execution, which is governed by the virtual machine. The validity at time of consensus should be thought of as "inclusion" validity, or block acceptance. In AE, snowman++ will only check that the accounts broadcasting the transactions will be able to pay for gas in native AVAX, which will effectively prevent double spend attacks. Consensus however will not check that the transactions’ instructions are valid, meaning that failure at the time of execution may still result in reverted transactions.

[meaghanfitzgerald]

[🚨Note!] The updates to the ACP mentioned below are still in DRAFT and have not been merged. A comment will be added to this discussion thread when said updates have been added.

🔊 ACP-194 Follow-Up Community Call: Streaming Asynchronous Execution (SAE)

Meeting Date/Time: June 26, 2025, 14:30 UTC (10:30 AM EST)
Meeting Duration: 1 hour
Presenters: Arran Schlosberg, Stephen Buttolph

Purpose of the Meeting

This follow-up session will dive into key updates and clarifications for ACP-194, which proposes Streaming Asynchronous Execution (SAE)—decoupling consensus and execution to improve throughput, reduce latency, and enable future optimizations like encrypted mempools.

Focus Areas

• Demo: Proof that SAE introduces no latency impact under realistic conditions.
• ACP Updates:
  • Max block size adjustments for queue stability.
  • Queue size restrictions to prevent DoS.
  • Removal of "pending" and "finalized" block labels.
  • Clarification that "safe" refers to hard-drive corruption risk, not consensus finality.
• UX Feedback: Discussion on parameterization (e.g., λ for gas limits, τ for settlement delay).
• Open Q&A: Addressing lingering questions from the first meeting.

Who Should Attend?

• Protocol engineers
• Validators and node operators
• Developers impacted by execution model changes

No need to re-register if you've signed up for prior ACP community meetings.

Links

Sign Up Form: Google Form
Recording: To be added post-meeting.

Preparation Material

🚨Updates Pending ACP-194 Latest Draft

Agenda

1. Demo: Latency impact analysis (10 min).
2. Updates to ACP:
   • Block/queue sizing (15 min).
   • Label simplification ("safe" vs. "finalized") (10 min).
3. Community Discussion: Parameter tradeoffs (λ, τ) and UX (15 min).
4. Q&A (20 min).

Key Changes Since Last Meeting

• Simplified Block Labels: "Safe" now exclusively denotes local hard-drive persistence, not consensus finality (which is inherent in Snowman++).
• Queue Limits: Formalized ω = R · τ · λ to cap queue gas limits and prevent spam.
• Gas Charging: Adjusted g_C = max(g_U, g_L/λ) to disincentivize bloated gas limits.

FAQs

Q: Why remove "pending" and "finalized" labels?
A: Under Snowman++, all accepted blocks are finalized. "Safe" now signals local execution persistence (i.e., low risk of disk corruption).

Q: How does SAE handle bursty traffic?
A: The queue (ω) absorbs bursts, while λ ensures fair gas pricing even with inflated limits.

Q: What's the risk of a bloated queue?
A: The worst-case gas price inflation is capped at ~6% (see Security Considerations).