Image for post
Image for post
Image Credit: Swirlds

Hedera Hashgraph and a few thoughts on the future of distributed ledgers

Eckart Burgwedel
Mar 20, 2018 · 23 min read

Written on March 20, 1018; updated Sept 13, 2018.

Much has been written about the Crypto space in the past months and most has been bad news. ICO scams, seemingly erratic regulatory crackdowns in the absence of actual regulation, and heated discussions about the real or alleged shortcomings of Bitcoin, Ethereum and all the other contenders in the space.

Four days ago, on March 13th 2018, a new platform saw the day of light, Hedera Hashgraph. In their inaugural launch event in NYC, somewhat aside of the mainstream, a new approach emerged from stealth that strikes me to be one of the most fascinating new concepts in the crypto space in a very long time. They claim it to be the 4th generation of distributed ledger technology (DLT) and there is certainly something to that claim.

Hedera Hashgraph is a permissionless, decentralized public ledger, just like Bitcoin, Ethereum and many others. Hashgraph (without the Hedera) is a new consensus algorithm powering the ledger, developed — and patented(!) — by Dr. Leemon Baird, Co-Founder and CTO of Swirlds, a privately held U.S. company. It emerged a few months ago, after five years of research in secrecy.

I stumbled upon Hashgraph through an interview on the Hidden Forces Podcast, and just like the host Demetri Kofinas (thanks for asking all the smart questions!) I wasn’t able to get this out of my head again. It’s a masterpiece of technology and design, but there are also a few open questions concerning governance and political decentralization.

A new consensus layer

So what exactly is this ominous Hashgraph? In a nutshell, it’s a consensus algorithm in which consensus is guaranteed and reached within seconds, amongst potentially millions of trust-less participants — at a speed of 50k+ transactions per second, requiring only very little computational power. As a bonus, toss in a timestamp of each transaction so that the order of transactions is documented and guaranteed as well.

No gradual consensus like in the Blockchain or derivatives like Tangle, no proof of work and its massive waste of energy, no locked up funds for proof of stake, no block time to ensure synchronicity, no off-chain channel transactions like in Lightning — nothing.

Let this sink in. When I read it first, I thought it was a joke.

Technically, Hashgraph is the first known (hence the patent) way to create a trust-less system that’s truly asynchronous Byzantine Fault Tolerant (aBFT). The name goes back to the Byzantine’s Generals Problem, who could only communicate with his remote troops via messengers, who might or might not tell the truth. Here’s a great article by Georgios Konstantopoulos on BFT.

aBFT is nothing new. The mathematical strategies and proofs have been around for decades, but in large networks they required billions of messages flying around for each transaction, making it impractical for the internet. What Leemon Baird came up with, is so elegantly simple that you have to scratch your head and ask yourself why no-one had the idea before.

What he does to achieve consensus are only two things:

It’s hard to understand at first, so if you want to know the details, here’s the whitepaper. However, watch this video first.

Image for post
Image for post
The Hashgraph (Image credit: Hedera Hashgraph)

What this all suggests, is the following: Hashgraph seems to have solved all problems at once that other solutions have only solved in part, still have solve, or might not solve at all: trustlessness (no one needs to trust anyone else), high-performance, energy efficiency, guaranteed consensus and a timestamp to this guarantee, fairness in terms of access and transaction order.

Of course, any blockchain or DLT is based on the assumption, that at any given time, only 1/3 or less of the network may be malicious. At 1/3 + 1 malicious nodes, any system will fail. That’s even the case for blockchains such as Bitcoin (instead of the widely assumed 51%), but that’s a topic for another article about selfish mining.

Shared state: chopping down the tree

One of the most fascinating features of Hashgraph is the shared state. As consensus is guaranteed and this guarantee has a timestamp, at the time of consensus everyone knows what everyone else knows, in other words, everyone knows the same things and that’s a shared state. That leads to the question why you should keep the entire history of messages forever. Well, you don’t. After a little bit of time, messages are actually discarded (unless required otherwise). Wait, you might say, what about the transactions and the resulting balances? They end up in the shared state, as states of each account (State Efficiency, Whitepaper, Page 15).

In other words: unlike in Blockchains, the individual transactions are principally no longer needed to compute the account balances from the genesis block, as the current balance in the shared state is cryptographically guaranteed to be correct. You might keep them for legal purposes and audits, but technically they are no longer required.

From a purely technical point of view there is not much else you need to build the perfect public ledger. Really? Let’s see.

Performance — speed vs. network size

One of the most sorely felt problems in public ledgers such as Bitcoin and Ethereum is speed — the amount of transaction that can be processed per second (tps) and how long it takes until this transaction is validated (consensus latency). Right now, for Bitcoin it’s 4–7 tps, in Ethereum about 15–20 tps. The Visa payment network processes up to 50,000 tps. However, that’s only half of the story. As it stands today, both Bitcoin, Ethereum and all other blockchain solutions (also IOTA) only gradually arrive at consensus, through the sheer number of blocks following any given transaction. Given a block time (time between two blocks being mined) of 15min (Bitcoin) and 15s (Ethereum), the consensus latency is measured rather in minutes or hours than in seconds and essentially lies in the eyes of the beholder who needs to decide what level of trust is required. By contrast, the specified maximum confirmation time in the Visa network is 7 seconds.

Obviously both Bitcoin and Ethereum are working on solutions, introducing Lightning, and Casper, respectively. There are many other solution being built to address the performance issues, most well known ones being IOTA, Ripple, Stellar, but there are many more in fact.

While all proposed solutions have their advantages and drawbacks, I have not seen anything yet with the simplicity and elegance of the Hashgraph, seemingly solving all of those problems. However, there are a few open questions about performance. Here’s what the whitepaper says:

“The hashgraph is fast. It is limited only by the bandwidth. If each member has enough bandwidth to download and upload a given number of transactions per second, the system as a whole can handle close to that many. Even a fast home internet connection could be fast enough to handle all of the transactions of the entire VISA card network, worldwide.”

(Hedera Hashgraph Whitepaper, Page 11)

If you look at the performance charts provided in the whitepaper, it becomes clear that, for Hashgraph to perform at top speed of 50k tps and more with low latency, the amount of nodes (participants) has to be limited. To build a worldwide network with millions of nodes, Hashgraph uses sharding — which essentially is creating subgroups of nodes which arrive at consensus independently from each other and then communicate their result to the other shards, if needed. For safety, the nodes in each shard are chosen randomly and can be re-distributed at any time. By the way, this is done by a ‘master shard’, but the whitepaper doesn’t give any further information as to whether this might be a security issue. Provided the master shard is large enough, I wouldn’t think so.

In the NYC Launch Event, Leemon Baird provided performance test results, claiming 50k tps in a worldwide system with time to (guaranteed!) consensus of 2.9s. If that’s true, that speed is crazy. Bear in mind, other high-throughput solutions (e.g. Lightning, Casper, IOTA) might be just as fast or faster, but they cannot formally guarantee consensus at any specific time, let alone in 2.9s. But it didn’t stop here: in a network spreading across ‘only’ a single continent (2 regions), the speed supposedly increased to 250k tps at essentially the same latency.

What Hedera didn’t communicate on stage, however, was that the number of nodes in the entire test system was only 39, exactly as many as members of the Governing Council (will get to that in the Governing section), as revealed in an another interview of Leemon Baird by Hidden Forces, recorded one day before the event. Hedera claims that the speed of the entire network is essentially limited by the internet connection and how fast nodes can process the transactions and verify the necessary hashes. As a side note, the latter is going to happen on the GPU.

Verifying against the whitepaper, I found slightly confusing figures. From what I could understand in the graphs, I found the network size for the speed of 50k tps @3s latency at 32 nodes per shard, and for 250k tps @3s even only 8 global nodes per shard. Further, this doesn’t include the inter-shard communication. I’m waiting for Hedera to provide additional information.

Image for post
Image for post
Image credit: Hedera Hashgraph Whitepaper, Pages 12–14

My assumption here is that clever sharding with nodes being in the same geographical region will allow for shards large enough to be resilient against Sybil attacks (subversion of the network by forged identities) while still be small enough to be fast. More on this in just a moment.

However, make no mistake: this limitation is relevant only if you require very low latency until guaranteed consensus. If you allow for 60s and are happy with Hashgraph’s probabilistic consensus prediction until that point (e.g., for microtransactions), Hashgraph can probably process 500k+ tps — but that’s just an educated guess.

Sharding — proving the state

Sharding is just another masterpiece in Hashgraph. First, why would we want to have sharding in the first place? In a network with millions of nodes, it would be an enormous waste of resources and a complete overkill to have every single node run every single transaction. Instead, especially as not all transactions will usually span across the entire globe, it’s much more efficient to have individual groups of nodes in some proximity to each other, in groups small enough to be fast, but as large as necessary to be secure. With such a system, each new shard would actually increase the overall performance. The challenge lies in creating the system in which each of such shards can unconditionally trust each other to maintain overall consensus without running all transactions in every shard involved in a given transaction.

