Askhat Beltsev, a representative of the Validator.Center pool and the upcoming Minter network masternode under the same name, prepared a column for the readers of DeCenter in which he told how to run the masternode and also gave real numbers for different architecture configurations and explained how much it would cost.

At the beginning of the article, I would like to note that the parameters proposed below are suitable for the Testnet and the first six months of the main network, but no more. Further on, with an increase in the number of users, and consequently with an increase in the number of transactions and the size of the blockchain, the options presented below will not cope with the load.

We begin our narration with the simplest configuration: launching the masternodes without using SNA. And let us briefly analyze three key steps that need to be done to start this masternode.

For reference: The Sentry Node Architecture (SNA) is a solution that provides a way to hide the IP address of a validator node and provide a more easily scalable list of public IP addresses to mitigate DDoS attacks. In simpler terms, this is the first line of defense that protects the main masternode of the validator from cyber attacks.

Step 1. We rent a virtual server and hosting from the provider: 2 cores, 4GB of RAM, and 40GB of SSD.

Why such parameters?

We take two cores for the Testnet with a margin to have additional “strength.” The signature is formed only on one core, but it’s better to use more than one CPU to balance and simultaneously perform other tasks.

A 40GB SSD node will last for at least a couple of months. It may be enough for a more extended period, depending on the development of the network. You need an SSD because it works faster than an HDD.

The blockchain of the project is rapidly growing: 5,000 transactions at 1 KB each is a lot: 5 MB + 20% for headers => 6 MB is one block, and in the future, we plan to conduct 10,000 transactions!

You need 4GB of RAM because the cost is small and it’s better to give it a margin. In the Testnet, it is enough to have 1.5GB of RAM.

I recommend that the hosting provider be load dependent and with hourly rates, any of the following will suit:

 Microsoft Azure

 Amazon Cloud

 Google Cloud Platform

That is, if there is no load, we pay less, and as soon as resources are allocated, respectively, it becomes more expensive. For the beginning, this is the best solution until the network gains serious “momentum.”

You can select a virtual server with a permanent configuration. There are a lot of companies on the VDS hosting market, but we eyeballed these two:

 Germany: Hetzner with the CX21 product for €5.78 per month

 USA: Linode with a 2GB product for $10 per month

It’s better to take it up in the USA since the Germans are very pedantic and have good “ironclad” firewalls. It is difficult to “fail” such servers, but due to excessive security, there are losses of 20 milliseconds, and this is a block skipped.

Step 2. We install the OS on a virtual server and configure it.

The OS can be installed on any 64-bit system. You can use Windows, MacOS, or the UNIX-like one (Linux or *BSD). Operating systems like UNIX are free and well-proven as operating systems for servers. If you prefer Linux, then your choice is the Ubuntu Server, Debian, Centos, or RedHat; if BSD, FreeBSD or OpenBSD will do.

Step 3. Installing the Minter blockchain.

Download the latest version of the Minter platform most suitable for you from GitHub. If your architecture is not there, you can build it yourself, since the source code is entirely open.

In the settings, we set that our server will work in Validator mode, and in the config.toml file, we assign the “true” value to the validator_mode command (it will look like this: validator_mode = "true").

The node will work in the validator mode even without this command, but then there will be more loopholes to “fail” the node, so you should chop off other functions and leave it only as a validator.

The file is located in the config directory, where the entire blockchain project is synchronized. The path can be configured to this folder, but the default directory is set to .minter.

A More Difficult, but Cheaper Configuration with SNA

We take three virtual machines on the Google Cloud Platform. Features: 1 processor (we strongly recommend 2 or more cores, but it will work on 1 core), 3.75GB of RAM, and a 40GB SSD.

As for money, theoretically, it costs 3*$27.7= $83.1, but in practice, it was ~$30 per month. There are three virtual servers on the GCP, but it is hard to say how much each one consumes, there are no such statistics.

Under load, however, there will still be problems (crashes), since the signing is not parallelized. A powerful processor (3 GHz or more) can cope with this, but, unfortunately, products with a capacity of 2.7 GHz are mainly presented on the virtual server market.

Based on the foregoing, we offer the following starting configurations for “holding out a punch”:

 3 or 4 Linode 8GB virtual machines (4 CPU, 8GB of memory, and a 160GB disk), 3 SNA, and 1 validator=$40*4=$160.

 3 or 4 Google virtual machines (4 CPU, 8GB of memory, and a 160GB disk), 3 SNA, and 1 validator=$113*4=$452. In fact, the costs will largely depend on the network load, and it is a minimum at the beginning.

What do the developers recommend for the Mainnet?

 RAM 4GB

 SSD 200GB

 x64

 3.4 GHz

 8 vCPUs

What does Linode have?

 32GB

 8 Cores

 640GB SSD

 16TB

 40Gbps

 7,000Mbps

Product: Linode 32GB. Price: $160 per month.

Total: $160*4=$640 per month.

What is Hetzner?

 8 vCPUs

 RAM 32GB

 Disk 240GB

 Traffic 20TB

Product: CX51. Price: €35.28 per month.

Total: €35.28*4 =€141.12 per month. But, I remind you, blocks are skipped.

What does Google have?

 8 CPUs

 RAM 7.2GB

 Disk 200GB

Price: $178.92 per month

Total $178.92*4=$715.68 per month. I remind you that in reality, the costs will depend on the load, that is, potentially they will be lower during the starting period.

As you already understood, you don’t need to have a huge capital to start; it is only important to design the architecture correctly and select the appropriate configuration. And finally, I will give you a couple of tips:

 The blockchain is growing, so 200GB is not enough.

 3 SNA will not be enough, better to use around 10 to cover a large area.

We will be happy to discuss all your questions and suggestions in our chat. Join us now!