As you can see, when they talk about their throughput, not even they are talking about how fast their consensus algorithm is. So let’s put this myth to rest, please.

But Hashgraph’s consensus algorithm is super fas-

No. It doesn’t matter if Hashgraph’s consensus algorithm is so fast that it all just happens all automagically. All you’re talking about is reducing the size of that tiny train carriage. Even if you eliminate it completely, you still haven’t barely done anything to improve the performance of the system.

Quick note on speed: There are two ways DLTs can go “faster”.

There’s the TPS, and then there’s transaction confirmation times (finality latency). That the Hedera Hashgraph has quicker native finality is mostly true, but it’s also sort of debatable. I’ll just point to a few counter-examples of how you can reach hashgraph-level latency for bitcoin and other Proof-of-Work chains:

Sidechains : You can have a consortium of nodes controlling a bitcoin multisig wallet where you deposit your coins, where >2/3 of the nodes are required to sign off on transactions made within the wallet and before they can leave the wallet. This is what Blockstream’s Liquid is (which runs on a 1 minute block time, and reaches finality at the 2nd block). You can set up something faster if you want; for example, the nodes operating the wallet could run the open-source XRP codebase and settle transactions with the same speed as Hedera Hashgraph (~4 seconds), with similar security guarantees.

: You can have a consortium of nodes controlling a bitcoin multisig wallet where you deposit your coins, where >2/3 of the nodes are required to sign off on transactions made within the wallet and before they can leave the wallet. This is what is (which runs on a 1 minute block time, and reaches finality at the 2nd block). You can set up something faster if you want; for example, the nodes operating the wallet could run the open-source XRP codebase and settle transactions with the same speed as Hedera Hashgraph (~4 seconds), with similar security guarantees. Lightning Network (L2): Lightning transactions are fast. It is a channel-capacity dependent L2 solution, but can settle transactions near-instantly, with almost the full assurance of Bitcoin’s Proof-of-Work security.

Lightning transactions are fast. It is a channel-capacity dependent L2 solution, but can settle transactions near-instantly, with almost the full assurance of Bitcoin’s Proof-of-Work security. Pre-consensus: Another way to reduce finality latency it is to have mining pools come to consensus on which transactions in the mempool to include in the next block on beforehand and orphan any miner that doesn’t follow the plan (it means they lose the block reward). This is what Bitcoin Cash is planning with Avalanche (called “pre-consensus”). Avalanche reaches consensus in ~2 seconds with strong probabilistic finality.

Another way to reduce finality latency it is to have mining pools come to consensus on which transactions in the mempool to include in the next block on beforehand and orphan any miner that doesn’t follow the plan (it means they lose the block reward). This is what Bitcoin Cash is planning with Avalanche (called “pre-consensus”). Avalanche reaches consensus in ~2 seconds with strong probabilistic finality. 0-conf: You can just accept a transaction as soon as it shows up in your mempool. This happens nearly instantly. Oh, but this is insecure you say? You’re saying while it’s true that most miners honor the first-seen rule, there are some pools out there replacing transactions that could end up losing you your money? So… you’re saying it doesn’t matter how fast the transactions are, but how difficult it is to reverse such a transaction and how harsh the punishments are for the actors trying to do it? I agree :)

Hedera Hashgraph vs PoW in efficiency

Before I leave this part, I do want to talk quickly about how efficient Hashgraph’s consensus algorithm actually is compared to PoW in terms of how much data is propagated and needed for validation. If you’re not interested in this, you can skip to the next heading.

So Hedera Hashgraph doesn’t have blocks, but it does have events. This is what the blue circle in the image above depicts — these are constantly sent around to each other by the nodes in the system. These events contain one (or several) transaction(s), just like blocks do. And the transaction(s) in these events are all signed by their respective senders. But the senders are different from the nodes. Senders are the typically people outside of the network who just want to get their transaction confirmed, and they deliver it to these selected Hedera nodes (Alice, Bob, Carol etc.) who are responsible for including it in the hashgraph. And that’s how the transaction(s) end up in events (tiny blocks) that the nodes circulate with each other for consensus.

