Joint post with Yaron Velner

Smartpool, the decentralized mining pool is live on Ethereum testnet for over 20 days. The testnet deployment is fully functional in terms of efficient proof-of-work verification. However, currently the pool pays to miners for their work in a way that is both infeasible and unfair. In this post, we describe a new payment scheme which is feasible, pool-hopping-secure and fair to distribute miners’ reward in SmartPool. This post contains three parts. In the first part of the post we recall the ideal properties that a payment scheme should have and what are the popular payment schemes for existing mining pools. In the second part we explain the difficulties in implementing a payment scheme for Smartpool. We propose a practical payment scheme for Smartpool and analyze it in the last section.

Payment Scheme Ideal Properties

Our goal is to obtain the next three properties in a payment scheme for a decentralized mining pool.

Feasible: The scheme can be executed forever without requiring significant initial capital or additional capital during the execution. Pool-hop-secure: Miner cannot (on average) benefit more from joining or leaving the pool at certain times. Fair: Big and small miners should be rewarded equally, proportional to their contribution. Moreover, all the pool revenues should be distributed to miners.

We recall that in cryptocurrency mining pools, pool miners are paid for the shares they submit to the pools. Payment schemes for centralized mining pools have been well studied in the literature, most notably by the work of Meni Rosenfeld. Today, the two most popular schemes are Pay-Per-Share (PPS) and Pay-Per-Last-N-Shares (PPLNS). In PPS a fixed payment is given for every submitted share, the payment is dependent on the relative difficulty between the share and the block. This is the most simple and elegant payment scheme. The PPLNS scheme only considers the last N shares to distribute the pool mining reward of the new block among all miners. The PPLNS scheme satisfies all three ideal properties. In practice, there are variants of PPS and PPLNS schemes, namely FPPS (Full Pay Per Share) which considers the transaction fees in the reward when paying to miners, SMPPS (Shared Maximum Pay Per Share) which is similar to PPS but never pays more than the pool earns.

In the next section, we explain why it is technically impossible or economically infeasible to implement either naive PPS or PPLNS scheme in Smartpool.

Challenges in designing a payment scheme for SmartPool

In Smartpool miners submit batches of shares to the contract. This is the key difference from traditional centralized pools where every share is submitted immediately after found. In addition, only a single (random) share from the batch is examined by the contract. We note that allowing batch submissions is critical in SmartPool to permit low gas costs. Hence the PPLNS scheme is technically impossible to be implemented in SmartPool as PPLNS requires all shares to be freshly available and are Chronologically ordered to decide the payment distribution.

Below we list additional challenges that arise in the Smartpool model.

In SmartPool, it is hard to estimate how much more the pool has to pay to miners since we allow batch submissions. Miners may submit their batch of found shares anytime, so we cannot know how much of the pool’s current balance should be reserved for work that was already done and had not yet submitted. Miners may strategically decide when to submit the batch of shares to gain more advantages than honestly following the protocol. This can be viewed as internal pool-hopping. As gas costs of a submission are fixed and roughly cost 0.05 ETH (2667571 gas), big miners would prefer to submit batches in short intervals (e.g., once a day) and small miners would prefer long submission intervals (e.g., once a week). In Ethereum, block difficulty is constantly changing (usually increasing). A work in the beginning of the week may be worth more than the same work at the end of the week. For example, during the week starting from 10/4/2017, the block difficulty increased by 6.6%.

Given these difficulties, it is not trivial to make a fair payment scheme for SmartPool that is not pool-hopping secure. In the next section we present our payment scheme, which is a variance of Pay-Per-Share. We also provide that our payment is fair and secure in practice.

SmartPool’s Pay-Per-Share Payment Scheme

In this section we describe the SmartPool’s Pay-Per-Share (SPPS) payment scheme and analyze its properties. For the sake of presentation we first describe a naive way of implementing PPS in SmartPool. We then present the second version (SPPS) that will be used in SmartPool which addresses potential problems of the naive PPS.

Naive PPS

