You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Optimistic Quorum Store is a technique to reduce Quorum Store + Consensus (QS+Consensus) Latency by two network hops (about 180ms in Aptos Mainnet as of October 30, 2024) in the common case. The technique involves proposing quorum store batches in consensus before collecting proof of stores and modifying the consensus voting mechanism to ensure batch availability. While Aptos currently circumvents Quorum Store and inlines transaction payloads into the proposal directly under low throughput cases (up to 100 transactions per block), Optimistic Quorum Store makes Aptos’ QS+Consensus Latency four network hops under all loads in the common case.
Out of scope
This work does not focus on Mempool to Consensus latency which includes the mempool queuing time, the amount of time the transaction spends in the mempool before pulled into quorum store batches.
High-level Overview
The Quorum Store in the validators form batches of transactions from validator mempool and disseminate them to other validators and collect proof of stores. Today, transactions can take one of two paths through consensus from mempool: one optimize for latency and the other optimize for throughput.
In the first path, consensus proposes batches inlining the transaction payload within the proposal. This inlining of the payload in the proposal obviates the need to collect proof of store thus reducing consensus latency by two network hops. The latency in this case is four network hops, which while optimal, is only effective until the block proposer is not network bandwidth constrained. In mainnet, this path is configured for blocks that contain less than 100 transactions (approx. 500 TPS as of today).
Under load, the validators prioritize proposing proof of stores to allow for maximum utilization of the block space. This yields a latency of 6 network hops.
Latency in terms of network hops for two proposal paths: Batch Inlining vs Quorum Store Proof
The goal with Optimistic Quorum Store is to introduce a path for transactions from mempool through consensus with a latency of four network hops while scaling throughput with Quorum Store. Under this technique, consensus proposals contain batches that do not yet have proof of stores available, called Optimistic Batches, similar to the inlined batches but without inlining the payloads. Quorum Store is responsible for disseminating the payload within the batches. This allows Optimistic Quorum Store to scale throughput avoiding the proposer bottleneck but also provide 4-hop latency.
Latency in terms of network hops with Optimistic Quorum Store
To ensure honest validators will always have the payloads for the batches, the consensus voting rule is extended to vote on a proposal only if all the payloads for optimistic batches are available. It is the responsibility of the proposer to generate a proposal that will be accepted by honest validators. To ensure a successful round, the proposer choose optimistic batches whose payloads are expected to be available at the validators at proposal receipt. To choose optimistic batches, the proposer collects metrics about past proposals and uses this information to select optimistic batches to pack into the proposal.
AIP Discussion
Summary
Optimistic Quorum Store is a technique to reduce Quorum Store + Consensus (QS+Consensus) Latency by two network hops (about 180ms in Aptos Mainnet as of October 30, 2024) in the common case. The technique involves proposing quorum store batches in consensus before collecting proof of stores and modifying the consensus voting mechanism to ensure batch availability. While Aptos currently circumvents Quorum Store and inlines transaction payloads into the proposal directly under low throughput cases (up to 100 transactions per block), Optimistic Quorum Store makes Aptos’ QS+Consensus Latency four network hops under all loads in the common case.
Out of scope
This work does not focus on Mempool to Consensus latency which includes the mempool queuing time, the amount of time the transaction spends in the mempool before pulled into quorum store batches.
High-level Overview
The Quorum Store in the validators form batches of transactions from validator mempool and disseminate them to other validators and collect proof of stores. Today, transactions can take one of two paths through consensus from mempool: one optimize for latency and the other optimize for throughput.
In the first path, consensus proposes batches inlining the transaction payload within the proposal. This inlining of the payload in the proposal obviates the need to collect proof of store thus reducing consensus latency by two network hops. The latency in this case is four network hops, which while optimal, is only effective until the block proposer is not network bandwidth constrained. In mainnet, this path is configured for blocks that contain less than 100 transactions (approx. 500 TPS as of today).
Under load, the validators prioritize proposing proof of stores to allow for maximum utilization of the block space. This yields a latency of 6 network hops.
Latency in terms of network hops for two proposal paths: Batch Inlining vs Quorum Store Proof
The goal with Optimistic Quorum Store is to introduce a path for transactions from mempool through consensus with a latency of four network hops while scaling throughput with Quorum Store. Under this technique, consensus proposals contain batches that do not yet have proof of stores available, called Optimistic Batches, similar to the inlined batches but without inlining the payloads. Quorum Store is responsible for disseminating the payload within the batches. This allows Optimistic Quorum Store to scale throughput avoiding the proposer bottleneck but also provide 4-hop latency.
Latency in terms of network hops with Optimistic Quorum Store
To ensure honest validators will always have the payloads for the batches, the consensus voting rule is extended to vote on a proposal only if all the payloads for optimistic batches are available. It is the responsibility of the proposer to generate a proposal that will be accepted by honest validators. To ensure a successful round, the proposer choose optimistic batches whose payloads are expected to be available at the validators at proposal receipt. To choose optimistic batches, the proposer collects metrics about past proposals and uses this information to select optimistic batches to pack into the proposal.
Read more about it here: https://github.com/aptos-foundation/AIPs/blob/main/aips/aip-106.md
The text was updated successfully, but these errors were encountered: