update block reward target from KPI event, use that value to pay block rewards #366
Conversation
Codecov Report
@@ Coverage Diff @@
## master #366 +/- ##
==========================================
+ Coverage 42.60% 42.64% +0.04%
==========================================
Files 40 40
Lines 4204 4202 -2
==========================================
+ Hits 1791 1792 +1
+ Misses 2154 2152 -2
+ Partials 259 258 -1 |
| newBaselinePower := a.newBaselinePower(&st) | ||
| st.BaselinePower = newBaselinePower | ||
| st.CumsumBaseline = big.Add(st.CumsumBaseline, st.BaselinePower) | ||
|
|
||
| st.RealizedPower = *currRealizedPower | ||
| st.CumsumRealized = big.Add(st.CumsumRealized, *currRealizedPower) |
There was a problem hiding this comment.
I think this needs to be added as many times as there are iterations in the loop below.
There was a problem hiding this comment.
what @anorth is saying is correct but not exactly right because of the edge cases of null rounds. If there is a null round and UpdateNetworkKPI is called in the round after that, we need to first add the RealizedPower at the null round (before the update) to CumsumRealized to account for the null round, and then update RealizedPower to currRealizedPower and then add that to CumsumRealized to account for the change in power in this round.
|
|
||
| st.EffectiveNetworkTime = a.getEffectiveNetworkTime(&st, st.CumsumBaseline, st.CumsumRealized) | ||
|
|
||
| a.computePerEpochReward(&st, i, st.EffectiveNetworkTime, 1) |
There was a problem hiding this comment.
I would think we can do this just once at the end, though I could be missing a side-effect that's important.
There was a problem hiding this comment.
Yes, doing it once at the end sgtm unless im missing something too.
There was a problem hiding this comment.
I was wrong, it has important side effects on the supply state
There was a problem hiding this comment.
Actually I'm not so sure. Since no reward is actually minted on those null rounds, updating the supply as if there was also seems wrong.
anorth
changed the title
|
@whyrusleeping based on our discussion, I have pushed commits here that simplify the minting function to only count non-empty tipsets, since those are the only ones it pays out. The actor no longer references There are still a bunch of problems, most notably supply over-estimation, but this should pay non-zero rewards reliably (except on the first epoch 😭) |
anorth
force-pushed
the
feat/fix-block-reward-computation
branch
from
c992364 to
3ae5472
Compare
…k rewards (#366) * update block reward every epoch, use that value to pay block rewards * address review feedback * fix CumsumRealized additions * Change reward schedule to only pay on non-empty tipsets Co-authored-by: anorth <[email protected]> Co-authored-by: Łukasz Magiera <[email protected]>
No description provided.