Peerplays API nodes & Installation Guide
The list of Peerplays mainnet API nodes are given below
A list of public full API nodes for the Peerplays blockchain is maintained as a Github gist:
API node Installation Guide
1. Introduction
The API node is a computer or virtual machine participating in the Peerplays Peer-to-Peer (P2P) network and maintaining an open port for queries and other client interactions. It provides a gateway to the blockchain by exposing a client API (Application Programming Interface) for inspecting or interacting with the blockchain. API nodes usually function as a back-end service to front-end software that provides a user interface (such as a graphical “wallet” interface), but they can also be queried directly with command-line tools for blockchain introspection.
Node types:
P2P Node:
Relays blocks and transactions
Can be a “seed node” (helps other nodes sync blocks)
API Node:
A P2P node, but also:
Exposes API for inspecting blockchain state and/or broadcasting transactions
BP Node:
A P2P Node, but also:
Produces blocks for the network (BP = Block Producing)
Must be elected by stakeholders to produce blocks; is rewarded for successful block production
Installation target
The instructions below detail the installation and setup of a private API node that connects to the Peerplays public Test Net. The install base is an Ubuntu 20.04 Virtual Machine with root access via SSH, such as one might acquire from a cloud compute provider like DigitalOcean or Linode. The requirements for a test net API node are lightweight — 1 GB RAM and 25 GB disk should be sufficient.
Note: The steps here are for the public test net. For a main net deployment, some steps will differ and the CPU, RAM, and disk requirements may be steeper.
2. Initial login and VM setup
After instantiating a VM or cloud compute machine based on Ubuntu 20.04 or similar, the first step is to connect to it in a terminal window using “ssh” and your node name. The below command and output is an example:
3. Installation of node software
The below commands will be executed in the newly deployed node terminal, which will act as a private API node.
3.1 System updates
The number of software packages to be updated can be determined by using the command “apt update”. The output for the command is provided below:
Example output:
Similarly, to see the list of packages run the “apt list --upgradable” command.
Example output:
3.2 Software Packages Upgrade
After collecting the list of software packages, run the command “apt upgrade” to begin the upgrade. The command will build, extract, unpack, and install the package.
Example output:
3.3 Getting the software
The two executables needed are witness_node and cli_wallet. These can be compiled, or built, via the instructions at https://gitlab.com/PBSA/peerplays. Often, however, pre-built binaries for your system (e.g. Ubuntu 20.04 on AMD64 hardware) may be available in the “Releases” tab in the GitLab repo. The instructions that follow involve retrieving pre-built binaries that were compiled for “TESTNET”.
The files related to witness_node and cli_wallet should be stored in an accessible directory and it is handy to keep subdirectories based on software versions, to make it easy to select different builds in the future. So, create a directory as follows:
3.4 Retrieve the software:
In the directory created above, run the following commands to configure the witness node and cli wallet related files,
Example Output:
To configure the witness node use the below command
To configure the cli wallet use the below command:
Now the witness node and cli wallet file will be created in the desired folder.
3.5 File Permissions
To make the witness node and cli wallet files executable, the file permission must be given accordingly. Use the below command to provide necessary permission. The “a+x” makes the file executable for all users.
Example Output:
The necessary file permissions are given to the files.
3.6 Library Installation
1. LibZMQ and LibBoost
Boost is an open source software development library which provides various tools and utilities for C++ programmers. The C++ framework relies on the boost libraries. The boost is mainly used to create high quality, efficient, and portable c++ code.
Output:
2. Other runtime libraries: libBitcoin
libBitcoinA runtime library is a collection of executable software programs used at program run time to provide one or more native program functions or services. Peerplays witness_node software depends on some libraries that are not widely available. We have built these libraries and hosted them for convenient download.
2.1 Getting software package
Output:
2.2 Installation of the runtime libraries
The following command will install the run-time lib. If you observe the permission denied in the output, it can be ignored as the installation will be done directly through the root in some cases.
Output:
2.3 Checking the library file installation
To make sure the library files are installed correctly, run the following command in the terminal,
Output:
3.7 Witness node version check
Run the below command to check the witness node version and other build versions.
Output:
3.8 Move to the home directory
Run the below command,
3.9 Create necessary Directories
Next we will create the folders in which the witness node will store block data and configuration files.
1. peerplays-testnet directory
Run the below command to create the required directory and move to the location: /root/Node/peerplays-testnet
2. “bin” folder creation
The user should be in the location: /root/Node/peerplays-testnet, then create the bin folder. Below is the output,
3. Symbolic link creation
The ln command supports the symbolic link creation subcommand. It will build links or aliases to other files on our system. The ln -s commands create soft symbolic links. We will use this to link to the current version of the software. (This will make it easier to upgrade later.)
Execute the following commands in terminal:
The user should be in the directory “ /root/Node/peerplays-testnet/bin ”
4. Witness node update
4.1 Switch to “peerplays-testnet” directory
Execute the following commands in the terminal,
4.2 Downloading the “Genesis” JSON file
The “genesis” file is a JSON description of the initial starting state of the Peerplays Public Test Net. It is needed to allow the software to connect to and interoperate with the public test net.
Use the wget command to download the required file. Execute the following:
4.3 Compare the checksum value
After the Json file download, the file’s sha256 checksum value must be same as the given value here “195d4e865e3a27d2b204de759341e4738f778dd5c4e21860c7e8bf1bd9c79203”.
Make sure both the values are the same.
4.4 Create Witness node directory
Running witness_node for the first time will create the data directory structure for blocks and configuration. Execute the below command to create the witness node directory. The software will hang after a while because it does not yet know how to connect to the correct network. When console output stops, stop the witness_node with Ctrl-C.
Note that a new folder “witness_node_data_dir” now exists.
4.5 Install the editor of your choice (VIM is used here)
Once the editor is installed, some values in the config file witness_node_data_dir/config.ini need to be updated. But, before updating the file, you may wish to make a copy of the original config file with another name.
1. Make a copy of original config.ini
The below commands helps in terminal execution:
Now, the original config file is copied and saved as “config.ini-original”. The user can update the values in the config.ini file.
2. Input values in config.ini file
The user must be in the directory, “/Node/peerplays-testnet# cd witness_node_data_dir/” and open the config.ini file using the editor installed.
The config.ini file is large and only the necessary values are mentioned here.
Only the highlighted values in the above config.ini file must be updated based on the values of your node and save the file.
Notes on listening ports:
p2p-endpoint:
This is the port the node uses for P2P connections (for relaying blocks and transactions across the network). 127.0.0.1:19777 — Node will make out-going P2P connections to peers, but will not accept incoming connections from peers.
0.0.0.0:19777 — Node will accept incoming P2P connections in addition to making outgoing connections.
rpc-endpoint:
This is the “client port” that client software (GUI interfaces, CLI wallets, etc.) connect to to interact with the network. 127.0.0.1:18090 — Connections allowed from “localhost” only — such as cli_wallet or a GUI wallet running on the same machine as the node. 0.0.0.0:18090 — Connections allowed from any machine. Useful when the client software and the node are on separate machines, or when offering the API connection as a public service.
4.6 Initial synchronization of the node with the blockchain
After the config file is updated, the node must be resynced with the blockchain to reflect the changes. The user must be in the location “/root/Node/peerplays-testnet”. This command should be executed only once to sync the chain. (If started with --resync-blockchain again in the future, the blocks database will be discarded and the entire blockchain will be downloaded again.) Execute the below command to perform the resync,
After the sync is complete, the terminal will begin to show blocks received in real time. You can stop the node at this point (with Ctrl-C), and in the future start it without the resync flag.
To start the node normally, run the below command:
5. Persisting the run environment with GNU Screen
The purpose of the “screen” command is to create a pseudo virtual terminal. Mainly used to keep the witness node running even after the terminal dies. The terminal must be screened before starting the execution, to keep the witness node alive at all times. Also, the node can be reattached from another terminal at any time.
Execute the below command to screen the terminal before starting the node:
To Detach the screen session
Switch to the screen session, Press Ctrl+A and then D to detach from the screen. It can later be reattached with the same “screen -DRRS PeerplaysTestNet” command
To check the SCREEN session status
When logging into the node, one can check for running screen sessions with:
The screen command used here is one of the options for persisting the terminal. Users can pick their own option to perform this operation. Other options include tmux, pm2, Docker, and others.
Last updated
Was this helpful?