Bitcoin’s Need for Speed: The Case for HashGraph

By Leave a comment

Podcast Transcription with John Best and Paul Madsen

John Best:

Welcome to this edition of The BIGCast. I’m John Best, the CEO of Best Innovation Group. We do cool things for credit unions. If you want to check us out, you can go to Fintech.com. I’m also one of the partners and the interim CTO for CULedger – which is how I am going to spend my time today – talking about the CULedger platform. I was fortunate enough, that when I asked my friend if he had 20 minutes he could spend with me talking about this … Well, I’d like to welcome Paul Madsen. He’s the Technical Architect for Swirlds.

Paul Madsen:

Hi John! Thanks for having me.

John Best:

You’re going to be at our AXFI Conference, which I’m really excited about, doing a talk about this. It’s just fascinating. Today we have altcoins and cryptocurrency coming out of our ears. If you go on any exchange you’ll find hundreds of different types of coins and units of value being passed back and forth. So, this cryptocurrency kind of craze is doing well. We’re seeing that Bitcoin caught on and had a big run, and now it’s coming back, despite everybody always trying to kill it. But the underlying technology for that – SHA‑256 or Scrypt – we’re finding it’s a little slow. There are also a lot of other issues, because it’s basically a first try at this. There’s talk of a new kind of technology out there, and it’s starting to really hit. It’s called HashGraph – which is what Swirlds is. I’m not sure everyone understands the difference and why it’s such a big deal. I’m hoping you can give us the low-down on that.

Paul Madsen:

Swirlds is a company that has developed a consensus algorithm, or distributed ledger technology, or in the generic sense – a blockchain, that could be used to build a cryptocurrency like Bitcoin or the hundreds of other altcoins that you describe. Let’s step back a bit and think about what Bitcoin is. It’s a ledger. Bitcoin is a distributive ledger, a record of who owns how many coins at any given time, and is shared amongst thousands of nodes on the network. Rather than a single bank being entrusted with the responsibility, rather than having a single party maintain that ledger, everybody maintains it. We collectively work together to ensure that everybody has the same set of wallet balances, and that no one can cheat or spend coins twice. Bitcoin is a cryptocurrency that allows people (in theory) to buy things – a practice that Bitcoin hasn’t worked out yet, but in theory … buy things using a distributed digital coin that no one entity owns, manages, or controls.

John Best:

This includes governments and Cross-Border payments … Those sorts of things.

Paul Madsen:

That’s the premise. If no single party can manage that database, then they can’t inappropriately control that ledger, or prevent payments, or do the things that a central bank or the government can do. A particular application of this idea is that a number of parties, who don’t necessarily trust each other, can nevertheless come to agreement on some set of facts. For Bitcoin cryptocurrency, a set of facts is how many bitcoins everybody has. The basic premise, that you can allow a community to agree (or come to consensus on some set of facts), can be applied to lots of different applications – not just how many coins I have in my wallet, but what identity attributes I might have, different financial applications, and lots of different information we might want a community to come to agreement on – and critically do so without some party in the middle mediating and telling people what’s what. HashGraph is a new way to allow that network of nodes or members to come to consensus on some shared set of facts, and also allow for that consensus to be established quickly, particularly relative to things like Bitcoin.

John Best:

I want to make sure I’m understanding. I did buy some stuff over Christmas using my Bitcoin, and the way I did it was through a company called BitPay. I bought some stuff from Newegg. I went on there to buy some stuff and it says you can choose Bitcoin as your payment mechanism. I went ahead and clicked on it, and read, “Here’s the address that you have to go to in order to send us this money and, by the way, you have 15 minutes to do it.” I thought, “Fifteen minutes? That seems like a long time.” I soon found out that 15 minutes is not that long of a time when you’re trying to get this stuff done. What ended up happening is that the transaction at the retailer site timed out before Coinbase could make enough confirmations. The money went out of my account, but I never got the goods I tried to buy from Newegg. Here is a value proposition to your point though. Because the Bitcoin ledger is open to everyone, it was very easy for me to call BitPay and have them just put the money back. It is unlike Visa, where the only transactions you can see are on the financial issuer’s ledger. Everyone in the world can say, “Yeah, and there is no way that you can deny this money got sent here and they owe it back to you.” Is that kind of the speed issue you’re talking about?

