Jormungandr: [JIP] - Implement pledge logic

[mark-stopka]

Is your feature request related to a problem/context ? Please describe if applicable.
In order to experiment with different reward sharing schemes, I would like Jormungandr to support the concept of pledge, following would be desired:

• Pledge operation mode can be either static or dynamic

  • Static pledge is part of the pool registration certificate and must be met at the end of each epoch
  • if actual pledge is greater than the registered amount, it does not impact the calculated rewards
  • if actual pledge is lower than the registered emount, no rewards are paid
  • Dynamic A pledge is part of the pool registration certificate and must be met at the end of each epoch
  • if actual pledge is greater than the registered amount, it impacts the rewards is if the registered amount would be the actual amount
  • if actual pledge is lower than the registered emount, no rewards are paid
  • Dynamic B pledge is NOT part of the pool registration certificate and rewards calculation works with the actual amount
  • actual pledged amount is used for rewards calculation

• Pledge can have following influence on rewards calculation

  • absolute pledge influence
  • relative pledge influence

Absolute pledge influence
Absolute pledge influence means that rewards are calculated as described in 5.5.2 Pool Rewards chapter of Engineering Design Specification for Delegation and Incentives in Cardano–Shelley

Relative pledge influence
For relative pledge inflience, absolute pledge influence formula is modified in such a way that pledge influence is calculated as a relative meassure between the __pledged__ and __total delegated stake__, if pledged stake= total stake, pool is eligible for maxial rewards, as the total stake increases above pledged stake, amount of rewards to distribute is decreasing.

Other notes
It should be possible to switch between different _pledge operation modes_ during a chain live-cycle and it should be possible to switch between pledge influence modes...

Implementation should reflect the fact that it may be desirable to test many different formulas for pledge influence, including one described in CIP-ShawnMcMurdo-CurvePledgeBenefit .

@NicolasDP or @vincenthz do you believe that this could be implemented in this mainstream project without adding too much overhead for overall project mainenance when doing "your stuff"? Would it be possible to help-out @pavlix who would be implementing this, so he can get faster up to speed with the code structure,...? I am sure he will be happy to document what he will discover during this excersise in a form of a developer documentation which seems to be rather obsolete...

Other references

• Reward Sharing Schemes for Stake Pools
• Jorm Reboot Issue: Add pledge influence factor to rewards sharing scheme

[mark-stopka]

@pavlix the documentation regarding rewards implementation is IMO here in chain-libs...

[mark-stopka]

@pavlix, any update since our call last week?

[vincenthz]

this needs a jormungandr related proposal, not a link to an unrelated project's "engineering spec". personally, I'm rather unconvinced by the concept of pledges altogether.

[sjmackenzie]

Exactly what problem does the concept of a pledge solve? Could you expand on "different reward sharing schemes".

[pavlix]

@sjmackenzie Hello. As far as I understand the goal of pledge is to distinguish own stake from delegated stake and reward own stake to motivate stake owners to become stake pool owners and possibly cooperate with their trusted friends running a co-owned stake pool rather than opt delegate to other parties.

[mark-stopka]

personally, I'm rather unconvinced by the concept of pledges altogether.

Does that mean that you don't think a sybil attack vector would be a valid attack vector in liquid proof of stake consensus protocols such as Ouroboros or you don't think that pledge mechanism provides a sollution for such attack vector on the consensus layer?

[vincenthz]

note, pure ouroboros doesn't have a sybil attack vector at all by design.

But to answer your question, it's more about the later; The more general pressing problem is starting/continuing the protocol with "whales" (divided or not).

[mark-stopka]

@vincenthz, true, it's game theory assumption as opposed to direct Ouroboros consensus protocol feature...

More to the point though, you may have hear I am proposing a project dCloud[1] as part of Project Catalyst, when it comes to the relative pledge influence, it's the reward sharing scheme we would like to use for our dCloud Telemetry Sidechain, we have not decided if we run it using Jormungandr or cardano-node...

So my question is, we want to maintain minimal differences from upstream at this stage of the project, would it be possible to implement such functionality (as optional) in any way, shape or form in a minimalistic version. You may notice, I have tasked @pavlix as the developer, so the prior censorship anger issues would be avoided even if this is merged to upstream...

dCloud Telemetry Sidechain should be implemented using Ouroboros Praos because IOG PoS side-chain already demonstrates it's feasibility so given the restricted budget in current Project Catalyst funds, we would rather not re-invent a wheel...

We also have big plans with PolderCast so it is in our best interest to contribute to Jormungandr, @pavlix has deep understanding of networking, he was actually one of the lead developers of NetworkManager employed by Czech RedHat branch...

@romainPellerin, can we figure out a way how to work on this as a joint effort?

[1] - https://cardano.ideascale.com/a/dtd/Decentralized-Cloud-Platfom/322909-48088