Yes, force to unstake is the only current penalty for slashing solution. So get slashed
means node will be force to unstake
[Outdated & Changed] Dynamic committee size and dynamic sharding: implementation phase
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
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.
-
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.
@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
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:
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.
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
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.
- 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
- 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
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
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ā¦
UPDATE 26 FEB 2021
Staking Flow V2 + Slashing
Finish:
-
Deploy feature
Staking Flow V2
ontestnet
-
Merge code from
Staking Flow V2
feature withmainnet
code.
Next Step:
- Waiting for
Multiview
feature release onmainnet
for deployingStaking Flow V2
tomainnet
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