Warring Stakes Leader Board

Instructions for Participating in the Meter Test Net

If you haven't, please complete the complete the KYC form if you want to receive the testnet incentive. The testnet is however completely permissionless and we welcome any abuses. If you are running your own validator node, it is highly advised to connect the official Meter Wallet to your own node, so you have the most secure and up to date view of the network. Please also remember to comment on the Github Issue 1 of your validator.

Overview

Meter is a hybrid PoW and PoS blockchain system with dual chain structure. All the accounts and transactions are recorded on the PoS chain while PoW chain (currently a modified version of Bitcoin starting from the same genesis of Bitcoin) just maintains the crypto puzzles for mining. The PoW chain submits the solutions for the crypto puzzles to the PoS chain and the winning miners receive reward on their accounts on the PoS chain.

Epoch: Meter operates on epochs, which are signaled by k-blocks (regular blocks are called m-blocks). At the end of epoch, the committee nodes vote on the longest PoW chain and distribute mining rewards to all the PoW miners, it also pass the information to the PoW chain and all the PoW miners will have to start mining for the stamped PoW block. To create a k-block, the PoW chain typically has to have more than 60 blocks. Since the average PoW block period is 1 minute, each epoch is therefore around 1 hour (currently the time for epoch is completely decided by PoW, but we will implement cross interactions for epoch adjustments in the future). All system financial related activities like reward distribution, entering and exiting the delegate node pool only happens at k-blocks.

It is also required to run both PoS and PoW processes on the same physical or virtual machine to ensure security.

In Meter, there are several types of full nodes in the network:

1. Regular full node: They sync for each block and can support interactions with wallets
2. Delegate nodes: These nodes are candidates for the committee nodes and have opportunity to propose and sign blocks. To become a delegate node, the top N (N is a protocol parameter) staked full nodes(including both self staking and votes from other stakers) are the delegate nodes.
3. Committee nodes: A random subset of the delegate nodes are selected for every epoch. These nodes form a committee quorum and perform consensus. The committee nodes take turns to propose blocks. If a proposed block receives endorsement signatures from 2/3 of nodes in the committee, the signatures form a QC (Quorum Certificate). Each newly proposed block carries QC for the previous block. Once the newly proposed block obtains a QC, the previous block is considered as confirmed and finalized.

In the test net and initial launch of the main net. The number of Delegate Nodes will be the same as the number of the committee nodes. In the future, there maybe a subset of nodes with better performance and network connectivity dedicated as the leaders in the committee nodes.

Requirements for running a delegate/committee node:

To achieve the full performance of the Meter network, the ideal hardware configuration is more than 8 compute optimized vCPU, 16GB of memory and 500GB of SSD (AWS c5.2xlarge instance or better). The maximum block size in Meter is around 1.3MB. However the Meter consensus protocol is capable of adapting to transaction load, network and node processing speed to some extent by varying the block period from 2 sec to up to 30 sec. The minimum requirement is 2 vCPU and 4GB of memory (a $20~$40/month AWS lightsail nodes). When the network has minimum load, the average monthly block data is expected to be about 1.5GB. We highly recommend the validators to use the same setup as the mainnet. In addition, please try avoid running nodes behind the country firewalls like the Great Firewall of China. If your node has connectivity issues with other nodes, it may receive penalty points and get jailed.

Testnet Incentives

To help validators bootstrap the requirements for validator nodes and properly align the interests, all testnet incentive tokens will be distributed with a 6480 epoch lock(around 270 days). You could stake these tokens for candidates and votes, but will not be able to send them to other addresses. Each week of the final warringstakes testnet, we will distribute 15,000 points (1 point = 1 MTRG) and split them among validators who have maintained the nodes properly by weight. The base weight for each correctly maintained validator node is 1. If a validator(based on KYC) starts multiple nodes, their weight goes up by 1 for every 2 additional nodes. To make the game fair for everyone, the maximum weight per KYCed validator will be 3. Each reported and validated testnet bug may qualify for additional 100 to 500 points depend on its severity. We target to run the testnet for 2 to 3 weeks before flip the switch to mainnet.
We will make snapshot every week at random time of the validator list and publish the updates on participants weight on a google sheet Please reach out to @jenniferkong on discord for any KYC related questions.

