Reduce confirmation latency for payments on Solana

Research
,
1

This post aims to inspire the Solana ecosystem by examining potential lessons from other blockchain ecosystems, specifically Sui. Drawing insights from competitors is crucial for Solana to maintain its status as the most performant blockchain in the years to come. I work professionally in AI, not crypto. As such, this post should be viewed as a starting point for discussion, not a detailed design proposal. My goal is to encourage Solana’s community to evaluate whether this type of design could enhance its performance and ensure any decision is well-informed.

Today the most successful use-case for crypto (beyond memes) is payments. Solana’s north star (Increase bandwith reduce latency) is also well aligned with payments, as customers expect a near instant experience. This is what they are used to today with Apple Pay etc. With 400 ms blocktimes and a 1-2 slots confirmation time solana already has a performance that is well aligned with this. But we should always strive to be better, right?

Sui has implemented the Mysticeti consensus mechanism, which employs a hybrid approach to transaction processing. One of its key features is the “fast path”, a mechanism that allows certain transactions to be executed without requiring full consensus.

Examples of transactions that benefit from this fast path include:

  • Asset transfers
  • Stablecoin transfers
  • Payments
  • NFT minting

My understanding is that this results in that all transactions are confirmed/finalized in the block they land in (so SFF) without having to wait 1-2 slots (often longer) for an optimistic confirmation. The alternative (“slow path” ) would be to route the transaction through full consensus. Sui applies the “slow path” for complex transactions (1-2 slot latency) and “fast path” for simple transactions.

The fast path enables Sui to achieve finality within 400 ms for these transactions. This is reflected in their Grafana dashboard, where their p90 latency (finality time for 90% of transactions) typically falls between 300–500 ms.

In comparison, Solana’s p90 confirmation time often hovers around 1 second or more.

It’s important to note that Sui operates at a smaller scale, with lower throughput (~80 TPS at the time of writing) and a smaller validator set (~100 validators). While this makes it an imperfect apples-to-apples comparison, I believe there are valuable lessons to be learned from their approach. It is significant because it means that Sui can settle stablecoin transfers 2-3x faster than Solana

Sui latency dashboard: Grafana
SUI Mystecity: The Sui Mysticeti Upgrade Demystified

The design Sui has for fast path is roughly:

  • Transaction Submission: A user initiates a transaction, such as transferring an NFT they own, by creating and signing it with their private key. This transaction is then sent to a Sui Full node.
  • Certification: The Full node forwards the transaction to validators, who perform validity checks, including verifying user signatures and ensuring the user owns the involved objects. Validators lock the owned input objects to prevent double-spending, sign the transaction upon successful validation, and return the signatures to the Full node. The Full node collects signatures from a supermajority (at least two-thirds) of validators to form a transaction certificate.
    *Execution via Fast Path: For transactions involving only owned objects (e.g. a stablecoin transfer), the fast path allows immediate execution without waiting for consensus. Validators verify the certificate’s validity and execute the transaction promptly. This process significantly reduces latency, achieving transaction finality in as little as 400 milliseconds.
  • Post-Execution: After execution, validators sign the transaction effects, detailing the actions taken (e.g., objects mutated or created). The Full node assembles these into an effects certificate, providing proof of transaction settlement. Subsequently, all certificates are forwarded to Sui’s Directed Acyclic Graph (DAG)-based consensus protocol for inclusion in the blockchain’s permanent record.

Below is a ChatGPT generated design proposal for how this could be implemented on Solana. View this as inspiration only:

Context:
Solana’s consensus currently combines Proof of History (PoH) as a global clock and Tower BFT as a finality gadget. This architecture focuses on high throughput and fast confirmation, but it still treats all transactions as going through a similar process: being ingested by the leader, sequenced, and then confirmed by validators via the Tower BFT mechanism. Introducing a “fast path” for simple, low-contention transactions (e.g., payments) means adding a mechanism that can bypass some of the full consensus steps while maintaining security, correctness, and state consistency.

