This blog series was jointly written by Tim McHale and Greg Scullard (Developer Advocates).
Tokenized assets are a common starting point for developers to enter into blockchain and distributed ledgers. First popularized by the Solidity smart contract language in production, many would like for these tokens to be faster and cheaper to operate.
This 4-part blog series describes some of our early thoughts on tokens implemented with Hedera Consensus Service (HCS).
Our hope is that this will stimulate discussion in the developer community and encourage convergence around viable approaches that foster innovation and standards to lead to real-world solutions.
There are many token implementations, but large-scale adoption has yet to take off. Real-world use of these technologies is still rare despite the plethora of blockchain projects and significant investment. Many projects or proofs-of-concept have been "parked" until technology improvements surpass throughput bottlenecks; others remain in limbo because of security and confidentiality concerns. Fairness and governance have also given many of us reason to pause.
Hedera aims to address these issues at both the platform level and its governance model, and the recent release of HCS puts the full power of the hashgraph consensus algorithm directly into developers’ hands. We want to illustrate a few ways HCS can be applied to the token ecosystem, as well as the pros and cons of each.
Our first approach to implementing tokens on Hedera used the Smart Contract service. This service allows existing Solidity contracts to be executed on Hedera with minimal change. Many of the developers in our community dived straight in and built all kinds of contracts.
There were some changes required around eventing, as mirror nodes are necessary to gain insight into transaction history with Hedera. There were also changes needed to enable gas payments in tinybars (fractions of an hbar).
However, running a smart contract of any kind on a ledger is very inefficient compared to a more conventional program executing the same logic. Of course, there are good reasons for this, but the result is that it is also resource-intensive to execute a smart contract. This approach doesn’t scale well and in our opinion isn’t sustainable for many use cases.
Indeed, the resource consumption turns into resource contention, meaning that throughput is ultimately compromised, or ever more expensive hardware is required to run a node to keep up with demand, this in terms of CPU, Memory, and Storage.
The likely end-result is an increase in centralisation due to hardware cost, and higher transaction fees, or the implementation of resource reservation schemes that reduce the availability of the platform to the very few.
The good news is there are emerging alternatives.
Using permissioned or private ledgers, it is entirely possible to stand up a private network, be it Hyperledger, Corda or Quorum and use the outstanding tooling these networks provide to develop and deploy smart contracts, be it in Chaincode, Java, or Solidity. These networks can also offer total privacy, which is often a critical business requirement.There are drawbacks though, because first the network has to be set up and maintained, which is reasonable to expect large enterprises to be able to deal with, but likely outside the scope of smaller implementations.
Permissioned networks have also historically have had consensus engines that eschew some security concerns in order to achieve greater throughput (they are unlikely to withstand a Denial of Service attack, for example), however, even within the safety of a private environment, trust between actors remains necessary.
With the advent of HCS, Hedera proposed an alternative whereby the consensus engine for these private networks can be augmented or replaced by a public network consensus. A Hybrid network where privacy and throughput aren’t compromised and where trust is provided by the public network.
Hedera has done some work in this respect.
Hyperledger Fabric
The developer preview of the Pluggable HCS Hyperledger Lab showcases how HCS can be utilised by deploying a Fabric network with multiple organizations, peers, and orderers with transaction ordering provided by HCS. The Fabric network can be deployed locally or in any cloud environment while connecting to the Hedera public testnet or mainnet.
Quorum (private Ethereum)
Further to the Hyperledger work, Hedera has created a proof of concept for Quorum networks.
Corda
Similar to Hyperledger Fabric, R3’s Corda provides a suite of tooling for leveraging distributed ledger technology for a specific use case. In the Corda architecture, “notaries” are used to validate transactions. The validation may include validation of the transactional data, but will always include validation that a given state has not been consumed before, therefore preventing double spending.
A Corda network can now use HCS to provide an order of consumed states to all notaries in the network. In doing so, the network will now have a tamper proof log of messages, which allow each notary to stay in sync with consumed states while preserving the private nature of the networks data. The Corda HCS plug-in is available in developer preview alongside a full demo.
All three of these are potential solutions for developing tokens (or using smart contracts more generally), leveraging the best tooling private ledgers have to offer along with the best public network consensus service.
In part 2 of the series, we discuss a starting point to use HCS in full to tokenize assets in a more decentralized manner.