-
Notifications
You must be signed in to change notification settings - Fork 136
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
EPIC: Cryptographic verification of equivocation #732
Comments
Summarizing our last discussion with @mpoke, we can separate the work into two main concerns:
|
About 2.
What we have currently is a mapping that uses the valset update id. On the provider chain, this id maps a block height. If we decide to use it, that means the equivocation evidence message must contain the valset id, so the provider can determine the height, and then determine the voting power at this height. My concern is how do we verify that valset id passed in the message is correct ? I don't think we can use IBC client for that. Maybe instead the message should contain the entire valset, instead of just the ID. At least the entire valset can be verified if I'm not wrong. But then the message is harder to create for the user. |
Had a discussion with @sainoe regarding the light client evidence handling. I think it is fairly complex, the code as is in tendermint cannot really be used. You will also need some implementation that monitors chains and submits three light blocks (the conflicting block si not enough, you need common and trusted) as part of the new type of evidence. This doesn't exist.
Wondering if we should consider this now as it looks like it's harder to do all the earlier phase work instead of this. For duplicate vote I think we still need a trigger from the consumer chain evidence module, Then not sure why we cannot use that for both light client attacks and conflicting votes. Not sure though this is along the lines of "used automatically for packets coming from a consumer chain." And I may be missing something fundamental. |
Or we do not trust that consumer chain validators run the proper tendemint protocols, for example they may drop the evidence or duplicate votes? |
I would suggest to update the links to the CometBFT repository. The code should be the same, but the Tendermint Core (old) repository is now obsolete. |
Problem
We would like the provider chain to be able to verify equivocation evidence on its own, instead of trusting consumers, or needing evidence to go through governance. For this, we can look at the code in Tendermint which does this, but it will need heavy changes.
Problem details
To keep things simple at first, we should design this code to be used by an accuser who would like to cause an equivocating validator to be slashed by submitting a message to the chain containing all necessary evidence. Later, we can adapt this to be used automatically for packets coming from a consumer chain.
Fortunately, almost all the code used by Tendermint to verify equivocation evidence is in one file: https://github.com/cometbft/cometbft/blob/main/evidence/verify.go. A lot of this code should be possible to reuse, however, it depends on state stored by Tendermint nodes, most of which will not be available on the provider chain.
There are two basic types of equivocation: Double signing and light client attacks.
Double signing
This is trivial, you can see the function that does it here. The only complicated thing is that it requires the validator set and powers at the height of the evidence. But we should be able to store these on the provider. Also, the evidence will have the height of the consumer which will need to be mapped to the height of the provider to get the validator powers at that height. But I think we already have code to do that.
Light client attacks
This is much more complicated, and it requires more state. The additional state that is required is the true header of the block in question, known as the "trustedHeader" or the "commonHeader". In Tendermint, this is loaded from the node's state. On the provider chain, we will not be able to access this. Instead, it should be possible to have the accuser supply the trusted header along with the rest of the evidence. The provider chain can then use the record of validator powers from that block to check that the trusted header is real.
Task list
Must have
feat/ics-misbehaviour-handling
branch to SDK v47 #1302Nice to have
The text was updated successfully, but these errors were encountered: