Great post @dungtran. There are two point in my mind about Dynamic Committee Size:
- Committee Auto Adjustment between epoch. After each epoch the algorithm automatically adjust the committee size of all shards and beacon, so the can balanced the number of waiting candidate as well as committee in shard. I think fixed committee size in one epoch time is still reasonable at early stage of development. Because Incognito’s epoch is relatively short, in fact it’s really short (just 3 hour), compared to 24 hours of Harmony.one and others (maybe days). So if we got an honest validator from candidate list. The probability that validator still honest in next three hour is high. It’s too little time to corrupt that validator during an epoch.
- Dynamic committee size during an epoch: I think this would help slashing become more effectively. Because Incognito Chain is using PBFT, so committee is very important to identify how many signatures proposer need to get so as to commit a block. So when nodes try to kick out some validator out of committee, we need to adjust the committee size in order to continue producing block with PBFT. In my opinion, this problem is very rare because of the assumption: we got 2f + 1 honest node in our system.
So I think Point 1 should be solved first then Point 2 next. The reason why Point 1 should be solved first because:
- Incognito Chain currently has a lot of waiting candidate in list, it’s very much unbalanced 176 node in committee and more than 1000 node in waiting list. If we balance these two number then we greatly enhance the network security. Of course this also push a lot of pressure on network bandwidth and synchronization.
- Beside committee size is algorithmically changed in a secure way. Not just waiting for an external force.
I think Point 1 match @dungtran Problem 1 then Point 2 match Problem 2. I haven’t thought much about Problem 3.