Configure, Run, and Set Up a Service

You have prepared your machine to be part of the upcoming network. Now it is time to:

1. Configure the rest of the software.
2. Start the software and have it establish a peer-to-peer (P2P) network with others.

Configuration

Start by putting myprojectd into /usr/local/bin, or into whichever path you put your executables. Confirm it works with:

Copy $ myprojectd version

In the previous section, you configured some parameters of your node when it comes to CometBFT, in ~/.myprojectd/config/config.toml.

In config/app.toml, you will find other parameters to configure. Take special note of halt-height which assists you in gracefully stopping the node, such as when applying a migration.

As for the database(s), classic considerations apply. With the db_dir flag, consider storing its files in a dedicated and redundant volume. On Linux, you could mount the data folder to that separate drive.

Events are also stored in a database, and here too you can choose to store them separately. Note that events are purely a node concern, not a consensus or network one.

Run user

Another standard security concern is that you want to avoid running your application as root. So, create a new user and prepare it:

Copy $ sudo adduser chainuser

With this done, move the configuration folder to the home folder of the new user:

Copy $ sudo mv ~/.myprojectd /home/chainuser $ sudo chown -R chainuser:chainuser /home/chainuser/.myprojectd

Commands

To finally launch your software, you could simply run:

Copy $ ./myprojectd start

The larger your genesis file, the longer this step takes. Do not worry if it seems like nothing is happening.

As a service

Instead of relaunching your software every time, it is a good idea to set it up as a service. You can use your preferred method, but if you are on Linux it may be with systemd. Here is an example of a service file, modeled on Gaia's (opens new window), to save in /etc/systemd/system/myprojectd.service:

Copy [Unit] Description=My Project Chain Daemon After=network-online.target [Service] User=chainuser ExecStart=$(which myprojectd) start Restart=always RestartSec=3 LimitNOFILE=4096 [Install] WantedBy=multi-user.target

Check the section on migrations to see how you may add parameters to this file if you want to use Cosmovisor.

Enable it once:

Copy $ sudo systemctl daemon-reload $ sudo systemctl enable myprojectd

Now, if you do not want to try a computer restart, you can start the process immediately with:

Copy $ sudo systemctl start myprojectd

When to start

You have launched your blockchain software, and the other validators have done the same, so when is the first block minted? This happens when validators representing at least two-thirds (opens new window) (67%) of the total staked amount are online.

This means that, although you should coordinate with your peers for a convenient date and time to start, you need not narrow it down to the second. You can collectively agree to all start on Tuesday and it will therefore start safely at some point on Tuesday.

However, this is another reason why, when adding staking transactions in the genesis, you need to be sure about the reliability of the other validators, otherwise your start could be delayed.

Further concerns

Now that you have a running network, you may consider coming back to it and try to:

• Make your life easier with shell command completion (opens new window).
• Add a node that checks invariants (opens new window).
• Add telemetry (opens new window) so as to keep an eye on your node(s).
• See what other projects (opens new window) can benefit you.

This is just an extract of the different customizations that are available to you. For more ideas, peruse this documentation (opens new window).

When your network has been running sufficiently to be considered "established", your next steps are to advertise it and facilitate its eventual integration within the ecosystem. A good way to achieve this is to open a pull request on the chain registry repository (opens new window) with chain.json and assetlist.json files that describe your chain in a systematic way. Make sure that your JSON files follow the given schemas, for instance by checking with this online validator (opens new window).

If you would like to see how to apply what you've learned, you can go straight to the exercise in Simulate production in Docker to start from scratch.

More specifically, you can jump to:

• Executables that run, to see how to prepare (Docker) nodes to run.

synopsis

To summarize, this section has explored:

• How to configure other software necessary to be part of a network.
• How to start the software and establish a P2P network with other nodes.
• The importance of avoiding running your application as a user (rather than as root) for security reasons.
• How to set up your software as a service, to avoid the need to repeatedly relaunch it.
• How to coordinate with your peers regarding when to start your network to ensure timely behaviour.