Warum Cross-Chain-Bridges immer wieder leergeräumt werden (und ob du überhaupt eine brauchst)

Cross-Chain-Bridges sind das lukrativste Ziel in Crypto. Allein 2022 haben Bridge-Exploits rund 2 Milliarden Dollar abgezogen, etwa 69 % aller in dem Jahr aus DeFi gestohlenen Mittel, und die kumulierte Summe über alle gemeldeten Bridge-Vorfälle liegt mittlerweile deutlich über 2,5 Milliarden Dollar. Die ehrliche Zusammenfassung: Bridges werden wegen ihrer Vertrauensannahmen leergeräumt, nicht nur wegen schlechtem Code. Eine Bridge muss eine Chain davon überzeugen, dass auf einer anderen Chain etwas passiert ist, die sie nicht sehen kann. Was auch immer du beauftragst, diese Behauptung aufzustellen, Validatoren, ein Multisig, ein Komitee von Signern, ist genau das, was ein Angreifer angeht. Dieser Post beginnt mit der Entscheidung, die die meisten Teams überspringen: Brauchst du überhaupt eine Bridge, und welches Vertrauensmodell versagt wie.

Wie werden Cross-Chain-Bridges tatsächlich leergeräumt?

Eine Bridge tut eine schwierige Sache: Sie bringt Chain B dazu, zu glauben, dass auf Chain A ein Deposit passiert ist. Chain B hat keinen nativen Weg, Chain A zu verifizieren, also schiebt die Bridge eine Autorität dazwischen, die das bezeugt. Diese Autorität ist die Angriffsfläche. Räumst du eine Bridge leer, machst du fast immer eines von drei Dingen: Du stiehlst die Keys, die Withdrawals autorisieren, du trickst die Verifizierungslogik dazu, eine Nachricht zu akzeptieren, die nie gültig war, oder du nutzt die Ökonomie eines Liquidity-Pools aus, der die Funds vorstreckt. Die Beträge sind enorm, weil eine Bridge den gelockten Wert von allem, was je über sie gelaufen ist, in einem Contract konzentriert. Es gibt keinen Schaden pro Nutzer. Es gibt einen Honeypot.

Dieses Framing ist wichtig, weil es dir sagt, wo du hinschauen musst. Der Smart-Contract-Code kann makellos sein, und die Bridge wird trotzdem leergeräumt, wenn die Off-Chain-Signer kompromittiert sind (Ronin). Die Signer können ehrlich sein, und die Bridge wird trotzdem leergeräumt, wenn die On-Chain-Verifizierung ein Loch hat (Wormhole, Nomad). Du sicherst zwei Systeme ab, nicht eines, und die meisten Post-Mortems führen zurück auf das Vertrauensmodell, das das Team am Anfang gewählt hat.

Drei Fehlschläge seziert: Ronin, Wormhole, Nomad, was jeder davon lehrt

Ronin (~625 Mio. $, März 2022). Der größte Bridge-Hack bis heute. Ronin nutzte neun Validatoren und brauchte fünf Signaturen, um eine Withdrawal freizugeben. Der Angreifer erlangte fünf Keys: vier kontrollierte Sky Mavis, ein fünfter kam von einem Axie-DAO-Validator, dessen Zugang früher erteilt und nie widerrufen worden war. Mit fünf von neun waren die Withdrawals nach den eigenen Regeln der Bridge völlig gültig. Der Code tat genau das, was ihm gesagt wurde. Lektion: Ein externes Validator-Set ist nur so sicher wie sein Key-Management und seine Ehrlichkeitsschwelle. Fünf Signer sind keine Dezentralisierung, sie sind ein Single Point of Failure mit fünf Personen. Der Breach blieb sechs Tage unbemerkt, weil niemand das Signer-Set überwachte.

Wormhole (~325 Mio. $, Februar 2022). Ein reiner Verifizierungsfehler. Wormhole verließ sich auf ein Set von Off-Chain-"Guardians", deren Signaturen das Minting auf der Zielchain autorisieren. Der Contract auf der Solana-Seite nutzte eine veraltete Instruction, um zu prüfen, dass Signaturen verifiziert worden waren, aber er validierte nie, dass das Signatur-Verifizierungsprogramm das echte war. Der Angreifer reichte einen gefälschten Account ein, bestand die Prüfung in einem anderen Kontext und mintete 120.000 wETH, ohne dass etwas dahinterstand. Lektion: Die Signer waren ehrlich; der On-Chain-Code, der ihnen vertraute, war nicht sorgfältig. Ein Signaturschema ist nur so gut wie der Contract, der es prüft.

