How to Launch Your Own Blockchain: Game of Validators [Part V]

You’ve made a big step forward and now your project is in a testnet phase. Now it’s time to think about validators. 

In some blockchains validators are pre-defined, in others independent teams and individuals  own the nodes. Game-based approach is an excellent way to choose validators wisely.

Validators are major supporters of your network. They are responsible for security maintenance, and most serious  attacks on the blockchain imply an attack on validators. Undoubtedly, you will prefer specialists to random people for this role, as in case of network problems they will be able figure out the reasons, protect the nodes from attacks, quickly update the code and help developers.

Often, a new project is expected to demonstrate the outstanding quality of documentation and support so that a newbie could become a validator after reading the README instructions on Github. This is good for decentralization but bad for running a stable and high-quality network. Three professional devops engineers are better than a hundred newcomers who would waste developers’ time or quit halfway. Over time, the project will certainly grow, and anyone will be able to easily launch the node and become a validator, but at the beginning quality is more important that quantity.

Try to find good validators at this stage. A good validator should:

Node support is similar to highload service maintenance: both are checked using load tests and pentesting. However, there are some nuances: it is required to constantly monitor validator addresses and balances, automated participation in voting, etc. So, you will need a few dozen experienced devs or talented beginners who can independently launch nodes and support them in case of code errors or external attacks.

To do this, there is a great idea that we learned about from the Cosmos project: to run a contest (a game) between potential validators in order to test all the above stated skills.

Cybersecurity specialists like to play the game called “Capture The Flag”: team players attack the servers of each other, trying to find secret “flags”.

Validators compete among themselves to determine who will be able to provide a better service to the network, whose nodes are more stable, who is more resistant to attacks, who responds more quickly to necessary code updates, etc.

This approach has no analogues in a centralized world. (Imagine a group of independent banks that compete among themselves before launching a payment system to find out who will be able to make more payments and remain resilient to attacks.)

Blockchains can use tokens as a reward for the winning validators. Tokens earned in the competition can be transferred to the main network, or the project team can promise the winners a place among the validators of the main network.

It is difficult to set the game criteria, since some of them cannot be confirmed in a decentralized environment. Validators and the project team do not know each other, and the maximum uptime (% of the time when the service was available) can be determined only in a centralized environment. A service that measures these parameters may be attacked or mistrusted by others, and it is extremely difficult to prove something in case of divergent results. If you want to use traditional parameters to assess the quality of IT services, you should choose a judge and admit of the fact that players will gather in a centralized way.

The second way is to abandon any centralized metrics and use only verifiable ones. This approach has a huge advantage - anyone can check the results of the game, but it is very hard to dispute them.

One of the most reliable metrics is the number of blocks that each validator has produced. To some extent, the metric also reflects the uptime of the validator (as they could not produce blocks offline), the number of transactions (who produced more blocks and processed more transactions), and even rewards (for the largest number of produced blocks). The number of validated blocks for almost any PoS or PoA blockchain is an excellent metric for validators to compete for. In case of attacks, code errors or network load the fastest validators will be able to produce and process a larger number of blocks.

You can also set economic parameters for the game. For example, winners can be determined by the number of tokens earned during the game. If validators profit from transaction commissions or there are other mechanisms for generating profit (for example, a referral system), the latter can be used to “top up” tokens. On the other hand, validators that send transactions to themselves and make money on this, automatically load the entire network and force others to validate their transactions. Validators can independently “attack” the network, i.e. test it in the extreme mode.

Do not forget that some blocks (or all) in consensus algorithms are validated and signed by a group of validators. In addition, serious money can be at stake. For example, a validator can change the code in a way that the node will skip some checks and unconditionally accept the transactions. Thus, he will gain speed advantage over other validators and free up resources. If there are only “good” transactions in the network, such fraud can be overlooked. Therefore, it makes sense to load the network with invalid transactions as well, so that the chains with blocks missed by dishonest validators are rolled back.

