[Shipped] Dynamic committee size

This received 5/5 vote and is funded @dungtran. Congrats! I will move this under “funded projects”.

Annie

3 Likes

Update on May 8th, 2020

Work with @ruler regarding randomly assign nodes to shard

Note: To avoid the join-leave attack (attacker would like to send its nodes into the same shards), unstake is executed only when it’s in the common pool.

  • Committee size: taking into account the feasibility of Ethereum bridge feature.

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-150 committee members

  • The size of the waiting list is 100-200% of the current committee size
    1. Committee size is unchanged, 10% of committee members are replaced at each epoch.
  • If number of candidates in waiting list > 200% of the current committee size
    1. Increase committee size by up to 15% of the current committee size.
    2. 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
    1. Reduce the committee size by up to 10% and keep committee size not less than 30.
    2. While committee size reduces, replace 10% of current committee members (after reduced).

Case 3. Greater than 150 committee members

  • If the size of the waiting list is 400% of the current committee size, every additional 100% of the current committee size the staking amount increased by 1750 PRV for new staking nodes.

For example:
- 400-500% in waiting list, new staking amount = 1750 + 1750 = 3500PRV.
- 500-600% in waiting list, new staking amount = 3500 + 1750 = 5250PRV.
and so on.

Based on our analysis in the post on April 24th, the size of the waiting list is proportional to the security of the chain, but the earning of the validators is reduced. Hence to give credit for early adoption validators, increasing the staking amount for late one is reasonable.

We continue working on the problem of balancing shard committee size

6 Likes

Update on May 15th, 2020
Our weekly progress has been update in this document: https://docs.google.com/document/d/19KChrg0B2LmfT_t-K8vovCG-mXUkAYG88j5FQsKPXT4/edit?usp=sharing

Achievement:

  1. Define more specific constraints in section 1
  2. Re-structuring role of nodes in shard pool. Refine staking flow, link.
  3. New swapping rule, which satisfies pre-defined constraints
  4. Incognito chain will give beacon node more power, which make them be able to fully verify shard block

Next Research Problem:

  1. How we handle faulty block?
  2. How to handle data availability in one shard?
  3. What will chain do next if a faulty block is found
  4. Dynamic sharding
  5. Draw more details activity chart for each operation
4 Likes

You are doing a great job @hungngo ! Thank you for being one of the technical saviors of Incognito!

2 Likes

thanks a lot @raz

1 Like

Update on May 22th, 2020

Achievement:

  1. Agreement on new feature beacon node: be able to verify all shard (all transactions and block).
  2. Agreement on all problem statement and solutions (provided in link below)
  3. Proposed implementation roadmap

Notice:

  • Some of minor issue or not urgent issue we still leave un-solved. Because, the more time we have, the more information and knowledge we occupy. Team will solve all any unclear problems later.

Our weekly progress has been update in this document: https://docs.google.com/document/d/19KChrg0B2LmfT_t-K8vovCG-mXUkAYG88j5FQsKPXT4/edit?usp=sharing

6 Likes

Dear everyone, we are moving to implementation phase, follow us on Dynamic committee size and dynamic sharding: implementation phase

3 Likes