Wie Cross-Chain-Brücken funktionieren und warum 4 Milliarden Dollar von 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 Hauptbuch, ihren eigenen Konsens und ihre eigenen Finalitätsregeln. Diese Isolation ist ein Merkmal des Sicherheitsdesigns, schafft jedoch ein praktisches Problem: Benutzer halten Vermögenswerte auf einer Kette und möchten sie auf einer anderen verwenden.

Brücken existieren, um dieses Problem zu lösen. Eine Brücke ist ein System, das es einem Benutzer ermöglicht, Vermögenswerte auf Kette A einzuzahlen 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 zentrale Schwierigkeit ist die Verifizierung. Wenn ein Benutzer behauptet, 100 ETH auf Ethereum eingezahlt zu haben und 100 ETH auf Arbitrum anfordert, muss jemand oder etwas überprüfen, dass die Einzahlung tatsächlich erfolgt ist. Der für diese Verifizierung gewählte Mechanismus bestimmt das Sicherheitsmodell der Brücke, ihre Geschwindigkeit, ihre Kosten und ihre Angriffsfläche. Wie eine Analyse von Coinbase zu Brücken-Hacks feststellte, resultieren Sicherheitsfehler bei Brücken konsequent aus der Kluft zwischen den Vertrauensannahmen, die eine Brücke behauptet, und den Vertrauensannahmen, die sie tatsächlich durchsetzt.

Dieser Leitfaden behandelt, wie die wichtigsten Brückenarchitekturen funktionieren, warum jede der größten Ausnutzungen erfolgreich war und was zu überprüfen ist, bevor man einer Brücke sein Geld 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. Lock. Der Benutzer sendet Token an einen Smart Contract auf der Quellkette. Die Token werden in diesem Vertrag gesperrt (gehalten), nicht verbrannt oder übertragen.
2. Verify. Eine Gruppe von Validatoren, Relayern oder einem Oracle beobachtet die Einzahlung auf der Quellkette und bestätigt ihre Gültigkeit auf der Zielkette.
3. Mint. Ein Smart Contract auf der Zielkette mintet eine synthetische Version des gesperrten Tokens. Der Benutzer erhält „wrapped ETH“ oder „bridged USDC“, das einen Anspruch auf das gesperrte Original darstellt.

Um zurückzukehren, kehrt der Prozess um: Der Benutzer verbrennt den synthetischen 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 erfolgt ist, obwohl dies nicht der Fall war, kann er nicht gedeckte Tokens minten. Genau das geschah bei den größten Brücken-Ausnutzungen.

Das arithmetische Problem. Lock-and-Mint-Brücken müssen ein 1:1-Verhältnis zwischen gesperrten Originals und geminteten Synthetikern aufrechterhalten. Wenn 10.000 ETH auf Ethereum gesperrt sind, sollten genau 10.000 bridged ETH auf der Zielkette existieren. Jede Abweichung bedeutet, dass einige bridged Tokens nicht gedeckt sind. Wenn Ausnutzungen nicht gedeckte Synthetiker schaffen, finden die letzten Benutzer, die einlösen, den Tresor leer. Dies schafft eine Bank-Run-Dynamik: Sobald die Nachricht von einer Ausnutzung verbreitet wird, eilt jeder Inhaber des wrapped Tokens, um einzulösen, in dem Wissen, dass nur die ersten, die ankommen, echte Vermögenswerte erhalten.

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

Burn-and-Mint beseitigt das Problem der wrapped Tokens, indem das Original zerstört und ein neues geschaffen wird.

1. Burn. Der Token wird auf der Quellkette dauerhaft zerstört.
2. Verify. Das Verbrennungsevent wird auf der Zielkette verifiziert.
3. Mint. Neue Tokens werden nativ auf der Zielkette gemintet.

Dieses Modell funktioniert nur für Tokens, deren Herausgeber das Minting auf mehreren Ketten kontrollieren. Circles Cross-Chain Transfer Protocol (CCTP) für USDC ist die größte Implementierung. Wenn ein Benutzer USDC von Ethereum nach Avalanche über CCTP bridgt, wird der Ethereum USDC verbrannt und nativ USDC auf Avalanche gemintet. Es gibt keine wrapped Tokens, keine Liquiditätsfragmentierung und keine nicht gedeckten Synthetiker.

Die Einschränkung besteht darin, dass Burn-and-Mint erfordert, dass der Token-Emittent Infrastruktur auf jeder unterstützten Kette bereitstellt und betreibt. Es handelt sich nicht um einen universellen Mechanismus. Beliebige ERC-20-Token können Burn-and-Mint nicht nutzen, es sei denn, ihre Entwickler bauen die Infrastruktur für das Cross-Chain-Minting. 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 Wrapping als auch Burning, indem es vorfinanzierte Liquiditätspools auf jeder Kette nutzt.

