On Fuji Testnet

Note

This document describes how to use the new Avalanche-CLI to deploy an Avalanche L1 on Fuji.

After trying out an Avalanche L1 on a local box by following this tutorial, next step is to try it out on Fuji Testnet.

In this article, it's shown how to do the following on Fuji Testnet.

Create an Avalanche L1.
Deploy a virtual machine based on Subnet-EVM.
Join a node to the newly created Avalanche L1.
Add a node as a validator to the Avalanche L1.

All IDs in this article are for illustration purposes. They can be different in your own run-through of this tutorial.

Prerequisites

1+ nodes running and fully bootstrapped on Fuji Testnet. Check out the section Nodes on how to run a node and become a validator.
Avalanche-CLI installed

Avalanche can run multiple blockchains. Each blockchain is an instance of a Virtual Machine, much like an object in an object-oriented language is an instance of a class. That's, the VM defines the behavior of the blockchain.

Subnet-EVM is the VM that defines the Avalanche L1 Contract Chains. Subnet-EVM is a simplified version of Avalanche C-Chain.

This chain implements the Ethereum Virtual Machine and supports Solidity smart contracts as well as most other Ethereum client features.

Fuji Testnet

For this tutorial, it's recommended that you follow Run an Avalanche Node Manually and this step below particularly to start your node on Fuji:

To connect to the Fuji Testnet instead of the main net, use argument --network-id=Fuji

Also it's worth pointing out that it only needs 1 AVAX to become a validator on the Fuji Testnet and you can get the test token from the faucet. If you already have an AVAX balance greater than zero on Mainnet, paste your C-Chain address there, and request test tokens. Otherwise, please request a faucet coupon on Guild. Admins and mods on the official Discord can provide testnet AVAX if developers are unable to obtain it from the other two options.

To get the NodeID of this Fuji node, call the following curl command to info.getNodeID:

curl -X POST --data '{
    "jsonrpc":"2.0",
    "id"     :1,
    "method" :"info.getNodeID"
}' -H 'content-type:application/json;' 127.0.0.1:9650/ext/info

The response should look something like:

{
  "jsonrpc": "2.0",
  "result": {
    "nodeID": "NodeID-5mb46qkSBj81k9g9e4VFjGGSbaaSLFRzD"
  },
  "id": 1
}

That portion that says, NodeID-5mb46qkSBj81k9g9e4VFjGGSbaaSLFRzD is the NodeID, the entire thing. The user is going to need this ID in the later section when calling addValidator.

Note

With more data on Fuji, it may take a while to bootstrap Fuji Testnet from scratch. You can use State-Sync to shorten the time for bootstrapping.

Avalanche-CLI

If not yet installed, install Avalanche-CLI following the tutorial at Avalanche-CLI installation

Private Key

All commands which issue a transaction require either a private key loaded into the tool, or a connected ledger device.

This tutorial focuses on stored key usage and leave ledger operation details for the Mainnet deploy one, as Mainnet operations requires ledger usage, while for Fuji it's optional.

Avalanche-CLI supports the following key operations:

create
delete
export
list

You should only use the private key created for this tutorial for testing operations on Fuji or other testnets. Don't use this key on Mainnet. CLI is going to store the key on your file system. Whoever gets access to that key is going to have access to all funds secured by that private key. To deploy to Mainnet, follow this tutorial.

Run create if you don't have any private key available yet. You can create multiple named keys. Each command requiring a key is going to therefore require the appropriate key name you want to use.

avalanche key create mytestkey

This is going to generate a new key named mytestkey. The command is going to then also print addresses associated with the key:

Generating new key...
Key created
+-----------+-------------------------------+-------------------------------------------------+---------------+
| KEY NAME  |             CHAIN             |                     ADDRESS                     |    NETWORK    |
+-----------+-------------------------------+-------------------------------------------------+---------------+
| mytestkey | C-Chain (Ethereum hex format) | 0x86BB07a534ADF43786ECA5Dd34A97e3F96927e4F      | All           |
+           +-------------------------------+-------------------------------------------------+---------------+
|           | P-Chain (Bech32 format)       | P-custom1a3azftqvygc4tlqsdvd82wks2u7nx85rg7v8ta | Local Network |
+           +                               +-------------------------------------------------+---------------+
|           |                               | P-fuji1a3azftqvygc4tlqsdvd82wks2u7nx85rhk6zqh   | Fuji          |
+-----------+-------------------------------+-------------------------------------------------+---------------+

