-
Notifications
You must be signed in to change notification settings - Fork 237
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Off-Chain Avalanche Warp Messages #729
Labels
Milestone
Comments
Follow on to this should be to create a demo upgrading OpenZeppelin upgradeable contracts via an Off-Chain Avalanche Warp Message. |
This was referenced Dec 18, 2023
We have already merged this PR Are there still remaining items for this issue? If not can we close this? |
github-project-automation
bot
moved this from Backlog 🗄️
to Done ✅
in Platform Engineering Group
Jan 29, 2024
Warp Upgradeable contracts have now been implemented via ava-labs/icm-contracts#404 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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:
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:
GetSignature(...)
to check the in-memory map for an eligible warp message, so that it will sign these as wellTesting
We should add a unit test to ensure that adding a valid/invalid message to the VM's chain config works as expected
The text was updated successfully, but these errors were encountered: