What is XinFin XDPoS ?

XinFin XDPoS is an innovative solution to the scalability problem of the Ethereum blockchain, and other current blockchain platforms. XinFin XDPoS relies on a system of 108 Masternodes with XDPoS consensus that can support low transaction fees and 2-second transaction confirmation times. Security, stability and chain finality are guaranteed via novel techniques such as double validation, staking via smart-contracts and true randomization processes.

XinFin XDPoS supports all EVM-compatible smart-contracts, protocols, and atomic cross-chain token transfers. New scaling techniques such as sharding, EVM parallelisation, private-chain generation, hardware integration will be continuously researched and incorporated into XinFin XDPoS's Masternode architecture. It will be an ideal scalable smart-contract public blockchain for decentralized apps, token issuances and token integrations for small and big businesses.

XinFin Delegated Proof of Stake (XDPOS) Consensus

Self KYC compliant XinFin Delegated Proof of Stake (XDPoS) Consensus on XDC Blockchain

XinFin Delegated Proof of Stake (XDPoS) is the fastest, efficient, decentralized, and flexible consensus model available. XDPoS leverages the power of stakeholder consensus issues in a fair and democratic way. Self KYC feature adds more enterprise usecases and regulator friendliness to the Public network.

This document describes the specification for a XDPoS (XinFin Delegated Proof of Stake) network.

XinFin Spec

1. Staking
2. Delegating
3. Withdrawal
• Validators Registration with KYC document
• Choosing Validators
1. Balanced staked
• Rewards
• Fork Peversion, Malicious or Double Spends
• Slashing
1. Off-chain
2. On-chain
• Parameters
• Upgradability

1. Staking

Users can stake their coins by sending them to the deposit function on the staking contract.

• The staked amount must be larger than an amount MIN_STAKE
• The user will have to wait for 2 epochs (epoch N+2) before being able to vote for a delegate.
2. Delegating
• After 2 epochs, a Nominator can vote for a Validator with the staked coins.
• The vote will be effective in the epoch N+2, N being the current epoch.
• A new vote can be casted every 2 epochs.
• In this version, the entire stake must be voted to a single Validator. If a user wants to delegate to multiple Validators they can split their stake amongst several accounts which can then individually register as Nominators.
3. Withdrawal

Nominators should be able to withdraw their stake.

• First they must call delegate to remove their vote.
• After a specified number of epochs WITHDRAWAL_PERIOD the funds are unlocked and withdraw function on the smart contract can be called with a withdrawal address.

Validators Registration

Any network participant will be able to register as a Validator.

• A specified value 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.
• Validator is required to add KYC document at the time of staking XDC token.
• A hard limit to the total number of registered Validators MAX_REGISTERED_VALIDATORS should be specified.
• Any Validator registering will have to wait for the beginning of epoch N+2 (current epoch being N) to be eligible.
• A Validator's total stake must be greater than the MIN_TOTAL_STAKE in order for it to be eligible.
• The top validators (by a total stake) in a given epoch are chosen as the active Validator Set: those Validators that produce blocks in the next epoch.

KYC:

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.

Choosing Validators

The problem is : how to choose L Validators for a certain epoch N?

1. Balanced staked

This version of the XDPoS 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

Rewards are assigned via the Rewards Contract.

• Rewards for active Validators are calculated as a percentage of total stake, VALIDATOR_REWARD.
• Nominators would also need to be rewarded to incentivize them to stake. There are a couple of options here:
• The reward contract pays directly out to nominators, minus a fee payed the Validator, which could be specified when registering.
• The Validator is responsible for calculating/paying out the rewards. This could be done by allowing the Validators to register their own Reward Contract when registering.

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.

Slashing

In order for the network to be secure, misbehaviours must be detected and punished.