Wanchain Galaxy Consensus — Randomized Consensus
Wanstake Design
Overview
In Wanstake an account’s stake is determined by the amount of WAN tokens held by that account as well as the length of time it is held for in the Consensus Smart Contract (CSC) , a.k.a coin age. The period over which the tokens are held in CSC is called a “locking period”. The token-generated-to-time ratio during a locking period is not linear. At the conclusion of each locking period all tokens deposited will be returned to their original stakeholders after a set amount of time.
H function is used to compute the amount of Wanstake the consensus participants are to be rewarded with.
ω: the amount of WAN tokens lockedL: total locking timet: the ratio of remaining locking time and total locking time (L)σ_L: an increasing function of L
Key Properties
- The more Wan tokens locked and the longer they are held for, the more rewards.
- The shorter the remaining time, the bigger the participant’s reliability (i.e. non-byzantine behavior).
- For the same amount of tokens, staking them over one longer period yields more rewards than staking over two shorter periods.
- No extra rewards for splitting stake into multiple accounts.
Core Protocol
Protocol Sequence
- Protocol participants are selected from the Community to participate in consensus.
- At the beginning of each epoch, a Random Number Proposer Group (RNPG) and an Epoch Leader Group (ELG) for the next epoch are selected from the Community using a random number from the Random Beacon (RB).
- The RNPG generates a new random number to update the RB in the current epoch.
- The ELG generates a secret verifiable message unknown to others in this epoch to determine the right to propose a block.
- The ELG determined at the beginning of the previous epoch runs a selection algorithm to determine the Unique Leader of each slot in the current epoch who proposes block.
Notice that the Slot Leader sequence is fixed at the beginning of the next epoch by the RB to prevent Grinding Attacks. In other words, the RB does NOT update until a secret message is generated.
A random generation algorithm designed to simulate the RB is run once in each epoch by the RNPG, and produces a result that will be used as random seeds in the following 3 aspects:
- Selecting the RNPG for the current epoch
- Selecting the EL for the next epoch
- Setting the order of the ELs of the current epoch
Random Beacon (RB)
The RB divides each epoch into the following 3 stages:
- DKG1: Participants make commitments for the data to be submitted.
- DKG2: Participants as a group generate a group public key and a group secret key share.
- Signing: Participants each compute their group signature share using the group secret key share generated from last stage.
A random output will be generated at the conclusion of stage 3.
Epoch Leader (EL) Selection
ELs for the next epoch are selected at the beginning of each epoch based on each participants’ stake ratio k blocks before. The selection process is simulated by implementing Follow-the-Stake-Rate (FTSR), a random lottery model similar to Follow-the-Satoshi (FTS) in Ouroboros Proof-of-Stake. FTSR can be briefly described in the following steps:
- Stake Ratio Calculation: Calculate the stake value of each node as well as the stake ratio of each consensus participant from the community.
- Tree Traversal: a binary tree is constructed in a way that the leaf nodes in the tree are represented by a hash of their own public key, while the sum of stake ratio in each sub-tree representing the value of the tree node. Down below we illustrate an example where there are
NELG members:
Unique Slot Leader (USL) Selection
In each epoch, the participants selected as ELs during EL selection are responsible for selecting the USL of the next block by generating a secret message inside the group for assigning subsequent block production rights. The generation of this secret message can be divided into 2 stages as the following:
- SMA1: Each node in the group selects a random number and encrypts it with its public key. The encrypted random number is eventually put on the chain as a commitment to ensure its immutability.
- SMA2: Each node submits the random number selected in SMA1, and encrypts with the public key of all nodes (including its own) in the group. In addition, the node is required to provide a DLEQ-Proof (Discrete Log Equivalence Proof) to ensure that all public keys are encrypted with the same random number.
At the conclusion of SMA2 the ELs decrypt the encrypted data to get a random data sequence, while a random number is generated in the meantime to be used as a seed for sorting the ELG nodes in ascending order based on the operation results. The sorting result will then be used to allocate the order of production rights in subsequent blocks.
Delegation Mechanism
Proxy Signature Scheme
It’s a well acknowledged fact that in most PoS chains where rewards are proportional to the amount of tokens staked, those who hold small numbers of the tokens have little to no motivation to participate in consensus by staking. It’s a dangerous game especially for the validators who run high-cost infrastructures and are required to be online almost all the time, as the operational cost can easily outweigh the rewards.
To combat this very issue, Wanchain implements a delegation scheme leveraging a trusted ledger based triple ECDSA proxy signature scheme that allows the original signer to delegate his signing right to another entity, called a Proxy signer, in case of being offline due to whatever reason there might be. The signature computed by the Proxy Signer can later be verified by anyone with access to the Original Signer’s public key. Note that in the case of proxy signing the Original Signer never loses his custody of the tokens. When he delegates away his signing rights to a Proxy Signer, a new proxy public keys pkp over which himself has the total control is generated. In addition, a proxy smart contract Proxy_SC is executed acting like a digital contract managing the relationship between the Original Signer and the Proxy Signer. Only when pkp is selected as the RNP or block proposer will the Proxy Signer perform the signing on behalf of the Original Signer.
Advantages
Some notable advantages Wanchain’s delegation scheme has over others in this space:
- Non-interactive: There’s no additional communication channel required between the Original signer and the Proxy signer, which saves bandwidth and avoids unnecessary complexity in consensus.
- Reward distribution: In the proxy signature scheme, rewards generated from the consensus process will be split between the Original Signer and the Proxy Signer. When an entity has multiple delegators, the rewards are split between the corresponding (Original signer, Proxy signer) pair.
- Limited message space: There is a message space in Wanchain’s triple ECDSA proxy signature scheme dedicated to limiting the signing space of a Proxy Signer. This would allow for conditional signing right delegation and various other use cases.
Incentive Model
Activeness Index
In Galaxy consensus one can participate in consensus by either being a RNP that’s responsible for generating random numbers to update the RB, or being a EL that contributes in secret message generation and block proposal. Both roles are rewarded in Galaxy for their contribution in maintaining the consensus and honest behavior. As to exactly what the rewards are determined based on, we need to first look into the Active Index defined for each role. In short, there are three different index models of activeness in Galaxy consensus:
- RNP Activeness index: This index number is determined based on a RNP’s participation in the two stages of random number generation. Participation in both stages would be a 1, and 0 otherwise.
- Epoch leader Activeness Index: Similarly the activeness index number for an Epoch leader is determined based on a his participation in the two stages of secret message generation. Participation in both stages would be a 1, and 0 otherwise.
- Epoch Leader Group Activeness Index: This index number is calculated as the ratio of the number of proposed blocks that were valid in an epoch and the total number of blocks included in that epoch.
Reward Distribution
As a way to encourage participation in the Galaxy consensus protocol, Wanchain has reserved 10% (21 million) of the total supply of Wan tokens (210 million) as supplemental rewards. 50% of the 21 million tokens will be issued in the first five years, with the rest being issued at half the rate every five year after that. Within each 5-year period, the reward allocation for each epoch is said to be equal.
Supplemental rewards are paid out to RNPs and non-byzantine ELs. On the other hand, transaction fees are distributed among Block Proposers and all RNPs. The reason for rewarding RNPs part of the transaction fee revenue is two-fold:
- If RNPs were only paid supplemental rewards, we would eventually reach a point where the incentive for RNPs to stay participating in consensus were no longer sufficient as the issuance rate of supplemental rewards were cut in half every five years.
- Consistency in participants’ behavior is enforced as the rewards for each epoch are settled in the first block of the next next epoch.
Incentive Model for Delegation
Lastly, we will take a brief look at the incentive model for delegation in Galaxy consensus. In Wanchain each delegate (or validator) usually charges a commission fee m in exchange for providing delegation service. So when a delegator is rewarded R for his contribution in consensus, he gets R*(1-m) and the delegate gets R*m. Not only is the max amount of stake a delegate can be delegated proportional to his principal, there is also a ceiling number s for the total amount of stake a delegate can receive. Delegates receiving stake exceeding swill see a reduction in rewards, which in turn encourages a more equal stake distribution overall.
References
[1] Guo, D., Shi, C., & Chen, Y. (2019). Galaxy Consensus: A Practical Proof-of-Stake Protocol With a Robust Delegation Mechanism [Ebook]. Retrieved from https://github.com/wanchain/explorewanchain/raw/master/_media/Wanchain-Galaxy-Consensus-V1.0.pdf
[2] Wanchain Documentation. (2019). Retrieved 11 September 2019, from https://www.explorewanchain.org
