Spam Protection and Sybil Resistance for Comments and Discussions in Governance

[mfornos]

Description

The current model in comments and discussions assumes that participants use a Polkadot public-private key pair to sign messages. However, this approach may not be robust enough due to the ease of generating multiple key pairs, allowing a spammer to create numerous accounts and overwhelm the system with spam messages.

While posting remarks directly on-chain incurs costs (e.g., transaction fees and content hosting such as running IPFS/Helia), which could act as a deterrent, using the implementor’s services for posting remarks may open the system to spam abuse without proper safeguards.

Security Considerations

• Weakness of Public-Private Key Pair Assumption: Simply having a Polkadot key pair is insufficient for spam protection, as it's trivial to create multiple keys for Sybil attacks.

• Increasing Sybil Resistance: One potential approach to mitigate this is to mandate a positive balance check on the account before allowing signed comments. Accounts with no or insufficient balances could be restricted from participating in discussions, adding a cost to Sybil attacks.

• Spam Mitigation: In the proposed system, it is up to the implementor to limit the number of signed messages from a single account, even when the system includes some mechanism for Sybil resistance. This could be done via rate-limiting or other approaches.

• Cost of Posting: It is important to note that the costs of posting messages on-chain are borne by the implementor. Therefore, it is in the implementor's interest to introduce additional checks and measures to prevent spam, as unchecked spam can lead to increased costs and system degradation.

Potential Countermeasures

1. Require Positive Balance for Participation: Enforce a positive balance check on accounts signing data to increase the cost for Sybil attackers.
2. Rate Limiting and Quotas: Limit the number of messages an account can post in a given time period to further deter spam. Since the multi-writer logic is sequenced on-chain all the implementors should know the current messages from an account.
3. Delegating Responsibility to Implementors: Ensure implementors have mechanisms in place to detect and prevent excessive or malicious activity from the same account or set of accounts.

By considering these mechanisms, the system can better guard against spam while distributing the responsibility between the network and the implementors.