From 3039ad61824447a7fe5c139a7d8667eeae2e749e Mon Sep 17 00:00:00 2001 From: Simon Noetzlin Date: Thu, 3 Aug 2023 09:58:58 +0200 Subject: [PATCH] Update docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md Co-authored-by: Marius Poke --- .../adrs/adr-005-cryptographic-equivocation-verification.md | 2 +- 1 file changed, 1 insertion(+), 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 2912dc8fd0..4f96bb8419 100644 --- a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md +++ b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md @@ -35,7 +35,7 @@ A light client attack occurs when a Byzantine validator sends invalid headers to As the light client doesn't execute transactions, it can be deceived into trusting corrupted application state transitions. For instance, if a light client receives header `A` from the primary and header `B` from a witness for the same block height `H`, and both headers are successfully verified, it indicates a light client attack. -Note that it this case, either the primary and/or witness nodes are malicious. +Note that in this case, either the primary or the witness or both are malicious. To orchestrate a light client attack, Byzantine actors create a header with incorrect state transitions that must be signed by ⅓+ of the voting power. The types of light client attacks are defined by analyzing the differences between the conflicting headers.