arXiv subjects

Alberto Sonnino

Publications and source records attributed to Alberto Sonnino.

At least 37 records · Page 2Linked to original sources

arXiv2025

Pilotfish: Distributed Execution for Scalable Blockchains

Scalability is a crucial requirement for modern large-scale systems, enabling elasticity and ensuring responsiveness under varying load. While cloud systems have achieved scalable architectures, blockchain systems remain constrained by the need to over-provision validator machines to handle peak load. This leads to resource inefficiency, poor cost scaling, and limits on performance. To address these challenges, we introduce Pilotfish, the first scale-out transaction execution engine for blockchains. Pilotfish enables validators to scale horizontally by distributing transaction execution across multiple worker machines, allowing elasticity without compromising consistency or determinism. It integrates seamlessly with the lazy blockchain architecture, completing the missing piece of execution elasticity. To achieve this, Pilotfish tackles several key challenges: ensuring scalable and strongly consistent distributed transactions, handling partial crash recovery with lightweight replication, and maintaining concurrency with a novel versioned-queue scheduling algorithm. Our evaluation shows that Pilotfish scales linearly up to at least eight workers per validator for compute-bound workloads, while maintaining low latency. By solving scalable execution, Pilotfish brings blockchains closer to achieving end-to-end elasticity, unlocking new possibilities for efficient and adaptable blockchain systems.

cs.DC↗

arXiv2025

Stingray: Fast Concurrent Transactions Without Consensus

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.

cs.CR↗

arXiv2024

Obelia: Scaling DAG-Based Blockchains to Hundreds of Validators

Obelia improves upon structured DAG-based consensus protocols used in proof-of-stake systems, allowing them to effectively scale to accommodate hundreds of validators. Obelia implements a two-tier validator system. A core group of high-stake validators that propose blocks as in current protocols and a larger group of lower-stake auxiliary validators that occasionally author blocks. Obelia incentivizes auxiliary validators to assist recovering core validators and integrates seamlessly with existing protocols. We show that Obelia does not introduce visible overhead compared to the original protocol, even when scaling to hundreds of validators, or when a large number of auxiliary validators are unreliable.

cs.CR↗

arXiv2024

Sui Lutris: A Blockchain Combining Broadcast and Consensus

Sui Lutris is the first smart-contract platform to sustainably achieve sub-second finality. It achieves this significant decrease by employing consensusless agreement not only for simple payments but for a large variety of transactions. Unlike prior work, Sui Lutris neither compromises expressiveness nor throughput and can run perpetually without restarts. Sui Lutris achieves this by safely integrating consensuless agreement with a high-throughput consensus protocol that is invoked out of the critical finality path but ensures that when a transaction is at risk of inconsistent concurrent accesses, its settlement is delayed until the total ordering is resolved. Building such a hybrid architecture is especially delicate during reconfiguration events, where the system needs to preserve the safety of the consensusless path without compromising the long-term liveness of potentially misconfigured clients. We thus develop a novel reconfiguration protocol, the first to provably show the safe and efficient reconfiguration of a consensusless blockchain. Sui Lutris is currently running in production and underpins the Sui smart-contract platform. Combined with the use of Objects instead of accounts it enables the safe execution of smart contracts that expose objects as a first-class resource. In our experiments Sui Lutris achieves latency lower than 0.5 seconds for throughput up to 5,000 certificates per second (150k ops/s with transaction blocks), compared to the state-of-the-art real-world consensus latencies of 3 seconds. Furthermore, it gracefully handles validators crash-recovery and does not suffer visible performance degradation during reconfiguration.

cs.DC↗

arXiv2024

Mahi-Mahi: Low-Latency Asynchronous BFT DAG-Based Consensus

We present Mahi-Mahi, the first asynchronous BFT consensus protocol that achieves sub-second latency in the WAN while processing over 100,000 transactions per second. We accomplish this remarkable performance by building Mahi-Mahi on an uncertified structured Directed Acyclic Graph (DAG). By forgoing explicit certification, we significantly reduce the number of messages required to commit and minimize CPU overhead associated with certificate verification. Mahi-Mahi introduces a novel commit rule that allows committing multiple blocks in each DAG round, while ensuring liveness in the presence of an asynchronous adversary. Mahi-Mahi can be parametrized to either attempt to commit within 5 message delays, maximizing the probability of commitment under a continuously active asynchronous adversary, or within 4 message delays, which reduces latency under a more moderate and realistic asynchronous adversary. We demonstrate the safety and liveness of Mahi-Mahi in a Byzantine context. Subsequently, we evaluate Mahi-Mahi in a geo-replicated setting and compare its performance against state-of-the-art asynchronous consensus protocols, showcasing Mahi-Mahi's significantly lower latency.

cs.DC↗

arXiv2024

Jolteon and Ditto: Network-Adaptive Efficient Consensus with Asynchronous Fallback

Existing committee-based Byzantine state machine replication (SMR) protocols, typically deployed in production blockchains, face a clear trade-off: (1) they either achieve linear communication cost in the happy path, but sacrifice liveness during periods of asynchrony, or (2) they are robust (progress with probability one) but pay quadratic communication cost. We believe this trade-off is unwarranted since existing linear protocols still have asymptotic quadratic cost in the worst case. We design Ditto, a Byzantine SMR protocol that enjoys the best of both worlds: optimal communication on and off the happy path (linear and quadratic, respectively) and progress guarantee under asynchrony and DDoS attacks. We achieve this by replacing the view-synchronization of partially synchronous protocols with an asynchronous fallback mechanism at no extra asymptotic cost. Specifically, we start from HotStuff, a state-of-the-art linear protocol, and gradually build Ditto. As a separate contribution and an intermediate step, we design a 2-chain version of HotStuff, Jolteon, which leverages a quadratic view-change mechanism to reduce the latency of the standard 3-chain HotStuff. We implement and experimentally evaluate all our systems. Notably, Jolteon's commit latency outperforms HotStuff by 200-300ms with varying system size. Additionally, Ditto adapts to the network and provides better performance than Jolteon under faulty conditions and better performance than VABA (a state-of-the-art asynchronous protocol) under faultless conditions. This proves our case that breaking the robustness-efficiency trade-off is in the realm of practicality.

cs.DC↗

arXiv2023

HammerHead: Leader Reputation for Dynamic Scheduling

The need for high throughput and censorship resistance in blockchain technology has led to research on DAG-based consensus. The Sui blockchain protocol uses a variant of the Bullshark consensus algorithm due to its lower latency, but this leader-based protocol causes performance issues when candidate leaders crash. In this paper, we explore the ideas pioneered by Carousel on providing Leader-Utilization and present HammerHead. Unlike Carousel, which is built with a chained and pipelined consensus protocol in mind, HammerHead does not need to worry about chain quality as it is directly provided by the DAG, but needs to make sure that even though validators might commit blocks in different views the safety and liveness is preserved. Our implementation of HammerHead shows a slight performance increase in a faultless setting, and a drastic 2x latency reduction and up to 40% throughput increase when suffering faults (100 validators, 33 faults).

cs.CR↗

arXiv2023

Cuttlefish: Expressive Fast Path Blockchains with FastUnlock

