Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Harmony has transcended the blockchain trilemma by bringing the best research to production. Sharding is proven to scale blockchains without compromising security and decentralization.
We divide not only our network nodes but also the blockchain states into shards, scaling linearly in all three aspects of machines, transactions and storages.
To prevent single shard attacks, we must have a sufficiently large number of nodes per shard and cryptographic randomness to re-shard regularly. Each shard has 1/4 of nodes for strong security guarantee against Byzantine behaviors. We use Verifiable Random Function (VRF) for un-biased and unpredictable shard membership.
Harmony has innovated on the battle-tested Practical Byzantine Fault Tolerance (PBFT) for fast consensus of block transactions. Our Fast BFT (FBFT) leads to low transaction fees and 1-block-time finality in Harmony Mainnet.
We use Boneh–Lynn–Shacham (BLS) constant-sized signatures to commit blocks in a single round of consensus messages. We achieve 2-second block time with view changes in production against adversarial or unavailable leaders.
Harmony Mainnet was launched in June 2019. Our network has produced 30M+ blocks with 450k+ transactions in publicly traded, native ONE tokens.
Harmony has designed a novel Proof-of-Stake (PoS) mechanism for network security and economics. Our Effective Proof-of-Stake (EPoS) reduces centralization and distributes rewards fairly to thousands of validators.
Our staking mechanism supports delegation and reward compounding. To support 100% uptime but fully open participation, EPoS slashes validators who double-sign and it penalizes elected but unavailable nodes.
Harmony Economics Model caps the annual issuance at 441 million tokens (about 3% rate in long term). Our model gives validators a simple and predictable return. All transaction fees are burnt to offset the issuance, naturally leading to zero inflation when our network usage becomes high.
Harmony allows smart contracts to receive random numbers on chain, using a Verifiable Random Function (VRF) powered by distributed randomness generation (DRG). This allows any DAPP in the Harmony ecosystem to leverage randomness without relying on off-chain oracles.
Harmony’s sharding approach depends on a secure randomness source so the validators can be assigned to shards in a truly random manner to avoid single-shard attacks. Harmony designed a distributed randomness generation (DRG) protocol which involves both VRF (Verifiable Random Function) and VDF (Verifiable Delay Function) to achieve the follows key properties:
Unpredictable: No one should be able to predict the random number before it is generated.
Un-biased: The process of generating the random number should not be biasable by any participant.
Verifiable: The validity of the generated random number should be verifiable by any observer.
Scalable: The algorithm of randomness generation should scale to a large number of participants.
Since the random assignment (resharding) of validators only happens every epoch, Harmony’s DRG protocol only needs to execute once per epoch. It works as follows:
During the epoch, each validator takes turns to become the FBFT leader and at the end of the epoch, all validators should have become leader for at least once. Each new leader runs VRF to create a random number R and a proof P using its BLS key. The random number and the proof will be attached to the first proposed block by the leader, which will be verified by the validators and committed to the blockchain.
As soon as more than 2/3 of the validators have done the VRF submission, the immediate next leader will combine all the submitted random numbers with an XOR operation to get the preimage pRnd of the final randomness.
The leader runs FBFT among all the validators to reach consensus on the pRnd and commit it in block.
After pRnd is committed, the leader starts computing the actual randomness Rnd=VDF(pRnd, T), where T is the VDF difficulty and is set algorithmically such that the randomness can only be computed after k blocks.
Once Rnd is computed, the leader initiates a FBFT among all validators to agree on the validity of Rnd and finally commit the randomness into the blockchain.
The VDF (Verifiable Delay Function) is used to delay the revelation of the final randomness in order to be secure against last-revealer-attack.The VDF is used to provably delay the revelation of Rnd and prevent the last leader from biasing the randomness by choosing to submit or not the last random number. Because of the VDF, the last leader won’t be able to know the actual final randomness before pRnd is committed to the blockchain. By the time Rnd is computed with the VDF, pRnd is already committed in a previous block so the leader cannot manipulate it anymore. Therefore, the most a malicious leader can do is to either blindly commit the randomness pRnd, or stall the protocol by not committing pRnd. The former is the same as the honest behavior. The latter won’t cause much damage as the timeout mechanism in FBFT will be triggered to switch the leader.
The consensus algorithm is a key component of any blockchain. It determines the security and performance of a blockchain and is often referred to as the "engine" of a blockchain. Harmony’s consensus algorithm is called Fast Byzantine Fault Tolerance (FBFT), which is an innovative upgrade on the famous PBFT algorithm. FBFT is one order of magnitude faster and more scalable than PBFT because BLS (Boneh–Lynn–Shacham) aggregate signature is used to significantly reduce the communication cost. Specifically, FBFT allows at least 250 validators to reach consensus within 2 seconds.
For every round of consensus in FBFT, one validator serves as the “leader” and there are three phases: the announce phase, the prepare phase and the commit phase. In the announce phase, the leader proposes a new block and broadcasts the block hash to all of the validators. In the prepare phase, validators verify the message and sign on the block hash, as well as sending the signature back to the leader. The prepare phase finishes when signatures with more than 2/3 of the voting power are collected. After that, the leader aggregated the collected signatures into a O(1)-sized BLS aggregate signature and then broadcast it with the whole block to start the commit phase. The commit phase involves validators verifying the block and doing a similar signing process as the prepare phase (i.e. 2/3 voting power collection). The consensus is reached after the commit phase is done. This whole process can be done within 2 seconds in mainnet.
Specifically, Harmony’s FBFT consensus involves the following steps:
The leader constructs the new block and broadcasts the block hash to all validators. This is called the “announce” phase.
The validators check the validity of the message, sign the block hash with a BLS signature, and send the signature back to the leader.
The leader waits for valid signatures with more than 2/3 voting power from validators (including the leader itself) and aggregates them into a BLS aggregate signature. Then the leader broadcasts the new block and the aggregated signature along with a bitmap indicating which validators have signed. Together with Step 2, this concludes the “prepare” phase.
The validators check that the aggregate signature has at least 2/3 of total voting power, verify the new block, sign the received block from Step 3, and send it back to the leader.
The leader waits for valid signatures with more than 2/3 voting power (can be different signers from Step 3), aggregates them together into a BLS aggregate signature, and creates a bitmap for all the signers. Finally, the leader commits the new block with the aggregate signatures and bitmaps into local DB, and broadcasts the aggregate signature and bitmap for all validators to confidently commit the block too. Together with Step 4, this concludes the “commit” phase.
One of the drawbacks of BFT-based consensus is the potential stallment of the consensus if the leader is malicious. The solution to this in PBFT algorithm is the additional view change protocol on top of the consensus which is able to switch leaders when the consensus is stalled. The view change in PBFT works well in the traditional distributed system setting but it fails in the more complicated blockchain space. Particularly, the view change in PBFT is relying on the timeout mechanism where the timer is triggered based on the live progress of the consensus. This works fine if the nodes are always online and are in sync with the consensus progress. However, this won’t be true in the real world situation where nodes can be down for extended time or restarted due to machine crash, which will make the nodes having inconsistent view IDs and not able to make progress in the view change.
We solve this problem by using an improved version of the view change protocol that’s fully synchronous based on the local clock rather than assuming the liveness of the nodes. Specifically, instead of setting the validator’s view ID based on the live progress of the consensus, the view ID is calculated based on the elapsed time of the last successfully committed block’s timestamp. Of course, there is no global clock to rely on in the calculation of elapsed time. Each validator will use their own local clock for that. However, this is totally fine as long as more than 2/3 of the validators maintain a relatively accurate local clock that’s not drifting by a few seconds. This is achievable in the protocol to make validators to periodically synchronize its local clock with NTP time.
This improvement makes our view change protocol fully robust and functional as long as more than 2/3 of the honest validators are online, guaranteeing the liveness of the FBFT consensus. Besides, BLS aggregate signatures are also used in the view change protocol to reduce network communication cost, making it a very efficient process which takes a few seconds to finish.
Harmony is one of the first production mainnets to feature a fully sharded PoS architecture. Across the 4 shards in Harmony mainnet, blocks are produced every 2 seconds and cross-shard transactions are finalized in 2 block times.
Harmony’s Effective Proof-of-Stake (EPoS) is the first staking mechanism in a sharded blockchain that achieves both security and decentralization. EPoS allows staking from hundreds of validators and the unique effective stake mechanism reduces the tendency of stake centralization. Meanwhile, stake delegation, reward compounding, double-sign slashing, and unavailability checking are also supported.
Let’s call the bid price of the elected BLS keys the raw stake. The effective stake of an elected BLS key is a bounded value on its raw stake with a threshold around the median bidder’s raw stake (denoted as median_stake in the picture below). The upper threshold is 115% of the median_stake and the lower threshold is 85% of the median_stake. For a key with raw stake that’s out of bound of the threshold, its effective stake will be bounded by the corresponding threshold, otherwise, the effective stake is the same as the raw stake.
The effective stake of each BLS key is determined at the last block of an epoch during the election process and will stay the same throughout the next epoch.
After the election and shard assignment, the BLS keys assigned in a shard become the committee of that shard. The voting power of an elected BLS key in a committee is the metrics used to measure the key’s weight in the consensus voting process. The total voting power of a shard committee is always 1.0 (or 100%). The consensus of a committee is only reached if more than 2/3 of the voting power is collected in the votes.
Each BLS key in the committee has a certain voting power proportional to the share of its effective stake among the whole committee. For example, if the sum of the effective stake of all the keys in the committee is 10k ONE, a BLS key with effective stake of 1000 ONE will have voting power 0.1 (or 10%).
For each of the blocks produced and confirmed within a shard, it should contain signatures from the keys with more than 2/3 of the total voting power of the shard committee. Each confirmed block will produce 7 ONE as block reward for the validators behind the committee. The 7 ONE is initially allocated to all the validators whose BLS key(s) signed on the block, proportionally to the voting power of the key(s) that signed.
The allocated block reward for a validator will be further distributed to delegators proportionally to their stake after the commission fee is charged. For example, a validator with a commission rate of 25% got allocated 4 ONE for a block it signed. The validator staked 1000 ONE itself and it has 2 delegations each with 1000 ONE. The block reward distribution for this validator works as follows:
The commission fee of 1 ONE (4 ONE * 25%) is cut from the original reward and credited to the validator.
The rest of the reward of 3 ONE is then distributed to all the stakers (including both the validator and its delegators) proportionally based on their stake. Since the stakers (the validator and the two delegators) each staked/delegated 1000 ONE, they each receive 1 ONE in the reward distribution.
If any BLS key(s) are detected signing conflicting blocks (i.e. blocks with the same height and view ID but with different block hashes), the validator will be slashed and forever banned from the network. When a validator is slashed, a certain percentage (i.e. slashing rate) of staked tokens from the validator and its delegators will be forfeited, of which half will be burnt and another half will be credited to the reporter of the double sign event.
The slashing rate is calculated by simply summing all the voting power of the double signing keys with a minimum of 2%. For example, if 3 BLS keys with voting power of 3%, 3% and 4% double signed at the same time, 10% of all staked tokens will be slashed on the validators who hold the 3 BLS keys.
The elected validators are obligated to validate blocks with their elected BLS keys. In every epoch, an elected validator should sign more than 2/3 of the signatures that its BLS keys are asked to sign.
The signing performance is represented by a percentage value called uptime. A validator’s uptime is the ratio of the number of signatures its elected BLS keys signed over the total number of signatures the keys should sign. For example, a validator has 2 elected BLS keys and each of the keys is presented 100 blocks to sign. In the final tally, the first key signed 70 blocks and the second key signed 80 blocks. Overall, the validator’s uptime is (70+80) / (100*2) = 75%.
At the end of each epoch, the validators with uptime of no more than 2/3 (66.66%) will have their status set to “Inactive” and be ruled out from the new election. For these inactive validators, they are required to manually set their status to “Active” by sending an EditValidator transaction in order to participate in future elections. We encourage validators to be proactive in maintaining a high uptime to ensure they remain elected and earn the most block reward possible.
Harmony blockchain is sharded in three dimensions: state, network and transaction.
State Sharding
In Harmony, each shard maintains it's own chain of blocks and state database. Therefore, the validators of each shard only need to store 1/N of the global state, where N is the number of shards. The consistency between states from different shards are guaranteed by the property of eventual atomicity of cross-shard transactions, which guarantees that double spending between shards can not happen.
Network Sharding
Harmony's validator network is also divided into shards where each shard involves a separate set of validators connected closely with each other and running consensus between themselves. Most of the time, validators communicate with other validators within the same shard to reach consensus or synchronize blocks. In cases of cross-shard transactions and beacon chain synchronization, validators from different shards send messages across shards through the globally connected network.
Transaction Sharding
Transactions in Harmony blockchain are sent to and processed by a specific shard instead of all shards. This way, shards can process transactions in parallel which greatly improves the overall transaction processing capacity of the blockchain. Users need to specify a field named shard_id
in the signed transaction which indicates which shard this transaction belongs to. For cross-shard transactions, another field named to_shard_id
is needed to indicate the destination shard while the shard_id
field indicates the source shard.
An epoch in Harmony blockchain is a pre-determined period of time when the validator committees of shards stay unchanged. In Harmony mainnet, one epoch is 32768 blocks which translates to around 18.2 hours. In Harmony testnet, one epoch is 8192 blocks which is around 4.6 hours.
When one epoch ends, the election for the new validator committees will be conducted in beacon chain and the result (i.e. shard state) will be written in the last block of the epoch in the beacon chain. After that, beacon chain enters the new epoch with the new validator committee producing blocks. Once beacon chain enters new epoch, all the other shards will follow and also enters the new epoch. The new shard state from the beacon chain will be written in the new block of the shards which also marks the last block of the epoch for that shard.
Crosslink is an important piece of data which is sent from shard chains and stored in beacon chain. A crosslink contains data for block signatures and the block identifier data such as block hash, block number, view id and epoch etc. When a new block is confirmed in a shard chain, the corresponding crosslink will be created and sent to the beacon chain. Upon the receipt of the crosslink, the beacon chain verifies its signature and checks that it’s from the canonical chain of the shard. Successfully verified crosslinks will be added in the new block of the beacon chain to permanently endorse the block of the shard chain as canonical. Shard chain blocks without corresponding crosslinks endorsed in the beacon chain won’t be recognized by the network and will be deemed as invalid blocks.
Besides serving the purpose of marking canonical blocks of the shard chains, crosslinks are also used to record and tally the signing activity of the shard chain validators. Since epoch transition and EPoS election happens only on beacon chain, the validator signing activity from shard chains are sent to the beacon chain via the crosslink so it can be used for block reward calculation and uptime calculation which affect the validator’s election status.
Our token economics model incentivizes early stakers with higher rewards to bootstrap the network successfully. For those validators or delegators who would like to join , this guide will help you get started and learn about how everything works.
Effective stake is a new measure introduced in EPoS in order to prevent stake centralization and still provide capitalistic fairness. For exactly how it achieves that, is the design rationale behind it.
In the updated economic model of our network, the total reward across the network (issuance plus transaction fees) will remain constant regardless of average block time and staking ratio. The goal of this change is to achieve a higher staking ratio, to simplify the model and to create a path to 0 issuance, all of which we believe will bring long term benefits for Harmony.
ONE is the native token for Harmony which supports the monetary flow of the entire Harmony economic system. ONE has 18 decimals.
The smallest unit of ONE is called Atto, which is 0.000000000000000001 ONE. (equivalent to Wei in Ethereum).
The second smallest unit of ONE is called Nano, which is 0.000000001 ONE (equivalent to Gwei in Ethereum)
ONE token has several important utilities that’s required for using the network and is essential to the security of the network.
ONE token is the native token for paying transaction fees. Users need to specify a certain amount of transaction fee in ONE so the transaction can be successfully processed and included in the blockchain.
Harmony is a Proof-of-Stake blockchain which means the security of the network is protected by staked tokens. ONE token is the native token that’s accepted for staking. Potential node runners need to stake a certain amount of ONE token to be elected as a validator. ONE token holders are also able to delegate their ONE tokens to existing validators to participate in the staking process. The more ONE token staked, the more secure the network becomes. Elected validators who successfully sign blocks will receive block rewards in ONE tokens as compensation for their services.
Harmony is a permission-less and decentralized network which is governed by the community. Any protocol level decisions or improvements will be put as a proposal which will go through the open governance process to finalize. ONE is the only accepted token used as the measure for voting in the governance process.
Block finality refers to the concept that a proposed block is finalized by the blockchain and can not be reverted or the cost of reversion is prohibitively high. Block finality is usually measured by how long it takes for the newly proposed blocks to be finalized. For example, in Ethereum, it takes more than 6 blocks or 1 minute to have reasonable confidence that the block is finalized and can not be reverted.
Thanks to the nature of Harmony‘s FBFT consensus, blocks can be finalized as long as the 2/3 majority quorum is reached on the block. On Harmony mainnet, it now takes 2 seconds to finalize a newly proposed block and the transactions inside. Read more about our 2-second finality here:
Harmony follows the same transaction fee model as Ethereum where users pay a certain amount of tokens to get their transactions processed and included in the blockchain. Since Harmony is fully EVM-compatible, users can translate directly the fee model from Ethereum and apply to Harmony. For example, a normal token transfer transaction cost 21000 gas. The gas price can be as low as 0.000000001 ONE (or 10 Gwei as in Ether) since Harmony have high TPS and the network is highly efficient and rarely clogged. This means a normal transfer cost only about 0.000021 ONE. In General, transactions in Harmony network cost around $0.000001 gas fee.
The reason for Harmony to be able to afford such low fee is twofold. First, Harmony is Proof-of-Stake chain where the cost of running a node is much cheaper than PoW chains as no wasteful computation is needed. Second, Harmony is a highly scalable blockchain which currently provide thousands of transactions per seconds as throughput. This means users don't need to bid with high fee to get their transaction processed in time. We expect the low fee situation will stay as long as Harmony network is not fully utilized and even if that happens, we can solve the problem by extending the network with more shards to provide more transaction processing power.
The latest design is documented here: https://gitlab.com/mukn/harmony1-proposal/-/blob/main/README.md. The following design is deprecated.
We will adopt the asynchronous cross-shard communication model just like we did for cross-shard ONE token transfer. Meaning any smart contract which needs to call another smart contract from another shard will have the sender contract transaction finalized first at initiating shard, then a receipt will be created including the call data, and finally the receipt will be sent and processed at the destination shard.
A new Opcode “CALL2” will be added to the virtual machine which is used for a cross-shard smart contract call.
CALL2’s input is similar to CALL but with an another shardID parameter:
Unlike CALL which actually executes the contract code within the same shard, CALL2 won’t run any code but only lead to the creation of a receipt after the transaction is successfully confirmed in this block. The receipt structure can be like this:
Specifically:
TxHash: the transaction hash of the original transaction sent from the real user
Sender: the address of the transaction sender
From: the address of the caller smart contract which initiated the cross-shard call
To: the address of the callee smart contract in another shard
ShardID: the shardID of the caller smart contract
ToShardID: the shardID of the caller smart contract
Input: the input data for the smart contract call, exactly like the payload of a normal intra-shard transaction that calls a smart contract
Amount: is the among of ONE that is sent along with the call to the callee smart contract
Gas: the gas that’s going to be paid to the destination shard.
Once the corresponding block of the receipt is finalized, a proof data for the receipt will also be generated. This is exactly the same as cross-shard ONE token transfer:
Once the receipt and proof are obtained, they will be sent from source shard to destination shard (CXReceipt.ToShardID) for processing.
The destination shard process the cross-shard smart contract receipt by:
Verify the receipt is valid using the proof data
Use the CXReceipt.To as the callee smart contract address and CXReceipt.Input data as the contract call data for contract execution. CXReceipt.Amount and CXReceipt.Gas are also used the same way as normal contract calls.
If this contract call produces additional cross-shard contract calls. Additional receipts will be generated and the same cross-shard call process will happen.
What if the callee contract doesn’t exist in the destination shard?
We could simply abort the cross-shard call but credit the gas to the destination shard. This way, we don’t need another cross-shard receipt to go back to the source shard to credit the gas.
Or we could create a brand new contract. This requires the receipts include the contract bytecode which can be user specified or the same as the caller contract’s code (in case of HRC20 contract replication across shards)
What if the gas sent in the receipt is not enough to pay for the transaction?
Simply abort the contract call as a normal transaction “Out of Gas” situation.
In any failure cases of the cross-shard contract call. The sent token in CXReceipt.Amount should be credited to?
The sender address in the destination shard. This avoids having to send another cross-shard receipt to credit the token back to the sender shard.