The Distributed Ledger Crash Course - Leemon Baird (Bitcoin, Ethereum, NEM, Hashgraph)

Since releasing Episode 8 of Hidden Secrets of Money, we've fielded many questions about some of the cryptocurrencies and blockchain projects that weren't included in the episode due to time constraints. In this bonus video, Leemon Baird gives Mike Maloney an excellent rundown of the pros and cons of the various blockchain/consensus protocols. Watch the full episode and many other bonus features like this.

What is a Distributed Ledger?

A distributed ledger is a way that a group of computers can come to an agreement– usually an agreement on the ordering of some transaction, maybe an agreement on what time each transaction reached the communiity, as well. We want to come to an agreement even though we don’t trust any particular computer. That’s what a ledger is. And it’s all about trust.

We don’t want to have to trust any one person in the community to be honest. We just want to have to trust that the community as a whole doesn’t have too many bad apples in it.

So we want to trust that even if there are a few bad people, and even if those people are colluding and working together, and even if there’s bad firewalls cutting us off from each other that are colluding with the bad people, we’ll still maintain a secure network, we’ll still keep running, we’ll still get the right answer, we’ll still come to the right agreement.

That’s what a ledger is about. It’s building trust in the final result… that our election is fair, or our money isn’t being forged, or that documents aren’t being forged when they shouldn’t be.

The Five Major Techniques for Building a Ledger

There are actually many different ways to build a full consensus ledger. Bitcoin was not the first. The first of these ledgers appeared roughly during the 1980s. As technology has evolved, so has our solution to the byzantine general’s problem.

1. Pure Voting Systems:

Voting algorithms are pretty complicated, but we all send votes to each other on some yes/no question. Of course, it’s kind of hard to put things in order just knowing yes/no questions, and it’s hard to get a time stint with that info. The problem with voting algorithms is that we all send each other votes, and then we send each other receipts about our votes. And then each node in the network has to tell the other nodes how other members of the community voted, which becomes bloated with information and exchanges of data. 

And then we go through multiple rounds of this, and then at the end all we know is it was a single yes/no question. 

It’s very secure. It could even be fair in some senses, although getting fair ordering doesn’t come out of any of these systems we’ve seen proposed. The problem is that it’s slow– so slow we don’t know if anyone has ever done it.

2. Proof of Work:

We use a chain of blocks, and each block will have a bunch of transactions in it. It started with moving money from one wallet to another, but now we’ve extended it to changing our shared data layer or running smart contracts and recording their results. There’s lots of things you can do.

The idea is as a community we’ll all agree that this block, this set of transactions, this list in an order of transactions is the first one. And then as a community we’ll all agree this next one gets put on top, and then the next one. But how do we do that?

Any node in the network can raise their hand and say here’s a block! And we just apply blocks in that order. But what if two nodes raise their hand at the same time. You would have a chain, and then at the top you’d have two blocks put on at the same time. At that point, the chain is forking and turning into a tree. But that’s not helpful.

When the ledger was a chain, we knew what order each transaction ocurred in, but if it changes into a tree we don’t know what order things happened it.

So the community will always add to the longest chain, and as long as we can talk pretty fast eventually we’ll all agree on which one is longer, and we’ll say which fork is the real chain.

But wait! What if we’re adding so fast that it forks faster than we can chop off the forks. So we have to slow ourselves down on purpose. That’s called proof of work. Proof of work is anybody can raise their hand and add a lbock, but first they have to solve a math puzzle, which doesn’t accomplish anything for humanity.

If the problem is super complex, the only nodes who’ll be able to solve the problem are miners using supercomputers, but this means we’re wasting money and electricity to build a system that is slow on purpose.

The reason we did proof of work int he first place was to slow things down, which isn’t terribly conducive to being fast.

3. Leader Based:

Leader-based ledgers solve the problem that plagues proof-of-work and voting ledgers: they’re slow.

In a leader-based ledger, all transactions are sent to the designated leader of the community. 

The leader arbitrarily picks the order of the transactions. Then the leader tells the community what order the transactions are in, and then the members of the community can digitally sign that they agree with the order.

However, the problem with leader-based ledgers is that they are vulnerable to attacks.

There’s Distributed Denial of Service (DDOS) attacks. In these cases, a hacker compromises hundreds or thousands of little computers all over the internet, and then they tell them all to flood one computer with messages, and that computer is so flooded with messages it’s unable to process other information or requests for as long as the attack continues.

If then the network stops working as long as the attack goes on. But we don’t want ourselves to be vulnerable. 

If it’s a small botnet, and it can only shut down two or three computers at a time, 

We want Denial of Service resilience. We don’t want it to be denial of service proof, but at least resistant.

In a leader-based system, an attacker can flood the dictator with messages and effectively shut down the leader. In that case, the network can react and elect a new leader.

But there’s still a problem. Imagine that one of the computers in the network is compromised. Because it’s in the network, it has to know who the leader is. And if it knows who the leader is, and if it’s talking to the botnet that is perpetuating the attack, the compromised computer can relay that info to the attacker.

So the botnet simply follows the leader as it changes from computer to computer, and it will shut down the entire network for as long as the attack goes on.

However, leader-based systems don’t scale well. Although they’re generally faster than voting and proof-of-work systems, leader-based systems 

4. Simulated Economy / Proof of Stake: 

In a simulated economy or proof-of-stake system, all the computers in the network talk to each other randomly. Each computer changes it’s opinion based on the opinions of the other computers in the network.

It’s like building a blockchain, but every time the chain forks, each node has to figure out which fork to go with. Each node gets to vote on which chain it believes is the correct one, but you have to gamble real monetary value in order to vote on the chain.

If it turns out you voted with the majority, you get your money back plus some extra, but if you’re in the minority, you lose your money.

That’s one example of an economy based system.

Economy based systems incentivize each member of the community to participate in the voting by antying up a monetary reward.

If every member of the network is self-interested and acting independently, then Adam Smith’s invisible hand of the market should cause emergent behavior, and we’ll all do the right thing and we’ll have consensus.

If we start forking too fast, members of the community will hesitate to vote because they won’t know which chain is the right one. This self-regulates the speed of the blockchain.

But how secure is it?

Nobody knows. Although economy-based systems are resilient to DDOS attacks, it’s impossible to mathematically prove that the system is secure. It’s a complex system with chaotic behavior. You can’t mathematically prove it won’t crash, but the same is true of the New York Stock Exchange, but we’re not going to abandon that.

5. Virtual Voting: 

Virtual voting is all of the math proofs of the voting system, except that you’re doing the voting system with no votes.

The challenge with virtual voting is that you have to know a lot– you have to know what everyone else knows, you have to know when they knew it and in what order they learned it.

Leemon Baird’s company has accomplished this type of ledger with Hashgraph. Hashgraph accomplishes consensus using the gossip protocol and gossip-about-gossip, then uses virtual votes to build a ledger.

There’s no leader. There’s noone to attack. There’s no wasting electricity on proof-of-work.  We have proof of asynchronous byzantine and proof of fairness.

Those are the five ways to build a ledger. For more info, watch the rest of Leemon Baird's HSOM 8 bonus features.