Cuttlefish addresses several limitations of existing consensus-less and consensus-minimized decentralized ledgers, including restricted programmability and the risk of deadlocked assets. The key insight of Cuttlefish is that consensus in blockchains is necessary due to contention, rather than multiple owners of an asset as suggested by prior work. Previous proposals proactively use consensus to prevent contention from blocking assets, taking a pessimistic approach. In contrast, Cuttlefish introduces collective objects and multi-owner transactions that can offer most of the functionality of classic blockchains when objects transacted on are not under contention. Additionally, in case of contention, Cuttlefish proposes a novel `Unlock' protocol that significantly reduces the latency of unblocking contented objects. By leveraging these features, Cuttlefish implements consensus-less protocols for a broader range of transactions, including asset swaps and multi-signature transactions, which were previously believed to require consensus.

cs.CR↗

arXiv2023

Performance of EdDSA and BLS Signatures in Committee-Based Consensus

We present the first performance comparison of EdDSA and BLS signatures in committee-based consensus protocols through large-scale geo-distributed benchmarks. Contrary to popular beliefs, we find that small deployments (less than 40 validators) can benefit from the small storage footprint of BLS multi-signatures while larger deployments should favor EdDSA to improve performance. As an independent contribution, we present a novel way for committee-based consensus protocols to verify BLS multi-signed certificates by manipulating the aggregated public key using pre-computed values.

cs.DC↗

arXiv2022

Efficient Multiparty Protocols Using Generalized Parseval's Identity and the Theta Algebra

We propose a protocol able to show publicly addition and multiplication on secretly shared values. To this aim we developed a protocol based on the use of masks and on the FMPC (Fourier Multi-Party Computation). FMPC is a novel multiparty computation protocol of arithmetic circuits based on secret-sharing, capable to compute addition and multiplication of secrets with no communication. We achieve this task by introducing the first generalisation of Parseval's identity for Fourier series applicable to an arbitrary number of inputs and a new algebra referred to as the "Theta-algebra". FMPC operates in a setting where users wish to compute a function over some secret inputs by submitting the computation to a set of nodes, without revealing them those inputs. FMPC offloads most of the computational complexity to the end users, and includes an online phase that mainly consists of each node locally evaluating specific functions. FMPC paves the way for a new kind of multiparty computation protocols; making it possible to compute addition and multiplication of secrets stepping away from circuit garbling and the traditional algebra introduced by Donald Beaver in 1991. Our protocol is capable to compute addition and multiplication with no communication and its simplicity provides efficiency and ease of implementation.

cs.CR↗

arXiv2022

Bullshark: The Partially Synchronous Version

The purpose of this manuscript is to describe the deterministic partially synchronous version of Bullshark in a simple and clean way. This result is published in CCS 2022, however, the description there is less clear because it uses the terminology of the full asynchronous Bullshark. The CCS version ties the description of the asynchronous and partially synchronous versions of Bullshark since it targets an academic audience. Due to the recent interest in DAG-based BFT protocols, we provide a separate and simple description of the partially synchronous version that targets a more general audience. We focus here on the DAG ordering logic. For more details about the asynchronous version, garbage collection, fairness, proofs, related work, evaluation, and efficient DAG implementation please refer to the fullpaper. An intuitive extended summary can be found in the "DAG meets BFT" blogpost.

cs.DC↗

arXiv2022

Bullshark: DAG BFT Protocols Made Practical

We present Bullshark, the first directed acyclic graph (DAG) based asynchronous Byzantine Atomic Broadcast protocol that is optimized for the common synchronous case. Like previous DAG-based BFT protocols, Bullshark requires no extra communication to achieve consensus on top of building the DAG. That is, parties can totally order the vertices of the DAG by interpreting their local view of the DAG edges. Unlike other asynchronous DAG-based protocols, Bullshark provides a practical low latency fast-path that exploits synchronous periods and deprecates the need for notoriously complex view-change mechanisms. Bullshark achieves this while maintaining all the desired properties of its predecessor DAG-Rider. Namely, it has optimal amortized communication complexity, it provides fairness and asynchronous liveness, and safety is guaranteed even under a quantum adversary. In order to show the practicality and simplicity of our approach, we also introduce a standalone partially synchronous version of Bullshark which we evaluate against the state of the art. The implemented protocol is embarrassingly simple (200 LOC on top of an existing DAG-based mempool implementation (Narwhal & Tusk). It is highly efficient, achieving for example, 125,000 transaction per second with a 2 seconds latency for a deployment of 50 parties. In the same setting the state of the art pays a steep 50% latency increase as it optimizes for asynchrony.

cs.CR↗

arXiv2022

Narwhal and Tusk: A DAG-based Mempool and Efficient BFT Consensus

We propose separating the task of reliable transaction dissemination from transaction ordering, to enable high-performance Byzantine fault-tolerant quorum-based consensus. We design and evaluate a mempool protocol, Narwhal, specializing in high-throughput reliable dissemination and storage of causal histories of transactions. Narwhal tolerates an asynchronous network and maintains high performance despite failures. Narwhal is designed to easily scale-out using multiple workers at each validator, and we demonstrate that there is no foreseeable limit to the throughput we can achieve. Composing Narwhal with a partially synchronous consensus protocol (Narwhal-HotStuff) yields significantly better throughput even in the presence of faults or intermittent loss of liveness due to asynchrony. However, loss of liveness can result in higher latency. To achieve overall good performance when faults occur we design Tusk, a zero-message overhead asynchronous consensus protocol, to work with Narwhal. We demonstrate its high performance under a variety of configurations and faults. As a summary of results, on a WAN, Narwhal-Hotstuff achieves over 130,000 tx/sec at less than 2-sec latency compared with 1,800 tx/sec at 1-sec latency for Hotstuff. Additional workers increase throughput linearly to 600,000 tx/sec without any latency increase. Tusk achieves 160,000 tx/sec with about 3 seconds latency. Under faults, both protocols maintain high throughput, but Narwhal-HotStuff suffers from increased latency.

cs.CR↗

arXiv2022

Zef: Low-latency, Scalable, Private Payments

We introduce Zef, the first Byzantine-Fault Tolerant (BFT) protocol to support payments in anonymous digital coins at arbitrary scale. Zef follows the communication and security model of FastPay: both protocols are asynchronous, low-latency, linearly-scalable, and powered by partially-trusted sharded authorities. Zef further introduces opaque coins represented as off-chain certificates that are bound to user accounts. In order to hide the face values of coins when a payment operation consumes or creates them, Zef uses random commitments and NIZK proofs. Created coins are made unlinkable using the blind and randomizable threshold anonymous credentials of Coconut. To control storage costs associated with coin replay prevention, Zef accounts are designed so that data can be safely removed once an account is deactivated. Besides the specifications and a detailed analysis of the protocol, we are making available an open-source implementation of Zef in Rust. Our extensive benchmarks on AWS confirm textbook linear scalability and demonstrate a confirmation time under one second at nominal capacity. Compared to existing anonymous payment systems based on a blockchain, this represents a latency speedup of three orders of magnitude, with no theoretical limit on throughput.

cs.CR↗

arXiv2022

Twins: BFT Systems Made Robust

This paper presents Twins, an automated unit test generator of Byzantine attacks. Twins implements three types of Byzantine behaviors: (i) leader equivocation, (ii) double voting, and (iii) losing internal state such as forgetting 'locks' guarding voted values. To emulate interesting attacks by a Byzantine node, it instantiates twin copies of the node instead of one, giving both twins the same identities and network credentials. To the rest of the system, the twins appear indistinguishable from a single node behaving in a 'questionable' manner. Twins can systematically generate Byzantine attack scenarios at scale, execute them in a controlled manner, and examine their behavior. Twins scenarios iterate over protocol rounds and vary the communication patterns among nodes. Twins runs in a production setting within DiemBFT where it can execute 44M Twins-generated scenarios daily. Whereas the system at hand did not manifest errors, subtle safety bugs that were deliberately injected for the purpose of validating the implementation of Twins itself were exposed within minutes. Twins can prevent developers from regressing correctness when updating the codebase, introducing new features, or performing routine maintenance tasks. Twins only requires a thin wrapper over DiemBFT, we thus envision other systems using it. Building on this idea, one new attack and several known attacks against other BFT protocols were materialized as Twins scenarios. In all cases, the target protocols break within fewer than a dozen protocol rounds, hence it is realistic for the Twins approach to expose the problems.

cs.CR↗

arXiv2022

Low-latency, Scalable, DeFi with Zef

Zef was recently proposed to extend the low-latency, Byzantine-Fault Tolerant (BFT) payment protocol FastPay with anonymous coins. This report explores further extensions of FastPay and Lef beyond payments. We start by off-chain assets (e.g. NFTs). We introduce the idea of on-demand BFT consensus instances throught the example of atomic swaps between account owners.

cs.CR↗

arXiv2021

Be Aware of Your Leaders

Advances in blockchains have influenced the State-Machine-Replication (SMR) world and many state-of-the-art blockchain-SMR solutions are based on two pillars: Chaining and Leader-rotation. A predetermined round-robin mechanism used for Leader-rotation, however, has an undesirable behavior: crashed parties become designated leaders infinitely often, slowing down overall system performance. In this paper, we provide a new Leader-Aware SMR framework that, among other desirable properties, formalizes a Leader-utilization requirement that bounds the number of rounds whose leaders are faulty in crash-only executions. We introduce Carousel, a novel, reputation-based Leader-rotation solution to achieve Leader-Aware SMR. The challenge in adaptive Leader-rotation is that it cannot rely on consensus to determine a leader, since consensus itself needs a leader. Carousel uses the available on-chain information to determine a leader locally and achieves Liveness despite this difficulty. A HotStuff implementation fitted with Carousel demonstrates drastic performance improvements: it increases throughput over 2x in faultless settings and provided a 20x throughput increase and 5x latency reduction in the presence of faults.

cs.DC↗

arXiv2021

Shard Scheduler: object placement and migration in sharded account-based blockchains

We propose Shard Scheduler, a system for object placement and migration in account-based sharded blockchains. Our system calculates optimal placement and decides of object migrations across shards and supports complex multi-account transactions caused by smart contracts. Placement and migration decisions made by Shard Scheduler are fully deterministic, verifiable, and can be made part of the consensus protocol. Shard Scheduler reduces the number of costly cross-shard transactions, ensures balanced load distribution and maximizes the number of processed transactions for the blockchain as a whole. It leverages a novel incentive model motivating miners to maximize the global throughput of the entire blockchain rather than the throughput of a specific shard. Shard Scheduler reduces the number of costly cross-shard transactions by half in our simulations, ensuring equal load and increasing the throughput 3 fold when using 60 shards. We also implement and evaluate Shard Scheduler on Chainspace, more than doubling its throughput and reducing user-perceived latency by 70% when using 10 shards.

cs.CR↗