Bridge-Risiken: Validatoren, Multisig und Replay-Angriffe

2026-08-12

Eine Bridge bewegt nichts. Sie stellt auf einer Kette eine Behauptung auf und bringt eine zweite Kette dazu, danach zu handeln, und jeder Bridge-Hack ist diese zweite Kette, die einer Behauptung geglaubt hat, die sie hätte ablehnen müssen. Deshalb sortiert man Bridge-Risiken sinnvoll nach Vertrauensannahme statt nach Produktnamen: Was glaubt die Zielkette, und was wäre nötig, damit sie etwas Falsches glaubt. Dieser Artikel geht fünf strukturelle Quellen durch, von externen Validatoren-Sets bis zu den Upgrade-Schlüsseln.

Die Frage, die jede Bridge sortiert

Ethereums eigene Entwicklerdokumentation dampft Bridge-Sicherheit auf eine Frage ein: Wer verifiziert das System? Gebühren, Geschwindigkeit und die Zahl der angebundenen Ketten liegen alle stromabwärts davon.

Die Mechanik variiert kaum. Auf der Quellkette passiert etwas. Irgendeine Partei bezeugt, dass es passiert ist. Ein Vertrag auf der Zielkette prüft dieses Zeugnis gegen eine Regel und gibt frei oder prägt, wenn es besteht. Alles, was ein Angreifer will, liegt auf der anderen Seite dieser Regel.

Die Dokumentation teilt die Bauweisen in zwei Familien. Vertrauensbasierte Bridges werden extern verifiziert: von einer Föderation mit Multisig, einem System für Mehrparteienberechnung oder einem Orakelnetzwerk. Vertrauensminimierte Bridges stützen sich auf die verbundenen Ketten und deren eigene Validatoren und fügen keine neue Annahme hinzu. Die erste Familie kauft Konnektivität und Tempo und zahlt mit Sicherheit: Eine Bridge, die von externen Validatoren gesichert wird, ist meist schwächer als eine, die nativ von den Ketten selbst gesichert wird.

Die Summen machen diesen Tausch unbarmherzig. Bis August 2022 zählte Chainalysis 13 separate Cross-Chain-Bridge-Hacks über rund 2 Milliarden US-Dollar, etwa 69% von allem, was in jenem Jahr bis dahin in Krypto gestohlen wurde. Bridges ziehen Angriffe an, weil sie Sicherheiten genau an der Stelle bündeln, an der eine einzige Regel geprüft wird.

Deshalb sind die folgenden Abschnitte nach Annahmen geordnet und nicht nach Vorfällen. Zwei Bridges mit verschiedenen Namen und demselben Verifikationsmodell scheitern gleich, und die Namen zu kennen sagt nichts über die eine, die du gleich benutzt.

Ein externes Validatoren-Set ist ein System, das du nicht geprüft hast

Die häufigste vertrauensbasierte Bauweise setzt ein Set aus N Parteien zwischen die Ketten. Sie beobachten die Quellkette, signieren ein Zeugnis darüber, dass ein Ereignis eingetreten ist, und der Vertrag auf der Zielkette akzeptiert es, wenn mindestens M dieser Signaturen verifizieren. Eine andere Meinung über die Wirklichkeit hat der Vertrag nicht.

Die Folge ist unverblümt: Wer M Schlüssel kontrolliert, kann prägen. Nimm ein Set aus 9 Parteien mit einem Schwellenwert von 5. Ein Angreifer mit 5 Schlüsseln braucht keinen Vertragsfehler, keine Schwäche in einer der beiden Ketten und keine weitere Prüfung. Während er die Bridge leert, tut sie genau das, wofür sie gebaut wurde.

Achte darauf, welche Sicherheit du tatsächlich kaufst. Das Validatoren-Set ist ein eigenes System mit eigenen Betreibern, Maschinen und Anreizen, und es erbt nichts von den Ketten, die es verbindet. Eine Bridge, die von einem externen Set verifiziert wird, ist so stark wie dieses Set und keinen Deut stärker, wie groß die Netzwerke zu beiden Seiten auch sein mögen.

Die lohnenden Fragen sind also Fragen zur Besetzung. Wer sind die N, und sind sie überhaupt offengelegt? Sind es getrennte Organisationen oder eine Organisation mit neun Maschinen? Wie hoch ist M? Haben die Mitglieder etwas im Einsatz, das ihnen genommen werden kann, wenn sie eine falsche Nachricht signieren? Und wer darf die Besetzung ändern, denn ein Set, das ein einziger Schlüssel umschreiben kann, ist eine Ein-Schlüssel-Bridge im Kostüm eines Komitees.

Ein Schwellenwert zählt nur, wenn die Schlüssel unabhängig ausfallen

