From 780ce1a2585f1c5efd60e0bc727ee1859ce8d94b Mon Sep 17 00:00:00 2001 From: galaio Date: Thu, 17 Apr 2025 00:20:40 +0800 Subject: [PATCH 1/5] BEP: add Enhanced Validator Network proposal; --- BEPs/BEP-563.md | 124 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 124 insertions(+) create mode 100644 BEPs/BEP-563.md diff --git a/BEPs/BEP-563.md b/BEPs/BEP-563.md new file mode 100644 index 00000000..0b77e7e2 --- /dev/null +++ b/BEPs/BEP-563.md @@ -0,0 +1,124 @@ +
+  BEP: 563
+  Title: Enhanced Validator Network
+  Status: Draft
+  Type: Standards
+  Created: 2025-04-16
+  Description: To make network more efficient between validators.
+
+ +# 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 or consensusAddress. +- Only validators created in stakeHub can add multiple NodeIDs. +- The max number of NodeIDs can be changed by 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](https://creativecommons.org/publicdomain/zero/1.0/). From 1ab7c16e41c5bd5df86254179398f473db1c4cfb Mon Sep 17 00:00:00 2001 From: galaio Date: Fri, 18 Apr 2025 15:20:36 +0800 Subject: [PATCH 2/5] BEP: add Enhanced Validator Network proposal; --- BEPs/BEP-563.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/BEPs/BEP-563.md b/BEPs/BEP-563.md index 0b77e7e2..4e481a53 100644 --- a/BEPs/BEP-563.md +++ b/BEPs/BEP-563.md @@ -67,7 +67,7 @@ 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 max number of NodeIDs can be changed by governance, 5 by default. +- 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: @@ -78,7 +78,7 @@ There are two approaches to update the nodes: 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 +#### 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; From afc2914bfe13fbf22c04bc4bce6968fbeee58a8f Mon Sep 17 00:00:00 2001 From: galaio Date: Fri, 18 Apr 2025 18:34:13 +0800 Subject: [PATCH 3/5] BEP: add Enhanced Validator Network proposal; --- BEPs/BEP-563.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/BEPs/BEP-563.md b/BEPs/BEP-563.md index 4e481a53..bcd1e2c3 100644 --- a/BEPs/BEP-563.md +++ b/BEPs/BEP-563.md @@ -65,7 +65,7 @@ This BEP will upgrade the StakeHub contract; it needs to add new storage slots t And there are some rules: -- NodeIDs update can only be conducted with operatorAddress or consensusAddress. +- 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. @@ -78,6 +78,8 @@ There are two approaches to update the nodes: 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; +> For security reasons, users should use agentAddress to modify NodeID first. + #### 4.2.2 Update on node start 1. Validator node operator needs to add or remove NodeIDs in validator config file; From 0bfa7aa00a143a348192666f0f4ff6003c116be9 Mon Sep 17 00:00:00 2001 From: galaio Date: Thu, 24 Apr 2025 19:57:08 +0800 Subject: [PATCH 4/5] BEP: fix some comments; --- BEPs/BEP-563.md | 30 +++++++++++++++++------------- 1 file changed, 17 insertions(+), 13 deletions(-) diff --git a/BEPs/BEP-563.md b/BEPs/BEP-563.md index bcd1e2c3..69d26410 100644 --- a/BEPs/BEP-563.md +++ b/BEPs/BEP-563.md @@ -18,7 +18,7 @@ - [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.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) @@ -71,21 +71,25 @@ And there are some rules: There are two approaches to update the nodes: -#### 4.2.1 Update on web page +#### 4.2.1 New Interfaces of StakeHub contract -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; +The StakeHub system contract will provide two new interfaces to add and remove NodeIDs respectively: -> For security reasons, users should use agentAddress to modify NodeID first. +```solidity + function addNodeIDs(bytes32[] calldata newNodeIDs) external; + function removeNodeIDs(bytes32[] calldata targetNodeIDs) external; +``` -#### 4.2.2 Update on node start +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. -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.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 @@ -98,7 +102,7 @@ There are two approaches to update the nodes: 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. +- 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 From 4bec5485cbfa106428e01d7c282322040e28ed24 Mon Sep 17 00:00:00 2001 From: galaio <12880651+galaio@users.noreply.github.com> Date: Fri, 16 May 2025 13:34:39 +0800 Subject: [PATCH 5/5] Update BEPs/BEP-563.md Co-authored-by: zzzckck <152148891+zzzckck@users.noreply.github.com> --- BEPs/BEP-563.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/BEPs/BEP-563.md b/BEPs/BEP-563.md index 69d26410..6b3c9bdc 100644 --- a/BEPs/BEP-563.md +++ b/BEPs/BEP-563.md @@ -94,7 +94,7 @@ It’s important to note that this process is not part of the consensus mechanis ### 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. +- 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