feat: pause unbondings during equivocation proposal voting period #791

tbruyelle · 2023-03-17T16:45:04Z

Description

The change registers 2 gov module hooks in the provider module:

AfterProposalDeposit: if the proposal is an equivocation proposal in voting period, then call PutUnbondingOnHold for each unbondings of each validators found in the proposal.
AfterProposalVotingPeriodEnded: if the proposal is an equivocation proposal, then call UnbondingCanComplete for each unbondings of each validators found in the proposal.

A new key is also added, to store the equivocation proposal ID for which unbondings have been put on hold. This covers 2 specific cases:

The gov module allows additional deposits even if the proposal is already in voting period. So when AfterProposalDeposit is invoked, we have to make sure the proposal is in voting period for the first time before puting the unbondings on hold. This is simply handled by checking if the proposal ID exists in the store at the beginning of the hook, and then storing it if not.
If the provider chain is upgraded with this change and there's already an equivocation proposal in voting period, AfterProposalVotingPeriodEnded could be invoked without the initial AfterProposalDeposit, so some unbondings could be un-paused while they hadn't been paused (conflicts with AfterUnbondingInitiated hook). To prevent that, we check the proposal ID exists in the store, which means AfterProposalDeposit has been called prevouisly.

Linked issues

Closes: #747

Type of change

If you've checked more than one of the first three boxes, consider splitting this PR into multiple PRs!

Feature: Changes and/or adds code behavior, irrelevant to bug fixes
Fix: Changes and/or adds code behavior, specifically to fix a bug
Refactor: Changes existing code style, naming, structure, etc.
Testing: Adds testing
Docs: Adds documentation

Regression tests

If Refactor, describe the new or existing tests that verify no behavior was changed or added where refactors were introduced.

New behavior tests

If Feature or Fix, describe the new or existing tests that verify the new behavior is correct and expected.

A new e2e test have been added in tests/e2e/proposal.go.

Versioning Implications

This PR will affect semantic versioning as defined for ICS

If the above box is checked, which version should be bumped?

MAJOR: Consensus breaking changes to both the provider and consumers(s), including updates/breaking changes to IBC communication between provider and consumer(s)
MINOR: Consensus breaking changes which affect either only the provider or only the consumer(s)
PATCH: Non consensus breaking changes

Targeting

Please select one of the following:

This PR is only relevant to main
This PR is relevant to main, and should also be back-ported to ____ (ex: v1.0.0 and v1.1.0)
This PR is only relevant to ____ (ex: v1.0.0, v1.1.0, and v1.2.0)

Fix cosmos#747 The change registers 2 gov module hooks in the provider module: - `AfterProposalDeposit`: if the proposal is an equivocation proposal in voting period, then call `PutUnbondingOnHold` for each unbondings of each validators found in the proposal. - `AfterProposalVotingPeriodEnded`: if the proposal is an equivocation proposal, then call `UnbondingCanComplete` for each unbondings of each validators found in the proposal. A new key is also added, to store the equivocation proposal ID for which unbondings have been put on hold. This covers 2 specific cases: - The gov module allows additional deposits even if the proposal is already in voting period. So when `AfterProposalDeposit` is invoked, we have to make sure the proposal is in voting period for the first time before puting the unbondings on hold. This is simply handled by checking if the proposal ID exists in the store at the beginning of the hook, and then storing it if not. - If the provider chain is upgraded with this change and there's already an equivocation proposal in voting period, `AfterProposalVotingPeriodEnded` could be invoked without the initial `AfterProposalDeposit`, so some unbondings could be un-paused while they hadn't been paused (conflicts with `AfterUnbondingInitiated` hook). To prevent that, we check the proposal ID exists in the store, which means `AfterProposalDeposit` has been called prevouisly. Co-authored-by: Albert Le Batteux <contact@albttx.tech>

tbruyelle · 2023-03-17T16:50:18Z

app/provider/app.go

