[Outdated & Changed] Dynamic committee size and dynamic sharding: implementation phase

[hungngo]

Update 10 Aug 2020

Finish:

• Unstake flow technical specification

In progress:

• Refactor:
  • Testing with QC team
• New Staking flow: 60%
• Unstake flow: begin implementing

[hungngo]

Update 17 Aug 2020

This week our team had a nice-to-have debate about design pattern and code structure. The new-staking-flow code is refactored based on our solution. It took us three days but will be rewarded.

In progress:

• Implementing unstake
• Refactoring code of New-staking-flow and continue to implement
• Testing finished part with QC team

[hungngo]

Update 28 Aug 2020

WONDERFUL NEWS

Finish:

• Implementation of Unstake Feature
• Implementation of New Swap/Assignment Rule

Let’s explain a little bit about these features. Both these features effect directly our dear end-user, especially those who run node.

• Unstake feature is a desirable feature since our first day. It allows user to withdraw his/her stake amount whenever user’s node in candidate list, which mean it plays no role in any shards (neither committees in block creation phase nor committees in preparation phase). In short, Unstake feature tells one how long he/she must wait to get back one’s staking amount (in PRV).

• New Swap/Assignment Rule makes Incognito’s consensus more secure and changes reward amount in short term duration.

  • The new assignment rule helps one’s node got assigned into one shard more quickly, but it must wait longer before earning something. In general, reward amount in one year might not change much. However, if you are lucky you will earn a lot more reward in the same duration compare to the current version.
  • The new swap rule allows us to development slashing feature easier.

In progres:

• Review & Testing Unstake Feature
• Review & Testing New Swap/Assignment Rule

[hungngo]

Update 21 Sep 2020

The new swap rule (swap rule v2) which is implemented last month seem not meet our needs. So far, this month we are discussing how to implement it properly. The swap rule v2 allows beacon chain to force shard chain changing shard’s committees.

In progress:

• Slashing node which continuously missing votes for blocks in one epoch
• Re-design and implement swap rule v2

[hungngo]

Update 25 Sep 2020

Finish:

• Review & Unit test swap rule v2.

In Progress:

• Implement shard block creation v2 and integrate with swap rule v2.
• Merge Code from Swap Rule V2 and continue to implement slashing module.

With this development speed, I am confident that we will finish implementing two task above by the end of next week (2 Otc 2020). After that, team will move to testing & debugging phase. I am so excited that team found a proper design for slashing flow after a couple times of trying.

[hungngo]

Update 18 Oct 2020

Finish:

• Implementation of new Shard Block Creation V2. From now on, a new shard block is only allowed to created if it find a higher beacon block. Otherwise, shard chains will stop producing new block

• New Swap (change committee) rule. This is a really big change to our consensus working mechanism. At first, we think that shard independently changing its committee after one epoch will make Incognito more secure. But seem that, it create more problem than helping the chain. The Shard chains and Beacon chain must synchronize too many kinds of information, which is very hard to get the same correct answer. The New Swap Rule, swap-rule-v2, forbid shard to change its committee by them self. Instead, the Beacon chain will force shard to change its committee. Less data to synchronize, less problem to tackle.

• Slashing module by counting missing signatures from committees in 1 epoch creation. For example, if one shard creates 100 blocks in 1 epoch, each nodes must sign at least 50 blocks or it be force un-stake. This module is carried by the Beacon chain.

• Documenting Implementation detail, integration testcase.

• Refactoring a huge amount of code which covered by thoughtful unit-test.

In progress:

• Review code
• Local testing
• Continuously defining new testcases
• Integration

I am so glad that this feature is getting much better, clearer. It took us almost five months from researching to implementation, testing. A lot of re-design, re-work was conducted. If luck is on our side, this feature will be launched in testnet by the end of this month (October).

This is our specification link: https://docs.google.com/document/d/19KChrg0B2LmfT_t-K8vovCG-mXUkAYG88j5FQsKPXT4/edit#heading=h.k9idjn4fvxia

[doc]

@hungngo

Slashing module by counting missing signatures from committees in 1 epoch creation. For example, if one shard creates 100 blocks in 1 epoch, each nodes must sign at least 50 blocks or it be force un-stake. This module is carried by the Beacon chain.

