At Hedera we encourage review, welcome scrutiny, and appreciate feedback, as it often highlights technical questions that we are happy to address head on. While many in the community have asked us to engage on Twitter (and we have) to a popular, self-titled “FUD” piece on Medium written by a crypto influencer, Twitter is not the right venue for deep analysis of these difficult concepts. We will always lean towards providing the community with comprehensive explanations, especially of technical concepts. These explanations rarely fit into 280 characters.

For those of us immersed in hashgraph it is important to acknowledge that for those with a lot of experience with blockchain-based technologies, many of the characteristics of hashgraph consensus don't fit squarely into that frame of reference.

Is hashgraph inefficient in bandwidth overhead?

In hashgraph, transactions are bundled into a container event by nodes along with two hashes, a timestamp, and a signature. The hashes, timestamp, and signature are consequently overhead to the fundamental payload of the transactions.

For the current Hedera network, the two additional hashes are each 48 bytes, the timestamp 12 bytes, and the signature 384 bytes. Consequently, the overhead is 492 bytes. For comparison, a simple hbar transfer transaction is approximately 150 bytes.

The relative size of the overhead to the payload will then depend on how many transactions are in each event. This average value will depend on the throughput the network is supporting, how many nodes there are, and how many events per second the nodes are creating.

As a representative calculation, for 50k transactions per second (tps), 13 nodes, and 10 events/sec, the bandwidth overhead is

492 / (492 + (50,000 x 150)/(13 x 10)) = 0.85%

At higher tps, the percentage overhead is proportionally smaller as there will be more payload transactions in each event.

It would be bad if overhead increased with throughput, as that would imply that as the network’s bandwidth pipe filled up with transactions, then the contribution of the overhead would cause the pipe to back up and overflow (queued transactions). For Hedera, as the transactions fill up the pipe, the contribution of the fixed event overhead becomes neglible.

Of course, at lower tps, the percentage overhead contribution will be larger as there would be fewer transactions in each event.

But is this a problem? Overhead becomes an issue only when it limits the network’s ability to process transactions into consensus. But, at low tps, the network’s capacity is mostly untouched.

There are ways we could minimize the above stated overhead. As the Swirlds whitepaper discusses, the hashes could be replaced with a smaller index. Additionally, the timestamp and signature could be smaller. Perhaps we will explore such optimizations in the future. But for the moment, it’s not important.

Does Hedera provide fair ordering?

The hashgraph algorithm fairly orders the events that contain transactions – the order is fair because no leader (even for a short period) unilaterally decides which events come before others. Instead the network as a whole calculates this order – the result reflecting the weighted contribution of all the nodes.

But, if events carry multiple transactions (as discussed above) then what of the order of the transactions within an event? Is that fair?

It is true that nodes control the order of transactions they receive from clients and add to the events they create. A bad node could preferentially place transactions from Alice to the front of events, and those from Bob to the end of the event. With nodes creating multiple events each sec, the resulting difference in timestamps between Alice’s and Bob’s transactions would be small but nevertheless could be important in markets and auctions where order matters more than absolute time.

Critically, Bob has defenses against such a bad node.

Unlike in blockchains, where a client has no control over which miner/validator/BP it is that creates the block in which their transactions are eventually placed, in hashgraph the client has this control. If Bob is worried that a node is unfairly ordering his transactions (based on experience or reputation), Bob can avoid that node and send his transactions elsewhere.

Or Bob can send his transactions to multiple nodes (paying for the duplication). The copies of his transactions will effectively race to be assigned a place in consensus order. Only the first will be placed, the others rejected. Even if a node unfairly delays (or even censors) one of the copies, another will receive a fair time.

In these ways, Bob can be confident both that the events inside which his transactions are bundled receive a fair order from the network, and that his transactions within those events receive a fair ordering.

Does Hedera sacrifice trustlessness for TPS?

Hedera’s transaction model is, at a high level, as follows:

1. Client submits a transaction to a node
2. Node performs precheck on transaction before bundling with other transactions into an event
3. Node gossips event to network
4. Network determines consensus timestamp and order for transaction(s)
5. Network applies transaction to state in consensus order
6. Seconds later, client queries (the same or a different) node for confirmation of transaction
7. Client proceeds based on response of #6

The latency and throughput of Step 5 will vary for different transaction types, meaning an hbar transfer will be faster than executing a smart contract call. When Hedera cites throughput of 10k or higher, we are referring to the former and not the latter. Every DLT makes choices about what transaction type to optimize for and we are optimized for fast crypto transactions (and fast consensus ordering via the Consensus Service).