Testnet faucets

You could claim testnet tokens from the testnet faucet

Setting up Docker

Node software is currently provided as docker images. Please refer to Ubuntu Docker Installation Guide.

By default, if you installed docker through apt install, it requires root user privilege to run. However, this may introduce security concerns. It is highly recommended to run Docker as non-root user.

Setup Docker usergroup to run Docker as non-root user. We assumed the non-root user that will be running docker is "ubuntu", please change the commands accordingly if you are using a different user.

sudo groupadd docker
sudo usermod -aG docker ubuntu

After this, please logout and log back in to refresh the user group setting and you will be ready to go.

Setting up a full node

1. Download the latest desktop wallet and make sure you select the warringstakes testnet. There will be a new wallet release right before the testnet. Please make sure your wallet version is 1.2.1, otherwise you may not be able to interact with the testnet properly

2. Prepare host working directory for Meter Docker container It is recommended to have a host working directory for the container to save important keys and block database, so we could retain them in future upgrades. We will create a directory called meter-data and set its path to and environment variable called METER_DATA_PATH (you will have to modify accordingly if you have a different directory structure) and map it to the /pos directory inside the container.

(the following instructions assumes the user operates in $METER_DATA_PATH. Please pay attention to the parameters in the commands and replace the path accordingly to your environment, especially the path after -v in docker run commands).

If your node has run Meter in the past, please make sure to clean the working directory and remove the container with the following commands.

rm -rf meter-data
docker container rm -f meter
docker container rm -f watchtower

Prepare a clean working directory

$ mkdir meter-data
$ cd meter-data/
$ echo "export METER_DATA_PATH=$PWD" >> ~/.bashrc
$ source ~/.bashrc

3. Launch the Meter container

docker pull dfinlab/meter-allin:latest
docker run --network host --name meter --restart always -e NETWORK="warringstakes" -v $METER_DATA_PATH:/pos -d dfinlab/meter-allin:latest

Several useful commands for docker:

docker container ls -a

The output will be like the following:

CONTAINER ID        IMAGE                      COMMAND                  CREATED             STATUS              PORTS               NAMES
260bbd571d1a        dfinlab/meter-allin   "/usr/bin/supervisord"   23 hours ago        Up 23 hours                             meter

docker container stop meter              //stop the container
docker container start meter             //start the container
docker container rm meter                //remove the container
docker image ls
docker image rm [image ID]                   //remove the container image, will trigger redownloading the image at the next docker run, it is recommended to do this every time we upgrade the testnet
docker container exec -it meter bash     //launch a bash in the container

The log files can be located inside the container, under /var/log/supervisor directory. If you file any bugs, please remember to attach the logs for PoS (both the stderr and stdout) in the bug. You could either copy and paste the log or use

docker cp meter:/var/log/supervisor/[LogFileNameHere]     //replace with the log file name

After confirming the node is running properly through the log, you could then connect the desktop wallet to your own full node.

You could compare the with height with the official Warring Stakes Testnet Explorer

4. Point Meter desktop wallet to your own full node In the settings of the wallet, under node, you could and connect add your own full node by adding http://IPaddrOfYourNode:8669 . The icon in the left of the address bar should turn green if everything is running properly. You could use the explorer inside the wallet to look at the status of the block productions. You should also create an account. Please make sure you keep the mnemonics in a secure location, you will need them to retrieve your account when we switching between the test nets and it should also work on the future main net. Please contact a team member to obtain MTRG and MTR test tokens.

Become a delegate node

Becoming a delegate node requires staking MTRG tokens. You will have to have both MTR and MTRG tokens in order to perform the transaction.

1. Configure network ports for your node. It is recommended to have a public IP address if you want to become a delegate node and have the following ports open for inbound TCP connections

