DPOPS alpha report — Retrospective, enhancements, and future
Dear Community,
Today, we would like to take the time to present you a report on the DPOPS alpha test phase and give you an overview of the tremendous progress that has been made. We will go in-depth into the changes, improvements, and enhancements of the consensus, as well as reminding some of the aspects of this next update.
We will also start talking about the organization of the beta, which will begin in the following weeks as the alpha phase is in its final stage.
What is DPoPS?
DPoPS stands for Delegated Proof-Of-Private-Stake, a custom DPoS consensus implementation on the X-Cash blockchain.
Delegated Proof-of-Stake (DPoS) is an efficient, decentralized, democratic, and flexible blockchain consensus framework that has been actively researched and implemented during the past years. However, the private nature of a coin can make DPoS implementation challenging as balances are obfuscated. As a representative system, DPoS needs the right balance of transparency to remain efficient, and most privacy coins cannot cope with missing part of their opacity.
To address this challenge, we have developed and proposed our custom DPoPS, an improved Delegated Proof-of-Stake algorithm for privacy coins. DPoPS inherits all the advantages of the original DPoS consensus while offering the opportunity to be used in a privacy coin.
From a technical implementation perspective, we have chosen to use a combination of Delegated Proof-of-Stake and delegated Byzantine Fault Tolerance (DBFT) with the use of Verifiable Random Functions (VRF) for the block producer election. As X-Cash is a privacy-based coin where balances are hidden, Monero’s reserve Proofs are extensively used through the election process.
There are three different actors in the DPoPS consensus algorithm:
Shared delegates
The shared delegates are people that wish to secure the network by running a node but don’t necessarily have enough coin to be in the top 100 delegates at all times. Stakers will be able to assign a vote to these delegates, assuming they share the same values!
The shared delegates have the possibility to retribute their voters by redistributing a share of the block reward to them or at least are expected too if they want people to keep providing their stake to them.
They can also decide to use the block reward to fund other projects in the X-Cash ecosystem.
In theory, you can run a shared delegates nodes with 0 XCASH! You would just need to convince people to vote for you 😉
Solo delegates
The solo delegates are holding a substantial amount of coin, enough to be elected as a delegate and run a node without anyone assigning their stakes to them.
They will be able to secure the network and claim the block reward for themselves.
In theory, a solo delegate should hold at least 1% of the circulating supply (a bit over 500M XCASH at the moment) to be sure to stay in the elected 100 delegates.
Stakers/voters
Stakers are people who would want to participate in the network without the possibility or the desire to run a node. They can start staking with a minimum amount of coins (2M XCASH at the moment) to a shared delegate to help them get elected, in exchange for a share of the block reward.
Because of the design of our DPoPS consensus, the stakers can keep their stake in their own wallets. They keep the control of their stakes at all time!
🙏 We need your help!
As we are preparing for the beta and soon the launch of the mainnet, we would like to ask you where do you see yourself in this setup. You can anonymously fill up the below form; it will only take 1 minute and enable us to better prepare for the beta, ultimately reducing the time to launch!
👉Google Form: https://forms.gle/xp7KC9SF9RtfAWu49
Alpha phase report
We would like to preface the report to take the occasion to thanks every participant of the alpha phase, without whom it wouldn’t have been possible to find all these paths of improvements and potential bugs. 🙏
As you may be aware, the alpha phase of the DPoPS lasted for longer than we initially planned. First of all, this can be explained by the simple fact that this new consensus is not an adaptation or fork of anything existing in the cryptocurrency space. It’s an original work, starting from zero and is now soon reaching a state of an official release.
Although we have widely underestimated the time needed to validate the first iteration of the DPOPS and the strict application of our design on paper, having a working and bug-free system is mandatory for an update of this size. We also took the time to prepare the groundwork for the next technical features of X-Cash, as our development roadmap will continue right after the release of the DPOPS mainnet.
In this report, we will go through a selection of features and improvements that have been made and were necessary for the DPOPS to enter its next phase of development.
Auto-installer script
At the early stage of the alpha, the installation of the DPoPS needed to be done mostly manually (you can have a look at the historical instructions here 👉 https://github.com/X-CASH-official/xcash-dpops#installation-process, it will surely scare some of you if you were planning on hosting a node 😉).
One of the first obvious tasks was to improve user experience and provide an easier way to install xcash-dpops to run a node.
That is why Zach, with the suggestion of Twinkie#2421, a skilled alpha-tester, has written the auto-installer script enabling in one simple command to install and set-up the DPoPS node easily.
Anti-DDOS system
This issue was first brought by picatextra, an engaged participant of the alpha-test and a seasoned bug hunter.
In any system where communication between peers is essential, an attacker could decide to flood a delegate to deny him/her a round of block creation. This has been seen a lot in other DPOS consensus, whenever the next block creator is known (in a round-robin type system), to deny them the next block creation and reward.
The delegate selection being random in the DPOPS, there is less incentive in using a DDOS attack as the attacker wouldn’t know in advance who would be the next block creator. This being said, any delegate must be able to withstand this kind of attack.
And when we say the selection of delegate is random, it’s truly random 👉 with our implementation of Verifiable Random Functions 😎
This has been done by limiting the number of simultaneous communications to 20. Additionally, only the top 200 registered delegates (with a minimum of 100M XCASH) can send messages to other delegates.
Delegate Websites & Supervisor
To easily see the list of delegates, we created a delegates explorer website that gathers all information about the elected delegates and their statistics, helping you choose who to vote for a delegate.
We are also providing the delegates pool website, which will provide shared delegates the possibility to easily and automatically retribute people voting for them. No need to send the rewards manually and stakers can check their latest payment, such as in a classic mining pool website.
Finally, the delegates’ supervisor is a light webpage hosted by the delegates’ servers to check your delegates’ statistics quickly (before you would have needed to check in the CLI with specific commands 😁)
All of these websites are part of the builders’ program, and are open to contribution!
Code Coverage
As the xcash-dpops will be part of the builders’ program, any community additions will have to pass a set of unit tests to ensure that every new integrated feature will not prevent another one from working correctly.
With that in mind, it was important that at the beta stage, most of the code is covered by unit tests. With 457 unit tests, the xcash-dpops code coverage is above 90%.
Performance enhancement
Lighter and more efficient messages
We changed the message sending system from a “send and receive” to a “send and close” style system. In short, this enables a block verifier to create a connection to every block verifier, send them data, and not wait for the response, greatly reducing the time it took to process data (from up to a minute to 10 seconds).
Before, the message function was using threads (pthreads) to send messages, which has been changed to a system combining worker threads (using phtreads) and event-driven asynchronous processing using file descriptors (epoll) 🤓, enabling reduced CPU usage (only one CPU thread is required now to send all block verifiers a message in under 3 seconds).
We also improved the way the node receives messages to make it quicker and more efficient (using a C-style memory trick to erase the raw TCP socket deliminator string, instead of using a string_replace call per received message 🤓).
In short, less data is transmitted with the same amount of verification, making it quicker and using less bandwidth.
Better p2p syncing
The syncing system was reconfigured to include multiple hashes at once for reserve bytes and reserve proofs, reducing the number of messages per database collection, reducing the syncing time. Adding data to the database has been optimized to be faster as well.
Additionally, we added a quick sync mode for block verifiers to participate in the next round they are joining in by quickly syncing their data from the seed node.
Decrease bandwidth and complexity
In every block creation process, the delegates need to exchange information. These messages include VRF information (have a look at page 25 of our yellowpaper for more information on how we use VRFs), the block and transaction data, the data necessary for dBFT verification, etc.…
In the first iteration, the number of messages sent was initially at seven (7) and was reduced to four (4), which greatly decreasing the blockchain size increase rate and bandwidth use.
LXC Containers Support
LXC Containers enables people to install xcash-dpops on a machine that is not necessarily running Ubuntu 18.04, which is required for running a node. However, it is recommended to use the auto-installer on a Ubuntu-running server.
Testing infrastructure
Reuniting all alpha testers from different timezones on the same schedule limited the number of tests we could do during the week. It was important to prepare a test environment that would give us no limit on the number of tests that we could do.
That is why we have worked and designed a test environment of 20 virtual machines hosted in our server infrastructure. This enabled us to multiply the number of weekly tests by nearly 10, and while it took a lot of time to set up the environment, it enabled us to speed up the alpha phase greatly.
The Next Step
Above are just outstanding features and enhancements that have been made during the alpha test-phase, to only cite a few. In practice, more than a thousand commits were made since the beginning of the alpha, and it would be futile to list every bug fixes by them. In these commits, there is also the groundwork for the next features of the X-Cash blockchain, to facilitate the development of the next steps in our technical roadmap (token creation, smart contracts, etc…).
But before that, we need to validate in a real setup the DPOPS and make the switch to the new consensus on the mainnet. We are organizing the beta phase as we are speaking, while the alpha is coming to an end. This test phase filled its role perfectly, enabling us to test, validate, and improve what we had designed on paper.
This time, everyone will be able to participate in the beta, as we want to test in a close-to-reality setup. It may seem a bit blurry at the moment, but we are preparing a series of tutorials and videos to help you join. So rest assured, it will be made accessible for everyone.
In the meantime, please help us by filling out this form (if you haven’t already) to help us designing the beta 👉 https://forms.gle/xp7KC9SF9RtfAWu49
We hope that by reading this article, you are starting to get as excited as we are to see more about this new consensus and participate in the validation of the network, and to start staking.
We are more than ever grateful for your support. 🙏 We will keep you posted for more news really soon!
