docs: update ADR-005 on cryptographic equivocation verifcation

docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md

@@ -25,7 +25,8 @@ 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. 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