Deployment Steps

📘

Join TG Group

Users who deploy fullnode and validator nodes can join

TG ： https://t.me/visioncore_nodeupgrade_pa

Learn the upgrade information as soon as possible, participate in the discussion and proposal voting.

Environment:

Operating system: Linux distributions
Libs and Toos:
1. JDK1.8 (Recommend the Oracle JDK tools)
2. gradle (gradle 4.10 and newer)
3. git
4. ntp or other time synchronization service

Recommend Server Configuration:

CPU:8 cores or above
Memory:16G or above
Bandwidth: 50M or above
Disk: recommended to use nvme protocol solid state disk(SSD), capacity of 200G or more

Node Deployment

Method 1: Compile the source code for deployment

(1) Create code directory

mkdir core

(2) Download the source code of vision-core

cd core
git clone https://github.com/vision-consensus/vision-core.git

(3) Compile the vision-core project

# When the source code is successfully retrieved, a new directory named vision-core will be created in the current directory

cd vision-core
gradle build -x test

📘

Deploying a vpioneer test network node

If you wish to deploy a vpioneer test environment node, you can use the following command to switch the source branch to vpioneer before compiling the project.

git checkout vpioneer

📘

FullNode.jar

After successfully compiling the vision-core project, a directory named "build" will be created in the current directory, and the libs subdirectory under the build directory will generate the core files we need to use next, named FullNode.jar.

In the build/libs directory, in addition to the FullNode.jar file that we need to deploy the underlying node, there are also some toolset files that can be used at the underlay of vision. These files are not needed to deploy the underlying node. We can ignore these files in this section.

For the sake of clarity and simplicity of the deployment process. It is strongly recommended that you copy or move the FullNode.jar file to a dedicated directory. For the following deployment steps I will move the FullNode.jar file to the /vision/core directory.

(4) Start the FullNode

mkdir -p /vision/core
cp -a build/libs/FullNode.jar /vision/core/
cd /vision/core/
mkdir configs          # for storing the node running configuration files we need to get later 
wget -P configs https://vision-mainnet-configs.s3.us-east-2.amazonaws.com/stage001/vision-mainnet.config
nohup java -Xmx12g -XX:+UseConcMarkSweepGC -jar FullNode.jar -c configs/vision-mainnet.config &

🚧

Tips

Please make sure that the TCP port 16666 can be accessed by other external hosts

📘

Attentions

We can use the wget command to obtain the configuration file for the corresponding network. The configuration file for the vision network can be obtained from the following location.

Main network : https://vision-mainnet-configs.s3.us-east-2.amazonaws.com/stage001/vision-mainnet.config

vpioneer test network: https://vpioneer-backups.s3.us-east-2.amazonaws.com/configs/vision-vpioneer.config

If we are deploying a vpioneer test network node, then we have to switch to the vpioneer branch first when we compile the vision-core project. Then we select the vpioneer test network configuration file when we get the configuration file. There is no difference in the other steps.

The vision mainnet node consume large machine resources. We need to allocate enough memory to keep the service stable. We recommend using a separate machine to run the vision master node. Allocating 60% to 80% of the physical memory available to the JVM is a good choice.

The -XX:+UseConcMarkSweepGC command parameter indicates the use of memory allocation optimization, and we need to install Google's tcmalloc library instead of our system's default glibc maclloc call. The implementation steps are given at the end of the documentation.

The deployment of FVGuarantee node

📘

Tips

In the vision network, we refer to a FullNode as a full node. By default, the fullnode does not produce blocks in the network, it only passively synchronizes blocks from other nodes.

In the vision network, the task of block production is performed by the FV (First Validator) node. If you want your node to take on the block production task and get a reward for it, then you can deploy an FV node. FV node is short for FVGuarantee node

🚧

You should know!!

In the vision network, if we want to deploy an FV node, then we must first have an account with witness privileges. Then we pass the private key corresponding to the account address as an argument to the start command. We can link our Vtimes wallet on the official vision page. Request for currently logged-in account to become a witness account. The transaction will burn 900 VS of the account.

The FV node deployment steps are very similar to the fullnode node deployment process described above. They only have some differences in the command to start the node.

nohup java -Xmx12g -XX:+UseConcMarkSweepGC -jar FullNode.jar --witness -p <privateKey> -c configs/vision-mainnet.config &

If our FV account address sets the witness_permission permission and specifies another account to perform its blocking action. Then we must use --witness-address to specify the address of the FV account and -p to specify the private key of the FV proxy account in the command. Usually we just need to specify the private key of the FV account directly.

nohup java -Xmx12g -XX:+UseConcMarkSweepGC -jar FullNode.jar --witness -p <privateKey> --witness-address -c configs/vision-mainnet.config &

📘

private-key

is the private key for the account address we use with witness privileges, which is a hexadecimal string of 65 characters. We just need to replace it with this string. Remember to remove the parentheses as well.

After the node is normally started, two additional folders, logs and output-directory, will be created in the current directory of the start command, with the following functions.