Now, Hashgraph has it’s own special way of reaching consensus on the event order which isn’t important to this topic right now, but what you need to know is that they use a virtual voting process that is enabled by nodes doing what’s called “gossiping about gossip”. This means that when a node receives transactions, it gossips this information to its neighbours (in the form of an event), but it also gossips the identifiers of the last event it received and the last event it sent (those are the two “hashes” in the image above). You don’t need to understand why they do this, but it is what allows the system to reach unanimous consensus without voting on things.

Now, Hedera prides itself on being able to broadcast this gossip very efficiently because nodes just send short identifiers of the hashes rather than the actual hashes (see “Efficient Gossip”, p. 91, Hedera Hashgraph whitepaper), so that it only amounts to one or two bytes per hash tops. But the real overhead in this system are not the hashes — it’s the signatures which are 64 bytes each. Remember, these signatures that each node attaches to their event have nothing to do with the cryptocurrency transaction(s) they contain, they are additional signatures that the nodes use to come to a trusted consensus on the event order. It’s a part of the Hedera voting protocol, ergo, it’s all overhead!

Now, do you remember what the PoW overhead was in the example for Bitcoin? 6 bytes per transaction + 80 byte overhead (it’s a few bytes more, but not relevant):

So this means that unless each gossiped event in Hedera contains more than 10 transactions, Hedera’s 64 byte signature overhead is already more bloating than Bitcoin in terms of how many bytes must be sent for consensus purposes. But if Hedera would really begin batching transactions within events like this, it reintroduces the problem where the nodes batching the transactions can influence their order, which is one of the primary issues with bitcoin mining Hedera set out to solve. In other words, this would be a strange option.

Regardless of which, this overhead contains signatures, and validating them requires doing a signature validation step on your computer.

For some frame of reference, Bitcoin artificially limits the number of signature operations (sigops) a block can contain to 20,000 to not put too much load on the computers validating the blocks. That’s 20,000 signatures per 10 minutes. That’s just 33 signatures per second. Hedera is doing far more than this for the consensus process alone. And that’s not counting Hedera’s hash identifiers and timestamps that also need to be gossiped with each event for the consensus to work.

The lesson here is that Bitcoin’s consensus process already is truly lightweight. Apart from those 6 bytes per transaction necessary to order the transactions into a block, Bitcoin only emits ~80 bytes of data every ten minutes for consensus to be reached. This is a bizarrely little amount of data, compared to Hashgraph that gossips about gossip constantly and attaches a new signature every time a node gossips. And then we haven’t even gotten to the part about how Hashgraph communicates this consensus to the users on the outside, which is a whole other ordeal which we’ll get into later.

So maybe Hashgraph really is a revolution in voting protocol efficiency, I really don’t know — but what I do know is that it’s got nothing on PoW, which doesn’t have to deal with votes at all.

Now to the fun stuff

Let’s re-read that sentence about throughput once again:

If the network node has enough bandwidth to download and upload a number of transactions per second, the network as a whole can handle close to that many transactions per second.

One thing that’s bound to make certain people spill their coffee is that Hashgraph is cloning Ethereum’s EVM (the engine for Ethereum transaction and smart contracts execution) so it will work with Solidity applications.

For those who have followed my Ethereum syncing thread, you’ll know I’m currently running the EVM at the capacity of what my machine is capable of at the moment. And what’s interesting is that it isn’t the bandwidth that’s the bottleneck. Actually, here’s a list of the things that are not the bottlenecks on my Ethereum node:

Downloading all the blocks and transactions (in the right order)

Validating the Proofs-of-Work

The RAM

The CPU

With only 100 KB/s utilized, my machine already has more than enough transactions buffered, waiting in a queue to be processed. But it’s the speed of the SSD that stops this transaction processing from going any faster. And my MacBook Pro 2019 has the fastest SSD a laptop can have (which is really competitive). Here’s a snippet from my Ethereum log file: