[R4R]: new implement of BEP-127

[gothery001]

BEP-127: Temporary Maintenance Mode for Validators

• BEP-127: Temporary Maintenance Mode for Validators
  • 1. Summary
  • 2. Abstract
  • 3. Status
  • 4. Motivation
  • 5. Specification
  • 6. License

1. Summary

This BEP introduces the Temporary Maintenance mode for validators on the Binance Smart Chain.

2. Abstract

Temporary Maintenance is supposed to last one or a few hours. The validator seat will be temporarily dropped from the block producing rotation during the maintenance. Since long-time offline maintenance is not encouraged, the validator will still be slashed if the maintenance lasts too long. To lower the impact from poorly-operating validators who forget to claim its maintenance, they will be forced to enter Temporary Maintenance mode too.

3. Status

Draft.

4. Motivation

Due to the design of Parlia consensus, the absence of the validator, even if it is due to scheduled maintenance, will cause instability and capacity loss of BSC due to the extra waiting time and chain reorganization for other validators. Introducing Temporary Maintenance mode will stabilize the blocking rotation and maintain the capacity of BSC.

5. Specification

Current Slash Mechanisms

The slash contract will record the missed blocking metrics of each validator.

• Once the metrics are above the predefined threshold, the blocking reward for validator will not be relayed to BC for distribution but shared with other better validators.
• If the metrics remain above another higher level of threshold, the validator will be dropped from the rotation, and put as “in jail”. This will be propagated back to Binance Chain, where a predefined amount of BNB would be slashed from the self-delegated BNB of the validator.

Temporary Maintenance Mode

Proactive Maintenance

Validator can claim itself to enter scheduled maintenance by sending a transaction signed by the consensus key. The validator can claim itself to exit maintenance by sending another transaction. The slash cleaning work will be done within the exit transaction:

SlashCount = (MaintenanceEndHeight - MaintenanceStartHeight)/len(currentValidatorSet)/Scale

Scale is a governable parameter, the initial setting is 2, usually it should be larger than 1. If SlashCount is larger than a predefined value, the validator will still be slashed. The validator can get more time to bring the node back before being slashed if it claims itself to enter maintenance. Validator is encouraged to claim itself to exit maintenance even if it will be put in jail, since it can send the unjail transaction earlier.

Passive Maintenance

Once the number of missed blocks is above a predefined threshold, the validator will enter maintenance automatically. The validator still gets a chance to catch up and claim itself online again.

Limit

1. The number of maintained validators has an upper limit at the same time. Once exceeded, the following proactive/passive claim request will be rejected.
2. A validator can only enter maintenance once per day.

ValidatorSet Change

The validators election will repeat every 24 hours, the maintenance will end immediately once election happens.

Impact to Validator Maintainers

Validator maintainers can claim the validator to enter maintenance mode once the node runs into unexpected issues. Validator maintainers need to send transactions to exit maintenance mode even if the validator is enforced into maintenance, otherwise, the validator may be put in jail.

6. License

The content is licensed under CC0.

[NashBC]

LGTM

[realuncle]

Duplicated code here, since doupdate will do this.

[gothery001]

fixed

[NashBC]

LGTM. Another little suggestion, can we reorg the commit, really no need to show so many commits.

[gothery001]

LGTM. Another little suggestion, can we reorg the commit, really no need to show so many commits.

It will be squash merged, no worry