Casper vs Hedera

Hedera Hashgraph launched in 2018 with a unique hashgraph consensus mechanism which is unlike standard blockchain technology. The project has been marketed as ‘enterprise grade’ with a governing council of many well known, large and respected industry giants across a large variety of sectors.

We shall review the Hashgraph consensus mechanism, drawing parallels with existing blockchain technologies and noting how the mechanism is akin to a standard blockchain but with a layer 2 implementation of global time (such as is the case with Solana). Because of this, we can note the greater node requirements to operate as a validator on the network which then introduces similar load risks we have recently seen on the Solana network.

We shall discuss how HBARs enterprise strategy is different to that of Casper’s, where the offering is to provide a public ledger where existing permissioned blockchains can send hashes of transactions (without sharing confidential content), in order to increase auditability.

Finally, we shall note a few properties of the Governing council, question how truly decentralized this makes Hedera and also plot from interesting price metrics between HBAR and CSPR.

As we have extensively covered CSPR in our previous articles, we shall focus on first providing insights into Hedera and their consensus protocol before moving to the comparison and concluding with a summary. We recommend first reading our deep-dive of the CSPR token here.

Background

The Hashgraph distributed consensus algorithm was invented by Dr. Leeman Baird (the Hedera Cofounder and chief scientist). The other co-founder is Mance Harman who is currently the CEO, covering operations and management.

2012: Work began by Dr. Baird in researching consensus

2016: The Hashgraph whitepaper is published on May 31.

2017:

• Seed rounds were conducted
• The Hashgraph Consortium was created as a Delaware limited liability company
• Technology was displayed publicly at TechCrunch Disrupt in San Francisco
• First letters of intent are signed by potential council members

2018: Mainnet goes live with 50 billion HBAR tokens minted

2019: First meeting of Governing Council

Hashgraph Consensus

In a blockchain, information is stored in blocks in a linear fashion where each block (excluding the current and genesis block) will have a single predecessor and single following block. This creates a single chain of blocks (as can be seen to the left of the illustration below). There are variations or branches of the chain, whereby a consensus will agree upon as to which branch to continue as the primary chain. Any user can create a transaction which will be placed into a block. If two blocks are created at the same time, the network validators will choose one chain to continue and discard the other (ignoring forks for now).

For a hashgraph (as depicted to the right of the image below), every ‘block’ of transactions is incorporated into the ledger (nothing is discarded). All branches continue to exist forever and are effectively woven together.

We can then say that in hashgraph, operations are recorded not via the chain (like in a blockchain), but via a directed acyclic graph (DAG). It is based on an asynchronous Byzantine-Fault Tolerance (aBFT) consensus. In this protocol, the network keeps honest consensus (as long as less than 1/3 of the nodes are malicious).

To explain the protocol, let us consider 8 users on the network. Alice has a transaction she wanted to send.

1. She puts this inside of a message and then sends it out to a random person (David, in the example below).
2. That random person then in turn sends it to another random person (David to Bob). In addition, Alice can also send to another random person (Gina)
3. Very quickly the message is shared with all actors on the network.

We can also consider how new messages are then added to this network via other participants. In the below chart, two new messages are highlighted with the blue and green colouring:

Now that we understand how messages propagate through the network via the ‘Gossip’ mechanism, let’s now consider how we capture message timings in the protocol. This is simply done by logging when each individual received each of the messages (red/blue/green) and then take the average time for each, eg. if we order all of the times the red message was received and then take the middle time, then do this for green and blue and then using the middle times we can then order the red, blue and green messages to know which is first, second and third. This timestamp is known as the consensus timestamp.

In terms of knowledge of when each individual received a message, this is done via the below chart where each message is conveyed by a line from one participant to another. Time evolves upwards in the chart where the very first message from Alice to Dave is the red line originating from the bottom left of the chart.

Create a message for every circle in the graph that contains:

