This proposal outlines every potential Node state and the transitions between them.
A Node can be in 1 of 7 possible operational states:
Registered: the Node is registered on the VSL, with sufficient deposit.
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.
Online: the Node is operational.
Offline: the Node is not operational.
Exiting: the Node is going to exit the Network.
Exited: the Node has exited the Network.
Slashed: the Node is slashed.
The figure shows all the possible transition paths for a Node.
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.
“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.
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.
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.
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.
I completely agree. The current proposal needs clearer state transitions and better rule explanations. We are actively working on improving these aspects.
Hi all,
After thorough discussions and testing, we have created a state transition diagram illustrating the entire lifecycle of a node, as well as a legend showing which states are eligible for rewards at the end of an epoch. Please see the details below.
After multiple rounds of thorough discussions and revisions, we have finally completed the development and testing of tasks related to this REP. The process has not been easy, but our collective efforts have brought us here. The final status of this REP is currently awaiting approval.