M-of-N ist eine Aussage über Unabhängigkeit, keine Rechenaufgabe. Fünf von neun ist nur dann spürbar schwerer als eins von eins, wenn diese neun Schlüssel auf neun unzusammenhängende Arten ausfallen können.

Oft können sie das nicht. Schlüssel innerhalb einer Firma teilen einen Einstellungsprozess, ein Laptop-Image, ein VPN, einen Cloud-Schlüsseldienst und eine Signieroberfläche. Wenn eine einzige Phishing-Nachricht alle neun Inhaber erreicht oder ein Cloud-Konto fünf davon hält, ist N eine Zahl auf einem Dashboard und das echte N liegt näher bei 1.

Den Schwellenwert anzuheben repariert das nicht, und es kostet etwas. Bei hohem M lässt der Verlust weniger Schlüssel die Bridge gar nicht mehr signieren: Gestohlen wird nichts, bewegt sich aber auch nichts, und wer Assets auf der falschen Seite hat, wartet. Jeder Schwellenwert ist eine Wahl zwischen zu leicht zu stehlen und zu leicht einzufrieren.

Die Signierfläche verdient so viel Aufmerksamkeit wie die Verwahrung. Signierende geben Daten frei, die sie meist nicht lesen können; zeigt die Oberfläche also eine freundliche Zusammenschau, während die Bytes darunter etwas anderes sagen, erzeugen ehrliche Signierende eine gültige bösartige Signatur. Blindes Signieren macht aus einem M-of-N-Komitee einen M-of-N-Stempel, und kein Schwellenwert schützt davor.

Light-Clients und optimistische Prüfung wetten auf Verschiedenes

Die vertrauensminimierten Bauweisen entfernen das externe Set, aber sie entfernen kein Vertrauen, sie verlagern es. Zwei Familien machen die Hauptarbeit.

Die Prüfung per Light-Client setzt einen Client der Quellkette in die Zielkette hinein. Die Zielkette speichert den Konsenszustand der Quellkette und prüft, ob ein behauptetes Ereignis dagegen bewiesen ist. In IBC nutzt jede Seite einer Verbindung den Light-Client der anderen Kette, um eingehende Nachrichten zu prüfen, sodass sich die Annahme auf den Konsens der Quellkette plus die Korrektheit des Client-Codes reduziert. Die neuere IBC-Version sagt es ausdrücklich: Ein Client ist schlicht ein Verifikationsmodell und kann ebenso gut ein Light-Client, ein Multisig oder ein Beweisprüfer sein. Nicht die Bezeichnung ist die Annahme, sondern der Client-Typ.

Die optimistische Prüfung geht den umgekehrten Weg: Nimm die Nachricht vorläufig an und gib jedem ein Fenster, in dem er sie als falsch beweisen kann. Die Annahme lautet, dass mindestens ein Beobachter läuft, finanziert ist und eine Einspruchstransaktion vor Ablauf des Fensters unterbringt. Ein Beobachter, der für die Dauer des Fensters offline, ohne Gas oder zensiert ist, ist dasselbe wie gar kein Beobachter.

Keine der beiden Familien ist gratis, und die Kosten sind strukturell, nicht zufällig. Light-Clients kosten Gas und Entwicklungsarbeit für jedes Kettenpaar, und ein Fehler im Client ist ein Fehler in der Regel selbst. Optimistische Bauweisen verbinden billig, zwingen aber jeden ehrlichen Nutzer, eine vom Entwickler gewählte Verzögerung auszusitzen. Ethereums Dokumentation benennt beide Kosten direkt: Konnektivitätsgrenzen bei Light-Client-Bridges, Tempo bei optimistischen.

Replay ist eine gültige Nachricht, doppelt gezählt

Eine Bridge-Nachricht ist eine Autorisierung. Replay ist der Angriff, bei dem eine tatsächlich erteilte Autorisierung erneut vorgelegt wird: ein zweites Mal an derselben Stelle oder ein erstes Mal dort, wo sie nie gelten sollte. Nichts wird gefälscht. Dieselben gültigen Bytes werden schlicht wiederverwendet.

Die kanonische Lösung steckt in Ethereums eigener Geschichte. EIP-155 faltet die Chain ID in die Daten, die gehasht und signiert werden, sodass eine für eine Kette erzeugte Signatur auf einer anderen nicht verifiziert. Beachte, wie es eingeführt wurde: Das ältere Format mit sechs Elementen blieb gültig, dieser Schutz ist also etwas, wofür sich der Signierende entscheidet, und nichts, was das Format garantiert.

Für die strukturierten Nachrichten, die Bridges tatsächlich herumreichen, definiert EIP-712 einen Domain-Separator. Er kann einen Namen, eine Version, die Chain ID und die Adresse des prüfenden Vertrags tragen, dazu ein Salt als Trenner der letzten Instanz, und er hält fest, dass eine Wallet die Signatur verweigern sollte, wenn die Chain ID nicht zu der Kette passt, auf der der Nutzer gerade ist. Andere Kette, anderer Vertrag, andere Version, andere Nachricht. Genau das heißt Domain-Trennung in der Praxis: das Ziel in das hineinzulegen, was signiert wurde.