• Transactions: What you want to include
• Timestamp: When you are ‘claiming’ you have created it
• Digital signature of participant
• 2x Cryptographic Hashes:
  • Last message you made
  • Last message you received

The above graph is stored on memory on all the computers. This is the ‘gossip about gossip’ feature which is often referred to in Hedera online materials. Its the sharing of the chart, where the chart denotes the gossip, and the sharing of the chart denotes gossiping about gossip. The sharing of the chart means no additional messages are required to track timings (which is often what where a lot of the load in blockchain networks stems from). This is the concept of virtual voting.

Open Source / Open Review

The code running on the Hedera mainnet consists of two components: platform and services. The platform code includes the gossip and consensus protocol code, and the various libraries that are used by the services code.

Unlike the majority of blockchains, the Hedera Hashgraph platform is not open sourced. It is instead ‘open review’. In Open Review, the code is available only for reviewing, compiling, and testing, but not for any other use. In Open Source, the code is also available for broad use (not limited to reviewing and testing).

Open source, means that source code is made freely available to the public. Typically you would expect the source code for a blockchain to be available on GitHub, where developers will have the ability to branch or modify.

What makes open source so important for blockchain? At a glance, you may worry that it would make the technology vulnerable, but in reality, the open source nature helps to protect it and maintain that all-important transparency.

One of the core philosophies behind anything open source is the efficiencies that can be gained. When you allow others into the technology, you can exponentially boost the potential applications available and the spread of the technology.

The business world collectively gasped when Elon Musk announced that Tesla was opening up its patents in “good faith” to anyone who wanted to use them. Why would he do such a thing? One argument is altruism – a desire to share in the spirit of open source, but there can also be more pragmatic reasons. Some believe that by opening up the technology for electric cars to more players, Musk was ensuring the proliferation of the technology.

The arguments that Hedera have put for this is “This difference is part of our commitment to those building on the Hedera ledger, that this ledger will be stable, without forking or splitting”

Validator Nodes

Requirements for running a validator node on the HBAR network:

• Dual Power – 1600W minimum, 2000W recommended
• 48-core or better CPU
• 256 GB PC4-21300 2666MHz DDR4 ECC Registered DIMM

consideration for future expansion:

• Chassis must be Nvidia Tesla V100 PCIe certified
• 1x Nvidia Tesla V100 PCIe 16GB GPU

Enterprise Focus

HBAR is heavily advertised as being the “enterprise grade blockchain”. Enterprise-grade being described as where products can integrate into infrastructure with minimal complexity and offer transparent proxy support. So what does this actually mean? (Read more about enterprise blockchains here).

A private blockchain provides a means to control the logic and sharing of information within a set of known as authorized parties. Outside of Casper, existing private blockchain frameworks, such as Corda, Hyperledger Fabric, and Quorum can connect to Hedera to achieve decentralized trust without exposing its content. Thus using Hedera Consensus Service, for each update of the permissioned blockchain, a transaction hash is sent to the Hedera public ledger. This now immutable transaction hash ensures transaction information remains private while being fully auditable by authorized parties.

Put in another way:

Transactions on Hedera are immutable and verifiable. Permissioned blockchains can integrate Hedera, sending hashes of transactions to the public ledger for enhanced auditability. The offer is that Hedera won’t slow down your permissioned network, achieving thousands of transactions per second with finality in seconds.

https://hedera.com/use-cases/permissioned-blockchain

Governing Council

The Hedera Governing Council consists of up to 39 term-limited and highly diversified organizations and enterprises, reflecting up to 11 unique sectors, academia, and non-profits globally. Council members are committed to governing software changes, whilst bringing stability and continued decentralization to the public network.

In addition to charting the path for the platform and public network. They will also be responsible for:

• Hosting and maintaining initial network nodes
• Establishing a governance framework
• overseeing the software run by 100’s thousands of nodes at scale
• Overall direction of the hedera platforms codebase

Comparison with CSPR

