Consensus Check- #REI DAO #8 Proposal # Penalty Logic Optimization for Validator Double Signature

Quorum

2% of the circulating supply (750 million). The purpose of this quorum is to ensure that the only measures that pass have adequate voter participation.

Proposal background

As the underlying punishment mechanism of the public chain, the Slash Mechanism has played an important role in the security of the PoS public chain and the stability of the operation, especially the punishment for double signatures of validators, which is also necessary to maintain the security, stability, health and sustainable development of the PoS public chain. REI Network introduced the Slash Mechanismin in 2021, and it has been in operation so far, providing a guarantee for the safe and stable operation of REI Network. In the past development, REI Network has continuously adjusted and improved this mechanism according to the needs of the community.

In line with the principle of decentralized governance, REI Network will continue to further optimize the penalty logic of validator double signature according to the needs of the community. In the past underlying rules of the blockchain, if each validator finds that a validator has signed and voted for a different block of the same height, it will trigger the double signature penalty logic. Each validator will call the slash function of the system contract to fine the malicious validator. Slash will transfer the validator’s staked balance, mining rewards, and 40% of the waiting queue balance directly to the black hole address as a penalty. This series of confiscation process cannot be revoked or stopped.

If the manager of the validator makes a wrong operation (such as opening two validators in the server), resulting in the double signature, the system will ruthlessly confiscate it and cannot recover the loss though the manager doesn’t do that on purpose. So this proposal aims to optimize the double signature slashing rules.

Specific goals

  1. Optimize the Slash Mechanism of REI Network, so that this mechanism can better play a role in the safe and stable operation of REI Network in the future.

  2. Fully understand the opinions of the community on the upgrade of the Slash Mechanism, and ensure that every $REI holder can fully realize their on-chain governance rights to the REI Network.

  3. Deepen $REI holders’ professional understanding of the PoS mechanism, and enable more community supporters to become more professional on-chain crypto citizens while realizing on-chain governance.

  4. Punish the double signature according to the actual impact, so that a certain degree of fault tolerance will be given to the double signature caused by force majeure of the validator and the enthusiasm of the validator to produce blocks can be protected .

After the next REI DAO upgrade is completed, the logic of the validator double signature penalty will be optimized. The details include:

  1. When a validator double-signs, the validator will be frozen immediately and stop producing blocks;

  2. The Community Governance Committee and the Community Developer Committee jointly evaluate the negative impact of the validator’s double signature on the REI Network, and give a suggested value for the penalty amount;

  3. The community governance committee initiates a Snapshot governance proposal, and the final confiscated amount for the validator is determined by the results of community voting;

The specific technical specifications are as follows:

Before FORK_BLOCK_NUMBER:

After the validator discovers the double-signature evidence, the underlying layer calls the slash function of the system contract to fine the malicious validator.

/**
 * Slash validator
 * @param validator        validator address
 * @param reason           reason for confiscation
 * @param hash             hash of evidence
 */
function slash(address validator,uint8 reason, bytes32 hash) external;

After FORK_BLOCK_NUMBER:

The freeze period logic is added. When evidence of the double signature is found, the freeze function of the bottom-layer call system contract will freeze the malicious validator.

/**
 * Freeze validator
 * @param validator       validator address
 * @param hash            hash of evidence
 */
function freeze(address validator, bytes32 hash) external;

notes: Validators in the frozen state cannot produce blocks, cannot obtain rewards, and the staked withdrawal function is disabled. After the community decides on the punishment of the validator, the community administrator uses the multisig wallet to call the unfreeze function of the system contract to unfreeze and punish the malicious validator.

/**
 * Unfreeze validator
 * @param validator       validator address
 * @param factor          unfreeze confiscation factor
 */
function unfreeze(address validator, uint256 factor) external returns (uint256 amount);

notes: When calling unfreeze, if the factor parameter is 0, no penalty will be imposed. If the factor is greater than 0 and less than or equal to 100, a percentage penalty will be applied. If the factor is greater than 100 and less than the validator’s mining reward, the mining reward penalty will be imposed.

Rationale

The processing flow after the fork is as follows:

  1. Freeze the malicious validator: When the validator finds the double-signature evidence of the malicious validator, the underlying call system contract (address: 0x0000000000000000000000000000000000001001) passes in the address of the validator and the double-signature evidence to freeze the validator.

  2. Community discussion: The community discusses the nature of the malicious validator and decides the severity of their punishment. (If the circumstances are serious, a 100% penalty can be imposed; if the circumstances are less serious, the penalty will be imposed on its mining rewards; if the circumstances are harmless, no punishment will be imposed).

  3. Unfreeze by community administrators: Community administrators use community multi-signature wallets to call the unfreeze function of the system contract (address: 0x0000000000000000000000000000000000001001), and pass in the penalty parameters determined after community discussions to unfreeze and punish the malicious validator.