search

aionnetwork / aion-unity-poc

Aion Unity Consensus - Proof-of-Concept
GNU General Public License v3.0
0 stars 0 forks source link

Network partition test #43

Closed iamyulong closed 5 years ago

iamyulong commented 5 years ago

The system is partitioned for X minutes, and successfully recovers.

ghost commented 5 years ago

====Scenario 1========= n1 - miner (1 cpu thread) n2 - miner (1 cpu thread) n3 - staker (1000 wei) n4 - staker (1000 wei)

blockade partition n1,n2 n3,n4 
blockade status               
NODE            CONTAINER ID    STATUS  IP              NETWORK    PARTITION  
n1              3ae8903abc18    UP      172.17.0.2      NORMAL     1          
n2              0e9f9ca8442c    UP      172.17.0.3      NORMAL     1          
n3              fbb51fb2284b    UP      172.17.0.4      NORMAL     2          
n4              c92502c67ea2    UP      172.17.0.5      NORMAL     2

Parition for 30 mins then join

blockade join           
blockade status
NODE            CONTAINER ID    STATUS  IP              NETWORK    PARTITION  
n1              3ae8903abc18    UP      172.17.0.2      NORMAL                
n2              0e9f9ca8442c    UP      172.17.0.3      NORMAL                
n3              fbb51fb2284b    UP      172.17.0.4      NORMAL                
n4              c92502c67ea2    UP      172.17.0.5      NORMAL

=======================

View from n1 after partition:

get block info from 3801 to 3822
total pos:0 --- 0%
total pow:22 --- 100%
                                  Key                                Type    Total Block     %overall
0x1111111111111111111111111111111111111111111111111111111111111111  Pow 13  59.09090909090909%
0x2222222222222222222222222222222222222222222222222222222222222222  Pow 9   40.909090909090914%

View from n3 after partition:

get block info from 3801 to 3822
total pos:22 --- 100%
total pow:0 --- 0%
                                  Key                                Type    Total Block     %overall
0xA06586f27e6C4e218183CdE720931B35056d3857B52B8aA28afbF0dB110cAC03  Pos 15  68.18181818181817%
0xa0D9342Bc958587c8f14781EB6B124f68336d3921732a111343f11DF0E3F13Fb  Pos 7   31.818181818181817%

View from n1 after join:

➜  KPI git:(master) ✗ node reward.js
Latest block number: 3898
Fetching data from block #3799 to #3898
get block info from 3799 to 3898
total pos:0 --- 0%
total pow:100 --- 100%
                                  Key                                Type    Total Block     %overall
0x2222222222222222222222222222222222222222222222222222222222222222  Pow 46  46%
0x1111111111111111111111111111111111111111111111111111111111111111  Pow 54  54%

View from n3 after join:

➜  KPI git:(master) ✗ node reward.js
Latest block number: 3925
Fetching data from block #3826 to #3925
get block info from 3826 to 3925
total pos:100 --- 100%
total pow:0 --- 0%
                                  Key                                Type    Total Block     %overall
0xa0D9342Bc958587c8f14781EB6B124f68336d3921732a111343f11DF0E3F13Fb  Pos 43  43%
0xA06586f27e6C4e218183CdE720931B35056d3857B52B8aA28afbF0dB110cAC03  Pos 57  56.99999999999999%
iamyulong commented 5 years ago

I can confirm this issue. Looks like it's a bug within the sync implementation.

fredericzha commented 5 years ago

should be fixed in pr #46 They have refactored the sync & p2p modules but not yet released. This old version that we are using is problematic and I repaired the problems we are having when syncing backward. attention: Please avoid configuring two nodes to be boot nodes to each other. This can lead to potential issues in the case of network partition & rejoin in the current implementation. One-way configuration is enough for them to connect.

ghost commented 5 years ago

The fix worked!

View from mining group after partition:

➜  KPI git:(master) ✗ node reward.js 250 290
Latest block number: 290
Fetching data from block #250 to #290
total pos:0 --- 0%
total pow:41 --- 100%
                                  Key                                Type    Total Block     %overall
0x1111111111111111111111111111111111111111111111111111111111111111  Pow 25  60.97560975609756%
0x2222222222222222222222222222222222222222222222222222222222222222  Pow 16  39.02439024390244%

view from staking group after partition:


➜  KPI git:(master) ✗ node reward.js 250 290
Latest block number: 343
Fetching data from block #250 to #290
total pos:41 --- 100%
total pow:0 --- 0%
                                  Key                                Type    Total Block     %overall
0xa0D9342Bc958587c8f14781EB6B124f68336d3921732a111343f11DF0E3F13Fb  Pos 20  48.78048780487805%
0xA06586f27e6C4e218183CdE720931B35056d3857B52B8aA28afbF0dB110cAC03  Pos 21  51.21951219512195%

After join, staking side chain becomes canonical chain:

➜  KPI git:(master) ✗ node reward.js 250 350
Latest block number: 365
Fetching data from block #250 to #350
total pos:100 --- 99.00990099009901%
total pow:1 --- 0.9900990099009901%
                                  Key                                Type    Total Block     %overall
