Dynamic committee size
1. What problem are you solving?
Problem 1. Incognito currently employs a fixed committee set up. In practice, the number of validators will change over time, so should the size of the committee.
Some considerations:
- The relationship between committee size and validators on the waiting list. If the committee size is much larger than number of candidates, there will not be enough backup validators. If the committee size is too small, candidates may have to wait a long time to be selected.
- Number of committee members are rotated in each epoch. If itâs small then the candidate validators may wait too long, if itâs too big then the new committee at the beginning of each epoch may not be stable.
Problem 2. Issues arise if members of a shard committee suddenly go offline or disconnect from the majority group. The committee will not be able to collect â +1 votes to commit new blocks or a new committee when the epoch is over. We need a mechanism which allows the system to automatically replace offline validators, or reduce committee size to ensure the liveness of the chain.
Problem 3. Validator availability may vary. Contributions towards building a durable chain may vary. Some validators be running out dated software, broken hardware, or drop out of their own intent, which may harm the stability of the system. Therefore, slashing is put in place to ensure balance, integrity and durability of the system.
2. What is our solution?
Preliminaries
Preparation node: Staking done â Assigned to a Shard â Start downloading shard database.
Candidate node: Finish downloading shard database â ready to join the committee.
Initial approaches
Problem 1.
The proposed protocol should respect the following properties:
- Safety: maintain a balance between committee size and the number of candidates in the waiting list.
- Stability: when adjusting the committee size, increase/decrease a reasonable number of committee members to ensure the stability of the system.
Case 1. Fewer than 30 committee members
- Assign all candidates to committees, i.e allow empty waiting list
- No lower bound of committee members
Case 2. 30-300 committee members
- The size of the waiting list is 100-120% of the current committee size
- Committee size is unchanged, 10% of committee members are replaced at each epoch.
- If number of candidates in waiting list > 120% of the current committee size
- Increase committee size by up to 15% of the current committee size. Keep the size of the waiting list at least 100% of the committee size.
- While the committee size increases, donât replace any current committee members.
- If the number of candidates in waiting list < 100% of the current committee size
- Reduce the committee size by up to 10%, until the size of the waiting list is equal to the size of the current committee.
- While committee size reduces, replace 10% of current committee members (after reduced).
Case 3. Greater than 300 committee members
- If the size of the waiting list is 120%-180% of the current committee size
- Committee size is unchanged, 10% of committee members are replaced at each epoch.
- If the number of candidates in the waiting list > 180% current committee size
- Increase committee size by up to 10% of current committee size. Keep the size of the waiting list at least 150% of the committee size.
- While the committee size increases, donât replace any current committee members.
- If the number of candidates in the waiting list < 120% of the current committee size
- Reduce the committee size by up to 8% until the waiting list is equal to the size of the current committee.
- While reducing the committee size, replace 10% of current committee members.
- Note: In a situation where increasing the committee size causes a system overload and â +1 signatures cannot be obtained, reverse to the previous committee size, and stop increasing the committee size for 100 epochs (~ 2 weeks).
Problem 2.
If a significant number of current committee members are disconnected, the beacon is responsible for changing the committee of any shard with the proof of failure from shard nodes. In order to do that, beacon nodes have to keep track of the shard nodes during the time where they failed to produce new blocks.
The new committee flow (if not enough signatures are collected) is depicted in fig 1.
Fig 1. Update committee size when >=â members are disconnected.
Problem 3.
When it comes to slashing, we prefer a light punitive approach â i.e. a slashing policy that does not deduct any PRV from the stake/reward of the validators. However the policy must effectively prevent misbehavior and unreliability.
% of missing votes when in the committee | Minimum # of epochs: node has to wait before rejoining the candidate list |
---|---|
11-20 | 2 |
21-30 | 4 |
31-40 | 8 |
41-50 | 16 |
51-60 | 32 |
61-70 | 64 |
> 70% | 128 |
3. Which solutions do people resort to because this doesnât exist yet
NA
4. Who are you?
Hi, iâm @dungtran, part of the research & development team at Incognito. We believe decentralization and autonomous operation are two of the most beautiful properties of blockchain technology. We work to help Incognito achieve those targets.
5. Why do you care?
The Incognito chain currently fixes parameters such as: committee size, conditions to be a candidate, and no slashing policy. We need a mechanism that allows the chain to automatically find the appropriate parameters for any given situation. This is important, if a system is to maintain stability and balance by itself.
6. Whatâs your plan? Whatâs your schedule?
The solutions detailed above will be complete in 1 month.
1st week | Literature review, find different approaches around these problems |
---|---|
2nd week | Propose appropriate approaches for the Incognito chain |
3rd week | Criticism |
4th week | Finalize the solution |
Future weeks | Implementation if approved |
7. Whatâs your budget?
1 researcher 2000 PRV/mo
8. Is there an existing conversation around this idea?
Proof-of-stake (PoS) is a consensus algorithm for blockchain networks. It is based on a randomly selected state of validators who âstakeâ the native network tokens by locking them into the blockchain to produce and approve blocks. However, validator misbehavior (whether intentional or not) is unavoidable. PoS blockchains take different approaches in handling misbehavior. These approaches can be classified into two groups:
Non punitive projects: Aion [1], Algorand [2], and Tezos [3] stand out as they do not punish delegators at any time, although Tezos does include a variant of slashing for validators in order to protect the network. Tezosâ non-punitive approach to delegating is to require an initial 21-day period before generating rewards (with Tezos offering a high stake).
Punitive projects: Cosmos [4], Livepeer [5] and ICON [6] have chosen a higher degree of severity to make both delegators and validators accountable for protocol violations made by the validator. Cosmos operates in a similar rewards environment as Tezos, despite having one of the highest double-signing slashing parameters.
References
[2] https://www.algorand.com/what-we-do/technology/algorand-protocol
[3] https://tezos.com/static/white_paper-2dc8c02267a8fb86bd67a108199441bf.pdf
[4] https://cosmos.network/cosmos-whitepaper.pdf
[5] https://github.com/livepeer/wiki/blob/master/WHITEPAPER.md
[6] http://docs.icon.foundation/ICON-Whitepaper-EN-Draft.pdf