CZ: Block-Explorer sollten Spam-Transaktionen filtern, um das Risiko von Address Poisoning zu reduzieren
CZ: Block-Explorer sollten Spam-Transaktionen filtern, um das Risiko von Address Poisoning zu reduzieren
Address Poisoning (auch Transaktionsverlauf-Vergiftung genannt) hat sich leise zu einer der hartnäckigsten Bedrohungen auf der „UI-Ebene“ über Ethereum und andere EVM-Netzwerke hinweg entwickelt. Angreifer müssen weder Kryptographie brechen noch Smart Contracts ausnutzen; sie nutzen menschliche Gewohnheiten aus – insbesondere die Tendenz, eine Adresse aus dem aktuellen Transaktionsverlauf zu kopieren, nachdem nur die ersten und letzten paar Zeichen überprüft wurden. Eine klare Darstellung, wie diese Betrügereien in der Praxis funktionieren, finden Sie in der Erklärung von Etherscan zu Address-Poisoning-Angriffen. (info.etherscan.com)
Anfang 2026 ist das Ausmaß dieser Kampagnen kaum zu ignorieren. Eine Studie der Carnegie Mellon University CyLab (basierend auf mehrjährigen On-Chain-Daten) dokumentierte Hunderte von Millionen von Vergiftungsversuchen und betonte, dass die Grundursache die Benutzerfreundlichkeit ist: lange hexadezimale Adressen, Kürzungen in Benutzeroberflächen und unsichere Copy-Paste-Verhaltensweisen. (cylab.cmu.edu)
Vor diesem Hintergrund hat CZ kürzlich die Diskussion über eine einfache Idee neu entfacht: ** offensichtliche Spam-Überweisungen von vornherein nicht mehr anzeigen**. Während sich ein Großteil der öffentlichen Diskussion auf Wallet-Apps konzentriert, gilt das gleiche UX-Prinzip für Block-Explorer – denn Explorer sind die Orte, an denen Benutzer, Support-Teams, Analysten und sogar Wallet-UIs häufig den Transaktionsverlauf „lesen“.
Warum Address Poisoning weiterhin funktioniert
Die meisten Address-Poisoning-Angriffe folgen einem wiederholbaren Muster:
- Ein Scammer generiert eine ähnlich aussehende Adresse (die oft mit dem Anfang und Ende der Adresse eines echten Gegenparts übereinstimmt).
- Er sendet eine Staubüberweisung (winziger Betrag, manchmal sogar ein Token-Ereignis, das wie eine Überweisung aussieht), damit der Verlauf des Opfers „verunreinigt“ wird.
- Später kopiert das Opfer die falsche Adresse aus dem Verlauf und sendet eine echte Zahlung an den Angreifer.
Etherscan stellt fest, dass diese Angriffe nicht auf eine einzige Benutzeroberfläche beschränkt sind; sie können auf allen Explorern, Wallets und anderen Web3-Frontends auftreten. (info.etherscan.com)
CZs Punkt: Spam-Filterung ist ein UX-Fix, keine Protokolländerung
CZs Kernargument ist einfach: Wenn eine Benutzeroberfläche ein Vergiftungsmuster (oder eine bekannte Vergiftungsadresse) identifizieren kann, sollte sie warnen oder blockieren – und wenn eine Transaktion im Wesentlichen wertloser Spam ist, sollte sie standardmäßig ausgeblendet werden, um die Wahrscheinlichkeit eines Copy-Paste-Fehlers zu verringern. Berichte, die seine Kommentare diskutieren, heben zwei praktische Richtungen hervor:
- Bekannte Vergiftungsziele erkennen und blockieren (eine „Blockchain-Abfrage“ plus Bedrohungsanalysen)
- Transaktionen mit vernachlässigem Wert in Verlaufsansichten nicht anzeigen (financefeeds.com)
Hier werden Block-Explorer Teil der Lösung: Viele Wallets und Portfolio-Tools verlassen sich auf Explorer-APIs und activity feeds im Explorer-Stil. Wenn Explorer Spam-Überweisungen mit dem gleichen visuellen Gewicht wie echte Zahlungen darstellen, verstärken sie unbeabsichtigt den „UI-Fußabdruck“ des Angreifers.
Block-Explorer haben Spam bereits gefiltert – das ist nicht neu
Die Branche hat bereits „Sichtbarkeitskontrollen“ auf Explorer-Ebene ausprobiert. BlockBeats berichtete beispielsweise zuvor, dass Etherscan seine Standardansicht aktualisiert hat, um wertlose Token-Überweisungen nicht anzuzeigen, als Reaktion auf Vergiftungs-ähnliche Betrügereien, während es Benutzern weiterhin ermöglicht, die Sichtbarkeit in den Einstellungen wieder zu aktivieren. (theblockbeats.info)
Dies ist ein wichtiges Präzedenzfall: Die Filterung auf UI-Ebene ändert nicht die On-Chain-Wahrheit. Sie ändert, was hervorgehoben, was zusammengeklappt und was einen zusätzlichen Klick erfordert – genau die Art von Reibung, die kostspielige Fehler verhindern kann.
Der schwierige Teil: Filtern ohne legitime Anwendungsfälle zu beeinträchtigen
Kritiker aggressiver Filterung äußern oft eine berechtigte Sorge: Was, wenn „kleine Überweisungen“ legitim sind?
In den Jahren 2025–2026 wird diese Frage wichtiger, da sich die Branche in Richtung von Folgendem entwickelt:
- Niedrigere Gebühren und höherer Durchsatz auf L2s und Hochleistungs-Chains
- On-Chain-Automatisierung (Bots, Keeper, Intent-Solver)
- KI-Agenten, die auf Mikrozahlungen oder hochfrequente Abwicklungen angewiesen sein könnten
CZ räumte eine Version dieses Kompromisses ein: Wenn die Zukunft KI-zu-KI-Mikrotransaktionen umfasst, könnte eine pauschale Filterung nur nach Wert echte Aktivitäten verbergen – doch die gleichen KI-Fähigkeiten können auch verwendet werden, um Spam genauer zu klassifizieren, wenn diese Zukunft eintritt (d. h. intelligentere Erkennung statt einfacher Schwellenwerte).
Ein vernünftiger Mittelweg für Explorer ist:
- „Wahrscheinlich Spam“ standardmäßig ausblenden, nicht „niedriger Wert“
- Einen Ein-Klick-Schalter „Ausgeblendete Aktivitäten anzeigen“ bereitstellen
- Erklärbare Labels anbieten (warum etwas ausgeblendet wurde: 0-Wert, gefälschtes Token-Muster, bekannter Vergiftungscluster, hoher Ähnlichkeitswert usw.)
- Eine Ansicht mit rohen Protokollen/Ereignissen für Power-User und Auditoren beibehalten
Dies wahrt die Transparenz, schützt aber die Mehrheit der Benutzer vor dem häufigsten Fehlerfall: dem Kopieren der falschen Adresse aus einem verunreinigten Feed.
Was Explorer und Wallets tun sollten (praktische Checkliste)
1) Standardmäßig aufhören, Adressen in risikoreichen Kontexten zu kürzen
Wenn eine Benutzeroberfläche kürzen muss, sollte sie Tippen zum Erweitern, Unterschiede hervorheben und stabile visuelle Hinweise (Identicons, Namensschilder, Kontakthinweise) unterstützen.
2) „Ähnlichkeitswarnungen“ beim Senden hinzufügen
Der sicherste Zeitpunkt für ein Eingreifen ist vor der Signatur. Wenn das Ziel einer kürzlich verwendeten Adresse sehr ähnlich ist (aber nicht identisch), sollte die Benutzeroberfläche eine bewusste Bestätigung erzwingen.
3) Spam-Sichtbarkeit als Sicherheitseinstellung behandeln
„Verdächtigen Spam ausblenden“ sollte standardmäßig aktiviert sein, mit klaren Steuerelementen zur Überprüfung ausgeblendeter Elemente.
4) Überall Checksummen verwenden, wo möglich
Für Adressen im Ethereum-Stil hilft die EIP-55 Mixed-Case-Checksummenkodierung, Tippfehler zu erkennen und bestimmte Arten von Kopierfehlern zu reduzieren. Sehen Sie sich die ERC-55 (EIP-55) Spezifikation an. (eips-wg.github.io)
5) Ein lokales Adressbuch pflegen (und Whitelists fördern)
Ein gespeicherter Kontakthinweis ist schwerer zu vergiften als „was auch immer zuletzt im Verlauf angezeigt wird“.
Was Benutzer heute tun können, um das Risiko von Address Poisoning zu reduzieren
Auch wenn Explorer und Wallets die Filterung verbessern, sollten Benutzer davon ausgehen, dass Vergiftungsversuche fortgesetzt werden – denn das Senden von Staub ist billig und Angreifer automatisieren im großen Stil. Hier sind Gewohnheiten, die das Risiko erheblich reduzieren:
- Kopieren Sie niemals eine Empfängeradresse aus dem Transaktionsverlauf, es sei denn, Sie verifizieren sie vollständig.
- Senden Sie bei großen Überweisungen zuerst eine kleine Testtransaktion.
- Bevorzugen Sie vertrauenswürdige Adressquellen (Ihr eigenes Adressbuch, verifizierte Gegenparteien, QR-Codes von einem authentifizierten Kanal).
- Vergleichen Sie manuell mehr als die ersten/letzten 4 Zeichen – überprüfen Sie auch das mittlere Segment.
- Verwenden Sie einen Signatur-Workflow, der Sie zwingt, die vollständige Adresse auf einem vertrauenswürdigen Display zu überprüfen.
Dieser letzte Punkt ist es, wo ein Hardware-Wallet das Risikoprofil erheblich verändert.
Wo OneKey in dieses Sicherheitsmodell passt
Address Poisoning ist im Grunde ein Problem der UI-Täuschung, daher ist die robusteste Verteidigung, „was Sie auf einem potenziell kompromittierten Bildschirm sehen“ von „was Sie auf einem vertrauenswürdigen Bildschirm genehmigen“ zu trennen.
Ein Hardware-Wallet wie OneKey hilft dabei, indem es private Schlüssel offline hält und die Transaktionsbestätigung auf dem Gerät verlangt – sodass Sie, wenn Ihr Browser, Ihre dApp oder Ihr Transaktionsverlauf durch Spam-Überweisungen verunreinigt wird, immer noch die Möglichkeit haben, die Empfängeradresse und den Betrag auf dem Hardware-Bildschirm zu überprüfen, bevor Sie signieren.
Wenn Sie häufig mit DeFi interagieren, Stablecoins senden oder operative Wallets verwalten, ist die Kombination aus:
- Explorer/Wallet-basierter Spam-Filterung und
- Hardware-basierter On-Device-Verifizierung
eine der praktischsten Möglichkeiten, Verluste durch Address Poisoning zu reduzieren, ohne die Self-Custody-Vorteile von öffentlichen Blockchains aufzugeben.
Weiterführende Literatur
- Etherscan: What is an address poisoning attack?
- CMU CyLab: Study on blockchain address poisoning at scale (cylab.cmu.edu)
- Ethereum-Standard: ERC-55 (EIP-55) checksum addresses (eips-wg.github.io)
