In this report, we cover the following two test cases
- The 2.0 protocol should not confirm new blocks if the voting power threshold is not reached
- In case a subset of the master nodes does not upgrade to 2.0, these outdated nodes will create a hard fork. (But Liam, your experiment showed the opposite: there was no fork.)
In brief summary: Both tests were successful.
Test target: When there are less than 2/3 active master nodes, XDPoS 2.0 should not grow blocks due to insufficient votes.
Step 1: Stop 5 out of the 10 master nodes.
Test target: Simulate real world case on main net, partial nodes doesn't upgrade to v2. We should observe mining stuck on v1 and v2 nodes keep mining.
- Network: Devnet
- Number of Master nodes: 10
- Blocks per Epoch: 900
- V1 mining nodes: 4
- V2 mining nodes: 6
- V2 mining vote thresholds: 4
- V2 first block: 6946200
At a first glance, this stalling is not as expected. But it is indeed justified. Every v1 blocks require a second master node to sign it. When the second master node has already upgraded to v2 (which is the case in our test), this block will never acquire the second signature and thus can never be confirmed.
However, if there are next masternodes available for v1 blocks, the block may grow in the very slow pace under most of nodes already upgraded to v2.
Do you have any good test cases in mind? Please share it here!