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.

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.

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 will ask for blockchain configuration values. Since we are deploying to Fuji, select I want to use defaults for a production environment.

? Do you want to use default values for the Blockchain configuration?:
  ▸ I want to use defaults for a test environment
    I want to use defaults for a production environment
    I don't want to use default values
    Explain the difference

The default values for production environment:

Use latest Subnet-EVM release
Allocate 1 million tokens to:
1. a newly created key (production): name of this key will be in the format of subnet_blockchainName_airdrop
2. ewoq address (test): 0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC
Supply of the native token will be hard-capped
Set gas fee config as low throughput (12 million gas per block)
Use constant gas prices
Disable further adjustments in transaction fee configuration
Transaction fees are burned
Enable interoperability with other blockchains
Allow any user to deploy smart contracts, send transactions, and interact with your blockchain.

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

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               |
+------------+-----------------+-------------------+-------------------+

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. Select a key to has P-Chain AVAX to pay for transaction fees.

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 require bootstrap validators during creation process. Avalanche CLI has enabled using local machine as a bootstrap validator on the blockchain. This means that you don't have to to set up a remote server on a cloud service (e.g. AWS / GCP) to be a validator on the blockchain.

We will select Yes on using our local machine as a bootstrap validator. Note that since we need to sync our node with Fuji, this process will take around 3 minutes.

You can use your local machine as a bootstrap validator on the blockchain
This means that you don't have to to set up a remote server on a cloud service (e.g. AWS / GCP) to be a validator on the blockchain.
Use the arrow keys to navigate: ↓ ↑ → ←
? Do you want to use your local machine as a bootstrap validator?:
  ▸ Yes
    No

Well done. You have just created your own Avalanche L1 on Fuji.

You will be able to see information on the deployed L1 at the end of avalanche blockchain deploy command:

+--------------------+----------------------------------------------------+
| DEPLOYMENT RESULTS |                                                    |
+--------------------+----------------------------------------------------+
| Chain Name         | testblockchain                                     |
+--------------------+----------------------------------------------------+
| Subnet ID          | 2cNuyBhvAd4jH5bFSGndezhB66Z4UHYAsLCMGoCpvhXVhrZfgd |
+--------------------+----------------------------------------------------+
| VM ID              | qcvkEX1zWSz7PtGd7CKvPRBqLVTzA7qyMPvkh5NMDWkuhrcCu  |
+--------------------+----------------------------------------------------+
| Blockchain ID      | 2U7vNdB78xTiN6QtZ9aetfKoGtQhfeEPQG6QZC8bpq8QMf4cDx |
+--------------------+                                                    +
| P-Chain TXID       |                                                    |
+--------------------+----------------------------------------------------+

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

Add a Validator

Before proceeding to add a validator to our Avalanche L1, we will need to have the validator's NodeID, BLS public key and proof of possession. These can be obtained by ssh into the node itself and run the getNodeID API specified here

To add a validator to an Avalanche L1, the owner of the key that acts as the controller of ValidatorManager contract specified in avalanche blockchain create command above run:

avalanche blockchain addValidator testblockchain

Choose Fuji:

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

You will need to specify which private key to use to pay for the transaction fees:

Use the arrow keys to navigate: ↓ ↑ → ←
?  Which key should be used to pay for transaction fees on P-Chain?:
    test
  ▸ mytestkey

Now enter the NodeID of the new validator to be added.

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

Next, enter the node's BLS public key and proof of possession.

Now, enter the amount of AVAX that you would like to allocate to the new validator.

The validator's balance is used to pay for continuous fee to the P-Chain. When this Balance reaches 0, the validator will be considered inactive and will no longer participate in validating the L1.

1 AVAX should last the validator about a month.

What balance would you like to assign to the validator (in AVAX)?: 1

Next, select a key that will receive the leftover AVAX if the validator is removed from the L1:

 Which stored key should be used be set as a change owner for leftover AVAX?:
    test
  ▸ mytestkey

Next, select a key that can remove the validator:

? Which stored key should be used be able to disable the validator using P-Chain transactions?:
    test
  ▸ mytestkey

By the end of the command, you would have successfully added a new validator on the given Avalanche L1 on Fuji!

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/2U7vNdB78xTiN6QtZ9aetfKoGtQhfeEPQG6QZC8bpq8QMf4cDx/rpc]
- Chain ID: 3333
- Symbol: TST

Prerequisites

Virtual Machine