You may use the C-Chain address (0x86BB07a534ADF43786ECA5Dd34A97e3F96927e4F) to fund your key from the faucet. The command also prints P-Chain addresses for both the default local network and Fuji. The latter (P-fuji1a3azftqvygc4tlqsdvd82wks2u7nx85rhk6zqh) is the one needed for this tutorial.

The delete command of course deletes a private key:

avalanche key delete mytestkey

Be careful though to always have a key available for commands involving transactions.

The export command is going to print your private key in hex format to stdout.

avalanche key export mytestkey
21940fbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb5f0b

This key is intentionally modified.

You can also import a key by using the --file flag with a path argument and also providing a name to it:

avalanche key create othertest --file /tmp/test.pk
Loading user key...
Key loaded

Finally, the list command is going to list all your keys in your system and their associated addresses (CLI stores the keys in a special directory on your file system, tampering with the directory is going to result in malfunction of the tool).

avalanche key list
+-----------+-------------------------------+-------------------------------------------------+---------------+
| KEY NAME  |             CHAIN             |                     ADDRESS                     |    NETWORK    |
+-----------+-------------------------------+-------------------------------------------------+---------------+
| othertest | C-Chain (Ethereum hex format) | 0x36c83263e33f9e87BB98D3fEb54a01E35a3Fa735      | All           |
+           +-------------------------------+-------------------------------------------------+---------------+
|           | P-Chain (Bech32 format)       | P-custom1n5n4h99j3nx8hdrv50v8ll7aldm383nap6rh42 | Local Network |
+           +                               +-------------------------------------------------+---------------+
|           |                               | P-fuji1n5n4h99j3nx8hdrv50v8ll7aldm383na7j4j7q   | Fuji          |
+-----------+-------------------------------+-------------------------------------------------+---------------+
| mytestkey | C-Chain (Ethereum hex format) | 0x86BB07a534ADF43786ECA5Dd34A97e3F96927e4F      | All           |
+           +-------------------------------+-------------------------------------------------+---------------+
|           | P-Chain (Bech32 format)       | P-custom1a3azftqvygc4tlqsdvd82wks2u7nx85rg7v8ta | Local Network |
+           +                               +-------------------------------------------------+---------------+
|           |                               | P-fuji1a3azftqvygc4tlqsdvd82wks2u7nx85rhk6zqh   | Fuji          |
+-----------+-------------------------------+-------------------------------------------------+---------------+

Funding the Key

Do these steps only to follow this tutorial for Fuji addresses. To access the wallet for Mainnet, the use of a ledger device is strongly recommended.

A newly created key has no funds on it. Send funds via transfer to its correspondent addresses if you already have funds on a different address, or get it from the faucet at https://core.app/tools/testnet-faucet/ using your C-Chain address. If you already have an AVAX balance greater than zero on Mainnet, paste your C-Chain address there, and request test tokens. Otherwise, please request a faucet coupon on Guild. Admins and mods on the official Discord can provide testnet AVAX if developers are unable to obtain it from the other two options.
Export your key via the avalanche key export command. The output is your private key, which will help you import your account into the Core extension.
Connect Core extension to Core web, and move the test funds from C-Chain to the P-Chain by clicking Stake, then Cross-Chain Transfer (find more details on this tutorial).

After following these 3 steps, your test key should now have a balance on the P-Chain on Fuji Testnet.

Create an EVM Avalanche L1

Creating an Avalanche L1 with Avalanche-CLI for Fuji works the same way as with a local network. In fact, the create commands only creates a specification of your Avalanche L1 on the local file system. Afterwards the Avalanche L1 needs to be deployed. This allows to reuse configs, by creating the config with the create command, then first deploying to a local network and successively to Fuji - and eventually to Mainnet.

To create an EVM Avalanche L1, run the blockchain create command with a name of your choice:

avalanche blockchain create testblockchain

This is going to start a series of prompts to customize your EVM Avalanche L1 to your needs. Most prompts have some validation to reduce issues due to invalid input. The first prompt asks for the type of the virtual machine (see Virtual Machine).