• Network nodes:
  • HBAR currently requires 256GB of RAM with the intent for this to be
  • CSPR nodes are required to have 32 GB of RAM.
  • The HBAR node requirements are akin to that of Solana – as both tackle the concept of global time. HBAR have taken this one step further than Solana by not only having the concept of global time, but also requiring that the full Hashgraph be communicated and stored across nodes.
• Decentralization:
  • The Hedera council are initially responsible for the setting up and running of network nodes.
  • The Casper maintain launch was only 6 month prior to the time of writing this article, however all 100 community validator slots have been taken and is exhibiting good levels of decentralization at this early stage.
  • Arguments put by HBAR for the lack of decentralization are that the affective decentralization for both Bitcoin and Ether is notably less than the sum of nodes due to the colluding nature and miner pooling which is inherent in those networks. I shall argue in the conclusion why I don’t believe this is a apt comparison.
• Throughput:
  • Hedera can operate in the region of 10k+ TPS
  • This compares with CSPR which is currently achieving 2.5k transactions per block (100 WASM deploys per block)
  • We should note Casper is achieving their TPS by utilizing only 100 low power validator nodes (with a possible increase of x5 throughput being tested at present). HBAR utilizes GPU grade validators with the concept of global time and virtual voting to achieve their high TPS. As this is not part of its security consensus protocol, but a mechanism to simply increase throughput, it can be considered in the same way as many sharding methodologies being researched currently. As we are aware (from the final section of our sharing article here), CSPR is currently researching a proposal on how to multi thread (parallel processing) transactions. To summarize the proposal: CSPR Sharing – Transactions will list all spaces in memory (shards) which they require and each block is given a limited amount of sequential computation time. When a block includes a bunch of transactions instead of specifying a transaction order, it specifies a computation schedule. This schedule uses times from 0 to t where t is our bound on sequential compute time. Each transaction is assigned a sub-interval of this window with the length of the sub-interval given by the computation bound specified by the transaction. Furthermore, the intervals for any two transactions that share a shard are not allowed to overlap. Distinctions could also be made between reads to a shard and writes to a shard and allow several transactions to simultaneously read from the same shard so long as none write to it.
• Security:
  • The security and finality of the CSPR network has been covered in these two articles: CBC and Highway. From the articles its clear that CSPR is a powerful non-statistical method to guarantee security and finality given a threshold of malicious nodes.
  • For HBAR, security is achieved via asynchronous Byzantine-Fault Tolerance (aBFT) consensus
• Predictable fees:
  • Hedera’s fee schedule is set by the Hedera Governing Council and always based in USD — making it easy to estimate and control future costs.
  • Casper are introducing a ‘Gas Futures Market’ where the fee can be locked in, thus providing enterprise with the degree of certainty they desire.
• Enterprise adoption:
  • The Hedera network offers a public blockchain which EXISITING private blockchains can send transaction hashes to in order to increase auditability.
  • The Casper enterprise adoption strategy is one of the strongest in the market at present where the team have not boxed themselves into a niche business but instead have a wide ranging enterprise strategy targeting all potential markets. This is in addition to the public side chain. Casper will offer not only the public blockchain, but also the architecture for private enterprise blockchains.
• Future Proof:
  • The design and engineering of CSPR ensures it is a fully future proof blockchain. It has achieved this by ensuring all components (Execution Engine, Network Engine, Consensus Layer) are pluggable. This allowed the blockchain to be upgraded with relative ease.
  • The HBAR design is such that it aims to scale with increased network bandwidth capabilities in the future.

Price Comparisons

Both CSPR and HBAR experienced quite aggressive selling pressure immediately post launch date. The CSPR selling was exacerbated by a more generic pullback in the market (read not newly issued tokens are exposed to greater price volatility here).

One driving factor for the sell-off was the fact both tokens experience large token unlocks immediately after launch. This excess supply not only triggered selling, but also had the affect of seemingly postponing buying pressure from investors who were keen to gain exposure.

Reviewing the full historical HBAR price below, we can zoom in on the region immediately after launch. You will note the large sell-off, followed by stagnation, a modest pullback and then a long period of stagnation once again. It was almost 13 months after launch when HBAR started exhibiting the parabolic price rises we have seen recently.

Now let us plot the CSPR chart below. The similarities are stark.

If the HBAR price evolution is something which CSPR continues to track in the near term, we may soon experience similar parabolic price rises in the CSPR token.

Conclusion

Hedera is indeed a very exciting and innovative proposal for consensus. However the degree to which it is reliant on storing, sharing and saving the full transaction flow history, makes it an extremely heavyweight system. We have already experienced issues with other layer 1 blockchains that have similar memory requirements. Namely Solana which experienced an outage for a week after load pushed the network to over 750GB thus bringing down the entire network and effectively having to restart the genesis block. What I fear with these types of strategies where there is a mindless race for TPS, is that there has been little thought to curtailing transactions in periods of extreme demand. Because HBAR is insistent on saving the message flow, it loses the ability to time out or queue any messages in cases of excess load. This is something which the Casper team has considered and implemented via a simple time out strategy during periods of excess load.

A present, for HBAR, this Governing council are responsible for validating transactions on the network and therefore the extremely high cost of running a node is a limiting factor. However when the network opens up, we feel this could indeed become an issue – as is the case with Solana where there are only a small number of trusted nodes. All of these point to a more centralized network than we would hope for when it comes to distributed ledger technologies. 39 council members governing the project with a codebase that is not open for modification raises many red flags. Typically a project should be open for forking where new ideas can be implemented outside of the control of a select few. Note that a typical response we see when the issue of centralization is raised, is a comparison to the collusion of miners/validators on the Bitcoin/Ether network in various mining pools. I believe this is a wrong comparison as the collusion in Bitcoin and Ether stems from the fact that those networks are both Proof-Of-Work. Meaning collusion is required to reduce computational costs. It is wrong to compare centralization in a Proof-Of-Stake networks (such as Hedera), which can be addressed without cost, to that of a POW system where there are sizeable additional costs related to computation. I feel that with any increase in decentralization for HBAR, we could experience a sharp pullback in the security of the network, purely because of the fact that this was not a driving consideration when designing a system closely controlled by the governing council.

The above is comparable to Casper who are looking to implement a more traditional and decentralized blockchain network. I would like to note at this point however, that when Casper does indeed implement a global time level 2 sharding solution to increase throughput, we will indeed also see increased memory requirements on the network. However from the proposal being discussed to-date, it is unlikely that we shall see the same high levels of memory requirements (read more about the proposal at the bottom of our sharding article here).

In terms of the enterprise strategy Casper is offering both the public and permissioned blockchain whereas Hedera’s strategy is to offer their public chain to existing private permissioned chains to use for increased auditability via a trustless network. These are two very different strategies. I would argue that there is a dependency on the success or competence of existing private chains for HBAR to succeed. With Casper however, the fate of their success lays solely in their hands, as the network offers both a public and private chain (albeit, with collaborations with other blockchain projects).

I expect a strong future for both of these projects, however at present the ‘relative value’ play (where the market cap of Casper is considerably smaller than Hedera) places Casper firmly as a favourite for investment. In addition, in the longer run, I would expect a greater degree of adoption on Casper. This is because, as Enterprise choose Casper for their private chain (because of the clear advantages over current competition), they will likely also then leverage the public chain as opposed to connecting to Hedera to increase auditability.

Disclaimer: This article is written for the purposes of research and does not constitute financial advice or a recommendation to buy.

Stake your CSPR with us at GHOST:
1. Earn passive interest compounded every 2 hours!
2. High performance server with low CPU utilization that can be monitored in real time here.
3. Low fees with a GUARANTEE of no increases EVER!
Find out more here.