Hi, I have some technical questions I was hoping the community would be interested in and be able to answer. I’ve searched around the subreddit and not seen anything that I think satisfies them but my apologies if I’ve missed those posts. Also, I will get some things wrong. This is a new technology to me and I'm still learning.
1. Ledger size, node requirements and inclusive accountability
There's a lot of focus on TPS and it's one of the key competitive advantages of Hedera. The thing is, TPS are only one side of the coin. The transaction throughput has never really been the bottleneck for blockchains. It's remaining decentralized with all that data. Take BSV for example, a low-tech offshoot of Bitcoin that for the most part just increases the block size. I think they're doing around 9,000TPS at the moment. This of course increases the size of the ledger, increases the requirements of a full node and centralizes the network. So what are the requirements of a full node in the future for Hedera? I've found this spec for the current nodes. But this is just the current spec. A question regarding future requirements has been asked here. The solution that Hedera is employing is to use signed state described in section 7.2 of the whitepaper. The nodes essentially sign and delete the immutable past. This is not a new idea, it has been part of the blocksize debate. By having a full node store the entire ledger we get what's called inclusive accountability. This essentially means someone joining the network can verify the ledger from genesis all the way through to the current state. Without it one must trust that the live network is honest. So losing inclusive accountability is a tradeoff. Now, Hedera have proposed mirror nodes that will have a full history of the ledger. But you run into the same problem, the mirror nodes require specialized hardware which centralizes the network.
So what are the expected requirements of Hedera nodes in the future? This is a critical specification for a decentralized network.
If we accept that inclusive accountability is not necessary, nothing stops a standard blockchain from using the same approach - dynamically deleting the immutable data to keep the ledger a reasonable size. We already have blockchains with extremely high TPS but they are largely ignored because people understand these tradeoffs.
2. Scalability and sharding
This leads into another point about hashgraph which is its approach to scaling. As more nodes are added to a single shard performance drops off rapidly compared to blockchains. So if there were 1000 nodes we may split that into 10 shards with 100 nodes in each. (There will be some optimum node count per shard but just as an example). Here is Leemon describing sharding for those interested. The security of the entire network is then only as secure as the weakest shard. Each shard must trust the security of the shard it receives a message from.
This is one aspect I'm assuming I have wrong. Is our proof-of-stake system now fractioned into how many shards we have? Meaning a network with 10 shards could be compromised with 34% -> 3.4% of the tokens?
Anyway, I come back to a similar point I made above. Sharding is not a technique exclusive to hashgraph. Blockchains are using this to scale. Does hashgraph scale more efficiently through sharding than a blockchain can? If they follow similar principles then really we should compare a single-sharded blockchain to a single-sharded hashgraph network when making comparisons?
3. Competitive advantages and tradeoffs
I don't want this to sound all negative. I'm surprised that Leemon didn't bring up fairness when he talked about competitive advantages. The ordering of events and its potential to solve many of the issues with MEV (miner extractable value) seems really promising. Hedera also claims pretty amazing latency/finality.
I just think that there's almost always tradeoffs with these technologies and I want to better understand where they might exist here. Apologies for anything I got wrong or if I'm rehashing points that have been clearly explained elsewhere.
No comments:
Post a Comment