RFC-0097: lack of specification in the rebonding scenario

[Moliholy]

Introduction

The RFC-0097 for the unbonding queue defines the implementation that will allow stakers to unbond their tokens in potentially shorter periods of time while maintaining a sufficient amount available for slashing. It exhaustively defines the process that should be triggered when a user wishes to unbond, but it apparently has a non-covered use case that I define below:

Rebonding

When rebonding, part of the stake that is in the ledger's unbonding queue is removed from that queue, and hence it is no longer scheduled for release, but available to nominate again. However, although the RFC briefly specifies that the back of the unbonding queue should be updated by subtracting the old era delta, it does not specify how existing stakers can get their unbonding eras updated with a potentially lower value.

Potential exploitation

An attacker bonds sufficient amount of tokens so that, if an unbonding operation would be performed, it'd increase the back of the unbonding queue by at least one era. This way, the attacker could increase by at least one era the unbonding time of all participants. At some point before the attacker's unbonding queue is about to expire, the funds could be rebonded and unbonded again to renew the artificial delay. In the worst case, the attacker would have sufficient balance to delay the queue up to the maximum value.

[Moliholy]

A solution for this issue is to increase the granularity of the time-measurement units. Pico-eras were proposed for this, always rounding up to the nearest pico-era. An in-depth explanation with concrete calculations has been discussed in the implementation.