Understanding SLICE (PPLNS+JD)
Introduction
DMND Pool is the first pool to use the Stratum v2 protocol developed over the past five years by a joint force of FOSS Developers in the Bitcoin Space, mainly the Stratum Reference Implementation (SRI) team. Stratum V2’s goal is to decentralize Bitcoin, specifically the mining and pooled industries. The main lever to achieve this is by righting the wrongs that the previous implementation —Stratum V1— made when it shifted block template creation from the miners to the pool operators. But decentralizing pooled mining is a complex tasks, as mining sits in the cross roads between technology and economics.
This interplay, between technology and economics, has become more poignant over the past few years. We have seen how the pooled mining landscape trended towards centralization by the hands of the Full Pay Per Share (FPPS) payment system. Between FPPS and Stratum V1, the network was constrained into a path of increasing centralization, where a only handful of Pools decided which blocks got into the blockchain. Thus, even in the event of full Stratum v2 adoption, economic incentives towards mining centralization would still be present.
SLICE [1] is a new mining pool payment system designed to tackle this issue. SLICE has been engineered to work alongside Stratum V2’s design, making sure that both centralization vectors (technical and economic) are addressed harmoniously. SLICE ensures that the economic incentives for pools and miners are well aligned towards fairness, transparency, low variance and decentralization. In the following paragraphs we’ll try to summarize and explain how SLICE works in a simple manner.
SLICE: Adapting PPLNS to Stratum V2
When it comes to our requirements as a pool looking to decentralize, PPLNS is one of the best options out there. It provides a clear idea of how the pool’s financial rewards get distributed amongst miners. Furthermore, it’s transparent and very easy to verify if the pool is playing any games. Its also an actual payment system, not an insurance policy like FPPS, and is thus much cheaper for both pool operators and miners.
But PPLNS wasn’t built with Stratum v2 in mind. More specifically, PPLNS doesn’t take into account miners exercising their freedom to build their own blocks using their own node, a feature that Stratum V2 encourages. This also includes the freedom to not mine the most financially lucrative blocks. That’s the Achilles Heel of PPLNS, and its a blindspot that will only get worse as transaction fees become a bigger part of the blocks.
Therefore, SLICE divides the blocks into two parts, the block subsidy and the fees. The block subsidy is distributed with the classic PPLNS method, based purely on the amount of hashrate you contributed inside the lookback window. On the other hand, the transaction fees are distributed according to both the hashrate contributed, and the financial value tied to that hashrate. The fee portion is what the Job Declarator in the Stratum V2 helps miners decide, that’s why SLICE can also be called PPLNS+JD.
Creating fair Slices
So far we have a great set up, one that accounts not only for the work contributed (hashrate) but also for the financial value attached to that hashrate (transaction fees). Nonetheless, we still need to add one last modification to make sure that the system is fair. This has to do with the scoring, or weighting, that each share gets once it’s adjusted for the transactions attached to it, the Job Declarator part of SLICE. Because if all transactions inside the PPLNS look back window are weighted equally in regards to fees, earlier shares will be penalized by no fault of their own.
This is fairly straightforward to understand once you take into account that, as time goes on, the potential for how many fees a block can have increases. Therefore, a share submited at 10am on any given day will have more financial value than a share submitted 5 minutes before, since in those 5 minutes, new transactions have been submitted, and usually at a higher fee rate than the ones before. If we do not account for this, we would just be falling for the same pitfalls as older pool payment methods like SCORE.
This concept of accounting for the maximum value in fees a block can have is technically called Maximum Mempool Extractable Value (MMEV). That’s due to the transactions present in the mempool of each node, which are the transactions miners use to build their blocks.
That’s where slices come in. Instead of having all shares be part of one huge lookback window, and penalising shares that, for no fault of their own, simply couldn’t get more valuable transactions, we subdivide the lookback window into smaller slices of time. Inside each slice, all of the shares submitted will be compared and scored to the highest revenue generating share. Since we assume that in such a small window of time everyone should have the same ability to generate the most amount of fees possible. This benchmark is continuously updated upwards as new transactions with higher fees show up in the mempool, providing a constant incentive to keep generating the best blocks.
Now, thanks to slicing the huge PPLNS lookback window into smaller slices, we can level all of the shares provided in a fair way, not only in regards to fees, but also in regards to fees across time. This innovation is what adapts PPLNS to Stratum V2’s full potential, enabling all miners to exercise their freedom to build their own blocks knowing that they’ll get their fair share of the pool’s rewards.
The size of a Slice
It’s important to note that slices can be as long or as short as the pool wants them to be. There are also certain criteria for when a slice ends and a new one starts:
- A new Blocks is found, thus the current slice ends and a new one starts
- The maximum fees we can add to a block have increased a certain amount X, thus we start a new slice and wait till fees increase by X again before we start a new slice
With this set up, the pool can choose how big or how small X is, and thus modify the dynamic length of the slices. It’s usually recommended that X is fairly small, since this will allow for more slices to be created, which makes the scoring of all shares across time more fair.
Thus, slices are created one after the other in a dynamic way, in an efficient, programmatic, and fair way. Each slice is composed of all of the shares submitted by the miners during that time period, and each share has a difficulty that informs the pool of how much work that share contributes. Therefore, each slice ends up having a certain size, which is calculated in the amount of difficulty inside of it.
Fun Fact: there is no way to actually know the amount of hashrate in anything, be it a machine, a farm, a pool or even the Bitcoin network. The only way we can “know” the hashrate of anything is by inferring it from the shares, or attempts, that it submits and at which difficulty that was. That’s also the reason for why your machine’s hashrate, or a pool’s hashrate, or the network’s hashrate is never stable and fluctuates, because we can only infer the hashrate given the shares the machine submits.
A simple experiment to check this is to use the Bitcoin network itself. You can go to either Glassnode or Coinmetrics and compare the amount of Daily Blocks with that day’s Network Hashrate. You’ll see that they match perfectly for 2 weeks, until the next difficulty adjustment slightly shifts them. This is because the network only allows 144 valid shares per day, which opens the door to a lot of variance. But as we collect more shares, our calculations get closer to the real hashrate. That’s why pools tend to ask for many shares a minute, in order to smooth out the variance.
Share treatment in SLICE
This difficulty is decided by the pool, and in DMND Pool’s case we try to target getting 6 shares per minute from each client. We do this by dynamically modifying the Pool Difficulty for submitting shares that each miner has.
Once a miner finds a share that is above our set difficulty, they send it to the pool, and the pool adds it to the current slice. It is important to note that shares are valued at the Pool Difficulty, not the calculated difficulty of that specific share. This is in order to keep distributions fair, since DMND Pool uses a difficulty based lookback window. Specifically, DMND Pool uses the Bitcoin’s network difficulty and multiplies it by 8 to create the look back window.
A good example for why this is important is the case in which a miner finds a block. The current difficulty to find a block is somewhere above 110T, and the lookback window for DMND Pool accounts for 8 times the current network difficulty worth of shares submitted by miners. But if a miner found a block, they would necessarily have a share with a difficulty worth at least that much if not more, and they would occupy at least 1/8 of the Lookback window and thus get that share of the rewards.
This may sound like a good deal for the lucky miner that found the block, but it’s not fair or efficient for all the other miners, and even the lucky miner would complain once the next block found wasn’t his. Therefore, it’s important to remark that all shares, even the lucky share, are accounted at the pool’s set difficulty for that miner, balancing the system and making it fair once again.
Payouts in SLICE
As previously mentioned, DMND Pool’s lookback window is calculated by multiplying the current Network Difficulty by 8, and then accounting for all of shares submitted that amount to that. But in SLICE, shares are grouped and weighted into slices that normalise them all to account for fees. In the cases were the lookback window cuts a slice in half, the whole slice is included with all of the shares inside of it. All of the shares inside the lookback window are then paid according to the previously mentioned method, were Block Subsidy is distributed only according to work submitted, and Transaction Fees according to work and financial value of said work.
Lifecycle of a Share in SLICE
Since SLICE uses a lookback window of 8 times the Network Difficulty, this effectively means that your shares will be paid 8 times regardless of how big or small the pool is. This is because the lookback window is big, and your share will be accounted for various times. It also means that each share will take a bit longer to reach it’s full expected value, a total of 8 small payments.
When taking all of your shares in aggregate, this means that there’s a ramp up period before you start seeing the full value of your shares being reflected in your payout. On the other hand, this means that there is a ramp down period, where you’ll still be receiving payouts even though you are not mining anymore. This happens because your shares will still be included in the lookback window.
Sources and more learning material
[1] PPLNS with Job Declaration Whitepaper: https://www.dmnd.work/pplns-with-job-declaration/pplns-with-job-declaration.pdf
[2] Delving Bitcoin Discussion on PPLNS+JD Whitepaper: https://delvingbitcoin.org/t/pplns-with-job-declaration/1099
[3] Analysis of Bitcoin Pooled Mining Reward Systems, M. Rosenfeld,https://arxiv.org/abs/1112.4980
[4] Extension on SV2 share accounting https://github.com/demand-open-source/share-accounting-ext/blob/master/extension.md
[5] Incentive Compatibility of Bitcoin Mining Pool Reward Functions https://timroughgarden.org/papers/bitcoin.pdf