Der Mechanismus:

1. Einzahlung. Der Benutzer hinterlegt Token in einem Pool auf der Quellkette.
2. Abhebung. 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 die Pools regelmäßig über die Ketten hinweg aus, um eine angemessene Liquidität aufrechtzuerhalten.

Stargate (gebaut auf LayerZero) und Across Protocol verwenden Variationen dieses Modells. Der Vorteil ist die Geschwindigkeit: Da die Token bereits auf der Zielkette existieren, gibt es keine Verzögerung beim Minting. 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 die Brücken aktiv genutzt werden. In Zeiten mit geringem Volumen verdienen Liquiditätsanbieter wenig, während ihr Kapital untätig bleibt. Die aggregierten Kapitalanforderungen über alle unterstützten Ketten können Hunderte Millionen Dollar erreichen, was eine Eintrittsbarriere schafft und ein Konzentrationsrisiko birgt, wenn ein einzelner Liquiditätsanbieter dominiert.

Der Ronin-Bridge-Hack: 624 Millionen Dollar durch kompromittierte Schlüssel
Am 23. März 2022 entzogen Angreifer 624 Millionen Dollar in ETH und USDC von der Ronin-Bridge, die Ethereum mit der Ronin-Seitenkette verband, die von dem Spiel Axie Infinity verwendet wird.

Die Ronin-Bridge verwendete ein Multisig-Validierungsschema. Neun Validator-Knoten überprüften die Brücken-Transaktionen, und fünf davon konnten eine Abhebung autorisieren. Die Sicherheitsannahme war, dass es unpraktisch wäre, fünf von neun unabhängigen Validatoren zu kompromittieren.

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

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

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

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

Der Wormhole-Hack: 326 Millionen Dollar durch Umgehung der Verifizierung
Am 2. Februar 2022 nutzte ein Angreifer die Wormhole-Bridge aus, um 120.000 wETH (wrapped ETH) auf Solana zu minten, ohne ETH auf Ethereum einzuzahlen. Der Exploit hatte einen Wert von etwa 326 Millionen Dollar.

Die Wormhole-Bridge verließ sich auf eine Gruppe von 19 Guardians zur Verifizierung von Cross-Chain-Nachrichten. Die Guardians beobachteten eine Einzahlung auf Ethereum, produzierten eine signierte Bestätigung (genannt VAA, Verified Action Approval), und der Solana-Seitenvertrag überprüfte die Unterschriften, bevor er mintete.

Die Schwachstelle lag in der Signaturverifizierung auf der Solana-Seite. Der Solana-Vertrag von Wormhole verwendete eine veraltete Systemanweisung (verify_signatures), die die übergebenen Konten nicht ordnungsgemäß validierte. Der Angreifer stellte eine gefälschte Guardian-Gruppe zusammen, reichte ein gefälschtes VAA mit Unterschriften aus dieser gefälschten Gruppe ein, und der Vertrag akzeptierte es als gültig.

Im Wesentlichen sagte der Angreifer dem Solana-Vertrag: "Diese Wächter haben diesen Mint genehmigt", und der Vertrag überprü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 verhinderte, dass es zu kaskadierenden Verlusten bei den Solana DeFi-Protokollen kam, die wETH hielten.

Die Lehre. Der Verifizierungscode der Brücke ist eine hochgradig angreifbare Fläche. Ein einziger Logikfehler bei der Validierung von Signaturen kann unbegrenztes unbefugtes Minting ermöglichen.

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

Am 1. August 2022 wurde die Nomad-Brücke um etwa 190 Millionen Dollar erleichtert. Im Gegensatz zu Ronin und Wormhole wurde Nomad nicht von einer ausgeklügelten Gruppe angegriffen. Sie wurde von Hunderten von einzelnen Nachahmern entleert, nachdem der ursprüngliche Exploit öffentlich wurde.
Sie könnten auch interessiert sein: Cetus Protocol Hack und Sui Exploit: Die ganze Geschichte hinter dem 260-Millionen-Dollar-Angriff.

Nomad verwendete ein optimistisches Verifizierungsmodell. Cross-Chain-Nachrichten wurden eingereicht und als gültig angenommen, es sei denn, sie wurden innerhalb eines 30-minütigen Zeitfensters angefochten. Ein routinemäßiges Vertrags-Upgrade führte zu einem Fehler: Der Vertrag wurde mit einem vertrauenswürdigen Root von 0x00, dem Null-Bytes32-Wert, initialisiert.

