RFC-0313: Registration is not bound to an epoch

[AaronFeickert]

In RFC-0313, validator node registration binds a locked UTXO to a validator node public key through the use of a Schnorr signature, with the intent that the node operator signals its willingness to participate as a validator node.

Because this signature only binds the UTXO commitment and not an epoch, block producers can influence if and when the registration takes effect, as long as the registration transaction remains valid. It should be asserted that this is intended behavior.

[sdbondi]

Good point, block producers can always influence this because the fact that the UTXO is marked as a vn registration and the VN public key is known. By binding to the epoch we commit to a registration being valid for a particular epoch (and onwards until expiry). The registration will be disregarded by validators and the base layer since it does not validate for the current epoch i.e. the committed epoch is "too far back" from the current epoch. Is this understanding correct?

I guess we're relying on the assumption that some block producer will choose to include it timeously (perhaps by default a higher fee per gram should be used for VN reg transactions) so I suspect, for simplicity, that a registration should be considered valid when it is put into the block regardless of which epoch it was submitted. I will make this clear in the RFC.

[AaronFeickert]

I think it should depend on what the precise intent of the registration is. If it's intended to signal that the operator wishes to be a validator node for any future epoch until/unless the UTXO is invalid, then it's probably fine as is. If it's intended to signal that the operator wishes to be a validator node only for a particular epoch (perhaps it wishes to use its computational resources for something else at different times, or go offline), then it would need to bind to that epoch identifier, and the validator set algorithm needs to account for it.

Even with this binding, it is still always possible for a block producer to withhold the transaction entirely, or to delay it in an attempt to pull some kind of shenanigans (like influencing set ordering). But at least you could mitigate some of the effects of this if desired.

[AaronFeickert]

Can this be reopened? Discussion on this issue is still ongoing.