Ignacio Amores-Sesar

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.

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.

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.