In Hashgraph, each shard is independent and holds a shared state of everything it knows — messages, storage, and states/balances of each account. When a transaction occurs between clients of different shards, the first, initiating shard reaches internal consensus and then communicates its entire shared state to the second shard, along with a cryptographic proof. Aside from the state itself, this message contains a (block)chain of address books, where each address book contains the public keys of all shard members, and where each address book is signed with a hash by the members of the previous address book. This creates a history chain of address books down to the signature of the first address book (genesis), so the node cannot lie about the shared state of its shard. This inaugural signature is also the name of the ledger (Ledger ID).

The result: no node can forge the state of its shard without the recipient noticing and ignoring the message. This allows the entire system to be asynchronous Byzantine fault tolerant while scale its general performance with the number of shards. Again, let this sink in. The open question is how big a shard actually has to be to be considered secure.

Permissionlessness — a discussion of patents and live(li)ness

There have been numerous claims that Hashgraph would only work in a permissioned environment and was therefore ‘not permissionless’. To underpin the point, there have been mainly two arguments put forward — the existence of a patent and the alleged necessity to know and actively accept every individual participants in the network.

To avoid confusion, the term ‘permissionless’, may refer to two different permissions: whether you may use some existing code and stand up your own public network, and whether you are free to join a network at any time as a node. For the former point, the answer is clearly no — we’ll get to that later.

For the second, the answer is definitely yes. I believe much of the confusion arose from Hashgraph’s exclusive use in permissioned, private networks before Hedera was announced. In addition, it was made clear that Hedera would start with a limited set of well reputed nodes — the Council, more on that later — , until the network was ready to slowly scale up with additional nodes. Unfortunately, the whitepaper does not clearly explain how new nodes would be added or removed from the consensus process. Upon inquiry, Leemon Baird and Paul Madsen explained how the process would eventually play out.

Initially nodes are permissioned, but eventually anonymous people will be able to join and run nodes, with new nodes being added once a day.

Every 24 hours every member participating in the consensus in any given shard will be reviewed and its vote weight adjusted in accordance to its availability, activity, and stake. If a node does not satisfy the necessary requirements to participate, its vote weight might drop to zero and the node removed from the shard’s member address book. At the same time, new (qualifying) nodes are added to a shard’s address book by the master shard. As a result, the group of nodes participating in the consensus is rebalanced once a day.

It’s critical to note however, that for Hashgraph to form consensus, a supermajority of votes is required at all times. Therefore, should the amount of participating stake (=weighted votes, ≠ nodes!) suddenly drops below 2/3 of all registered active stake (e.g. by a network partition), both now separated parts of the network will not be able to reach supermajority and will grind to a halt until enough nodes with sufficient stake come back. Any partition with less than 2/3 of all registered stake will stay frozen until re-united with other partitions into a network with sufficient stake. Finally, only once the supermajority of stake is re-established, the number of participating stake will be rebalanced again.

The Hedera Hashgraph platform

Hedera is Latin and means ivy, the full name being “Hedera Helix”. If you look at Hashgraph’s acyclic message graph, it’s a perfect fit.

Hedera Consortium LLC is a private U.S. company, developing the Hedera Hashgraph public ledger, which in turn uses the Hashgraph technology, for which it acquired a irrevocable license by Swirlds. Mind the last bit, there is no legal way to revoke the license and deny Hedera the use of the technology. We’ll get to that later in the governance section.

Components — consensus, storage, Solidity smart contracts, currency

The platform consists of the consensus layer, a storage system and a virtual machine for Solidity smart contracts. Hedera claims that existing smart contracts will run without any change — played skillfully in combination with SEC/KYC/AML compliance (thereby allowing mom-and-pop to participate), this feature alone could catapult Hedera into mass adoption overnight. On top of all that sits a cryptocurrency to provide the fuel powering the platform. You can find most of the details in Hedera’s whitepaper. Tt’s very well written, for the most part even more non-technical people.

Image for post
Image for post
Image credit: Hedera Hashgraph Whitepaper

As noted above, Hedera Hashgraph is a permissionless, technically decentralized public ledger. That means, no permission is needed to run a node or use the services. Further, no permission is needed to build applications on the platform.

However, as Swirlds holds a patent on the Hashgraph technology, a license is required to build private permission ledgers, and explicitly no license will be granted to build a competing public ledger. Hedera has claimed to use the patent only very defensively and to issue licenses to any interested party for legit purposes — time will tell.

Storage — a file system on a Merkle tree

The storage system is essentially a Merkle tree (tree of hashes allowing for fast differential proof of state), with the twist that it’s mapped out as a file system, allowing the developer to do all the usual operations while maintaining the advantages of the Merkle tree. In fact, I believe to have read somewhere that it will be a Patricia Trie, but I can’t find the location anymore and the whitepaper speaks of a Merkle tree. Merkle trees have been around forever, and being German, I’m glad it didn’t end up being a Merkel-Tree. ;-)

Cryptoeconomics: three fees, a salary and a proxied proof-of-stake

Cryptoeconomics is essentially the art of balancing a system into the so-called Nash equilibrium, by which no participant can gain an advantage by using a different strategy than the others. To me personally, this field is one of the most exciting in the entire crypto space.

The real meat of Hedera’s cryptoeconomic concept is in a clever mix of node incentives and a kind of delegated — or ‘proxied’, as they call it — proof-of-stake. In a nutshell, it allows any account holder to delegate their currency’s (= stake’s) voting power to a node, for both to earn interest on it. However, before we look into that, let’s understand how the nodes actually make money.


In the absence of proof-of-work, Hashgraph’s currency cannot be mined and their supply is limited, thus, the incentive for nodes to operate is provided through a system of three different types of fees, charged to any client using the network. There are three fees in the network: a node fee, a network fee, and a service fee.

The node fee will be negotiated between the client and the node executing the transaction, and paid directly. This is effectively creating a transaction market, just like in Bitcoin and Ethereum, and immediately begs the question, whether this is any better than Bitcoin’s mempool, in which hundreds or thousands of transactions are hanging around and eventually get discarded, simply because their fee is too low to incentivize the miners to process the transaction. The difference here is that the client will immediately know whether the transaction was accepted for the offered fee and can respond accordingly.

The two other fees, the service fee and the network fee, depend on the necessary computational effort and are calculated according to a fixed schedule determined by the Hedera Council. They are paid by the client to the network (Hedera), which in turn uses those fees to pay nodes for providing computational resources. The network fee is used to compensate nodes for the costs of gossip and consensus, while the service fee is to compensate nodes for the long term costs of maintaining the effect of a transaction, e.g. storing a file, running a smart contract. However, Swirlds is going to keep 10% of all fees in return for the license to Hedera.

Note: As of this update (Sept 13, 2018), Hedera changed the taxonomy of “Transaction Fee” to “Network Fee”. Although the following image is from the current whitepaper (v1.2–180906), it still uses the old term.

Image for post
Image for post
Image credit: Hedera Hashgraph

Incentive payments: a salary for voting

Im addition to the payments based on the computational effort to process transactions, every node is also paid a specific amount for each day it operates with more than (probably) 90% participation in all voting rounds. However, this sum is dependent on the amount of currency this node holds in its accounts, effectively allowing the nodes with more cash to reap even higher rewards. Why? To increase adoption and security, as counter-intuitive as it might sound.

‘Proxied’ proof-of-stake: earning interest while increasing security

Proof-of-stake is an alternative principle to proof-of-work whereby greater influence on the integrity of the system is granted to those who have more ‘at stake’, in other words, have more currency to lose and therefore a greater interest in staying faithful to the truth. As the most prominent example, Ethereum’s future Casper is designed to gradually replace the existing proof-of-work model with proof-of-stake — in order to give all that burned electricity back to Iceland. ;-)

Following this principle, in Hashgraph, the weight of each node’s vote in achieving consensus depends on the amount of currency it holds. The assumption is that a node with a lot of currency will be more likely to refrain from malicious behavior and therefore should have a stronger vote.

But wait! Doesn’t that cause centralization of power for the rich? Yes and no. To put up mining rigs for 100M dollars in one spot is not exactly decentralized, either. But yes, there are a lot of smart people who think exactly that, and that’s why Ethereum is careful to introduce a lock-up period for a cash deposit and a severe punishment for cheaters — their currency gets ‘slashed’.

However, in Hashgraph, there is no such thing as a lock-up and slashing, and that’s where — drumroll — the ‘proxy’ (necessarily) enters the stage. What it means is that any client can entrust their currency’s voting power (not the currency itself) to any node to bolster the node’s vote in the network. This can be anyone, a well-respected institution, a friend or a stranger. The clients remain in control of their currency and are free to withdraw or re-proxy it against another node at any time.