Paul Madsen:

It’s related. You attributed the fact that you were able to call someone at (BitPay) as something unique to Bitcoin. It actually runs counter to the premise of Bitcoin. The premise of Bitcoin is that there is nobody in charge.

John Best:

I was able to call BitPay to get them to just put it back. Let’s say I paid you some money and used Visa to do it, I can’t see the Visa ledger.

Paul Madsen:

You can’t see it. You would need to trust Visa to roll back the transaction – which is what they probably would do, but for different reasons. Just because they want to maintain reputation. But, the fundamental issue you highlighted is inherent to the nature of how Bitcoin achieves consensus. Bitcoin relies on a consensus technology called blockchain – which as the name suggests, is a chain of blocks that contain the transactions. You were trying to buy some computer peripheral.

John Best:

I was trying to buy an HTC Vive for my son for Christmas.

Paul Madsen:

At the end of the day, what should have happened is that your Bitcoin wallet should have dropped by some fraction of bitcoins, and Newegg’s Bitcoin wallet would have gone up accordingly. That’s what we want to achieve. We want that transaction to be recorded into history as having happened. To do that, Bitcoin has to rely on blockchain. Blockchain is this technology of sequentially ordering transactions into these blocks. To do so, it temporarily empowers a particular node (called a miner) on the network. The miners race other miners to perform this math puzzle in order to win the right to be the one who gets to write the current set of transactions into history. The nature of how blockchain works is that it is artificially forcing all of the transactions that would have been happening on the network around the time you were trying to perform yours, and would have allowed a single miner get some significant reward for the energy and effort of doing so. The fact of how blockchain works means that your transaction might make it into the winning block, or it might not. If it did, the miner who created the transaction still has a lot of discretion as to whether they add it to the top of the block, towards the end of the block, etc. There are issues around how blockchain works with respect to whether it would treat your transaction fairly or otherwise.

But for you, the fundamental issue was just speed. Blockchain is designed to be slow. What it calls proof of work is designed to slow the network down to the point where transactions can be manually slotted into these blocks in a reasonable amount of time, appropriate to the number of transactions on the network. What that means, is that by design it can’t deal with a lot of transactions at the same time. Its speed, its throughput, is around three transactions per second globally. It means that Newegg couldn’t be completely confident that you actually had the coins you were trying to spend within that 15 minute window. It actually takes about an hour for any retailer, anybody accepting coins as part of a payment, to be pretty confident that it was a legitimate transaction, and that they should ship the product. You fell into this current reality of Bitcoin’s inefficiencies as a payment mechanism – as an actual currency.

Unfortunately that is just a reality of how Bitcoin’s first generation consensus technology works. It’s slow. It’s wasteful. The miner I referred to wasted a lot of energy performing that math puzzle. The miners who didn’t win, but who still tried to compete, wasted the same amount of energy – but ultimately as a lost cause because they didn’t get any rewards associated with the block. Those are the current limitations of Bitcoin. Other altcoins tweak that model. Instead of a ten minute window in which a miner competes to write that block, maybe it’s a shorter period of time. Those technologies are limited in the speed with which they can process transactions.

Segue to the need for something better – a more efficient consensus algorithm that can do what Bitcoin promises to do, but offers better speed. Faster latency. It doesn’t take a minute, tens of minutes, or an hour for a transaction to be acknowledged as having happened – latency of seconds or subseconds, and not the minutes or hours of a bitcoin of blockchain. That’s the opportunity that we think HashGraph, an alternative consensus algorithm, has. We demonstrate those sorts of characteristics in speed and latency, and lots of other qualitative differences, more so than more quantitative differences.

John Best:

My organization has been involved in this, and we found a lot of useful things when it was tested. One was this idea of “gossip protocol” – so that as each node learns about network events, it can tell what is consensed and what isn’t consensed. [Yes, consensed is a word.] Another is the idea that the order of the transactions is so quick, and the platform is speedier. There are some other pieces that are involved. If I were to try to do this in a voting system, I would have to have a leader. Even that guy who gets to write that block for that minute is sort of at risk in the design that is there. Can you talk about that for a minute?

