[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"`

[martineckardt]

It reuses the same data type as the conversion message. Updated the ACP to use the exact naming and refer to the current implementation

https://github.com/ava-labs/avalanchego/blob/d36f7d392bdae99a68ced5c4f6ef345ff3ce25da/vms/platformvm/warp/message/subnet_to_l1_conversion.go#L25C19-L25C52

[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?

[martineckardt]

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?

I think the PoA case is pretty straight forward. It get's difficult once there is no owner and there are tokens involved.

Ideally, the PoS VMC is involved in that flow. High level I am thinking about an initiateValidatorManagerUpdate method that locks the current state for a certain time for example. A requirement could be that there are no pending registrations, delegation and removals at that time. We could also possibly add the state root of the locked VMC state in the UpdateValidatorManagerMessage so it can be reconstructed on the new validator manager.

We also need to account for a scenario where the VMC is not available anymore, so we can't make the step above required. The L1 validator set should always have the power.

[geoff-vball]

Nearly set the chainID to the P-Chain chainID in the Validator Manager contract, or in the tx to the P-Chain? In either case, should we add a defensive check against this since it's invalid?

[martineckardt]

This specific case was on the P-Chain. I am chatting with Stephen about a separate ACP to protect against this

[geoff-vball]

What happens to in-flight weight updates? If a delegator stakes to a validator, and then the validator manager contract is migrated before the weight update message can be delivered, will that weight change still be able to be applied?

[geoff-vball]

I'm pretty sure it is not feasible to put the whole list of Validators in the message. The current P-Chain conversion message only includes the hash of the ConversionData.

[geoff-vball]

Stephen would have more insight on why, but I think it was p-chain gas