We’re a software engineering firm. We build web applications, mobile applications, high-performance and scalable APIs, server-side integrations, the whole lot. Our two most recent projects, Kabuto and MyHbarWallet, are built on top of Hedera Hashgraph. But why? We’ve built projects in the Ethereum space and were hopeful about the economics. We’ve done proofs of concept on EOS and loved that it used WASM for compute. We’ve built plugins for Corda. All of those projects have huge traction in the distributed ledger technology (DLT) space for the markets they are addressing. Why would we choose to build our own products on top of Hedera Hashgraph? The answers are quite pragmatic and driven very little by hype or speculation.

Kabuto

First of all, let me say that we are skeptical about any technology that claims to be the “next generation of {X}”. When blockchain started to gain attention around the concept of operating in a trustless environment, we asked, “So what? If I have to chose between waiting 2 minutes (or 2 hours) for finality so I can trust the transaction versus executing in 12ms with a centralized compute, 90% of the time I’m going with the high performance.” Trust, as defined by the DLT space, was not a meaningful business driver. Even now, when people come to us to build on a DLT, our first question is, “Why?” There has to be a compelling business reason. So why is Hedera Hashgraph different?

1. It’s fast enough to be practical for certain types of business processes

This is critical. We built a prototype gaming application on Ethereum and 2 minutes to settle financial transactions was not fast enough. Well, what if we did a side-chain, or accounted off-chain and just settled periodically on-chain? Yeah…we explored the options, but fundamentally, if we were doing stuff off-chain, we were losing a lot of the “trust” benefit, so why wouldn’t we just do a centralized digital currency that operated in milliseconds? Enter Hashgraph. Transactions are final within 3 seconds. For most of our in-game financial transactions, that was perfect! We can do some UX magic to make that 3 seconds feel like nothing, but gamers are moving too fast to wait 2 minutes. We felt that Hashgraph gave us sufficient performance even if it wasn’t in milliseconds AND the trust of a decentralized network.

Note: We’ve also found that DLT is not a good fit for every project. We tend to build our software in a very centralized performance-/security-first model. Even with Hedera’s superior speed, sometimes you just need sub-10ms response times and then it’s a question of what’s more important, performance or trust?

2. It’s FINAL

This was a bigger deal than we originally thought. With Ethereum, we could technically think of a transaction as “final” once it had 1 confirmation. There was a good chance nothing would happen after, and that only took 10–20 seconds, but it turns out that the financial services space doesn’t think that’s enough. Even exchanges wait up to 35 confirmations on Ethereum before considering a transaction “final”. That’s 350 seconds (almost 6 minutes). Bitcoin takes 6 confirmations or 60 minutes! For a high-throughput gaming application, we can’t be waiting that long for finality and we can’t take the chance of any of our transactions not finalizing.

Hashgraph gave us real finality quickly. By “real finality” I mean that Hashgraph is a voting algorithm. Once 2/3 of the network confirms a transaction, it is final. That’s it. It’s not probabilistic. The confidence doesn’t grow over time as confirmations roll in. It happens quickly (~3 sec) and that is it. Done. Final. There is no chance of forking or pruning or purging. I can “take that to the bank”.

3. It’s more decentralized than most major projects

If I’m giving up the performance of centralized processing, that platform better be decentralized! Now, I’ve been on both sides of the coin for this value proposition. Hedera is made up of 10 enterprises hosting 13 nodes while Ethereum has 7,093 as of today. The problem with most DLT projects is a problem of leader-based consensus. Most projects chose a single leader to decide which transactions are included in a block and in which order. That’s a LOT of power for a single decision-maker. The way that proof of work resolves this is that they rotate the leadership based on a mathematic competition that is mostly unpredictable. If there are a lot of nodes, it’s really hard to determine who will be the next leader which means it’s hard to compromise the next leader and even malicious leaders would find it difficult to compromise enough of the network to make a meaningful impact. That sounds promising, except when you take into consideration that 32% of Ethereum mining is performed by Spark Pool and 21% by Ethermine. Two mining pools that control over 53% of the mining power. If one of the pools decided to implement nefarious code, there is a high probability of them compromising the network. With collusion the two could compromise the network with a brute force attack. On January 5th, 2019 there was an Ethereum Classic (Ethereum’s little bro) that suffered a 51% attack and in the last 24 hours Bitcoin Gold suffered the same thing. To be fair, there is a lot of scrutiny of these pools, so the likelihood of two entire pools colluding around malicious code is very small. But a 51% attack, or a 25% attack in the case of selfish mining, is a real threat to leader-based systems.

