Wie Cross-Chain-Brücken funktionieren und warum 4 Milliarden Dollar aus ihnen gestohlen wurden

Einführung

Blockchains kommunizieren nicht miteinander. Ethereum kann den Zustand von Solana nicht lesen. Arbitrum kann eine Transaktion auf Avalanche nicht verifizieren. Jede Kette führt ihr eigenes Ledger, ihren eigenen Konsens und ihre eigenen Finalitätsregeln. Diese Isolation ist ein Merkmal des Sicherheitsdesigns, schafft aber ein praktisches Problem: Benutzer halten Vermögenswerte auf einer Kette und möchten sie auf einer anderen verwenden.

Brücken existieren, um dies zu lösen. Eine Brücke ist ein System, das es einem Benutzer ermöglicht, Vermögenswerte auf Kette A zu hinterlegen und entsprechende Vermögenswerte auf Kette B zu erhalten. Das Konzept klingt einfach. Die Umsetzung ist der Punkt, an dem Milliarden von Dollar verloren gegangen sind.

Die Kernschwierigkeit ist die Verifizierung. Wenn ein Benutzer behauptet, 100 ETH auf Ethereum hinterlegt zu haben, und 100 ETH auf Arbitrum anfordert, muss jemand oder etwas verifizieren, dass die Einzahlung tatsächlich stattgefunden hat. Der für diese Verifizierung gewählte Mechanismus bestimmt das Sicherheitsmodell der Brücke, ihre Geschwindigkeit, ihre Kosten und ihre Angriffsfläche. Wie eine Coinbase-Analyse von Brücken-Hacks feststellte, resultieren Sicherheitsfehler bei Brücken durchweg aus der Diskrepanz zwischen den Vertrauensannahmen, die eine Brücke behauptet, und denen, die sie tatsächlich durchsetzt.

Dieser Leitfaden behandelt, wie die wichtigsten Brückenarchitekturen funktionieren, warum die größten Exploits erfolgreich waren und worauf man achten sollte, bevor man einer Brücke seine Gelder anvertraut.

Lock-and-Mint: der ursprüngliche Brückenmechanismus

Das früheste und häufigste Brückendesign ist Lock-and-Mint. Der Mechanismus funktioniert in drei Schritten:

1. Sperren. Der Benutzer sendet Token an einen Smart Contract auf der Quellkette. Die Token werden in diesem Vertrag gesperrt (gehalten), nicht verbrannt oder übertragen.
2. Verifizieren. Eine Reihe von Validatoren, Relays oder einem Orakel beobachtet die Einzahlung auf der Quellkette und bestätigt deren Gültigkeit auf der Zielkette.
3. Minten. Ein Smart Contract auf der Zielkette mintet eine synthetische Version des gesperrten Tokens. Der Benutzer erhält "verpackte ETH" oder "gebrückte USDC", die einen Anspruch auf das gesperrte Original darstellen.

Um zurückzukehren, kehrt sich der Prozess um: Der Benutzer verbrennt das synthetische Token auf der Zielkette, Validatoren bestätigen die Verbrennung, und die ursprünglichen Token werden auf der Quellkette entsperrt.

Die Sicherheit von Lock-and-Mint hängt vollständig vom Verifizierungsschritt ab. Wenn ein Angreifer die Zielkette davon überzeugen kann, dass eine Einzahlung stattgefunden hat, obwohl sie nicht stattfand, kann er ungedeckte Token minen. Genau das geschah bei den größten Brücken-Exploits.

Das Rechenproblem. Lock-and-Mint-Brücken müssen ein 1:1-Verhältnis zwischen gesperrten Originalen und geminteten Synthetiken aufrechterhalten. Wenn 10.000 ETH auf Ethereum gesperrt sind, sollten auf der Zielkette genau 10.000 gebrückte ETH existieren. Jede Abweichung bedeutet, dass einige gebrückte Token ungedeckt sind. Wenn Exploits ungedeckte Synthetiken erzeugen, finden die letzten Einlöser den Tresor leer. Dies erzeugt eine Bank-Run-Dynamik: Sobald sich die Nachricht von einem Exploit verbreitet, eilen alle Inhaber des verpackten Tokens zur Einlösung, da sie wissen, dass nur die Ersten echte Vermögenswerte erhalten.

Burn-and-Mint: native Cross-Chain-Token

Burn-and-Mint eliminiert das Problem des verpackten Tokens, indem das Original zerstört und ein neues erstellt wird.

1. Verbrennen. Das Token wird auf der Quellkette dauerhaft zerstört.
2. Verifizieren. Das Verbrennungsereignis wird auf der Zielkette verifiziert.
3. Minten. Neue Token werden nativ auf der Zielkette gemintet.

Dieses Modell funktioniert nur für Token, deren Emittenten das Minting auf mehreren Ketten kontrollieren. Circles Cross-Chain Transfer Protocol (CCTP) für USDC ist die größte Implementierung. Wenn ein Benutzer USDC über CCTP von Ethereum zu Avalanche überbrückt, wird das Ethereum-USDC verbrannt und natives USDC auf Avalanche gemintet. Es gibt keine verpackten Token, keine Liquiditätsfragmentierung und keine ungedeckten Synthetiken.

Die Einschränkung besteht darin, dass Burn-and-Mint erfordert, dass der Token-Emittent Infrastruktur auf jeder unterstützten Kette bereitstellt und betreibt. Es ist kein allgemeiner Mechanismus. Beliebige ERC-20-Token können Burn-and-Mint nicht nutzen, es sei denn, ihre Entwickler bauen die Cross-Chain-Minting-Infrastruktur auf. CCTP unterstützt derzeit über ein Dutzend Ketten, aber jede Integration erfordert die direkte Beteiligung von Circle.

Liquiditätspool-Brücken: Geschwindigkeit durch Kapital

Ein drittes Modell vermeidet sowohl das Verpacken als auch das Verbrennen, indem es vorfinanzierte Liquiditätspools auf jeder Kette verwendet.

Der Mechanismus:

1. Einzahlung. Der Benutzer zahlt Token in einen Pool auf der Quellkette ein.
2. Auszahlung. Der Benutzer (oder ein Relayer, der in seinem Namen handelt) hebt äquivalente Token aus einem Pool auf der Zielkette ab.
3. Rebalancing. Das Protokoll gleicht regelmäßig die Pools über Ketten hinweg aus, um eine ausreichende Liquidität aufrechtzuerhalten.

Stargate (auf LayerZero aufgebaut) und Across Protocol verwenden Variationen dieses Modells. Der Vorteil ist die Geschwindigkeit: Da Token bereits auf der Zielkette vorhanden sind, gibt es keine Prägebedingung. Der Benutzer erhält sofort echte, native Token.

Der Nachteil ist die Kapitaleffizienz. Liquidität muss auf jeder unterstützten Kette vorab bereitgestellt werden, und dieses Kapital erzielt nur dann eine Rendite, wenn Brücken aktiv genutzt werden. In Zeiten geringer Volumina verdienen Liquiditätsanbieter wenig, während ihr Kapital ungenutzt bleibt. Der aggregierte Kapitalbedarf über alle unterstützten Ketten kann Hunderte Millionen Dollar erreichen, was eine Eintrittsbarriere und ein Konzentrationsrisiko darstellt, wenn ein einzelner Liquiditätsanbieter dominiert.

Der Ronin-Bridge-Hack: 624 Millionen Dollar durch kompromittierte Schlüssel

Am 23. März 2022 entwendeten Angreifer 624 Millionen Dollar in ETH und USDC aus der Ronin-Bridge, die Ethereum mit der Ronin-Seitenkette verband, die vom Spiel Axie Infinity verwendet wird.

Ronins Brücke verwendete ein Multisig-Validierungsschema. Neun Validatorknoten überprüften Brückentransaktionen, und jede fünf konnten eine Auszahlung autorisieren. Die Sicherheitsannahme war, dass es unpraktikabel wäre, fünf von neun unabhängigen Validatoren zu kompromittieren.

Die Annahme war falsch. Sky Mavis, das Unternehmen hinter Axie Infinity, kontrollierte vier der neun Validatorknoten. Ein fünfter Validator hatte Sky Mavis während einer Phase mit hohem Transaktionsvolumen vorübergehend die Erlaubnis erteilt, in seinem Namen zu signieren, und diese Erlaubnis wurde nie widerrufen.

Die Angreifer (später vom FBI der Lazarus-Gruppe Nordkoreas zugeschrieben) kompromittierten die Systeme von Sky Mavis und erlangten die privaten Schlüssel für alle fünf Validatoren. Mit fünf von neun Signaturen autorisierten sie zwei betrügerische Auszahlungen: 173.600 ETH und 25,5 Millionen USDC.

Der Exploit wurde sechs Tage lang nicht entdeckt. Er kam erst ans Licht, als ein Benutzer versuchte, 5.000 ETH abzuheben und feststellte, dass die Brücke nicht genügend Mittel hatte.

Die Lehre. Multisig-Sicherheit ist nur so stark wie die Unabhängigkeit ihrer Unterzeichner. Wenn eine einzelne Organisation die Mehrheit der Schlüssel kontrolliert, ist das Multisig ein einzelner Fehlerpunkt mit zusätzlichen Schritten.

Der Wormhole-Hack: 326 Millionen Dollar durch eine Verifizierungsumgehung

Am 2. Februar 2022 nutzte ein Angreifer die Wormhole-Brücke aus, um 120.000 wETH (gewickeltes ETH) auf Solana zu prägen, ohne ETH auf Ethereum zu hinterlegen. Der Exploit war ungefähr 326 Millionen Dollar wert.

Wormholes Brücke verließ sich auf eine Gruppe von 19 Wächtern, um kettenübergreifende Nachrichten zu verifizieren. Die Wächter beobachteten eine Einzahlung auf Ethereum, erstellten eine signierte Bestätigung (genannt VAA, Verified Action Approval), und der Solana-seitige Vertrag überprüfte die Signaturen, bevor er prägte.

Die Schwachstelle lag in der Solana-seitigen Signaturverifizierung. Wormholes Solana-Vertrag verwendete eine veraltete Systemanweisung (verify_signatures), die die übergebenen Konten nicht ordnungsgemäß validierte. Der Angreifer erstellte eine gefälschte Wächtergruppe, reichte eine gefälschte VAA mit Signaturen dieser gefälschten Gruppe ein, und der Vertrag akzeptierte sie als gültig.

Im Effekt sagte der Angreifer dem Solana-Vertrag: „Diese Wächter haben diese Prägung genehmigt“, und der Vertrag prüfte nicht, ob die Wächter echt waren.

Jump Crypto, das Wormhole unterstützte, ersetzte die gestohlenen 120.000 ETH aus eigenen Reserven. Die vollständige Wiederherstellung erfolgte innerhalb von 24 Stunden, eine beispiellose Reaktion, die kaskadierende Verluste über Solana-DeFi-Protokolle verhinderte, die wETH hielten.

Die Lehre. Brückenverifizierungscode ist eine Angriffsfläche mit hohem Wert. Ein einzelner Logikfehler bei der Validierung von Signaturen kann unbegrenztes unbefugtes Prägen ermöglichen.

Der Nomad-Hack: 190 Millionen Dollar durch ein fehlerhaftes Update

Am 1. August 2022 wurden der Nomad-Brücke ungefähr 190 Millionen Dollar entzogen. Im Gegensatz zu Ronin und Wormhole wurde Nomad nicht von einer ausgeklügelten Gruppe angegriffen. Es wurde von Hunderten von einzelnen Nachahmern geleert, nachdem der erste Exploit öffentlich wurde.

Nomad verwendete ein optimistisches Verifikationsmodell. Cross-Chain-Nachrichten wurden eingereicht und als gültig angenommen, sofern sie nicht innerhalb eines 30-Minuten-Fensters angefochten wurden. Ein routinemäßiges Vertrags-Upgrade führte einen Fehler ein: Der Vertrag wurde mit einer vertrauenswürdigen Wurzel von 0x00 initialisiert, dem Null-Bytes32-Wert.

In der Verifikationslogik von Nomad wurde jede Nachricht gegen die vertrauenswürdige Wurzel geprüft. Da 0x00 der Standardwert für nicht initialisierten Speicher in Solidity ist, bestand jede Nachricht automatisch die Verifikation. Jeder Benutzer konnte eine beliebige Nachricht einreichen, und der Vertrag akzeptierte sie als bewiesen.

Sobald der erste Angreifer demonstrierte, dass beliebige Nachrichten akzeptiert wurden, kopierten andere die Transaktion, änderten die Empfängeradresse und spielten sie erneut ab. Die Brücke wurde von einem Schwarm opportunistischer Angreifer geleert, darunter auch White-Hat-Hacker, die später etwa 36 Millionen Dollar der wiederhergestellten Gelder zurückgaben.

Die Lehre. Initialisierungsfehler in Brückenverträgen können katastrophal sein. Ein einziger falsch konfigurierter Parameter verwandelte Nomads Sicherheitsmodell von „optimistischer Verifikation mit Betrugsnachweisen" zu „überhaupt keiner Verifikation".

Der Harmony-Horizon-Hack: 100 Millionen Dollar durch eine Zwei-von-Fünf-Multisig

Im Juni 2022 verlor die Harmony-Horizon-Brücke 100 Millionen Dollar, als Angreifer die privaten Schlüssel von zwei der fünf Validatoren in der Multisig der Brücke kompromittierten. Harmonies Brücke erforderte nur zwei von fünf Unterzeichnern, um eine Transaktion zu genehmigen, eine ungewöhnlich niedrige Schwelle für eine Brücke, die 100 Millionen Dollar hält.

Der Angriff verstärkte die Ronin-Lektion: Multisig-Brücken sind nur so sicher wie ihre schwächste Unterzeichnergruppe. Wenn die Schwelle im Verhältnis zur Anzahl der Unterzeichner niedrig ist, kann ein einziger Kompromiss der Infrastruktur ausreichen. Sicherheitsforscher hatten Harmonies Zwei-von-Fünf-Schwelle vor dem Angriff öffentlich kritisiert.

Die Lehre. Die Wahl der Schwelle ist genauso wichtig wie die Anzahl der Validatoren. Eine Fünf-von-Neun-Multisig bietet eine deutlich andere Sicherheit als eine Zwei-von-Fünf-Multisig, auch wenn beide denselben zugrunde liegenden Mechanismus verwenden.

Kumulative Verluste und Angriffsmuster

Das Ausmaß der Brückenverluste ist in der Sicherheit von Smart Contracts beispiellos. Brücken-Exploits machen etwa 3 Milliarden Dollar der insgesamt 17 Milliarden Dollar an Krypto-Hacks im letzten Jahrzehnt aus, was Brücken zur am häufigsten angegriffenen Kategorie von Smart Contracts macht.

Die Angriffsmuster gruppieren sich in drei Kategorien:

Schlüsselkompromittierung. Der Angreifer erhält genügend Validator- oder Unterzeichnerschlüssel, um Brückennachrichten zu fälschen. Ronin und Harmony folgten diesem Muster. Die Schwachstelle liegt nicht im Code, sondern in der operativen Sicherheit der Unterzeichnerinfrastruktur.

Verifikationsumgehung. Der Angreifer findet einen Fehler in der Verifikationslogik, der es ermöglicht, gefälschte Nachrichten durchzulassen. Wormhole folgte diesem Muster. Die Schwachstelle ist ein Fehler auf Codeebene in der kritischsten Funktion des Brückenvertrags.

Initialisierungs- oder Upgrade-Fehler. Der Angreifer nutzt eine Fehlkonfiguration aus, die während der Bereitstellung oder des Upgrades eingeführt wurde. Nomad folgte diesem Muster. Die Schwachstelle ist prozedural: Das Team machte einen Fehler während einer routinemäßigen Operation.