Use the arrow keys to navigate: ↓ ↑ → ←
? Choose your VM:
  ▸ SubnetEVM
    Custom

As you want to create an EVM Avalanche L1, just accept the default Subnet-EVM.

Choose either Proof of Authority (PoA) or Proof of Stake (PoS) as your consensus mechanism.

? Which validator management type would you like to use in your blockchain?: 
  ▸ Proof Of Authority
    Proof Of Stake
    Explain the difference

For this tutorial, select Proof of Authority (PoA).

For more info, reference the Validator Management Contracts.

Which address do you want to enable as controller of ValidatorManager contract?: 
  ▸ Get address from an existing stored key (created from avalanche key create or avalanche key import)
    Custom

This address will be able to add and remove validators from your Avalanche L1. You can either use an existing key or create a new one. In addition to being the PoA owner, this address will also be the owner of the ProxyAdmin contract of the Validator Manager's TransparentUpgradeableProxy. This address will be able to upgrade (PoA -> PoS) the Validator Manager implementation through updating the proxy.

Next, CLI asks for the ChainID. You should provide your own ID. Check chainlist.org to see if the value you'd like is already in use.

✔ Subnet-EVM
creating Avalanche L1 test blockchain
Enter your Avalanche L1's ChainId. It can be any positive integer.
ChainId: 3333

Now, provide a symbol of your choice for the token of this EVM:

Select a symbol for your Avalanche L1's native token
Token symbol: TST

At this point, CLI prompts the user for the fee structure of the Avalanche L1, so that he can tune the fees to the needs:

Use the arrow keys to navigate: ↓ ↑ → ←
? How would you like to set fees:
  ▸ Low disk use    / Low Throughput    1.5 mil gas/s (C-Chain's setting)
    Medium disk use / Medium Throughput 2 mil   gas/s
    High disk use   / High Throughput   5 mil   gas/s
    Customize fee config
    Go back to previous step

You can navigate with the arrow keys to select the suitable setting. Use Low disk use / Low Throughput 1.5 mil gas/s for this tutorial.

The next question is about the airdrop:

✔ Low disk use    / Low Throughput    1.5 mil gas/s
Use the arrow keys to navigate: ↓ ↑ → ←
? How would you like to distribute funds:
  ▸ Airdrop 1 million tokens to the default address (do not use in production)
    Customize your airdrop
    Go back to previous step

You can accept the default -again, NOT for production-, or customize your airdrop. In the latter case the wizard would continue. Assume the default here.

The final question is asking for precompiles. Precompiles are powerful customizations of your EVM. Read about them at precompiles.

✔ Airdrop 1 million tokens to the default address (do not use in production)
Use the arrow keys to navigate: ↓ ↑ → ←
? Advanced: Would you like to add a custom precompile to modify the EVM?:
  ▸ No
    Yes
    Go back to previous step

For this tutorial, assume the simple case of no additional precompile. This finalizes the prompt sequence and the command exits:

✔ No
Successfully created genesis

It's possible to end the process with Ctrl-C at any time.

At this point, CLI creates the specification of the new Avalanche L1 on disk, but isn't deployed yet.

Print the specification to disk by running the describe command:

avalanche blockchain describe testblockchain

+------------------------------------------------------------------+
|                          TESTBLOCKCHAIN                          |
+------------+-----------------------------------------------------+
| Name       | testblockchain                                      |
+------------+-----------------------------------------------------+
| VM ID      | tGBrM94jbkesczgqsL1UaxjrdxRQQobs3MZTNQ4GrfhzvpiE8   |
+------------+-----------------------------------------------------+
| VM Version | v0.6.12                                             |
+------------+-----------------------------------------------------+
| Validation | Proof Of Authority                                  |
+------------+-----------------------------------------------------+
 
+--------------------------+
|           TOKEN          |
+--------------+-----------+
| Token Name   | TST Token |
+--------------+-----------+
| Token Symbol | TST       |
+--------------+-----------+
 
+-----------------------------------------------------------------------------------------------------------------------------------+
|                                                      INITIAL TOKEN ALLOCATION                                                     |
+---------------------+------------------------------------------------------------------+--------------+---------------------------+
| DESCRIPTION         | ADDRESS AND PRIVATE KEY                                          | AMOUNT (TST) | AMOUNT (WEI)              |
+---------------------+------------------------------------------------------------------+--------------+---------------------------+
| Main funded account | 0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC                       | 1000000      | 1000000000000000000000000 |
| ewoq                | 56289e99c94b6912bfc12adc093c9b51124f0dc54ac7a766b2bc5ccf558d8027 |              |                           |
+---------------------+------------------------------------------------------------------+--------------+---------------------------+
 
+-----------------------------------------------------------------------------------------------------------------+
|                                                 SMART CONTRACTS                                                 |
+-----------------------+--------------------------------------------+--------------------------------------------+
| DESCRIPTION           | ADDRESS                                    | DEPLOYER                                   |
+-----------------------+--------------------------------------------+--------------------------------------------+
| Proxy Admin           | 0xC0fFEE1234567890aBCdeF1234567890abcDef34 | 0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC |
+-----------------------+--------------------------------------------+--------------------------------------------+
| PoA Validator Manager | 0x0C0DEbA5E0000000000000000000000000000000 |                                            |
+-----------------------+--------------------------------------------+--------------------------------------------+
| Transparent Proxy     | 0x0Feedc0de0000000000000000000000000000000 |                                            |
+-----------------------+--------------------------------------------+--------------------------------------------+
 
+----------------------------------------------------------------------+
|                      INITIAL PRECOMPILE CONFIGS                      |
+------------+-----------------+-------------------+-------------------+
| PRECOMPILE | ADMIN ADDRESSES | MANAGER ADDRESSES | ENABLED ADDRESSES |
+------------+-----------------+-------------------+-------------------+
| Warp       | n/a             | n/a               | n/a               |
+------------+-----------------+-------------------+-------------------+

Also you can list the available Avalanche L1s:

avalanche blockchain list
go run main.go subnet list
+-------------+-------------+----------+---------------------------------------------------+------------+-----------+
|   Avalanche L1    |    CHAIN    | CHAIN ID |                       VM ID                       |    TYPE    | FROM REPO |
+-------------+-------------+----------+---------------------------------------------------+------------+-----------+
| testblockchain  | testblockchain  |     3333 | tGBrM94jbkesczgqsL1UaxjrdxRQQobs3MZTNQ4GrfhzvpiE8 | Subnet-EVM | false     |
+-------------+-------------+----------+---------------------------------------------------+------------+-----------+

List deployed information:

avalanche blockchain list --deployed
go run main.go subnet list --deployed
+-------------+-------------+---------------------------------------------------+---------------+-----------------------------------------------------------------+---------+
|   Avalanche L1    |    CHAIN    |                       VM ID                       | LOCAL NETWORK |                          FUJI (TESTNET)                         | MAINNET |
+-------------+-------------+---------------------------------------------------+---------------+-----------------------------------------------------------------+---------+
| testblockchain  | testblockchain  | tGBrM94jbkesczgqsL1UaxjrdxRQQobs3MZTNQ4GrfhzvpiE8 | Yes           | SubnetID: XTK7AM2Pw5A4cCtQ3rTugqbeLCU9mVixML3YwwLYUJ4WXN2Kt     | No      |
+             +             +                                                   +               +-----------------------------------------------------------------+---------+
|             |             |                                                   |               | BlockchainID: 5ce2WhnyeMELzg9UtfpCDGNwRa2AzMzRhBWfTqmFuiXPWE4TR | No      |
+-------------+-------------+---------------------------------------------------+---------------+-----------------------------------------------------------------+---------+

Deploy the Avalanche L1

Note

To deploy the Avalanche L1, you will need some testnet AVAX on the P-chain.

To deploy the new Avalanche L1, run:

avalanche blockchain deploy testblockchain

This is going to start a new prompt series.

Use the arrow keys to navigate: ↓ ↑ → ←
? Choose a network to deploy on:
  ▸ Local Network
    Fuji
    Mainnet

This tutorial is about deploying to Fuji, so navigate with the arrow keys to Fuji and hit enter. The user is then asked to provide which private key to use for the deployment. The deployment basically consists in running a createSubnet transaction. Therefore the key needs to have funds.

Also, this tutorial assumes that a node is up running, fully bootstrapped on Fuji, and runs from the same box.

✔ Fuji
Deploying [testblockchain] to Fuji
Use the arrow keys to navigate: ↓ ↑ → ←
? Which private key should be used to issue the transaction?:
    test
  ▸ mytestkey

Avalanche L1s are currently permissioned only. Therefore, the process now requires the user to provide which keys can control the Avalanche L1. CLI prompts the user to provide one or more P-Chain addresses. Only the keys corresponding to these addresses are going to be able to add or remove validators. Make sure to provide Fuji P-Chain addresses -P-Fuji....-.

Configure which addresses may add new validators to the Avalanche L1.
These addresses are known as your control keys. You are going to also
set how many control keys are required to add a validator.
Use the arrow keys to navigate: ↓ ↑ → ←
? Set control keys:
  ▸ Add control key
    Done
    Cancel

Enter at Add control key and provide at least one key. You can enter multiple addresses, just use one here. When finishing, hit Done. (The address provided here is intentionally invalid. The address has a checksum and the tool is going to make sure it's a valid address).

✔ Add control key
Enter P-Chain address (Ex: `P-...`): P-fuji1vaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaasz
Use the arrow keys to navigate: ↓ ↑ → ←
? Set control keys:
    Add control key
  ▸ Done
    Cancel

Finally, there is a need to define the threshold of how many keys to require for a change to be valid -there is some input validation-. For example, if the is one control key, as preceding, just enter 1. The threshold could be arbitrary depending on the needs, for example 2 of 4 addresses, 1 of 3, 3 of 5, etc., but currently this tool only works if the private key used here owns at least one control key and the threshold is 1.

✔ Enter required number of control key signatures to add a validator: 1

Here the wizard completes, and CLI attempts the transaction.

If the private key isn't funded or doesn't have enough funds, the error message is going to be:

Error: insufficient funds: provided UTXOs need 100000000 more units of asset "U8iRqJoiJm8xZHAacmvYyZVwqQx6uDNtQeP3CQ6fcgQk3JqnK"

If the private key has funds, but the control key is incorrect (not controlled by the private key), the CLI is going to create the Avalanche L1, but not the blockchain:

Avalanche L1 has been created with ID: 2EkPnvnDiLgudnf8NjtxaNcVFtdAAnUPvaoNBrc9WG5tNmmfaK. Now creating blockchain...
Error: insufficient authorization

Therefore the user needs to provide a control key which he has indeed control of, and then it succeeds. The output (assuming the node is running on localhost and the API port set to standard 9650) is going to look something like this:

Avalanche L1 has been created with ID: 2b175hLJhGdj3CzgXENso9CmwMgejaCQXhMFzBsm8hXbH2MF7H. Now creating blockchain...
Endpoint for blockchain "2XDnKyAEr1RhhWpTpMXqrjeejN23vETmDykVzkb4PrU1fQjewh" with VM ID "tGBrMADESojmu5Et9CpbGCrmVf9fiAJtZM5ZJ3YVDj5JTu2qw": http://127.0.0.1:9650/ext/bc/2XDnKyAEr1RhhWpTpMXqrjeejN23vETmDykVzkb4PrU1fQjewh/rpc

Well done. You have just created your own Avalanche L1 with your own Subnet-EVM running on Fuji.

To get your new Avalanche L1 information, visit the Avalanche L1 Explorer. The search best works by blockchain ID, so in this example, enter 2XDnKyAEr1RhhWpTpMXqrjeejN23vETmDykVzkb4PrU1fQjewh into the search box and you should see your shiny new blockchain information.

Join an Avalanche L1 as a Validator (LEGACY)

The new Avalanche L1 created in the previous steps doesn't have any dedicated validators yet. To request permission to validate an Avalanche L1, the following steps are required:

Note

Before a node can be a validator on an Avalanche L1, the node is required to already be tracking the P-Chain.

If the validator is within 24 hours of expiring on the primary network, it can't be added to the Avalanche L1.

See here on how to become a validator.

First, request permission to validate by running the join command along with the Avalanche L1 name:

avalanche blockchain join testblockchain

Note: Running join does not guarantee that your node is a validator of the Avalanche L1! The owner of the Avalanche L1 must approve your node to be a validator afterwards by calling addValidator as described in the next section.

When you call the join command, you are first prompted with the network selection:

Use the arrow keys to navigate: ↓ ↑ → ←
? Choose a network to validate on (this command only supports public networks):
  ▸ Fuji
    Mainnet

Next, there are two setup choices: Automatic and Manual configurations. As mentioned earlier, "Automatic" is going to attempt at editing a config file and setting up your plugin directory, while "Manual" is going to just print the required config to the screen. See what "Automatic" does:

✔ Automatic
✔ Path to your existing config file (or where it's going to be generated): config.json

Provide a path to a config file. If executing this command on the box where your validator is running, then you could point this to the actually used config file, for example /etc/avalanchego/config.json - just make sure the tool has write access to the file. Or you could just copy the file later. In any case, the tool is going to either try to edit the existing file specified by the given path, or create a new file. Again, set write permissions.

Next, provide the plugin directory. The beginning of this tutorial contains VMs description Virtual Machine. Each VM runs its own plugin, therefore AvalancheGo needs to be able to access the correspondent plugin binary. As this is the join command, which doesn't know yet about the plugin, there is a need to provide the directory where the plugin resides. Make sure to provide the location for your case:

✔ Path to your avalanchego plugin dir (likely avalanchego/build/plugins): /home/user/go/src/github.com/ava-labs/avalanchego/build/plugins

The tool doesn't know where exactly it's located so it requires the full path. With the path given, it's going to copy the VM binary to the provided location:

✔ Path to your avalanchego plugin dir (likely avalanchego/build/plugins): /home/user/go/src/github.com/ava-labs/avalanchego/build/plugins█
VM binary written to /home/user/go/src/github.com/ava-labs/avalanchego/build/plugins/tGBrMADESojmu5Et9CpbGCrmVf9fiAJtZM5ZJ3YVDj5JTu2qw
This is going to edit your existing config file. This edit is nondestructive,
but it's always good to have a backup.
Use the arrow keys to navigate: ↓ ↑ → ←
? Proceed?:
  ▸ Yes
    No

Hitting Yes is going to attempt at writing the config file:

✔ Yes
The config file has been edited. To use it, make sure to start the node with the '--config-file' option, e.g.
 
./build/avalanchego --config-file config.json
 
(using your binary location). The node has to be restarted for the changes to take effect.

It's required to restart the node.

If choosing "Manual" instead, the tool is going to just print instructions. The user is going to have to follow these instructions and apply them to the node. Note that the IDs for the VM and Avalanche L1s is going to be different in your case.

✔ Manual
 
To setup your node, you must do two things:
 
1. Add your VM binary to your node's plugin directory
2. Update your node config to start validating the Avalanche L1
 
To add the VM to your plugin directory, copy or scp from /tmp/tGBrMADESojmu5Et9CpbGCrmVf9fiAJtZM5ZJ3YVDj5JTu2qw
 
If you installed avalanchego manually, your plugin directory is likely
avalanchego/build/plugins.
 
If you start your node from the command line WITHOUT a config file (e.g. via command
line or systemd script), add the following flag to your node's startup command:
 
--track-subnets=2b175hLJhGdj3CzgXENso9CmwMgejaCQXhMFzBsm8hXbH2MF7H
(if the node already has a track-subnets config, append the new value by
comma-separating it).
 
For example:
./build/avalanchego --network-id=Fuji --track-subnets=2b175hLJhGdj3CzgXENso9CmwMgejaCQXhMFzBsm8hXbH2MF7H
 
If you start the node via a JSON config file, add this to your config file:
track-subnets: 2b175hLJhGdj3CzgXENso9CmwMgejaCQXhMFzBsm8hXbH2MF7H
 
TIP: Try this command with the --avalanchego-config flag pointing to your config file,
this tool is going to try to update the file automatically (make sure it can write to it).
 
After you update your config, you are going to need to restart your node for the changes to
take effect.

Add a Validator

If the join command isn't successfully completed before addValidator is completed, the Avalanche L1 could experience degraded performance or even halt.

Now that the node has joined the Avalanche L1, an Avalanche L1 control key holder must call addValidator to grant the node permission to be a validator in your Avalanche L1.

To whitelist a node as a recognized validator on the Avalanche L1, run:

avalanche blockchain addValidator testblockchain

As this operation involves a new transaction, you will need to specify which private key to use:

Use the arrow keys to navigate: ↓ ↑ → ←
? Which private key should be used to issue the transaction?:
    test
  ▸ mytestkey

Choose Fuji:

Use the arrow keys to navigate: ↓ ↑ → ←
? Choose a network to deploy on. This command only supports Fuji currently.:
  ▸ Fuji
    Mainnet

Now use the NodeID of the new validator defined at the beginning of this tutorial. For best results make sure the validator is running and synced.

What is the NodeID of the validator you'd like to whitelist?: NodeID-BFa1paAAAAAAAAAAAAAAAAAAAAQGjPhUy

This ID is intentionally modified. The next question requires a bit of thinking. A validator has a weight, which defines how often consensus selects it for decision making. You should think ahead of how many validators you want initially to identify a good value here. The range is 1 to 100, but the minimum for an Avalanche L1 without any validators yet is 20.

Just select 30 for this one:

Use the arrow keys to navigate: ↓ ↑ → ←
? What stake weight would you like to assign to the validator?:
    Default (20)
  ▸ Custom

✔ What stake weight would you like to assign to the validator?: 30

Then specify when the validator is going to start validating. The time must be in the future. Custom option is going to require to enter a specific date in YYYY-MM-DD HH:MM:SS format. Just take the default this time:

Use the arrow keys to navigate: ↓ ↑ → ←
? Start time:
  ▸ Start in one minute
    Custom

Finally, specify how long it's going to be validating:

✔ Start in one minute
Use the arrow keys to navigate: ↓ ↑ → ←
? How long should your validator validate for?:
  ▸ Until primary network validator expires
    Custom

If choosing Custom here, the user must enter a duration, which is a time span expressed in hours. For example, could say 200 days = 24 \* 200 = 4800 hours

✔ How long should this validator be validating? Enter a duration, e.g. 8760h: 4800h

CLI shows an actual date of when that's now:

? Your validator is going to finish staking by 2023-02-13 12:26:55:
  ▸ Yes
    No

Confirm if correct. At this point the prompt series is complete and CLI attempts the transaction:

NodeID: NodeID-BFa1padLXBj7VHa2JYvYGzcTBPQGjPhUy
Network: Fuji
Start time: 2022-07-28 12:26:55
End time: 2023-02-13 12:26:55
Weight: 30
Inputs complete, issuing transaction to add the provided validator information...

This might take a couple of seconds, and if successful, it's going to print:

Transaction successful, transaction ID :EhZh8PvQyqA9xggxn6EsdemXMnWKyy839NzEJ5DHExTBiXbjV

This means the node is now a validator on the given Avalanche L1 on Fuji!

Avalanche L1 Export

This tool is most useful on the machine where a validator is or is going to be running. In order to allow a VM to run on a different machine, you can export the configuration. Just need to provide a path to where to export the data:

avalanche blockchain export testblockchain
✔ Enter file path to write export data to: /tmp/testblockchain-export.dat

The file is in text format and you shouldn't change it. You can then use it to import the configuration on a different machine.

Avalanche L1 Import

To import a VM specification exported in the previous section, just issue the import command with the path to the file after having copied the file over:

avalanche blockchain import /tmp/testblockchain-export.dat
Avalanche L1 imported successfully

After this the whole Avalanche L1 configuration should be available on the target machine:

avalanche blockchain list
+---------------+---------------+----------+-----------+----------+
|    Avalanche L1     |     CHAIN     | CHAIN ID |   TYPE    | DEPLOYED |
+---------------+---------------+----------+-----------+----------+
| testblockchain    | testblockchain    |     3333 | SubnetEVM | No       |
+---------------+---------------+----------+-----------+----------+

Appendix

Connect with Core

To connect Core (or MetaMask) with your blockchain on the new Avalanche L1 running on your local computer, you can add a new network on your Core wallet with the following values:

- Network Name: testblockchain
- RPC URL: [http://127.0.0.1:9650/ext/bc/2XDnKyAEr1RhhWpTpMXqrjeejN23vETmDykVzkb4PrU1fQjewh/rpc]
- Chain ID: 3333
- Symbol: TST

Note

Unless you deploy your Avalanche L1 on other nodes, you aren't going to be able to use other nodes, including the public API server https://api.avax-test.network/, to connect to Core.

If you want to open up this node for others to access your Avalanche L1, you should set it up properly with https//node-ip-address instead of http://127.0.0.1:9650, however, it's out of scope for this tutorial on how to do that.

On this page