-
Notifications
You must be signed in to change notification settings - Fork 122
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
Conversation
implement msg handling logic e2e test msg handling logic
8e48493
to
865e43b
Compare
// Assign the Tendermint client misbehaviour concrete type | ||
tmMisbehaviour := misbehaviour.(*ibctmtypes.Misbehaviour) |
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
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.
There was a problem hiding this 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 |
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// 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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// 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) |
There was a problem hiding this comment.
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) { |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// 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 { |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
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)
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...
!
to the type prefix if state-machine breaking change (i.e., requires coordinated upgrade)CHANGELOG.md
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...
!
in the type prefix if API or client breaking change