In der Verifizierungslogik von Nomad wurde jede Nachricht gegen den vertrauenswürdigen Root überprüft. Da 0x00 der Standardwert für nicht initialisierten Speicher in Solidity ist, bestand jede Nachricht automatisch die Verifizierung. Jeder Benutzer konnte jede 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 einer Schar opportunistischer Angreifer entleert, darunter auch White-Hat-Hacker, die später etwa 36 Millionen Dollar an wiedergewonnenen Mitteln zurückgaben.

Die Lehre. Initialisierungsfehler in Brückenverträgen können katastrophal sein. Ein einziger falsch konfigurierter Parameter verwandelte das Sicherheitsmodell von Nomad von "optimistischer Verifizierung mit Betrugsnachweisen" in "keine Verifizierung überhaupt".

Der Harmony Horizon Hack: 100 Millionen Dollar durch ein 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 von fünf Validierern im Multisig der Brücke kompromittierten. Die Brücke von Harmony erforderte nur zwei von fünf Unterzeichnern, um eine Transaktion zu genehmigen, was eine ungewöhnlich niedrige Schwelle für eine Brücke darstellt, die 100 Millionen Dollar hält.

Der Angriff verstärkte die Lektion von Ronin: Multisig-Brücken sind nur so sicher wie ihr schwächstes Unterzeichner-Set. Wenn die Schwelle im Verhältnis zur Anzahl der Unterzeichner niedrig ist, kann ein einziger Infrastrukturkompromiss ausreichend sein. Sicherheitsforscher hatten die Zwei-von-Fünf-Schwelle von Harmony öffentlich kritisiert, bevor der Angriff stattfand.

Die Lehre. Die Auswahl der Schwelle ist ebenso wichtig wie die Anzahl der Validierer. Ein Fünf-von-Neun-Multisig bietet bedeutend andere Sicherheit als ein Zwei-von-Fünf-Multisig, obwohl beide denselben zugrunde liegenden Mechanismus verwenden.

Kumulative Verluste und Angriffsmuster

Das Ausmaß der Brückenverluste ist ohne Präzedenzfall in der Sicherheit von Smart Contracts. Brücken-Exploits machen etwa 3 Milliarden Dollar von 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 Unterzeichner-Schlüssel, um Brücken-Nachrichten zu fälschen. Ronin und Harmony folgten diesem Muster. Die Verwundbarkeit liegt nicht im Code, sondern in der operationellen Sicherheit der Unterzeichner-Infrastruktur.

Verifizierungsumgehung. Der Angreifer findet einen Fehler in der Verifizierungslogik, der es gefälschten Nachrichten ermöglicht, durchzukommen. Wormhole folgte diesem Muster. Die Verwundbarkeit ist ein Code-Fehler in der kritischsten Funktion des Brückenvertrags.

Fehler bei der Initialisierung oder Aktualisierung. Der Angreifer nutzt eine Fehlkonfiguration aus, die während der Bereitstellung oder Aktualisierung eingeführt wurde. Nomad folgte diesem Muster. Die Schwachstelle ist prozedural: Das Team machte einen Fehler während eines routinemäßigen Vorgangs.

Jedes Muster erfordert eine andere Verteidigung. Der Schlüsselkompromiss wird durch eine erhöhte Vielfalt der Signierer und die Verwendung von Hardware-Sicherheitsmodulen gemildert. Der Umgehung der Überprüfung wird durch Audits und formale Überprüfungen entgegengewirkt. Initialisierungsfehler werden durch Aktualisierungsverfahren gemildert, die obligatorische Testläufe auf geforkten 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 jedoch auf Brücken ab, deren Governance konzentriert ist oder deren Zeitverriegelung für Upgrades zu kurz ist. Brückenteams verwenden zunehmend mehrtägige Zeitverriegelungen (48 bis 72 Stunden) für Vertragsaktualisierungen, um den Benutzern Zeit zu geben, sich zurückzuziehen, bevor eine böswillige Änderung wirksam wird.

Die absichtsbasierten Alternativen zu traditionellen Brücken

Ein neuerer Ansatz umgeht Brückenverträge vollständig, indem er absichtsbasierten Cross-Chain-Transfer 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 (genannt Relayer) sendet sofort Token aus seinem eigenen Inventar auf der Zielkette und fordert später eine Erstattung an.