Jedes Muster erfordert eine andere Verteidigung. Schlüsselkompromittierung wird durch erhöhte Vielfalt der Unterzeichner und den Einsatz von Hardware-Sicherheitsmodulen gemildert. Verifikationsumgehung wird durch Audits und formale Verifikation gemildert. Initialisierungsfehler werden durch Upgrade-Verfahren gemildert, die obligatorische Testläufe auf Fork-Netzwerken beinhalten.

Ein viertes aufkommendes Muster verdient Erwähnung: Governance-Angriffe. Ein Angreifer, der genügend Governance-Token ansammelt, um den Upgrade-Mechanismus einer Brücke zu kontrollieren, kann den Brückenvertrag ändern, um Gelder abzuziehen. Dieser Angriff ist langsamer und sichtbarer als die anderen, zielt aber auf Brücken, deren Governance konzentriert ist oder deren Zeitverzögerung bei Upgrades zu kurz ist. Brückenteams verwenden zunehmend mehrtägige Zeitverzögerungen (48 bis 72 Stunden) bei Vertrags-Upgrades, um den Benutzern Zeit zu geben, Gelder abzuheben, bevor eine bösartige Änderung wirksam wird.

Die absichtsbasierte Alternative zu traditionellen Brücken

Ein neuerer Ansatz umgeht Brückenverträge vollständig, indem er absichtsbasierte Cross-Chain-Transfers verwendet. Across Protocol und UniswapX's Cross-Chain-Modus ermöglichen es Benutzern, eine Brückenabsicht auszudrücken: „Ich habe 1.000 USDC auf Ethereum und möchte 1.000 USDC auf Arbitrum." Ein Solver (auch Relayer genannt) sendet sofort Token aus seinem eigenen Bestand auf der Zielkette und fordert später eine Erstattung an.

Dieses Modell reduziert die Vertrauensfläche. Der Benutzer hinterlegt niemals Token in einem Brückenvertrag, der gepoolte Gelder hält. Der Solver übernimmt das Erstattungsrisiko, und der Abwicklungsvertrag stellt sicher, dass der Benutzer die versprochene Ausgabe erhalten hat. Es gibt keinen großen Pool gesperrter Vermögenswerte, den ein Angreifer angreifen könnte.

Der Kompromiss ist die Abhängigkeit vom Solver: Wenn kein Solver bereit ist, die Absicht zu einem akzeptablen Preis zu erfüllen, wird der Transfer nicht ausgeführt. Für stark frequentierte Routen (Ethereum zu Arbitrum, Ethereum zu Base) ist der Wettbewerb unter den Solvern stark. Bei Routen mit geringem Volumen sind Solver möglicherweise nicht aktiv.

Light-Client-Brücken und Zero-Knowledge-Verifizierung

Die oben genannten Exploits haben eine gemeinsame Schwäche: Sie verlassen sich auf externe Validatoren oder Multisigs, um zu bestätigen, dass etwas auf einer anderen Kette passiert ist. Wenn diese Attestoren kompromittiert sind, scheitert die Brücke.

Light-Client-Brücken verfolgen einen anderen Ansatz. Anstatt einer Validatorengruppe zu vertrauen, führt die Zielkette einen Light-Client aus, der den Konsens der Quellkette direkt verifiziert.

Eine Light-Client-Brücke zu Ethereum würde beispielsweise die Validatorengruppe von Ethereum verfolgen und Blockheader und State-Proofs on-chain verifizieren. Wenn ein Benutzer behauptet, Token auf Ethereum hinterlegt zu haben, verifiziert der Brückenvertrag den Merkle-Beweis gegen den bereits validierten Ethereum-Blockheader.

Dieser Ansatz ist vertrauensminimiert: Die Brücke vertraut dem Konsens der Quellkette, nicht einem externen Ausschuss. Aber es ist teuer. Die Verifizierung des Ethereum-Konsenses auf einer anderen Kette erfordert erhebliche Rechenleistung, was sich in hohen Gas-Kosten niederschlägt.

Zero-Knowledge-Beweise bieten eine Lösung für das Kostenproblem. Anstatt jede Validatorsignatur on-chain zu verifizieren, kann ein ZK-Beweis die Verifizierung in einen einzigen prägnanten Beweis komprimieren. Die Zielkette verifiziert einen Beweis anstelle von Hunderten von Signaturen.

Projekte wie Succinct Labs, Polymer und Lagrange bauen ZK-verifizierte Brücken. Diese sind noch in der Entwicklung, aber sie repräsentieren das stärkste Sicherheitsmodell für die Cross-Chain-Kommunikation: Vertraue der Mathematik, nicht dem Ausschuss. Erste Implementierungen zeigen sinkende Verifizierungskosten, da ZK-Beweissysteme effizienter werden, wobei einige Brücken bereits im Mainnet mit Beweiszeiten unter 30 Sekunden arbeiten.

Was dies nicht abdeckt

Dieser Leitfaden erklärt die Mechanik von Brücken und die größten Exploits. Er deckt nicht ab:

• Tokenspezifische Brückenstrategien oder welche Brücke für einen bestimmten Vermögenswert verwendet werden soll
• Detaillierter Vergleich von Brückenaggregatoren (Li.Fi, Socket, Bungee)
• Die Ökonomie der Liquiditätsbereitstellung für Brückenpools
• Cross-Chain-Messaging-Protokolle über ihre Brückenfunktion hinaus (LayerZero, Axelar, Chainlink CCIP als allgemeine Messaging-Ebenen)

Praktische Checks vor der Nutzung einer Brücke

Überprüfen Sie den Verifizierungsmechanismus. Multisig-Brücken sind das schwächste Modell. Light-Client- und ZK-verifizierte Brücken sind die stärksten. Optimistische Brücken liegen dazwischen. Wissen Sie, wem Sie vertrauen.

Schauen Sie sich die Validator- oder Guardian-Gruppe an. Bei Multisig-Brücken prüfen Sie, wie viele Unterzeichner es gibt, wer sie betreibt und ob sie wirklich unabhängig sind. Wenn die Mehrheit der Unterzeichner derselben Organisation oder geografischen Gerichtsbarkeit angehört, bietet die Multisig nur begrenzte Sicherheit.

Überprüfen Sie die Audit-Historie. Brückenverträge sind Ziele mit hohem Wert. Suchen Sie nach mehreren unabhängigen Audits von seriösen Firmen. Eine Brücke, die nicht auditiert wurde oder nur einmal auditiert wurde, erfordert besondere Vorsicht. Achten Sie auf den Umfang der Audits: Ein Audit des Token-Vertrags deckt nicht die Verifizierungslogik ab.

Berücksichtigen Sie den Total Value Locked im Vergleich zum Sicherheitsbudget. Eine Brücke, die 500 Millionen Dollar mit einer Fünf-von-Neun-Multisig hält, weist ein sehr anderes Risikoprofil auf als eine Brücke, die 5 Millionen Dollar hält. Angreifer zielen auf Brücken ab, bei denen die potenzielle Auszahlung den Aufwand rechtfertigt. Der rationale Angreifer berechnet, ob die Kosten für die Kompromittierung genügend Schlüssel geringer sind als der Wert, der extrahiert werden kann.

Testen Sie zuerst mit kleinen Beträgen. Bevor Sie größere Werte überbrücken, senden Sie eine kleine Testtransaktion. Stellen Sie sicher, dass die Empfängeradresse, der Token und der Betrag korrekt sind. Brückentransaktionen sind in der Regel unumkehrbar.

Bevorzugen Sie native Brücken für Rollups. Für Ethereum-L2-Rollups (Arbitrum, Optimism, Base) erbt die kanonische Brücke die Sicherheit direkt vom Ethereum-Konsens. Brücken von Drittanbietern mögen schneller sein, führen aber zusätzliche Vertrauensannahmen ein. Verwenden Sie kanonische Brücken für große Transfers, bei denen Sicherheit wichtiger ist als Geschwindigkeit.