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.