Key Considerations:

  1. Differentiation of Transaction Types:
  • We first need a clear classification of “simple” transactions. For instance, these could be single-account-to-single-account SPL token transfers
  • These simple transactions must have properties such as deterministic outcomes, no complex state dependencies (just account balances), and no cross-contract calls that might require a more thorough consensus step.
  1. Partial Ordering and Fast-Path Quorums:
  • A straightforward approach is to allow validators to “pre-confirm” simple transactions out of band, without waiting for full finalization.
  • To accomplish this, you could introduce a secondary lightweight protocol that runs in parallel with Solana’s main consensus. This secondary protocol would:
    • Allow a client (e.g., a user’s wallet) to send a simple transaction to a wide set of validators.
    • Each validator, upon verifying the transaction’s correctness (e.g., sufficient balance, valid signature), signs a “fast confirmation” attestation.
    • Once a transaction obtains signatures from a threshold of validators (e.g., > 2/3 of stake weight), the client can treat the transaction as “fast-path confirmed.”Such a design is somewhat analogous to “quorum certificates” or single-round threshold confirmations seen in some Byzantine agreement protocols, but applied only to a restricted class of transactions.
  1. Incorporating Fast-Path Transactions into the Ledger:
  • Even if a transaction obtains a fast-path quorum, it must eventually be recorded in the canonical ledger to maintain a consistent chain state.
  • The leader could package these fast-path transactions with their quorum certificates into the next block. Other validators who see a valid quorum certificate plus the transaction can immediately include it without waiting for multiple block confirmations.
  • This ensures that the “fast-lane” doesn’t produce forks that aren’t eventually resolved in the main chain. The final block inclusion by the leader and subsequent BFT rounds would “cement” the transaction’s finality.
  1. Relation to Proof of History (PoH):
  • PoH can still serve as the ordering mechanism. The difference is that before a transaction even appears in a PoH sequence, it’s already widely agreed upon by a threshold of validators that it’s valid and should be included.
  • When the leader sequences these transactions, the network sees them as “pre-agreed upon.” This can significantly reduce the latency to perceived confirmation for end-users.
  1. Inspiration from Sui’s Mysticeti (Fast-Pay) Approach:
  • Sui’s Mysten Labs introduced a concept akin to “fast pay” for simple transactions, utilizing a set of validators to quickly confirm and finalize low-contention payments.
  • In Sui, simple transfers can bypass the full Narwhal-Bullshark consensus by directly getting signed off by a quorum of validators. The final block producer then includes these direct-confirmation results in the DAG-based consensus.
  • For Solana, a similar approach would mean introducing a “fast quorum” attestation mechanism. This could be an additional module layered on top of existing validator software, communicating alongside PoH and Tower BFT.
  • The main differences would be adapting it to Solana’s slot-based leader rotation and ensuring compatibility with PoH’s linear ordering.
  1. Handling Reversion and Conflicts:
  • If multiple fast-path transactions try to spend the same funds simultaneously, validators would only sign the first valid one they see and reject conflicts. Because these are simple transactions, double-spend attempts are easily detected.
  • Conflicts could be handled by validators at the fast-path layer by only providing signatures for the first observed, valid, non-conflicting transaction affecting a particular account’s balance.
  • If a leader later attempts to include conflicting transactions, the lack of a quorum certificate for the conflicting one ensures it doesn’t gain fast-path acceptance.
  1. Security and Incentives:
  • Validators must have the right incentives to participate in this fast-path. They could receive small, immediate fees for signing fast-path transactions to ensure timely and honest participation.
  • The fast-path mechanism should not undermine the overall security of the chain. The threshold for a fast quorum should be as robust as the threshold used in the standard consensus. This means an attacker would need to compromise the same majority of stake to forge fast-path confirmations.
  1. Final Integration Steps:
  • Implement a separate RPC or P2P channel for clients and validators to negotiate fast-path confirmations.
  • Validators maintain a lightweight, in-memory state of account balances related to these simple tokens for quick checks.
  • Once a validator provides a signature, that attestation is broadcast and aggregated until a quorum is reached.
  • Clients present the quorum certificate as proof of “fast confirmation,” and the leader includes the transaction plus its quorum certificate into the ledger, at which point Tower BFT finalizes it as part of the normal block finalization process.

Summary:
To introduce a “fast path” in Solana’s consensus similar to Sui’s Mysticeti, you would add a parallel, lightweight agreement layer specifically for simple, low-dependency transactions. This layer allows validators to produce threshold signatures attesting to a transaction’s validity before it is included in the chain. The main consensus (PoH + Tower BFT) would then incorporate these pre-agreed transactions, finalizing them with minimal additional latency. This hybrid approach achieves rapid perceived confirmation for simple payments while preserving Solana’s security and eventual finality properties.