Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fee Revenue Decay Rate set to per topic's epoch rather than global fi…
…xed constant (#529) ## Purpose of Changes and their Description Currently, we use a global parameter to drip revenue to the same extent across all topics, regardless of their epoch length. This is somewhat unfair, as topics of larger epochs then get dripped comparatively less than those with shorter epoch lengths. @jmdkastro proposes a more appropriate way of updating effective revenue, that actually takes the topic epoch length into consideration (through calculation of "epochs per week"). Relevant text from the whitepaper: The quantity `C_{t,i}` decays _each epoch_ by subtracting an amount `∆ C_{t,i} = N_{epochs,w} * C_{t,i}` (where `N_{epochs,w}` is the number of epochs per week) and thus captures recent revenue. This PR modifies the keeper.go `DripTopicFeeRevenue` function to do the following: identify if we have dripped yet this epoch. If we have not, then calculate the number of blocksPerWeek based on the blocksPerMonth, get the epochs per block from the topic, then do the math to calculate how much to decay for this epoch. Then it overwrites the fee revenue for this topic, and marks this epoch as having been decayed. This change add a new data structure to the keeper called `lastDripBlock`. This change also deletes the global emissions module parameter `TopicFeeRevenueDecayRate` ## Link(s) to Ticket(s) or Issue(s) resolved by this PR PROTO-2150 RES-302 ## Are these changes tested and documented? Our existing unit tests were adapted to fit this new change, as some of them had broke from the different algorithms.
- Loading branch information