this means cycles are not possible so it results in a directed acyclic graph (DAG).Let's dig a bit deeper into the consensus algorithms and see what are the bottlenecks for each approach:- Radix HotStuff does 3 voting rounds where the leader transmits message to all the validators and they have to respond. Keep in mind that the responses can happen in parallel so it's still pretty fast but the bottleneck here is the leader which needs to process and send all those messages. I'm still waiting for Dan to publish his whitepaper in order to find out how he implemented the leaderless approach in Cassandra.- HBAR gossip process is sequential, this means that instead of each node sending the signature to the leader, he sends it to the next validator node. You don't have the leader bottleneck problem, but you run into scaling problems. Since there is no explicit voting, Hashgraph must ensure that the honest majority of nodes have finalized a transaction before allowing it to be exposed to clients, otherwise, a transaction that conflicts (double spend) can propagate and there is no point. This means that as the Hashgraph node count increases, latency and throughput decreases. In simpler terms, Hashgraph seems to be at optimal performance around 100 nodes. Afterwards, performance begins to decline. That's why Hedera network is a small number of nodes operated by Governing Council Members, all in a single shard.Both consensus algorithms are good in their own way, without any clear benchmark comparison between the two, there is no winner because each has its own different bottlenecks.In a small environment with < 100 honest nodes, HBAR seems faster but also keep in mind that Hashgraph's consensus only handles timestamps and does not execute any smart contract logic.Sharding. Sharding will enable huge amounts of TPS for both projects. There's not much info on HBAR's exact sharding approach but from what I gathered their shards will communicate through the exchange of messages between nodes of the different shards. The nodes in each shard will maintain a queue of outgoing messages to each of the other shards. Each shard will remember the sequence number of the last message it processed from each of the other shards. So it's still like their gossip mechanism but between shards but it gets more complicated because you have to synchronize timestamps across shards which is not an easy feat. They need to have a messaging system that the other shards processed and included the transaction from the current shard and vice versa.Radix on the other hand does not need to syncronize timestamps across shards because of its unique sharding design. Unrelated transactions don't need to be synchronized. They just need to merge together (braid) the results of the voting rounds in each shard when doing cross shard transactions. Radix has the edge here because they don't really care about timestamp but about the order of the transactions so that they avoid double spending.Because Hedera separated their consensus from smart contracts, they have to work only with block timestamps. While their approach makes things really simple for the consensus and provides a nice TPS boost in a single shard environment but it could have drawbacks when they need to synchronize across shards.One thing that is overlooked on how radix works is the advantage of not having to order transactions. Based on the coffee shop #AMA example, if there are millions of coffee buyers that only make deposit operations to the coffee shop account (not withdrawals) then these deposits don't need to wait for a previous deposit to finish as they have no dependencies on each other. Transactions need waiting on radix only on the withdrawal side. All these transactions can work in parallel unlike on HBAR where they need to be sorted based on timestamps.There's also the topic about atomic composability. From my understanding of how hedera sharding will work, it will indeed have some sort of atomic composability on the consensus level because shards will wait until for messages from the other shard before finalizing the transaction timestamps but I have no idea how they synchronize the results across mirror nodes that will execute the smart contract transaction so that if one transaction fails, the other mirror node transaction should also fail. I don't think they have this synchronization across mirror nodes so they won't have atomic composability across smart contracts.I will give this point to radix as they already have a working prototype for sharding, their Cerberus cross-shard consensus is well documented and cross shards smart contract transactions are supported natively. On HBAR side I only found details in their whitepaper and some videos that didn't describe the process in depth I also didn't find details if they also shard the smart contract execution (which is an important part imo).Finality. According to https://twitter.com/fuserleer/status/1452223162268147722 Radix finality will be around 12 seconds cross shard and ~3 seconds intra shard. HBAR transactions achieve finality, on-ledger, within three to five seconds in the current single shard finality, couldn't find details about cross-shard.Security and liveness.I saw that HBAR coined the term aBFT (asynchronous byzantine fault tolerant) which means that instead of having a maximum threshold of message latency when coming to a consensus the network eliminates this assumption and allows for some messages to be lost or indefinitely delayed. In more simple terms, on blockchain, you can't start mining a new block before you know about the previously mined block. If you do mine block and reference the block before the last, there is high chance that your block gets orphaned because others grow the other chain faster than you. This makes it synchronous. The HBAR consensus only cares about timestamps and not about executing transactions that's why their consensus doesn't need to wait for old blocks to finish before processing new ones because everything can be ordered based on timestamp. The mirror node will however have to wait and execute the transactions in order - so there is still waiting just not on the consensus part." title="Anyone in the mood to debunk Hedera criticism?">full image - Repost: Anyone in the mood to debunk Hedera criticism? (from Reddit.com, Anyone in the mood to debunk Hedera criticism?)
Mining:
Exchanges:
Donations:
Hey, I found this post on the Radix subreddit. It was comparing and Hedera and Radix. I tried debunking it myself however I found myself stuck with especially: how does the mainnet deal with corrupted shards and how does an increase in shards affect performance (point 7). Feel free to tackle the other points aswell!We can compare the projects but keep in mind that they target a completely different public than radix. I'm biased because I like the tech behind radix but I'll try to make the comparison as impartial as I can. Both are good investments but with different usage so let's take it step by step.1.Smart contracts. 1 point for radix in this category because of how safe & easy to use is Scrypto. Radix could've gone the same way as hedera and add fast Solidity support just to attract developers, but they chose the hard way. 2.2.Tokenomics. Both are kind of bad so it's equal. From what I read, HBAR has 30% public and the rest is privately owned. Radix has similar problems with people (CGs) that supported Dan with their bitcoins for the last 8 years while he did his R&D and have millions of XRD. I would put them as equal here. It depends on you if you like to get rugpulled by private companies or early supporters.3.Marketing. Clear point to hbar as it is available on more exchanges, gets shilled on tik tok and youtube more than radix.4.Potential for growth. HBAR market cap is 3 times the size of radix, so not much of a difference here. Both coins could boom in the next bull run. Keep in mind that during bull runs marketing is important because it creates hype.Projects. Since radix doesn't have smart contracts yet, HBAR has the upper hand here. Developer activity is trending upwards on HBAR with an average of 6,000 developer events per month but I believe radix will soon catch up with the Babylon release.5.Decentralization. Both radix and hbar right now are kind of centralized. The only difference is that in the future radix promises to be truly decentralized where even someone with an ordinary pc can participate, while hbar is permissioned and their consensus may or may not become decentralized in the future. The node requirement for Hedera is pretty insane ((https://ift.tt/qxOvywh) and similar to Solana requirements. Also, hbar patented their tech while radix will publish their source code on gitlab once it is done (bonus point for radix here as a developer). On this decentralization topic we also need to dig a bit deeper into how hbar works to understand why it will never be truly decentralized. Their consensus mechanism is separated from smart contracts completely. The execution pipeline for hbar looks something like this:Receive transactions from clientsDistribute transactions amongst network nodesPlace transactions into orderExecute transactions in the order of #3Store the new state created by the transactionsRespond to clients with the result of transaction executionMonitor for discrepanciesTheir Hedera Consensus Service (HCS) uses a model where only Step #3 happens on the public Hedera DLT, the rest of the steps are executed by what they call a Mirror Node. Unlike hbar, for most of the crypto techs out there (radix included), each node - miners and non-miners - must execute the software - the contract. That's what makes them truly decentralized. HBAR separated their consensus from smart contract execution so that their consensus can be super fast (just establish a general timeline for blocks) which is super smart and elegant, but sacrifices decentralization for speed and efficiency. They only need to store on their DLT the time of the block and validator node signatures. This is the reason why hbar targets companies, because they want the privacy and efficiency of a small network (mirror node), but the trust and security of a large public network (their consensus).I'm a fan of the truly decentralized thinking and imo this point goes to radix. We have to be aware that HBAR is not targeting people like me, they are going for large companies that seek this kind of privacy/centralization while marketing their solution as "decentralized" for the public.Let's just hope that HBAR will not turn into something like this scene from Mr. Robot https://youtu.be/1ee-cHbCI0s?t=296.Consensus. At a first glance, HBAR consensus is clearly faster because it doesn't have to do the HotStuff voting process that radix does, it only has to make sure that a block is processed by a majority of nodes and they agree on a timestamp. Really simple. How do you do it? Just make each node forward the block with his signature to another random node and that's it. When a node receives a block he knows which nodes validated that block so he only forwards it to ones that are not part of the signature => this means cycles are not possible so it results in a directed acyclic graph (DAG).Let's dig a bit deeper into the consensus algorithms and see what are the bottlenecks for each approach:- Radix HotStuff does 3 voting rounds where the leader transmits message to all the validators and they have to respond. Keep in mind that the responses can happen in parallel so it's still pretty fast but the bottleneck here is the leader which needs to process and send all those messages. I'm still waiting for Dan to publish his whitepaper in order to find out how he implemented the leaderless approach in Cassandra.- HBAR gossip process is sequential, this means that instead of each node sending the signature to the leader, he sends it to the next validator node. You don't have the leader bottleneck problem, but you run into scaling problems. Since there is no explicit voting, Hashgraph must ensure that the honest majority of nodes have finalized a transaction before allowing it to be exposed to clients, otherwise, a transaction that conflicts (double spend) can propagate and there is no point. This means that as the Hashgraph node count increases, latency and throughput decreases. In simpler terms, Hashgraph seems to be at optimal performance around 100 nodes. Afterwards, performance begins to decline. That's why Hedera network is a small number of nodes operated by Governing Council Members, all in a single shard.Both consensus algorithms are good in their own way, without any clear benchmark comparison between the two, there is no winner because each has its own different bottlenecks.In a small environment with < 100 honest nodes, HBAR seems faster but also keep in mind that Hashgraph's consensus only handles timestamps and does not execute any smart contract logic.Sharding. Sharding will enable huge amounts of TPS for both projects. There's not much info on HBAR's exact sharding approach but from what I gathered their shards will communicate through the exchange of messages between nodes of the different shards. The nodes in each shard will maintain a queue of outgoing messages to each of the other shards. Each shard will remember the sequence number of the last message it processed from each of the other shards. So it's still like their gossip mechanism but between shards but it gets more complicated because you have to synchronize timestamps across shards which is not an easy feat. They need to have a messaging system that the other shards processed and included the transaction from the current shard and vice versa.Radix on the other hand does not need to syncronize timestamps across shards because of its unique sharding design. Unrelated transactions don't need to be synchronized. They just need to merge together (braid) the results of the voting rounds in each shard when doing cross shard transactions. Radix has the edge here because they don't really care about timestamp but about the order of the transactions so that they avoid double spending.Because Hedera separated their consensus from smart contracts, they have to work only with block timestamps. While their approach makes things really simple for the consensus and provides a nice TPS boost in a single shard environment but it could have drawbacks when they need to synchronize across shards.One thing that is overlooked on how radix works is the advantage of not having to order transactions. Based on the coffee shop #AMA example, if there are millions of coffee buyers that only make deposit operations to the coffee shop account (not withdrawals) then these deposits don't need to wait for a previous deposit to finish as they have no dependencies on each other. Transactions need waiting on radix only on the withdrawal side. All these transactions can work in parallel unlike on HBAR where they need to be sorted based on timestamps.There's also the topic about atomic composability. From my understanding of how hedera sharding will work, it will indeed have some sort of atomic composability on the consensus level because shards will wait until for messages from the other shard before finalizing the transaction timestamps but I have no idea how they synchronize the results across mirror nodes that will execute the smart contract transaction so that if one transaction fails, the other mirror node transaction should also fail. I don't think they have this synchronization across mirror nodes so they won't have atomic composability across smart contracts.I will give this point to radix as they already have a working prototype for sharding, their Cerberus cross-shard consensus is well documented and cross shards smart contract transactions are supported natively. On HBAR side I only found details in their whitepaper and some videos that didn't describe the process in depth I also didn't find details if they also shard the smart contract execution (which is an important part imo).Finality. According to https://twitter.com/fuserleer/status/1452223162268147722 Radix finality will be around 12 seconds cross shard and ~3 seconds intra shard. HBAR transactions achieve finality, on-ledger, within three to five seconds in the current single shard finality, couldn't find details about cross-shard.Security and liveness.I saw that HBAR coined the term aBFT (asynchronous byzantine fault tolerant) which means that instead of having a maximum threshold of message latency when coming to a consensus the network eliminates this assumption and allows for some messages to be lost or indefinitely delayed. In more simple terms, on blockchain, you can't start mining a new block before you know about the previously mined block. If you do mine block and reference the block before the last, there is high chance that your block gets orphaned because others grow the other chain faster than you. This makes it synchronous. The HBAR consensus only cares about timestamps and not about executing transactions that's why their consensus doesn't need to wait for old blocks to finish before processing new ones because everything can be ordered based on timestamp. The mirror node will however have to wait and execute the transactions in order - so there is still waiting just not on the consensus part.
Social Media Icons