On public blockchains such as Bitcoin and Ethereum, anyone can verify payments and trace how funds move between addresses. Addresses do not identify their owners directly. Therefore, in the early days of these blockchains, many people believed that payments on them were private. However, simple heuristics can link the addresses of one owner together and thereby deanonymize a large portion of users. Moreover, information from an exchange or merchant can connect addresses to real people, and then anyone can read their financial history. Privacy-preserving cryptocurrencies such as Monero and Zcash allow payments to be verified while hiding their source. Unsurprisingly, this privacy comes at a cost, and this cost motivates our work. We have analyzed such protocols to better understand the trade-off between transaction privacy, storage cost, and scalability. Our results have been published at AFT 2026.

Erasure codes are an important technique for storing and distributing data reliably across multiple nodes. The basic idea is to encode a file into several pieces of equal size and distribute these pieces, also called fragments, among different nodes. Even if some of the nodes become unavailable, the original file can still be reconstructed from the remaining fragments. Classical erasure codes, such as Maximum Distance Separable (MDS) codes – including Reed–Solomon codes – typically implement a k-out-of-n threshold structure. A file is encoded into \(n\geq k\) fragments of equal size and distributed across \(n\) nodes, such that any \(k\) of the \(n\) nodes are sufficient to reconstruct the original file. This is well-known in the literature on information dispersal.

For decades the problem of defining reliable broadcast with causal ordering in the presence Byzantine faults has been considered too complex. After exploring the literature for existing approaches, we have identified limitations in prior work. This leads us to finally propose the first complete definition of causality in the Byzantine setting that mirrors the existing one for crash-faults.

Public blockchains such as Bitcoin and Ethereum are often referred to as transparent ledgers: every transaction is visible on-chain, and addresses can be linked through transaction graph analysis.

The third part of the series deals with the more advanced Consensus protocols introduced by the whitepaper called “Snowflake” and “Snowball”, and in particular their mechanisms to finalize a consensus decision of nodes. Further, we will outline a weakness in these mechanisms and propose a change (“Blizzard”) that resolves it.

In the second part of the series we take a look at the most basic Snow protocol, called “Slush”. We outline how this protocol works, including the effects of various network and tuning parameters on its performance, and give a rough sketch of our approach to analyze this protocol.

In this three part series, we look at the “Snow” protocols that address the fundamental consensus problem and were introduced in a whitepaper by a group associated with AvaLabs that pioneered the Avalanche blockchain infrastructure. This first part gives an overview of these Snow protocols and a summary of our findings.

We introduce a new abstraction for expressing fault-tolerant consensus protocols in open, permissionless networks. It generalizes fail-prone systems and Byzantine quorum systems, asymmetric distributed trust, and gives a new characterization of the model used in the Stellar blockchain.

A new, efficient protocol prevents attacks on decentralized finance platforms and ensures a novel notion of differential order-fairness for transactions in atomic broadcast.

Composing Byzantine quorum systems for securing distributed protocols

Among asynchronous, randomized, and signature-free implementations of consensus, the protocols by Mostéfaoui et al. (PODC 2014 and JACM 2015) represent a landmark result.

We show how to realize randomized signature-free asynchronous Byzantine consensus with asymmetric quorum systems.

Scaling blockchains by reducing the concurrency across token transactions.

A technical analysis of Ripple’s protocol reveals that it ensures neither safety nor liveness under the stated assumptions.

How does one express a trust structure for consensus in a distributed system that does more than counting possible faults?

A sound model for blockchain consensus with flexible and subjective trust.

Blog posts here can be longer than tweets and are still easier to read than research papers.