It would be useful, to me at least, that there is a process when this is rolled out that if a vNode is getting slashed there is some notification to user. Especially when this roles out, as currently I believe there may be vNodes incorrectly configured on the network, and due to the current setup the nodes are still earning even if they are missing blocks (or completely offline and unreachable). It would be nicer if when this is rolled out the nodes in committee that are not providing incorrect solutions/missing blocks were not initially penalized, but rather notified so validators could have an opportunity to fix any configuration issues they may have. Otherwise there may be quite a few validators that see drops without an understanding of why… Just something to consider.

Also,

@hungngo

For example, if one shard creates 100 blocks in 1 epoch, each nodes must sign at least 50 blocks or it be force un-stake.

Am I reading this correctly, that if your validator gets “slashed” it will be forced to unstake?

[hungngo]

@doc

Especially when this roles out, as currently I believe there may be vNodes incorrectly configured on the network, and due to the current setup the nodes are still earning even if they are missing blocks (or completely offline and unreachable).

Thanks for sharing your thoughts. We will figure out a way to notify slashed vNode via out mobile application.

@doc

It would be nicer if when this is rolled out the nodes in committee that are not providing incorrect solutions/missing blocks were not initially penalized, but rather notified so validators could have an opportunity to fix any configuration issues they may have.

The current slashing rule only force Node out of committee. The staking-amount and reward which node received in that epoch will remain intact. We assume that all our users are trying to contribute to the system. When something go wrong, node get slashed, is a kind of notification to our users their nodes are not working properly

[hungngo]

@doc

Am I reading this correctly, that if your validator gets “slashed” it will be forced to unstake?

Yes, force to unstake is the only current penalty for slashing solution. So get slashed means node will be force to unstake

[hungngo]

Update 9 Nov - 15 Nov

Finish:

• Unittest multiple instructions in one Beacon Block (Swap, Unstake, Assign, Random, Snapshot random list, Stop Auto Stake)
• Review Stop Auto Stake and Unstake metadata and instruction. These instructions will be included in blockchain whenever they can change Incognito Chain state.
• Integrate Slashing with New Staking Flow
• Sync Testnet 2, all shard and beacon, (full verification) with New Staking Flow code
• Sync Mainnet, beacon (full verification) with New Staking Flow code

[abduraman]

@hungngo

Review Stop Auto Stake

Hey @hungngo,

I examine the code for a while. I see “autostake” properties in the response of “getbeaconbeststatedetail” RPC method. Some of them are true, others are false. What is the exact usage of “autostake”? Is there any relation with the committee?

Thanks.

[hungngo]

• autostake == true means your node will automatically get into candidate list once you finish your role as committee.
• autostake == false means after you finish your role as committee, you will be completely out of Incognito Chain (no longer hold any role) and your staking will also be returned.

At this time, there’s no force unstake action or unstake rpc in Mainnet. This mode is in development and testing phase. Only stop auto stake action and stop auto stake rpc.

[doc]

@hungngo

The current slashing rule only force Node out of committee. The staking-amount and reward which node received in that epoch will remain intact. We assume that all our users are trying to contribute to the system. When something go wrong, node get slashed, is a kind of notification to our users their nodes are not working properly

@hungngo It would be very beneficial to have the notification feature put in place prior to the slash/auto unstake feature takes place. So the community members hosting vNodes and pNodes can make sure their validators are operating as they expected (solid internet connection, bandwidth, etc.). I also think that community members are trying to contribute, but what I dont want to see is a large number of validators get slashed as the new update goes live because of misconfiguration…

For example, if you look back at the info on previous post there was misinformation on whether an ETH client was needed, and it was shown that it was to validate un/shield transactions, but there are several people who do not have an eth client running as they didn’t think it was needed.

I think it is also possible that some people using WiFi connections could have more unstable connections than they realize and would only realize this if there was some sort of notification that they were getting slashed.

These are just two possible things I can think of off top of my head, and it would be beneficial to the community to get these notifications prior to the full release of the dynamic committee being released, so they can make adjustments and fix their setups without being auto unstaked.

Going to cc @Peter on here, as I think this could really fall into a community experience realm

[ning]

@doc

These are just two possible things I can think of off top of my head, and it would be beneficial to the community to get these notifications prior to the full release of the dynamic committee being released, so they can make adjustments and fix their setups without being auto unstaked.

hey @doc, thanks for this. we released a topic earlier today that gives a general overview of the release plan, briefly mentioning validator support for the transition. would be great to hear your thoughts on how best to structure that!

to all validators reading this – please feel free to share your ideas here:

2021 plan and dependencies for releasing fixed shard nodes