Dieses Modell reduziert die Vertrauensoberfläche. Der Benutzer hinterlegt niemals Token in einem Brückenvertrag, der gebündelte Gelder hält. Der Solver übernimmt das Risiko der Erstattung, und der Abrechnungsvertrag stellt sicher, dass der Benutzer den versprochenen Output erhalten hat. Es gibt keinen großen Pool an gesperrten Vermögenswerten, auf den ein Angreifer abzielen kann.

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

Leichtclient-Brücken und Zero-Knowledge-Verifizierung

Die oben genannten Ausnutzungen teilen 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 Bestätiger kompromittiert sind, schlägt die Brücke fehl.

Leichtclient-Brücken verfolgen einen anderen Ansatz. Anstatt sich auf ein Validator-Set zu verlassen, führt die Zielkette einen Leichtclient aus, der den Konsens der Quellkette direkt überprüft.

Eine Leichtclient-Brücke zu Ethereum würde beispielsweise das Validator-Set von Ethereum verfolgen und Block-Header und Statusnachweise on-chain überprüfen. Wenn ein Benutzer behauptet, Token auf Ethereum hinterlegt zu haben, überprüft der Brückenvertrag den Merkle-Nachweis gegen den Ethereum-Block-Header, den er bereits validiert hat.

Dieser Ansatz minimiert das Vertrauen: Die Brücke vertraut dem Konsens der Quellkette, nicht einem externen Gremium. Aber es ist teuer. Die Überprüfung des Konsenses von Ethereum auf einer anderen Kette erfordert erhebliche Berechnungen, was zu hohen Gas-Kosten führt.

Zero-Knowledge-Beweise bieten eine Lösung für das Kostenproblem. Anstatt jede Validator-Signatur on-chain zu überprüfen, kann ein ZK-Beweis die Überprüfung in einen einzigen prägnanten Beweis komprimieren. Die Zielkette überprüft einen Beweis anstelle von Hunderte von Signaturen.

Projekte wie Succinct Labs, Polymer und Lagrange bauen ZK-verifizierte Brücken. Diese befinden sich noch in der Entwicklung, stellen jedoch das stärkste Sicherheitsmodell für die Cross-Chain-Kommunikation dar: Vertraue der Mathematik, nicht dem Gremium. Frühe Implementierungen zeigen, dass die Überprüfungskosten sinken, da ZK-Beweissysteme effizienter werden, wobei einige Brücken bereits im Mainnet mit Beweiszeiten von unter 30 Sekunden betrieben werden.

Was dies nicht abdeckt

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

• Token-spezifische Brückstrategien oder welche Brücke für einen bestimmten Vermögenswert zu verwenden ist
• Detaillierte Vergleiche von Brückenaggregatoren (Li.Fi, Socket, Bungee)
• Die Wirtschaftlichkeit 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 Überprüfungen 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.

Sehen Sie sich das Validator- oder Guardian-Set an. Bei Multisig-Brücken überprüfen Sie, wie viele Unterzeichner existieren, wer sie betreibt und ob sie tatsächlich unabhängig sind. Wenn die Mehrheit der Unterzeichner zur gleichen Organisation oder geografischen Gerichtsbarkeit gehört, bietet die Multisig nur begrenzte Sicherheit.

Überprüfen Sie die Audit-Historie. Brückenverträge sind hochpreisige Ziele. Suchen Sie nach mehreren unabhängigen Audits von renommierten 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 insgesamt gesperrten Wert im Vergleich zum Sicherheitsbudget. Eine Brücke, die 500 Millionen Dollar mit einer Fünf-von-Neun-Multisig hält, hat ein sehr anderes Risikoprofil 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 das Kompromittieren von genügend Schlüsseln geringer sind als der Wert, der extrahiert werden kann.

Testen Sie zuerst mit kleinen Beträgen. Bevor Sie einen erheblichen Wert überbrücken, senden Sie eine kleine Testtransaktion. Überprüfen Sie, ob die Empfangsadresse, der Token und der Betrag korrekt sind. Brücken-Transaktionen sind typischerweise irreversibel.

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 Konsens von Ethereum. Drittanbieter-Brücken können schneller sein, bringen jedoch zusätzliche Vertrauensannahmen mit sich. Verwenden Sie kanonische Brücken für große Überweisungen, bei denen Sicherheit wichtiger ist als Geschwindigkeit.

Mehr erfahren: Was sind Cross-Chain-Brücken? Warum sie ständig gehackt werden