In a PPS payment scheme, every share is paid some specific amount of reward based on the difficulty of the share. For example, if the difficulty of a share is 10⁶ times easier than a block, the share is paid 1/10⁶ the block reward, minus the pool fees if any. One can easily implement a PPS payment scheme in SmartPool by paying each share in a verified submission the same reward, given all shares to have the same difficulty. The share reward is determined by

Block reward * Share difficulty / Block difficulty,

in which block difficulty is the difficulty of the block at the time of submission. Thus, the reward for a batch submission is computed as the number of shares multiplies the share reward.

Implementing this PPS scheme is trivially feasible, it only requires some reserved capital from the pool. Internal pool-hopping (i.e., postponing the batch submission) is not profitable since miners will get less reward since the block difficulty will most likely increase over time. External pool-hopping (i.e., switching to a different pool when SmartPool has bad luck) does not earn the miner more reward either since the miner’s reward does not depend on the pool’s luck.

The naive PPS is not fair in the sense that small miners would receive relatively less reward than big miners . As aforementioned, a miner may submit a batch of shares every week, and the difficulty might vary by 6% within that week. Thus, a work unit could be worth 6% more on Monday than on Saturday. Hence, small miners would lose from submitting only by the end of the week. On the other hand, big miners, by submitting and claiming their reward everyday, will not suffer from the difficulty changes. In the next section, we describe a variant of PPS scheme to solve the unfairness problem.

SmartPool’s PPS

In SPPS (i.e. SmartPool’s Pay-Per-Share), miners still submit and get paid per batch of shares. However, to guarantee better fairness for miners in presence of difficulty changes, we allow miners to commit the found shares periodically, say per hour or per day depending on the size of the miners. For example, a small miner can still verify his batch of shares and get the payment every week, but every day the miner submits the Augmented Merkle root hash of all the shares found within that day. A miner with more mining power can get paid every day and submit the commitments every hour or two. After the miner has committed the work up to some block, he/she cannot submit shares of previous blocks in the next commitment. All commitments must be included when the miners submit their share batch and get the payment. In SPPS, instead of having only one single Augmented Merkle root, the miner has to submit a list of all Augmented Merkle roots as the commitments. When SmartPool randomly select a share for verification, it first randomly chooses a commitment from the batch, and then randomly chooses a share from that commitment. We then check if the share is valid according to all the periodic commitments in this batch. If there is any conflict, the share is rendered invalid and the batch is rejected.

Given that the difficulty does not vary much in a day (i.e. less than 1%) and stays almost constant in an hour, our SPPS scheme guarantees better fairness than the naive PPS scheme. A big miner may still get slightly higher relative reward when commit his work every hour, since the block difficulty stays almost constant within an hour. However, the advantage is much less than in the naive PPS scheme. Note that big miners, who can submit a batch of shares and claim reward, say, every hour, do not have to submit frequent commitments at all.

Drawback

As any other PPS scheme, SPPS requires an initial capital to pay to miners. The amount required is proportional to the size of the pool, i.e. more miners join the pool, more capital is required to prevent the pool from going bankrupt due to bad luck. When we deploy SmartPool on the main Ethereum network, this capital may come from some donations that we received back in January. The capital could be partly from charging the miners the pool fees. More details about how much capital is needed and the fee structure will be available in our next blog post.

Other updates

We have been implementing support for big mining farms which have many mining rigs. The goal is to make the transition from traditional centralized pool to SmartPool as smooth as possible. The support includes: statistics for each mining rig, statistics for the whole farm, connecting all mining rigs to a single SmartPool’s client and so on.

We completed full coverage unit test regression for the pool’s smart contract.

We plan to run a private test on Ethereum mainnet in about 2 weeks. If you want to join the test, please drop us a line at admin@smartpool.io and we will get in touch with you. More details will be released soon in our call for participations post.

Summary

We introduced a SPPS payment scheme which is easy to implement in the SmartPool framework and is secure and fair in practice.

Acknowledgement

We would like to thank the SmartPool donors for their generous donations. Please consider donating to support further SmartPool development.