Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
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, here is the design rationale behind it.
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.
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.
For more information about block reward, please read our token economics model.
A validator in Harmony blockchain is a single person or entity who stakes tokens and runs nodes (validator client software) to validate blocks. A validator can specify one or multiple validating keys (a.k.a. BLS keys) which will be used to sign on validated blocks.
To become a validator in Harmony, you will need to do the following:
Setup a validator node(s) and let it fully synchronized with the latest blockchain.
Create an on-chain validator record by sending a CreateValidator transaction.
Start validating using the node(s) with the BLS key(s) you added in your validator record
There are many fields to configure for your validator. It’s worth clarifying some of the important fields in more detail:
amount: The amount of ONE tokens the validator will stake initially.
rate: The commission fee (%) the validator charges from the block reward.
bls-pubkeys: One or multiple BLS public keys the validator will sign with. Each BLS key will be used separately to bid for a slot and if successful, the key is obligated to validate blocks.
BLS stands for Boneh–Lynn–Shacham. It is a digital signature method used for verifying the authenticity of digital messages or documents.
A BLS key represents what the validator signs the blocks with, and is a way of authenticating the validator. A validator can have multiple keys to sign with, this means that a validator is signing blocks in parallel.
BLS keys are attached to validator via:
Creating a new validator (put commas between multiple BLS keys)
Adding new keys to an existing validator (edit-validator --add-bls-key), only one key can be added at a time
An instance is a virtual private server or dedicated hardware with a unique IP address on which a validator runs the node software.
Within each instance, there could be up to 4 BLS keys signing transactions. If you have more than a single BLS key in your instance, it means that you're using the multiBLS feature. If you have a single BLS key in the instance, we will call that single-key instance.
Here are some rules to follow:
In order to use multiBLS feature (multiple BLS keys in same instance), all keys are required to be on the same shard
Total number of BLS keys allowed per validator is 1/3 of total external seats (network level)
Total number of BLS keys allowed per validator can't be more than 6% of total expected external keys in a shard.
Note that validators sometimes choose to run duplicate instances (2 instances, each running with same BLS key) as a backup mechanism.
Below are some differences to using multiBLS vs. single-key instance:
Machine cost will be lower in a multiBLS instance (compare 'validator 2' vs. 'validator 1')
Single-key instances could run nodes for a validator in different shards, whereas a multiBLS instance requires all BLS keys to be in the same shard
MultiBLS and single-key instance have different staking commands
In order to make changes to the keys in a multiBLS instance, the node needs to be stopped and restarted; whereas a single-key instance can be directly added to a validator (since the node is running on a different instance)
Too many BLS keys signing using a single node creates a single point of failure (validator’s risk)
In Harmony mainnet, there are 4 shards each producing new blocks separately and in parallel. The block heights between shards are not synchronized so you will see different shards have different block heights.
An epoch is a period of time when the beacon shard (i.e. shard 0, the coordinator for other shards) produces a fixed number of blocks. In Harmony mainnet, an epoch is 32768 blocks (~18.2h with a 2s block time) in the beacon shard. Once an epoch is completed in the beacon shard, that change is also passed onto the other shards, thus all shards are synchronized by epoch.
At the end of each epoch, the committee election process will take place to elect the committees for the next epoch. The election process takes into account all the staking transactions confirmed before the election happens. The election result will take effect immediately, so we encourage all candidate validators to spin up their nodes even before the election happens.
This section helps validators ramp up about Harmony staking
For those validators or delegators who would like to join Harmony Open Staking, this section will help you get started and learn about how everything works.
The following links can also help you better understand Harmony's staking mechanism and token economics.
After a validator is elected, each of its elected BLS keys will be semi-randomly assigned to a shard in the network (fully random shard assignment will come in the final phase of mainnet). In the current stage of mainnet, the rule of assignment is simply based on the modulus of the BLS public key’s underlying bytes. For example, with 4 shards, a BLS public key like “xxxxxx8ad5” will be assigned to shard 1 because 5 % 4 = 1. Note that, for each of the elected BLS keys, the validator is obligated to spin up a validator node and validate blocks in the assigned shard.
In Open Staking of mainnet, there will be 900 slots available for bidding. A slot represents membership in the network which gives the validator the right to use a specific BLS key to sign on blocks and the signature will be acknowledged by other validators.
After you create the validator record, the tokens you stake, along with any delegated tokens to your validator, will be automatically used to bid for the slots.
Each of the added BLS keys will create a unique bid for a slot in the network. The bid price equals the total stake on your validator divided by the total number of BLS keys attached to your validator.
Simply put, all tokens staked to the validator will be equally divided into each BLS key and each key bids separately. For example, a validator with a total stake of 300 ONE and 3 associated BLS keys will have 3 bids each with a bid price of 100 ONE.
The election for the slots works as follows.
Before the start of an epoch, all validator bids are ranked by bid price in descending order.
The highest 900 bids will be awarded the slots in the upcoming epoch.
The BLS key that successfully bids for a slot is deemed elected. Elected BLS keys will eventually form the committees of the shards. A validator in possession of at least one elected BLS key is also deemed elected.
Above is a simple example of bidding and election process with 10 slots and 5 validators.
Slashing is an integral component of EPoS which serves as the deterring factor to prevent any non-conforming behaviors from validators such as double signing and being offline.
If validators breach the protocol in the two ways:
Unavailability — a validator temporarily loses his slot if he misses more than 1/3 of the blocks in an epoch; this unresponsiveness is due to nodes being offline, largely not malicious behavior.
Double signing -- a validator loses at least 2% of the stake depending on how many slots are corrupted; this behavior is considered a malicious behavior.
A fraction of the staked tokens is slashed as penalties.Slashing penalties are imposed on both validators and delegators.
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 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.
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.
If a delegator decides to stop delegating to a validator, he or she can choose to undelegate their tokens from the validator. After undelegation transaction is submitted, the undelegated tokens will be locked until the end of the current epoch. Note that the unlocked tokens can be used for a new delegation transaction only starting from next epoch. This means the same token can only possibly generate rewards for you starting from the epoch after next epoch. The token will be made available on in your wallet after 7 epoch is passed