The committes page can be hard to understand.
Let’s break it down.
COMMITTEE LISTS
At the top of the page are lists for the Beacon Committee and each of the 8 Shards (0-7).
The Beacon Committee is currently run by the Incognito Team. The seven beacon nodes are fixed and do not change.
Next are the Committee Lists; Shards 0-7 with 32 validators per each shard.
through
Index 1-22 of each shard represents a validator currently run by the Incognito Team. 22 * 8 = 176 fixed validators. These 176 validators (the first 22 per shard) do not change.
Index 23-32 of each shard are the 10 community validators. These are swapped out 5 at a time each epoch. The nodes in index slots 23-27 exit the committee at the end of the epoch/beginning of next epoch. The nodes in index slots 28-32 then move up to slots 23-27. 5 new nodes from the top of the corresponding shard pending list are moved into committee list, to index slots 28-32 in the same order as they appear in the pending list.
The previous process would swap 4 nodes each epoch, but otherwise this is the same as the previous process.
THE WAITING LIST
This is the big list of validators that have not been selected for committee. As the header reads – TO BE SELECTED AT RANDOM. Indeed nodes were previously selected at random. They are no longer.
Nodes are moved to a shard pending list directly from the top of the list.
This is different than the previous process.
The order of this list is not changing.
This is different than the previous process.
Nodes exiting committee should join this list. This is no longer happening.
This is different than the previous process.
THE PENDING LIST
This is the list of all the validators plucked from the above waiting list, in preparation to join the committee lists at the top of the page. While in this list, a node will sync the assigned shard’s chain. This used to be a much smaller period of time. It is now growing.
The order of this list does not change from epoch to epoch. Validators are pulled from the top of each shard’s list to join committee. Newly assigned validators from the waiting list join the assigned shard’s pending list at the bottom.
Other than the (still) increasing size of each shard’s list, this is the same as the previous process.
It would not have been possible to know which nodes would become validators, except for that short notice when a validator’s role was changed to “pending”. That short window has grown to 6, 14, 23, etc. epochs.
It is also now possible to even know when a validator will be assigned “pending” in n number of epochs ahead of that increasing window. This opens the network and validators up to potential exploitation.
This validator, currently in the Waiting List at position 51 for Epoch 3480, will be assigned to a shard waiting list in Epoch 3482; it will not do so in Epoch 3481. In Epoch 3481 (the next epoch) it will move up to position 1. (This will happen around block ~175 of 3481 +/- 25 blocks)
That kind of forecasting for “pending” was not previously possible. It is now. And it can be exploited to potentially attack the network. The only randomness now is which shard a validator will be assigned. The “when” of candidate selection is no longer a random unknown. Not while the Waiting List is fixed and unshuffled.
