F/rewards distribution 2 #97
Conversation
maurolacy
force-pushed
the
f/rewards-distribution-2
branch
from
0caebc0 to
ff51423
Compare
This reverts commit a038254.
maurolacy
force-pushed
the
f/rewards-distribution-2
branch
from
ff51423 to
934aabc
Compare
|
Probably this design is good for now as 1) this serves as a PoC/baseline on the user stories that we can improve upon, and 2) we haven't received a concrete tokenomics design from the product team. However, I think problem 1/2/3 needs to be resolved if we really decides on the pro rata distribution over FPs. This is because the protocol needs to ensure the reward distribution is fair, i.e., the reward of an FP has to be proportional to its contribution. Using the last voting power table to do the distribution might cause non-negligible bias. For example, if a FP is slashed and then suddenly the chain has 100 new finalised blocks, then this FP won't get any reward for its previous contribution. This looks like an edge case in terms of engineering, but this bias might not be negligible from the product's pov. It would be good if we create a github issue to track this |
| // Try to use the finality provider set at the previous height | ||
| let active_fps = FP_SET.may_load(deps.storage, env.block.height - 1)?; | ||
| // Short-circuit if there are no active finality providers | ||
| let active_fps = match active_fps { | ||
| Some(active_fps) => active_fps, | ||
| None => return Ok(()), | ||
| }; |
There was a problem hiding this comment.
Maybe add a TODO here that we will have to use the voting power table of the height that is being finalised, rather than the latest height, for fair distribution.
Btw, Babylon side has implemented the exact design for reward distribution at the FP level -- https://github.com/babylonlabs-io/babylon/blob/main/x/incentive/keeper/btc_staking_gauge.go
If a FP falls off the active set it will lose their contribution from previous blocks, true. It is assumed the delta of finalised blocks is typically / usually small (<10?).
Will do. Update: #99. |
maurolacy
force-pushed
the
f/rewards-distribution-2
branch
from
934aabc to
5a3698e
Compare
Follow-up / Alternative to #95, in which the rewards are distributed over the (latest) active finality provider set.
This may incur a number of (small) errors in the distribution, namely:
In summary: These small potential errors are considered acceptable, and are all in the name of simplicity.
Please notice that this also fixes a bug in the impl, in which we were considering the rewards were being sent to the staking contract for distribution. They clearly have to be sent to the finality contract instead, since a) it has the info for distribution, b) it has to send the rewards to Babylon, and so it requires ownership of them.
Will fix this in the SDK and docs next as well.