|
| 1 | +# The Reward Calculation |
| 2 | + |
| 3 | +When nodes produce blocks, the block producers and those that have delegated |
| 4 | +their stake to them are rewarded with a proportion of the fees for that epoch, |
| 5 | +as well as a fixed proportion of the reserves. This document examines how the |
| 6 | +rewards are computed. |
| 7 | + |
| 8 | +## Snapshots |
| 9 | + |
| 10 | +The first thing to be aware of is that the reward calculation for a given |
| 11 | +epoch involves the two _surrounding_ epochs: |
| 12 | + |
| 13 | +- The _previous_ epoch detemines the stake distribution used for leader |
| 14 | + election. Since the rewards for a pool are related to its _expected_ |
| 15 | + performance (which depends on its stake), this is also needed to compute the |
| 16 | + rewards. |
| 17 | +- Rewards are given out with respect to how many blocks are produced in the |
| 18 | + previous epoch. However, we would prefer not to have to recompute these data |
| 19 | + if the chain gets rolled back. As such, we wait until all blocks from the |
| 20 | + relevant epoch are _stable_ (e.g. at least $k$ blocks deep[^1]) before computing |
| 21 | + the rewards, which means that the reward computation and distribution happens |
| 22 | + in the following epoch. |
| 23 | + |
| 24 | +## Timing of the reward calculation |
| 25 | + |
| 26 | +The [Shelley Ledger Specification](https://github.com/intersectmbo/cardano-ledger/releases/latest/download/shelley-ledger.pdf), |
| 27 | +section 11 provides a good breakdown of the reward calculation timing, which we |
| 28 | +reproduce here: |
| 29 | + |
| 30 | +```mermaid |
| 31 | +timeline |
| 32 | + title Reward Calculation for Epoch i |
| 33 | + section Epoch i-1 |
| 34 | + A : A stake distribution snapshot is taken at the begining of epoch i−1. |
| 35 | + B : The randomness for leader election is fixed during epoch i-1. |
| 36 | + section Epoch i |
| 37 | + C : Epoch i begins |
| 38 | + D : Epoch i ends. |
| 39 | + : A snapshot is taken of the stake pool performance during epoch i. A snapshot is also taken of the fee pot. |
| 40 | + section Epoch i+1 |
| 41 | + E : One stability window (3k/f slots) into epoch i+1 |
| 42 | + : The snapshots from (D) are stable and the reward calculation can begin. |
| 43 | + F : The reward calculation is finished and an update to the ledger state is ready to be applied. |
| 44 | + G : Epoch i+1 ends |
| 45 | + : Rewards are paid out |
| 46 | +``` |
| 47 | + |
| 48 | +We can thus see that the actual reward calculation takes place between points |
| 49 | +(E) and (G). At point (E) the pool performance snapshot (e.g. how many blocks |
| 50 | +each pool issued in the previous epoch) is stable. At point (G) the rewards |
| 51 | +must be paid out. |
| 52 | + |
| 53 | +Early implementations of Shelley had the reward calculation performed at point |
| 54 | +(G), on the epoch boundary. However, performing such a heavy calculation at the |
| 55 | +epoch boundary had the effect of slowing down block producing nodes at this |
| 56 | +exact point, when they also needed to perform other computations relevant to |
| 57 | +transitioning to the new epoch. As such, later implementations moved to |
| 58 | +computing the reward computation incrementally beteen (E) and (G). New node |
| 59 | +implementations should take this into account. |
| 60 | + |
| 61 | +Note that, while computing the rewards at the epoch boundary was especially bad |
| 62 | +(since this coincides with a number of other things that need to happen), we |
| 63 | +want to avoid heay CPU spikes at any determined point in the chain. Thus the |
| 64 | +Haskell node deliberately spreads the calculation across the period between (E) |
| 65 | +and (G). Alternate solutions (such as computing the rewards in the background) |
| 66 | +were considered, but rejected due to a couple of things: |
| 67 | + |
| 68 | +- Difficulty in restoring the state of a partial computation should the node |
| 69 | + restart before completing the computation. |
| 70 | +- Wanting to avoid a CPU spike when the computation begins, even though that |
| 71 | + spike may be happening in the background. |
| 72 | + |
| 73 | +This is an instantiation of the principle of wanting the [worst case to be |
| 74 | +equal to the average case](../../principles/README.md). |
| 75 | + |
| 76 | +## Pots |
| 77 | + |
| 78 | +Aside from the UTxO and the reward accounts, there are a small number of |
| 79 | +distinguished places where funds can be held within Cardano. We typically refer |
| 80 | +to these as "pots" and they consist of the following: |
| 81 | + |
| 82 | +Reserves |
| 83 | +: A proportion of the initially minted ADA which provides initial funding for |
| 84 | + block producers. |
| 85 | + |
| 86 | +Treasury |
| 87 | +: An account for funding future development of the ecosystem. A certain |
| 88 | + proportion of fees get allocated to the treasury each epoch. |
| 89 | + |
| 90 | +Fee |
| 91 | +: An accumulation of the fees paid for transaction processing. |
| 92 | + |
| 93 | +Deposit |
| 94 | +: Deposits which are held by the system in compensation for data held in |
| 95 | + non-UTxO parts of the ledger state (such as stake pool registrations). |
| 96 | + |
| 97 | +Not all of these pots are involved in the reward computation. |
| 98 | + |
| 99 | +In addition, there is one "pseudo-pot" to which we make reference in the |
| 100 | +description of the reward calculation - the "reward pot". This is basically the |
| 101 | +"in" side of the reward balancing - the total amount of funds to be paid out to |
| 102 | +SPOs, delegators and the treasury. |
| 103 | + |
| 104 | +## Inputs to the reward calculation |
| 105 | + |
| 106 | +The following table details the various inputs to the reward calculation, |
| 107 | +including where and when they come from. |
| 108 | + |
| 109 | +| Name | Symbol | As Of | Role | |
| 110 | +| ---- | ------ | ------ | ---- | |
| 111 | +| monetaryExpansion | $\rho$ | (D) | Determines the proportion of the reserves which are added to the fee pot each epoch | |
| 112 | +| treasuryCut | $\tau$ | (D) | Determines the proportion of the "reward pot" to be paid to the treasury each epoch | |
| 113 | +| poolPledgeInfluence | $a0$ | (D) | Determines how much the pool pledge contributes to stake pool rewards | |
| 114 | +| poolParams | n/a | (A) | The pool's registration parameters determine how the pool's rewards are distributed | |
| 115 | +| fees | n/a | (D) | Fees paid during the previous epoch | |
| 116 | +| blocksMade | n/a | (D) | Number of blocks produced by each stake pool during epoch i | |
| 117 | +| Stake Distribution | n/a/ | (A) | The stake distribution governing leader election during epoch i | |
| 118 | + |
| 119 | +In eras before the switch to Praos consensus (e.g. when still using TPraos), |
| 120 | +the protocol parameter $d$, measuring the decentralisation of the system, was |
| 121 | +also a relevant factor in the reward calculation. |
| 122 | + |
| 123 | +## Requirements on the Consensus Layer |
| 124 | + |
| 125 | +Computing rewards represents the one area where there is a dependency of the |
| 126 | +ledger on the consensus layer (all other dependencies are in the other |
| 127 | +direction). Specifically, the ledger relies on the consensus layer to inform it |
| 128 | +as to the number of blocks made by each stake pool in the preceding epoch (the |
| 129 | +'blocksMade' parameter above). |
| 130 | + |
| 131 | +[^1]: Whilst we express the bound in terms of blocks, we actually measure it as |
| 132 | + a fixed number of slots ($3k/f$), relying on the Chain Growth property to |
| 133 | + guarantee that we will have the requisite number of blocks in that time. |
0 commit comments