Off-Chain Avalanche Warp Messages

[aaronbuchwald]

Off-Chain Avalanche Warp Messages: Signing out of Band

Subnet-EVM should support signing Avalanche Warp Messages out of band.

Signing messages out of band will enable the validator set of a subnet collaborating to sign a message that does not correspond to an on-chain event. This can be used in order to implement upgradeable smart contracts where the Subnet's validator set replaces the typical multi-sig in order to authorize an update.

Problem

If you are deploying a critical smart contract on-chain, then you have the choice between leaving that contract as immutable and upgradeable.

If you choose to make it immutable, then handling any discovered vulnerabilities in the contract may be extremely difficult.

If you choose to make it upgradeable, then you need to decide who/what has the ability to perform that upgrade, which creates a hazardous point of failure.

Therefore, authorizing a dynamic validator set to sign an out of band Avalanche Warp Message offers an alternative. There are two key advantages to this approach:

1. base upgradeability off of a dynamic subnet validator set instead of a multisig
2. support deploying upgradeable contracts at the same address across multiple chains with a unified upgrade mechanism

Solution

Subnet-EVM should add an option to its chain config https://github.com/ava-labs/subnet-evm/blob/master/plugin/evm/config.go#L83 to create an allow list of messages that the validator should be willing to sign from the warp backend: https://github.com/ava-labs/subnet-evm/blob/master/warp/backend.go.

On startup the VM should:

1. Read the list of messages included in the chain config
2. Parse each message as an Avalanche Warp Message to ensure that it's valid (fatal if an invalid message is specified)
3. Load the list of messages in-memory into the Warp Backend (should we write them to the database? leaning towards no)
4. Modify GetSignature(...) to check the in-memory map for an eligible warp message, so that it will sign these as well

Testing

We should add a unit test to ensure that adding a valid/invalid message to the VM's chain config works as expected

[aaronbuchwald]

Follow on to this should be to create a demo upgrading OpenZeppelin upgradeable contracts via an Off-Chain Avalanche Warp Message.