Paris support

[nicolasochem]

In Paris, everything is changing. As "Paris B" was chosen by governance, as soon as Paris activates, adaptive issuance will kick in.

Paris starts at 5,726,209 cycle 743. There will be a grace period of a few cycles where the rights have already been calculated, so first cycle with active AI is 748 .

Then, rewards calculations will change. In tezos, rewards are derived from baking rights. In Oxford, baking rights come from delegation (including baker's own balance). In Paris, they are split in 2 unequal parts:

• 2/3 of rights come from staking. Staking is now an explicit operation: both bakers and their delegators can stake their tez (put them at stake). Staking rewards are paid in protocol, only tz account can bake (no smart contract can bake)
• 1/3 of rights come from delegation as before, however the methodology to calculate rewards is changing:
  • there is no more 5 cycle delay between delegation and reward accrual. this is replaced with a 1 cycle delay
  • there are no more concept of "snapshots" with balances taken at random, determining the stake (hence reward distribution). Instead, the lowest balance throughout the cycle is taken into account for reward calculation.
  • also, the fees collected in blocks by bakers (negligible today) are not taken into account for staking rewards. They all go to delegation rewards.

Note: this 2/3 / 1/3 distribution is global, not per baker. It is possible for a baker to have no stakers, only delegators, or no delegators, only stakers.

There is no RPC to query this lowest balance. Therefore, the ability to implement a simple RPC-based reward distributor has been lost.

For a while, the only supported backend of TRD has been tzkt. This will remain the only supported solution in Paris, however tzkt did not implement the same calculations as the protocol for minimal balance. It is still providing reward data, by looking at the end of cycles. TRD will keep using this data, even though it does not precisely represent the reward distribution, it approximates it.

The first few cycles after Paris, rewards are already calculated using Oxford formulas. Adaptive issuance calculation takes effect a few cycles later only. This is all handled by TzKT, so we do not concern ourselves with this.

Other things we should do:

• deprecate estimated early rewards: now, everyone will be getting that since PRESERVED_CYCLES=5 is going away.
• deprecate ideal rewards: staking rewards won't be ideal, so having ideal delegation rewards would be confusing. Besides, the calculation for this would be changing (which parts of unrealized rewards would have gone to delegation rather than staking?) and we do not want to introduce new calculations.
• previously, it was the case that the baker's fees earned from inclusion of operations in the block would be redistributed to delegators. Now, under the Adaptive issuance, the in-protocol reward mechanism does not redistribute these fees at all. It only redistributes the PoS rewards. What is for us to do?
  • calculate portion of block reward from fees attributable to delegation, and distribute them
  • distribute all block rewards from fees equitably to delegators
  • leave all block rewards from fees to the baker
  • let the user choose (new configuration knob)
    We will pick solution 3 (leave all fees to the baker). This makes delegation reward distribution similar to staking reward distribution, is less work for us to implement, and keeps the software simpler.

I will update this ticket as development progresses.

[jdsika]

"also, the fees collected in blocks by bakers (negligible today) are not taken into account for staking rewards. They all go to delegation rewards."

If there is no delegation and I am not using e.g. TRD as payout tool then the fees remain with the baker and are not distributed to the "stakers"?

sorry. Didn't see the last parageraph before doing the comment :)

"We will pick solution 3" - I am ok with that!

[jdsika]

For a while, the only supported backend of TRD has been tzkt. This will remain the only supported solution in Paris, however tzkt did not implement the same calculations as the protocol for minimal balance. It is still providing reward data, by looking at the end of cycles. TRD will keep using this data, even though it does not precisely represent the reward distribution, it approximates it.

Has this issue been raised with the tzkt team?

[jdsika]

For a while, the only supported backend of TRD has been tzkt.

Everstake uses tzPro but the service will be deprecated and therefore we can remove it.

UPDATE: TzPro APIs will further be maintained by Trilitech according to this tweet