I loved Itn and Cardano, but I may not love mainet because of a0!

Staking & Delegation Stake Delegation
118

What is this "DDoS on a pool" attack?

It takes advantage of 2 things:

1-“A pool with a too low RoS will loose its delegates (at least a large part of them)”
2-“Delegating rather large amounts of ADAs to a pool can lead to important RoS drop”

  • a-In my scheme by over-saturating a pool
  • b-In yours by over-saturating a pool, or because of a0 (if the pool leader cannot follow stake in terms of pledge)

An attacker might want to have the possibility take down a pool for several reasons:

  • To harm the Cardano network.

  • To blackmail the pool.

  • Because he thinks he can attract delegates that will have to leave that pool and find another one.

Here is how the attack would do:
1-Take control of a quite large stake but not that high either (at most 1/k needed)

2-Delegate it at once to the targeted pool to have RoS drop dramatically

3-Wait for other delegates of that pool to leave the pool

4-Undelegate the large stake to the pool, so it has only few delegated stake left.

5-Repeat if needed, if the delegates rejoin the pool, until they learn it’s clear the will loose money if they rejoin.

6-Wait for the pool owner to give up and shut down its pool.

how to solve it my scheme:

It’s a proposal it might be perfectible, (I don’t see any way to solve it in yours).

We need to change the way the reward obtained by the pool is distributed, inside the pool. We calculate reward per ADA within a pool this way:

reward_per_ada= obtained_reward_after_fees / min ( total_staked_ADA, 1/k , b0*total_pledge_ADA)

of course if the pool is saturated the pool will not be able to give rewards at this rate to every ADA staked in his pool.

So suppose for each delegate i we have the following information:

  • t_i “time” of delegation (or re-delegation) to the pool
  • m_i the minimum amount of stake of the delegate since delegation
  • l_i live stake of the delegate (l_i >= m_i)

Here is the order in which to reward ADAs in the pool at rate of reward_per_ada until no reward is left

    1-Reward the pledge
    2-Reward delegates up to m_i by chronological order of t_i
    3-Reward delegates up to l_i-m_i by chronological order of t_i

This way someone that delegates to a pool that is not saturated at that time, it is guaranteed to have a “normal” RoS for the amount of ADA delegated at that time as long as he keeps his stake. On the contrary an attacker that would purposefully delegate to a saturated pool will get no reward at all.

As allways I may miss something, and I would love to hear your thoughts about all that. That will be all for me until tomorrow!

1 Like