0xa0D9342Bc958587c8f14781EB6B124f68336d3921732a111343f11DF0E3F13Fb  Pos 49  48.51485148514851%
0xA06586f27e6C4e218183CdE720931B35056d3857B52B8aA28afbF0dB110cAC03  Pos 51  50.495049504950494%
0x1111111111111111111111111111111111111111111111111111111111111111  Pow 1   0.9900990099009901%
ghost commented 5 years ago

====Scenario 2========= n1 - miner (1 cpu thread) n2 - miner (1 cpu thread) n3 - staker (1000 wei) n4 - staker (1000 wei)

➜  blockade git:(master) ✗ blockade partition n1,n3 n2,n4 
➜  blockade git:(master) ✗ blockade status                
NODE            CONTAINER ID    STATUS  IP              NETWORK    PARTITION  
n1              fde99c206c40    UP      172.17.0.2      NORMAL     1          
n2              1173073a637c    UP      172.17.0.3      NORMAL     2          
n3              904845e1d083    UP      172.17.0.4      NORMAL     1          
n4              0302462805b3    UP      172.17.0.5      NORMAL     2
ghost commented 5 years ago

While partitioned: View from n1,n3 group:

➜  KPI git:(master) ✗ node reward.js 900 1000
Latest block number: 1009
Fetching data from block #900 to #1000
total pos:59 --- 58.415841584158414%
total pow:42 --- 41.584158415841586%
                                  Key                                Type    Total Block     %overall
0x1111111111111111111111111111111111111111111111111111111111111111  Pow 42  41.584158415841586%
0xA06586f27e6C4e218183CdE720931B35056d3857B52B8aA28afbF0dB110cAC03  Pos 59  58.415841584158414%

View from n2,n4 group:

➜  KPI git:(master) ✗ node reward.js 900 1000
Latest block number: 1038
Fetching data from block #900 to #1000
total pos:65 --- 64.35643564356435%
total pow:36 --- 35.64356435643564%
                                  Key                                Type    Total Block     %overall
0x2222222222222222222222222222222222222222222222222222222222222222  Pow 36  35.64356435643564%
0xa0D9342Bc958587c8f14781EB6B124f68336d3921732a111343f11DF0E3F13Fb  Pos 65  64.35643564356435%
ghost commented 5 years ago

After join: view from n1,n3 group

➜  KPI git:(master) ✗ node reward.js
Latest block number: 1083
Fetching data from block #984 to #1083
total pos:60 --- 60%
total pow:40 --- 40%
                                  Key                                Type    Total Block     %overall
0x1111111111111111111111111111111111111111111111111111111111111111  Pow 40  40%
0xA06586f27e6C4e218183CdE720931B35056d3857B52B8aA28afbF0dB110cAC03  Pos 60  60%

view from n2,n4 group:

➜  KPI git:(master) ✗ node reward.js
Latest block number: 1091
Fetching data from block #992 to #1091
total pos:64 --- 64%
total pow:36 --- 36%
                                  Key                                Type    Total Block     %overall
0xa0D9342Bc958587c8f14781EB6B124f68336d3921732a111343f11DF0E3F13Fb  Pos 64  64%
0x2222222222222222222222222222222222222222222222222222222222222222  Pow 36  36%
fredericzha commented 5 years ago

scenario reproduced and bug confirmed. When chain A has a higher best block number and chain B has a higher total difficulty, there is a problem for chain A to successfully sync from chain B. fixing...

fredericzha commented 5 years ago

fixed in pr #48

ghost commented 5 years ago

==== Scenario 3========= n1 - miner (1 cpu thread) n2 - miner (1 cpu thread) n3 - staker (2000 wei) n4 - staker (1000 wei)

blockade partition n1,n3 n2,n4

Group n1,n3 fork becomes canonical chain after join.

➜  KPI git:(master) ✗ node reward.js
Latest block number: 3038
Fetching data from block #2939 to #3038
total pos:59 --- 59%
total pow:41 --- 41%
                                  Key                                Type    Total Block     %overall
0xA06586f27e6C4e218183CdE720931B35056d3857B52B8aA28afbF0dB110cAC03  Pos 58  57.99999999999999%
0x1111111111111111111111111111111111111111111111111111111111111111  Pow 41  41%
0xa0D9342Bc958587c8f14781EB6B124f68336d3921732a111343f11DF0E3F13Fb  Pos 1   1%
ghost commented 5 years ago

==== Scenario 4========= n1 - miner (1 cpu thread) n2 - miner (2 cpu thread) n3 - staker (1000 wei) n4 - staker (1000 wei)

blockade partition n1,n3 n2,n4

Time t after partition, change staking to as below

n1 - miner (1 cpu thread) n2 - miner (2 cpu thread) n3 - staker (3000 wei) n4 - staker (1000 wei)

The result shows that n1,n3 partition's total difficulty will surpass n2,n4 partition eventually