A Detailed Tour of the BNB Smart Chain Euler Upgrade

2022.6.8  •  7 min read
Blog post image.

After months of planning and effort, the Euler upgrade is scheduled to go live on the BNB Smart Chain Mainnet at block 18,907,621. The current block generation speed forecasts the upgrade on June 22, 2022, at 08:00 (UTC).

BSC node operators should upgrade their nodes before the fork block. Due to the variability of block time, we recommend updating several days before the expected date.

Let’s dive deep into the enhancements and new functionalities that the Euler Upgrade brings!

TL;DR:

BNB Smart Chain will become a more secure, robust, and decentralized network with the Euler upgrade. We hope that this new release will open doors to more validating participants and developers.

The upgrade aims to strengthen the network's survival and ensure that even if more than half of the validator set is censored or taken down in an unexpected or hostile way; thereby increasing the  BSC network’s availability and reliability. Furthermore, these improvements aim to achieve a more reliable and stable validator set as well as provide faster transaction finality. The Euler upgrade will also introduce a scheduled maintenance feature aimed at stabilizing the blocking rotation and maintaining the capacity of BSC in the absence of a validator.  

BEP-131: Introducing candidate validators onto BNB Smart Chain

BNB Smart Chain currently has 21 active validators and several inactive validators. In the present setup,  inactive validators receive no rewards; hence, they have no incentive to remain active or upgrade their hardware. Euler upgrade will enable BEP-131 to introduce a maximum of 21 new candidate validators onto BNB Smart Chain to enhance the network's liveness and robustness while also increasing decentralization.

BEP-131 will introduce more validators, including 21 inactive validators, to the validator set as backup, called "Candidates." Candidates will compete to produce blocks and earn gas fees on BNB Smart Chain Mainnet, but they will have a  lower chance of succeeding than the active validator set of the 21 elected validators. It is expected that a decent motivation will be maintained so that the candidate validators are willing to ensure the quality and help secure BNB Smart Chain.

The number of candidate validators is subject to the BSC governance. After the Euler upgrade, this will not automatically come into action. The BSC Mainnet will keep the same number of active (elected) validators and 0 candidate validators. Future governance actions will be required to grow the candidate validator set to allow new candidate validators to join.

For more details about the election strategy, please refer to BEP131.

BEP-127: Temporary Maintenance Mode for Validators

Due to the design of the Parlia consensus, the absence of the validator, even if it is due to scheduled maintenance, will result in instability and capacity loss of the BSC Mainnet as a result of the extra waiting time and chain reorganization required for other validators.

The Euler upgrade will enable BEP-127 to stabilize the blocking rotation and maintain the network capacity. A validator can set itself to enter temporary maintenance mode by sending a transaction to interact with the ValidatorSet smart contract. Temporary maintenance is supposed to last up to a few hours. A validator that enters the temporary maintenance mode will be temporarily dropped from the block-producing rotation until it quits the maintenance mode. If a validator remains in the maintenance mode for too long, it will be slashed. Poorly-operating validators who fail/forget to enter maintenance mode will be forced to enter temporary maintenance mode. A validator can claim to exit the maintenance mode by sending another transaction. The validator should sign both the transactions for entering and exiting temporary maintenance mode using the consensus key.

For more details, please refer to BEP127.

FAQ: BEP-131

1. What is the purpose of introducing candidate validators?
BSC should introduce more validators to decentralize the network further. Besides increasing its anti-censorship ability, BEP-131 will increase the robustness and availability of the network. BNB Smart Chain should survive even if more than half of the validator set were censored or taken down in either incidental or hostile events.

2. What are the parameters that are governed in the election procedure?
The following parameters can be governed:

  • MaxNumOfCandidates: The maximum number of candidates can be elected on the BNB Chain Staking module each day. The value of MaxNumOfCandidates can be gradually increased when there are enough ready candidates.
  • MaxNumOfWorkingCandidates: The max number of candidates can be randomly selected to be working validators for each epoch on the BNB Smart Chain.

