Using Docker

Install Requirements

All types of Bifrost Network nodes can be executed easily through Docker. Docker must be pre-installed in the environment you wish to run the node. Once installed, you can proceed with the following process.

First, create a local directory to store the chain data of the Bifrost Network. This directory stores all block information collected from the genesis block to the present and additional session keys of the corresponding validator node.

# Add sudo at the beginning if it doesn't work
mkdir -p /var/lib/bifrost-data

You must set the ownership and permissions for the directory you created. If you wish to set it to a specific user, you can run the command written in “case 1” and change DOCKER_USER to the actual user name to run Docker later. If you want to set it as the currently connected user, you can run the command written in "case 2".

# case 1. chown to a specific user
chown DOCKER_USER /var/lib/bifrost-data

# case 2. chown to current user
sudo chown -R $(id -u):$(id -g) /var/lib/bifrost-data

Generate Peer Key

This section is only required for node client versions that are higher than or equal to v2.0.1

Every node running on the Bifrost Network requires a peer key to connect to the P2P network. To generate a new peer key and insert it into your chain data automatically, simply run the following command.

docker run --rm -it -v "/var/lib/bifrost-data:/data" thebifrost/bifrost-node:latest \
    key generate-node-key \
    --chain /specs/bifrost-testnet.json \
    --base-path /data

Run the Node Container

To run the validator node, you can simply run the following command. In this case, YOUR_NODE_NAME is a parameter indicating the name of the node to be executed and should be modified to the desired name.

Check Logs

To check your running bifrost-node container logs, execute the command below.

If the Docker image is successfully pulled, and the validator node is executed, the chain information will be shown as the following.

Since chain data needs to be synced starting from the genesis block, the information that it is currently syncing will be shown as the following output. You can proceed to the next steps only when the sync is complete, and it may take up to several days at most.

To quickly synchronize your chain data, follow this link.

When the chain data is completely synchronized, newly generated blocks will start to synchronize one by one at every block time as follows.

Key Setup and Bonding

We now proceed with the key setting that is required to allow the validator node to perform the process of block generation and finalization. From this step, the chain data synchronization of the running node must be completed.

First, validator nodes essentially require two Ethereum-style accounts, the controller and stash accounts, and in the case of full nodes, an additional relayer account is required.

A stash account is an account that holds a certain amount of self-bond that must be deposited in the system so that the delegated account can act as a validator. The role of a stash account is to deposit self-bonds and delegate one account (controller) to perform validator activities publicly on its behalf.

The controller account is the delegated target from the stash account and is the prime account that acts as a validator. The role of the controller is an account that is dedicated to all activities such as session key registration, block generation, finalization, etc., and requires minimal assets to pay transaction fees.

If you need to create a new account, you can run the following commands.

After executing the command, the available new validator accounts will be printed as follows. You must send enough BFC to each account that meets the requirements to proceed to the next process.

Next, the validator node must issue and register session keys to be used in the consensus algorithm. The process can be performed by executing the following command. Make sure that you are in the tools directory.

Example

This command will generate three session keys for your node. Each key has their own purpose. Aura is for block creation, grandpa is for block finalization, and ImOnline is for node liveness. The generated keys will be stored in your chain data directory. The directory path will look like this: /var/lib/bifrost-data/chains/{testnet|mainnet}/keystore.

Finally, it is necessary to deposit the self-bonds of the validator node to form the initial voting power. The process can be performed by executing the following command.

Example

If you have successfully completed every process mentioned above, the amount of BFC deposited from the stash account will be deducted from the wallet, and your controller account will participate in the active validator update process in the next round. You can check whether or not you successfully joined the validator pool on the following page.

If the tier of the validator node to be operated is a full node, it must be operated together with the relayer. The manual for relayer setup can be found in the "Setting up a Relayer" section.

Update Node Client

As Bifrost Network development continues, it will sometimes be necessary to upgrade your node client. Node operators will be notified on our Discord channel or by personal contacts when upgrades are available and whether they are necessary (some client upgrades are optional).

Before upgrading your node client, please keep a backup file of your chain data to prevent any further data, keys, or credential losses.

PreviousSetting up a Validator NodeNextUsing Systemd

Last updated