Stingray: Fast Concurrent Transactions Without Consensus

TL;DR

Stingray addresses blockchain scalability by enabling fast-path concurrency for nearly commutative transactions through a Byzantine fault-tolerant bounded counter and a FastUnlock contention-resolution protocol. It extends the Sui/Mysticeti fast path to support multi-owner transactions and collective objects while maintaining safety and liveness under Byzantine faults. Formal proofs accompany a geo-distributed evaluation showing up to ~10,000x throughput improvements for commutative workloads, with no material penalties on parallel workloads or during faults. The approach significantly reduces latency for complex, multi-party operations without requiring global consensus for many fast-path transactions, enhancing programmability and throughput in practice.

Abstract

Recent advances have improved the throughput and latency of blockchains by processing transactions accessing different parts of the state concurrently. However, these systems are unable to concurrently process (a) transactions accessing the same state, even if they are (almost) commutative, e.g., payments much smaller than an account's balance, and (b) multi-party transactions, e.g., asset swaps. Moreover, they are slow to recover from contention, requiring once-in-a-day synchronization. We present Stingray, a novel blockchain architecture that addresses these limitations. The key conceptual contributions are a replicated bounded counter that processes (almost) commutative transactions concurrently, and a FastUnlock protocol that uses a fallback consensus protocol for fast contention recovery. We prove Stingray's security in an asynchronous network with Byzantine faults and demonstrate on a global testbed that Stingray achieves 10,000 times the throughput of prior systems for commutative workloads.

Figures (7)

• Figure 1: General protocol flow of Sui Lutris suiL fast-path (➊-➐) & consensus failover system (➑,➏',➐').
• Figure 2: Version updates in the bounded counter. Circles represent unit decrement transactions and dashed boxes versions. The initial balance is $\textsf{Bal}_0\xspace = 9$, and $f = 1$. For version $v_0$, each validator has a budget of $\frac{f+1}{2f+1}\textsf{Bal}_0\xspace = 6$. After $6$ transactions are certified, the user sends a version update (dashed box $v_1$) containing pointers to the $6$ certified transactions. The remaining balance is $9 - 6 = 3$ and the validators update their budget to $\frac{f+1}{2f+1}*3 = 2$. Finally, when the remaining balance is $1$, the user converts the bounded counter to a standard owned object and spends the remaining balance.
• Figure 3: Version updates and merges in the collective bounded counter. Version $v_3$ results from a merge request on two conflicting version updates $v_1$ and $v_2$. Version $v_4$ results from a merge request on version $v_3$ for which the user sent transactions exceeding the budget.
• Figure 4: FastUnlock interactions between a user and validators to unlock an object.
• Figure 5: Comparing throughput and latency of Sui and Stingray with a commutative load. WAN measurements with $10$ and $50$ validators.

Theorems & Definitions (29)

• definition 1: Transaction Validity
• definition 2: Certificate Validity
• definition 3: Safety Properties
• definition 4: Liveness Properties
• definition 5: Bounded counter
• theorem 1
• theorem 2
• definition 6
• lemma 1
• definition 7