2. Become a candidate In the desktop wallet, under the "Candidates" tab, you could self elect to be a candidate for delegate node by staking at least 2000 MTRG tokens and input all the required information for your node. When filling in the "Candidate" page, you will have to name your validator, put in the IP address of your node, select whether you want to system to automatically participate in the onchain MTRG auction for you (enable autobid) and also submit the public key used to sign the block proposals (this is the BLS key for the node running the validator, you could find the key in $METER_DATA_PATH/public.key file, its corresponding private key is in the master.key file) You could have other accounts delegate their votes to you as well to increase the chance of becoming a delegate node. The candidate transaction is recorded immediately and the node could start to receive votes. However, the votes won't be counted until the next k-block even with enough votes. You could check the list of candidate nodes through http://IPaddrOfYourNode:8669/staking/candidates or inside the wallet.

The votes for each validator automatically increases at 5% annualized rate to encourage validator to stay in long term. if you uncandidate and recandidate, you will lose these bonus votes. Whenever you uncandidate and undelegate, it will take one week before the tokens become unbounded and transferrable.

Please be aware that the public.key file in the docker container is generated when the container is launched. If you start a container from scratch, the public.key will be different from the one you used for the "Candidate" transaction. You could either "Uncandidate" and "Candidate" again with the new public key or change the public key to the one you used before.

Your node will automatically pick up by our Meter Scan once you successfully become a candidate.

Please be aware that the candidate transaction require tokens that are not staked. If you want to make any changes to the candidate information, currently the system requires to wait at least 7 days. In case you made any mistakes, the fastest way maybe to Uncandidate. After uncandidate, the tokens will still be in locked mode, you could use them to vote your self, but could not use them to candidate yourself. If you unbound the tokens, it will take 30 days for these tokens to be unlocked.

3. Become a delegate node If a candidate receives enough votes and ranked in the top N candidate nodes, it will become a delegate node. You could find the list of delegates through http://IPaddrOfYourNode:8669/staking/delegates

Setting up automatic update for Meter Docker images (Please make sure to do this on testnet)

1. Backup meter BLS keys If you look into the meter-data directory, there are three files that are important to keep: master.key, public.key and p2p.key. In addition, there are also several other files and directories in this folder, we suggest you to delete them on the testnet. This will cause the database to resync

We have prepared a watchtower container which will automatically check if there is any newly released docker image for Meter and upgrade accordingly.

docker run -d --name watchtower --restart always -v /var/run/docker.sock:/var/run/docker.sock containrrr/watchtower --include-stopped --revive-stopped --enable-lifecycle-hooks --interval 10 --cleanup meter

Please make sure you run the watchtower on testnet as we have very frequent upgrades.

The following steps are not needed if you are running the watchtower

If you prefer to manage the upgrade manually, you could follow the following instructions：

1. Stop and delete the current docker container

   docker rm -f meter

2. Pull the latest meter docker image

   docker pull dfinlab/meter-allin:latest

3. Force Resync block history(Recommended)

   sudo rm -rf $METER_DATA_PATH/instance-aad99a171ffea4f4

4. Start the container and mount the host data backup folder to the pos folder inside the container -v $METER_DATA_PATH:/pos

   docker run --network host --name meter --restart always -e NETWORK="warringstakes" -v $METER_DATA_PATH:/pos -d dfinlab/meter-allin:latest

Clean up unused docker images

As we have frequent upgrades in the testnet. After a while there maybe a lot of unused container images. You could use the following commnads to remove unused container images

docker system prune -af

Monitor the testnet status

You could look at the most current block height of your node through http://IPaddrOfYourNode:8670/probe and make sure the block height is in sync with the explorer We also have a monitor site to look at the status of different nodes in the network. As validators are still getting familiar with Meter, slashing will not be enabled initially on the network, instead we introduced a jailing concept to remove unperforming validators. The current rule of jailing on Meter is if a node has missed more than 3 proposals in any of the last eight epochs for two times, missed to organize the committee for 2 times or double signed once. Once a node is jailed, it takes 10 MTRG to revive it from the jailed states. You could complete this with the "bail out" option on the top right corner of the Meter Wallet.