Enabling secure and resource-efficient blockchain networks with VOLT Srinath Setty Soumya Basu? Lidong Zhou Michael L. Roberts Ramarathnam Venkatesan Microsoft Research ?Cornell University Abstract per second) at relatively low latency (e.g., a few seconds). This paper describes VOLT, a permissioned blockchain While Byzantine fault-tolerant (BFT) protocols [22, network for a group of autonomous organizations to au- 31, 36, 55] seem to solve the core consensus problem, tomate cross-organizational business processes. Specif- subtle, but fundamental, aspects render these protocols ically, VOLT ensures that a correct member—without insufficient for permissioned blockchain networks, even trusting anyone else—shares a consistent history of trans- though the underlying substrate in BFT remains relevant. actions with other members in the system. VOLT achieves These BFT protocols were primarily designed to replicate this strong security property using the concept of a self- services in a datacenter environment—to guard against verifying ledger: an append-only ledger of transactions crash failures and Byzantine behavior by a subset of the that can be checked locally by a verifier process at each replicas. In the context of permissioned blockchain net- node; the ledger also embeds succinct cryptographic mes- works, the protocol has to be carried out across trusted sages encoding views of members to enable each veri- domains with each member representing a participating fier to locally determine globally-committed transactions. organization (such as a bank), rather than a replica of a To orchestrate this concept, VOLT employs a logically replicated service typically in the same trusted domain. centralized—but untrusted—service provider. We instan- Consequently, the desirable guarantees must be defined tiate the service provider using a highly-available cloud from the perspective of each member, rather than for a service built atop a fault-tolerant cloud storage service. replicated service as a whole only. The assumptions in An experimental evaluation of our implementation demon- these BFT protocols must also be revisited. As an ex- strates that VOLT achieves tens of thousands of transac- ample, the availability properties of each member (repre- tions per second for a realistic 50-node payment network. senting a well-resourced autonomous business entity) are different from a replica running on an unreliable machine 1 Introduction in a traditional replicated system. Furthermore, under the status quo, an organization does not trust the computing Blockchain technology promises to dramatically trans- infrastructure of other organizations for the security of its form business processes that span multiple autonomous or- cross-organizational business transactions. ganizations in areas such as finance [84], supply chains [38], These observations lead to the design of a system and the public sector [77]. The fundamental reason is that called VOLT, a permissioned blockchain in which a member— it enables a new form of trustworthy business processes without trusting anyone else—constructs an append-only among multiple, mutually distrusting business entities ledger such that it shares a verifiably consistent prefix with by offering automation, auditability, and integrity with- all other members. To accomplish this, VOLT introduces out requiring participants to trust any single entity, or the concept of a self-verifying ledger. Specifically, VOLT mutual trust among the participating entities. Example ap- employs a simple verifier run by each member node, and plications include: (a) a distributed payment network that each verifier lazily verifies an append-only ledger main- enables banks to execute clearing and settlement mecha- tained by a highly-available—but untrusted—cloud ser- nism [39]; (b) a group of financial institutions maintaining vice, which we refer to as the blockchain service provider asset registries for securities such as bonds and gold [51]. (BSP). In other words, VOLT’s approach is to delegate Motivated by these mission-critical applications, our the task of maintaining a ledger to the BSP and have each goal is to build a permissioned blockchain network: a sys- verifier execute simple, local checks on the end-to-end tem that enables a group of mutually distrusting member behavior of the service. Naturally, these checks are inde- organizations to define rules for validating transactions pendent of the internal details of how these services are and then maintain a shared, append-only ledger contain- implemented and deployed. More fundamentally, VOLT’s ing an ordered list of valid transactions processed by the approach decouples the work of a member from the rest network. The primary requirement of such a system is that of the system, thereby offering desirable flexibility to all participants following the protocol must share a con- each member in terms of implementation, operation, and sistent view of the shared ledger; i.e., a pair of correct par- configuration. ticipants must share the same prefix of the ledger. Further- Operationally, to ensure all correct members in the more, for many applications, the system must maintain system share a consistent view of the ledger maintained high throughput (e.g., tens of thousands of transactions 1 by the BSP, VOLT’s verifiers persist succinct messages a digital signature scheme. They also agree on code (or on the BSP’s ledger itself. Specifically, each verifier peri- a state machine) for validating transactions. The system odically submits a special transaction, called an approval must enable these members to construct an append-only transaction, to the BSP to be included in the BSP’s ledger. ledger containing an ordered list of valid transactions. Such an approval transaction cryptographically encodes Specifically, we wish to build a system that satisfies the a member’s complete local view of the BSP’s ledger. requirements listed below. We show that each verifier can process approval trans- 1. Consistency. A correct member (i.e., one that follows actions (submitted by other members) recorded in the its prescribed protocol) shares a consistent view of a BSP’s ledger as part of its local checks to compute an ledger containing an ordered list of valid transactions approved prefix—a prefix of the BSP’s ledger shared by processed by the system. other members in the system. Because computing an ap- proved prefix is a local operation, it offers the flexibility to 2. Progress. If a participant submits a valid transaction, members to layer business-specific policies to determine then it eventually (e.g., in a few seconds) appears in when a transaction can be considered committed. the views of the ledger on all correct participants. We implement VOLT’s BSP as a cloud service atop 3. Governance. The system enables members to evolve Azure Cosmos DB [1], a fault-tolerant cloud storage sys- membership in the system (e.g., admit or evict partic- tem, and VOLT’s verifier and the approval protocol in ipants) and transaction processing rules. Concretely, a client library that interacts with the BSP. To evaluate members share a consistent view of membership in a VOLT’s costs, we build a distributed payment network. blockchain network. Our experimental evaluation demonstrates that VOLT can process up to 20K transactions/second with one sec- 2.2 Design goals and principles ond latency and scales to 50 members in a permissioned As discussed in Section 1, traditional BFT protocols fo- blockchain network. cus on replicating a (deterministic) service across a set of This paper contributes the following: unreliable machines to emulate a single correct service. Permissioned blockchains is fundamentally a different • A new foundation—the concept of a self-verifying problem, even though the core building blocks and mech- ledger instantiated with a simple verifier and an un- anisms in a traditional BFT protocol remain relevant in trusted BSP—for building practical distributed ledgers. the design of a permissioned blockchain. We now discuss • Extensions to the core system that offer flexible, member- the key observations and principles that guide the design controlled policies, decentralized membership man- of our system, VOLT. agement, and scale-out throughput via partitioning. Egocentric members. Members participating in permis- • An experimental evaluation of our implementation sioned blockchains are egocentric with their own inde- that demonstrates VOLT scales to realistic workloads: pendent identities, as they usually represent organizations for 50-member payment network, our system achieves (e.g., banks) to carry out business-critical transactions. about 20,000 transactions per second. This is in contrast to the largely nameless replicas in tra- ditional replicated services, where the correctness of the 2 Requirements and design principles replicated service is what matters. This section provides an overview of VOLT’s target appli- Trust thyself only. Each member defines its own trust cations as well as its high level architecture. domain and engages with other distrusting members across 2.1 Applications and requirements trust boundaries in a permissioned blockchain. Thus, the system must empower each member to enforce end-to- Target applications. Our principal goal is to enable an end guarantees through a local mechanism within its trust emerging class of applications that employ blockchain domain. Furthermore, the mechanism must be flexible networks to re-architect mission-critical business pro- enough to allow