At first sight, this does sound like good old Delegated proof-of-stake (DPoS), but PPoS is actually quite different. The idea of DPoS has been around for a while, Bitshares uses it for example. In their implementation, the stake is used to elect a group of nodes (‘approved witnesses’), from which one is randomly chosen to produce that next block. In a blockchain, this is necessarily a binary affair — only one witness can validate a new block at any given time and receive the block reward.

Proxied proof-of-state, on the other hand, is a gradual approach. Each token staked against a specific node increases the node’s weight in the voting process. Since every node in Hedera gets paid in accordance to its accumulated stake, by acting as a proxy the node can make even more money, but it shares the profit with its stakeholders.

To understand why this leads to more security, let’s recall that in any given decentralized system, 2/3 of all participants must be benign for the system to be secure. However, what this also means, is that no more than 1/3 of all participants may go offline or be dormant. Hence, active participation is key. In a system with millions of accounts, only very few account holders will operate a node — thus, we could end up in a situation in which only 0,1% of all currency is actually held by operating nodes. In a system with proof-of-stake, this would impose a huge security risk, as an attacker would no longer have to corner 1/3 of the entire ecosystem but only 1/3 of the active 0,1%.

Hence, Hedera introduced a system to incentivize not only nodes to operate, but normal account holders to participate in the security of the network. Interestingly, the profit share between node and account holder is negotiated between the two and therefore open to market forces. To prevent too much concentration of power, there’s also a limit of currency that every node may represent. Just as importantly, this eliminates the necessity for each account holder to stake its currency ‘wisely’, as is often the case in DPoS.

Expected client fees and resulting network security

While not giving absolute numbers, Hedera assumes the fees will only be a tiny fraction of what other platforms will charge, allowing for micro- or even nano-transactions of the fraction of a cent. As there is no proof-of-work and the protocol is light on resources, a full node is very cheap to run.

With respect to fees, we will see what happens when Bitcoin and Ethereum introduce Lightning and Casper, respectively. Others, such as IOTA, don’t have any transaction fees at all — and, depending on network adoption, this might eventually turn out to dis-incentivize nodes to operate at all, jeopardizing the network security.

A particularly interesting question will be therefore whether and how Bitcoin — or any other PoW system with fixed token supply and no monetary policy — will maintain its security once that supply has been fully mined. At this point, the miners will only be rewarded by the transaction fees. Given that especially Bitcoin is currently almost exclusively used as a store of value, such transactions fees would have to increase dramatically for the miners to maintain the same level of security, which in turn would render the use of Bitcoin as a medium of exchange infeasible, thereby reducing the number of transactions and increasing the transaction fees even further. Transaction demand and volume are key, so Bitcoin has until 2040 to become electronic cash with sufficient transaction throughput in order to reward the miners.

As a side note, the Lightning Network with its nearly unlimited transaction speed wouldn’t much help here: transaction fees within the network wouldn’t accrue to the miners but to the Lightning participants routing payments — if a transaction is not directly peer to peer anyway and thus free altogether. The more adoption the network experiences, the more channels would remain permanently open and the less frequently channels would need to be settled. In addition, the miners would be in direct competition with the Lightning hubs, driving the transaction fees on both main chain and Lightning to a minimum. Miners would need to also become Lightning hubs in order to mitigate their loss of transaction fees by charging routing fees, but it remains to be seen how this plays out — and it wouldn’t be any good news for decentralization either.

Time will tell which system creates the right incentives for all participants to both maintain usability and network security in the long run. Short term, I would expect Hedera’s nodes to be subsidized in order to keep the fees low to drive adoption until usage has racked up to actually cover the costs of operation.

Governance — patents and councils: A Game of Thrones?

Blockchain, DLTs, and cryptocurrencies are a grassroots movement, and any solution cannot be gauged without a very close look at their governance model, regardless of their technical brilliance.

With Hedera Hashgraph, for me, there are two elephants in the room:


Much has been lamented about Swirlds’ patent on the Hashgraph. As briefly mentioned at the outset, the Hedera Consortium received an irrevocable license of the Hashgraph patent. As such, the patent isn’t much a problem for Hedera as a public ledger. The fact that Hedera is a private U.S. company imposes much bigger problems, but we’ll get to that in a second.

At first sight, the patent will have at least two major effects: it will fence of competitors in the private sectors of Swirlds business activity, and it will prevent another public ledger based on Hashgraph. But then again, will it? Why shouldn’t anyone just grab the concept and nakamoto a decentralized version of Hashgraph into existence? Bitcoin 2049.

