We are switching to delegated Proof-of-Stake
Dear X-Network community,
Today, we would like to give you a sneak peek into our next major upgrade of X-Cash core code 2.0: delegated Proof-of-Stake (dPoS).
To summarize, X-Cash dPoS is:
- An improvement of the public blockchain network where 100 elected delegates are in charge of the consensus;
- A unique algorithm that combines delegated Byzantine Fault Tolerant consensus mechanism and Verifiable Random Functions;
- The first dPoS cryptocurrency based on private transactions;
- The first dPoS cryptocurrency based on Monero and Reserve proofs;
- A backbone for the sidechain technology that will allow higher scalability and new use cases.
The first part of the article aims at summarizing the basic concepts behind dPoS and how it is implemented into other cryptocurrencies.
The second part describes what technological choices have been made for X-Cash’s dPoS, as well as detailing what will be the minimum requirements to host a delegate.
What is dPoS?
dPoS is a consensus mechanism where only a subset of nodes in the network are allowed to validate transactions and mine blocks. The nodes validating the transactions are known as the delegates as they are elected by the token holders of the cryptocurrency. Given that the process of block creation doesn’t require heavy computation as in Proof-of-Work, it is also known as forging.
In practice, the token holders can assign their stake to a specific node candidating to be elected as a delegate. At the end of each period (which can vary from a few seconds to days), the top x (typically between 7 to a few hundred) candidates in terms of staked votes are elected delegate. The delegates are in charge of validating the transactions of the network. The typical process of block creation is called a “round” and can be decomposed as follow:
- A delegate is selected to be the block producer. This process can follow a certain pattern (e.g round-robin) or be random;
- The block producer creates a suggested version of what the next block should be in terms of transactions, including its block producer reward;
- The other delegates vote to accept or reject the suggested block. If the block is voted valid, every delegate (and therefore, the whole network) add the block to their version of the blockchain and a new round can start.
Advantages:
- Higher security (no 51% PoW attacks)
- Faster and easier consensus
- Lower energy consumption
Disadvantages:
- Higher centralization
- Implementation difficulty
delegated Proof-of-Stake in the current cryptocurrency ecosystem
The first implementation of dPoS was from BitShares in 2013 which holds a total number of 101 delegates. Through the impulsion of Dan Larimer (currently CTO of EOS), it showed that greater scalability could be easily achieved at a cost of a higher centralization. Since then a certain number of projects have decided to use dPoS as a consensus algorithm. While EOS is currently the most popular one from a market capitalization perspective, a few interesting projects have also set their foot in the space. The below table offers an overview of these actors and summarizes the main technical characteristics related to dPoS:
*currently, the delegate selection process is not fully open and adjustable on NEO and ONT. More details on the full process can be found here.
RR = Round-Robin
VRF = Verifiable Random FunctionsX-Cash delegated Proof-of-Stake
At X-Network, we are convinced that delegated Proof-of-Stake currently offers the best trade-off between security, decentralization, and scalability while allowing a lower energy consumption. After assessing, using, and participating in most of the existing dPoS based cryptocurrency, we have designed a new version of dPoS that will combine most of the existing features while being tailored to our ecosystem and the future improvements we plan to make.
Additionally, one of the main rationales for switching to dPoS is to offer a real-world experiment of dPoS under a privacy coin, and eventually create some return on experience to the Monero community from which we have inherited a lot. The philosophy behind the development of X-Cash’s dPoS has always been aligned with X-Network and we want to make it fully open source, reusable, and transparent.
While most of the details will be given in the yellow paper which will be released in the next weeks, we want to give you a first look into what the algorithm will be.
Stake delegation
One of the key components of dPoS is the capacity for the users to vote for delegates using their stake. This creates an interesting momentum where delegates need to behave accurately to be supported by the users. Eventually, this leads to a healthier ecosystem by creating competition among the delegates. This competition materializes in higher block reward sharing, higher performances of the network, and better involvement of the delegates in the community.
The minimum stake to vote for a delegate has been set to 2M X-Cash to allow anyone to participate while keeping the number of voters manageable. The voting will be done directly in the wallet by assigning a reserve proof to a specific delegate. The top 100 nodes in terms of voting stake will be elected delegates and will take part in the consensus process. Under the current circulating supply, we have estimated that the minimum stake to be elected should be in the 200M X-Cash range. We have also prepared a tool for the delegate to automatically share the staking reward from the blocks forging, similarly to what is currently done in the mining pool.
Byzantine Fault Tolerant Algorithm
The consensus algorithm will be based on delegated Byzantine Fault Tolerant (dBFT) scheme which was introduced in NEO. The primary interesting feature of this algorithm is the need to have ⅔+1 delegates to achieve consensus. This means that collusion (such as Lisk’s cartel of delegates) in the network is less likely to happen, considering that the company and the future foundation of X-Cash will also own a fully independent number of delegates.
The other interesting concept behind dBFT is the removal of alternative chains. This has two major implications; the first one is the fact that the number of confirmation needed to legitimate a transfer (more particularly a deposit on an exchange) can be greatly reduced, as there is theoretically no chance for a rollback of the chance. On the other hand, this also resolved the nothing-at-stake issue where delegates could be incentivized to support all alternative chain (on the contrary of PoW). In dBFT, since there are no alternative chains, there is no nothing-at-stake issue.
Random Block Producer Selection
Another fundamental technical component of our dPoS algorithm will be the random Block Producer Selection through the use of Verifiable Random Functions. As we have seen previously, most of the current dPoS algorithms currently use a round-robin process for the selection of the block producers. Without being a critical threat to the system, this can raise questions on the overall healthiness of the consensus as block producers know in advance when they will be creating the next block.
In X-Cash dPoS we will use another process derived from the algorithm used in Ontology (ONT). We believe having each block producer selected randomly to be a critical step. From a technical perspective, this can be challenging as this random selection process is controlled by one node at a time (the previous block producer). Therefore, how can a node guarantee that the process was truly random and not artificial to favorize some other block producers? This is when Verifiable Random Functions comes in as they allow a posteriori the network to verify the randomness of the selection process. In practice, the VRF generation is tied to the previous block hash to avoid any favorable precomputed data.
Requirements to run a node
In the design of the technical components of the algorithm, we have tried to find the best compromise between performances and features. As stated from the inception, we have always wanted to offer the possibility to have a delegates node run on light VPS. In practice, matching the minimum requirements on a node will allow it to run the mainnet while sticking to the recommended specs will also guarantee better stability and the possibility to run additional sidechains when they are released.
Minimum requirements
- Operating System: Linux Ubuntu 18.04 or higher
- CPU: 2 cores
- RAM: 2 GB
- Disk Space: 50 GB
- Bandwidth: 500 GB/mo
- Bandwidth(peak): 100 MB/s
Recommended specs
- Operating System: Linux Ubuntu 18.04 or higher
- CPU: 4 cores
- RAM: 4 GB
- Disk Space: 100 GB
- Bandwidth: 2 TB/mo
- Bandwidth(peak): 100 MB/s
Conclusion
The change of consensus algorithm from Proof-of-Work to delegated Proof-of-Stake is a significant milestone for the X-Cash blockchain, and will also bring innovation to Cryptonote, Monero and the overall blockchain ecosystem.
The design of X-Cash delegate Proof-of-Stake consensus algorithm has raised significant challenges, as it is a pioneering work for both a Cryptonote and public/private hybrid transaction coins. For this first version of the algorithm, it has been chosen to use a combination of delegated Proof-of-Stake and delegated Byzantine Fault Tolerance (dBFT) with the use of Verifiable Random Functions (VRF). As X-Cash is a privacy-based coin where balances can be obfuscated, Monero’s Reserve Proofs are extensively used through the election process.
From a growth perspective, the change of algorithm has been widely anticipated and will strengthen the community while providing more involvement and a better governance process. From a technological standpoint, delegated Proof-of-Stake will increase the security and resilience of the network as well as providing the foundation for the sidechain technology development.
Additional links:
- Follow delegated Proof-of-Stake development on GitHub: https://github.com/X-CASH-official/XCASH_proof_of_stake
- More information on X-Cash: https://x-network.io/xcash/
- X-Network Twitter: https://twitter.com/xcashcrypto