Die Domain-Trennung verhindert immer noch nicht, dass dieselbe Nachricht zweimal an dasselbe Ziel geliefert wird. EIP-712 sagt das selbst: Der Standard deckt das Signieren ab und enthält keinen Replay-Schutz, also müssen Anwendungen die Wiederholung ablehnen oder die autorisierte Aktion idempotent machen. Diese Arbeit gehört einer Nonce, einer Sequenznummer oder einem Verzeichnis bereits verbrauchter Nachrichten.

IBC zeigt das fertig zusammengesetzte Muster. Zustellung genau einmal ist eine erklärte Eigenschaft des Protokolls: Jedes Paket trägt eine Sequenznummer, die empfangende Kette schreibt unter dieser Nummer eine Quittung, und ein Paket, dessen Quittung schon existiert, wird abgewiesen. Die Spezifikation merkt an, dass dies dasselbe Sequenznummernproblem ist wie bei signierten Nachrichten, nur mit dem Light-Client in der Rolle des Signierenden. Prüfung ohne Entdopplung ist eine halbe Bridge.

Bridge-Risiken nach Vertrauensannahme sortiert: externe Validatoren-Sets, Multisig-Schwellenwerte, Light-Client und optimistische Prüfung, Nachrichten-Replay und Upgrade-Schlüssel

Upgrade-Schlüssel stehen über jeder anderen Annahme

Alles bisher beschreibt die Regel, die eine Bridge heute durchsetzt. Der Upgrade-Schlüssel entscheidet, wer diese Regel morgen ersetzen darf.

Die meisten Bridge-Verträge sind Proxys, und ERC-1967 standardisiert, wo ein Proxy seine Verdrahtung ablegt: ein Speicherslot für die Implementierungsadresse, an die er delegiert, ein weiterer für die Admin-Adresse, die diese Implementierung ändern darf. Eine Transaktion des Admins richtet den Proxy auf neuen Code, und neuer Code darf Gültigkeit definieren, wie er will.

Damit ist der Upgrade-Schlüssel eine Obermenge jedes anderen Risikos auf dieser Seite. Ein Validatoren-Set aus neun Schlüsseln, ein Light-Client, ein Einspruchsfenster: All das kann ersetzen, wer den Admin-Slot kontrolliert. Die ehrliche Obergrenze der Sicherheit einer Bridge ist das Schwächere von Verifikationsmodell und Upgrade-Pfad.

Der Trost ist, dass sich ausgerechnet das prüfen lässt. Der Standard sagt dir, wo du hinschauen musst, und verlangt, dass Änderungen an diesen Slots Events auslösen: Upgraded bei einer neuen Implementierung, AdminChanged bei einem neuen Admin. Lies den Admin-Slot. Sieh nach, ob dort ein einzelnes externes Konto steht, ein Multisig oder ein Timelock, und falls Timelock, wie lang die Verzögerung läuft und wer abbrechen darf.

Pausen und Parameteränderungen verdienen dieselbe Lektüre. Die Macht, eine Bridge anzuhalten oder ein Transferlimit anzuheben, ist kleiner als die Macht, die Regeln neu zu schreiben, aber es ist trotzdem ein Schlüssel in jemandes Hand, und eine Bridge, die pausiert werden kann, kann pausiert werden, während dein Transfer auf halber Strecke ist.

Fazit

Bridge-Risiko sortiert sich sauber, sobald du fragst, wer verifiziert. Ein externes Validatoren-Set ist ein eigenes System, dessen Schwellenwert sein Sicherheitsbudget ist, und dieser Schwellenwert hält nur, wenn die Schlüssel dahinter unabhängig ausfallen können. Light-Clients verschieben die Annahme auf den Konsens der Quellkette und die Korrektheit des Client-Codes; optimistische Bauweisen darauf, dass mindestens ein Beobachter das ganze Fenster über lebt und ungehindert bleibt. Replay-Schutz ist eine getrennte Anforderung: Das Ziel muss Teil des Signierten sein, und jede Nachricht braucht eine Sequenz oder eine Quittung. Über allem steht der Upgrade-Schlüssel, der den Rest in einer Transaktion ersetzt. Diese fünf Antworten, und nicht die Marke auf der Oberfläche, sind das, worauf du vertraust.

Haftungsausschluss: Dieser Artikel ist Bildungsinhalt der Bitbase Academy, nur zu Informationszwecken. Er ist keine Anlage-, Handels-, Steuer- oder Finanzberatung. Krypto-Assets sind volatil — schätze dein Risiko selbst ein. Stand August 2026; maßgeblich sind die aktuellen offiziellen Informationen.