This HOWTO contains instructions on how to build and configure a RUST validator node in TON blockchain. The instructions and scripts below were verified on Ubuntu 20.04.
| Configuration | CPU (threads) | RAM (GiB) | Storage (GiB) | Network (Gbit/s) |
|---|---|---|---|---|
| Minimum | 48 | 128 | 1000 | 1 |
SSD/NVMe disks are obligatory.
Adjust (if needed) net.ton.dev/scripts/env.sh:
Set export DEPOOL_ENABLE=yes in env.sh for a depool validator (an elector request is sent to a depool from a validator multisignature wallet).
Set export DEPOOL_ENABLE=no in env.sh for a direct staking validator (an elector request is sent from a multisignature wallet directly to the elector).
cd net.ton.dev/scripts/
. ./env.sh
Note: Make sure to run the script as
. ./env.sh, not./env.sh
install_deps.sh script supports Ubuntu OS only.
./install_deps.sh
Install and configure Docker according to the official documentation.
Note: Make sure to add your user to the docker group, or run subsequent command as superuser:
sudo usermod -a -G docker $USER
Do this step when the network is launched. Deploy the node:
./deploy.sh 2>&1 | tee ./deploy.log
Note: the log generated by this command will be located in the net.ton.dev/scripts/ folder and can be useful for troubleshooting.
Wait until the node is synced. Depending on network throughput this step may take significant time (up to several hours).
Use the following command to check if the node is synced:
docker exec -it rnode /ton-node/tools/console -C /ton-node/configs/console.json --cmd getstats
Script output example:
tonlabs console 0.1.254
COMMIT_ID:
BUILD_DATE: 2021-12-24 10:53:20 +0300
COMMIT_DATE:
GIT_BRANCH:
{
"sync_status": "synchronization finished",
"masterchainblocktime": 1640343840,
"masterchainblocknumber": 13393489,
"timediff": 4,
"in_current_vset_p34": true,
"in_next_vset_p36": false,
"last_applied_masterchain_block_id": {"shard":"-1:8000000000000000","seq_no":13393489,"rh":"e74d505222bbe64617bbd42939cf01334b035990ae4b4e285e67ecbb1b537dd3","fh":"fc0be7c22310389400a7bdbd000b3737b317ce44d92e9a5ed72086c4fa404afa"},
"processed_workchain": 0,
"validation_stats": {
"-1:8000000000000000": "1 sec ago",
"0:e800000000000000": "1 sec ago"
},
"collation_stats": {
"-1:8000000000000000": "never",
"0:e800000000000000": "6 sec ago"
},
"tps_10": 2,
"tps_300": 1
}
If the timediff parameter is less than 10 seconds, synchronization with masterchain is complete.
"sync_status": "synchronization finished" means synchronization with workchains is complete
Note: The sync process may not start for up to one hour after node deployment, during which this command may result in error messages. If errors persist for more than an hour after deployment, review deployment log for errors and check the network status.
There is a small difference between direct staking and DePool validators on this step:
- For direct staking validator it is necessary to create and deploy a validator SafeMultisig wallet in
-1chain. - For a DePool validator it is necessary to create and deploy a validator SafeMultisig wallet in
0chain.
You can use TONOS-CLI for this purpose. It should be configured to connect to the net.ton.dev network.
Refer to this document for the detailed wallet creation procedure, or follow the links in the short guide below:
- All wallet custodians should create seed phrases and public keys for themselves. At least three custodians are recommended for validator wallet, one of which will be used by the validator node. All seed phrases should be kept secret by their owners and securely backed up.
- The wallet deployer (who may or may not be one of the custodians) should gather the public keys from all custodians.
- The wallet deployer should obtain SafeMultisig contract code from the repository.
- The wallet deployer should generate deployment keys.
- The wallet deployer should generate validator wallet address: in -1 chain for direct staking validator or in 0 chain for a DePool validator.
- Any user should send at least 1 token to the generated wallet address to create it in the blockchain.
- The wallet deployer should deploy the wallet contact to the blockchain and set all gathered public keys as its custodians. At this step the number of custodian signatures required to make transactions from the wallet is also set (>=2 recommended for validator wallets). Deploy to -1 chain for direct staking validator or to 0 chain for a DePool validator.
- In case of direct staking, the funds for staking should be transferred to the newly created validator wallet.
Once the wallet is deployed, place 2 files on the validator node:
/ton-node/configs/${VALIDATOR_NAME}.addrshould contain validator multisignature wallet address in formX:XXX...XXX(the folder on the host isnet.ton.dev/docker-compose/ton-node/configs)/ton-node/configs/keys/msig.keys.jsonshould contain validator multisignature custodian's keypair (the folder on the host isnet.ton.dev/docker-compose/ton-node/configs/keys/)
The node will use the wallet address and the keys provided to it to generate election requests each validation cycle.
Note: If the validator wallet requires more than 1 custodian signature to make transactions, make sure each transaction sent by the validator node is confirmed by the required amount of custodians.
For a DePool validator it is necessary to deploy a DePool contract to workchain 0.
You can use TONOS-CLI for this purpose. It should be configured to connect to the net.ton.dev network.
Refer to this document for the detailed DePool creation procedure, or follow the links in the short guide below:
- Obtain contract code from the repository.
- Generate deployment keys.
- Calculate contract addresses.
- Send tokens to the calculated addresses.
- Deploy contracts. Make sure to specify your validator wallet in the DePool contract at this step.
- Configure DePool state update method.
Once DePool is successfully deployed and configured to be regularly called to update its state, you can make stakes in it. Note that validator stakes must always exceed validator assurance, otherwise DePool will not participate in elections.
Also note, that DePool and supporting contracts balance should be monitored and kept positive at all times.
Once the validator wallet and the DePool are deployed, place 3 files on the validator node:
/ton-node/configs/${VALIDATOR_NAME}.addrshould contain validator multisignature wallet address in form0:XXX...XXX(the folder on the host isnet.ton.dev/docker-compose/ton-node/configs)/ton-node/configs/keys/msig.keys.jsonshould contain validator multisignature custodian's keypair (the folder on the host isnet.ton.dev/docker-compose/ton-node/configs/keys/)/ton-node/configs/depool.addrshould contain DePool address in form0:XXX...XXX(the folder on the host isnet.ton.dev/docker-compose/ton-node/configs)
The script generating validator election requests (directly through multisig wallet, or through DePool, depending on the setting selected on step 2.1) will run regularly, once the necessary addresses and keys are provided.
Note: You may need to renew your copy of net.ton.dev scripts but do not remove any working files from the previous deployment (for example, configs folder).
Adjust (specify new commit ID) net.ton.dev/scripts/env.sh:
export TON_NODE_GITHUB_REPO="https://github.com/tonlabs/ton-labs-node.git"
export TON_NODE_GITHUB_COMMIT_ID="master"
export TON_NODE_TOOLS_GITHUB_REPO="https://github.com/tonlabs/ton-labs-node-tools.git"
export TON_NODE_TOOLS_GITHUB_COMMIT_ID="master"
export TONOS_CLI_GITHUB_REPO="https://github.com/tonlabs/tonos-cli.git"
export TONOS_CLI_GITHUB_COMMIT_ID="master"Upgrade the node:
./upgrade.sh 2>&1 | tee ./upgrade.log
Note: the log generated by this command will be located in the net.ton.dev/scripts/ folder and can be useful for troubleshooting.
Wait until the node is synced.
Note: call docker-compose commands from the
net.ton.dev/docker-compose/ton-nodefolder.
To stop the node use the following command:
docker-compose stop
To restart a stopped node use the following command:
docker-compose restart
It is highly recommended to record the full log during node deployment:
./deploy.sh 2>&1 | tee ./deploy.log
The log is saved to the net.ton.dev/scripts/ folder next to the deployment script and can be useful for troubleshooting.
When operational, the node keeps a number of logs in the net.ton.dev/docker-compose/ton-node/logs folder.
Logs are generated with log4rs framework. For detailed documentation on it refer to https://docs.rs/log4rs/1.0.0/log4rs/.
Logging configuration is determined by the net.ton.dev/docker-compose/ton-node/configs/log_cfg.yml file. By default is contains the recommended configuration for the Rust node.
refresh_rate: 30 seconds
appenders:
stdout:
kind: console
encoder:
pattern: "{d(%s.%f)} {l} [{h({t})}] {I}: {m}{n}"
stdout_ref:
kind: console
encoder:
pattern: "{f}:{L} {l} [{h({t})}] {I}: {m}{n}"
logfile:
kind: file
path: "/ton-node/logs/output.log"
encoder:
pattern: "{d(%s.%f)} {l} [{h({t})}] {I}: {m}{n}"
rolling_logfile:
kind: rolling_file
encoder:
pattern: "{d(%Y-%m-%d %H:%M:%S.%f)} {l} [{h({t})}] {I}: {m}{n}"
path: /ton-node/logs/output.log
policy:
kind: compound
trigger:
kind: size
limit: 50 gb
roller:
kind: fixed_window
pattern: '/ton-node/logs/output_{}.log'
base: 1
count: 1
tvm_logfile:
kind: file
path: "target/log/tvm.log"
encoder:
pattern: "{m}{n}"
root:
level: info
appenders:
- rolling_logfile
loggers:
# node messages
ton_node:
level: trace
boot:
level: trace
sync:
level: trace
# adnl messages
adnl:
level: info
overlay:
level: info
rldp:
level: info
dht:
level: info
# block messages
ton_block:
level: debug
# block messages
executor:
level: debug
# tvm messages
tvm:
level: info
librdkafka:
level: info
validator:
level: debug
catchain:
level: debug
validator_session:
level: debug
The currently configured targets are the following:
ton_node: node-related messages, except initial boot and sync, block exchange with other nodes
boot: initial boot messages, creation of trusted key block chain, loading blockchain state
sync: node synchronization - loading a certain number of most recent blocks
adnl: messages of the ADNL protocol
overlay: messages of the overlay protocol
rldp: messages of the RLDP protocol
dht: messages of the DHT protocol
ton_block: messages of the block structures library, logs are turned on in debug
executor: messages of the smart contract execution library, logs are turned on in debug
tvm: ton virtual machine messages, logs are turned on in debug
librdkafka: kafka client library messages
validator: top level consensus protocol messages
catchain: low level consensus protocol messages
validator_session: mid level consensus protocol messages
To migrate your validator from legacy C++ node to Rust node, complete the following steps:
- Set up a new host for the Rust node, according to steps 1-3 of this document.
- Wait for node to sync. Check sync according to step 4 of this document.
- Stop the C++ node sending election requests (by default - disable scheduling of the validator script). Do not shut down the C++ validator itself, let it finish the current round.
- Configure validator wallet and corresponding keys, optionally - DePool (copy them from C++ node files to Rust Node files). By default:
- Copy validator wallet address from
~/ton-keys/$(hostname -s).addrfile on the C++ node to/ton-node/configs/${VALIDATOR_NAME}.addron the Rust Node. - Copy validator wallet keys from
/ton-keys/msig.keys.jsonon the C++ node to/ton-node/configs/keys/msig.keys.jsonon the Rust Node. - If you have a DePool set up, copy DePool address from
~/ton-keys/depool.addron the C++ node to/ton-node/configs/depool.addron the Rust Node. Once this is done, the Rust node validator script will start automatically with the next round.
- Copy validator wallet address from
- DO NOT shut down the C++ host. Wait for the C++ node to complete the current round until the validator set is changed.
- Check
logs/validator.logon the Rust node, and make sure the first election request was successfully sent. There should be no errors in the log. - Only once the validator set changes, the C++ node is no longer a validator and the Rust node starts validating (
validation_statsandcollation_statsin the console output should not be empty), shut down the C++ node.
Here are some solutions to frequently encountered problems.
This error occurs in two cases. Either the docker daemon isn't running, or current user doesn't have rights to access docker.
You can fix the rights issue either by running relevant commands as the superuser or adding the user to the docker group:
sudo usermod -a -G docker $USER
Make sure to restart the system or log out and back in, for the new group settings to take effect.
The following error may occur for a short time immediately after node deployment when attempting to check synchronization:
thread 'main' panicked at 'Can't create client: Os { code: 111, kind: ConnectionRefused, message: "Connection refused" }', bin/console.rs:454:59
Currently this is expected behavior, unless it persists for more than a few minutes. If it does persist, check network status at https://net.ton.live/, and, if the network is up and running, review deployment logs for errors.
The following error may occur for up to an hour after node deployment when attempting to check synchronization:
Error executing command: Error receiving answer: early eof bin/console.rs:296
Currently this is expected behavior, unless it persists for more than one hour. If it does persist, check network status at https://net.ton.live/, and, if the network is up and running, review deployment logs for errors.
Make sure you are running all docker-compose commands from the net.ton.dev/docker-compose/ton-node folder.
It's recommended to send at least two ticktocks while the elections are open. For rust node you can use the provided ticktock script, which sends 5 ticktocks after the elections open.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent