From c89b59784f8349ffe54913943b3cb15661896d7e Mon Sep 17 00:00:00 2001
From: 0xOZ <52073989+0x0OZ@users.noreply.github.com>
Date: Sun, 28 Apr 2024 22:24:26 +0300
Subject: [PATCH] Update
 public/content/developers/docs/consensus-mechanisms/poa/index.md

Co-authored-by: Paul Wackerow <54227730+wackerow@users.noreply.github.com>
---
 .../content/developers/docs/consensus-mechanisms/poa/index.md   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/public/content/developers/docs/consensus-mechanisms/poa/index.md b/public/content/developers/docs/consensus-mechanisms/poa/index.md
index d43f59f2bdd..32d4b7d52cd 100644
--- a/public/content/developers/docs/consensus-mechanisms/poa/index.md
+++ b/public/content/developers/docs/consensus-mechanisms/poa/index.md
@@ -36,7 +36,7 @@ It may happen that a malicious user gets added to the list of signers, or that a
 
 Another interesting attack vector is if a signer (or group of signers) attempts to censor blocks that vote on removing them from the authorization list. To work around this, the allowed minting frequency of signers is restricted to 1 out of N/2. This ensures that malicious signers need to control at least 51% of signing accounts, at which point they would effectively become the new source-of-truth for the chain.
 
-### Spamming signers {#spamming-signers}
+### Spam {#spam-attack}
 
 Another small attack vector is malicious signers injecting new vote proposals inside every block they mint. Since nodes need to tally up all votes to create the actual list of authorized signers, they need to track all votes through time. Without placing a limit on the vote window, this could grow slowly, yet unbounded. The solution is to place a _moving_ window of W blocks after which votes are considered stale. _A reasonable window might be 1-2 epochs._