Deploy the validators
So far we created an L2 subnet with four validators using metadata operations on Bitcoin L1. Now we are spinning up "physically" the subnet and validators using docker.
First connect to the bitcoin-ipc container (if not already done so) running:
docker exec -it bitcoin-ipc bashThen run:
# from inside the container
/usr/local/bin/spin_up_subnet_a_from_container.sh $SUBNET_IDwhere SUBNET_ID indicates the subnet for which you deploy validators (the script of the Subnet creationoutputs it).
This is the /scripts/spin_up_subnet_a_from_container.sh script from the bitcoin-ipc repo, which has been mounted in the container for convenience. Even though it is run inside the container, the command is handled by the docker daemon on your host machine.
It does the following:
It starts twelve Docker containers (three for each validator:
fendermint,cometbft, andethapi) on your host.It starts a Relayer for each validator, with log files stored in
/root/logs/in the container. See Optional: Helper scripts for more information on the log files.
If you have created a subnet using the bootstrap_subnet_from_container.sh script in the previous step, it will have also been added in /root/.ipc/config.toml inside the bitcoin-ipc container.
About the Relayer and Checkpoint messaging
In IPC a checkpoint message, also called a bottom-up message, contains:
release operations from the child (an L2 subnet) to the parent (Bitcoin L1)
transfer operations from the child to another subnet,
the actual checkpoint hash.
IPC requires a relayer for the bottom-up messaging. A relayer is a binary that is run locally by one or more validators. It connects
to the local Fendermint node of the validator, so as to obtain any finalized checkpoints,
to the parent network (in case of bitcoin, to the RPC exposed by the
providerwe started in the previous guides), so as to submit the finalized checkpoint messages.
The fees for submitting the checkpoints to bitcoin are paid by the multisig that controls the subnet.
By default, the relayer binary checks for checkpoints every 15 seconds. This parameter (which is different than the checkpoint generation period that we set during subnet creation) can be changed using the --checkpoint_interval_sec option of the relayer binary.
Multiple relayers can be run for an L2 subnet. A validator and any other party can be a relayer. If multiple relayers are running, only one of them will successfully submit it (as we rely on Bitcoin UTXOs to this end)
Alternative: Install on the host machine
If in page Installation you chose the alternative deployment — hence bitcoin-core , the monitors and providers, and ipc-cli are running on your host machine — then you must also use this alternative approach here to deploy the validators.
Even if you used the default Docker-based deployment, you still have the option to use this alternative approach here to deploy the validators. In that case, you need to run all following commands from inside the bitcoin-ipc container — the ipc and bitcoin-ipc repos can be found in the /root/workspace directory.
Please make sure you have successfully run all steps in the previous page Subnet creation. In particular, make sure that sufficiently many validators have submitted the join and fund commands for the newly created subnet.
Step 1: Spin-up docker containers
We have provided a script that automates spinning up the subnets. The script assumes that you have used the ports, wallet names, and authentication tokens as described in these docs, and that you have already created and joined a subnet with four validators, and that the monitor and provider binaries for those validators are running.
Make sure docker is running on your machine.
The only input to the script is the subnet id. From the bitcoin-ipc repo, run
Attention:
The scripts outputs a CometBFT ID and a Resolver Address . This looks like:
We will need this information later when we start a fifth validator for the subnet. Please note them down and/or create the following environment variables:
Verify on docker that the containers are up and running — for each validator there should be three containers: validatorX-fendermint , validatorX-cometbft , and validatorX-ethapi .
Step 2: Check the status of the subnet
You can now use the the scripts provided in Optional: Helper scripts to check the status of the subnet.
In particular, you can verify that the subnet is producing blocks:
and check the balances in the subnet
Optional: Deploy validators manually
Step 1: Deploy the infrastructure
Let's start our first validator which the rest of the validators will bootstrap from. Make sure you have docker running before running this command.
TOPDOWN_CHAIN_HEAD_DELAY specifies "the number of blocks to delay before reporting a height as final on the parent chain". TOPDOWN_PROPOSAL_DELAY specifies "the number of blocks on top of TOPDOWN_CHAIN_HEAD_DELAY to wait before proposing a height as final on the parent chain". These parameters are used by standard IPC, but when the parent chain is bitcoin the finalization period is handled by the bitcoin monitor (by default, 0 blocks for bitcoin regtest and 6 for bitcoin mainnet, but these values can be configured). Hence, we do not need to specify additional delay on the fendermint level.
Once the first validator is up and running, it will print out the relative information for this validator.
This is shown in this video guide.
You'll need the final component of the IPLD Resolver Multiaddress (the peer ID) and the CometBFT node ID for the next nodes to start.
BOOTSTRAPS: <CometBFT node ID for validator1>@validator-1-cometbft:26656
RESOLVER_BOOTSTRAPS: /dns/validator-1-fendermint/tcp/26655/p2p/<Peer ID in IPLD Resolver Multiaddress>, where <PeerID> is the last part of the IPLD Resolver Multiaddress
Attention:
We will need this information later when we start a fifth validator for the subnet. Please note them down and/or create the following environment variables:
Now, let's start the rest of the validators:
Last updated