3. What will be the different validator roles in this upgrade?

  • Cabinet: The top 21 stake validators in daily election snapshots get the most chance of producing blocks.
  • Candidate: The top (21, 21+ MaxNumOfCandidates] staked validators in daily election snapshots get a small chance to produce blocks.
  • Inactive: The rest validators get no chance to produce validators.

4. How does the election strategy work? Can the selection randomness be manipulated by anyone?
First select N validators randomly from Cabinet,  then select M validators randomly from the unselected Cabinet validator and candidates, and finally form a group of 21 validators. In order to ensure that the randomness cannot be manipulated, epochNumber = BlockHeight / 200 is chosen as the random source. epochNumber is a fixed value within one epoch and is incremental across the epoch. When the total number of available validators is less than 21, the random selection rule will not be applied. The randomness can actually be predicted. But since consensusAddr are limited to change and epochNumber is incremental across the epoch, the randomness cannot be manipulated by anyone.

5. Will the 21 candidate validator seats open at once?
No. The seats will gradually open according to the BSC governance procedure. You can check the real-time candidate validator seat setting through the following command:

./bnbcli  params    side-params  --side-chain-id=bsc    --trust-node   --node    http://dataseed1.binance.org:80     --chain-id Binance-Chain-Tigris

The candidate seats are (max_validators-21).

6. How to become a candidate validator?
The process is identical to setting up a validator; a minimum of  10K BNB is required to create a validator. You may refer to the docs about how to become a validator on the BSC network - according to the current staking position.

7. How do Candidate Validators help in monitoring collusion of Active Validators?
A higher staked validator is more trustworthy. Based on this assumption, we let the top 21 validators generate blocks in turn to maintain a certain degree of security, and the other validators are randomly selected to ensure that these validators will not collude and cause damage to the overall network.

8. What happens if a large percentage of Candidates go offline?
Cabinet and Candidates will be randomly chosen to form the 21 working validators for each epoch. The liveness of the network is usually decided by Cabinet validators who are the majority of the working validators. It means the network is still alive even if a large percentage of Candidates go offline. However, the network still suffers a liveness crisis if the majority of the Cabinet goes offline.

9. What is the risk and earn of delegating a candidate validator?
It depends on the quality of the staked validator. In general, the APY of staking a candidate validator is similar to staking an active validator.

FAQ: BEP-127

1. What is the benefit of introducing the temporary maintenance mode?
The implementation of the Temporary Maintenance Mode will stabilize the blocking rotation and maintain the capacity of BSC.

2. What is the impact on developers and users?
It is totally transparent to developers and users.

3. How can validator operators utilize this feature and adjust their monitor system?
A validator can claim itself to be in temporary maintenance mode by sending a transaction. Every validator operator is strongly suggested to closely monitor the maintenance event, check here for more details.

4. What is the current slash mechanism?
The slash contract records of each validator’s missed blocking metrics.

  • Once the metrics surpass the predefined threshold, the blocking reward for the validator will no longer be relayed to BNB Beacon Chain for distribution but will be 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 in “jail”. This will be propagated back to the BNB Beacon Chain, where a predefined amount of BNB would be slashed from the self-delegated BNB of the validator.

5. What are the different Temporary Maintenance Modes and how slashing is avoided for a validator in maintenance mode?

  • Proactive Maintenance: Validator can claim to enter scheduled maintenance by sending a transaction signed by the consensus key. They can claim 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, and 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 to enter maintenance. The 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.

6. Are there any limits imposed on the maintenance of validator nodes?
Yes, there are certain limits imposed to control the number of nodes going into maintenance mode.

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

7. When is the ValidatorSet scheduled to change and does it affect the maintenance?
The validator election will repeat every 24 hours, resulting in the change of the ValidatorSet. Furthermore, the maintenance will end immediately once the election happens.

8. What is the impact of BEP127 on the 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.


Follow us to stay updated on everything BNB Chain!

Website | Twitter | Telegram | Youtube | Gitcoin | Discord | Build N' Build Forum | CMC Gravity

Share