gossip-cache-invariance

Injectable Skill: Gossip Cache Invariance

L1 trigger: P2P flag AND (seen_cache, message_cache, tx_cache, gossipsub, pubsub, dedup, seen_chunks detected) Inject Into: depth-network-surface, depth-consensus-invariant Language: Go and Rust Finding prefix: [GCI-N]

1. Write-After-Validate

For each attacker-controlled cache key, prove the ordering between cache write and integrity/authenticity validation. Cache insertion before validation is a poisoning primitive.

Tag: [GOSSIP-CACHE:ORDER]

2. Duplicate Handling

Check whether duplicate suppression is keyed on canonical content, the right topic/partition, and enough sender identity. Look for cases where legitimate messages are suppressed or malicious messages can be replayed after eviction.

Tag: [GOSSIP-CACHE:DUPLICATES]

3. Eviction Invariants

Under burst traffic or memory pressure:

• what gets evicted first?
• can attacker traffic evict honest messages before processing?
• can eviction reopen a previously rejected malicious message?

Tag: [GOSSIP-CACHE:EVICTION]

4. Cache Key Soundness

Verify the key includes the right tuple of topic / partition / chain / message identity. Flag collisions where distinct messages alias to the same cache key.

Tag: [GOSSIP-CACHE:KEY]

5. Broken Safety Property

State the resulting invariant failure explicitly:

• valid message can be suppressed
• invalid message can block later valid message
• message can be processed repeatedly
• attacker can force honest work without progress

6. Cache-miss amplification

For each receive-and-rebroadcast path:

1. Does the handler consult a seen/validated cache before re-broadcast?
2. Is the cache key canonical, or can the attacker create many distinct IDs for effectively the same payload?
3. If the cache misses, does one inbound message cause fan-out to many peers?

If a cache miss multiplies traffic or work across peers, record it as an amplification finding rather than a simple duplicate-handling bug.