At first, it seems that the more people can participate in the game, the better. You can spend a lot of effort to attract the maximum number of participants but this will work out differently.

PoW networks should have the maximum number of miners of any level, as they only help pools choose block hashes. In Proof-of-Stake and Proof-of-Authority networks, validators are responsible for data security of blocks; their importance is much higher, and their disabling  is a serious problem.

If there are hundreds of people who want to launch their node in the project chats, then you will have to organize massive support, spend time on questions from newcomers, and most importantly, vote for them on the network and distribute tokens on their balances. At the same time, only a few dozen validators will be able to work effectively, and the rest will come and go, losing hope of getting on the top list.

Choose wisely, try to attract good teams and focus on quality instead of quantity. You can also prepare documentation, instructions, monitoring tools in advance and automate staking and voting operations. The team will be able to focus on transactions and code during the game instead of spending time on support.

There are no rules without exceptions. We faced the situations when a pair of well-trained guys competed on equal terms with eminent validators, helped other participants and eventually got a place on the mainnet.

The main game conductor is the project team, so do not rely on the community, but devote your time to supporting participants. There will certainly be questions, bugs, new requirements - and a prompt reaction will be required.

As for the game scenario, you need to determine the functionality and describe it in advance to validators. At the same time, do not forget about the “lazy validator” problem. Even if your scripts sound tempting, this does not mean that validators will be active. Often, they prefer the paradigm "if something works - don’t sweat it." They will not actively attack other validators, optimize the nodes or monitor the game attentively, but rather support stable server functioning.

Remember that for validators the game means  thousands of dollars, hundreds of hours of experienced devOps engineers, powerful servers, new software research, and 24/7 support. Without a solid reward, no company will allocate serious resources.

Validators must be constantly busy processing various transactions. To do this, the project team, that controls the token, creates numerous accounts and evenly distributes the load between the competitors.

There is also a more flexible strategy applicable to DPoS networks. The network hosts a giver contract (also called a faucet), which gives any validator a fixed number of tokens per time unit. The validator can access this contract on an ongoing basis (by creating a transaction) and use the received tokens to advance in the top list of validators. Otherwise, he can be replaced by more active participants. This approach encourages validators to constantly form new transactions, while simultaneously loading and testing the network.

As I described above, dishonest validators can turn off digital signature verification of transactions and save CPU resources in order to better withstand a large flow of transactions. It makes sense to send invalid transactions to the network - then the blocks signed by dishonest validators will be filtered by honest ones. It is worth catching the deceivers this way only if there is a lot of money or influence at stake.

In this case, the game will be complete, and validators will have to tackle serious problems - protect their machines from attacks, change IP addresses, quickly cut off attacking traffic, etc. As in the transaction load case, it is better if validators attack each other to gain an advantage in the number of produced blocks. To do this, devOps specialists will have to become attackers for a while and use the software to perform attacks. In addition, more wealthy participants can use the purchased cloud power and influence the course of the game.

A uniform attack of validators by the project team would be a good strategy. Mind that such actions can be detected by the provider, and you may need documentary evidence of the attack for testing purposes.

Updating the node code is a regular task for any validator team since they will have to do that in the main network. The procedure can be either very simple or quite complex (for example, if a chain replay from scratch is required).

The best option is if the bug does not allow to produce new blocks, and bug fixing restores this functionality. In this case, the validators that were able to update the code faster (and possibly rebuild the chain from the genesis block) will be able to resume block production faster and gain an advantage in the game.

There are many scenarios that can be included in the game. The project team can add bonuses for useful network actions, such as publishing code for node monitoring and governance tasks, etc. Everything depends on your imagination.

However, do not forget about the “lazy validators." If the awarded actions require complex interactions or development of specialized tools, validators are unlikely to get involved.

The game of stakes is a great way to gather a team of professionals capable of protecting the blockchain, to reward the teams prepared for difficulties and to hold a memorable marketing event that has no analogues in a boring centralized world.

The next article will be about the mainnet launch. See you soon!