Pause unbondings while equivocation slashing proposal is in voting period

[jtremback]

Problem

Currently, if an equivocation slashing proposal is created after more than one week has passed since the equivocation, it is possible that the validator in question could unbond and get away without being slashed, since the unbonding period is 3 weeks, and the voting period is 3 weeks. For this reason, it might be good to pause unbondings for validators named in an equivocation slashing proposal until the proposal's voting period is over.

NOTE: This will be kind of complicated and janky to implement, and it may be that we would be better off just getting automatic equivocation slashing to work correctly. Just writing it here for future reference.

Solution

With current Cosmos Hub settings, it would be sufficient to simply pause all unbondings for a validator that were started before the proposal was created. This is because new unbondings created after the proposal could not complete before the proposal's voting period ended, because the voting period is shorter than the unbonding period. However, if for some reason the voting period was set to be longer than the unbonding period, this would no longer hold, and it would be necessary to pause unbondings started after the proposal was created.

There is no way to get the governance module to run some code when a proposal is created, so we would need to create an antehandler which recognizes a tx creating an equivocation slashing proposal, validates it, and pauses the unbondings. This is kind of janky, but would work.

The API necessary to pause unbondings was added to Cosmos-SDK as part of the changes that we made to enable replicated security. There are 3 types of unbondings: undelegations, redelegations, and validator self unbondings. To pause unbondings for a specific validator, we would first need to get a list of all undelegations, redelegations and self unbondings for that validator, and then pause them.

To get undelegations, call GetValidatorDelegations. This should be an efficient function that uses an index and does not iterate any records that it does not need to, but we should verify that.

To get redelegations, call GetRedelegationsFromSrcValidator.

I don't remember how to get validator self unbondings right now, but it should also be possible.

Once we have a list of all unbondings for a validator, iterate it, and call PutUnbondingOnHold for each one. This will pause the unbonding and it will no longer be able to complete.

It will then be necessary to unpause the unbondings once the voting period is over. We will need to check periodically in an endblocker to see if the voting period is over. If it is, call UnbondingCanComplete for each unbonding to allow the unbonding to complete.

TODOs

• Labels have been added for issue
• Issue has been added to the ICS project

[tbruyelle]

What about the UnbondingCanComplete invoked when a VCS matured packet is handled by the provider chain (see completeMaturedUnbondingOps function) ? Couldn't it unpause the unbondings while a proposal's voting period is not over ?

This might need an extra check in completeMaturedUnbondingOps: ensure there's no pending slashing proposal for the related validator.

[jtremback]

What about the UnbondingCanComplete invoked when a VCS matured packet is handled by the provider chain (see completeMaturedUnbondingOps function) ? Couldn't it unpause the unbondings while a proposal's voting period is not over ?

This might need an extra check in completeMaturedUnbondingOps: ensure there's no pending slashing proposal for the related validator.

That's a really interesting point- we have to think through how this interacts with the existing use of the API. At first glance, I think it's not a problem. Unbondings are actually paused with a counter. So if it's paused twice it needs to be unpaused twice. But this definitely needs to be thought through

[tbruyelle]

@jtremback Don't you think this pause should be triggered on proposal activation rather than on proposal creation ?

Because if it's on proposal creation, I fear that some malicious people could pause the validator unbondings almost indefinitively, by submitting the same equivocation proposal consecutively.

[jtremback]

@jtremback Don't you think this pause should be triggered on proposal activation rather than on proposal creation ?

Because if it's on proposal creation, I fear that some malicious people could pause the validator unbondings almost indefinitively, by submitting the same equivocation proposal consecutively.

Well, you can't make the equivocation proposal at all unless a consumer chain claims the validator has equivocated. So for this to be an avenue of attack, you would also need a consumer chain to forge slash packets. Of course since this is the attack that we are trying to prevent, we can't count on it not being possible.

