Coloring Crypto

the podcast illuminating the blockchain and cryptocurrency

Episode 27: Hashgraph and Distributed Ledger Technology

Where we face the dilemma: do we have to change our tagline?

Gabe: I feel like I am just starting to understand the blockchain, and now you guys come up with something better?
Paul: Sorry

Today's Guests on Coloring Crypto:

1. [00:22]: Paul Madsen with Swirlds. Swirlds, founded by Leemon Baird, creator of Hashgraph
2. [35:00]: John Hartigan with Intiva Health, one of the first companies to implement a solution on Hashgraph

Glossary of terms

• DLT is an acronym for Distributed Ledger Technology
• Distributed Ledger Technology is what the blockchain is and DLT is just a broader definition for the same solutions that aren't creating blocks.
• Byzantine Fault Tolerant came from a classic computer dilemma outlined in the 1980s. It just means that the group coming to consensus can't be corrupted by bad actors.
• Public Ledger is DLT solution that is open to anyone, the network is permission-less. This is how most of us think of the transparency and access to the ledger of transactions on blockchain technologies like Bitcoin.
• Private Ledger brings the same benefits of security and transparency of the peer to peer nature of DLTs but in a closed network. Same as a Permission Network.
• Gossip Protocol is the method that Hashgraph is using to come to consensus. wikipedia

Listen to Episode 27: Hashgraph and Intiva Health

	Youtube 00:00, 35:00	Website

(an edited transcription of the Hashgraph interview is below)

Transcription: Hashgraph Interview

Coloring Crypto: Ep.27 (part 1)

Gabe: What is Hashgraph?
Paul: So what we're trying to do is the same as what blockchain does, or aspires to do, and that is to allow some set of people on a network or computers, or on nodes in general, to come to an agreement or come to consensus on the state of some set of transactions.

Gabe: The proof of work model that most of the blockchain runs on, or even proof of stake, the problem is that it's just really slow. And so clearly if you guys have something much faster that's going to be welcomed.
Paul: Yeah, I think so, but you know to be fair to Bitcoin and Ethereum, they've got proposals by which they argue that they're going to address some of the scaling challenges. Both communities have mechanisms that they believe will increase those numbers, and that's great. We still believe that the sort of throughput that we can provide and in our tests validate that is orders of magnitude larger.

More important than those quantitative differences is the qualitative differences between the nature of our consensus and that of a blockchain so specifically we are Byzantine Fault Tolerant.

Gabe: Could you describe the Byzantine issue and how that relates to Hashgraph?
Paul: Sure, so Byzantine, in the context of consensus algorithms is a reference to a thought problem posed by some computer scientists thirty years ago. They presented the problem of distributed consensus that we're all concerned with now in the context of a bunch of generals with armies encamped around a particular city that they are trying to attack.
The challenge for those generals. Is that they all need to do the same thing so that the numbers are such that if they all attack they're going to swamp the defenders, and win the battle, but if only half of them attack then the defenders behind their walls are going to have the advantage so that the critical decision for those generals, you know separated by a couple of miles or across the battlefield of uncertain terrain where any messengers that they might send between themselves might be captured or killed or defect the challenge for those generals is how do we come to a decision either attack or retreat in the face of?

Uncertain messaging, uncertain loyalties how do we make the right decision?

How do we come to a consensus decision to attack or retreat in the face of all these difficulties. So that's the reference to Byzantine Generals right because for whatever reason these computer scientists called it that.

Gabe: So these Generals are isolated and all the actors have to decide to do the same thing.
Paul: Exactly. That's the challenge right. A community trying to collaboratively make a decision to go or no-go. Byzantine has kind of morphed into meaning evil or malicious. So a consensus algorithm if you want to make a public platform out of it, you have to anticipate that some of your nodes, some of the participants, will be malicious.
They'll be evil, they'll be Byzantine, and and so that's one metric by which we can measure a consensus algorithm. How well does it do against Byzantine actors who are actively trying to subvert the consensus, stopping consensus or skew it to their benefit?

The archetypical example for crypto currencies is a double spend where I'm a bad guy, and I send you five coins. I've only got six. I send you five and then I immediately send five to somebody else.

So all of that to set the context that Byzantine is bad & Byzantine Fault Tolerance with respect to a consensus algorithm means something a little bit more specific. It means in a broad sense that you can deal with bad actors. And you know mathematically it's provable that no consensus algorithm can deal with more than 1/3 bad actors if you've got thirty-four percent of the community and they're bad, and you control them then you're in charge.

Gabe: So does everything in this space has to deal with that, bitcoin, the blockchain...
Paul: Indeed and you know that the Bitcoin communities and the blockchain communities they talk about a 51% attack, and and yes, they have that attack, but they also have a 33% attack. It's one where you need 33 percent of your community or your influence whether it's you know hashing power or stake or however you measure influence. Plus you know the potential of the attacker controlling a firewall and using that to partition honest nodes into into you know sectors that they can sort of target differentially. So yeah every DLT (Distributed Ledger Technolology ) confronts 33 percent.
It's a law of Nature, and that's been proven. We do to to be you know full disclosure. We like every other DLT. If thirty-three percent of the nodes on a hash craft network are colluding inappropriately and maliciously then all bets are off.

