Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: update ICS misbehaviour to work with all IBC client implementations #1128

Closed
wants to merge 33 commits into from

Conversation

sainoe
Copy link
Contributor

@sainoe sainoe commented Jul 11, 2023

Description

Closes: #1125


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 state-machine breaking change (i.e., requires coordinated upgrade)
  • Confirmed this PR does not introduce changes requiring state migrations, OR migration code has been added to consumer and/or provider modules
  • 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 this PR does not introduce changes requiring state migrations, OR confirmed migration code has been added to consumer and/or provider modules
  • 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

@sainoe sainoe changed the base branch from feat/upgrade-e2e-testing to feat/ics-misbehaviour-handling July 12, 2023 09:12
@sainoe sainoe requested a review from a team as a code owner July 12, 2023 09:12
@sainoe sainoe changed the base branch from feat/ics-misbehaviour-handling to sainoe/ics-equivocation-handling July 17, 2023 06:51
@sainoe sainoe changed the base branch from sainoe/ics-equivocation-handling to sainoe/ics-misbehaviour-handling July 17, 2023 06:51
@sainoe sainoe changed the base branch from sainoe/ics-misbehaviour-handling to feat/ics-misbehaviour-handling July 17, 2023 06:52
Comment on lines +29 to +30
// Assign the Tendermint client misbehaviour concrete type
tmMisbehaviour := misbehaviour.(*ibctmtypes.Misbehaviour)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we should have an explicit check here for non-tendermint misbehaviour. I know it's already done above but it is hidden.

// HandleConsumerMisbehaviour checks whether the given IBC misbehaviour is valid and, if they are, the misbehaving
// CheckConsumerMisbehaviour check that the given IBC misbehaviour headers forms a valid light client attack evidence.
// proceed to the jailing and tombstoning of the bzyantine validators.
func (k Keeper) HandleConsumerMisbehaviour(ctx sdk.Context, misbehaviour exported.Misbehaviour) error {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we want to make this generic, this should be moved to a new tendermint/misbehaviour.go since this is tendermint specific. Also a few other functions in this file.

@mpoke mpoke linked an issue Jul 24, 2023 that may be closed by this pull request
Copy link
Contributor

@p-offtermatt p-offtermatt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the work! I left a few comments.
I think none are really pressing, so I'm approving.

For the failing checks:
The failure in the markdown check seems unrelated to the content of the PR as far as I can tell.
For the code quality failure, the uncovered code is boilerplate and client/cli which is exhibited by the e2e tests, so it seems unproblematic.

Thanks again, great work!

@@ -28,7 +28,7 @@ RUN go mod tidy
RUN make install

# Get Hermes build
FROM ghcr.io/informalsystems/hermes:1.4.1 AS hermes-builder
FROM otacrew/hermes-ics:latest AS hermes-builder
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you add a comment here why we need ICS from that repo instead of from the informal systems one?


// stepsCauseConsumerMisbehaviour forks a consumer chain in order to cause a ICS misbehaviour.
// The malicious validator behind the attack gets jailed and the consumer client freezed on the provider.
func stepsCauseConsumerMisbehaviour(consumerName string) []Step {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it make sense to call this something like stepsForkConsumerChain instead?
stepsCauseConsumerMisbehaviour seems more broad and less informative, since there could be other types of consumer misbehaviour than a fork, right?

},
{
// start a consumer chain using a single big validator knowing that it holds more than 2/3 of the voting power
// and that the other validators hold less than 5% so they won't get jailed thanks to the sof opt-out mechanism.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// and that the other validators hold less than 5% so they won't get jailed thanks to the sof opt-out mechanism.
// and that the other validators hold less than 5% so they won't get jailed thanks to the soft opt-out mechanism.

chainA: chainID(consumerName),
chainB: chainID("provi"),
connectionA: 0,
portA: "consumer", // TODO: check port mapping
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This TODO should probably be addressed

func (k Keeper) HandleConsumerMisbehaviour(ctx sdk.Context, misbehaviour exported.Misbehaviour) error {
logger := ctx.Logger()

// Check that the validity of the misbehaviour
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// Check that the validity of the misbehaviour
// Check the validity of the misbehaviour

// convert consumer consensus address
consuAddr := sdk.ConsAddress(v.Address.Bytes())
provAddr := k.GetProviderAddrFromConsumerAddr(ctx, tmMisbehaviour.Header1.Header.ChainID, types.NewConsumerConsAddress(consuAddr))
k.stakingKeeper.ValidatorByConsAddr(ctx, consuAddr)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this line doing anything? The return value is not used, might be worth commenting explicitly if this has some expected side effects

ConflictingBlock: conflicted,
}

if ev.ConflictingHeaderIsInvalid(trusted.Header) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

my understanding is that regardless of the outcome of this function,
the height, timestamp and totalvotingpower come from trusted -
either they are taken directly from the trusted block, or they are the same in both anyways.

Is this if/else even needed? If yes, could you clarify in a comment?

)

// TestHandleConsumerMisbehaviour verifies first that ICS misbehaviour is handled
// only if its conlflicting headers are valid. Then, it checks
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// only if its conlflicting headers are valid. Then, it checks
// only if its conflicting headers are valid. Then, it checks

cs, ok := s.providerApp.GetIBCKeeper().ClientKeeper.GetClientState(s.providerCtx(), s.path.EndpointB.ClientID)
s.Require().True(ok)

if tc.expPass {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could it make sense to check for error types to avoid failing due to unexpected errors?
From a quick look at the code, it doesn't seem the actual errors are produced in the misbehavior code,
so this might be too annoying to do, but if it's easy, it might be worth it.


// TestMsgSubmitConsumerClientHandler tests that the provider
// handler can parse MsgSubmitConsumerMisbehaviour
// TODO: move this to x/provider/handler_test.go
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The TODO should probably be addressed - is there something blocking this?


flags.AddTxFlagsToCmd(cmd)

_ = cmd.MarkFlagRequired(flags.FlagFrom)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why not just cmd.MarkFlagRequired(flags.FlagFrom)

@mpoke mpoke marked this pull request as draft September 7, 2023 14:44
@sainoe sainoe closed this Nov 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Update ICS misbehaviour msg definition
4 participants