On Fuji Testnet
Learn how to deploy an Avalanche L1 on the Fuji Testnet.
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
Virtual Machine
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.
This is going to generate a new key named mytestkey
. The command is going to then also print addresses associated with the key:
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:
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.
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:
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).
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:
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).
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.
For this tutorial, select Proof of Authority (PoA)
.
For more info, reference the Validator Management Contracts.
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
.
The default values for production environment:
- Use latest Subnet-EVM release
- Allocate 1 million tokens to:
- a newly created key (production) - name of this key will be in the format of subnet_blockchainName_airdrop
- ewoq - 0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC (test)
- Supply of the native token will be hard-capped
- Set gas fee config as low throughput (12 mil gas per block)
- Use constant gas prices
- Disable further adjustments in transaction fee configuration
- Transaction fees are burned
- Enable interoperation 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.
Now, provide a symbol of your choice for the token of this EVM:
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:
Deploy the Avalanche L1
To deploy the Avalanche L1, you will need some testnet AVAX on the P-chain.
To deploy the new Avalanche L1, run:
This is going to start a new prompt series.
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.
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.
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:
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:
Choose Fuji
:
You will need to specify which private key to use to pay for the transaction fees:
Next, we will require
Now enter the NodeID of the new validator to be added. For best results make sure the validator is running and synced.
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.
Next, select a key that will receive the leftover AVAX if the validator is removed from the L1:
Next, select a key that will can remove the validator:
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:
Last updated on