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).
- Part 1: Permissioned networks with HCS
- Part 2: Decentralized application networks
- Part 3: Mapping an ERC-20 Token to HCS
- Part 4: Mapping an ERC-20 Token to HCS (continued)
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.
Building truly decentralized applications
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.
Hedera Smart Contract Service
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.
Permissioned network with HCS
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.