Staking Rewards Distribution at Protocol level

MIPs (Mina Improvement Proposals)
1

I wonder on the road to mass adoption whether a system where staking rewards distribution is integral to a nodes configuration could be implemented at protocol level?

This could allow someone running a node to configure a payout schedule and their % commission without the need for an external script.

I would be interested to hear feedback from the team as to whether this is a good idea or not.

I know the cost barrier to running a successful node is fairly high at this point, but this feature may be one that standardises the process and gives greater clarity to the community around staking in general.

5 Likes
2

I did not see your topic and I was going to create one. In my opinion, Mina needs this feature.

On Mina, validators process staking payouts. They have to:

1/ compute payout based on epoch-2 ledger and their fee
2/ send transactions to pay their delegators

I’m not able to discuss pro and cons from the technical standpoint. I’m sure developers and other members will help on this point.

From the validator perspective, I can see a few advantages. First, they can choose the payout frequency. Then, it allows to implement a couple of advanced features

  • redirect payouts to a single payout account (to get supercharged compound yield)
  • customize fees ( for example distinguish locked and unlocked accounts or provide deals with better fees in some cases)

On the other side, there are considerable disadvantages to both validators and delegators:

  • this behavior has many security risks: rewards are at risks until the distribution. Here are the more obvious I can think of:
    ** losing coin receiver key: BP loses access to rewards and can’t proceed to payouts
    ** suffer of a coin receiver key steal: an attacker would be able to steal rewards
    ** setting a bad coin receiver: in the event of a bad configuration a BP could send rewards to a ‘burn’ account
    ** mistakes in the reward calculation or at the transaction time: it would result in inaccurate amounts sent (at least). In the end, some delegators would not get their full share.
  • the more a validator customize its fee policy, the more unclear it is for the delegators. It is very likely that most delegators delegate through Clor.io or Auro wallets without knowing about advanced fees/features or special terms implemented by the validator. It opens the gate to potential abusive T&C that could deny reward distribution to some delegators. Also, it is unclear what kind of policies a validator is allowed to implement. (outside of the MF program a validator can do anything).

Of course, honest validators applying best practices are safe. But why put unnecessary trust on the validator side?
In addition, MF program is a significant recognition of a validator’s work. It gives top 120 validators a significant stake and encourages delegators to choose them. However, nothing proves that top120 get there applying best practices to prevent those risks. Especially when the daemon is getting very reliable and most validators are moving toward a 100% uptime.

Finally, the European Union did vote a law that could force European validators to proceed KYC before sending any transaction. (see Crypto assets: new rules to stop illicit flows in the EU | News | European Parliament)
It could force a delegator to identify himself in order to receive its rewards from such a validator. It would be a major issue for Mina users’ privacy.
On the other side, rewards distribution at protocol level does not allow such KYC.
In my opinion, this example shows that it is a bad thing to put unnecessary responsibilities on validators. Especially when it could allow censorship.

I don’t know how difficult it is to move payouts at the protocol level.
Since most of us already use the same script, may be there is little work to integrate this code into the Mina protocol implementation.
If automated payouts at block production times generate to many transactions, Mina could let delegators or validators trigger payout like Polkadot does (Simple Payouts · Polkadot Wiki).

Please let us know your opinion. I’d like to know the pro/cons that I missed.

2 Likes
3

The first one is not an advantage since you spend a lot of time processing the payments vs it vs sending a single transaction.
the customized fee also can exist on-chain reason it doesn’t exist is. To start with it’s just complicated for users can be exploited etc. Another problem is depending on the protocol it can cut a significant part of it’s throughput to just make these calculations. In short, it’s an unnecessary weight for a gimmick use case

If this is happening that BP is 99% malicious. The distribution is processed by a script no one sends the transactions one by one manually or calculates them somewhere.

These can happen but mostly shouldn’t happen(You can also lose your crypto in exchange, smart contract etc these kinds of risks always exist and you only risk rewards in this situation while it’s not optimal not a significant thing IMO). Also for the first example if someone can’t take responsibility for their keys and lose them. Which is the first step into crypto that person shouldn’t be a BP.

I agree but making it at the protocol level requires an insane amount of resource, time and cost. There is also the problem of maintaining that system between updates. The on-chain rewards system can be exploited so it’s not a simple thing to do.

At the current state impossible script utilized a staking ledger which the chain doesn’t keep. I believe the whole payout system needs to be designed from the ground up. Which is again a lot of work.

4

Thanks for all your details comments Emre, it is great to see someone with a lot of experience and knowledge sharing information on an open platform.

BUT!..

Looking at things from a slightly less technical background I think that having a system where payouts could be distributed at the protocol level would give Mina Hodlrs a level of assurance and trust that would encourage them to stake Mina with validators in the community apposed to on an exchange.

This would be awesome for the project and if MP is serious about being used by a lot of people then increasing throughput has to be something that is looked at anyway.

Do you think it would be possible to create a zkApp that developers could use (like Gareths script) that could essentially do the same thing in a more user friendly way?

5

I mostly agree with all you said, but I think you do minimize disadvantages.

Distribution made by script gives many rooms for errors including bad usage, wrong customization, and additional security treats.

Also, you mentioned that it brings crypto exchange risks at the validator level which is definitely something we should prevent.

@bkase
Since this feature is discussed in several topics here, could you give anonther feed back? How difficult is it to implement?

6

I aggre but here is the problem while protocol level will utilize the functions from zkapps it’s very long and hard process to implement. Depending on implementation we might face a time where someone exploit the system mint a lot of coins out of thin air or take others staking rewards.

You can create a zkapp but how people gonna feed the data is a bit problem which source you trust since the chain only keeps the staking ledger for 2 epochs, How you going to distribute etc. Since it’s also opt-in thing if it’s a zk app so I don’t think it’s working out rationally even though I prefer the app since running the script and wait for it to complete for hours than verifying can be annoying from time to time.

There is not much room for error unless there is someone malicious behind it, it’s wrong customization sure but still very low since you don’t customize it every single time. Security risk always exist someone can take control of the key from the validator. Normally on most chains, you don’t have to worry about your rewards getting stolen but you can get slashed and lost your stake so considering that risk is lower here. Not sure about the crypto exchange stuff you mention but exchanges will always have a significant part of the network that’s not something you can tackle with products or development.

1 Like