Devs

How to Run a Node on the Tezos Blockchain (Part 2)

17.02.20 | Mathis Selvi [SSB]

Note: This is *Part 2* of  “How to Run a Node on the Tezos Blockchain” Series

To run a node using Docker, please read part 1

To run a node using a snapshot, please read part 3

Ever wondered how to run a Tezos node? Or why should you run one yourself? If yes, you’re on the right series of articles. In this second part, we’re going to run a node, building it from sources.

Running a Node, And Building it From Sources

Why would a business runs its own node?

A business should want to run its own node for a few reasons, including more trust, safety, privacy, as well as contributing to Tezos (which is super cool, right?).

– Having your own node means you can handle the transactions and make sure they will be broadcasted to the network.

– When running your own node, you greatly contribute to the Tezos network by increasing safety and decentralization (because of you adding your own node to the network).

– If you’re baking, you will receive full rewards for all your operations and you will be to use your vote yourself, and not let another baker do so for you.

– Another very good reason is that by running your own node, you will be automatically up-to-date with latest upgrades, news, or technical improvements because you will have to keep an eye on them in order to successfully run your node.

My environment

First thing first, here is the environment I will be using for this tutorial:

Environment used

Environment used

In this second part, I will cover how to run a Tezos node, building it from sources.

Let’s dive into it!

Building from sources

Building from sources to run your own node is the method which takes the most time, but it allows for better understanding of what you’re actually doing.

Let’s start by creating a tezos-sources folder for the tutorial. Make sure to go inside it once it’s created. To do so, you can run:

$ mkdir tezos-sources && cd tezos-sources

Now, you should be in the tezos-sources folder, and we can start downloading the libraries we will need.

$ brew install hidapi libev gpatch opam

Next, we need to get the sources of Tezos by, first, cloning Tezos’ repo, then going into the tezos folder, and finally choosing the branch we want (mainnet in our case):

$ git clone https://gitlab.com/tezos/tezos.git
$ cd tezos
$ git checkout mainnet

Getting sources of Tezos

Getting sources of Tezos

Everything is going great so far. To continue, we need OPAM, the OCaml Package Manager. We already installed it with brew above, but let’s continue the setup.

Run this, and answer “y” if you need:

$ opam init --bare

Initializing OPAM

Initializing OPAM

Then, we need to install the OCaml Compiler as well as extra libraries Tezos will need. Run the following command:

$ make build-deps

This command will take some time. After a few minutes, you should have successfully installed the OCaml Compiler and all the extra libraries.

Finally, let’s update OPAM’s environment with:

$ eval $(opam env)

and compile the project:

$ make

If you did not have any issue, you should be ready to go. If you had an issue, unfortunately I can not really help on this article since it could be due to a lot of different things. However, if you feel like it’s on Tezos side, feel free to post your issue to get some help on Tezos’ StackExchange.

If you want to add Tezos binaries to your path, run:

$ export PATH=~/tezos:$PATH

To make sure that you have everything, as advised by Tezos’ Official Documentation, please check that you have the following in your folder:

  • tezos-node: the tezos daemon itself;
  • tezos-client: a command-line client and basic wallet;
  • tezos-admin-client: administration tool for the node;
  • tezos-{baker,endorser,accuser}-alpha: daemons to bake, endorse and accuse on the Tezos network. NOTE: as you’re on a production branch, the binary’s suffix won’t be “alpha” but “partial hash of the protocol they are bound to, such as”: 006-PsCARTHA for example;
  • tezos-signer: a client to remotely sign operations or blocks;

Now that you are sure everything went well, let’s start running our node! (Finally, right?)

Running our node

First thing first, feel free to use the man command to get access to the manual for each binary. Example:

$ ./tezos-client man

In order to run our node, we first need to generate an identity, which will be used to connect to the network. Run this command:

$ ./tezos-node identity generate

It may takes up to a few seconds/minutes. After waiting for a bit, you should see the new identity you just generated, right after the Generating message.

Generating a new identity…

Generating a new identity…

Let’s now start our node! Running a node is as easy as running this command:

$ ./tezos-node run

However, for this tutorial, I will add a parameter to communicate with the node later. Run this:

$ ./tezos-node run --rpc-addr 127.0.0.1

According to the man (./tezos-node man), the --rpc-addr parameter allows us to provide the TCP socket address at which this RPC server instance can be reached.

Your node should be running by now. As it’s the first time running the node, it will take a lot of time (up to a few days if you don’t have a very good hardware) to synchronize the chain. It basically starts in 2018, when Tezos was launched. If you don’t need to synchronize the whole chain, please see part 3, here.

If you want to make sure your node is running AND, at the same time, know at which date you are synchronizing, open a new window or tab of your terminal, go inside your tezos folder (should be /tezos-sources/tezos if you did the same thing as me in the beginning), and run this:

$ ./tezos-client -A 127.0.0.1 bootstrapped

Be sure to be in the tezos folder. -A allows to put the IP address of the node (which we set when we started running our node), and bootstrapped waits for the node to be bootstrapped/synced. If it’s not, you can see how the synchronization is going.

Waiting for the node to be bootstrapped

Waiting for the node to be bootstrapped

Our node seems to be running fine. As you can see with the timestamp, we’re currently synchronizing July 7th, 2018 and it will take more time to catch up until today.

If our node was not running, here is what would’ve happened when we ran the bootstrapped command:


This is it for the second part of this series of articles. Check part 1 and 3 (linked at the beginning of this article) for additional ways to run your own node.