XDC has a target block time of 2 seconds. This gives the network 2 seconds of time to propose, verify, vote, and execute each block. If the total time taken for a block is greater than 2 seconds, then the block time of this block will be higher than 2 seconds.
Block proposal, verification, and execution are done locally by each master node and, thus, are very fast. The main factor is thus the voting latency, i.e., the time it takes a block to receive enough votes, which is determined by the network latency.
In XDPoS 1.0, voting latency is not an issue because each block only needs to receive one vote. However, to achieve the maximum BFT (Byzantine fault tolerance), with the upcoming XDC2.0 upgrade, each block needs to receive 73 votes (2/3 of the 108 master nodes). This raises the following question: is the XDC network fast enough to cope with such an increase in votes?
To answer this question, we deployed a 120-node XDC2.0 devnet globally using AWS across 5 very diverse regions (even more diverse than the current XDC mainnet), including Ohio, Ireland, Tokyo, Sydney, and San Paulo. We then measured and analyzed the voting latency for all the blocks.
The result is affirming. From 19/April to 24/April, we observed a medium (50th percentile) voting latency of only 0.52 seconds, and a 95th percentile of 1.3 seconds (meaning that the voting latency of 95% of the blocks is less than 1.3 seconds). Both are far smaller than the 2-second target.
You can also observe the devnet live here: Devnet Explorer
You will see that every two seconds, a new block is created. You will also see the geological distribution of the nodes across the 5 regions (as of 27/April/2023). We may change the set up in the future.
Thus, we conclude that, with high confidence, XDC network is fast enough to support the upcoming XDC2.0 upgrade from the voting latency and block time perspective.
In the future, we will investigate the P2P protocol optimization for the consensus engine. We welcome collaborations and contributions from the community.