Avalanche L1 Precompile Config
Learn how to upgrade your Subnet-EVM precompile configuration.
You can customize Subnet-EVM based Avalanche L1s after deployment by enabling and disabling precompiles. To do this, create a upgrade.json
file and place it in the appropriate directory.
This document describes how to perform such network upgrades. It's specific for Subnet-EVM upgrades.
The document Upgrade an Avalanche L1 describes all the background information required regarding Avalanche L1 upgrades.
It's very important that you have read and understood the previously linked document. Failing to do so can potentially grind your network to a halt.
This tutorial assumes that you have already installed Avalanche-CLI. It assumes you have already created and deployed an Avalanche L1 called testblockchain
.
Generate the Upgrade File
The Precompiles documentation describes what files the network upgrade requires, and where to place them.
To generate a valid upgrade.json
file, run:
If you didn't create testblockchain
yet, you would see this result:
Again, it makes no sense to try the upgrade command if the Avalanche L1 doesn't exist. If that's the case, please go ahead and create the Avalanche L1 first.
If the Avalanche L1 definition exists, the tool launches a wizard. It may feel a bit redundant, but you first see some warnings, to draw focus to the dangers involved:
Go ahead and select Yes
if you understand everything and you agree.
You see a last note, before the actual configuration wizard starts:
Refer to Precompiles for a description of available precompiles and how to configure them.
Make sure you understand precompiles thoroughly and how to configure them before attempting to continue.
For every precompile in the list, the wizard guides you to provide correct information by prompting relevant questions. For the sake of this tutorial, select Transaction Allow List
. The document Restricting Who Can Submit Transactions describes what this precompile is about.
This is actually common to all precompiles: they require an activation timestamp. If you think about it, it makes sense: you want a synchronized activation of your precompile. So think for a moment about when you want to set the activation timestamp to. You can select one of the suggested times in the future, or you can pick a custom one. After picking Custom
, it shows the following prompt:
The format is YYYY-MM-DD HH:MM:SS
, therefore 2023-03-31 14:00:00
would be a valid timestamp. Notice that the timestamp is in UTC. Please make sure you have converted the time from your timezone to UTC. Also notice the ✗
at the beginning of the line. The CLI tool does input validation, so if you provide a valid timestamp, the x
disappears:
The timestamp must be in the future, so make sure you use such a timestamp should you be running this tutorial after 2023-03-31 14:00:00
.
After you provided the valid timestamp, proceed with the precompile specific configurations:
This will enable the addresses added in this section to add other admins and/or add enabled addresses for transaction issuance. The addresses provided in this tutorial are fake.
However, make sure you or someone you trust have full control over the addresses. Otherwise, you might bring your Avalanche L1 to a halt.
The prompting runs with a pattern used throughout the tool:
- Select an operation:
Add
: adds a new address to the current listDelete
: removes an address from the current listPreview
: prints the current list
More info
prints additional information for better guidance, if available- Select
Done
when you completed the list
Go ahead and add your first address:
Add another one:
Select Preview
this time to confirm the list is correct:
If it looks good, select Done
to continue:
Add one such enabled address, these are addresses which can issue transactions:
After you added this address, and selected Done
, the tool asks if you want to add another precompile:
If you needed to add another one, you would select Yes
here. The wizard would guide you through the other available precompiles, excluding already configured ones.
To avoid making this tutorial too long, the assumption is you're done here. Select No
, which ends the wizard.
This means you have successfully terminated the generation of the upgrade file, often called upgrade bytes. The tool stores them internally.
You shouldn't move files around manually. Use the export
and import
commands to get access to the files.
So at this point you can either:
- Deploy your upgrade bytes locally
- Export your upgrade bytes to a file, for installation on a validator running on another machine
- Import a file into a different machine running Avalanche-CLI
How To Upgrade a Local Network
The normal use case for this operation is that:
- You already created an Avalanche L1
- You already deployed the Avalanche L1 locally
- You already generated the upgrade file with the preceding command or imported into the tool
- This tool already started the network
If the preceding requirements aren't met, the network upgrade command fails.
Therefore, to apply your generated or imported upgrade configuration:
A number of checks run. For example, if you created the Avalanche L1 but didn't deploy it locally:
Go ahead and deploy first your Avalanche L1 if that's your case.
If you already had deployed the Avalanche L1 instead, you see something like this:
Select Existing local deployment
. This installs the upgrade file on all nodes of your local network running in the background.
Et voilà. This is the output shown if all went well:
There is only so much the tool can do here for you. It installed the upgrade bytes as-is as you configured respectively provided them to the tool. You should verify yourself that the upgrades were actually installed correctly, for example issuing some transactions - mind the timestamp!.
Apply the Upgrade to a Public Node (Fuji or Mainnet)
For this scenario to work, you should also have deployed the Avalanche L1 to the public network (Fuji or Mainnet) with this tool. Otherwise, the tool won't know the details of the Avalanche L1, and won't be able to guide you.
Assuming the Avalanche L1 has been already deployed to Fuji, when running the apply
command, the tool notices the deployment:
If not, you would not find the Fuji
entry here.
This scenario assumes that you are running the fuji
validator on the same machine which is running Avalanche-CLI.
If this is the case, the tool tries to install the upgrade file at the expected destination. If you use default paths, it tries to install at $HOME/.avalanchego/chains/
, creating the chain id directory, so that the file finally ends up at $HOME/.avalanchego/chains/<chain-id>/upgrade.json
.
If you are not using default paths, you can configure the path by providing the flag --avalanchego-chain-config-dir
to the tool. For example:
Make sure to identify correctly where your chain config dir is, or the node might fail to find it.
If all is correct, the file gets installed:
If however the node is not running on this same machine where you are executing Avalanche-CLI, there is no point in running this command for a Fuji node. In this case, you might rather export the file and install it at the right location.
To see the instructions about how to go about this, add the --print
flag:
The instructions also show the content of your current upgrade file, so you can just select that if you wish. Or actually export the file.
Export the Upgrade File
If you have generated the upgrade file, you can export it:
Just provide a valid path to the prompt, and the tool exports the file there.
You can now take that file and copy it to validator nodes, see preceding instructions.
Import the Upgrade File
You or someone else might have generated the file elsewhere, or on another machine. And now you want to install it on the validator machine, using Avalanche-CLI.
You can import the file:
An existing file with the same path and filename would be overwritten.
After you have imported the file, you can apply
it either to a local network or to a locally running validator. Follow the instructions for the appropriate use case.
Last updated on