Part 3: Proportional Reward Splitting
Split Rewards, not Hairs
Acknowledgement
This post was funded by the Quai network, which generously provided me with a grant to fund my proof-of-work education efforts.
We have dedicated two lengthy posts to exploring incentive alignment in blockchains. We first reviewed the phenomenon of selfish mining on Bitcoin and how it suggests the definitions of chain quality and fairness. We proceeded to examine the FruitChains protocol, and discuss at length its benefits and drawbacks, culminating in the unfortunate realization that — while solving all problems asymptotically — it can not be reasonably parameterized.
Now, we are finally in a position to present the protocol that motivated this entire series: Proportional Reward Splitting (PRS).
The key difference between PRS and FC is in the name: proportionality. In FC, each fruit has the same reward. In PRS, each share has a well-defined height. The amount of reward emitted at each height is fixed and is distributed equally among all shares of that height. This is a subtle yet profound difference. (Note that FruitChains also classifies blocks by height, but only for tracking freshness. Height does not affect the reward distribution.)
This is a subtle yet profound difference. In part because a new share retroactively affects the rewards gained by preexisting shares of the same height, making liveness trickier.
Quick Recap
In the first post, we described selfish mining, a phenomenon first observed on Bitcoin by Eyal and Sirer. We recast this discovery as a (bounded) violation of a retrofitted security property called fairness. Roughly, we defined -fairness as the assertion that as we consider increasingly long time frames, the proportion of rewards collected by an -miner should converge to .
By furnishing a profitable selfish mining strategy, Eyal and Sirer demonstrated that Bitcoin is not fair for a wide range of values (the exact range depends on the underlying network conditions, but even at optimal conditions, their strategy shows that -fairness is impossible for any ).
Selfish mining motivated Pass and Shi to create the FruitChains protocol, which we discussed at great length in the second post.
Incentive Alignment
FruitChains achieves perfect incentive alignment, but with a significant technical caveat: it only works in highly impractical parameter regimes. In other words, the time it takes the -miner's reward proportion to converge to a value close to is very long, while the required rate of fruit production is unreasonably high. It is not known whether FruitChains remains secure in reasonable parameter regimes. However, the security analysis strongly relies on assuming these regimes, and most would agree that analysing FruitChains in any other regime will require a brand new approach.
PRS solves this problem by providing a new trade-off: it allows exchanging the quality of incentive alignment for efficiency. This allows architects to choose a sweetspot where the incentive alignment is sufficiently strong (for example, the practical parametrization discussed in the paper guarantees -fairness for any ), yet the protocol is quick and lean enough for everyday applications.
Rational Equilibrium
A second property of FruitChains that is less than ideal is the necessity of an honest majority. The feat FruitChain achieves is that if at least half of the network is honest, then it is rational to follow the honest strategy.
This is a great improvement over Bitcoin, where a sufficiently large (yet still much smaller than ) rational miner will choose to selfish mine even if all remaining miners are honest. However, we would ideally want to remove the honesty assumption altogether, and only assume that a majority of miners is rational (which is the minimal possible requirement, as a blockchain with a Byzantine majority cannot stand). And that's exactly what the PRS paper shows.
Equilibria Degeneracy
The third issue we recognized in FruitChains is that the equilibrium is degenerate. Note the careful phrasing in the previous subsection: "it is rational to follow the honest strategy." Why not "rational miners will follow the honest strategy"? Ah, because as we noted, that's not the only rational strategy.
The problem is that there are decisions that miners can make that, on the one hand, affect the convergence, but on the other hand, do not affect the miner's expected profit. More concretely, FruitChains define the honest strategy as "packing all fruit you can", but what prevents a miner from only packing their own fruit? It's easier, and it doesn't lose any reward. Furthermore, if all miners choose this strategy, the benefits of FruitChains fade away.
Mathematically, we say that the honest strategy is a degenerate equilibrium. It is only a point in an entire section of equally profitable strategies. And it turns out that "baveling" the equilibrium to become unique is quite tricky.
This is a problem that PRS doesn't solve. And solving it is the motivation for the currently ongoing further research, which we will touch on at the end of the post.
Block Anchoring
FruitChain deals with orphaned blocks in a very straightforward way: it doesn't care. Each fruit of a given height can be repacked by any (sufficiently old) block. A fruit harvested at height can be packed by any basket with height , as long as where is the freshness window length.
In PRS, things work a little differently. Each workshare points to a specific block called its anchor. How can we use this information to design a robust reward distribution mechanism?
As a warm-up, first assume that shares anchored outside the main chain do not count. So, for example, in this case (I'm still using fruits and baskets to represent workshares and blocks because I like fruit):

workshare A will count, but workshare B will not. This is a bad assumption, which we will soon remove, but it is instructive for kicking off the discussion.
While this is ultimately not the correct way to determine workshare validity, it does make a lot of sense. The key benefit is that only the main chain determines what workshares count, so the only way to change how the reward for a particular height is split retroactively is via a reorg. This increases stability and, while making the computation of reward distribution simpler and more localized. (Another benefit, well outside our current scope, is that computing rewards this way is compatible with the PoEM chain selection rule.)
So what is the problem with only looking at the main chain? Perhaps this picture will give you a hint:

2 Selfish 2 Mining
It turns out that ignoring orphaned workshares makes selfish mining possible again!
With some reflection, this shouldn't be such a great surprise. FruitChain works because it decouples block creation from reward distribution. But ignoring shares outside the selected chain couples them right back! Not only is selfish mining possible again, but the very same attacks on Bitcoin can be used here!
An adversary can follow any selfish-mining attack on Bitcoin (e.g., Eyal-Sirer), while also packing all workshares to their own blocks. If they manage to orphan an honest block, they get an unfair advantage because the blocks they introduced instead only anchor their own workshares. It is true that other miners can retroactively add more shares to the adversary block, but why would they? They'd rather harvest on more recent blocks that have fewer workshares already anchored to them. So even in this scenario, only harvesting to newer blocks, leaving the adversary with their advantage, is not only honest but rational.
Hahaha, You Said "Knob"
So how can we use block anchoring in a more subtle way?
Simple, we allow repacking shares anchored in uncle blocks, as long as we are repacking on the main chain. In other words: we are still only counting workshares packed on the main chain, but we allow these workshares to be anchored on uncle blocks.
Consider this scenario:

The block packs the workshare , but that doesn't matter, since is not on the main chain. However, also packs . Hence is counted despite being anchored on an uncle block.
Astute readers might scratch their heads and wonder: Doesn't this completely undermine the purpose of anchor blocks? How is this any better than just using height? And those astute readers are completely right! The key is that we are not allowing all uncles, but only uncles close enough to the main chain.
This is the extra knob we alluded to earlier: the allowed uncle distance. Lets take the time to formalize this a bit.
In a blocktree, the "uncle distance" for each block is its distance from the selected chain. As an exercise, I urge you to examine the blocktree below and make sure you understand why the numbers below correctly reflect the uncle distance of each block, assuming the longest chain rule. (You can challenge yourself further by computing the uncle distance assuming the GHOST chain selection rule.)

This definition allows us to finally define our second knob to be the maximum allowed uncle distance.
Relative Uncle Distance
It will be convenient to provide a relative definition. That is, given blocks and , determine "how far an uncle" is to . The uncle distance from to is defined to be the distance from to the selected chain of . (Note that this is not a symmetric notion. The distance from to can be very different than the distance from to , which is why we say "from to " instead of "between and ". This can be fixed by choosing a bit more precise definition, but we don't require this precision.)
As an example, consider the following blocktree:

The uncle distance from the red block to the blue block is . (The uncle distance from the blue block to the red block is .)
To recover the previous (non-relative) definition of uncle distance, we note that the uncle distance of is simply the uncle distance from to the selected tip.
Putting Everything Together
So the upshot is that we defined two knobs. The workshare eligibility depth (previously known as freshness window), and the allowed uncled distance . The share eligibility policy implied by these two quantities is how PRS is defined. Let's make it explicit:
Definition: A workshare is eligible for block if the following conditions hold:
, where is the height of 's anchor and is the height of .
The uncle distance from to is at most .
So how should we set and ? We will get quantitative about it in the next section. Qualitatively, we want to set to be much smaller than . should represent a depth beneath which forks are sufficiently unlikely. For example, we can take a cue from Bitcoin and set . On the other hand, should be large enough to ensure shares are unlikely to be excluded (at least assuming enough honest miners).
Setting positive to allow "salvaging" workshares lost to shallow forks removes the selfish mining attack introduced by block-harvesting. Making it much smaller than (which needs to be much larger for other reasons anyway) retains the benefits of block-harvesting, at least approximately.
And this is how packing is allowed in PRS.
Let us summarize this in a table (which you are encouraged to compare with the FruitChains table):
PRStimating
After working so hard to define PRS, we conclude by reviewing the results of the analysis in the PRS paper, and how they compare to FruitChain.
Fairness and Convergence;
Since it was fairness we were after, it makes sense to first ask how fair PRS is. For that, let us consider the fairness averaged over consecutive levels. Say that an miner earned a fraction of the rewards within the window, then we would like to bound in terms of the window length , the protocol parameters, and perhaps also the network latency.
The weakest form of fairness is the statement that eventually vanishes. That's not enough. We need guarantees on how fast decays.
As a yardstick to measure how fast decays, we will first work out the strongest possible fairness.
Mining is an independent process: the probability of an -miner to mine the next block is not affected by any past events. It only depends on everyone's relative hash rates and mining strategies. This means that the best we can hope for is . This is the part we can't remove. The natural noise of a Poisson process. The background hum of block production. The price of independence.
For FruitChains, we had the following approximation (for appropriately selected ):
The interesting part of this bound is the term . Comparing it to our yardstick, we see that it already vanishes as fast as we could hope. So what more is there to say? The problem is neatly tucked away into the asymptotic notation. It turns out that the constant preceding is quite large. Not huge by any means, but formidable. The tragedy is that the only knob we have for scaling it down is , and is under a square root. To balance the bound, we must choose on the magnitude of the (quite large) constant squared!
And now the real kicker: recall the "impractical parameter regimes" we kept alluding to? They are impractical because on the one hand, we must have of size "quite large squared". But on the other hand, the parameter regimes force to increase with . The final coffin is the trivial observation that , because the convergence time can't be shorter than the freshness window.
PRS manages to squeeze a much better tradeoff:
Our yardstick reminds us again that asymptotically, is the best we could hope for. But this time, the constants are nice. Nice enough that even for it only exerts a mild effect, and for say it becomes small enough to ignore within a few dozen blocks.
The time-independent component that remains is . One might wonder: how come the time latency doesn't affect the bound? Don't worry, it does. The latency is not directly visible, but it manifests in how we choose (in the sense that any fixed will fail for sufficiently large ). wraps the stiff with a tweakable quantity.
But there's obviously the other side of the tradeoff. In the PRS analysis, we find that the selfish mining threshold has the form . Since we agreed that , we get that can be scaled down. However, we still want to avoid making too large. The convergence time scales linearly with , so setting it to moderately large values like is already purpose-defeating.
So, how should we set ? It is hard to provide analytical answers, so we turn to simulations. And indeed, the authors found via simulation that for a "moderately connected" adversary with a tie-winning probability of , setting and furnishes -fairness for any , a huge improvement over the Bitcoin can offer in the same regime.
Trust Model
A unique feature of the PRS analysis, which does not hold for the FruitChain analysis or most protocol analyses, is the reduction of the honest assumption.
The security of FruitChain holds in a model where there is an honest majority. This is a reasonable assumption, but still a relatively strong one, which we would like to reduce. In a perfect system, the rational majority coincides with the honest majority.
Relying entirely on game-theoretic considerations is complicated, and most analyses, including FruitChains', show that if enough of the network is honest, then it is rational for the rest of the network to remain honest. The PRS analysis shows that rational behavior is an equilibrium, even when no honest players are assumed. However, the analysis must assume that a majority is rational, and a quick reflection reveals that, for any protocol, without this assumption, it is impossible to establish anything.
Some would call such a protocol "self-enforcing".
Incentive Alignment and Future Goals
As mentioned above, PRS does inherit one drawback from FruitChains: equilibria degeneracy. In other words, referring to all workshares is a rational strategy, but not the rational strategy. There are other rational strategies that are equally profitable for the miner but are hazardous for the network. More concretely, a miner is rational if and only if they point to each of their own shares. But they have full freedom to choose how to regard shares by other miners.
Removing this limitation is currently a key priority in PRS research. So how would one go about this?
The hope, at least as I see it, is for finding another "knob" that will allow us to incentivize inclusiveness at the expense of a controlled trade-off of the benefits of the degenerate world. For example, we might find that an increase in share weight begets a proportional increase in the required honest fraction. Such a knob will allow us to make decisions such as "increase the share weight as much as possible without raising the honesty requirement beyond 10%". Of course, this is just one possible scenario out of many.
There is currently an interesting ongoing debate among the Quai developers and collaborators on these questions: What are the consequences of increasing share weight in terms of the honesty model and profitability thresholds? What is the correct way to choose share rates and weights? How do we juggle this array of properties — honesty requirements, incentive alignments, profitability threshold, expected profit, convergence time, and so on — which admit a great deal of subtlety within themselves and even more subtle interactions with each other? Is the share weight even the right parameter, or do we need a fancier knob?
Finding a way to balance out all these requirements into a trade-off that provides sufficient guarantees to all aspects is the art of protocol crafting. By watching or participating in improving PRS, you can see it unfold in real time.
Last updated