@@ -376,7 +376,7 @@ func New(
 		stakingtypes.NewMultiStakingHooks(
 			app.DistrKeeper.Hooks(),
 			app.SlashingKeeper.Hooks(),
-			app.ProviderKeeper.Hooks(),
+			app.ProviderKeeper.Hooks(app.GovKeeper),


As far as I can tell this is not very conventional, but on the other hand, adding the govKeeper to the providerKeeper is even more ugly, because the govKeeper needs the providerKeeper for the proposal routes. So we would have to write something like (pseudo code):

providerKeeper := providerKeeper.NewKeeper( ... govKeeper ...) // govKeeper is nil for now govKeeper := govKeeper.NewKeeper( ... providerKeeper ... ) providerKeeper.SetGovKeeper( govKeeper ) // finally set a non-nil govKeeper

I'm not against the current design per say, but imo adding a govKeeper pointer ref to providerKeeper, while using SetGovKeeper is the easiest to understand. No need to add a parameter for govKeeper in providerKeeper.NewKeeper(). You could just auto set govKeeper to nil, until it is explicitly set after the constructor

I see one benefit of having an additional parameter in Hooks(): it breaks compilation after upgrade. Typically when gaia will upgrade its interchain-security dependency, the fix will be obvious, while on the other hand, having to call SetGovKeeper can be easily forgotten.
Is there any validation we could setup to ensure SetGovKeeper is actually called ? A little bit like keeper.mustValidateField but for setters.

jtremback · 2023-03-17T23:05:43Z

Thanks! Will review this soon.

shaspitz

Awesome work

shaspitz · 2023-03-21T22:04:16Z

app/provider/app.go

@@ -376,7 +376,7 @@ func New(
 		stakingtypes.NewMultiStakingHooks(
 			app.DistrKeeper.Hooks(),
 			app.SlashingKeeper.Hooks(),
-			app.ProviderKeeper.Hooks(),
+			app.ProviderKeeper.Hooks(app.GovKeeper),


I'm not against the current design per say, but imo adding a govKeeper pointer ref to providerKeeper, while using SetGovKeeper is the easiest to understand. No need to add a parameter for govKeeper in providerKeeper.NewKeeper(). You could just auto set govKeeper to nil, until it is explicitly set after the constructor

shaspitz · 2023-03-21T22:34:52Z

tests/e2e/proposal.go

+			// activate prop
+			addDepositProp(s, proposalID, minDepositAmt)
+			checkStakingUnbondingOnHoldRefCount(s, valAddr, tt.expectedDuringProp)
+			// assert that an additionnal deposit done after the activation doesn't


Is it worth a quick check here to validate the voting period has not been reset?

How can that happen ? I see no message in the gov module that could reset the voting period.

tests/e2e/proposal.go

faddat · 2023-04-30T17:34:30Z

Do you guys figure that this one is complete? I think it might solve one of the test cases in the 47 work that we have been doing

mpoke · 2023-05-03T10:34:08Z

Converting to draft as this feature requires an analysis on the potential risks. @tbruyelle @jtremback it would be useful to create an ADR to be able to discuss on it.

tbruyelle · 2023-05-10T09:05:41Z

Converting to draft as this feature requires an analysis on the potential risks. @tbruyelle @jtremback it would be useful to create an ADR to be able to discuss on it.

OK, we'll work on an ADR with @albttx and @giunatale.

tbruyelle · 2023-05-16T15:16:00Z

Converting to draft as this feature requires an analysis on the potential risks. @tbruyelle @jtremback it would be useful to create an ADR to be able to discuss on it.

ADR ready for review #964

mpoke · 2023-11-30T21:09:16Z

@tbruyelle Closing this as the equivocation proposal was removed by the cryptographic verification of equivocation feature #1340.

witaliy12 · 2024-12-13T04:16:27Z

x/ccv/provider/keeper/relay_test.go

@@ -567,7 +567,7 @@ func TestHandleVSCMaturedPacket(t *testing.T) {

 	// Start first unbonding without any consumers registered
 	var unbondingOpId uint64 = 1
-	err := pk.Hooks().AfterUnbondingInitiated(ctx, unbondingOpId)
+	err := pk.Hooks(mocks.MockGovKeeper).AfterUnbondingInitiated(ctx, unbondingOpId)
 	require.NoError(t, err)
 	// Check that no unbonding op was stored
 	_, found := pk.GetUnbondingOp(ctx, unbondingOpId)


cosmos10d07y265gmmuvt4z0w9aw880jnsr700j6zn9kn

tbruyelle requested review from jtremback, mpoke, sainoe, shaspitz, MSalopek, mmulji-ic, glnro and yaruwangway as code owners March 17, 2023 16:45

tbruyelle commented Mar 17, 2023

View reviewed changes

shaspitz reviewed Mar 21, 2023

View reviewed changes

replace waitFor with existing incrementTime

6df4b95

mpoke marked this pull request as draft May 3, 2023 10:31

tbruyelle mentioned this pull request May 16, 2023

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

Merged

18 tasks

tbruyelle mentioned this pull request Jun 13, 2023

Pause unbondings while equivocation slashing proposal is in voting period #747

Closed

2 tasks

mpoke closed this Nov 30, 2023

witaliy12 reviewed Dec 13, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: pause unbondings during equivocation proposal voting period #791

feat: pause unbondings during equivocation proposal voting period #791

tbruyelle commented Mar 17, 2023

tbruyelle Mar 17, 2023

shaspitz Mar 21, 2023

tbruyelle Mar 22, 2023

jtremback commented Mar 17, 2023

shaspitz left a comment

shaspitz Mar 21, 2023

shaspitz Mar 21, 2023

tbruyelle Mar 22, 2023

faddat commented Apr 30, 2023

mpoke commented May 3, 2023

tbruyelle commented May 10, 2023 •

edited

Loading

tbruyelle commented May 16, 2023

mpoke commented Nov 30, 2023

witaliy12 Dec 13, 2024

feat: pause unbondings during equivocation proposal voting period #791

feat: pause unbondings during equivocation proposal voting period #791

Conversation

tbruyelle commented Mar 17, 2023

Description

Linked issues

Type of change

Regression tests

New behavior tests

Versioning Implications

Targeting

tbruyelle Mar 17, 2023

Choose a reason for hiding this comment

shaspitz Mar 21, 2023

Choose a reason for hiding this comment

tbruyelle Mar 22, 2023

Choose a reason for hiding this comment

jtremback commented Mar 17, 2023

shaspitz left a comment

Choose a reason for hiding this comment

shaspitz Mar 21, 2023

Choose a reason for hiding this comment

shaspitz Mar 21, 2023

Choose a reason for hiding this comment

tbruyelle Mar 22, 2023

Choose a reason for hiding this comment

faddat commented Apr 30, 2023

mpoke commented May 3, 2023

tbruyelle commented May 10, 2023 • edited Loading

tbruyelle commented May 16, 2023

mpoke commented Nov 30, 2023

witaliy12 Dec 13, 2024

Choose a reason for hiding this comment

tbruyelle commented May 10, 2023 •

edited

Loading