The State of Distributed Consensus
This post was originally published on July 01, 2019, and sent to Messari Pro subscribers.
What follows isn't for everyone. Many people seek to broaden their knowledge of crypto, but often get frustrated when things get too technical. The result is a plateau in learning and in some cases, lost interest. Learn both sides of crypto, finance, and technology, even if just for your own good. One can never know enough.
If you haven't already read Preethi’s piece on distributed consensus, I highly recommend you give it a read. It offers terrific coverage of the basics of distributed systems and their history, and is a fantastic starting point for this conversation. The high-level key takeaways: distributed systems are about tradeoffs. Every consensus algorithm can generally be broken down into a three-step process: 1) elect; 2) vote; 3) decide. There are various ways to execute this process. Historically, in distributed systems engineering, we have not been able to reach consensus in an asynchronous and byzantine fault tolerant ("BFT") manner. Before we explain why that’s a big deal, those look like extremely scary terminologies, so let's break them down.
"Asynchronous"
Synchrony = simultaneous action/occurrence. Asynchrony = opposite of synchrony; absence or lack of concurrence in time. Synchronous systems assume a perfect network where nodes are organized & deliver messages within a defined time-bound. This doesn’t match reality because distributed systems lack a global clock. Instead, they need a way of determining the order/sequence of events happening across all computers in the network. There are ways to resolve this, most notably: 1) partial synchrony; 2) asynchrony. Partial synchrony lies somewhere between synchrony and asynchrony. It introduces the ability to make certain time-bound assumptions, but limits their impact. You can reach consensus regardless of whether the time bounds are known. With asynchrony, consensus is not reached in a fixed time (no fixed upper time bounds exist). It is assumed that a network may delay messages infinitely, duplicate them, or deliver them out of order. This is often closer to reality for real-world systems.