go-spacemesh
go-spacemesh copied to clipboard
spacemeshos
Simplify switch to different poet services
Description
It is not easy to switch to different poet services or add new ones after the node has already registered in some for the next round. It requires manually editing the local state database (the poet_registration table) to remove the current registrations).
A nice UX would allow users to switch poet services just by editing the configuration of poet servers and restarting the node. The node should figure out that it needs to register again by itself.
Ideas for implementation
In nipost.go around: https://github.com/spacemeshos/go-spacemesh/blob/9970eecf947f13858c3dbb08414ab9c1bd199009/activation/nipost.go#L208-L212 query registrations table by nodeID and poet URL (instead of just by nodeID). This way the builder can detect if it misses any registrations (and must register) for the new poet servers and can disregard the existing registrations in poets that are no longer configured.
Anything that means users don't need to try and manually juggle or edit node_state.sql + nipost files is a very welcome update.
My feedback here is don't disregard existing registrations based on configured poet servers, wait until they're expired and unusable based on epoch.
Moving between poets without loss of rewards requires multiple configruations + registrations in the same epoch, even if only 1 is active at a time.
@reythia it is only possible to move from one poet phase to another if the new phase is later than the old one. Moving to an earlier phase is only possible by skipping one Epoch (and not getting rewards).
The reason for this is that your registration contains a reference to your previously published ATX. If you move to an earlier phase you have two options:
- drop your current registration and register at the new PoET - thereby not being able to publish an ATX this epoch and losing rewards in the next
- keep your current registration and publish an ATX this epoch but then not register at the PoETs for the old phase but wait for the registration window to open for the new phase, thereby not being able to publish an ATX next epoch and losing rewards in the epoch after that.
Either way you will have to skip rewards for one epoch in both cases. Having multiple configurations at the same time doesn't solve this.
Regarding the suggested implementation: we could go the simple approach and as you said automatically drop registrations for PoETs not in the configuration and automatically register for PoETs that are in the configuration but not in the local state.
I see a few cases where this could cause problems however:
- a user removes one of multiple PoETs from the config without changing the phase: we could drop the registration for that PoET or keep it? The phase didn't change so fetching the proof shouldn't hurt (besides the PoET maybe being offline and thereby delaying PoST proofing).
- a user adds a PoET without changing the phase: in that case we should actually make sure we don't eagerly register at the new PoET because if we do our challenge will be incorrect (wrong previous ATX reference). I think this is already the case but we should check to be sure.
I would change the criterion of dropping a registration not based on the URL but based on the configuration:
If the PoET round by that registration ends before the PoET round of the current phase starts we keep it otherwise we discard it. We (maybe) discard registrations at unknown PoETs and do not eagerly register at new PoETs in the configuration.