Paris B: Minimal Balance

[jdsika]

We are discussing the changes to TRD and I was wondering about this statement here:
tezos-reward-distributor-organization/tezos-reward-distributor#703 (comment)

Can you clarify this, please?

Best regards
Carlo

[Groxan]

Before P everything was super simple: baking power consisted of staked balance at the snapshot time and delegated balance at the snapshot time, so it was super easy to calculate both components on the indexer side. And tzkt showed you exactly those values in the rewards model.

However, in P we have a different situation: baking power consists of staked balance at the end of a cycle and minimal delegated balance over the cycle. And this changes everything! First of all, it's just impossible to tell at what moment the minimal value was reached, because in theory it can be reached multiple times per cycle with different combination of delegators and their balances. And therefore, it's impossible to precisely and unambiguously say what delegated balance a particular delegator had. Also, in general, calculating a minimal-over-cycle value is hardly possible on the indexer side, because we would need to fully replicate the whole protocol's code, because even the order in which we apply balance updates matters (because -10 + 5 and +5 - 10 lead to different extremums: -10 and -5 accordingly).

So, we initially thought about removing the delegated balance from the rewards model at all, because it was impossible to accurately calculate it for a given delegator, nor fetch it from RPC, but this would break all existing rewards distribution tools and approaches in general... Therefore, instead of removing it, we decided to simplify it and use a sort of approximation - in the rewards model we show staked and delegated balances both at the end of the cycle. This approximation allowed us to keep delegation rewards distribution work as before, just with negligible error.

[jdsika]

Thank you for this answer. Replicating the protocol would in fact not make any sense.
I would assume that with this new behavior the Octez client would need to provide a RPC to privide the correct value accoring to protocol. Was this issue discussed with the protocol team?
I am having trouble to understand the reason why the snapshot time would be different for stakers and delegators - I guess it provides flexibility to the delegators...

Is there an issue in the Tezos Gitlab for this?

[jdsika]

I created a ticket: https://gitlab.com/tezos/tezos/-/issues/7259

[Groxan]

Yes, we discussed it with the protocol team and, unfortunately, there is no good solution for that issue because of the nature of "min-over-cycle" values.

The RPC endpoint you suggested (returning min delegated balance for a particular delegator) won't help, because min delegated balance of the baker is not equal (but greater or equal) to the sum of min delegated balances of his delegators.

What you really need is to take a snapshot of all delegators with their balances each time when baker's delegated balance hits a new minimum. But it's too costly, because delegated balance is updated really often (it can be updated multiple times during processing a single block or even operation).

The reason, why they use min-over-cycle value, is because they removed balance snapshots (before P there were 16 snapshots per cycle, and the protocol randomly selected one of them for rights distribution).

[Groxan]

I'm closing this as resolved. Feel free to reopen if you have any further questions.