docs(adr): ADR-007 pause unbonding period during equivocation proposal

[tbruyelle]

Description

Link: #747 #791

---

Author Checklist

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.

I have...

• Included the correct type prefix in the PR title
• Added ! to the type prefix if API or client breaking change
• Targeted the correct branch (see PR Targeting)
• Provided a link to the relevant issue or specification
• Followed the guidelines for building SDK modules
• Included the necessary unit and integration tests
• Added a changelog entry to CHANGELOG.md
• Included comments for documenting Go code
• Updated the relevant documentation or specification
• Reviewed "Files changed" and left comments if necessary
• Confirmed all CI checks have passed

Reviewers Checklist

All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.

I have...

• confirmed the correct type prefix in the PR title
• confirmed ! in the type prefix if API or client breaking change
• confirmed all author checklist items have been addressed
• reviewed state machine logic
• reviewed API design and naming
• reviewed documentation is accurate
• reviewed tests and test coverage

[jtremback]

Thanks!

[mpoke]

Thanks @tbruyelle. I left some comments below. In general, I'm not sure that this proposal solves the main problem: Maintain the correctness of PoS (and the slashing mechanism), while avoiding delays of unbonding operations (e.g., undelegations) on the Hub.

[mpoke]

This may lead to unpausing unbonding operations that occurred after the AfterProposalDeposit hook was called. As a result, those unbondings would no longer wait for the unbonding period on the consumer to elapse.

[tbruyelle]

Good catch, we'll fix that.

[tbruyelle]

Fixed dd353c2

[mpoke]

the related unbonding operations of the related validator must be paused.

This needs to be described more precisely. For example, unbonding operations that are no longer waiting for this particular consumer chain should probably not be put on hold. Also, if the infraction occurred after the unbonding operation was initiated, there is no reason to pause the unbonding.

[tbruyelle]

good points, we'll add them.

[tbruyelle]

For example, unbonding operations that are no longer waiting for this particular consumer chain should probably not be put on hold.

Actually, for this particular case, I wonder how this is possible. Considering the protocol, how an unbonding period can end on a consumer chain before the provider chain ?

Or maybe when the unbonding period is deliberately configured shorter between consumer and provider ?

[tbruyelle]

For

Also, if the infraction occurred after the unbonding operation was initiated,

Fixed dd353c2

[mpoke]

IMO, this is the main argument against this proposal. The main reason for pausing unbonding operations is to enable the consumer chains to have shorter unbonding periods and avoid unbonding operations to be delayed. However, reducing the unbonding period on a consumer chain would impact the trusting period of all light clients of that consumer chain (even clients on other chains). This may lead to light clients expiring, which would be a major disruption for the consumer chain.

[mpoke]

The alternative to this proposal is to enable the provider to verify the evidence of equivocation on consumer chains, i.e., #732.

[jtremback]

@mpoke I'm not sure I follow. Currently (without this PR, or cryptographic verification), we are in a situation where the trusting period should be (consumer unbonding - provider voting period) * ~0.75. With a 20 day consumer unbonding period, that means the trusting period should be about 4-5 days. This is already pretty tough for consumer chains to deal with. If we took the consumer unbonding period down to 14 days like we want to, we'd need a trusting period of 0.

With this PR or cryptographic equivocation, we can go back to the trusting period being consumer unbonding * 0.75, or 10-11 days. So at least in this respect, it seems that this PR or cryptographic verification both mitigate this issue equivalently.

[mpoke]

@jtremback Yeah, that’s indeed confusing. Sorry for that.

There are actually two problems we are trying to address here. First, ensuring the correctness of the slashing mechanism of PoS. Second, avoiding delays in the completion of unbonding operations on the provider (which would affect the user experience). Note that the first is a safety concern, while the second is a liveness concern.

For the first, we MUST make sure that the stake of a validator that double signed on a consumer chain is still locked (on the provider) after an equivocation proposal passes. Thus, the following condition MUST hold consumerTrustingPeriod < consumerUnbondingPeriod - providerVotingPeriod. In addition, we MUST leave time for the double signing to be detected, a SlashPacket to be relayed and an equivocation proposal to be submitted. Let’s denote this extra time period with delta1. Then, consumerTrustingPeriod < consumerUnbondingPeriod - delta1 - providerVotingPeriod.

For the second, the following condition SHOULD hold consumerUnbondingPeriod < providerUnbondingPeriod. In addition, we SHOULD leave time to relay both VSCPackets and VSCMaturedPackets, and to account for potential downtimes of the consumer chain (as it happened on Neutron’s launch). Let’s denote this extra time period with delta2. Then, consumerUnbondingPeriod + delta2 < providerUnbondingPeriod.

From these two inequalities, we get consumerTrustingPeriod < providerUnbondingPeriod - delta2 - delta1 - providerVotingPeriod. For the Hub, providerUnbondingPeriod = 21 days, providerVotingPeriod = 14 days, which means consumerTrustingPeriod < 7 - delta2 - delta1. Best case scenario, delta1 = 1 day and delta2 = 1day, which means consumerTrustingPeriod < 5 days. This trusting period must be used for all light clients of the consumer chain, not only the ones on the provider. This means that the chances of a consumer light client expiring are quite high (which would clearly be a very disruptive event). Also, note that these values for the deltas are very low. For example, the network has ~7 days to detect a light client attack on a Hub client (i.e., delta1 ~ 7 days). Also, as we seen with Neutron, having delta2=1day may lead to delays of unbonding operations.

The only way to deal with this problem, is to get rid of the providerVotingPeriod, i.e., consumerTrustingPeriod < providerUnbondingPeriod - delta2 - delta1. This ADR is one way of doing that. 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.

[shaspitz]

@tbruyelle we now got the two approvals 👍 could you update your fork and then we can merge this PR, thanks

[tbruyelle]

@smarshall-spitzbart done!

I was wondering, shouldn't we change the ADR status before the merge ? Currently it's draft.

[mpoke]

@tbruyelle let's discuss in a separate PR / issue / discussion if we want to go ahead and implement this solution. cc @jtremback