Harmony – Problem-based Blockchain Development

Continuing with a series of articles discussing projects that aim to solve the current problems of blockchain technology, such as scalability and transaction processing time, and this time we will review Harmony, a Silicon Valley-based team of developers that decided to do an extensive research on previous projects to select the best factors of each of them, compile them and develop a new type of blockchain.

Improving on the Proof-of-Stake model, the BFT validation protocol, sharding and randomization, they propose a new model for blockchain that can withstand the potential latency spikes that are caused by the increase in transactions per second and in the size of an increasing transaction story.

Improved Consensus

Considering how the main concern with Bitcoin growing so popular is that the Proof-of-Work model it is based on is not suitable for quick transaction validation, which turns into high latency as the number of users and transactions increases.

The current solution to this, and one that more projects seem to be adopting, are Proof-of-Stake models, where each node can stake an amount of a token in order to have more votes in the validation, where the user with the highest stake becomes the leader and proposes the block for the rest of users to vote on. On top of this, there are limitations to prevent malicious users from corrupting the data (limit of votes per node so majority is not decided by a single one), and in the case of a malicious user becoming the leader, voters can reject the data and the leadership has to change before the process starts again.

Then, again, this simple model has a set of limitations in terms of the complexity order of communication being to high, as each validator not only has to vote but also count the total votes and then send back this counting to the leader. Harmony eliminates this issue by implementing a system of validation with a single multi-signature inspired by ByzCoin’s BFT but improving on it by only requiring one round-trip instead of two.


Overall, the process begins when the leader proposes the new block, sends the header to all validators and broadcasts the content with erasure coding (in order to reduce the amount of data sent to each validator). Then, each of the validators check and sign the header. The leader then waits until they receive a majority of approving signatures (twice as many opposing votes + 1). This multi-signature is then broadcasted as one to the validators for them to check the correct number of approving signatures, sign it and send it back to the leader, which ultimately commits to the new block.

With an efficient consensus model, the workload for each node is drastically reduced, thus reducing the amount of time needed for transmitting all of that data between the leader and the nodes, and back again. But this model can still develop issues in terms of security and scalability in the long term, which is why Harmony goes beyond that.

Better Sharding

With sharding already being considered the most practical solution to some of the issues, Harmony took the chance to work on top of what we already know to develop a sharding system that fits the consensus model and the necessities of the potential users, while not giving the opportunity for single shards to be corrupted.

First of all, their sharding model is not node-based but vote-based, to the point where a single validator may have votes distributed among different shards, but no single node can achieve a single majority in their shard. This distribution of stakes is always performed randomly, using an algorithm that Harmony developed themselves combining the strengths of other solutions (Algorand, RapidChain, Omniledger, RandHound, etc.).

Not only does their Verifiable Random Function (VRF) requires interaction between the leader and the validators, while a Verifiable Delay Function (VDF) keeps the generated random numbers hidden from the leader while validators reach the consensus on the randomness of said numbers. With this algorithm, they ensure that every step that requires generation of a random number (re-sharding and stake distribution, for example) are completely safe against malicious attacks.

The price of a voting share is set algorithmically to be low enough so those who plan to attack by staking a large number of tokens end up having their votes distributed among different shards so they can’t achieve majority, while also not knowing which shards they were assigned to.

Additionally, the process of resharding is facilitated by their fast state synchronization method, where new nodes can easily reach the current state of the shard by the fact that the first block of each epoch contains the information of the previous epoch in its hash, which means that new nodes don’t need to read through all of the data to catch up to the current epoch.

On top of their sharding mechanism, they also manage their information by differentiating what they call shard chains, which store their own state and validate their own transactions, and the beacon chain, which is also a shard but has the special tasks of generating the random number and accepting stakes, meaning that the validators deposit their tokens in the beacon chain. As the beacon chain also stores the block headers for each shard’s chain, this division also works as a security measure against attacks against a single shard.

Faster Networking

An issue that arises with sharding is that the network between them can become increasingly complicated, which increases the time necessary for cross-shard communication and a complete integration of the whole system.

They will implement a Kademlia mechanism for routing between shards, which assigns an ID for each shard and makes them hold a table of the nearest IDs, allowing for a complexity of O(logN) instead of the traditional O(N).

As for reducing the workload of broadcasting a message, they will implement a system where senders generate a chunk of erasure code to annex it to the message, and then broadcast encoded chunks of the message to each recipient, which then has the task to decode the message. This reduces the size of the message itself, and thus the workload on both the sender and the network.


Overall, it appears that Harmony have done a thorough research work and have spent their efforts in proposing ways to solve the most complex problems, with solutions that seem to be oriented towards long-term stability rather than being quick fixes that would soon become obsolete. It is a project that deserves attention and support from the overall community, as it may signify the future of blockchain implementation.