Introducing Staking Flow V3

Preliminary

  • New stake: node submits staking transaction and it is committed.
  • Sync pool: validator sync blocks of assigned shard.
  • Pend pool: validator sync completely and ready for verifying new blocks.
  • Committee: validator votes or proposes new blocks.

Life cycle

1. New Stake phase: When a staking transaction is committed, the submitted node will be in New Stake state. This new validator will be randomly assigned to a shard. In order to balance validators among shards, the shard with a smaller number of validators would have a higher probability of receiving new staking nodes.

2. Sync phase: right after the new validator gets the assigned shard, it starts to download the shard’s blocks. It sends the notification to the chain when finishing downloading the shard’s blocks. Then it’s moved to the Pending pool. The Pending pool is a first come first serve queue, the new validator will be appended to the end of the queue.

3. Pending phase: the validator keeps sync data and waits for the committee role.

4. Committee: each validator will be selected as proposer in round robin fashion, the proposer takes responsibility to propose a new block, other committee members will vote for it. At the end of the epoch, if the validator finishes the committee role, it will be appended to the end of the Pending pool queue. Or if the validator may be slashed, it’s forced to unstake, the staking PRV will be returned to the node, however, the node won’t get any reward in the last epoch.

5. Unstake: the validator could submit an unstake transaction at any time, however if the validator is assigned to a shard already, it has to wait until it finishes its committee role.

Analysis

  • Validators don’t have to sync data from all shards, this would save a lot of disk storage.

  • Can an attacker direct all of its nodes to a single share? It’s not that easy, because the random assign algorithm is to balance all shards’ validators.

  • If the attacker has ⅓ validators in a shard, it could suspend the shard by not voting in an epoch. However it’s not able to create double spending or airdrop transactions.

  • Currently, the foundation keeps the fixed proposer list in each shard, the validators are open to the community. The consensus of each block is the agreement of the foundation and community. A single side would not be successful to create any single block.

FAQ

Q: When is Staking v3 expected to go live?
A: Staking v3 is expected to go live 1 week after slashing v2 is rolled out.

Q: As a node operator what will I need to do to prepare for Staking v3?
A: Check that your nodes are fully synced on the node monitor (monitor.incognito.org). If an issue is found (stalling) please follow our troubleshooting guides to fix it.

Q: As a node operator what will I need to do after Staking v3 is released?
A: To get your nodes assigned to a shard; nothing. However, in order to delete unneeded shard data, it will require manual steps. A guide will be published to assist both pNode & vNode operators.

Q: Is anything changing with the way nodes unstake?
A: No, nodes with a request to unstake must still enter into committee and will be unstaked after swapping out of a shard committee.

Community questions will be added and answered here in this main post. Feel free to post questions below.

9 Likes

Really awesome work!! This solves one of the biggest challenges and is going to be a game changer for validators. Can’t wait to see it live :rocket:

What happens if post-committee the node gets assigned to a new shard? will it go straight to pending or into sync phase? In case there’s a corrupted block that stalls the sync, you wouldn’t want to stay like that in pending and potentially get slashed before the issue is fixed.

1 Like

In Staking Flow v3 once you’re assigned a shard number that will be your shard number unless you unstake and restake.

1 Like

Oh I missed that, that’s pretty cool, will save on loads of storage!

1 Like

Regarding,

What is the ideal total minimum number of healthy functioning validators at which point, the foundation would consider releasing more or all of the validating work to the community validators? I don’t mean to ask for a commitment or contract from the foundation, only a mathematically ideal number (or goal) of community validators functioning well (at which point, the network could start to live and validate on its own with the foundation playing less of a role in consensus) ?

What numerical thresholds of community validators constitute important milestones for the incognito network?

1 Like

One more question to be sure I understand the new Staking Flow V3. In the node monitor “sync state” column, will ONLY the above 4 sync phase titles (“New Stake”, “Sync Pool”, “Pending Pool” or “Committee” be used or are there other terms/ categories in addition to the above that can appear in the node monitor “sync state” column?

What is the ideal total minimum number of healthy functioning validators at which point, the foundation would consider releasing more or all of the validating work to the community validators?

The unhealthy validators will be slashed right after the slashing feature is activated at the end of this month. To release more or all of the validators does not depend on the number of healthy validators, it only depends on the two developing features: Lemma2 & Byzantine detection which are expected to be on testnet sometime in October and on mainnet at the end of this year. Since the committee size will be dynamic to the number validators on the network.

What numerical thresholds of community validators constitute important milestones for the incognito network?

That is 600 healthy validators per shard, and committee size reaches 128 members.

4 Likes

Monitor Sync state column gives information about the node syncing state such as STALL, LATEST, SHARD/BEACON SYNCING. The role column will reflect node life cycle: SYNC, PENDING,COMMITEE, NOT STAKE

4 Likes

To connect role column categories to the life cycle categories listed above: I am assuming that “Sync” in role column of monitor means node is in “Sync pool”, “Pending” means “Pending pool”, “committee” means “committee” and “Not Stake” means “Not Stake”, but that leaves out the life cycle category of “new stake” which appears separate from “Sync pool”. Is the “new stake” phase so fast (meaning a node after new stake occurs will almost immediately be placed in a shard sync pool that no monitor role category of “new stake” is needed (i.e. “sync” is good enough both “new stake and sync pool”) or will the role of “new stake” also appear in the node monitor?