Was ist eine Cross-Chain-Brücke? {#faq-question-4160687517}

Eine Cross-Chain-Brücke ist ein System, das Vermögenswerte oder Daten zwischen zwei Blockchains überträgt, die nicht nativ kommunizieren können. Die Brücke sperrt, verbrennt oder bündelt Token auf einer Kette und gibt entsprechende Token auf einer anderen aus, wobei ein Verifizierungsmechanismus verwendet wird, um sicherzustellen, dass die Übertragung legitim ist.

Warum wurden Brücken so oft gehackt? {#faq-question-1765570890}

Brücken sind hochpreisige Ziele, da sie große Pools gesperrter Vermögenswerte halten. Sie führen auch zu komplexen Vertrauensannahmen an der Grenze zwischen zwei verschiedenen Sicherheitsmodellen. Eine Schwachstelle im Verifizierungsmechanismus (kompromittierte Schlüssel, fehlerhafte Signaturprüfungen, Initialisierungsfehler) kann es einem Angreifer ermöglichen, den gesamten Pool in einer einzigen Transaktion abzuziehen.

Was ist der Unterschied zwischen Lock-and-Mint und Burn-and-Mint? {#faq-question-0293370535}

Lock-and-Mint hält den ursprünglichen Token auf der Quellkette und mintet eine synthetische (verpackte) Version auf der Zielkette. Burn-and-Mint zerstört den ursprünglichen Token und mintet einen neuen nativen Token auf der Zielkette. Burn-and-Mint produziert native Tokens anstelle von synthetischen, erfordert jedoch, dass der Token-Emittent das Minting auf beiden Ketten kontrolliert.

Sind verpackte Tokens sicher? {#faq-question-3820965888}

Verpackte Tokens sind nur so sicher wie die Brücke, die sie ausgegeben hat. Wenn die Brücke ausgenutzt wird und die unterstützenden Vermögenswerte abgezogen werden, werden die verpackten Tokens ungesichert und verlieren ihre Bindung. Benutzer, die verpackte Tokens halten, tragen das Sicherheitsrisiko der Brücke, nicht nur das Risiko des zugrunde liegenden Vermögenswerts.

Wie lange dauert das Bridging? {#faq-question-8084085272}

Es variiert je nach Mechanismus. Liquiditätspool-Brücken und absichtsbasierten Brücken (Across) können in Sekunden abgeschlossen werden. Lock-and-Mint-Brücken mit Multisig-Verifizierung benötigen typischerweise 10 bis 30 Minuten. Optimistische Brücken mit Betrugsnachweisfenstern können 7 Tage für Abhebungen von optimistischen Rollups zu Ethereum in Anspruch nehmen, obwohl schnelle Brücken die Liquidität vorfinanzieren können, um dies zu reduzieren.

Was ist eine Light-Client-Brücke? {#faq-question-5264913434}

Eine Light-Client-Brücke verifiziert den Konsens der Quellkette direkt auf der Zielkette, anstatt sich auf ein externes Validatorset zu verlassen. Sie überprüft Block-Header und Statusnachweise und vertraut auf die eigene Sicherheit der Quellkette. Dies ist vertrauensminimierter als Multisig- oder optimistische Verifizierung, kostet jedoch mehr Gas.

Kann ich Geld verlieren, wenn ich eine Brücke benutze? {#faq-question-7660039976}

Ja. Wenn die Brücke nach Ihrer Einzahlung, aber vor Ihrer Abhebung ausgenutzt wird, können Ihre gesperrten Token gestohlen werden. Wenn Sie verpackte Token halten und die Brücke gehackt wird, können Ihre verpackten Token wertlos werden. Darüber hinaus können falsche Zieladressen oder nicht unterstützte Token-Typen zu einem dauerhaften Verlust führen.

Welche Brücke sollte ich verwenden? {#faq-question-1819675312}

Keine einzelne Brücke ist für alle Situationen die beste. Für USDC ist Circles CCTP die sicherste Option, da es Burn-and-Mint ohne verpackte Token verwendet. Für allgemeine ERC-20-Übertragungen vergleichen Sie die Verifizierungsmechanismen der verfügbaren Brücken. Bevorzugen Sie Brücken mit Light-Client- oder ZK-Verifizierung, mehreren unabhängigen Prüfungen und einer nachgewiesenen sicheren Betriebsbilanz. Brückenaggregatoren wie Li.Fi können helfen, Routen zu vergleichen.

*Haftungsausschluss: Dieser Artikel dient nur zu Informationszwecken und stellt keine finanzielle, investive oder rechtliche Beratung dar. Kryptowährungen bergen erhebliche Risiken, und Sie sollten Ihre eigenen Recherchen durchführen, bevor Sie Entscheidungen treffen. Die Informationen sind Stand August 2026.*