Deploy Bootnode and Server

Set up backbone peers

These bootstrap/bootnode peers can be used as --initial_peers, to connect new servers to the existing ones. They can also serve as libp2p relays for servers that lack open ports (e.g., because they are behind NAT and/or firewalls).

To start a bootstrap peer, run this line in a tmux/screen shell:

Note: This runs without a connection to the blockchain with --no_blockchain_rpc.

subnet-dht-api \
--host_maddrs /ip4/0.0.0.0/tcp/31330 /ip4/0.0.0.0/udp/31330/quic \
--announce_maddrs /ip4/{your_ip}/tcp/31330 /ip4/{your_ip}/udp/31330/quic \
--identity_path bootnode.id \
--no_blockchain_rpc

Once you run it, look at the outputs and find the following line:

Mon 00 01:23:45.678 [INFO] Running a DHT instance. To connect other peers to this one, use --initial_peers /ip4/YOUR_ADDRESS_HERE/tcp/31337/p2p/QmTPAIfThisIsMyAddressGoFindYoursnCfj

The suggested method is to update the .env variable PUBLIC_INITIAL_PEERS list with the address from the bootnode. You can also provide this address as --initial_peers to servers or other backbone peers. If there is a risk that this peer goes down, you can launch additional hivemind-dht instances and provide multiple addresses. New peers will be able to join the swarm as long as at least one of their initial peers is alive.

Here are a few tips to help you set up:

• The --host_maddrs contains libp2p multi-addresses specifying a network protocol, IP address, and port. Learn more about them here.

  • If you want your swarm to be accessible outside of your local network, ensure that you have a public IP address or set up port forwarding correctly, so that your peer is reachable from the outside.

  • If you run your swarm in a local network only, it's fine not to have a public IP and ports as long as you use the local network's IP addresses everywhere.

  • You can specify 0.0.0.0 as the IP address, so that the script will listen to the IP addresses of your existing network interfaces.

• The --identity_path contains a peer's private key and defines the "/p2p/..." part of your peer's address (essentially, its public key).

  • Set --identity_path option to a file to ensure that your peer has the same identity each time you restart it. If the file doesn't exist, the script will generate a new private key and save it to the specified file.

  • Make sure each peer's identity is unique.

  • If you omit this option, the subnet template will generate a new identity each time a process is started.

    • In production, this is not recommended as other peers will not be able to verify your identity, and you will not pass the proof-of-stake mechanism.

Start Server

Once the bootnode is running and the bootnode address is in the .env file, you can start your first server with:

When running a P2P network locally, where each peer uses the same IP address, each peer MUST use separate ports. i.e., the bootnode uses 31330, and the server uses 31331.

In addition, when starting a server, use different --subnet_node_id's. There is a local mock SQLite database that mimics the blockchain when using --no_blockchain_rpc and will expect different node IDs.

subnet-server-mock \
--host_maddrs /ip4/0.0.0.0/tcp/31331 /ip4/0.0.0.0/udp/31331/quic \
--announce_maddrs /ip4/{your_ip}/tcp/31331 /ip4/{your_ip}/udp/31331/quic \
--identity_path alith.id \
--subnet_id 1 --subnet_node_id 1 \
--no_blockchain_rpc

You can also use the argument --initial_peers instead of using the .env file.