FastPay: High-Performance Byzantine Fault Tolerant Settlement Mathieu Baudet∗ George Danezis Alberto Sonnino [email protected] [email protected] [email protected] Facebook Novi Facebook Novi Facebook Novi ABSTRACT FastPay is a Byzantine Fault Tolerant (BFT) real-time gross set- FastPay allows a set of distributed authorities, some of which are tlement (RTGS) system. It enables authorities to jointly maintain Byzantine, to maintain a high-integrity and availability settlement account balances and settle pre-funded retail payments between system for pre-funded payments. It can be used to settle payments accounts. It supports extremely low-latency confirmation (sub- in a native unit of value (crypto-currency), or as a financial side- second) of eventual transaction finality, appropriate for physical infrastructure to support retail payments in fiat currencies. FastPay point-of-sale payments. It also provides extremely high capacity, is based on Byzantine Consistent Broadcast as its core primitive, comparable with peak retail card network volumes, while ensuring foregoing the expenses of full atomic commit channels (consen- gross settlement in real-time. FastPay eliminates counterparty and sus). The resulting system has low-latency for both confirmation credit risks of net settlement and removes the need for intermediate and payment finality. Remarkably, each authority can be sharded banks, and complex financial contracts between them, to absorb across many machines to allow unbounded horizontal scalability. these risks. FastPay can accommodate arbitrary capacities through Our experiments demonstrate intra-continental confirmation la- efficient sharding architectures at each authority. Unlike any tradi- tency of less than 100ms, making FastPay applicable to point of tional RTGS, and more like permissioned blockchains, FastPay can sale payments. In laboratory environments, we achieve over 80,000 tolerate up to f Byzantine failures out of a total of 3f +1 authorities, transactions per second with 20 authorities—surpassing the require- and retain both safety, liveness, and high-performance. ments of current retail card payment networks, while significantly FastPay can be deployed in a number of settings. First, it may be increasing their robustness. used as a settlement layer for a native token and crypto-currency, in a standalone fashion. Second, it may be deployed as a side-chain of KEYWORDS another crypto-currency, or as a high performance settlement layer on the side of an established RTGS to settle fiat retail payments. In distributed system, bft, settlement system, consistent broadcast this paper we present this second functionality in detail, since it ACM Reference Format: exercises all features of the system, both payments between FastPay Mathieu Baudet, George Danezis, and Alberto Sonnino. 2020. FastPay: High- accounts, as well as payments into and out of the system. Performance Byzantine Fault Tolerant Settlement. In Proceedings of ACM Conference (Conference’17). ACM, New York, NY, USA, 15 pages. https: Contributions. We make the following contributions: //doi.org/10.1145/nnnnnnn.nnnnnnn • The FastPay design is novel in that if forgoes full consensus; it leverages the semantics of payments to minimize shared 1 INTRODUCTION state between accounts and to increase the concurrency of Real-time gross settlement systems (RTGS) [4] constitute the most asynchronous operations; and supports sharded authorities. common approach to financial payments in closed banking net- • We provide proofs of safety and liveness in a Byzantine and works, that is, between reputable institutions. In contrast, blockchain fully asynchronous network setting. We show that FastPay platforms have proposed a radically different paradigm, allowing keeps all its properties despite the lack of total ordering, or account holders to interact directly with an online, yet highly se- asynchrony of updates to recipient accounts. cure, distributed ledger. Blockchain approaches aim to enable new • We experimentally demonstrate comparatively very high use cases such as personal e-wallets or private transactions, and throughput and low latency, as well as the robustness of the generally provide ecosystems more favorable to users. However, system under conditions of extremely high concurrency and until now, such open, distributed settlement solutions have come load. We show that performance is maintained even when at a high performance cost and questionable scalability compared some (Byzantine) authorities fail. to traditional, closed RTGS systems. Outline. This paper is organized as follows: Section 2 introduces ∗ Alphabetical order. real-time gross settlement systems, and permissioned blockchains. Section 3 introduces the entities within FastPay, their interactions, Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed and the security properties and threat model. Section 4 details the for profit or commercial advantage and that copies bear this notice and the full citation design of FastPay both as a standalone system, and operated in on the first page. Copyrights for components of this work owned by others than ACM conjunction with a Primary. Section 5 discusses safety and live- must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a ness. Section 6 briefly describes the implementation of the FastPay fee. Request permissions from [email protected]. prototype. Section 7 provides a full performance evaluation of Fast- Conference’17, July 2017, Washington, DC, USA Pay as we modulate its security parameters and load. Section 8 © 2020 Association for Computing Machinery. ACM ISBN 978-x-xxxx-xxxx-x/YY/MM...$15.00 discusses key open issues such as privacy, governance mechanisms https://doi.org/10.1145/nnnnnnn.nnnnnnn and economics of the platform. Section 9 covers the related work, Conference’17, July 2017, Washington, DC, USA Mathieu Baudet, George Danezis, and Alberto Sonnino both in terms of traditional financial systems and crypto-currencies. but is still below the peak volumes for retail payment systems. A Section 10 concludes. latency of multiple seconds when it comes to transaction finality is competitive with RTGS, but is unusable for retail payment at 2 BACKGROUND physical points of sale. Real-time gross settlement systems (RTGS) [4] are the backbone of modern financial systems. Commercial banks use them to maintain 3 OVERVIEW an account with central banks and settle large value payments. To illustrate its full capabilities, we describe FastPay as a side chain RTGS systems are limited in their capacity1, making them unsuit- of a primary RTGS holding the primary records of accounts. We able for settling low-value high-volume retail payments directly. call such a primary ledger the Primary for short, and its accounts Such retail payments are deferred: banks exchange information the Primary accounts. The Primary can be instantiated in two ways: bilaterally about pending payments (often through SWIFT [33, 47]), (i) as a programmable blockchain, through smart contracts, like they aggregate and net payments, and only settle net balances Ethereum [50] or Libra [14]. The Primary can also be instantiated through an RTGS, often daily. The often quoted volume figure of (ii) as a traditional monolithic RTGS operated by a central bank. In around 80,000 transactions per second for retail card networks [26, this case the components interfacing with FastPay are implemented 48] represents the rate at which ‘promises’ for payments are ex- as database transactions within the Primary. In both cases FastPay changed between banks, and not settled payments. Traditional acts as a side infrastructure to enable pre-funded retail payments. RTGS systems are implemented as monolithic centralized services FastPay can also operate with a native asset, without a primary operated by a single authority, and must employ a number of tech- ledger. In this case sub-protocols involving the Primary are super- nical and organizational internal controls to ensure they are reliable fluous, since all value is held within FastPay accounts andnever (through a primary-replica architecture with manual switch over) transferred out or into the system. and correct—namely ensuring availability and integrity. Tradition- ally only regulated entities have accounts in those systems. This result in a Balkanized global financial system where financial in- 3.1 Participants stitutions connect to multiple RTGS, directly or indirectly through FastPay involves two types of participants: (i) authorities, and (ii) ac- corresponding banks, to execute international payments. count owners (users, for short). All participants generate a key pair Blockchain-based technologies, starting with Bitcoin [35] in 2009, consisting of a private signature key and the corresponding public provide more open settlement systems often combined with their verification key. As a side-chain, FastPay requires a smart contract own digital tokens to represent value. Permissionless blockchains on the main blockchain, or a software component on an RTGS have been criticized for their low performance [18] in terms of ca- system that can authorize payments based on the signatures of a pacity and finality times. However, a comparison with established threshold of authorities from a committee with fixed membership.