Paul Madsen:

There is an analogy I like to make. Think about how democracies work. I am oversimplifying, but there are two different models for democracy – one of which citizens like you and I elect our leader from a set of candidates. They are going to be the president or the prime minister, depending on your country. We vote on them and then give them the power to make laws. We elect leaders who we think will do a good job, won’t become dictators, and won’t create laws that negatively impact society. That’s a representative model of democracy. In contrast with that is a so called direct model, where citizens don’t vote on who they want to be their leaders. They vote directly on the issues that confront society – tax rates, or whatever they are (typically more granular, fundamental questions). So we have two models of democracy, and we see the same distinction in consensus models. There’s a whole category of consensus where effectively one node in particular is elected leader – and they’re the ones who typically (for a short period of time) get to decree unilaterally that this is consensus “Because I say so!” and “Because I’m the leader everyone has to fall in line”.

Bitcoin is a proof-of-work system that really only involves electing a leader. You elect a leader really based on a lottery of who has the most hashing power. The other consensus, the leader based consensus, also picks a leader – but does it based on something other than hash and power … maybe how many coins they have, proof of stake, etc. If you have a leader, regardless of how you picked them, attackers can impose a denial of service and conceivably make them so busy dealing with pings that they are unable to do the duties that consensus demands of them. They can shut down the consensus. So, that’s one issue. Leaders are vulnerable to that. Another issue is that if you have one leader chosen by the community to decree what consensus is, then it’s hard to provide fairness to the other members of the node for that period. That leader is unilaterally in charge of deciding which transactions get written to the block, recorded into consensus, and which don’t. Bitcoin acknowledges that and allows users to add fees to their transactions in order to almost bribe the winning miner to include their transaction.

John Best:

Paul, put me at the top of the block. Put me in front of the line.

Paul Madsen:

Indeed. Right? And that’s why the fees currently in Bitcoin are ridiculous.

John Best:

You have to be careful. You can actually buy something, and the fee is more than the purchase price. That’s also why they introduced SegWit and Viking – which is all really fascinating to me.

Paul Madsen:

The point I was trying to make is that these leader-based models, as in leader-based democracies, are vulnerable. In representative democracies, sometimes we pick bad leaders, and it takes society a while to fix its mistake. They are vulnerable to all of the normal influences. The other model of democracy, one where citizens through a referendum or appellavity, are giving the ability to directly decide on some issue that confronts their society. That’s a pure form of democracy, but in practice it’s not logistically feasible to get all of the citizens together and give them appropriate information so that they’re going to be informed voters and actually get them to vote on a particular proposition.

If you could make that model logistically feasible, you could mitigate issues associated with the representative model of democracy. In consensus, if you could make a practical model where instead of one node (the leader) decreeing what model the current block transactions was going to be, and if you could allow the community to collaboratively establish what consensus is going to be, then it would include some attractive security and fairness. Ultimately it would also have some speed characteristics. That’s the model of consensus that HashGraph leverages. Critically, for efficiency and speed, we mitigate some of the inefficiencies. Let’s talk about how that works.

We start with the assumption that, if you want a community to be able to agree on the order of a set of transactions, then step one is just making sure that every member of the community knows about the transactions. We rely on a messaging model called gossip protocol. It’s been around for thirty some years. It’s an efficient way to get the news out to a community about something that has happened. If I am the first member in the community to learn about some transaction, maybe it’s that purchase you were trying to do on Newegg, I randomly pick one other member of the community and tell them that you’re trying to purchase the Vive with your coins. The other member of the community who I just told, well they pass that news on – they pick somebody else at random. While they’re doing that, I’m also telling somebody else. If everybody is continuing to pass the news on, very quickly, everybody learns that John’s trying to buy something at Newegg.

John Best:

But without having to have a mesh, right? Without having to say, “A needs to tell B, A needs to tell D, CA needs to tell D” and so forth.

Paul Madsen:

Right. It’s random. Because it’s random, it’s resilient to any one of those nodes being down or off-line. It’s resilient to those sorts of failures. It’s fast in that the news spreads exponentially fast, and it reaches all members of the community very quickly. We start with that point. We assume that the nodes that are trying to come to consensus on your transaction. The first thing they do is gossip it out, so that everybody knows about it. Critically, everybody learns about it at a different time. In the realities of network delays, everybody first learned about your transaction at a time different than me, the first node who sent it out. Our challenge is to allow everybody in the community to be able to come to an agreement on what time is best representative to agree for your transaction, because if we can agree on a time to assign to your transaction, then everybody can agree on where it fits in the order of all transactions. That’s fundamental to being able to process that transaction. No Encrypto. If you were trying to spend coins you didn’t have, a double-spend, that’s the challenge. Everyone knows about this transaction you’re trying to perform, but they don’t yet know the time or order in which it happened. That’s what HashGraph is going to enable. We’re going to allow the community to quickly come to an agreement on what time we should say that your transaction happened. Once we have that, then it can be processed, and appropriate balances can be incremented and decremented.

John Best:

I know we have to order them. How much less traffic would you say there is if we’re using this gossip protocol? I understand that there’s a supercomputing component. How much traffic do you think this reduces, compared to a traditional traffic consensus mechanism?

Paul Madsen:

If we’re comparing HashGraph to a historical voting model, those older ways of achieving consensus through voting (somewhat similar to what we do), not only do those nodes need to learn about all of the transactions, but they started sending ballots across the network about those transactions … where they would vote. In this case, we could imagine one node saying, “Well I’m going to propose that John’s transaction gets a particular time.” Some other node is going to vote for a different time. So we’re going to add up all of these votes. Maybe we’re going to average them. In those other voting models maybe there’s another set of messages where everybody else acknowledges that, “Yes! I agree on the fact that we’re going to give this time to John’s transaction.” So they were incredibly inefficient – just in the fact that they required all of these messages to flow across the network, and extra to the ones who actually learned about the transaction itself. That’s notably where HashGraph differs than these historically voting models. We do have nodes vote. [I’m making “air quotes” as I say that.] But, we don’t require that when you cast a vote, you being a node, you have to tell other nodes about that vote. So, we don’t have those extra messages where everybody says, “Hey, I propose 3 o’clock on Friday for John’s transaction.” And, someone says, “Well, I propose 3:01.” We don’t have those extra messages. The magic of the algorithm is such that everyone just looks at their own history of messages in the gossip that I previously referred to – by which people learn about transactions. Every node is able to look at their own data-structure, we call it a HashGraph, which they built up by paying attention to the times that messages were received by the network. So the votes in our world, or in our algorithm, are virtual. Virtual voting is what we call this process where every node is able to look at their own copy of the HashGraph (this history of messaging), and logically put themselves in the shoes of some other node across the network. And, logically able to vote as if they are that other node. All nodes are doing this, and so every node – in a purely local fashion, is able to run these elections, at the end of which everybody comes to the same answer about the time to be given a particular transaction.

John Best:

That’s the breakthrough, right? That’s where Leemon, yourself, and the group – but Leemon in particular … (When I first met him, well I was fortunate enough to meet him even before Mance was aboard; I’m not sure if you were working there at that point.) The big breakthrough here though, is what you described – the whole Byzantine General’s problem, which is: “Hey! You and I need to attack a city, and if we don’t attack together we’ll both die. We both need to be sure and guaranteed that we’re both going to attack, because it means our immediate destruction if we don’t do it.” I say I’ll attack a 3:00. You say you’ll attack at 3:01. Back and forth we go, or attack at dawn. What’s the big breakthrough in that context? I know Leemon had a huge breakthrough with this.

Paul Madsen:

So, there are multiple breakthroughs. One of which is what I just referred to is the efficiency of the algorithm, in that there’s a certain bare minimum of bandwidth required just to get the transactions out to all of the network. You can’t do any better in bandwidth than letting everybody know about the transaction. The beauty and elegance of the algorithm is such that we only add a small additional bit of information to each of these messages that enables this subsequent virtual voting process. In terms of bandwidth, we run really close to the absolute physical limit of how much bandwidth you actually need to get all of the information out to all of the nodes. We add this additional layer – a small layer of only one or two percent. That’s incredibly efficient. Ultimately, that is why HashGraph is so fast and why latency is so low. Because we run as close to the pipe can support. The Byzantine General’s Problem is that he’s got this number of generals, and more important than whether they decide to attack or to retreat, is that they all decide to do the same thing.

