Thank you for your response, Paul. I enjoyed discussing these points with you on Twitter aswell. I’ll write a “counter-counter-FUD” retort here.
On efficiency and fairness
Since the Hedera source code isn’t open to the public, it’s hard to know the exact size in bytes of the overhead other than what can be distilled from the Swirlds whitepaper, so it’s good to have some actual numbers on this, so thanks.
In my article I made a very low estimate of what the overhead in Hedera could be (to be on the safe side), but here you’ve shared that your actual overhead isn’t 64 bytes, but instead 492 bytes.
At 492 bytes overhead necessary for the Hedera consensus algorithm (compared to a transaction size of 150 bytes), this amounts to 328% in overhead. That’s an insanely high number compared to the 1.25% overhead size in bitcoin. The reason why bitcoin (or any DLT) reaches this small overhead is, of course, due to batching many transactions within a block. The larger the block, the smaller the overhead becomes in comparison.
In order to shrink this overhead down to 0.85%, what your example does is it implies batching of ~385 transactions per message (50,000 transactions divided over 13 nodes transmitting 10 messages per second each).
As you’ve described, the Hedera Hashgraph system only provides fairness of ordering for consensus messages, not for transactions within a message. Any node batching 385 transactions can choose which one of those messages came first and which one came last, and they can use this small power they have, for instance, to front-run orders in a stock exchange (see e.g. Flash Boys 2.0), which is one of Hedera’s suggested use cases.
In response to this issue I’ve highlighted (here’s the tweet where I originally remarked on this which led you to type out this long-form response), you talk about two new alternatives:
A) Trust that the Hedera node you transmit your transaction to will order it correctly
(Honestly, what kind of response was this? Hedera has fairness of ordering only if you trust the nodes? Well, bitcoin has fairness of ordering too if you trust the miners…)
B) Transmit your transaction to many nodes
I’m really at loss at how to address this issue. First of all, even if you transmit your transaction to many nodes, what does this mean? It means your transaction will probably make it into the hashgraph in a timely manner if you pay more (duplicating the transaction fees)? But does it guarantee your transaction will be fairly ordered in relation to the other 384 transactions within the batch?
If I submit my transaction to five Hedera nodes, and one of the nodes picks it up first and broadcasts it to the network (unfairly ordered with regard to the other 384), how will it help that the other Hedera nodes also have seen this transaction? The consensus order is still only ordering Hedera messages, and if this node really did find my transaction first and submitted it first (but unfairly ordered to the other 384), this node’s message will still be accepted by the hashgraph.
But even when entertaining the idea that this hack actually works, does this mean the trustless fairness of ordering attribute (which remains one of Hedera’s primary selling points) now depends on non-default client behavior (mentioned nowhere) and at additional costs? Does it mean the Hedera design now gives an advantage to people who can afford to pay more for transaction fees? Also, as you acknowledged on Twitter, this ordering design is entirely external to the consensus algorithm itself and has not been analyzed in any of the Hedera/Swirlds whitepaper materials.
As far as I’m concerned, it’s largely unknown and unproven whether this method actually works as intended or whether it comes with its own other issues, and what exploits this may actually expose an entity choosing to operate for instance a stock exchange ontop of Hedera to.
More broadly, how come I have to dig around in your project to uncover such important things? Why haven’t this been brought up previously? Is this just something you’re coming up with now or has this been addressed publicly anywhere previously? It’s a pretty major and obvious concern. Maybe if Leemon spent less time talking about all the benefits of Hedera and just entertained the idea for a second that there’s some pretty dire trade-offs at play in every design choice, I wouldn’t have to go and write these FUD pieces so these types of truths become understood by the broader public.
In your post you say:
“At Hedera we encourage review, welcome scrutiny, and appreciate feedback”.
Would it be too much to ask for a little scrutiny coming from Hedera’s own side? Or will it always be up to external critics and skeptics to do this?
Let’s continue with the other issues…
Does Hedera sacrifice trustlessness for TPS?
First of all I think the obvious and honest answer to address this question would have been to say “yes” as no matter if you validate receipts or state proofs, this is very different from being able to do full validation of the system and does indeed come with much greater trust assumptions. Hedera state proofs are not “trustless” in any shape or form, they’re the very definition of “trusted” because you don’t actually validate state transitions, you just trust 2/3 nodes to say “yeah this state is totally legit” with no in-protocol punishments or disincentives for lying.
But even if you did acknowledge that you sacrifice trustlessness for TPS, this wouldn’t even be the whole story. You sacrifice more than that; in your TPS figure, you don’t even count transactions that interact with smart contracts, which was one of the major points I brought up in my FUD piece. Hedera is supposedly a system built for applications, yet you cite only these figures for dumb account-to-account token transfer, and yet you still juxtapose these figures compared to Ethereum?
You did acknowledge that the smart contract TPS is “much less” in your Twitter responses though (for readers who are able to decode them). Again — why, why can’t these very important details be very visibly shared? It’s a huge deal. You should have made this very clear in your TPS figures. You can’t write “10,000+ TPS” and put a little disclaimer under it saying “cryptocurrency transactions” and hope that everyone figures out which restrictions that implies by reading through your 100-page whitepaper. But I guess it will become clear to everyone at launch (after you’ve raised funds at a $6bn valuation…).
But let’s get back to the specifics.
The real important thing that readers will want to know having read my FUD piece and your counter-FUD is what to make of this whole “receipts” situation. I’ve described how your figures were based on receipts, you’ve stated that you can also provide state proofs. So now what? If you read my article, there’s almost a whole chapter on state proofs and how they work, so there’s no confusion to be had here; yes, Hedera can provide state proofs (or well, state commitments to be correct).
But state proofs costs a lot of resources to generate; so much that users actually have to pay to receive them. And you mention that producing these state proofs for 10,000+ TPS would require more resources than processing the transactions themselves, so it’s not a minor thing we’re discussing. Your explanation here is that Hedera users don’t need to concern themselves over this too much because of mirror nodes. Mirror nodes are nodes that process the entire hashgraph and thus can produce these state proofs equally to the Hedera nodes and feed them to interested users, so the load doesn’t have to be on the Hedera nodes and doesn’t have to decrease the 10,000+ TPS. This is a valid point that I definitely concede to and also had in mind when I wrote my FUD piece.
But it’s not really that simple. If it was that simple, the Hedera TPS figures would have mentioned state proofs instead of just transaction receipts. Mirror nodes serving the public with 10,000 records + state proofs per second is a fantasy scenario that depends on good samaritans supporting the network that you’ve provided no incentive model for. Processing 10,000 transactions within a small network of 39 Hedera nodes is one thing; making these 10,000 transactions accessible to mirror nodes on a global scale with state proofs generated for each one? A completely different topic. You also acknowledge this in your tweet here (“performance curves are not end-to-end”).
Let’s be real for a second with all of this and let me express what isn’t being said here. The “solution” to the 10,000+ state proofs per second is not that there’ll be a giant altruistic infrastructure serving the public via mirror nodes. The solution you have in mind is that not everyone will be requesting the state proofs — they’ll just blindly trust the Hedera network. That’s your real solution, and that’s why you use the receipts benchmark in your TPS figure, isn’t it?
And that was it! Thanks for reading.
Update: Oh shoot, I forgot to respond re:
“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.”
Noted, I never addressed this. But I do find this security mechanism to be so questionable I wonder if it’s even worth bringing up? If Hedera Hashgraph catches on, do you really think there won’t be hbar derivatives markets where validators can easily hedge away their hbar exposure with the click of a button? Nope, I don’t think you can count on this improving security— and neither should Hedera (instead, I find it rather worrying that you don’t immediately see this).