How does Hedera address this? Well, it is built on the hashgraph consensus algorithm which requires at least 2/3 of the network to provably witness a transaction before a transaction is committed to the ledger. This is an important distinction. Other DLTs are in the business of selecting the next decision-maker (leader). Hashgraph is in the business of taking votes. If 2/3 or more of the network doesn’t see the same thing, the transaction can not succeed. That’s about as democratic as you can get on a fundamental protocol layer. To be clear, Hedera has 13 nodes. This means that 9 nodes must “cast their vote” for a transaction to be final. If my transaction is finalized, I know that it took 9 nodes to do it. By comparison, Ethereum has 7,093 nodes, but only 1 gets to make the next decision of which transactions to include in a block. And that 1 node is likely just 2 or 3 pools. For the current numbers, I’ve repeated that Hedera only has 13 nodes, but their stated goal is to grow that to 39 nodes for a period, and at some point open it to the public to host as many nodes as people want. It’s already more decentralized on a protocol layer and will only get more decentralized as it grows.

4. It’s governed by big regulated companies spread across the world

I mentioned that there are 10 enterprises hosting nodes. This sounds rather small compared to the open source, anarchical model of Ethereum and Bitcoin. Hedera says they plan to have 39 such enterprises as part of their council, but what does that mean? It turns out that these enterprises are council members and decision-makers about the strategic direction and tokenomics of the network. Beyond that, they are members of the LLC that is Hedera Hashgraph LLC. This is huge! 10 companies, spread across the world, with their own interests in their specific industries, are collaborating to build a public network using the fairest protocol, and they’ve publicly committed themselves to the project by joining the LLC. This isn’t a foundation agreement. It isn’t a community they occasionally explore or contribute to. This is a legal entity they are legally engaged in making decisions for the project that could have legal consequences. $10,000,000,000+ companies don’t join such an effort so completely without doing serious due diligence. To be fair, they all have internal initiatives to explore “blockchain” and probably have millions of dollars committed to that effort, but they clearly see something in Hedera that convinced them it was a good idea to join an LLC and participate monthly in committee meetings. I don’t blame them. Bottom line: big companies are governing the strategy and tokenomics while the network itself is governed by the fastest and fairest protocol.

5. Hedera Consensus Service (HCS)

We just wrote an article about how HCS works so well with Kabuto (find it here) and we can’t say enough. Putting aside the fact that it’s in Kabuto’s interest for people to build on HCS and leverage Kabuto for the results, HCS is freaking cool. We like to think of it as a decentralized message queue. While we could set up an MQ server somewhere and give people access to submit messages, there is always a question of who manages the server and how fair the ordering of messages is in that queue. HCS lets us define a topic, allow multiple parties to pour messages into that topic, and we get to listen via Kabuto for the resulting fairly ordered messages. This is really cool if you want to synchronize states across multiple parties while allowing multi-party inputs. Adding to this, you get sequence numbers which ensure you don’t miss any messages. You get a running hash which lets you know that the sequence hasn’t been tampered with. Soon you’ll get state proofs which are the signatures of at least 2/3 of the nodes confirming the validity of the message stream.

Note: As of right now, it takes 7–11 seconds for the submission-to-response cycle of HCS messages because they have to be passed from the mainnet to a mirror node like Kabuto. Kabuto has optimized the retrieval and parsing process, so it may be faster than most, but the fact still remains; not every message queue use case will tolerate a 7–11 second round trip. Many require <100ms round trips.

We’ve evaluated many DLTs for fit in our software development projects and hashgraph is the first one that’s shown real practical promise. We’ve looked at Ethereum and EOS for compute. We’ve looked at Stellar for payments and tokens. It almost always comes down to time-to-finality and potential throughput. Hashgraph excels at both of those. 3–5 seconds for transactions that don’t require mirror nodes and 7–11 seconds for those that do. Complete finality. Currently the network claims to be able to handle 10,000 transactions per second and will be growing that. That is between 3x to 1,000x more throughput than the most mature public networks.

At this point it is important to note that we don’t see Hedera Hashgraph as strictly competing with the other public and private networks on the market. We are even currently exploring using HCS as a “layer 0” of other ledgers, meaning that we see the value of the community and tools build on many ledgers and are looking at how to leverage just the consensus component of Hedera with those other ledgers. This space is still just getting started and we are on a mission to find where it fits in real business use cases. We expect that the final picture will look a lot like a normal technical stack with different tools, centralized and decentralized, that accomplish various tasks to offer something valuable to the market.