JaredCorduan
commented
3 years ago Hi @hodlonaut , thank you for providing some feedback! The best way to work through these kinds of proposals is through a CIP. You'll have the attention of the right folks there. I'm going to close this issue, but not at all to be dismissive of the idea. The stake pool rankings are enjoy a lot of lively discussion right now, even among our researchers. thanks again!
Hi
Delegation design spec document (and cardano-ledger-specs code that follows it fairly closely with regards to non-myopic rewards) calculates the non-myopic rewards for pool operator and a member (e.g. person considering delegating amount X ADA to the pool in question) by always comparing f (estimated pool rewards for an epoch) with c (fixed cost, in pool certificate) amongst other logic and variables.
However, when the calculated f (pool reward) for a pool for an epoch is smaller than the average expected reward for a single produced block (I'll call it 1BREW - as we know it's a variable that changes epoch to epoch), I feel current logic can be improved a little to more accurately calculate the estimated rewards. 1BREW can presumably be calculated using some of the data that makes up the 'leaderProbability' field within the same source file - https://github.com/input-output-hk/cardano-ledger-specs/blob/master/shelley/chain-and-ledger/executable-spec/src/Shelley/Spec/Ledger/Rewards.hs, that is using active slot coefficient, decentralization param value and so on to deduce number of leader slots available for an epoch and combining with pool's relative stake.
Since a pool cannot create half or quarter of a block, it doesn't seem right to subtract entire fixed cost value from the calculated f (pool reward) for these cases (typically involves pools outside of top K by desirability). So, for example if current average 1BREW is hovering around 750 ADA on Cardano mainnet, and user A wants to delegate 50k ADA to a pool that has owner pledge of 50k ADA, then since this pool would not be in top K for desirability, we calculate it's expected rewards if it had just 100k ADA delegated total (owner pledge + desired user delegation total)... for simplicity's sake, given this pool would have ~0.09310344827 leader slots per epoch (or roughly 1 block every 11 epochs if I'm not mistaken), it's raw calculated f value (pool reward) would be somewhere in the ballpark of 0.09310344827 * 750 = 69.8 ADA.
But because this value is less than the current calculated value of 1BREW, to more accurately calculate the projected rewards for pool owner and potential member delegator we should compare that f value with (fixedCost (f / 1BREW)), or in this case if we assume most common fixedCost value on the network, (340 ADA (69.8 / 750)) = 31.6 ADA. So non-myopic pool owner reward would be (31.6 + (69.8 - 31.6) * margin m) (I didn't give the margin component enough thought yet, perhaps it should be treated in similar manner, i.e. a fraction of the m for consistency - it just had a lot less impact on current behaviour due to it being typically a small percentage value), and non-myopic member reward would be the remaining amount... with both values being greater than zero, instead of the current behaviour where we end up with 0 as non-myopic rewards for this pool.
I feel like this more accurately depicts the reality of block production and rewards (i.e. if I have a small pool that on average makes a block every 50 epochs, as long as block reward is big enough almost any delegator will get some non-zero reward as a consequence when that block does arrive, and divided by the number of epochs they waited for it it will still be a non-zero value). Another added benefit of this would be the ordering of pools outside of K will be a bit more in line with the reality of the current protocol parameters and pool certificate values, i.e. instead of randomized list of thousands of pools the ones with bigger pledges (assuming equality across fees) would most likely be bubbled up to the top (and that's what we expect in the non-myopic reward case for pools outside of the Nash equilibrium top K).
I hope I didn't ramble on too much, or confuse everyone - I'd be keen to hear your thoughts on the above suggestion for improvement - feel free to point out any gaps/errors in my logic! You can find me on Telegram as @Homersapiens if you need a chat.