Exclusive from Hedera Hashgraph CEO: Hashgraph is BFT, Blockchains are notBy Feb 20, 2020 4 Min Read
Read part one.
Hedera Hashgraph is a decentralized public network built to support developers and decentralized applications and with a publicly stated mission to bring a layer of trust to the internet. Hedera Co-Founders Mance Harmon and Dr. Leemon Baird invented and developed the hashgraph—which is fast being recognized as an alternative public ledger technology that solves the same fundamental issues that are currently preventing blockchain from achieving mass adoption.
In this second part of our exclusive interview with Mance Harmon, CEO, and Co-Founder of Hedera Hashgraph, he answers our questions on the hashgraph’s unique consensus mechanism, the Hedera Hashgraph 2.0 whitepaper, and why the hashgraph is ACID-compliant while blockchains are not.
Can you explain the tree structure representation of Hedera Hashgraph?
The hashgraph is a representation of the history of messaging between the nodes of the network about a set of transactions. As an example, the hashgraph will contain within an indication that ‘Node A gossiped Transaction X to Node B at Time T1’. It is from this shared history that nodes are able to deterministically extract a consensus timestamp and order for each transaction, ie ‘Transaction X occurred at Time T2’. Other consensus algorithms may use a graph instead of a chain, but will generally track some other aspect than messaging history.
Satoshi once said, "The proof-of-work chain is a solution to the Byzantine Generals' Problem". To the best of our knowledge, Hashgraph uses a "Byzantine Fault Tolerance" as its consensus algorithm which requires at least two-thirds of nodes to remain honest and reliable to maintain the network. Why did you choose BFT instead of PoW?
Technically, while PoW mitigates byzantine or malicious nodes, it is not ‘Byzantine Fault Tolerant’. To be BFT, a consensus algorithm must deliver the finality of consensus, ie there must be a moment in time when each node knows the consensus value under consideration, and will not change its mind in the future. PoW blockchains do not provide finality, nodes have instead a growing level of confidence that a consensus value will not change - this as additional blocks are added to the chain and so make a reorganization more unlikely.
And of course, PoW is manifestly (and intentionally) wasteful in the use of electricity.
Hashgraph does not use BFT, it is BFT, ie it delivers finality of consensus and so meets the criteria. Furthermore, hashgraph can deliver finality even under challenging network conditions, e.g. firewalls and arbitrary messaging latency. Consequently, hashgraph is *asynchronous’ BFT - the highest guarantee of security a consensus algorithm can make.
In Hedera Hashgraph, how do you prevent a sybil attack (an attack where one person tries to take over the network by creating multiple nodes)? Is it by proof-of-stake, or only allowing authenticated nodes or other solutions?
For Hedera, we use a node’s stake to weight the votes of each node towards the determination of consensus timestamps, and so inhibit Sybil attacks. In the initial phase, the network is permissioned to only the Council members but will transition to permissionless when the distribution of hbars into the market allows us to do so securely.
According to the whitepaper,Hedera Hashgraph does not require pruning of would-be “forks” (as every container of transactions is incorporated into the ledger), Hashgraph allows more powerful mathematical guarantees, such as Byzantine agreement and fairness. Can you elaborate more on this concept?
In a blockchain, consensus manifests as the election of a leader that is empowered to determine the contents of the next block. If that determination is non-deterministic (as in PoW) then it will be possible for two leaders to be simultaneously elected and to both create valid candidate blocks. The network will, at least temporarily, fork into two valid chains - until one of them is rejected or pruned. There are inefficiencies in such pruning.
Hashgraph, on the other hand, does not prune or reject these sorts of alternate views of the transaction history. Instead, every participant's view of history is woven into the hashgraph - a shared & consistent representation of all those views. It is from this shared history that nodes deterministically extract a consensus view - specifically a consistent timestamp & order for all transactions within the hashgraph.
Because hashgraph does not concern itself with preventing forks (but rather reconciling them into a consensus), there is no need to slow the network down with PoW to keep those forks under control. Consequently, hashgraph can deliver significantly higher throughput.
In the whitepaper, Hedera Hashgraph claimed it is ACID-compliant and mentioned that blockchain would not be ACID compliant. Can you elaborate on the latter, and what is the significance of being ACID compliant?
More precisely, a PoW blockchain that does not provide finality of consensus will not be ACID compliant as, without finality, the durability D, ie, that once a transaction is committed, it will not change, cannot be guaranteed.
According to the whitepaper, the throughput of Hedera Hashgraph can reach up to 500,000 TPS in a single region. Can you justify this claim for us?
To be clear, the whitepaper cites performance testing that demonstrated throughput of this order of magnitude under certain assumptions about the # of network nodes' geographic distribution and desired latency. The whitepaper includes performance curves that demonstrate how tps depends on such parameters.
Critically, the whitepaper also acknowledges that the performance numbers are for just consensus, ie, the assignment of a consensus timestamp to each transaction. But of course, a real-world ledger does not merely assign timestamps and order to transactions; it applies the transactions to the shared state in that consensus order, e.g., if the transaction is a crypto payment, it updates the balances of the accounts accordingly. The whitepaper acknowledges that the details of the transaction will have an impact on the effective throughput.
What’s next for Hedera Hashgraph in 2020 and beyond?
Hedera has an audacious but simple vision: to build a trusted, secure, and empowered digital future for all.
While much of last year was spent ensuring the platform was ready for public open access, 2020 will focus on making it easier for applications to onboard, integrate with other parts of the DLT ecosystem, and develop highly scalable applications that meet their needs. A few items on our roadmap include:
HEDERA CONSENSUS SERVICE
Launched in Feb 2020. Developers can begin using Hedera Consensus Service to build high-throughput, low latency applications, utilizing the native speed, fairness, and finality of the network's underlying hashgraph consensus.
STATE PROOFS ON ENTITIES
State proofs can be requested by querying the network for a record. When a client requests an aspect of the state, nodes can construct and return a small file carrying cryptographic material, and signatures to prove the returned data is the true consensus state.
MIRROR NODE BETA
Hedera's Mirror Node software enters beta and is available for developers to download and configure for use with the Hedera testnet and mainnet.
OPEN REVIEW & OPEN SOURCE
The base layer of the codebase (hashgraph consensus) will be open for public review and made available for anyone to read, recompile, and verify that it is correct. In conjunction, Hedera services and tools will be open-sourced.
We will continue to share our roadmap publicly at https://www.hedera.com/roadmap.