BEP Proposal: Enhanced Validator Network

BEP
,
1

1. Summary

This BEP supports adding validator’s NodeID on the system contract, so the validators can identify each other in the p2p network and forward messages more efficiently.

2. Status

Draft

3. Motivation

The current BSC P2P network runs well with a 3-second block interval, but after BEP-520 and BEP-524, BSC will achieve a subsecond block interval, which has higher requirements for low message latency.

The current public P2P network is a permissionless network on a large scale, anyone can join the network. Permissionless is necessary for a decentralized network, but it has several challenges, especially on network latency and efficiency.

To satisfy the network requirement of subsecond block interval, it is very helpful to have validators recognize each other in the network and be close enough to each other. Meanwhile, core consensus messages, such as Block Message and Vote Message, can be propagated under the new network topology with better network quality.

4. Specification

4.1 Clarification

Before diving deep into the design doc, try to introduce some common concepts first.

4.1.1 Sentry Node

For security purposes, most validators work on the intranet. The Sentry Node is a full node that acts as the validator’s public network protection node. It connects to the public network P2P Node and forwards P2P messages.

Since the sentry node is the proxy node of the validator on the public network, the validator needs to register the sentry’s NodeID on the chain.

4.1.2 NodeID

NodeID is the public key that’s used for encrypting communication. A connection can be established with any P2P peer through IP+Port+NodeID.

4.2 NodeID Registration

This BEP will upgrade the StakeHub contract; it needs to add new storage slots to save the validator’s NodeIDs.

And there are some rules:

  • NodeIDs update can only be conducted with operatorAddress or consensusAddress.
  • Only validators created in stakeHub can add multiple NodeIDs.
  • The maximum number of NodeIDs that each validator can register can be changed through governance, 5 by default.

There are two approaches to update the nodes:

4.2.1 Update on web page

  1. User connects wallet with operator/agent account in BNB Chain Staking page;
  2. User can click AddNodeIDs or RemoveNodeIDs button, and input the NodeIDs that user want to add or remove;
  3. It will trigger the wallet to confirm the tx, and you need to sign the confirmed tx;
  4. The NodeIDs will be active when the tx is packaged on chain;

4,2,2 Update on node start

  1. Validator node operator needs to add or remove NodeIDs in validator config file;
  2. The validator will check the NodeIDs difference between registered on chain and local when synced;
  3. The validator will sign a replace NodeIDs tx when there is difference;
  4. The NodeIDs will be active when the tx is packaged on chain;

4.3 NodeID Verification

  • BSC node will query all validator NodeIDs when synced the chain;
  • BSC node will subscribe to AddNodeID & RemoveNodeID event to update the validator->NodeID mapping when importing blocks.
  • During P2P connection handle, it will check if the connected node matches one of the registered validator NodeIDs, it is treated as a validator’s sentry node; Otherwise, it will be taken as a normal node.

4.4 Message Propagation

Some connection features will be enabled between validators to optimize network congestion and reduce message latency.

  • Transaction: it will not be propagated between validators.
  • Block: it will directly broadcast to all other connected validators in this network.
  • Vote: same as block.

5. Rationale

5.1 Why add validator’s NodeID

Currently, validators often connect to the P2P Network through public full nodes. When producing blocks or sending votes, the connected full nodes may forward the block through multiple hops before reaching other validators.

By adding validator’s NodeID on the chain, validators can be identified, so the validator/sentry can choose to connect to validators first, and keep a small number of full nodes.

At the same time, a more efficient message forwarding mechanism can be enabled between validators, better traffic control can be implemented, and the delay of message reception can be further reduced.

5.2 Why use system contract

The update of the system contract depends on the hardfork, which can maintain consistent registration and query logic for all nodes.

At the same time, registering the NodeID in the system contract can also maximize decentralization. Any active validator can be updated at any time and can quickly establish an efficient P2P connection with other validators.

6. Backward Compatibility

This BEP requires a hard fork to upgrade the system contract and keep the logic of all nodes consistent.

7. License

The content is licensed under CC0.