logs: node log file
output-directory: the node's block data and current state storage location, i.e. the node's database file storage location.

Command line option parameter description:

--witness : Indicates to start the witness function, which is only used when the super node is deployed

--witness-address : Specify the First Validator Account address, only used when deploying super nodes

--log-config : This parameter can specify the location of the log file by yourself

-c : Specify the location of the configuration file used by the node

-p : Specify the private key of the super node.

Using the Keystore File

When deploying an FV node, if we do not want to specify the private key of our FV account in plaintext, then we can choose to use a secret key file to complete the deployment.

🚧

Be careful !!

Note: Since deploying an FV node with a secret key file requires entering the password corresponding to our secret key file at boot time, we can no longer use nohup followed by the boot command. It is recommended to use session software like screen, tmux, etc. to complete the deployment.

(1) First we need to comment out the localwitness entry in our configuration file, and then uncomment the localwitnesskeystore entry. We need to specify the location of our secret key file after the localwitnesskeystore entry. Please note that the secret key file must be placed in the current directory or subdirectory where we run the node startup command. For example, if the current working directory is /vision/core, and the location of the secret key file is /vision/core/keystore/localwitnessstore.json, our configuration entry is as follows
localwitnesskeystore = [
"keystore/localwitnesskeystore.json"
]

📘

We need to use the RegisterWalllet command in the vision-wallet-client tool to generate the secret key file and the corresponding password. vision-wallet-client project address: https://github.com/vision-consensus/ vision-wallet-client.git

(2) At this point, we no longer need to use -p to specify the secret key of our FV account in the startup command.

java -Xmx12g -XX:+UseConcMarkSweepGC -jar FullNode.jar --witness -c configs/vision-mainnet.config

(3) After typing the start command, the console will prompt us to enter the password, at this point we need to type the password corresponding to the secret key file of our configured FV account.

Use of log files

You can modify the level of the module to control the output of the log. The default level of each module is INFO. It can be modified as follows:

log.level = {
root = "DEBUG"
}

The configuration is directly added to the outermost layer of the configuration file.

The available log levels are: TRACE, DEBUG, INFO, WARN, ERROR

Stop node

ps aux | grep "java -Xmx.*g -XX:+UseConcMarkSweepGC -jar"
kill -15 PID

# 或者

kill -15 $(ps aux | grep "java -Xmx[[:digit:]]/+g -XX:+UseConcMarkSweepGC -jar" | awk '{print $2}')

📘

Full node and solidity node

(1) Currently, vision-core integrates full nodes and solidity node, eliminating the need to deploy an additional cured node.

(2) We can use the latest data image to synchronize our deployed nodes, which is much faster than trying to synchronize nodes from scratch. See the section on using data snapshots later for details.

(1) At present, the FullNode node has integrated the functions of SolidityNode. There is no need to build additional Solidity nodes.

(2) You can use the latest data for data synchronization. This is much faster than synchronizing data from the beginning. For specific steps, refer to the section on Official Public DB Image.

Use tcmalloc to optimize memory usage

In order to optimize the memory usage, you can use google tcmalloc to replace the system's glibc malloc. The method is as follows:

Install tcmalloc, and then add the following two lines to the startup script. The paths of tcmalloc in different Linux distributions are somewhat different.

Install tcmalloc:

(1) Ubuntu 20.04 LTS / Ubuntu 18.04 LTS / Debian stable

sudo apt-get install libgoogle-perftools4

Startup script

export LD_PRELOAD="/usr/lib/x86_64-linux-gnu/libtcmalloc.so.4"
export TCMALLOC_RELEASE_RATE=10

nohup java -Xmx12g -XX:+UseConcMarkSweepGC -jar FullNode.jar -c configs/vision-mainnet.config &

(2) Ubuntu 16.04 LTS

sudo apt-get install libgoogle-perftools4

Startup script

export LD_PRELOAD="/usr/lib/libtcmalloc.so.4"
export TCMALLOC_RELEASE_RATE=10

nohup java -Xmx12g -XX:+UseConcMarkSweepGC -jar FullNode.jar -c configs/vision-mainnet.config &

(3) Redhat8 (CentOS)
We first need to set up the epel yum source: https://dl.fedoraproject.org/pub/epel/

sudo yum install gperftools-libs

Startup script

export LD_PRELOAD="/usr/lib64/libtcmalloc.so.4"
export TCMALLOC_RELEASE_RATE=10

nohup java -Xmx12g -XX:+UseConcMarkSweepGC -jar FullNode.jar -c configs/vision-mainnet.config &

🚧

Startup script

The startup script is just a simple shell script, its main purpose is to set the two environment variables we mentioned above. The environment variables must be added before we start the node command, in the following format (please adjust the service start command according to the type of node and deployment method):

#!/bin/bash
#
export LD_PRELOAD="/usr/lib64/libtcmalloc.so.4"
export TCMALLOC_RELEASE_RATE=10

nohup java -Xmx12g -XX:+UseConcMarkSweepGC -jar FullNode.jar -c configs/vision-mainnet.config &