Subnet creation and deployment

We have now created all the required wallets and configuration files for five validators and two users. We'll now create an L2 subnet, have four validators join it, and then spin up their binaries.

Step 1: Subnet creation

To create a subnet, first connect to the bitcoin-ipc container running:

docker exec -it bitcoin-ipc bash

Then run:

# from inside the container
/usr/local/bin/bootstrap_subnet_a_from_container.sh

The script outputs the SUBNET_ID of the newly created subnet, make sure you export it using the printed command!

This is the scripts/bootstrap_subnet_a_from_container.sh script from the bitcoin-ipc repo, which has been mounted in the container for convenience. It does the following:

1. It submits to bitcoin-core all required transactions to create a subnet and to join and fund four validators.

2. It updates the config.json files of all validators in the /root/.ipc directory of the container.

3. It prints, among others, the SubnetID of the newly created subnet — it is a good idea to export it to an env variable.

Before running the previous command, you can start terminal(s) watching the logs of the Monitor and Provider for some validators, as explained in Optional: Helper scripts. This way you can see what is being writen and read from Bitcoin in real time.

Step 2: Validator deployment

The subnet has now been created and sufficiently many validators have joined. We can start the validators by running:

# from inside the container
/usr/local/bin/spin_up_subnet_a_from_container.sh $SUBNET_ID

where SUBNET_ID indicates the subnet from the first step.

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:

1. It starts twelve Docker containers (three for each validator: fendermint, cometbft , and ethapi) on your host.

2. 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.

About the Relayer and Checkpoint messaging

In IPC a checkpoint message, also called a bottom-up message, contains:

1. release operations from the child (an L2 subnet) to the parent (Bitcoin L1)

2. transfer operations from the child to another subnet,

3. 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 provider we 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)