Christian Cachin

DC
h-index45
10papers
11,736citations
Novelty61%
AI Score50

10 Papers

27.1CRJun 11
Crypto x AI, AI x Crypto: A Survey

Sarah Allen, Pranay Anchuri, James Austgen et al.

The intersection of crypto x AI is spawning papers, products, online posts, and companies. All the surrounding buzz, though, obscures what exactly has been done, what the opportunities and challenges are, and what open questions deserve attention. This survey paper asks what AI can do for blockchain-based technologies (broadly construed as "crypto") (crypto x AI), and vice versa (AI x crypto). We systematize existing work, summarize key takeaways, highlight open research questions, and offer a perspective on pervasive industry misconceptions, concluding that AI and crypto are still in the very early stages of meaningful integration.

8.1ITMay 21
Monotone Erasure Codes

Vivien Bammert, Annalisa Cimatti, Orestis Alpos et al.

Erasure codes are a critical component in reliable storage systems today, and many blockchain systems use consensus protocols that involve erasure codes to reduce their communication cost. Existing erasure codes rely on a threshold failure assumption, but recent blockchain systems have departed from this simple model and use generalized failure assumptions. This paper introduces monotone erasure codes that respect arbitrary trust assumptions on a set of nodes. The paper first describes a method for constructing a monotone erasure code from any access structure given by a monotone Boolean formula. Next, the relevant notion of a linear monotone erasure code is introduced, which works on vectors over a finite field and where the encoding is a linear operation. We then focus on constructing linear monotone erasure codes: We give an efficient algorithm to construct linear monotone erasure codes for any access structure, and we show how to efficiently construct linear monotone erasure codes for the special case of partitioned access structures with minimal storage overhead. Last but not least, this work also shows how to use monotone erasure codes to obtain a communication-efficient, generalized version of the well-known asynchronous verifiable information dispersal (AVID) primitive, which is a key building block for developing efficient reliable broadcast and consensus protocols.

1.7DCJul 6
Symmetry all the way down

Ignacio Amores-Sesar, Christian Cachin, Simon Holmgaard Kamp et al.

