You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After [Maxwell Hardfork](https://www.bnbchain.org/en/blog/bnb-chain-announces-maxwell-hardfork-bsc-moves-to-0-75-second-block-times), the block interval will be reduced to 0.75s, which is a huge improvement in user experience for BSC, and at the same time has greater requirements for the client's network, execution and other components.
10
-
11
-
BSC introduced a new network layer optimization, Enhanced Validator Network, aka EVN. It is not a new P2P network, but based on the current P2P network to optimize the validator network and reduce the latency of core consensus messages as much as possible.
12
-
13
-
14
-
15
-
EVN only affects the networking and configuration of the validator, and does not affect other roles. At the same time, the existing network topology is similar to EVN.
16
-
17
-
## How EVN Works
18
-
19
-
The essence of EVN is to allow validators to identify each other, optimize the broadcast algorithm, and reduce the broadcast latency of core consensus messages.
20
-
21
-
EVN is a network layer optimized based on the current existing network topology and broadcast algorithm. It is still not perfect and will continue to be optimized and improved.
22
-
23
-
You can also check [BEP-563](https://github.com/bnb-chain/BEPs/blob/master/BEPs/BEP-563.md) and [BEP-564](https://github.com/bnb-chain/BEPs/blob/master/BEPs/BEP-564.md) for more details.
24
-
25
-
### NodeID Registration
26
-
27
-
The operator adds the validator’s NodeID of the P2P network on the chain through the configuration file, then the node will auto sign a registration tx.
28
-
29
-
It establishes the identity mapping from the consensus layer to the network layer.
30
-
31
-
### EVN Peer Identification
32
-
33
-
All validators/sentry will pull the on-chain registration information, identify whether the connected P2P Peer belongs to the NodeID of a validator, and mark it as an EVN Peer.
34
-
35
-
### Broadcast Optimization
36
-
37
-
Transaction broadcast is disabled between all EVN Peers, and mined blocks are broadcast to all connected EVN Peers. Non-mined blocks still use the old gossip broadcast mechanism.
38
-
39
-
### EVN Whitelist
40
-
41
-
This is an EVN whitelist that takes effect on this node. It will consider the whitelisted Peers to be EVN Peers as well and apply the EVN broadcast algorithm.
42
-
43
-
### EVN Peer Connection
44
-
45
-
Currently, EVN Peers are mainly connected directly through static nodes, allowing most EVN Peers to connect directly to each other.
46
-
47
4
## Network Requirements
48
-
49
-
At the network layer, BSC hopes to have a low enough latency so that most of the time can be used for core processes such as block packaging and block verification. The entire BSC network is relatively decentralized and is distributed in different geographic locations.
5
+
At the network layer, BSC requires minimal latency to maximize time available for critical operations like block packaging and verification. The BSC network maintains decentralization through validators distributed across diverse geographic locations worldwide.
50
6
51
7
Taking AWS's network service as an example, the measured latency of some regions are:
52
8
- AP<->EU, latency ~100ms
@@ -56,12 +12,12 @@ Taking AWS's network service as an example, the measured latency of some regions
56
12
This data will be the theoretical best value of network message latency, and it is also the reference value for network environment testing between validators.
57
13
58
14
## Configuration
15
+
There are two different modes to configure your node, depends on how your validator is connected to the network.
In this mode, the operator needs to create multiple nodes, including multiple validator nodes, multiple sentry nodes, and fullnode nodes.
20
+
In this mode, the operator could create multiple nodes, including multiple validator nodes, multiple sentry nodes, and fullnode nodes.
65
21
66
22
The validator always remains in a secure intranet environment. Sentry is responsible for quickly exchanging messages with EVN Peer and forwarding them to the validator. Fullnode is a redundant path for additional transactions and other messages.
`EVNNodeIDsToAdd` fills in the sentry nodeID here. Because the validator is protected in the external network, sentry will act as an EVN Peer to help forward public EVN Peer messages.
`EVNNodeIdsWhitelist` is an EVN Peer whitelist that is only valid for the current node. In the transition period before enabling maxwell, the whitelist can be used to apply EVN in advance. At the same time, the operator can put the cooperating builder into the local whitelist.
76
+
`EVNNodeIdsWhitelist`: it is optional and is an EVN Peer whitelist that is only valid for the current node. In the transition period before enabling maxwell, the whitelist can be used to apply EVN in advance. At the same time, the operator can put the cooperating builder into the local whitelist.
77
+
78
+
`ProxyedValidatorAddresses`: it is optional and is only for sentry to identify which blocks should be broadcast to all EVN Peers, it is configured as the protected validator address.
108
79
109
-
`ProxyedValidatorAddresses` This configuration is only for sentry. In order to let sentry identify which blocks should be broadcast to all EVN Peers, it is configured as the protected validator address.
80
+
`StaticNodes`: it includes a list of well maintained EVN nodes for validators to connect to, the list could be changed in the future.
In the current mode, the operator needs to build multiple validator nodes and expose them directly to the public network environment, so that they can directly connect to other nodes.
86
+
With simple mode, the operator could run a validator node by exposing it directly to the public network environment, so that they can directly connect to other nodes.
### Q2: Can multiple validators share sentry nodes?
15
15
16
-
Yes, for service providers who act as agents for multiple validators, they can use fewer sentries to achieve the same function. It is worth noting that the combination of validators and sentry is best to be in the same region machine.
16
+
Yes, for service providers who act as agents for multiple validators, they can use fewer sentries to achieve the same function. It is worth noting that the combination of validators and sentry is best to be in the same region machine.
17
17
18
-
### Can a validator use multiple sentry nodes?
18
+
### Q3: Can a validator use multiple sentry nodes?
19
19
20
-
Of course, multiple sentries improve redundancy and reduce message delays caused by single sentry failures. It is also recommended that validators connect to multiple fullnodes and other P2P nodes to receive more transactions and improve message redundancy.
20
+
Of course, multiple sentries improve redundancy and reduce message delays caused by single sentry failures. It is also recommended that validators connect to multiple fullnodes and other P2P nodes to receive more transactions and improve message redundancy.
21
+
22
+
### Q4: How to register other key ecosystem player into EVN network
23
+
As only validator can register evn nodeid, so they can ask validator's help to register for them. It could be useful for some key users like mev-builders, infra providers... But there is a limitation on the number of evn nodeids that each validator can register, by default it is 5, but it can be changed by governance.
After [Maxwell Hardfork](https://www.bnbchain.org/en/blog/bnb-chain-announces-maxwell-hardfork-bsc-moves-to-0-75-second-block-times), the block interval has be reduced to 0.75s, which is a huge improvement in user experience for BSC, and at the same time has greater performance requirements for the client's network, execution and other components.
7
+
8
+
BSC introduced a new network layer optimization, Enhanced Validator Network, aka EVN. It is not a new P2P network, but based on the current P2P network to optimize the validator network and reduce the latency of core consensus messages as much as possible. You can also check [BEP-563](https://github.com/bnb-chain/BEPs/blob/master/BEPs/BEP-563.md) and [BEP-564](https://github.com/bnb-chain/BEPs/blob/master/BEPs/BEP-564.md) for more details.
Node operator could add the validator’s EVN NodeIDs through the configuration file(config.toml), then the node will automatically sign a registration tx to register the node id on chain.
17
+
18
+
It establishes the identity mapping from the consensus layer to the network layer.
19
+
20
+
### EVN Peer Identification
21
+
22
+
All validators/sentry will pull the on-chain registration information, identify whether the connected P2P Peer belongs to the NodeID of a validator, and mark it as an EVN Peer.
23
+
24
+
### Broadcast Optimization
25
+
26
+
Transaction broadcast is disabled between all EVN Peers, and mined blocks are broadcast to all connected EVN Peers. Non-mined blocks still use the old gossip broadcast mechanism.
27
+
28
+
### EVN Whitelist
29
+
30
+
This is an EVN whitelist that takes effect on this node. It will consider the whitelisted Peers to be EVN Peers as well and apply the EVN broadcast algorithm.
31
+
32
+
### EVN Peer Connection
33
+
34
+
Currently, EVN Peers are mainly connected directly through static nodes, allowing most EVN Peers to connect directly to each other.
0 commit comments