,
22 tweets,
5 min read
Read on Twitter
1/ Introducing a three-part thread on the current state of distributed consensus & the engineering tradeoffs therein in PoW & PoS (as I understand them) for anybody (particularly non-technical folks) seeking to enhance their technical expertise within #crypto.
Here's PART ONE:
Here's PART ONE:
2/ What follows isn't for everyone. This was inspired by an observation of people seeking to broaden their knowledge of #crypto yet getting frustrated when things get too technical, resulting in plateaued learning curves & in some cases, lost interest.
3/ Let's begin. If you haven't already read @iam_preethi 's piece on distributed consensus, I highly recommend you give it a read. It offers terrific coverage of the basics of distributed systems + their history, & is a fantastic starting point for this:
medium.com/s/story/lets-t…
medium.com/s/story/lets-t…
4/ The high-level key takeaways from Preethi's piece are that distributed systems are about tradeoffs & that every consensus algorithm can generally be broken down into a three-step process:
1) elect
2) vote
3) decide
That said, there are various ways to execute this.
1) elect
2) vote
3) decide
That said, there are various ways to execute this.
5/ Historically, in distributed systems engineering, we have not been able to reach consensus in an asynchronous & byzantine fault tolerant ("BFT") manner. Those look like extremely scary terminologies, so let's break them down:
6/ "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 isn't reality.
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 isn't reality.
7/ This isn't reality b/c distributed systems lack a global clock. 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
1) partial synchrony
2) asynchrony
8/ Partial synchrony. This lies somewhere between synchrony + asynchrony. Partial synchrony introduces the ability to make certain time bound assumptions, but limits their impact. This enables consensus to be reached regardless of those time bounds being known.
9/ Asynchrony. In a nutshell, consensus is not reached in a fixed time (no fixed upper time bounds exist). Basically, 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.
10/ Finally, byzantine fault tolerance (BFT). For those unfamiliar with the Byzantine Generals' Problem, I recommend some light research on the topic in CS. Byzantine failure inherently implies no restrictions, and makes no assumptions about the kind of behavior a node can have.
11/ Said differently, in a byzantine system, nodes have different incentives and can lie, coordinate, or act arbitrarily, and you cannot assume a simple majority is enough to reach consensus. @ercwl touches on this nicely:
12/ Turning back to tweet #5 earlier in this thread, historically building a consensus algorithm that is both BFT + asynchronous has been incredibly challenging. Two primary concerns for reaching BFT + asynchronous consensus emerged: safety vs. liveness. Let's unbundle these too.
13/ At a very basic level, liveness refers to a situation where if there is no consensus, a network partition (fork) will occur. A fork-choice rule is implemented (more on that in Part Two). On the contrary, safety refers to halting a system until consensus is reached.
14/ Enter #bitcoin. The brilliance of bitcoin is not really the technology but rather the game theory that cracked the asynchronous + BFT challenge (favoring liveness).
15/ In PoW, all nodes don't have to communicate to achieve termination (e.g., agree on a final state) and transition to the next state, but rather agree on the *probability of the state being correct* as determined by the node that can solve the mathematical puzzle the fastest.
16/ Since bitcoin’s birth, engineers & developers have been pushing the boundaries of layer-1 innovation to understand how different tradeoffs impact what can ultimately be achieved not just at the base layer, but also with regard to any other use cases + apps built atop them.
17/ PoW is arguably the securest mechanism design known to date. For a use case to potentially capture trillions of dollars of value, high security is vital. But at what point can we draw the line between “extremely secure” & “secure enough”? What is “sufficiently secure”?
18/ To understand the state of PoS innovation today, it's important to understand the limitations of PoW. PoW security is a function of two scarce contributions: energy + time. PoW proponents argue the act of hashing in PoW provides unforgeable costliness, something n/a in PoS.
19/ PoS proponents argue this view is limited given there’s another scarce contribution captured in PoS: opportunity cost of capital. Opp. cost of capital is a foundation of financial theory. Locked up (staked) capital is subjected to the opp. cost of investing it elsewhere.
20/ Coming full circle back to tweet #17 in this thread, if we want to better understand “secure enough”, then we should learn about the attack vectors & some solutions modern PoS networks can use to combat them & how that impacts their abilities to reach distributed consensus.
21/ I'll do my best to cover this in Part Two with some project-specific examples. Finally, in Part Three I will recap the key takeaways from this exercise & examine them in the context of a risk/reward framework. Stay tuned!
