Cross-Chain-Bridges haben durch Exploits mehr Geld verloren als fast jede andere Kategorie im Kryptobereich.
Die Ronin-Bridge verlor 625 Millionen US‑Dollar im Jahr 2022. Wormhole verlor im selben Jahr 320 Millionen. Nomad verlor nur wenige Monate später 190 Millionen.
Dennoch sind Bridges heute wichtiger denn je.
TAC, Celo und Dutzende anderer Projekte sind auf sie angewiesen, um getrennte Blockchain-Ökosysteme zu verbinden, die sonst nicht miteinander kommunizieren könnten.
Zu verstehen, warum Bridges gleichzeitig unverzichtbar und gefährlich sind, beginnt damit zu verstehen, was sie auf technischer Ebene tatsächlich tun.
TL;DR
- Eine Blockchain-Bridge ist Software, die Assets auf einer Chain sperrt und entsprechende Repräsentationen auf einer anderen mintet, sodass sich Wert zwischen isolierten Netzwerken bewegen kann.
- Bridges sind hochgradig attraktive Ziele, weil sie Verwahrung für gesperrte Assets übernehmen – manchmal Milliardenbeträge – in Smart Contracts oder Multisig-Wallets.
- Es gibt vier Haupt-Designs für Bridges (Lock-and-Mint, Burn-and-Mint, Liquiditätspools und Light-Client-Verifikation), jeweils mit eigenen Sicherheits-Trade-offs.
- Die meisten großen Hacks nutzten kompromittierte Validator-Schlüssel, Oracle-Manipulation oder Logikfehler in Smart Contracts aus, nicht die zugrunde liegenden Blockchains selbst.
- Neuere, vertrauensminimierte Designs mit Zero-Knowledge-Proofs verkleinern die Angriffsfläche, aber keine Bridge ist heute risikofrei.
Was eine Blockchain-Bridge tatsächlich macht
Zwei Blockchains sind standardmäßig völlig isolierte Systeme.
Bitcoin (BTC) hat kein Bewusstsein für Ethereum (ETH). Ethereum kann ein State-Update von Solana (SOL) nicht nativ lesen.
Jede Chain verarbeitet ihre eigenen Transaktionen, führt ihr eigenes Ledger und erreicht unabhängig Konsens. Es gibt keinen gemeinsamen Speicher zwischen ihnen.
Eine Bridge ist die Software-Schicht, die die Illusion von Cross-Chain-Bewegung erzeugt.
In der Praxis „wandern“ Assets nicht buchstäblich von einer Chain zur anderen. Tatsächlich passiert ein zweistufiger Prozess: Ein Asset wird auf der Quell-Chain gesperrt (oder verbrannt), und eine entsprechende Repräsentation wird auf der Ziel-Chain gemintet (oder freigegeben).
Das Bridge-Protokoll koordiniert diese beiden Ereignisse und garantiert, dass sie miteinander verknüpft sind.
Eine Bridge teleportiert deine Tokens nicht. Sie sperrt sie auf der einen Seite und druckt einen Schuldschein auf der anderen – die Sicherheitsfrage lautet immer: Wer kontrolliert das Schloss und wer autorisiert das Drucken?
Diese Unterscheidung ist für die Sicherheit enorm wichtig.
Das ursprüngliche Asset liegt irgendwo in Verwahrung. Diese Verwahrung ist die Angriffsfläche.
Ob es sich dabei um einen Smart Contract, eine Multisig-Wallet, die von einem Komitee von Validatoren kontrolliert wird, oder ein kryptografisches Beweissystem handelt, bestimmt nahezu alles darüber, wie sicher die Bridge ist.
Auch lesen: Bitget blockierte in einem Jahr 150 Mio. Cyberangriffe, neuer Bericht zeigt
Die vier Hauptdesigns von Bridges
Nicht alle Bridges funktionieren gleich. Es gibt heute vier dominante Architektur-Muster im produktiven Einsatz, und jedes nimmt andere Trade-offs zwischen Sicherheit, Geschwindigkeit, Kapitaleffizienz und Dezentralisierung in Kauf.
Lock-and-Mint ist das gängigste Design. Ein Nutzer sendet Tokens an einen Smart Contract auf der Quell-Chain, wo sie gesperrt werden. Das Validator-Set der Bridge beobachtet diese Einzahlung und weist die Ziel-Chain an, eine „wrapped“ Version dieses Tokens zu minten. Wrapped Bitcoin (WBTC) auf Ethereum funktioniert so. Genauso der Großteil der gebridgten ETH auf frühen Layer 2-Netzwerken. Der Wrapped Token repräsentiert einen Anspruch auf das gesperrte Original. Wenn ein Nutzer zurückwechseln will, verbrennt er den Wrapped Token und die Sperre auf der Quell-Chain wird aufgehoben.
Burn-and-Mint wird verwendet, wenn der Emittent eines Tokens das Angebot direkt auf mehreren Chains kontrolliert. Anstatt zu wrappen, wird der Token auf der Quell-Chain verbrannt (was das Gesamtangebot dort reduziert) und auf der Ziel-Chain frisch gemintet. Das Cross-Chain Transfer Protocol (CCTP) von Circle für USD Coin (USDC) funktioniert auf diese Weise. Da Circle selbst das Minten autorisiert, gibt es keinen Pool gesperrter Tokens, den ein Angreifer stehlen könnte; dafür vertraut man Circle vollständig.
Liquidity-Pool-Bridges wie bei Hop Protocol und Across Protocol arbeiten anders. Statt Assets zu sperren und Repräsentationen zu minten, verlassen sie sich auf Liquiditätsanbieter, die den nativen Token auf beiden Seiten halten. Ein Nutzer zahlt auf der Quell-Chain ein, und ein Liquiditätsanbieter auf der Ziel-Chain schickt ihm sofort den entsprechenden nativen Token. Der LP wird anschließend über das Protokoll entschädigt. Dieser Ansatz ist schneller und vermeidet Wrapped Tokens, hängt aber von ausreichender Liquidität ab und führt ein Gegenparteirisiko für LPs ein.
Light-Client-Verifikation ist das am stärksten vertrauensminimierte Design und das schwierigste zu bauen. Hier führt die Ziel-Chain einen kryptografischen Beweis des Konsenses der Quell-Chain direkt in einem Smart Contract oder ZK‑Circuit aus. Es ist kein externes Validator-Komitee erforderlich; die Mathematik beweist, dass die Einzahlung stattgefunden hat. IBC (Inter-Blockchain Communication), der Bridge-Standard im Cosmos-Ökosystem (ATOM), nähert sich diesem Modell an. ZK-basierte Bridges wie Succincts SP1 und Polyhedras zkBridge treiben dies weiter, indem sie Zero-Knowledge-Proofs nutzen, um State-Transitions kostengünstig zu verifizieren.
Auch lesen: HIVE hat gerade 115 Mio. US‑Dollar zu null Prozent aufgenommen, um gegen Bitcoin-Mining zu wetten
Warum Bridges so viel Risiko bündeln
Die Angriffsfläche einer Bridge unterscheidet sich grundlegend von der Angriffsfläche einer einzelnen Blockchain. Eine Chain wie Ethereum wird durch Hunderte Milliarden US‑Dollar in gestaktem ETH und Hunderttausende Validatoren gesichert. Sie zu kompromittieren erfordert, einen großen Teil dieses Validator-Sets gleichzeitig zu kompromittieren – ein praktisch unerschwinglicher Angriff.
Ein Bridge-Validator-Set ist oft viel kleiner. Die Ronin-Bridge, die das Spiel Axie Infinity auf ihrer eigenen Sidechain bediente, wurde von nur neun Validator-Knoten gesichert. Ein Angreifer brauchte die Kontrolle über fünf von ihnen, um Abhebungen zu autorisieren. Die Lazarus Group, die nordkoreanische, staatlich unterstützte Hackerorganisation, kompromittierte fünf Private Keys durch eine Kombination aus Phishing und einem gefälschten Jobangebot. Sie autorisierte betrügerische Abhebungen von 625 Millionen US‑Dollar. Die zugrunde liegenden Ethereum- und Ronin-Chains wurden nie angegriffen.
Der Ronin-Hack hat keine Blockchain gebrochen. Er hat ein Neun-Validatoren-Komitee gebrochen, bei dem fünf Schlüssel unsicher aufbewahrt wurden. Die Bridge war das schwächste Glied – per Design.
Das ist das strukturelle Problem extern validierter Bridges. Ihre Sicherheit wird nicht von den Chains geerbt, die sie verbinden; sie ist ein separates, oft kleineres und weniger erprobtes System. Je mehr Wert eine Bridge hält, desto attraktiver wird sie als Ziel, aber das Sicherheitsmodell skaliert nicht automatisch mit den Assets in Verwahrung.
Der Wormhole-Exploit im Februar 2022 war im Mechanismus anders, im Ergebnis jedoch ähnlich. Ein Angreifer fand einen Bug im Solana-Smart-Contract von Wormhole, der es ihm erlaubte, ein Ereignis zur „Guardian-Signaturverifikation“ zu fälschen. Er überzeugte den Contract davon, dass 120.000 ETH auf Ethereum eingezahlt worden waren, obwohl dies nicht stimmte, und mintete 320 Millionen US‑Dollar in Wrapped ETH auf Solana. Es wurden keine Validatoren kompromittiert. Die Verwundbarkeit lag in der Contract-Logik selbst. Jump Crypto, der Unterstützer von Wormhole, ersetzte die Mittel innerhalb von 24 Stunden, was einen Marktzusammenbruch verhinderte, den zugrunde liegenden Fehler aber nicht rückgängig machte.
Auch lesen: Polymarket-Nutzer verlieren 3,1 Mio. US‑Dollar bei Frontend-Angriff, während CFTC-Untersuchung andauert
Wie Validatoren und Oracles ins Bild passen
Die meisten Bridges, die keine reinen Light-Client-Systeme sind, verlassen sich auf irgendeine Form externer Beobachter, um zu bestätigen, dass eine Einzahlung stattgefunden hat, und um das entsprechende Minten oder Freigeben zu autorisieren.
Diese Beobachter tragen unterschiedliche Namen – Validatoren, Relayer, Guardians, Attestoren – erfüllen aber dieselbe Funktion: Sie beobachten eine Chain und melden den State an eine andere.
Die Vertrauensfrage lautet immer: Was ist nötig, damit diese Beobachter lügen?
In einem Multisig-Modell ist die Antwort: „Genug Schlüssel kompromittieren.“ In einem Oracle-basierten Modell könnte die Antwort sein: „Den Preisfeed oder Blockdaten manipulieren, die das Oracle meldet.“ In einem Proof-of-Stake-Validator-Modell lautet die Antwort: „Genug Stake erwerben, um eine Supermehrheit zu kontrollieren.“
LayerZero verwendet ein Modell, bei dem jede Anwendung ihr eigenes Set an Oracles und Relayern konfiguriert und so anwendungsspezifische Sicherheit statt eines gemeinsamen Bridge-Validator-Sets schafft. Das verschiebt das Risiko von „fällt eine Bridge aus, fällt alles aus“ zu „jede Anwendung trägt ihr eigenes Risiko“. Das verbessert die Isolation deutlich, legt aber mehr Verantwortung auf Entwickler, die Sicherheit korrekt zu konfigurieren.
Axelar nutzt ein eigenes Proof-of-Stake-Netzwerk von Validatoren, um Cross-Chain-Ereignisse zu beobachten. Die Sicherheit der Bridge ist somit an den Wert des Axelar-Tokens gebunden, den Validatoren staken – ein ähnliches Modell wie bei einer Layer‑1‑Blockchain, aber auf Cross-Chain-Messaging zugeschnitten.
Die grundlegende Herausforderung ist, dass man den State einer fremden Chain nicht nativ verifizieren kann, ohne deren Full Node auszuführen, was teuer ist. Light-Client- und ZK-Ansätze lösen dies kryptografisch. Alles andere bedeutet, einem Intermediär zu vertrauen, der ehrlich berichtet.
Also lesen: Steuert Ethereum nach Verlust wichtiger Unterstützung auf 1.000 US‑Dollar zu?
Wie ZK-Proofs die Bridge-Sicherheit verändern
Zero-Knowledge-Proofs sind die vielversprechendste langfristige Lösung für das Vertrauensproblem von Bridges. Ein ZK‑Proof ermöglicht es einer Partei, einer anderen zu beweisen, dass eine Aussage wahr ist – etwa „diese Transaktion wurde in einen finalisierten Block auf Ethereum aufgenommen“ –, ohne dass der Verifizierer die gesamte Berechnung selbst erneut ausführen muss.
Auf Bridges angewendet bedeutet dies, dass eine Ziel-Chain ein Ereignis auf der Quell-Chain verifizieren kann kryptografisch, ohne dass man einem externen Validator vertrauen muss. Der Proof selbst ist die Attestierung. Ein kompromittierter Validator kann keinen gültigen ZK‑Proof fälschen. Es gibt keine privaten Schlüssel, die gestohlen werden könnten. Die Sicherheit leitet sich aus der Mathematik ab.
Die praktische Herausforderung sind die Rechenkosten. Die Erzeugung von ZK‑Proofs für einen vollständigen Chain-Konsens (wie Ethereums Proof of Stake mit BLS‑Signaturaggregation über Tausende von Validatoren) erfordert erheblichen Rechenaufwand, obwohl diese Kosten dramatisch gesunken sind, seit sich die ZK‑Proving‑Technologie weiterentwickelt hat. Teams wie Succinct Labs, =nil; Foundation und Polyhedra bauen Proving-Systeme, die speziell für die Verifikation von Blockchain-States optimiert sind.
TAC, die Layer‑1‑Blockchain, die derzeit auf CoinGecko im Trend liegt, verfolgt einen spezifischen Ansatz für dieses Problem: Sie verbindet Ethereums EVM‑Developer‑Ökosystem mit dem TON (The Open Network) und der Telegram‑Nutzerbasis und nutzt dabei ein hybrides Validator- und Proof‑Modell. Projekte wie TAC verdeutlichen die praktische Nachfrage nach Bridges – Telegram hat rund 950 Millionen monatlich aktive Nutzer, und um dieses Publikum mit Ethereum‑kompatiblen Anwendungen zu verbinden, ist genau die Art von Cross‑Chain‑Infrastruktur nötig, die Bridges bereitstellen.
Der Trade-off bei ZK‑Bridges ist heute die Latenz. Die Erzeugung eines Proofs für einen finalisierten Ethereum‑Block kann Minuten dauern. Für Anwendungen, die schnelle Finalität benötigen, werden oft weiterhin optimistische Bridges mit Fraud‑Proof‑Fenstern bevorzugt. Man akzeptiert dabei eine längere Auszahlungsverzögerung (typischerweise 7 Tage bei großen optimistischen Rollups) im Austausch für Einfachheit.
Auch lesen: Chainlinks Wallet-Record macht den LINK-Rebound auf 9 $ zum Haupttest
Native Bridges versus Third‑Party‑Bridges
Wenn du Assets zwischen einer Layer‑1 und ihrem Layer‑2‑Rollup bewegst, nutzt du typischerweise eine „native Bridge“ – eine Bridge, die vom Rollup‑Team selbst gebaut und betrieben wird und tief in das eigene Sicherheitsmodell des Rollups integriert ist. Die native Bridge von Arbitrum (ARB), die native Bridge von Optimism (OP) und die native Bridge von zkSync fallen alle in diese Kategorie.
Native Bridges erben einen Großteil der eigenen Sicherheitsgarantien des Rollups. Bei einem optimistischen Rollup kann eine betrügerische Auszahlung innerhalb des 7‑tägigen Fraud‑Proof‑Fensters angefochten werden. Bei einem ZK‑Rollup wird eine Auszahlung erst dann finalisiert, wenn ein gültiger ZK‑Proof des Transaktionsbatches auf Ethereum gepostet wurde. Das sind deutlich stärkere Garantien als bei den meisten Third‑Party‑Bridges.
Der Trade-off besteht darin, dass native Bridges nur in eine Richtung funktionieren: von L1 zu L2 und zurück. Sie können keine Ethereum‑Assets nach Solana bridgen oder Assets direkt zwischen zwei separaten L2s verschieben. Für Bewegungen über Ökosystemgrenzen hinweg – etwa von Ethereum nach Solana oder von Arbitrum zu Polygon (POL) – müssen Nutzer Third‑Party‑Bridges verwenden, die die oben beschriebenen Validator‑ und Smart‑Contract‑Risiken mit sich bringen.
Das führt zu einer praktischen Taxonomie: Nutze native Bridges für die Bewegung von L1 zu L2, wenn Sicherheit die Priorität ist, und nutze geprüfte Third‑Party‑Bridges mit Track Record für Bewegungen zwischen Ökosystemen, wenn du das zusätzliche Risiko akzeptierst. Zu überprüfen, ob eine Bridge von einem renommierten Security‑Unternehmen (Trail of Bits, OpenZeppelin, Certik, Spearbit) auditiert wurde, und die bisherige Exploit‑Historie anzusehen, ist das Minimum an Due Diligence, bevor man einen Cross‑Chain‑Transferdienst nutzt.
Auch lesen: Russische Hacker fanden eine Schwachstelle bei Signal-Wiederherstellungsschlüsseln
Wer tatsächlich eine Bridge nutzen muss
Bridges sind für die meisten Gelegenheits‑Krypto‑Nutzer nicht notwendig. Wenn du Bitcoin (BTC) oder Ethereum (ETH) auf einer zentralisierten Börse hältst und einfach nur an der Kursentwicklung partizipieren möchtest, kommst du mit Bridges überhaupt nicht in Berührung.
Du brauchst eine Bridge, wenn du eine Anwendung nutzen willst, die auf einer anderen Chain lebt als der, auf der sich deine Assets befinden. Wenn dein ETH auf Ethereum Mainnet liegt, du aber ein DeFi‑Protokoll auf Arbitrum nutzen möchtest, bridgest du über die native Bridge von Arbitrum. Wenn du eine Solana‑native Anwendung mit USDC nutzen willst, das ursprünglich auf Ethereum entstanden ist, nutzt du eine Third‑Party‑Bridge.
Entwickler, die Cross‑Chain‑Anwendungen bauen, sind die intensivsten Bridge‑Nutzer. Jedes Protokoll, das Liquidität über mehrere Chains aggregieren will, oder jedes Spiel, das Spielern ermöglichen möchte, Assets über verschiedene Netzwerke hinweg zu nutzen, benötigt Bridging‑Infrastruktur, die direkt ins Produkt eingebaut ist. Aus diesem Grund positionieren sich Projekte wie LayerZero, Axelar, Wormhole und Hyperlane als „omnichain messaging protocols“ statt nur als Bridges: Sie sind Infrastruktur für Developer, nicht nur für Endnutzer, die Tokens verschieben.
Für normale Nutzer ist die praktische Empfehlung klar. Nutze kanonische native Bridges, wenn du dich zwischen L1 und einem großen L2 bewegst. Begrenze bei Third‑Party‑Bridges dein Exposure auf Beträge, deren Verlust du verkraften kannst, prüfe die Audit‑Historie, und bevorzuge Bridges, die seit mindestens einem Jahr unter nennenswertem TVL ohne Zwischenfälle betrieben werden. Der Ansatz „langsam bridgen, klein bridgen“ ist keine Ängstlichkeit, sondern spiegelt das ehrliche Risikoprofil der Technologie in ihrem aktuellen Zustand wider.
Auch lesen: Claude Fable 5 könnte zurückkehren, da Washington die Konfrontation mit Anthropic entschärft
Abschließende Gedanken
Cross‑Chain‑Bridges lösen ein reales und unausweichliches Problem.
Blockchains sind souveräne Systeme. Ohne Bridges wäre Krypto eine Ansammlung isolierter Silos, in denen Assets und Anwendungen nie miteinander interagieren.
Die Interoperabilität, die Bridges ermöglichen, bildet das Fundament für den Großteil von DeFi, Gaming und dem Multi‑Chain‑Ökosystem, das Projekte wie TAC aktiv aufbauen.
Die Hacks sind kein Beweis dafür, dass Bridges inhärent kaputt sind.
Sie sind ein Beweis dafür, dass frühe Bridge‑Designs aggressive Sicherheitstrade‑offs eingegangen sind – kleine Validator‑Komitees, nicht auditierte Smart‑Contract‑Logik, Oracle‑Abhängigkeiten – die nicht im Verhältnis zu den Werten standen, die sie schließlich hielten.
Jeder größere Exploit hat die Branche zu besseren Designs gedrängt: größere Validator‑Sets, formale Verifikation, ZK‑basierte Proof‑Systeme und native Rollup‑Bridges, die die L1‑Sicherheit direkt erben.
Als Nächstes lesen: PUMP gewinnt 12 %, während Protokolldaten warnen, dass der Rebound fragil sein könnte