Ultima-1.2.0

Release Summary

itemvaluecomment
Mandatory upgradeYes
Versionultima1.2.0
Upgrade Deadline2022.11.05 12:00
Tag version of Githubhttps://github.com/vision-consensus/vision-core/releases/tag/mainnet_ultima_v1.2.0
Docker Image Versionmaintainers/vision-mainnet:ultima_v1.2.0
maintainers/vision-mainnet:latest

Features changed in this version

Version 1.1.0 of Ultima introduces several optimization updates.

  1. Added multi-stage pledge and stage re-investment of photon and entropy, and community nodes voted for re-investment
  2. The JSONRPC interface is compatible with the vision native transaction
  3. Community node modification fee for voting address
  4. Community node reward burn statistics
  5. The first validator's create multiple proposed parameter verifications in batches
  6. Upgrade block header 's version code
  7. Upgrade fastjson library version

CORE

1. Added multi-stage pledge and stage re-investment of photon and entropy, and community nodes voted for re-investment

In previous versions of ultima 1.1.1, users could obtain voting rights by freezing photon and entropy at the same time. In the new version, we introduce a pledge model with multiple stages. Users can choose different stages to pledge photon or entropy to obtain voting rights. , the pledge period and voting weighting coefficients corresponding to different tiers are different. The higher the pledge stage, the higher the weighting factor. After the stall pledge expires, there will be a reinvestment consideration period. Within this time frame, the user can choose to unfreeze the resources. If the pledge is not released within this consideration period, the reinvestment period will be entered. The tier pledged in the tier requires the user to re-invest, and the corresponding weighting factor of the tier will continue to be valid. The community node voting re-investment function is the same. After the community node voting pledge time expires, there will also be a re-investment consideration period. During the consideration period, users can choose to release the pledge. Otherwise, after entering the re-investment period, users need to re-invest.

2. Community node modification node address fee and community node reward burn statistics

In previous versions of ultima 1.1.1, users can choose to modify the node address. In the new version, we introduce a proposal. The first validator can control the network by create a proposal to set the user's fee when modifying the community node address, so that the vision network is more flexible.

3. Upgrade block header 's version code and fastjson library

In previous versions of ultima 1.1.1, the version code of the block header in each block from the vision network was the initial value of 20. In the new version, we will start to iterate this version number. For functions with major version upgrades, we will Increment the version number.
Due to security vulnerabilities in fastjson1.2.80 and earlier versions, Ultima1.2.0 updated the version of the fastjson dependent library to 1.2.83, and enabled the fastjson safemode mode to ensure the security of using fastjson.

API

1. The JSONRPC interface is compatible with the vision native transaction

In previous versions of ultima 1.1.1, when users use the JSONRPC interface to access the vision network, they can only use EVM-related basic interfaces and functions such as the currency transfer and contract invocation, and cannot call the native transactions of the vision network, such as voting, the first Validator application, reward withdrawal, etc.
In the new version, vision network is compatible with JSONRPC interface. We have formulated a set of standards for the vision network, that is, the underlying native transaction types are compatible with the contract method specification, the transaction type is the contract method, and the transaction parameters are the parameters of the contract method.

Node Upgrade Procedure

Compile the source code to upgrade

1. Close the process

# Get the PID of the running vision-core process
ps aux | grep "java -Xmx.*g -XX:+UseConcMarkSweepGC -jar"
# Stop the process
kill -15 PID

2. back up the node's data

# First enter the working directory of your node, here we use $OLD_WORKDIR to represent the working directory of your node, the specific path should be replaced according to the directory you selected when deploying your node
cd $OLD_WORKDIR

# Back up the jar package of the currently running vision-core application
mv FullNode.jar FullNode.jar.$(date '+%FT%T').bak

# Back up the current database
tar --force-local -zcvf "output-directory-$(date '+%FT%T')-backup.tar.gz" output-directory

# Back up configuration files
cp vision-mainnet.config vision-mainnet.config.bak

3. Get the new version of the jar package

# Get the latest version of java source code
git clone https://github.com/vision-consensus/vision-core.git

# Compile the source code and get the FullNode.jar package
cd vision-core
gradle build -x test

# Copy the FullNode.jar package to the previous working directory, you need to replace $OLD_WORKDIR in the following command according to the working directory you are using
cp -a build/libs/FullNode.jar $OLD_WORKDIR

# Back in the node working directory
cd $OLD_WORKDIR

# Get the latest configuration file to replace the original one, assuming we have the configuration file in the configs subdirectory of our node's working directory and the configuration file name is the default vision-mainnet.config

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

📘

Get the official jar package directly

You can also get the official jar package directly to re-run the service.
Link address : https://github.com/vision-consensus/vision-core/releases/download/mainnet_ultima_v1.2.0/FullNode.jar

4. Start the node

# Go to your original working directory, replace $OLD_WORKDIR by yourself
cd $OLD_WORKDIR

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

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

# If you need to use another witness account, please replace the <privateKey>

📘

Optimize memory allocation with Google tcmalloc library

If you are using the Google tcmalloc library, please set the relevant environment variables before the command to start the node, for example, on Ubuntu 18.04 the start command is as follows.

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 &

  1. Upgrade completed, please wait until the whole network upgrade is completed.

📘

Delete backup data to save disk space

After the network upgrade, users can delete the packages, configuration files and database files we backed up in order to save disk space on the node machines.

Docker image upgrade

1. Close the container

# Shut down the docker container, please replace the container name of the vision-core service by yourself

docker stop $CONTAINER_NAME

docker rm $CONTAINER_NAME

2. backup node data

# Enter the external volume mapped by the vision-core service container, please replace VOLUME_NAME by yourself

cd $VOLUME_NAME

# Back up the current database

tar --force-local -zcvf "output-directory-$(date '+%FT%T')-backup.tar.gz" output-directory

3. Pull the latest docker image and update the configuration file

# Pull the docker image

docker pull maintainers/vision-mainnet:latest

# Update the configuration file, assuming our original configuration file is mainnet.config in the configs subdirectory of the external mapping volume of the docker container, we go to that external mapping volume and execute the following command.

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

🚧

Pull the image first and then run the container

Please use "docker pull" to pull the latest image independently first. Then use the following docker run command to run the container. Otherwise, nodes that have pulled the image with the same name locally will run the container directly with the original image. In this case, the node is restarting the service without upgrading the underlying code.

4. Starting a Docker container service with a new image

# fv witness Node:
docker run -itd \
    -v "/data/mainnet:/data/vision" \
    -p 7080:7080 \
    -p 7081:7081 \
    -p 7082:7082 \
    -p 16666:16666 \
    -p 60061:60061 \
    -p 60071:60071 \
    -p 60081:60081 \
    --name vision-mainnet-FVGuarantee \
    maintainers/vision-mainnet:latest --private <private-key>

# Please replace <private-key> with the private key corresponding to the witness account used by your node.



# FullNode 节点:
docker run -itd \
    -v "/data/mainnet:/data/vision" \
    -p 7080:7080 \
    -p 7081:7081 \
    -p 7082:7082 \
    -p 16666:16666 \
    -p 60061:60061 \
    -p 60071:60071 \
    -p 60081:60081 \
    --name vision-fullnode \
    maintainers/vision-mainnet:latest

❗️

Keep the original external mount volume

When rerunning a container with a new image, be sure to keep the original external container hanging on the volume. Do not change it.

5. The upgrade is complete, please wait for the completion of the network-wide upgrade