Mining pools

If very few nodes work in the blockchain, this is a bad story, resulting in weak decentralization. This entails understandable security risks. But this gives great speed.

If there are a lot of nodes running on the blockchain, this is also a bad story. A large number of participants will take too long to vote on candidate blocks, sending a lot of traffic between them. Many participants increases security, but reduces speed and increases the load on the CPU and network.

The advantageous one among both the situations described above is the optimal number of participants who generate new blocks and communicate with each other to reach a consensus to finally add a new block to the blockchain. To ensure that there are fewer active participants discussing a new block, all chips should unite into groups and elect several trusted participants in each such group. In what follows, we call such groups a mining pool.

The mining pool does not belong to anyone. It has no leader (neither chip nor human). This is a virtual self-combination of chips according to a mathematical algorithm. A mining pool is born as if by itself, when many chips suddenly (according to the algorithm) begin to consider themselves part of some pool. The mining pool also dies according to the algorithm after some time. At this point, all of its chips simply move to other pools and continue working.

In accordance with the algorithm embedded in the smart contract, each chip knows in advance in what future period of time it should work. A period is a period from several hours to a day. According to the formula, which includes the current time, the future period of work, the age of the block, the number of network participants recently, each chip understands exactly for every second of its life which mining pool it is working in now and at what point in time it should instantly switch on new.

The formula exists to ensure that chips are automatically pooled in silent mode, without sending transactions to the network and without generating a new load. Otherwise, they would have to send out messages, somehow get together in a queue, or the company would have to create a centralized mechanism that manages the aggregation. But this would be a centralized solution with obvious disadvantages.

Each chip, upon its startup and then periodically (once every few days), informs the managing smart contract that it exists. This happens when data is recorded on the blockchain. But all other operations occur without adding purely technical records to the blockchain, which do not provide benefits to the blockchain community and only take up extra space in the blockchain. At the same moment, there is a demand from the smart contract to withdraw the reward accumulated during the period of operation (to the user’s wallet).

The chip pooling formula guarantees a random and unpredictable distribution of chips across mining pools. It is based on the hash of one of the recent previous blocks, which will be added to the blockchain shortly before all the chips should be redistributed to the mining pools. This gives absolute randomness because it is impossible to predict the hashes of future blocks. But it also gives stability to the formula when it is calculated by all chips. All chips will understand the formula the same way (based on common public data) and each chip will automatically join its own mining pool. More importantly, this approach makes it impossible for the owner of a pile of chips to carry out any destructive actions. Even in theory, they will not be able to unite into one mining pool in order to somehow benefit from this.

During their life, mining pools earn themselves a certain rating. The better he does the job of generating blocks, the greater the % reward the pool and all its participants will receive. Due to the fact that the lifetime of the pool is limited, there is no problem that over time, due to some distortions, one mining pool will accumulate more and more ratings.

Within each mining pool, by analogy with the formula described above, there is a formula for selecting delegates within the pool. The second formula is also based on public data and contains block hashes and hashes of mining pool participants. It is used to silently select those chips that will actually generate and validate blocks. Only a few such participants are selected from the entire pool. They, on behalf of the entire mining pool, try to create a new block chain and vote for the most profitable other people's chains in order to achieve a general consensus. Each of these participants reports on the useful work performed to the managing smart contract, which checks their rights to such activities using known formulas. Receiving reports from all mining pools, the managing smart contract, in accordance with the reward distribution formula, divides one common reward for a new block (from the token fund) among all ordinary participants. The real distribution of the reward to each chip does not occur at the moment of block creation, but some time later, so as not to litter the blockchain with unnecessary small requests. The chip knows from the history of its work in which mining pools and when it worked, and the smart contract stores data for reward distribution. Thanks to optimization, the chip will be able to claim a reward for a single transaction over a significant period of time.

Instant issuance of accumulated rewards upon user command (pressed a button in the application) is acceptable. Or so that the reward is requested much more often than is provided in automatic mode. In this case, the user will actually receive it immediately, but will pay for extra transactions, i.e. will lose a small part of the reward.

The reward distribution algorithm encourages pooling, delegate selection, and other priorities described above. Chips follow this algorithm to increase their profits. Thus, it does not matter which chip became the lucky participant in generating a new block; all chips will receive their fair reward in proportion (if they follow the most optimal algorithm). The amount of reward received is affected by the amount of money the user has, which is used for staking, and other parameters. This is described in the chapter on staking.