Nomad (~190 Mio. $, August 2022). Eine optimistische Bridge, deren Verifizierung durch ein Routine-Upgrade praktisch abgeschaltet wurde. Nomads Replica-Contract initialisierte seinen Trusted Root auf 0x00, denselben Wert, den eine unbewiesene Nachricht trägt, sodass jede Nachricht mit leerem Proof als bereits bewiesen behandelt wurde. Ein Nutzer schickte 0,01 WBTC und zog 100 heraus. Der Exploit brauchte kein Können: Leute kopierten die funktionierende Transaktion, tauschten ihre eigene Adresse ein und reichten sie erneut ein. Es wurde ein crowdsourced Free-for-all mit hunderten Wallets, die die Bridge in Stunden leerräumten. Lektion: Optimistische und Fraud-Proof-Designs legen das gesamte Sicherheitsmodell in eine Verifizierungsprüfung. Brich diese Prüfung, und es gibt kein Fallback.

Die eigentliche Frage: Brauchst du überhaupt eine Bridge?

Die meisten Teams greifen zu einer Bridge, bevor sie fragen, ob sie eine sollten. Die günstigste Bridge zum Absichern ist die, die du nie baust. Bevor du die Haftung akzeptierst, stell dir drei Fragen:

• Kannst du Single-Chain bleiben? Wenn deine Nutzer und deine Liquidität auf einer Chain leben, fügt eine Bridge eine Angriffsfläche für ein Problem hinzu, das du nicht hast. Wähle die richtige Chain und bleib dort.
• Kannst du eine kanonische / native Bridge nutzen? Die meisten L2s liefern eine offizielle Bridge aus, die das Chain-Team pflegt und die das eigene Proof-System der Chain absichert. Sie ist langsamer und unflexibler als eine Drittanbieter-Bridge, aber du erbst die Sicherheit der Chain, statt deine eigene zu garantieren. Das ist das richtige Default für fast jeden, der Assets zu und von einer L2 bewegt.
• Musst du wirklich Assets bewegen, oder nur Nachrichten? Viele "Wir brauchen eine Bridge"-Anforderungen sind in Wahrheit "Wir müssen State von einer anderen Chain lesen." Das ist ein kleineres, günstigeres Problem als Wert zu locken und zu minten.

Bau eine Custom-Bridge nur, wenn du einen konkreten Grund hast, den die kanonischen und etablierten Drittanbieter-Optionen nicht bedienen können, und nur mit offenen Augen für die Audit- und Betriebskosten. Eine Bridge ist kein Feature, das du ausliefern und vergessen kannst. Sie ist ein Contract, der das Geld aller hält, beobachtet von allen, die einen Anreiz haben, ihn zu brechen.

Bridge-Vertrauensmodelle und wie jedes versagt

Jede Bridge wählt ein Vertrauensmodell. Das Modell entscheidet, wem du vertraust und damit, wie du leergeräumt wirst. Das ist der Vergleich, den du führen solltest, bevor du eine Zeile Code schreibst.

Native / Light-Client-Verifizierung ist am sichersten, weil sie das menschliche Vertrauens-Set vollständig entfernt: Die Zielchain prüft den Konsens-Proof der Source-Chain selbst. Sie ist auch am teuersten zu bauen und zu betreiben, was genau der Grund ist, warum Teams sich ein Multisig einreden und auf dieser Liste landen. Wormholes Fehler saß in der Lücke zwischen einem Signer-Modell und dem Contract, der es verifizierte; siehe unsere Notiz zu Gas-Kosten-Trade-offs über L1 und L2, warum die günstige Option am Ende selten günstig ist.

Eine Pre-Launch-Bridge-Security-Checkliste

Kurz, entscheidungsorientiert und geordnet danach, was dich tatsächlich rettet. Wenn du die ersten drei nicht beantworten kannst, bist du nicht launch-bereit.

1. Benenne dein Vertrauensmodell laut. Schreib genau auf, wer eine Withdrawal autorisieren kann und was es braucht, ihn zu kompromittieren. Wenn die Antwort "fünf Keys" ist, behandle es als Single Point of Failure mit fünf Personen.
2. Auditiere beide Ebenen gemeinsam. On-Chain-Verifizierung und Off-Chain-Signer sind ein System. Wormhole und Nomad waren On-Chain-Bugs; Ronin war Off-Chain. Auditiere die Naht, nicht nur die Contracts.
3. Widerrufe aggressiv. Ronin fiel teils auf eine veraltete Berechtigung, die niemand entfernt hatte. Inventarisiere jeden Key und jeden Grant und lass Zugang per Default ablaufen.
4. Überwache Signer-Set und Balances in Echtzeit. Ronin lief sechs Tage unbemerkt. Du brauchst Alerting auf jede Withdrawal und jede Signer-Änderung, mit einem Menschen auf Abruf.
5. Bau einen Pause- / Circuit-Breaker. Ein Rate-Limit oder eine globale Pause macht aus einem Total-Drain einen eingedämmten Vorfall. Nomad hatte keine Bremse, sobald die erste Transaktion funktionierte.
6. Deckle und rate-limitiere Withdrawals. Der Honeypot ist das Problem. Caps schrumpfen den Preis und kaufen dir Zeit zum Reagieren.
7. Plane den Upgrade-Pfad. Nomads Bug kam in einem Routine-Upgrade. Behandle jedes Bridge-Upgrade als frisches Audit, nicht als Patch.

"Eine Bridge ist ein Contract, der das Geld aller hält, beobachtet von allen, die einen Grund haben, ihn zu brechen. Die günstigste Bridge zum Absichern ist die, die du nie baust."

Q&A: kanonische Bridge oder Drittanbieter-Bridge?

Default zur kanonischen Bridge, wenn du Assets zu und von einer L2 bewegst. Du erbst die eigene Sicherheit und das Proof-System der Chain, statt ein separates Vertrauens-Set zu garantieren. Drittanbieter-Bridges gewinnen bei Geschwindigkeit, bei Chains, die eine kanonische Bridge nicht verbindet, und bei UX-Features, die der offiziellen Bridge fehlen, aber du vertraust jetzt dem Modell dieses Operators zusätzlich zu deinen eigenen Chains. Wähle eine Drittanbieter-Bridge für das, was sie einzigartig liefert, nicht weil sie das erste Ergebnis war.

Q&A: Reicht ein Multisig, um eine Bridge abzusichern?

Ein Multisig ist ein Ausgangspunkt, kein Sicherheitsmodell. Ronin war ein Multisig: fünf von neun, und es verlor 625 Mio. $, weil fünf Keys erreichbar waren. Ein Multisig hilft nur, wenn die Keys wirklich unabhängig sind, gehalten von Parteien, die nicht kolludieren können, mit Hardware-Custody und Widerrufs-Disziplin. In dem Moment, in dem eine Entität ein Quorum kontrolliert, ist das Multisig Theater. Wenn deine Bridge nennenswerten Wert hält, sollte ein Multisig eine Ebene mit Caps, Monitoring und einer Pause dahinter sein, nicht die ganze Verteidigung.

Q&A: Garantieren Audits, dass eine Bridge sicher ist?

Nein. Ein Audit senkt die Wahrscheinlichkeit eines Code-Bugs; es ändert dein Vertrauensmodell nicht. Nomads fatalen Wert führte ein Upgrade nach den Audits ein. Wormhole war auditiert. Ein Audit ist ein Snapshot einer Version einer Ebene. Es kann nicht zertifizieren, dass deine fünf Signer ehrlich bleiben oder dass dein nächstes Upgrade kein Loch wieder einführt. Behandle Audits als notwendig und nicht hinreichend. Siehe unsere Pre-Audit-Security-Checkliste, was du davor und danach tun solltest.

Q&A: Sollte ein Startup seine eigene Bridge bauen?

Fast nie. Die Teams auf der Verlust-Rangliste waren keine unbedarften Amateure; es waren finanzierte Teams mit Audits und Engineers. Eine Bridge konzentriert Risiko, das mit allem skaliert, was über sie läuft, und sie verlangt ab Tag eins 24/7-Monitoring und einen Incident-Response-Plan. Wenn du ein Startup bist, bleib Single-Chain oder nutze eine kanonische Bridge, bis eine Bridge wirklich dein Produkt ist und kein Feature. Wenn sie unvermeidbar ist, scope sie als das risikoreichste, was du ausliefern wirst, und ressourciere sie entsprechend. Siehe unseren Blockchain-Engineering-Service, wie wir das scopen, und das Glossar für die Begriffe oben.