After all, there might be a much more favourable interpretation of the patent: it could be the key to mass adoption, by offering only one — properly governed — ledger, while fending off the Googles and the U.S. governments of the world to come up with their own ledger, that everyone will simply adopt by default. Think about it.

Open review vs. open source

Hedera’s entire code base is going to be ‘open review’. Everyone can read, download, and compile it — at any time. Everything in the code base, any update, any change, is going to be transparent. However, the code may not be used for other projects without a license — except for the wallet code — , and most importantly, it cannot be changed by anyone else than Hedera through the permission of the Governing Council.

And this is where Hedera becomes centralized. Sort of.

Governing council

According to the whitepaper, Hedera is going to be governed by a council of 39 leading organizations in their respective fields, encompassing 18 industries, 6 continents, and competing interests. Every council member will serve a tenure of three years, with two terms at most, and will get proxied 2,56% of the stake remaining in the Hedera Treasury (about 65% of all tokens at the outset after the crowd sale according to Hedera’s FAQ). Subsequent council members will be elected by the council, except for Swirlds as the only permanent council member. (Whitepaper, Pages 6 ff., Forbes article on Hedera)

It appears that what Hedera is essentially doing, is apply the principles governing their technology to the governance of the entire organization — decentralized proof-of-stake. 39 nodes, each owning a share of the entire network, decentralized across the globe, with independent, even competing interests.

While the whitepaper doesn’t reveal any details on the actual process, assuming that important decisions would require 2/3 consensus, 14 members would need to collude to bring the system to a halt. However, to corrupt the entire network, 27 members would need to turn malicious. That’s essentially the principle how state constitutions get protected against arbitrary changes.

As the code base is operated under open review, any changes in the code will be immediately revealed — it remains an open question, however, whether the community could ultimately do anything about it. The whitepaper states that code changes will be rolled out in a centralized, coordinated fashion with an exact time of deployment:

“When the Hedera governing body releases a software update, all honest network providers will have their software automatically update, and all will do so at the same moment in history. Anyone with invalid software will no longer be able to modify the hashgraph and have the world accept their version of the hashgraph as legitimate.” (Whitepaper, page 7)

This doesn’t suggest much influence of the community — which is, of course, one of the necessary features to prevent hard forks from happening as we have seen them in Bitcoin (Cash) and Ethereum (Classic).

So, this then is the other elephant, the one bothering me the most. How can a privately held company protect itself against the government? One of the great features of Hedera is that they allow different levels of identification — from total anonymity to complete KYC/AML. However, even if Hedera was to comply with all the SEC/IRS/KYC/AML and what have you — right now, especially in the U.S., regulation is a complete mess, regardless of whether a token has pure utility or expected appreciation in value:

The SEC considers it a security, the Commodity Futures Trading Commission (CFTC) considers tokens a commodity, the Internal Revenue Service (IRS) considers tokens to be property, while the Financial Crimes Enforcement Network (FinCEN) consider tokens currency. (Source: Coin Telegraph).

If you are a hammer, everything looks like a nail.

Hence, wouldn’t a single cease and desist order based on some alleged or actual abuse of the platform or its currency disrupt the entire network? What would happen then? I have no answer to that, not even an educated assumption.

There is this argument that the U.S. dollar is being used for criminal activities every day — but it’s simply impossible to shut down. After all, the financial industry has worked hard to ruin the Dollar for years, and against all odds, it’s still around. ;-)

Final thoughts

I believe with Hedera Hashgraph, a new contender has entered the world stage with the potential to disrupt the entire game. Let’s look at the unique features:

Interestingly, while there have been several technical break-throughs accumulated in a single project, the technology itself might not even turn out to be the deciding factors. After all, do we need true asynchronous Byzantine fault tolerance for all use cases? Sure, if it’s really as fast as claimed and we can have it as open source. If not, aren’t Ethereum, Stellar, Tendermint, RChain, Radix and the likes good enough once they have sorted out their scaling or teething troubles issues?

What could in fact change the game is the ‘Apple factor’: did Apple invent all the wheels they are using? No. Does every developer love them? Hell, no. Where they the first to put things together in convincing, powerful and legally accessable packages for the world to embrace? Yes.

Regardless of how the governance play turns out, it’s hard to see how the world of blockchain and DLTs will stay the same with the advent of Hedera. Not that it could anyway, but there is much to be learned from this crazy man Leemon Baird and his team. Exciting times and I cannot wait to get my hands dirty.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store