docs: update cryptographic equivocation verification ADR

[sainoe]

Description

Closes: #1124

---

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 docs: prefix in the PR title
• targeted the correct branch (see PR Targeting)
• provided a link to the relevant issue 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 docs: prefix in the PR title
• Confirmed all author checklist items have been addressed
• Confirmed that this PR only changes documentation
• Reviewed content for consistency
• Reviewed content for spelling and grammar
• Tested instructions (if applicable)
• Checked that the documentation website can be built and deployed successfully (run make build-docs)

[mpoke]

Nice work @sainoe. See my comments bellow.

[shaspitz]

Great writeup!

[shaspitz]

Is it meant to say "increasing" here?

To me it seems like the 2 weeks for the prop to get approved would cause us to make an unbonding period that is longer, long enough for the prop to pass.

Suggested change

Currently, we use a governance proposal to slash validators for equivocation (double signing and light client attacks). This has the downside that it takes 2 weeks for the proposal to be approved, effectively reducing the unbonding period in some respects. This does not lead to any pressing real-world security concerns, but since it involves the basis of proof of stake, it would be good to get consumer chain slashing back to parity as soon as possible.

Currently, we use a governance proposal to slash validators for equivocation (double signing and light client attacks). This has the downside that it takes 2 weeks for the proposal to be approved, effectively increasing the unbonding period in some respects. This does not lead to any pressing real-world security concerns, but since it involves the basis of proof of stake, it would be good to get consumer chain slashing back to parity as soon as possible.

[mpoke]

I updated the entire paragraph

[shaspitz]

Am I understanding things correctly below?

The original IBC misbehavior handling is relevant to evidence submitted to a chain, where the misbehavior happened on that same chain. In ICS we're reusing that code to handle misbehavior evidence on the provider, where the misbehavior happened on a different chain (the consumer).

If my understanding is correct, it might be worth adding a couple sentences explaining how ICS's use of the IBC misbehavior handling is different than how it's conventionally used

[mpoke]

I'll let @sainoe to address this comment.

[sainoe]

@smarshall-spitzbart IBC misbehaviour handling serves as a security mechanism to protect a chain that runs the client of another chain. For instance, let's say that chain A runs a client of chain B. If chain B were to send invalid states to chain A, it becomes necessary that chain A stops trusting the client of chain B. This can be achieved by submitting an IBC misbehavior message to chain A, which will halt the client if successfully executed.

In the context of ICS, we're uniquely reusing the IBC misbehavior message verification methods. The message handling behaviour, however, differs from the IBC implementation as it involves jailing validators and refrains from modifying the client states.

[shaspitz]

Got it, all makes sense 👍, this info is prob worth adding to the ADR imo