Update ECDSA staker rewards to incentivize growing ETH under management

[pdyraga]

We need to update allocations to better incentivize growing ETH under management - rather than the churning behavior the current allocation mechanism has yielded. One possible strategy not involving a lot of changes is to adjust ECDSA keep rewards by the lifespan of a keep. From the on-chain perspective, stakers will submit a heartbeat to prove the keep is still active. From the off-chain perspective, to minimize operator's ETH expenditure, we can use application-specific actions introduced in the client to send a heartbeat to ECDSARewards contract at a deposit redemption request associated with the given keep.

[Agoristen]

If you reward lifespan without taking capital into account, you do not incentivize the growing of ETH supply. Rather you incentivize a new type of abuse.

I've kept my mouth shut about this, because I wanted interval 2 to end before laying out all the details. This strategy would have worked in interval 1 & 2, however if you enable this suggestion it will be far more effective and profitable.

This is how it works:

1. Deploy minimum 3 nodes. You only need the minimum amount of KEEP in each.
2. Using a bot, you spam deposit (timeout) transactions by lot size in descending order to fill up available capacity.
3. Assign ETH bond to your 3 nodes.
4. Spam the network with real deposits while monitoring the other nodes

At point 4. if any of the other nodes add capacity, you repeat 2.

Using this strategy, all real deposits will be sent to your own nodes. With all available capacity used up, you can use a lot size of 0.01 TBTC and therefore tie up very little real capital (ETH).

Here is a simple cost-analysis on filling up the network:

The table above shows you what it costs to fill up all available slots for each lot size. My assumption is that it costs 0.25 ETH per deposit (timeout). The cost for filling up all available node capacity is therefore 56.75 ETH.

Quite frankly, a pittance.

Depending on the ETH capital you're willing to deploy and the capacity of the network you can select your preferable lot size. If you find 0.01 TBTC to be too costly, the attack may still be viable at 0.1 TBTC and so forth.

Real deposits are of course not free either, but historically it's been very profitable to churn, and more so when each keep is spread across 3 nodes of which you are the sole owner. And now you don't need to churn, just deposit and skip the minting process, that way nobody can redeem it. All it takes is 1 single actor abusing this system. He could make millions of dollars at the expense of every other participant, all while providing zero utility and capacity to the network.

I've long argued on discord that incentives must be based on capital and written a blog post about why.

Any other system is very easily schemeable.

Now that I've mentioned what ETH stakers could do. What about KEEP stakers? Turns out this is actually much worse than current system in that regard too, because KEEP whales now gain an additional, unprecedented advantage.

By fighting against the churning of 10 TBTC you open the door for large KEEP whales to spam good-for-nothing 0.01 TBTC deposits and thereby secure themselves the vast majority of rewards. Similar to how 10 TBTC has been churned by ETH stakers in previous intervals, all you do here is flip the abuse from ETH holders to KEEP holders. This is bad, because you're not actually solving a problem, you're just exchanging it for another one.

These are two opposing forces, and might potentially result in whale wars. None of which really benefits honest stakers in the network.

If you do not take capital into account, the biggest contributors to TBTC (the ETH stakers) will get rewarded less than those who have a lot of KEEP.

If you want more ETH, this is the polar opposite of what you should do to attain it.

[mhluongo]

@Agoristen appreciate you taking the time to be explicit about the misaligned incentive here. Unless I've misunderstood our work for the past few weeks, though, this shouldn't apply in interval 3

One possible strategy not involving a lot of changes is to adjust ECDSA keep rewards by the lifespan of a keep.

My understanding is that we're still talking about capital * time here (can you confirm @pdyraga?) and that our differences are about how best to incentivize capitalization vs bond utilization.

To be clear, I believe the difference in the approaches we both have in mind is that you'd like to incentivize capacity and punish misbehavior (paying out rewards to anyone who bonds and stakes, then stopping if they don't operate), versus our currently developed approach that just incentivizes good behavior (back a keep, get rewards by how much ETH is locked up * the time).

I'm sympathetic to your approach, but to reiterate we will not be basing rewards on the number of keeps * time, regardless of whether we choose your approach or the one we're currently developing. It will be the economic weight of keeps that matters, not the number.

[pdyraga]

Thanks for writing this up @Agoristen. This issue does not present the final version of what we think the rewards should work and I think we all do agree the reward one receives should be a function of capital and time. What I propose to achieve here is to capture the "time" component in the code, purely from the technical side, and work on "capital" component separately.

To be clear, I believe the difference in the approaches we both have in mind is that you'd like to incentivize capacity and punish misbehavior (paying out rewards to anyone who bonds and stakes, then stopping if they don't operate), versus our currently developed approach that just incentivizes good behavior (back a keep, get rewards by how much ETH is locked up * the time).

I have read @Agoristen blog post and that's my understanding as well. Incentivizing capacity, in my opinion, is harder to capture in a smart contract especially with how the bonding contract is constructed and assuming we do not want to spend a bunch of ETH on reporting misbehavior.

we will not be basing rewards on the number of keeps * time, regardless of whether we choose your approach or the one we're currently developing. It will be the economic weight of keeps that matters, not the number.

💯 👌

[pdyraga]

The approach for calculating staker rewards has changed as we were discussing it with our community on project's Discord but the original idea remains the same: we want to incentivize the growth of ETH under management. Because the new approach can't be executed on-chain, rewards calculations will be performed weekly off-chain, and committed for distribution using a variant of Uniswap’s Merkle distributor. The team will publish a script to compute weekly rewards in advance of the first distribution. All the PRs targeting this issue are implementing this behavior.

These two functions allow a staker to calculate their reward weight, an indication of how much a particular operator node should earn relative to the rest of the pool. By calculating the reward weight of the entire pool, stakers can see how much of a rewards interval they can earn, and project their return on investment.

The detailed explanation is available here: https://blog.keep.network/a-new-rewards-mechanism-deef3412c3e1

[pdyraga]

Happily closing with #644.