John Best:

Right, and there are no bad actors. Don’t trust any of them because they don’t know for sure.

Paul Madsen:

You have to assume that some of them will be bad. How do you have a community of actors, some of which are going to be evil and trying to corrupt the result, and you can’t fully rely on the network between them. In the analogy, you send a horseman with a message saying, “I’m going to attack!”. Well, that horseman might be killed on his way, or maybe he just defects. I’m playing off that analogy. The Bitcoin solution to the Byzantine General’s problem would be that one general might have this vague sense of confidence after ten minutes: “Yeah! I think I should attack.” After twenty minutes he might have more certainty that attack is the right solution. Only after an hour, given how blockchain works with that sort of incremental additional assurance, only after an hour would he finally say, “Okay, I feel pretty confident that we’re going to do this. We’re going to attack.” Of course by then, the attack is over. The other generals have already attacked and they were rendered to the defenders of the castle.

The other key aspect of HashGraph that Leemon developed, is that consensus is not only fast, it’s final. There is a definite moment in time when everyone in the network knows that everybody else has reached consensus on a particular fact – in this case, the time of your transaction. Or, in the General’s case, the time at which we should attack. That’s very different than the blockchain world, where you sort of get more comfortable and confident that something is not going to change. But you never have that certainty or finality of consensus. That’s really what Byzantine fault tolerant means – that your consensus gives you this characteristic of the consensus. It’s like a step function. Before consensus happens, everybody is waiting for consensus to happen. It happens, and immediately after it happens everyone knows it’s happened and can move on to the next problem.

John Best:

I saw last night that you guys put out another SDK. I was playing with it and what I saw is that you’re giving this list of events. Some of them are consensed. Some of them aren’t. Now you’re even telling me for the ones that aren’t, when they will be – which is pretty wild.

Paul Madsen:

Yes. That’s a new feature in the SDK. I think Leemon referred to it as predictive – predictive value for the consensus. That can be useful for many applications because it can give the application a head’s up, and perhaps start processing that transaction even before it gets the final consensus time stamp for the transaction.

John Best:

I know that there are a whole lot of people who are going to have a lot of questions. If people want to know more, where should they go?

Paul Madsen:

HashGraph.com is the site where we maintain information about the algorithm. Swirlds.com has a number of different white papers and tech reports. On YouTube, if search on HashGraph or Leemon Baird, you’ll see a number of great videos that are incredibly helpful.

John Best:

We didn’t have videos when we started, so I had to spend days in a room with (Leemon). It’s a lot like being in “A Beautiful Mind” or something. It was pretty amazing.

Paul Madsen:

Every once in awhile I try to convince myself that I understand HashGraph, and then I’ll have a conversation with Leemon and I’ll quickly disabuse with the notion that I fully understand it to the level he does.

John Best:

Yeah, it’s amazing. So HashGraph.com. Also, Swirlds.com. How about a Twitter feed?

Paul Madsen:

@HashGraph is a lively source of information.

John Best:

And there’s a constant conversation going out there on Telegram. For those of you who don’t know what it is, it’s a chat room, like Discord. There’s a HashGraph Community, I believe it’s the name of the channel, and there’s just continuous communication going on out there.

Paul Madsen:

We also have a developer oriented chat room on Discord. We recently moved that off of Telegram just because it’s easier to show code and similar things there.

John Best:

I can’t thank you enough. I think we’re going to have to do a Part II to this, and I think good timing would be some time just before AXFI. For those of you who don’t know it, Paul is going to be a speaker at the AXFI Conference. I’m very excited to hear what he has to talk about, because there have been lots of applications and he has a well-rounded background. Go to AXFIConference.com. He’s got a full hour to really share with us in detail, all of these fascinating things. I can’t thank you enough for coming on, sharing your time, particularly on short notice.

Paul Madsen:

Thanks for the opportunity, John. HashGraph is a simple idea, but ideally one that has some nice characteristics.

 

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.