We could do a lot better to keep track of the slash packets. Right now we just check that there has been one at all. We could enhance this so that it needs to have been in the last unbodnign period

[tbruyelle]

Indeed, there's probably enough safeguard for now.

Anyway, the pause on proposal creation is coded right now, but it's trivial to change it for proposal activation. Now we're working on removing the pause when the voting period (or deposit period) is over.

[tbruyelle]

@jtremback I just realized that the answer to my question is actually in the issue title :

Pause unbondings while equivocation slashing proposal is in voting period

This excludes pause during the deposit period, so the pause should be triggered when the voting period starts, not when the proposal is created. Can you confirm ?

[jtremback]

That's a really good question. I will have to think about it.

[tbruyelle]

@jtremback The PR is now opened, we can continue the discussion inside it.

[tbruyelle]

@jtremback @mpoke @albttx @giunatale The ADR #964 has been merged, but it's still in the draft status.

@mpoke raised important points that were added to the ADR (dd353c2) and must be fixed in the implementation #791 :

• unbonding operations that are no longer waiting for this particular consumer chain should not be put on hold
• unbonding operations that occurred after the AfterProposalDeposit hook was called should not be put on hold

Before we rebase and add those points, I think we should first continue the discussions, and we'll work on that only if the ADR is finally accepted.

I think the blocking point is mainly related to that part #964 (comment).

[jtremback]

@tbruyelle I've thought of another possible issue with this approach. Maybe you can tell me if it sounds like a problem. It seems to me that an attacker could keep a validator's unbondings paused continually by submitting and resubmitting this type of proposal. Of course, this could only happen if that validator had already been slashed unfairly by a malicious consumer chain, and it would cost the attacker the deposit.

Additionally, we are getting closer to having actual cryptographic verification of equivocation evidence, so I'm not sure how much we should pursue this. But again, thanks very much for your work, it is very good.

[giunatale]

From what I understand, #964 (comment) concludes that this ADR is a possible approach to be followed at least until #732 is done.

The downside is that the suggested approach effectively increases the consumerUnbondingPeriod (when an equivocation proposal is submitted), which means that a malicious consumer can break liveness (i.e., delay unbondings). Given that such an event would result in that consumer being removed (via a ConsumerRemovalProposal), I think the risks are minimal. So, we could go ahead with this proposal for now until #732 is done.

With this in mind, what is effectively holding back this ADR from being implemented?

[giunatale]

@tbruyelle I've thought of another possible issue with this approach. Maybe you can tell me if it sounds like a problem. It seems to me that an attacker could keep a validator's unbondings paused continually by submitting and resubmitting this type of proposal. Of course, this could only happen if that validator had already been slashed unfairly by a malicious consumer chain, and it would cost the attacker the deposit.

Additionally, we are getting closer to having actual cryptographic verification of equivocation evidence, so I'm not sure how much we should pursue this. But again, thanks very much for your work, it is very good.

I didn't see this when I wrote my reply, I believe I was on an old browser tab that was not refreshed. Apologies.
To reply to your comment (I'll let also @tbruyelle chime in to correct me potentially) the attack vector you are describing could be avoided by either having a set timeframe after the time of the equivocation for a proposal to be submitted (thus it will eventually expire preventing another proposal re-submission), or limit the number of submissions that can be made wrt to a specific equivocation to a given number (e.g. just 1). Am I missing something here?

With that said, if the cryptographic verification is really close to completion, maybe you are right, this might be not worth pursuing. It really depends - IMHO - what it means "close to completion".

[tbruyelle]

@jtremback the problem you're talking about was one of our first concerns, so yes we still believe this can be a real issue, even with the need of having a slash log in the provider chain or with the need of initial deposit. I think @giunatale has raised good points to mitigate that, but that will require more work and add more complexity.

Cryptographic equivocation looks like a better solution, but unfortunately it's not complete for now (handles only light client attack and can't slash).

[mpoke]

Closing as no longer relevant since #1340 was merged.