3K/ Consensus - Do We Agree on What it Means to Agree?

Consensus - Do We Agree on What it Means to Agree?

Session Convener: Aaron D Goldman

Notes-taker(s): Richard Esplin

Tags / links to resources / technology discussed, related to this session:

Link to Slides

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

Context

Let’s use a blockchain! But do we really need one? When do we need consensus? What type of consensus do we need?

Additions to Content in the Slides

Levels of consensus: Durable = Crash Fault Tolerant Majority & Finality = Byzantine Fault Tolerance

• Overlapping quorums such that 1/3 – 1 can be unreliable.

Conflict-free Replicated Data Type CRDT

• Allows a consistent view without finalizing on the total order.
• Comes at a cost of discovering new data that hasn’t been incorporated.

Blockchain consensus / Nakomoto consensus is not actually final. In practice it works, but in theory a different chain could be discovered that is actually the longest chain.

Summary: when you are thinking about non-locality, stop talking about how long it takes to have consensus. Instead be specific about the time necessary to achieve the various states of consensus (local, durability, majority, finality), and expose this information to the application layer so that the user can aware of where their transaction is in consensus: (Local, Durable, Majority, Final)

Unanimity is distinct in theory from Finality, but in practice applications only care about when the transaction is unlikely to be reversed (Durable, Majority, or Final).

Though applications are usually interested in Finality, most of the time there are no cheaters, and we can move forward with Majority consensus that is much faster to achieve. But the application should be able to roll-back the transaction in the rare circumstances where Finality is not achieved.

If your application gives a Majority result without preventing Equivocation (the same node giving different answers to different queries), then the data is only Crash Fault Tolerant.

We need to ask ourselves if our application’s goals can be achieved with a lower level of consensus.

Other useful properties of consensus:

• Conflict detection
• Recording the history
• Non-repudiation

When you say “I need a ledger” ask yourself “what is the resource you are trying to mutually exclude”. Because if you aren’t trying to mutually exclude anything, you don’t need a ledger. Example SQL databases that use autoincrement(ROWID) force a level of slow consensus that isn’t needed. Instead you can use unique(ROWID) and it would be far faster.

• You don’t actually need total ordering, you just need a unique ID.

The provided consensus time matrix is as estimate based on reasoning:

• Local transactions only take a few clock cycles.
• Durable transactions require communication across the network with another machine in the datacenter, or in another region.
• Majority transactions require a two way commitment between distributed nodes.
• Finality transactions require a three-phase of nodes across the globe.

When doing state-machine replication, you could even reduce complexity be only implementing solutions for Local and Final.