Why do mining pools exist?
Well, mining pools first appeared on Bitcoin shortly after its launch, so let’s start there. In short, the creation of mining pools can be traced back to Bitcoin's security model (PoW). For those not familiar with proof-of-work, it’s relatively straightforward - the network creates puzzles whose complexity depends upon current network information (ex: hashpower, network load, etc…) and whoever solves the puzzle first gets to create a block with some of the pending network transactions in it.
In Bitcoin’s nascency, when all of these numbers were low, individuals could expect to earn a few Bitcoin on a regular basis by mining with their computer’s GPU. But as Bitcoin gained in value, more and more miners joined the network, making it harder and harder for any individual miner to successfully mine any Bitcoin. More miners did increase Bitcoin's overall security, though, due to the fact that as the number of independent parties in the network increased, the ability for any one party to control the network decreased.
And with the increase in miners came an increase in the complexity of these puzzles, antiquating the concept of the profitable and independent miner. This was furthered by the introduction and fabrication of specialized chips known as ASICs (which well outpaced GPUs) as well as the creation of Bitcoin mining warehouses. And as these new entrants made it near impossible for a single individual to mine any Bitcoin, the pooling of mining resources began to gain more and more popularity.
Mining pools take PoW problems and break them down into smaller problems (in a sort of map-reduce fashion). Individuals have a much better shot at solving the easier PoW problems and get reimbursed for their CPU cycles (less a fee). And by combining multiple nodes' hashpower, pools increase everyone's chances of contributing to the mining of a block and receiving some monetary return for doing so. Naturally, the popularity of these mining pools has exploded over time with the collective hashrate worrying some of the members within the Bitcoin community of a potential 51% attack.
And their worries are justified — it is certainly much easier to pay off a few mining pools than it is to pay off all of the independent miners which comprise each of them. And just because we haven’t seen it happen yet does not mean that there is a 0% probability of it happening (although this would completely undermine the Bitcoin network and likely destroy its reputation).
So, as Bitcoin mining got more and more competitive over time, we saw it go from the gold standard of decentralization to a network run by just a handful of pooled resources. And this was inevitable because the network’s security model did not ensure the profitability of independent miners. If independent miners were able to make a profit and there was no benefit to economies of scale for mining, we would not see these huge pools, like we do today.
So, how can we improve?
Removing Pool Incentives
The main reason why miners join pools is because they would be highly unlikely to turn a profit, otherwise. And for this reason (amongst many others), every node in the SKALE Network has the same profit potential and is rewarded based upon its network behavior or SLA metrics (Service Level Agreement metrics such as uptime, latency, serving as a good actor).
And each node is judged based on its SLA behavior which includes its ‘virtualized subnodes’ which it creates via containerization to participate in consensus for Elastic Sidechains. The judges for determining the behavior of each of these virtualized subnodes are a subset of other virtualized subnodes in each elastic sidechain and the overall behavior of the node is regularly monitored by 24 independent peer nodes. Combining these metrics yields an overall score which will determine whether or not to reward the node for their network participation.
To prevent freeriding of virtualized subnodes in the network, slashing is integrated and is enforced in the event of any malicious behavior (ex: double-spend attack) or prolonged downtime. Prolonged downtime will lead to a partial slash of the node, and the slashing will continue until the virtualized subnode corrects its behavior or is removed from the Elastic Sidechain because its parent node no longer has enough stake to serve as a validator in the network.
So, the slashing occurs at the virtualized subnode level (but effects the node's stake) and the rewards occur at the node level . If a node’s virtualized subnodes are not exhibiting any poor behavior, then the node itself should have no problems. In this way, SKALE allows every node in the network the same profit potential without risk that they will fail to serve as good actors within the network — removing incentives for mining pools and ensuring network security and growth through system design that protects profitability of independent miners.
Note: If you're wondering about how we prevent collusion within Elastic Sidechains, check out the 'Elastic Sidechain' section of this article.
By leveraging a novel security model in tandem with random sampling and validator shuffling, the SKALE Network is able to both ensure the profitability of independent nodes within the network as well as the decentralization / security of the network.
If you are interested in learning more about becoming a validator in the network, node rewards, where SKALE sources its randomness, etc… please ask the community on Discord! And if you’re interested in trying SKALE out, check out the Developer Documentation! Also, feel free to also check out SKALE’s Technical Overview and Consensus Overview for a deeper dive into how SKALE works and is able to provide 20,000 TPS.
SKALE’s mission is to make it quick and easy to set up a cost-effective, high-performance sidechain that runs full-state smart contracts. We aim to deliver a performant experience to developers that offers speed and functionality without giving up security or decentralization. Follow us here on Telegram, Twitter, Discord, and sign up for updates via this form on the SKALE website.