There have recently been a number of exciting 'next generation' blockchains that have been put through the paces on their respective testnets to ensure their reliability and scalability. We've covered a couple of these in recent posts. One such blockchain which has been rolled out on it's mainnet and is a Layer 1 protocol is Harmony (ONE).
Being Layer 1 means that Harmony has its own underlying blockchain architecture and is not an overlay network or a side-chain dependent on another blockchain like Ethereum, for instance. The YieldWallet team has just started running a validator on Harmony and we're actively working on putting together reliable infrastructure to support the project. This post covers some of the more technical details of the protocol.
Harmony vs Ethereum vs Zilliqa
Ethereum was the first blockchain infrastructure to propose a Turing-complete language for its smart contracts, thereby extending the use of the blockchain beyond the constrained set of uses that Bitcoin supported. However it did not solve the scalability problem and is able to support only about ~15 transactions per second.
Some of the solutions proposed to increase transaction throughput include using Proof-of-stake or delegated Proof-of-stake as in blockchains like EOS, instead of Ethereum's current Proof-of-work consensus, to re-imagining the blockchain structure itself to allow parallel processing, such as in IOTA's DAG (Directed Acyclic Graph) data structure.
However these solutions provide performance while sacrificing other critical features that one expects from Blockchains, such as security and decentralization. According to the Harmony whitepaper, the one scalability solution that both preserves security and decentralization, while increasing performance is sharding.
Sharding essentially involves organizing the blockchain structures, the transactions, the state and the validator sets into separate parallel 'shards' to get a boost in performance by being able to parallel process state changes or transactions. The number of shards can grow linearly to accommodate higher transaction throughput.
One of the first public blockchains to implement such a solution was Zilliqa. However their sharding approach suffers from a flaw in that it does not divide blockchain storage into shards, which makes a. storage a bottleneck to performance and b. it difficult for smaller players to run a node due to the storage requirements, thereby negatively impacting decentralization. They also use a Proof-of-work algorithm which makes them susceptible to Shard takeover attacks similar to the 51% attacks possible on other Proof-of-work blockchains.
Harmony - Key technical details
Scalability - Harmony implements sharding for the network communication, transaction validation and the blockchain state. This makes them a fully scalable blockchain.
Secure Sharding - The Harmony protocol includes non-interruptive resharding (meaning the ability to reshard the blockchain while staying online and serving the needed functionality) and a distributed randomness generation process that makes it unpredictable, verifiable and more resistant to attacks.
Proof-of-stake - Harmony uses a variation of the Practical Byzantine fault tolerance (PBFT) algorithm for consensus unlike other sharding-based blockchains which use Proof-of-Work.
Scalable networking - One of the keys for a scalable shard-based blockchain is inter-shard communication that is consistent, reliable and scalable. Harmony uses the Adaptive Information Dispersal Algorithm and Kademlia routing to achieve scalable cross-shard transactions.
Consensus mechanism
The first blockchain networks, Bitcoin and Ethereum used Proof-of-work consensus as mentioned earlier. Another type of consensus based on decades-long academic research is called PBFT or Practical Byzantine Fault Tolerance. At a high level, this involves one node being elected as the "leader" while the rest of the nodes are "validators''.
These actors then go through multiple phases of preparing and committing transactions in a way that is seen and approved by a quorum of validators. Each validator sees the approvals / votes by the other validators and so on. PBFT has a communication overhead complexity of O(N^2), which makes it inefficient. Harmony improves upon PBFT by using Schnorr signatures to combine multiple validator votes, thereby flattening the communication requirements and achieving a complexity of O(N).
Staking-based Sharding
One of the key security considerations in public blockchains is the Sybil attack, which is the notion of a single actor multiplying themselves to make them look like several independent actors, thereby taking control of a network. Blockchains like Bitcoin and Ethereum use Proof-of-work which involves the computation of a Cryptographic puzzle to align an actors power with their compute capacity, a scarce resource. This makes Sybil attacks quite difficult.
Sharding-based blockchains like Zilliqa and Quarkchain also use Proof-of-work to prevent Sybil attacks. Harmony uses a Proof-of-stake based approach to solve this problem. In order to become a validator, prospective participants need to stake a certain amount of tokens. The number of tokens staked determines the number of voting shares they get assigned.
Additionally, a validator's shares are split among multiple shards at the beginning of each round or epoch, making takeovers of the network or a shard by one validator doubly difficult. As with all proof-of-stake blockchains, good behavior is obtained as validators with stakes or skin-in-the-game have an incentive to act for the betterment and health of the blockchain network. There is also a slashing penalty, wherein validators could end up losing their stakes for bad behavior.
Shard chains and Cross-shard communication
As described earlier Sharding is essentially the notion of splitting one blockchain into multiple entities with it's own set of validators, state and so on with some form of cross-shard communication which binds them into a single larger blockchain entity. Harmony has the notion of shard chains, which is a relatively independent blockchain that communicates with other shard chains as needed.
Cross-shard communication is implemented differently by various Shard-based blockchains. Zilliqa relies on its 'Main' chain to achieve cross-shard transactions. This may become a bottleneck to transaction throughput as the blockchain scales up. Blockchains like Omniledger propose a client-driven approach, wherein client code is responsible for collecting and sending transactions to shards. This adds extra burdens to the client side and does not really allow for the notion of a light client.
Harmony chooses an approach wherein the shards communicate directly with each other, without external help. This type of communication is generally expensive as each cross-shard message is essentially a network-level broadcast. Harmony uses the Kademlia routing protocol to reduce communication complexity by an order of magnitude.
Beacon chain
The Harmony beacon chain is essentially a shard chain with a couple of additional purposes. Besides processing transactions like other shard chains the beacon chain is in charge of the functionalities of a. Random number generation for leader election among other things and b. Accepting stakes from prospective validators. Stakers deposit their tokens to the beacon chain to become validators.
Blockchain state sharding
Unlike other state-sharding blockchains that use a UTXO (Unspent transaction output) based data model, Harmony uses an Account-based model. Accounts and smart contracts are also treated differently. An account can have balances on different shards and is able to send funds across them using cross-shard transactions, as needed.
A smart contract is limited to the shard it's created on. A Dapp developer may instantiate multiple instances of a smart contract on different shards for scalability, but each of them has its own state. The different smart contracts can be networked and communicate with each other through cross-shard communication.
Kademlia-based routing
As described earlier, Harmony uses Kademlia-based routing for cross-shard communication, which at a high level entails the use of routing tables to chop down the distance a message needs to travel to get from its source shard to the destination shard, with the intelligent use of routing.
Incentives
The incentives for one to run a Validator on the Harmony blockchain are Block rewards that are distributed to all validators who sign each block (in proportion to their stake). Transaction fees are distributed to validators in a similar fashion.
As mentioned earlier, Harmony also implements a Slashing protocol, which involves penalizing Validators for failing to finish the consensus process or signing dishonest blocks. Any other validator can submit proof of such misbehavior and will get rewarded with the tokens slashed from the malicious validator.
Future work
Some of the future work planned for the Harmony protocol includes
Fraud proofs, which involves research into improving the security of cross-shard communication
Stateless Validators, which allow Validators to start validating transactions without having to sync up to the full blockchain state
YieldWallet.io plans
We are in the early stages of rolling out a Harmony validator and achieving the minimum stake needed. We are looking for users with Harmony to stake, who can help us achieve active delegate status and we are implementing an incentive program that will reward early delegators.
You can delegate directly to our validator (address: one1f7hfpy33pzw27jzpnt77y6ze2srckrhm52j40v) and do reach out to us at [email protected] if you'd like to be a part of this early cohort, as the incentive structure will need to be implemented outside the standard delegator-delegate reward system on the protocol.
Connect with us
Enjoyed this post? Join our communities and participate in the ongoing discussion.
Twitter, Facebook, Telegram, Email, Medium, LinkedIn
Please leave your comments and questions about Indra Crypto Capital, YieldWallet, Harmony or anything else you’d like to talk about and we will be sure to get back to you.