There are three variations in step 6, each differing in their detail, their cost, and the trust model between the client and the node.

1. The client can ask the node for a receipt for the transaction. Receipts are minimal in the information they provide, are free to the client and presume that the client trusts the node in question as a bad node can modify the receipt.
2. The client can ask the node for a record for the transaction. Records provide more information than a receipt, are not free, and also presume trust between client and node.
3. The client can, when asking for a record, stipulate it desires a state proof as well. This combination of record + state proof is trustless – the client need not trust the node in question as the state proof logically comes from the network as a whole. Whatever particular node returns the record cannot modify the record without that change being detectable via the proof. You can read more about state proofs here.

Note: the Medium author conflates the above options for query responses with the Consensus Service – which is a separate and distinct service in which off-ledger application networks can have their transactions timestamped and ordered by Hedera – with consequent states maintained locally. But we’ll put that aside for now.

Hedera predicts that we will support 10k cryptocurrency transactions per second (tps) at our Open Access on September 16.

The Medium author objects to the qualification that the above 10k tps is contingent on clients asking for receipts for those crypto transaction and not the ‘heavier’ but trustless state proof option. If a state proof is requested for each and every transaction (rather than the lighter receipt) then a greater portion of the network’s resources will be expended responding to queries than in processing the transactions into consensus and the overall throughput may be decreased.

For both receipts and records, a client can ask multiple nodes and so gain confidence in the response(s) if they agree and so obtain some measure of trustlessness.

It is the potential negative impact of node’s responding to queries (with either records or state proofs) on the more fundamental job of processing transactions into consensus state that motivates the mirror network. The mirror network offloads from the mainnet nodes the burden of responding to queries, allowing those nodes to focus exclusively on consensus. Mirrors (once out of alpha) will calculate consensus timestamps and create state proofs, and so be able to provide to clients the trustless state proof option without impacting the throughput of the mainnet.

Users will be able to run their own mirror node if they seek direct participation in consensus and the corresponding trustless certainty. Additionally, there can be many thousands of mirror nodes – allowing the burden of supporting the creation and return of state proofs to clients to be distributed across many mirrors.

Not everyone who submits a Bitcoin transaction will download the chain. Similarly, not everyone who sends hbars will ask for a state proof. Similar to how Bitcoin supports different trust models (and associated burden), we believe clients should be able to choose a confirmation mechanism with the right combination of detail, cost, and trust model for transactions of different sensitivity and value.

Is slashing a requirement of Proof of Stake?

Hedera will use a node’s hbar balance (as well as any hbars proxied to the node from other accounts) to weight the node’s votes in the hashgraph algorithm. With Hedera, there is no risk to a node of losing those hbars for breaking the rules of consensus – this potential for punitive loss of coins sometimes referred to as ‘slashing’.

Because there is no slashing in Hedera, there is no need for the hbars to be locked up or bonded in anticipation of future slashing. Nodes (and accounts that proxy to a node) can spend their hbars at any time – there is no loss of liquidity associated with our staking.

For some, this model is not Proof of Stake (PoS) as for them slashing is a necessary component. Hedera is not the only public DLT that describes itself as Proof of Stake but does not implement slashing conditions. Admittedly, we’ve ourselves struggled with this issue and at one point considered attempting to coin an alternative descriptor such as ‘Proof of Equity’ or similar. In the end, we decided to use PoS but explain our differences.

But putting aside terminology, it seems that the more fundamental objection is that, in the absence of on-chain punishment of bad behavior, the only recourse against such is the legal system.

This ignores the inherent protection of a stake-weighted consensus – that an attack presumes a significant aggregation of the coin, the value of which will likely be damaged by an attack.

But, to the more fundamental issue of reliance raised, we fully accept that Hedera exists within and not outside of legal and regulatory frameworks. For our enterprise customers, this is a feature, not a bug. We acknowledge that this is undesirable to many in the crypto community – we are fine with that.

Summary

We appreciate the Medium author’s in-depth analysis, critiques, and questions. Hopefully, we have clarified some of those questions. We fully acknowledge that our consensus algorithm, architecture, and governance is very different from Bitcoin and other DLTs, and we believe there is room in the ecosystem for many successful technologies to meet different customer needs.

Please continue to engage with us via our official Twitter handle (@hashgraph) or on Discord for any follow-up questions and check out the materials on our website for more information about Hedera Hashgraph.