Self KYC compliant Delegated Proof of Stake (DPOS) Consensus on XDC Blockchain
Delegated Proof of Stake (DPOS) is the fastest, efficient, decentralized, and flexible consensus model available. DPOS leverages the power of stakeholder approval voting to resolve consensus issues in a fair and democratic way. Self KYC feature adds more enterpise usecases and regulator friendliness to the Public network.
This document describes the specification for a XinFin DPoS (Delegated Proof of Stake) network.
Any network participant will be able to vote for eligible Validators.
Users can stake their coins by sending them to the
deposit function on the staking contract.
Nominators should be able to withdraw their stake.
delegateto remove their vote.
WITHDRAWAL_PERIODthe funds are unlocked and
withdrawfunction on the smart contract can be called with a withdrawal address.
Any network participant will be able to register as a Validator.
REGISTRATION_VALUE(in the native token) will be sent to a register function on the contract. It will be staked in order to limit the number of participants.
MAX_REGISTERED_VALIDATORSshould be specified.
MIN_TOTAL_STAKEin order for it to be eligible.
Masternode Holder need to Add Know your customer (KYC) identification as its falls under the responsibility of financial institution and/or regulated company. Validator needs to upload self KYC document and this document will be visible on open public network.
The problem is : how to choose L Validators for a certain epoch N?
This version of the DPoS contract should balance all the stakes by finding the minimum staked for all eligible Validators (eg. take the top 1000 Validators) and balance all the Validators stakes by refunding the users the contributions that overflowed the stake.
For example, if the minimum stake is S, we want to balance all stakes to S. If a Validator has S+100 stakes because of 3 contributions: S−10, 5 and 100, then the last nominator will be refunded 95.
In this model, an epoch would be of the maximum number of Validators allowed, eg. 1,001 (+/- an hour on a 4-seconds block time chain).
Rewards are assigned via the Rewards Contract.
Fork Perversion, Malicious or Double Spends:
To Prevent fork, we like to add feature to re-validate transaction. Every transaction will have 2 signatures. one signature will be by block creator and second signature will be by block verifier (both separate validator). So, block verifier will check for malicious or double spends etc.
In order for the network to be secure, misbehaviours must be detected and punished.
Off-chain detection of misbehaviour is easier to implement and can be used for tricky misbehaviour detections.
In the contract, there will be a
reportBenign method (part of the Validator Set Contract) that only Validators can call, passing a message and a block-number, and a slashing will execute if more than 2/3 of the Validators agree on the misbehaviour.
These might include but are not limited to:
It could slash a portion of the stakes, eg. only 4%
A slashing condition that can be verified on-chain is that a Validator signed-off 2 blocks with the same step (equivocation). Anyone could call this
reportMalicious method with the right data, being the two signatures of the Validator, and the message signed, which would contain the step of the blocks.
This method would thus include an RLP decoder. We could also detect if a Validator hasn't signed any block for the past 256 blocks on-chain, by challenging the Validator to submit the block he signed along with the signature. However, only the last 256 block hashes are available in the EVM, so it might be limited in this context of around 1,000-blocks epochs.
reportMaliciousmethod that only Validators can call, passing a message and a block-number, and a slashing will execute if more than 2/3 of the Validators agree on the
reportMalicious. It could slash a portion of the Entire 100% stakes of Validator Node.
There may be other on-chain slashable conditions.
Suggested parameter values from requirements:
MIN_STAKE : 10000000 XDC
VALIDATOR_REWARD : 0.01370% Daily
REWARDS_TRANSFER : Every next block of epoch
VALIDATOR_SET_SIZE : 21
WITHDRAWAL_PERIOD : Set of Epoch (1 Epoch == 500 Blocks)
MAX_REGISTERED_VALIDATORS : 5000
Contracts should be upgradeable, could be implemented with Proxy contracts.
Governance mechanism : In the contract, there will be a Vote method (part of the Validator Set Contract) that only Validators can call, passing a message and a Change function will be execute if more than 2/3 of the Validators agree on the Upgrade.
Contract state would need to be transferred to the new version of the contract, either through a migration process or a persistent storage pattern.
Programming Language: C++, Golang, Python, Rust
Consensus Related References