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: 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.

Check out our Staking Flow v3 Guide to reduce node data storage:
https://we.incognito.org/t/13811

12 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.

2 Likes

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?

Protocol update:
Currently, new stakers from sync pool have a chance to be assigned in the middle of the pending queue.
To prevent unfair earning, we implemented new mechanism which postpone node from Sync pool to Pending pool.
The delay is 1/2 pending cycle which is ~25 epochs.

5 Likes

A Pending cycle is no longer the amount of time a Node needs to fully sync the beacon chain? EDIT: Think first … then type, lol.

Pending queue is 200 nodes, half is 100. So we need ~25 epoch to take half of pending nodes out( each epoch take 4 out).
We still wait for a node to finish their sync process, before going to pending queue

3 Likes

I completely whiffed that one. Read “Pending cycle” was thinking “Sync cycle”.

2 Likes

Does this mean you can’t bootstrap the shard now?

@Josh_Hamon,

You can still bootstrap but after it finishes it will just wait until moved to Pending.

1 Like

Just to be clear the process is the following?

Stake node – 1 epoch to waiting for syncing pool – 25 epochs in syncing pool – pending pool – committee.

Both the beacon and shard data will start downloading and sync during the 25 epoch phase. Bootstrapping can still occur. The 25 epoch wait was made to avoid a new node coming in and getting selected right away compared with existing nodes waiting for selection i.e. no queue jumping!

3 Likes

Yes, that looks like a good summary and overview to me.

To emphasize the queue jumping. Previously new or re-staked nodes were slotted in randomly and as needed by the network. This sometimes would mean these new/re-staked nodes could earn very fast compared to some nodes that were waiting to be selected.

Gotcha! Thank you!

I’m a bit confused. How is this calculated exactly? I staked a new node on Dec 27th (6 days ago) and it went into committee this morning and has now already earned. That’s roughly 35 epochs after staking. The current pending time on shard 5 is 56 epochs. Should I keep staking and unstaking to earn more? :wink: