Introduction:

We plan to develop a specific tool to prevent slash caused by equivocation during node deployment.

Context of the proposal:

We are one of Polkadot validators, and we have been running stably and credibly for a long time and fulfilling relevant responsibilities.

However, not long ago, when we were about to start the construction of the second Polkadot validator node, we suddenly encountered equivocation and received a very serious slash as a result. According to our understanding, this slash may be the first case in the Polkadot network.

For this reason, we attach great importance to this problem and conducted an in-depth analysis of the problem, and found that during the deployment of Polkadot nodes, due to the setting of related parameter, equivocation will occur, which will lead to a serious slash. This kind of error usually occurs when there are multiple Polkadot validator nodes that need to be deployed. At present, most people who deploy Polkadot validator nodes, only deploy a single validator node, so this error is not common.

However, considering that with the implementation of the "Polkadot Validator 1000" and other programs, the number of validator node is gradually expanding, and there will be many people who hope to become the Polkadot validator and may deploy multiple Polkadot validator nodes at the same time. At that time, the error may occur frequently and cause serious slash to innocent people. At present, we have found that similar slashes have appeared in other projects that use substrate.

Therefore, we plan to develop a specific tool for avoiding the equivocation and accompanying slash in the node deployment process.

Problem statement:

When starting a new node, it usually takes a long time to synchronize the block data, and the time will increase as the running time of the Polkadot network increases. In order to shorten the synchronization time, an effective method is to use the image of other deployed node servers to create a new server, thereby greatly reducing the data and time to be synchronized.

We also adopted this method this time, which is to create an image from the server where we have deployed a validator node, and then use this image to create a new server. Under normal circumstances, after creating a new server, we need to change the Session Keys to match the identity of the new node, and we do plan to do so.

However, because the original validator node had a routine configuration of offline detection and self-starting, the program was automatically started before we change the Session Keys, so that two validator nodes with the same identity appeared on the Polkadot network at one time, resulting in equivocation, and then we are slashed and even suspected of being an attack on the Polkadot network.

Equivocation is not common at present but the slash brought by it is very serious. We hope to attract everyone's attention and completely solve the problem for everyone.

Proposal Objective:

Our first project is to develop an auxiliary tool to detect whether an equivocation will occur when deploying the validator node to prevent users from being slashed.

Our aim is to help more people to join the Polkadot ecosystem, making the process of deploying the validator node and maintaining easier. In the future, we will also develop a series of Polkadot maintenance tools, including deployment, monitoring, and alarm functions.

MileStone:(4 weeks)

M1：Test environment(1 developer * 1 week)

1.Rent a new cloud server

2.Become a validator at Westend

3.Make a server image from the validation server

M2：Detection Tool（1 developer * 2 weeks）

1.Detect whether local data will lead to equivocation

2.Provide users with cleanup options if equivocation is detected

3.Make a docker image

M3：Testing（1 developer * 1 week）

1.Test the equivocation detection function

2.Test user prompts and repair functions

Cost：

It mainly involves server and labor costs for tool development and verification, estimated to be 500 DOT.

How to verify：

1.Github Source

2.Demo video on Youtube