The Incognito network must eventually operate autonomously. One of the most important milestones is the release of fixed shard nodes, and a lot of work is being done in this department to ensure we can do so as soon as possible, as safely as possible. Since we are all eager for this milestone to be completed, here is some contextual information on what is being done behind the scenes. We’d also like to invite you to share your opinions and expectations so we can work together towards this event…

[hungngo]

@doc

I think it is also possible that some people using WiFi connections could have more unstable connections than they realize and would only realize this if there was some sort of notification that they were getting slashed.

These are just two possible things I can think of off top of my head, and it would be beneficial to the community to get these notifications prior to the full release of the dynamic committee being released, so they can make adjustments and fix their setups without being auto unstaked.

Your concern came cross our mind as well. We believe that our community is trying to help. The team will show the data of how vNodes and pNodes are working to all users, before any slashing in enable.

[hungngo]

Update 30 Nov 2020

Finish:

• QC test and stress test on Staking Flow V2 features.
• Merge code from development branch, resolve all conflicts and local test.
• Code look cleaner, easy to read, and maintain
• Dynamic-committee-size features are added into the team’s tasks. We drew some business process flow and tried to find our the bad cases.

Next:

• QC will continue testing Staking Flow V2. At the end of first week of Dec, we will try to put this on Testnet
• Complete Dynamic-committee-size business flow and move on the implementation spec

[hungngo]

UPDATE 13 DEC 2020

These two weeks, we make a lot of progress. We expect to finalize code base for staking flow V2 at the end of November. However, merge code from development branch requires QC to test from the beginning. And also, we decide a good strategy for the community to change from current version to slashing version. All the code, business rules are almost finalized. Last but not least, thanks @trungtin2qn1, @khanhj, @dungtran for your hard work.

As planned, we are try to launch Staking Flow V2 + Slashing at the end of this month.

The team moved into new features, Dynamic Committee Size feature.

1. Staking Flow V2 + Slashing Feature
   Finish:

• Merge code Slashing to Staking Flow V2
• QC business rules and stress test on Staking Flow V2 (which are finalized for team leaders’ review)
• Codebase and strategy to change from Staking Flow v1 to Staking Flow V2 + Slashing. After nodes pull the Staking Flow V2 + Slashing code, nodes will run as Staking Flow V1 mode for a certain amount of time. During this time, as the community mentioned, we also record how many signatures one node contribute to the Chain. Then it switch to Staking Flow V2 + Slashing mode.

In progress:

• QC business rules and stress test on Staking Flow V2 + Slashing.
• Team leaders code review
• Continuously conduct test in changing from Staking Flow v1 to Staking Flow V2 + Slashing

2. Dynamic Committee Size features:

Finish:

• Elicit ambiguous requirements from Research Document.
• Document: Process Business Flow Diagram, Class Diagram, User Story

In Progress:

• Implement Swap rules in Dynamic Committee Size features

[hungngo]

UPDATE 28 DEC 2020

Staking Flow V2 + Slashing

Finish:

• WONDERFUL NEWS, we finish QC local testing and ready to deploy into testnet
• As every expected, the team integrated the signature counter into Staking Flow V1. The result of number of signature will be shown to all user before Slashing is enable.

Next Step:

• Sync Testnet and Deploy into Testnet

Staking Flow V3 + Dynamic Committee Size

Finish:

• Business Process of Staking Flow V3 and refine Dynamic Committee Size rules to fit the new staking flow v3
• Refactor code

Next:

• Test code after refactoring
• Review and refine the document
• Begin implementation after the document and codebase is ready

[Tempestblack]

Hey Hungngo thank you for the awesome update news…the way this year has been (Covid and all the illness worldwide)…it is always good to hear about good news to wrap up the year…thank you once again…

[trungtin2qn1]

UPDATE 26 FEB 2021

Staking Flow V2 + Slashing

Finish:

• Deploy feature Staking Flow V2 on testnet

• Merge code from Staking Flow V2 feature with mainnet code.

Next Step:

• Waiting for Multiview feature release on mainnet for deploying Staking Flow V2 to mainnet

Staking Flow V3 + Dynamic Committee Size

Finish:

• Implementation lifecycle of validator part in Staking Flow V3

• Unit test lifecycle of validator part in Staking Flow V3

• Refactor codebase along side with testing

Next:

• Local test for lifecycle of validator part in Staking Flow V3

• Implement producing block by index of committees and beacon block height