FreeTON Validator Node

FreeTON is inheritor of TON blockchain which effectively got banned due to US court restricted GRM tokens worldwide. However, FreeTON project focuses on new, non-financial, use-cases of TON technologies and strives to bring this unique blockchain back to the world. 

FreeTON also going to have own tokens (as every blockchain) named Rubies and going to distribute those conducting several contests. One of such is Validator contest, where devops skills will come handy and the goal is to rollout own Validator node, as well as bring up logic that going to make stakes via this node and by that participate in Proof-of-Stake validation cycles confirming transactions in the blockchain.

I would like to share own solution that brings up Validator Node (full-node) from scratch as well as deploys application that can communicate with the node and perform staking, along with monitoring the node.

I called it SuTon (kind of short of Sudo Ton), as it ultimately it will allow you to control the node in every possible way. 

Github with code and instructions is here: https://github.com/jarig/suton

The main idea behind the architecture was to make node safe and expose as less as possible number of ports, hiding full-node from the outer world, however at the same time having possibility to control it and monitor.

High-level view of how it look like:

Solution consist of 3 docker containers:

• Validator That's where full-node is running, keeping itself in sync with the rest blockchain.
• Controller Application that communicates with the Validator via command-line utilities that FreeTON provides, all those are using network protocols for this. It also listens for the message-queue and accepts or sends control and info messages to it, so that applications on the other side of queue can either control the node in the given API scope or get some node information per request.
• Logstash Container with logstash client which listens for incoming telemetry events from the Controller, as well as gathers/parses logs from the Validator and sends structured output to various monitoring solutions.

As stated in the FreeTON specs Validator requires 1TB of SSD storage and at least 8 cores, so take care of choosing capable machine for that. The container mounting its working directory that going to use 1TB SSD using 'bind' mount and 'delegated' consistency for the fastest performance of the host SSD drive. 

At a moment mine validator node has 512GB of SSD storage though, and based on the current stats it looks that this size will be pretty much enough for the next 1year or so of the blockchain work. The most of the size is taking `[ton_work_dir]/db/archive` folder under working directory of the validator - that's where it holds old blocks that are not used often. That archive can be also placed on slower hard-disk. 

So far, the biggest performance gain is giving network speed and co-location of the node with the rest of the nodes, that's sounds weird for distributed blockchain, but at the same time it's logical. 

For the block to be signed it's required only 2/3 of signatures from the all validators, so the first ones who make those signatures 'wins' and other 1/3 will be skipped and won't participate. So, the closer you are to the rest of the nodes, the more chances you've to be part of that 2/3 group. 

As FreeTON developers say it's going to be balance between distributed architecture and performance. Latter has higher priority at least at the current stage.