Gabe: Just to clarify for listeners DLT is a Distributed Ledger, which is what blockchain is and also what we're going to talk about today: Hashgraph.
Paul: Yeah, so DLT is kind of a broad umbrella term to be fair some in the in the blockchain Community kind of reject that and you know I don't blame them. They want blockchain to be the generic term. Whatever right. We're all referring to the same thing.

Byzantine means bad and Byzantine Fault Tolerant means being able to tolerate to a certain extent that faults or bad actors.

But the other aspect of BFT ,Byzantine Fault Tolerant, set out in those original papers was that it also made requirements or stipulated nature of consensus that it can't be probabilistic it has to be final, so if you think about it. You know you've got these General sitting around the their campfires sending messages back and forth and they're trying to decide whether to attack on the next day.

It's not a lot of help to them if if they sort of have an 80% "comfortable feeling" on the morning that "I think the other guys going to attack"-- that might work, but 20% of the time they're going to get crushed by those defenders. BFT means that when you come to consensus, you won't change it.

Because it's mathematically guaranteed that others will come to the same conclusion as you just did. So it's it's a it's a very different nature of consensus than how blockchain works. Right you're you're adding additional blocks every 10 minutes, and it's that mechanism of sort of piling on that gives the community confidence in the earlier blocks the deeper in the chain block is. The more theoretical the risk of it being rolled back, but it's always there.

Gabe: So how does Hashgraph work to come to consensus, and be Byzantine Fault Tolerant?
Paul: Sure, so so we start with the assumption that you got a community a bunch of nodes. And by definition every one of those nodes needs to learn about some fact, some happening, some transaction. So we start with the assumption that if I pay you five coins, I'm going to tell the community that I did that as the first step in ultimately getting that transaction recorded into this collective memory, the collective state, the Ledger... so we use a gossip protocol as the means by which one node tells everybody else in the community some fact that transaction that I just gave you Five Points.

Gossip is a well-established messaging pattern. We didn't invent it.

And gossip, you know is a well-established messaging pattern. We didn't invent it, Bitcoin uses gossip as the means of distributing transactions, and then once a block is mined distributing the blocks back in the other direction, and they chose it for the same reason we did gossip is a fast and efficient way of getting the news out.

But of course getting the news out isn't enough because not only does every node need to know about the fact that I paid you 5 coins. The nodes also need to agree on a time at which that event happened particularly if they're trying to spot double spends f I sent you five coins, but I sent Dan five coins half a second earlier.

Just due to the nature of gossip and messaging delays and firewalls and the reality of networks so for hash graph the challenge is: we want to give the transaction of me sending you five coins a time that everybody can agree on. And if everybody can agree on times for each transaction that is flowing around the network, then everybody would be able to agree on an order for those transactions, and that's the Holy Grail right.

That's what consensus is about: everybody agreeing on the order in which a set of transactions happened.

The elegance of Hashgraph is that we're going to give to the particular transaction the median value of all the times that everybody received it. Just a very simple calculation. That serves to mitigate the the effect of slow pipes or fast pipes or malicious nodes. Well the more nodes there are the more resistant it is to evil nodes. If you've got three nodes, one node being bad will shut you down based on the math we talked about earlier. If you've got a thousand nodes then then your tolerance is higher because you're resistant to Byzantine faults. It's harder to get 333 people cooperating than one or two so there's there's safety in numbers.

Gabe: Is there a required minimum, or is this a "degree" of the level of trust?
Paul: Well, it depends. Hashgraph can be deployed in a Permission Network, and that's where we've started our business.

In a Permission Network, Everybody knows everybody-- that's not to say they trust each other.

There are other mechanisms, surrounding consensus to mitigate the risk of bad behavior, so in those deployments you could have three or four or 10 nodes and still be reasonably confident that one node is not going to corrupt consensus, or if they do at least you're going to spot them and kick them out. Right there are mechanisms to to mitigate it

In a Public Ledger, well, then you you've got to deal with the possibility of anonymous nodes where they can join freely. You don't know who they are you have to assume they're bad, and you protect yourself against those. So in those models you want hundreds or thousands, ultimately millions of nodes. It's up to whoever's implementing the particular Hashgraph solution to determine that sort of parameter. You know it's the [00:14:00] community right it's always going to be the case that the more nodes the better in certain deployment models you you can better deal with smaller numbers of notes.

Gabe: let's say I'm sending money, am I counted as a node? What I'm wondering is, is my time stamp included in this assessment to grab the median time of the transaction?
Paul: so it may well be a factor. The Hashgraph algorithm is pretty lightweight right. It's nothing like the proof of work intensity of Bitcoin. So your computer could run a Hashgraph if you had any sort of reasonable high-speed internet, and any sort of reasonable CPU.

In that case if you initiate the transaction and you are a node then yeah, your time stamp is going to be counted in the list of times that we're going to include when we do the median and by definition is going to be the earliest right because you were the first in the community to know about your send money transaction, but because you might be motivated to cheat and change your clock in order to get an earlier time stamp so that your bid.

Gabe: On the blockchain, nodes are called miners, for Hashgraph what to you call these and how are they incentivized?
Paul: It's a different model right if you think about it. On the blockchain, we pay miners, and we give them block rewards and fees because they're doing performing arduous calculations to validate transactions.

The expectation is that the node is contributing transactions into the network either for their own benefit or for their clients, these are light clients that interact on Hashgraph, it's not a lot of effort, so it's not a lot of payment.

Gabe: Okay, can you I'm curious about the whole concept of centralization and decentralization as a relates to Hashgraph, and I'm wondering if the right way to ask that question is to understand Swirlds the company that you work for and the relationship to Hashgraph. Is it open source? What's that structure like?
Paul: The founders of Swirlds invented Hashgraph and those founders have a patent on the algorithm. When Swirlds, like any other software company selling to an Enterprises charges those large Enterprises a fee for the use of their license software, so that's kind of traditional software licensing, and that's how we started our business on the Permission Network side.

Now a Public Ledger is a different proposition. A Public Ledger as I said presumes an ecosystem where anybody can can run a node. So for that permission-less , or open Public Ledgers we haven't yet announced our strategy.
You know there are there are indications that we may well soon be announcing that strategy. And what I would say is that like anybody else announcing a Public Ledger, we want developers to be able to freely build on that ledger with no cost to make their own licensing decisions about whether what they build is is open source or proprietary. We want a healthy ecosystem of applications built on that.

But yet, I would say that we look at the forks of Bitcoin and Ethereum and we would suggest that there's a valid point in the space where we can encourage stability and confidence and trust in that Public Ledger. Historically, open source software has been a great model for encouraging Innovation and incredible development, and yet when you marry that with cryptocurrency, it hasn't been all good-- where the incentives in an open source cryptocurrency to fork and clone and create their own coins and and do an ICO and see how much money they can make. We see value in a sort of a more stable model.

Gabe: Are you able to discuss some of the companies that you're working with?
Paul: Well, we've been very public about the company's on the permission side. Recently in Teva health is is building a credentialing and identity management platform for health professionals and building that on top of our consensus algorithm.

Gabe: Do you have a sense of the roadmap for when they'll be able to deploy this?
Paul: So I don't have a good sense you know their customers they buy our stuff, and then they have their own timelines.

Gabe: But Hashgraph itself is fully functioning and ready to build on?
Paul: Well, so Hashgraph is the algorithm right? We have an SDK, a Java SDK, by which somebody can download now and start building if their intent was to build a permission deployment of Hasgraph. Hashgraph is not is not just a white paper.

Gabe: In your wildly optimistic dreams if we were to jump five years into the future what does a great outcome look like? What kinds of impacts and changes do you anticipate because of this?
Paul: So I think the use cases that were used two talkin about with DLTs, use cases that Bitcoin and Ethereum and others in the space have pioneered you know we want to address those use cases. We think we have technical advantages that would allow us to address them and make them more practical and viable. But we also think that some of our advantages or features relative to other DLTs are qualitative and not quantitative. A example of a qualitative feature of hash graph is what we call fairness.

For example, EBay, or anything where two parties might be bidding on a particular resource and the order in which there two bids are are placed or matched. That requires fairness because if you don't have fairness then no one would ever be willing to put a bit in there because they couldn't be confident.

So we see a whole new category of distributed applications made possible with Hashgraph that aren't addressable by blockchain. And and you know that similar architecture so to your question you know five years out we want to be competing against the blockchain based DLTs for a lot of those use cases and will compete there based on speed and latency and DFT, but we also think that we have a we're uniquely positioned to go after that other set of use cases. So in total we were optimistic about our ability to address a wide range of distributed applications in the future. We aspire to be a full-featured Public Ledger.

Gabe: If listeners want to really dig in understand. Hashgraph what are some of the best resources out there for them?
Paul: Well, On YouTube the inventor of Hashgraph, Leeman Baird has some really powerful videos. Two notable websites Swirlds.com, there are a couple of white papers there that that I think are very useful. And Hashgraph.com if you go there you'll you'll see a countdown timer to an event we're holding in New York in two weeks March 13 where we wear will clarify some of the things I've hinted at today register before 3/13/18.

Sign up for Hashgraph announcement on March 13

Register for free here for the Hashgraph Live Announcement broadcast of Event in NY (offer expires 3/13/18 )

---

Here's the YouTube video of Leeman who created Hashgraph

Check out more episodes of Coloring Crytpo

Tweet Coloring Crypto