PoS add re-delegation about namada HOT 10 CLOSED

Yeah, we can do that with some queue that is processed by the protocol - it will need to update data in the re-delegation target if and when some slash(es) for the source are found

from namada.

We're putting this back in scope for Namada as it's an important feature for users and having to wait for unbonding period to re-delegate is not only cumbersome for users, it also makes them forfeit their delegation rewards they could have received during the unbonding period.

We discussed a potential solution to re-delegation and we'll sketch it out the in spec next.

from namada.

But can't we treat all redelegations from A to B in epoch e (A, B, e arbitrary) the same? We shouldn't need to iterate over them separately, no? (if not, why would we?)

Ah right, yes that should be fine. We should only need as many iterations as the number of unique re-delegation target validators in each relevant epoch.

We can perform processing once per redelegation at the pipeline offset delay to update the voting power / rewards / bond amount, I think.

When a re-delegation is requested in epoch e, the rewards for the original delegation up to epoch e + 1 (before pipeline) should be "transferred" to the re-delegated bond. Taking in consideration that rewards are also distributed at pipeline offset so that we're not affecting validator sets before pipeline offset, the reward for epoch e should contribute to the re-delegated bond at e + 2 and the reward for e + 1 should be added at e + 3 to be consistent with the reward products.

However, we actually need to apply this in advance at e and e + 1 rather than e + 2 and e + 3, so I think we might need to process the re-delegation when we're distributing rewards in e and e + 1 (i.e. twice for each re-delegation).

from namada.

There's a potential problem with slashing that's applied after re-delegation, because the re-delegated amount would be unbonded and bonded to the new target at unbonding offset, but unlike tokens that are unbonded for withdrawal, which are being slashed when they are being withdrawn, there's no further action required with the current re-delegation design.

When we re-visit re-delegation, we should add spec of it as it has to be accepted by the validity predicate and we should re-visit the integration spec in https://dev.anoma.net/master/explore/design/ledger/pos-integration.html?highlight=redelegate#delegator-transactions - this is not very clear, because we're re-using delegate function definition, which also transfers tokens, but re-delegation keeps all the tokens in PoS.

from namada.

At the point the re-delegated amount is bonded to the new target, can we check if there were any slashes since discovered that need to be applied?

(this may require some sort of queue, but the processing required should be low and thus safe, I think?)

from namada.

A high-level sketch of re-delegation functionality:

• A new delegator PoS action redelegate(owner: Address, old_validator: Address, new_validator: Address) that would allow to fully re-delegate a delegation bond (partial re-delegation is not allowed):
  • find the current amount of the bond - i.e. apply rewards and processed slashes to the old_validator delegation, if any (for delegations, this normally happens only when withdrawing to avoid iteration)
  • at pipeline offset, deduct re-delegated bond's amount from old_validator's total stake and add it to the new_validator
  • for the source delegation's old_validator, record re-delegation with the new_validator, the full amount of tokens that's being re-delegated and start and end epochs of the source delegation (the end epoch would be at the pipeline offset - 1)
    • Note that a validator can have many re-delegations, any slashes to this validator has to iterate all of these when being processed
  • For the target delegation, record the old_validator and the start and end epoch of the source delegation
    • A bond can only have one re-delegation at the time - while there's a re-delegation on a bond with end epoch + unbonding_len > current epoch , it cannot be re-delegated again
    • After that, the bond can be re-delegated, but additionally it has to:
      • Check if there are any rewards and slashes for the re-delegation's source old_validator while the re-delegation's amount still contributed to the source validator's stake, apply them together with the re-delegation's target new_validator rewards and slashes
      • The record of the old re-delegation should then be deleted in both the previous re-delegation's source old_validator's records and the target new_validator
  • On a new slashable event from the old_validator that has occurred somewhere between the re-delegation's source start and epoch epochs, once the slash is processed in the protocol, it will apply the slash rate on the amount of the re-delegation's target new_validator's total stake
  • A re-delegation must also be checked when a delegation is being withdrawn using the re-delegation record on the bond, if any, to find any slashes applicable to the old_validator
• Validator self-bond naturally cannot be re-delegated as validators are not allowed to delegate

from namada.

Note that a validator can have many re-delegations, any slashes to this validator has to iterate all of these when being processed

Wait, why? Can we at least reduce this to iterations proportional to validator pairs (of redelegations) per epoch?

After that, the bond can be re-delegated, but additionally it has to:

We can queue these calculations and do them when the redelegation completes (at unbonding_len), perhaps? Then we can avoid separate logic for delegations-which-were-once-redelegations.

Validator self-bond naturally cannot be re-delegated as validators are not allowed to delegate

Hmm, is this a special bond or just any bond from the validator's address to itself? The latter we should probably allow to be re-delegated? Not sure I understand the implied distinction here.

from namada.

Note that a validator can have many re-delegations, any slashes to this validator has to iterate all of these when being processed

Wait, why? Can we at least reduce this to iterations proportional to validator pairs (of redelegations) per epoch?

I think we can only reduce it to re-delegations that are not more than pipeline_len + unbonding_len old as that's how long their still liable for original validator's infractions.

After that, the bond can be re-delegated, but additionally it has to:

We can queue these calculations and do them when the redelegation completes (at unbonding_len), perhaps? Then we can avoid separate logic for delegations-which-were-once-redelegations.

Yeah, that sounds good, agree it should make it simpler.

Validator self-bond naturally cannot be re-delegated as validators are not allowed to delegate

Hmm, is this a special bond or just any bond from the validator's address to itself? The latter we should probably allow to be re-delegated? Not sure I understand the implied distinction here.

Self-bond is from validator's addess to itself, but we don't allow validators to delegate to other validators in general.

I think another thing we still need to figure out in more detail are the rewards for re-delegation. With auto-bonding, re-delegation should still receive rewards from original validator up before the pipeline offset, but we're not processing individual bonds when distributing rewards. The original validator's rewards should probably be "transferred" somehow with the re-delegation to the new validator's bond, so we might need to do a bit more for re-delegations on both the old and the new validator's stake until before pipeline.

from namada.

I think we can only reduce it to re-delegations that are not more than pipeline_len + unbonding_len old as that's how long their still liable for original validator's infractions.

But can't we treat all redelegations from A to B in epoch e (A, B, e arbitrary) the same? We shouldn't need to iterate over them separately, no? (if not, why would we?)

I think another thing we still need to figure out in more detail are the rewards for re-delegation. With auto-bonding, re-delegation should still receive rewards from original validator up before the pipeline offset, but we're not processing individual bonds when distributing rewards. The original validator's rewards should probably be "transferred" somehow with the re-delegation to the new validator's bond, so we might need to do a bit more for re-delegations on both the old and the new validator's stake until before pipeline.

We can perform processing once per redelegation at the pipeline offset delay to update the voting power / rewards / bond amount, I think.

from namada.

That all sounds reasonable to me!

from namada.