From cd177a84586a65fe21ab0e4b809bccec53232985 Mon Sep 17 00:00:00 2001 From: Simon Noetzlin Date: Wed, 14 Jun 2023 14:27:33 +0200 Subject: [PATCH 1/3] save first gist --- ...cryptographic-equivocation-verification.md | 50 ++++++++++++++++++- 1 file changed, 49 insertions(+), 1 deletion(-) diff --git a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md index 2f10da79e1..dd628bdc29 100644 --- a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md +++ b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md @@ -25,7 +25,55 @@ Current limitations: - This only handles light client attacks, not double signing. In the future, we will add the code to also verify double signing. - Since a special endpoint must be used to submit the evidence, the evidence is not automatically submitted by Hermes. In the future, we may make Hermes submit the evidence, or use a hook provided by IBC to run the code automatically when evidence is submitted to the IBC client. In the current state, someone will need to submit the evidence manually in the 3 weeks after a light client attack has occured. -- We currently can't derive an infraction height from the evidence, so it is only possible to tombstone validators, not actually slash them. +- We currently can't derive an infraction height from the evidence, so it is only possible to tombstone validators, not actually slash them. +In order to introduce the technical reasons of this limitation let's recall the fondation of the CCV slashing feature (now disabled under the untrusted consumer chain) to translate an infraction height from consumer to provider. + +From the CCV protocol foundation each validator set -updates? active on a provider chain will be reflected on its consumer chains. +When an attack occured on a consumer chain its current active validator set should be slashed on the provider chain. +On the provider, each validator set get asssigned an VSCID which is then mapped to a block height and stored. +This mapping allows to translate between provider and consumer under which validator set an event(unbonding/slashing) occured. + +Under the untrusted consumer chain narrative, ICS misbehaviour handling is sued over the VSCID sent from a consumer chain can be fraudulent and can't be used to slashing tokens. +Therefore + + +An attack that occured on a consumer chain securized under a validator set with ID vscid1 must be reported + + + let's recall that the infraction height is required by the slashing mechanism in order take in account the unbonding delegations +which occured after the infraction height on the consumer. The first naive approach is to use the valset available on the IBC misbehaviour header. This valset +can be mapped through a VSC ID and then map to a block height on the provider. However, a limitation stem to the fact that validator set are not unique and may be the same along different block height. +This solution can end up in a situation where V at VSCID1 determine the infraction height but a prior valset V' within the unbonding period would be slashed and the so the undelegations unfairly. + + + + - What is needed to slash according to consumer initiated slashing + - why we need it unbondings + - VSCID mapping + - give spec link + + - Introduce IBC Misbehaviour data + - Valset, TS ... + + - 1st approach naive approach using valset + - valset hash -> VSCID mapping - why we thought it was easy + - how to do it + - limitations n how it can be aribitraly broken or played + + - 2nd approach using timestamp + - tought experiemnt + - result in most basic attack + - limitations n how it can be aribitraly broken or played + + Conlclusion + potential directions + + + + + + + ## Consequences From 8282a1f27fdc464894dad0450e08d7fbf3a0de3f Mon Sep 17 00:00:00 2001 From: Simon Noetzlin Date: Thu, 15 Jun 2023 15:22:45 +0200 Subject: [PATCH 2/3] add first draft --- ...cryptographic-equivocation-verification.md | 49 +------------------ 1 file changed, 1 insertion(+), 48 deletions(-) diff --git a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md index dd628bdc29..870bf5c547 100644 --- a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md +++ b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md @@ -25,54 +25,7 @@ Current limitations: - This only handles light client attacks, not double signing. In the future, we will add the code to also verify double signing. - Since a special endpoint must be used to submit the evidence, the evidence is not automatically submitted by Hermes. In the future, we may make Hermes submit the evidence, or use a hook provided by IBC to run the code automatically when evidence is submitted to the IBC client. In the current state, someone will need to submit the evidence manually in the 3 weeks after a light client attack has occured. -- We currently can't derive an infraction height from the evidence, so it is only possible to tombstone validators, not actually slash them. -In order to introduce the technical reasons of this limitation let's recall the fondation of the CCV slashing feature (now disabled under the untrusted consumer chain) to translate an infraction height from consumer to provider. - -From the CCV protocol foundation each validator set -updates? active on a provider chain will be reflected on its consumer chains. -When an attack occured on a consumer chain its current active validator set should be slashed on the provider chain. -On the provider, each validator set get asssigned an VSCID which is then mapped to a block height and stored. -This mapping allows to translate between provider and consumer under which validator set an event(unbonding/slashing) occured. - -Under the untrusted consumer chain narrative, ICS misbehaviour handling is sued over the VSCID sent from a consumer chain can be fraudulent and can't be used to slashing tokens. -Therefore - - -An attack that occured on a consumer chain securized under a validator set with ID vscid1 must be reported - - - let's recall that the infraction height is required by the slashing mechanism in order take in account the unbonding delegations -which occured after the infraction height on the consumer. The first naive approach is to use the valset available on the IBC misbehaviour header. This valset -can be mapped through a VSC ID and then map to a block height on the provider. However, a limitation stem to the fact that validator set are not unique and may be the same along different block height. -This solution can end up in a situation where V at VSCID1 determine the infraction height but a prior valset V' within the unbonding period would be slashed and the so the undelegations unfairly. - - - - - What is needed to slash according to consumer initiated slashing - - why we need it unbondings - - VSCID mapping - - give spec link - - - Introduce IBC Misbehaviour data - - Valset, TS ... - - - 1st approach naive approach using valset - - valset hash -> VSCID mapping - why we thought it was easy - - how to do it - - limitations n how it can be aribitraly broken or played - - - 2nd approach using timestamp - - tought experiemnt - - result in most basic attack - - limitations n how it can be aribitraly broken or played - - Conlclusion - potential directions - - - - - - +- We currently can't derive an infraction height from the evidence, so it is only possible to tombstone validators, not actually slash them. To explain the technical reasons behind this limitation, let's recap the initial consumer initiated slashing logic. In the previous implementation, Validator Set Update IDs (VSCIDs) were used to derive the infraction height from evidences. Each VSCID was mapped to a block height and stored on both the provider and consumer chains. When an infraction occurred on a consumer chain, a IBC slashing packet was sent to the provider chain along with a VSCID obtained from mapping the evidence's infraction height. Upon receiving the packet, the provider could derive its own local infraction height to execute the slashing. In the context of untrusted consumer chains, all their states, including VSCIDs, could be corrupted and therefore cannot be used for slashing purposes. To address this, we explored a solution using the IBC misbehavior type, which includes the validator set active during the light client attack.By mapping each validator set hash to a block height, the provider would be able to derive an infraction height from an evidence again. However, this solution fails to consider that non-consecutive blocks can have the exact same validator set. In this scenario the validator set hashes would be identical for different unique block height making the mapping obsolete. ## Consequences From 189038fd1d588af383a0a87620d235c189aa8092 Mon Sep 17 00:00:00 2001 From: Simon Noetzlin Date: Fri, 16 Jun 2023 14:09:38 +0200 Subject: [PATCH 3/3] Update docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md Co-authored-by: Marius Poke --- .../adr-005-cryptographic-equivocation-verification.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md index 870bf5c547..80bf093777 100644 --- a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md +++ b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md @@ -25,7 +25,12 @@ Current limitations: - This only handles light client attacks, not double signing. In the future, we will add the code to also verify double signing. - Since a special endpoint must be used to submit the evidence, the evidence is not automatically submitted by Hermes. In the future, we may make Hermes submit the evidence, or use a hook provided by IBC to run the code automatically when evidence is submitted to the IBC client. In the current state, someone will need to submit the evidence manually in the 3 weeks after a light client attack has occured. -- We currently can't derive an infraction height from the evidence, so it is only possible to tombstone validators, not actually slash them. To explain the technical reasons behind this limitation, let's recap the initial consumer initiated slashing logic. In the previous implementation, Validator Set Update IDs (VSCIDs) were used to derive the infraction height from evidences. Each VSCID was mapped to a block height and stored on both the provider and consumer chains. When an infraction occurred on a consumer chain, a IBC slashing packet was sent to the provider chain along with a VSCID obtained from mapping the evidence's infraction height. Upon receiving the packet, the provider could derive its own local infraction height to execute the slashing. In the context of untrusted consumer chains, all their states, including VSCIDs, could be corrupted and therefore cannot be used for slashing purposes. To address this, we explored a solution using the IBC misbehavior type, which includes the validator set active during the light client attack.By mapping each validator set hash to a block height, the provider would be able to derive an infraction height from an evidence again. However, this solution fails to consider that non-consecutive blocks can have the exact same validator set. In this scenario the validator set hashes would be identical for different unique block height making the mapping obsolete. +- We cannot derive an infraction height from the evidence, so it is only possible to tombstone validators, not actually slash them. + To explain the technical reasons behind this limitation, let's recap the initial [consumer initiated slashing logic](https://github.com/cosmos/ibc/blob/2aa283d4bc8b747cbb860c0f94389d7a62bb802b/spec/app/ics-028-cross-chain-validation/overview_and_basic_concepts.md#consumer-initiated-slashing). + In a nutshell, consumer heights are mapped to provider heights through `VSCPackets`, namely through the so called `vscIDs`. + When an infraction occurs on the consumer, a `SlashPacket` containing the `vscID` obtained from mapping the consumer infraction height is sent to the provider. + Upon receiving the packet, the provider maps the consumer infraction height to a local infraction height, which is used to slash the misbehaving validator. + In the context of untrusted consumer chains, all their states, including `vscIDs`, could be corrupted and therefore cannot be used for slashing purposes. ## Consequences