BEP-563: add Enhanced Validator Network proposal;

BEPs/BEP-563.md

@@ -0,0 +1,130 @@
+<pre>
+  BEP: 563
+  Title: Enhanced Validator Network
+  Status: Draft
+  Type: Standards
+  Created: 2025-04-16
+  Description: To make network more efficient between validators.
+</pre>
+
+# BEP-563: Enhanced Validator Network
+- [BEP-563: Enhanced Validator Network](#bep-563-enhanced-validator-network)
+  * [1. Summary](#1-summary)
+  * [2. Status](#2-status)
+  * [3. Motivation](#3-motivation)
+  * [4. Specification](#4-specification)
+    + [4.1 Clarification](#41-clarification)
+      - [4.1.1 Sentry Node](#411-sentry-node)
+      - [4.1.2 NodeID](#412-nodeid)
+    + [4.2 NodeID Registration](#42-nodeid-registration)
+      - [4.2.1 Update on web page](#421-update-on-web-page)
+      - [4.2.2 Update on node start](#422-update-on-node-start)
+    + [4.3 NodeID Verification](#43-nodeid-verification)
+    + [4.4 Message Propagation](#44-message-propagation)
+  * [5. Rationale](#5-rationale)
+    + [5.1 Why add validator’s NodeID](#51-why-add-validators-nodeid)
+    + [5.2 Why use system contract](#52-why-use-system-contract)
+  * [6. Backward Compatibility](#6-backward-compatibility)
+  * [7. License](#7-license)
+
+## 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, agentAddress 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 New Interfaces of StakeHub contract
+
+The StakeHub system contract will provide two new interfaces to add and remove NodeIDs respectively:
+
+```solidity
+    function addNodeIDs(bytes32[] calldata newNodeIDs) external;
+    function removeNodeIDs(bytes32[] calldata targetNodeIDs) external;
+```
+
+As mentioned above, only three specific addresses of the validator: `operatorAddress`, `agentAddress`, and `consensusAddress` are permitted to call the two interfaces. Calls from any other address will be reverted.
+
+#### 4.2.2 Tips for Updating NodeIDs
+
+To simplify the process of updating NodeIDs, several approaches can be considered:
+
+- The BNB Chain Staking page can offer a user-friendly interface, allowing users to connect their wallets with operator or agent accounts to easily update NodeIDs.
+- The BSC client can provide configuration options for adding or removing NodeIDs.
+
+It’s important to note that this process is not part of the consensus mechanism, and detailed instructions will be provided later.
+
+### 4.3 NodeID Verification
+
+- BSC node will query all validator NodeIDs when synced the chain;
+- BSC node will subscribe to NodeIDAdded & NodeIDRemoved 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 prioritize broadcasting directly to all other connected validators in the network. The specific implementation depends on the client and needs to balance latency and bandwidth.
+- 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](https://creativecommons.org/publicdomain/zero/1.0/).