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 1: No block growth without enough votes
Test target: When there are less than 2/3 active master nodes, XDPoS 2.0 should not grow blocks due to insufficient votes.
Test Steps:
Step 1: Stop 5 out of the 10 master nodes.
From the blockchain status, we can see that the blockchain height did not grow, which is as expected.
The node log also indicates that no new block was generated.
Test 2: Hard Forking on V1 consensus 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.
Environment Setting
- 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
I upgraded 8 nodes to v2, including 6 Masternodes. And keeps 4 Masternodes in v1 version (v1.4.4).
After v2 switch blocks 6946200, we can observe v1 nodes stop mining and v2 nodes keep mining blocks.
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!
Discussion (0)