REP-33: Node State Transition

RSS3 Evolution Proposal
1

This proposal outlines every potential Node state and the transitions between them.

A Node can be in 1 of 7 possible operational states:

  1. Registered: the Node is registered on the VSL, with sufficient deposit.
  2. Initializing: the Node is operating on the DSL. Automated tasks will be executed at this stage to ensure the Node is in a healthy condition. This state applies to the initial startup or the first startup following any change in the Node’s coverage.
  3. Online: the Node is operational.
  4. Offline: the Node is not operational.
  5. Exiting: the Node is going to exit the Network.
  6. Exited: the Node has exited the Network.
  7. Slashed: the Node is slashed.

The figure shows all the possible transition paths for a Node.

image
image2000×1576 194 KB

6 Likes
2

We definitely need to discuss this further to turn this into an REP. The descriptions of each state require further elaboration.

How long should the grace period for a Node to transit into exited be?

2 Likes
3

The REP draft has been prepared!

2 Likes
4

I have created a PR to update the status of this REP to review.

1 Like
5

Waiting for an epoch to complete the necessary tasks should allow for an exit.

6

yeah, making exiting last 1 epoch only makes sense.

1 Like
7

So the state offline needs some clarifications:

  1. In the figure, “online → offline, its Po dropped below the required deposit”. this should not happen as when the deposit requirement isn’t met, the contract should move it into “exiting” immediately, and GIs should monitor that event on VSL.
  2. “slashed → offline”, this should not happen too, the state “slashed” should be permanent until the Operator manually confirms it’s ready to be online again.
2 Likes
8

So ideally, the contract should return the Node’s current state.

This should reduce GIs’ responsibility to maintain states, GIs only need to:

  • at the beginning of each epoch, fetch all states from VSL
  • during an epoch, monitor and submit demotions immediately as they happen (per REP draft on Demotion and Slashing Mechanism), the contract should keep a demotion counter, and automatically slashes when it hits the threshold. GIs may keep a local counter and check against VSL when it hits the threshold (to make it easier), then GIs do their usual stuff, removing Nodes from the distribution pool etc.
3 Likes
9

If a node does not have sufficient deposit, should it also be marked with a status of None? @Henry

10

Yes, I think there are implied rules that should be stated in the proposal.

nil state should be the initial state upon registration, until all requirements are met. Think of this as the “verify your email” step for a typical registration process. Only then, a Node is fully registered. So far, this only concerns the Node’s status on VSL.

Any states after “registered” should take the Node’s status on both VSL and DSL into consideration.

2 Likes
11

Hi all, the results of the above discussions have been updated in REP-33: refine the definitions of some Node states (#42) · RSS3-Network/REPs@c5b8afb · GitHub

2 Likes
12

I think we need a clearer version of the state transition diagram, listing all the possible paths. Also there are many cases not covered by the proposed states, many rules not explicitly stated in the proposal. This REP will require a lot of work to push forward its status.

2 Likes
13

I completely agree. The current proposal needs clearer state transitions and better rule explanations. We are actively working on improving these aspects.

1 Like