This article is the translation of Les Sidechains Horizen: Le Noeud Zendoo written by Xavier Garreau, a French community member, for his website: https://mescryptos.fr/les-sidechains-horizen-le-noeud-zend-oo/. Read the second article of this three-part series here.
Translated by Manon Boudoux
A Practical Introduction to Horizen Sidechains
Sidechains are THE new feature of the Horizen ecosystem. Horizen sidechains are independent but interact with the Horizen mainchain. They allow anyone to create a blockchain from a template, modifying only what is necessary for the original application.
Creating a sidechain from the mainchain is a bit like class inheritance in object-oriented programming. You will derive a sidechain from a functional model, but you can make any changes you need to it. The first step is to have a Horizen node with sidechain support.
Zend_oo is the beta version of the next Zend process. This release introduces sidechains and the mainchain’s ability to manage and communicate with them.
The purpose of this first tutorial is to install Zend_oo on a VPS.
Setting Up a Zend_oo Node
We’ll start by creating a zend_oo node. This ensures we have a node with sidechain capabilities.
I used a Digital Ocean VPS for this purpose, but any VPS will do. I chose the smallest in Debian 10. The build times are longer than on a monster, but it reduces the testing costs.
Once connected to the VPS, I create a Zendoo user that I add to the sudo group and assign a password to it.
# groupadd zendoo
# useradd -g zendoo -m -s /bin/bash zendoo
# adduser zendoo sudo
# passwd zendoo
I also add a bit of swap to this VPS, otherwise, the compilation won’t make it to the end due to a lack of memory (and it’s a long process to start all over again).
# fallocate -l 4G /swapfile
# chmod 600 /swapfile
# mkswap /swapfile
# swapon /swapfile
# echo ‘/swapfile none swap sw 0 0’ >>/etc/fstab
It’s ready! I switch to the Zendoo user for the rest and I place myself in the Zendoo user’s directory.
$ su zendoo
I complete the system updates and download the prerequisites.
$ sudo apt-get update
$ sudo apt-get -y upgrade
$ sudo apt-get -y install build-essential pkg-config libc6-dev m4 g++-multilib autoconf libtool ncurses-dev unzip git python zlib1g-dev bsdmainutils automake curl wget
I clone the source repository and compile zend_oo.
$ git clone https://github.com/ZencashOfficial/zend_oo.git
$ cd zend_oo
$ ./zcutil/build.sh -j$(nproc)
I’m downloading the necessary files. I didn’t get into what that step did, to be honest.
Starting zend for the first time will create the configuration file.
I edit it to specify that I want to use the testnet and I restart.
$ sed -i -e “s/#testnet=0/testnet=1/” ~/.zen/zen.conf
That’s it, I have my own Zendoo node! I can exit it with the key combination Ctrl+C, as shown.
Freeing Up Disk Space
The source directory and intermediate binaries take up a lot of space on the disk. I recommend removing all of that if you used a small VPS for testing like I did.
I create a Zen directory in the user’s home directory, move the binaries there and delete the zend_oo directory.
$ mkdir zen
$ mv zend_oo/src/zen-* ./zen/
$ mv zend_oo/src/zend ./zen/
$ rm zend_oo/ -rf
Addition to the PATH
For easier use of Zen binaries, I add the new directory to the PATH by adding the following to the ~/.bashrc file:
# ZEN binaries Path
The principle of the node is to not have to stay connected to watch it run. It can be launched in non-interactive mode as a daemon (or daemon by abuse of language).
This can be done by running zend -daemon instead of zend or, more permanently, by adding a line to the configuration file (~/.zen/zen.conf).
By doing so, it is no longer possible to stop zend with Ctrl+C. You have to use zen-cli to stop it (zen-cli stop) and/or, retrieve the PID of zend in the process list and send it a kill command.
Zen server starting
$ zen-cli stop
Zen server stopping
$ ps x
PID TTY STAT TIME COMMAND
1492 ? SLsl 4:29 zend
15373 pts/0 S 0:00 bash
15376 pts/0 R+ 0:00 ps x
$ kill 1492
We will use a bootstrap to speed up the synchronization of the node.
Useful note: for the moment the synchronization to the testnet is not necessary for sidechains.
We will use Zend_oo in regression test mode for now (argument -regtest or regtest=1 in the configuration file). However, I leave the method here for later use.
For my part, I stopped zend and deleted all the contents of the ~/.zen/testnet3 directory. The bootstraps can be retrieved here: https://bootstraps.ultimatenodes.io/ and more precisely in the case that interests me: https://bootstraps.ultimatenodes.io/horizen/masternode-sc/. We recover the link to the bootstrap of the day. We decompress it and delete the archive. For example, we can do the following.
$ cd ~/.zen/testnet3
$ wget https://bootstraps.ultimatenodes.io/horizen/masternode-sc/horizen_masternode_sidechains_blockchain_2020-07-07_06-00-01_UTC.tar.gz
$ tar xvzf horizen_masternode_sidechains_blockchain_2020-07-07_06-00-01_UTC.tar.gz
$ rm horizen_masternode_sidechains_blockchain_2020-07-07_06-00-01_UTC.tar.gz
As recommended, we add txindex=1 to the configuration file.
We can then start zend.
If the daemon=1 line has been added to the configuration file, the node simply launches by typing zend.
You can monitor what the daemon is doing in the debug.log files in the zen/testnet subdirectory and interact with it via the zen-cli client or via RPC calls. For example, we can do the following:
$ zen-cli getinfo
$ zen-cli getblockchaininfo
The node may not respond correctly at launch.
error code: -28
Loading block index…
You have to wait until this first step is completed before you have a reactive node. Once finished, zen-cli getinfo returns with:
Read the other articles in this series!