Asymmetric trust generalizes classical symmetric quorum systems by allowing each process to specify its own failure assumptions. While this flexibility enables tolerance of strictly more failure scenarios, it is not known if, in these cases, it is actually possible to solve distributed tasks, and if so, which. We answer this question using the depth hierarchy for asymmetric trust (Amores-Sesar et al., OPODIS~'25), which characterizes how much a process must rely on others to solve a task. We prove that asymmetric trust does not increase the solvability of tasks requiring depth two or more, such as reliable broadcast or consensus. Specifically, for any Byzantine asymmetric quorum system, every failure scenario that permits solving a task requiring depth at least two can also be tolerated by a suitably constructed Byzantine symmetric quorum system. We show this via a compiler that transforms asymmetric quorum systems into symmetric ones. The additional failure patterns tolerated exclusively by asymmetric trust correspond to scenarios in which only simpler tasks requiring depth one or less (such as consistent broadcast) can be solved. We further prove that this result is tight in the depth hierarchy, meaning that there exist no compilers that produce symmetric quorum systems that are valid also in failure scenarios where correct processes have depths one or less. Our results clarify the precise power of asymmetric trust. While it strictly enlarges the set of tolerable failure patterns, it does not provide additional strength for solving tasks requiring depth two or higher.

38.4DCJan 30, 2018Code
Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains

Elli Androulaki, Artem Barger, Vita Bortnikov et al.

Fabric is a modular and extensible open-source system for deploying and operating permissioned blockchains and one of the Hyperledger projects hosted by the Linux Foundation (www.hyperledger.org). Fabric is the first truly extensible blockchain system for running distributed applications. It supports modular consensus protocols, which allows the system to be tailored to particular use cases and trust models. Fabric is also the first blockchain system that runs distributed applications written in standard, general-purpose programming languages, without systemic dependency on a native cryptocurrency. This stands in sharp contrast to existing blockchain platforms that require "smart-contracts" to be written in domain-specific languages or rely on a cryptocurrency. Fabric realizes the permissioned model using a portable notion of membership, which may be integrated with industry-standard identity management. To support such flexibility, Fabric introduces an entirely novel blockchain design and revamps the way blockchains cope with non-determinism, resource exhaustion, and performance attacks. This paper describes Fabric, its architecture, the rationale behind various design decisions, its most prominent implementation aspects, as well as its distributed application programming model. We further evaluate Fabric by implementing and benchmarking a Bitcoin-inspired digital currency. We show that Fabric achieves end-to-end throughput of more than 3500 transactions per second in certain popular deployment configurations, with sub-second latency, scaling well to over 100 peers.

6.6CRAug 30, 2021
Generalizing Weighted Trees: A Bridge from Bitcoin to GHOST

Ignacio Amores-Sesar, Christian Cachin, Anna Parker

Despite the tremendous interest in cryptocurrencies like Bitcoin and Ethereum today, many aspects of the underlying consensus protocols are poorly understood. Therefore, the search for protocols that improve either throughput or security (or both) continues. Bitcoin always selects the longest chain (i.e., the one with most work). Forks may occur when two miners extend the same block simultaneously, and the frequency of forks depends on how fast blocks are propagated in the network. In the GHOST protocol, used by Ethereum, all blocks involved in the fork contribute to the security. However, the greedy chain selection rule of GHOST does not consider the full information available in the block tree, which has led to some concerns about its security. This paper introduces a new family of protocols, called Medium, which takes the structure of the whole block tree into account, by weighting blocks differently according to their depths. Bitcoin and GHOST result as special cases. This protocol leads to new insights about the security of Bitcoin and GHOST and paves the way for developing network- and application-specific protocols, in which the influence of forks on the chain-selection process can be controlled. It is shown that almost all protocols in this family achieve strictly greater throughput than Bitcoin (at the same security level) and resist attacks that can be mounted against GHOST.

1.2DCJan 14, 2021
On the Synchronization Power of Token Smart Contracts

Orestis Alpos, Christian Cachin, Giorgia Azzurra Marson et al.

Modern blockchains support a variety of distributed applications beyond cryptocurrencies, including smart contracts -- which let users execute arbitrary code in a distributed and decentralized fashion. Regardless of their intended application, blockchain platforms implicitly assume consensus for the correct execution of a smart contract, thus requiring that all transactions are totally ordered. It was only recently recognized that consensus is not necessary to prevent double-spending in a cryptocurrency (Guerraoui et al., PODC'19), contrary to common belief. This result suggests that current implementations may be sacrificing efficiency and scalability because they synchronize transactions much more tightly than actually needed. In this work, we study the synchronization requirements of Ethereum's ERC20 token contract, one of the most widely adopted smart contacts. Namely, we model a smart-contract token as a concurrent object and analyze its consensus number as a measure of synchronization power. We show that the richer set of methods supported by ERC20 tokens, compared to standard cryptocurrencies, results in strictly stronger synchronization requirements. More surprisingly, the synchronization power of ERC20 tokens depends on the object's state and can thus be modified by method invocations. To prove this result, we develop a dedicated framework to express how the object's state affects the needed synchronization level. Our findings indicate that ERC20 tokens, as well as other token standards, are more powerful and versatile than plain cryptocurrencies, and are subject to dynamic requirements. Developing specific synchronization protocols that exploit these dynamic requirements will pave the way towards more robust and scalable blockchain platforms.

3.3DCNov 30, 2020
Security Analysis of Ripple Consensus

Ignacio Amores-Sesar, Christian Cachin, Jovana Mićić

The Ripple network is one of the most prominent blockchain platforms and its native XRP token currently has one of the highest cryptocurrency market capitalizations. The Ripple consensus protocol powers this network and is generally considered to a Byzantine fault-tolerant agreement protocol, which can reach consensus in the presence of faulty or malicious nodes. In contrast to traditional Byzantine agreement protocols, there is no global knowledge of all participating nodes in Ripple consensus; instead, each node declares a list of other nodes that it trusts and from which it considers votes. Previous work has brought up concerns about the liveness and safety of the consensus protocol under the general assumptions stated initially by Ripple, and there is currently no appropriate understanding of its workings and its properties in the literature. This paper closes this gap and makes two contributions. It first provides a detailed, abstract description of the protocol, which has been derived from the source code. Second, the paper points out that the abstract protocol may violate safety and liveness in several simple executions under relatively benign network assumptions.

10.8DCJun 21, 2019
Asymmetric Distributed Trust

Orestis Alpos, Christian Cachin, Björn Tackmann et al.

Quorum systems are a key abstraction in distributed fault-tolerant computing for capturing trust assumptions. They can be found at the core of many algorithms for implementing reliable broadcasts, shared memory, consensus and other problems. This paper introduces asymmetric Byzantine quorum systems that model subjective trust. Every process is free to choose which combinations of other processes it trusts and which ones it considers faulty. Asymmetric quorum systems strictly generalize standard Byzantine quorum systems, which have only one global trust assumption for all processes. This work also presents protocols that implement abstractions of shared memory, broadcast primitives, and a consensus protocol among processes prone to Byzantine faults and asymmetric trust. The model and protocols pave the way for realizing more elaborate algorithms with asymmetric trust.

7.3DCMar 23, 2016
Non-determinism in Byzantine Fault-Tolerant Replication

Christian Cachin, Simon Schubert, Marko Vukolić

Service replication distributes an application over many processes for tolerating faults, attacks, and misbehavior among a subset of the processes. The established state-machine replication paradigm inherently requires the application to be deterministic. This paper distinguishes three models for dealing with non-determinism in replicated services, where some processes are subject to faults and arbitrary behavior (so-called Byzantine faults): first, a modular approach that does not require any changes to the potentially non-deterministic application (and neither access to its internal data); second, a master-slave approach, in which ties are broken by a leader and the other processes validate the choices of the leader; and finally, a treatment of applications that use cryptography and secret keys. Cryptographic operations and secrets must be treated specially because they require strong randomness to satisfy their goals. The paper also introduces two new protocols. The first uses the modular approach for filtering out non-de\-ter\-min\-istic operations in an application. It ensures that all correct processes produce the same outputs and that their internal states do not diverge. The second protocol implements cryptographically secure randomness generation with a verifiable random function and is appropriate for certain security models. All protocols are described in a generic way and do not assume a particular implementation of the underlying consensus primitive.

2.3DCFeb 16, 2015
Don't Trust the Cloud, Verify: Integrity and Consistency for Cloud Object Stores

Marcus Brandenburger, Christian Cachin, Nikola Knežević

Cloud services have turned remote computation into a commodity and enable convenient online collaboration. However, they require that clients fully trust the service provider in terms of confidentiality, integrity, and availability. Towards reducing this dependency, this paper introduces a protocol for verification of integrity and consistency for cloud object storage (VICOS), which enables a group of mutually trusting clients to detect data-integrity and consistency violations for a cloud object-storage service. It aims at services where multiple clients cooperate on data stored remotely on a potentially misbehaving service. VICOS enforces the consistency notion of fork-linearizability, supports wait-free client semantics for most operations, and reduces the computation and communication overhead compared to previous protocols. VICOS is based in a generic way on any authenticated data structure. Moreover, its operations cover the hierarchical name space of a cloud object store, supporting a real-world interface and not only a simplistic abstraction. A prototype of VICOS that works with the key-value store interface of commodity cloud storage services has been implemented, and an evaluation demonstrates its advantage compared to existing systems.