[ACP-186] Update Validator Manager

[martineckardt]

Proposes a new P-Chain tx type to update the validator manager of a Subnet

[meaghanfitzgerald]

is this referring to an instance where the validator management contract is deployed on a chain that may have stopped building blocks? if so I suggest:

Suggested change

	- Recover from misconfigurations where validator managers were set to inaccessible chains
	- Recover from incidents where the validator manager address was set to a chain that has halted or become corrupted

[martineckardt]

I was also referring to situations where the validator manager chain ID was set to the P-Chain. Another problem would arise if the validator manager was pointing to the wrong address on the C-Chain . If the latter happened on your L1 you could put a validator manager in the state there with a network upgrade, but that cannot be done on the C-Chain.

[meaghanfitzgerald]

Not sure that both the old and the new chain information needs to be conveyed by the update message, it should be enough to provide a boolean and the current active manager and address. This follows the precedent set in ACP-77 by L1ValidatorRegistrationMessage, wherein, "registered is a boolean representing the status of the validationID. If true, the validationID corresponds to a validator in the current validator set. If false, the validationID does not correspond to a validator in the current validator set, and never will in the future."

Suggested change

	// OldChainID identifies the blockchain where the old validator manager lived
	OldChainID ids.ID `json:"oldChainID"`
	// OldAddress is the address of the old validator manager
	OldAddress []byte `json:"oldAddress"`
	// NewChainID identifies the blockchain where the new validator manager lives
	NewChainID ids.ID `json:"newChainID"`
	// NewAddress is the address of the new validator manager
	NewAddress []byte `json:"newAddress"`
	// AddressUpdateID identifies attempted change in validator manager address and/or chainID for the message
	AddressUpdateID ids.ID `json:"addressUpdateID"`
	// Updated returns true if the validator manager `Address` has been updated
	Updated boolean `json:"updated"`
	// ChainID identifies the blockchainID of the active validator manager contract
	ChainID ids.ID `json:"chainID"`
	// Address identifies the contract address of the active validator manager contract
	Address []byte `json:"address"`

In this instance, Updated is a boolean representing the status of the AddressUpdateID. If true, the addressUpdateID corresponds to the current active Address and ChainID. If false, the AddressUpdateID does not correspond to these values, and never will in the future.

[martineckardt]

I was thinking to include both to make the migration from one validator manager contract to the other easier. If this was a PoS staking manager that was holding funds, having this very explicit message would allow designing a trustless migration where in a single transaction the old validator manager can be deactivated, instructed to move the funds to the new validator manager, that is then activated. If there is ambiguity of what exactly happened on the P-Chain the migration process may introduce the requirement of a trusted actor that coordinates the migration and potentially holds custody of the stake

[meaghanfitzgerald]

shouldn't this be

Validators []L1Validator `json:"validators"`

[meaghanfitzgerald]

One large question I have here is, how will the state of the validators and their rewards/ validation status be preserved when the address, and ultimately the storage slots of all the validator reward-relevant information is changed by action on a separate chain? How will we avoid race conditions between the changing state of the old validator manager contract and the valid Address of the VMC according to the P-Chain i.e. in the instance where a validator may be in the process of registering with the old VMC while the address is being changed on the P-Chain?