Cross-Chain-Bridge-Sicherheit: Brauchst du wirklich eine?

Cross-Chain-Systeme lassen eine Blockchain auf Informationen über eine andere reagieren. Dadurch entstehen zusätzliche Annahmen zu Verifikation, Verwahrung, Liquidität und Betrieb. Manche Designs nutzen externe Validatoren, andere Quell-Chain-Beweise oder lokale Liquidität. Entscheidend ist, welche Annahmen Werte bewegen können, wie Fehler begrenzt werden und ob Cross-Chain überhaupt nötig ist.

Der aktuelle ethereum.org Bridge-Leitfaden unterscheidet extern, lokal oder nativ verifizierte, optimistische, Light-Client- und Liquiditätsnetzwerk-Ansätze. Sicherheit, Konnektivität, Latenz, Fähigkeiten und Kosten stehen in Zielkonflikten.

Wie kann eine Cross-Chain-Bridge Mittel verlieren?

Eine Asset-Bridge sperrt, verbrennt, entsperrt oder tauscht Werte, nachdem sie Evidenz über eine andere Chain akzeptiert hat. Diese kann von Signern, Oracles, Light Clients, Fraud Proofs oder Transaktionen der verbundenen Chains stammen.

• Key und Governance. Ein Angreifer erreicht die Schwelle für Nachrichten, Upgrades oder Withdrawals.
• Verifikation und Contracts. Code akzeptiert eine gefälschte, wiederholte oder ungültige Nachricht, einen Proof oder State-Übergang.
• Liquidität und Wirtschaft. Pools, Preise, Inventar, Relayer oder Settlement versagen.
• Betrieb. Monitoring, Berechtigungen, Upgrades, Incident Response, Frontends oder Abhängigkeiten versagen.

Nicht jede Bridge hält alle Nutzerwerte in einem Contract und nicht jeder Fehler hat unbegrenzte Auswirkungen. Prüfe konkrete Contracts, Limits, Collateral, Routenliquidität, Upgrade-Kontrollen und Recovery.

Was zeigen Ronin, Wormhole und Nomad?

Ronin, März 2022. Ronin meldete den Abfluss von 173.600 ETH und 25,5 Millionen USDC. Das Security-Update schlug mehr unabhängige Validatoren und Auszahlungslimits vor. Die Relaunch-Mitteilung dokumentiert Erstattung, Audits, Governance-Änderungen, Auszahlungsstufen, menschliche Prüfung, Circuit Breaker und Tageslimit. Validator-Unabhängigkeit, Berechtigungslebenszyklus, Auszahlungspolitik und Erkennung gehören zur Sicherheitsgrenze.

Wormhole, Februar 2022. Der Incident Report beschreibt, wie der Solana-seitige Contract ausgenutzt und 120.000 unbesicherte wrapped ETH geprägt wurden. Der Fehler lag in der Prüfung des Instruction-Kontexts, nicht beim Guardian-Quorum.

Nomad, August 2022. Die Root-Cause-Analyse erklärt, dass ein Replica-Bug nach einem Upgrade unbewiesene Nachrichten passieren ließ. Zero Root und geänderter Check ergaben acceptableRoot(bytes32(0)) gleich true. Watcher deckten Updater-Key-Kompromittierung ab, nicht Contract-Bugs.

USD-Schätzungen hängen von Preis und Zeitpunkt ab. Deshalb nutzen wir gemeldete Tokenmengen. Die Vorfälle zeigen verschiedene Fehlerarten, nicht eine einzige Ursache aller Bridge-Verluste.

Brauchst du eine Bridge?

• Kann das Produkt auf einer Chain bleiben? Dann kann Cross-Chain Risiko ohne ausreichenden Mehrwert hinzufügen.
• Gibt es eine etablierte Route? Prüfe Proof-Reife, Upgrade-Keys, Pause-Rechte, Delays und Data Availability. Canonical bedeutet nicht risikofrei.
• Brauchst du Assets, Nachrichten oder nur Daten? Verwahrung, Message-Ausführung, Intent-Settlement und Read-only-Verifikation haben andere Anforderungen.
• Kannst du Optionen statt Verwahrung anbieten? Drittanbieter reduzieren Eigenentwicklung, fügen aber neue Annahmen hinzu.

Baue nur dann eine eigene Bridge, wenn bestehende Routen eine dokumentierte Anforderung nicht erfüllen und du Security Engineering, Review, Monitoring, Upgrades und Incident Response dauerhaft finanzieren kannst.

Wie vergleichst du Trust-Modelle?

Labels sind Startpunkte. Admin- oder Upgrade-Kontrollen können die beworbene Verifikation dominieren.

Light Clients können externe Signer reduzieren, sind aber nicht automatisch überall am sichersten. Client-Bugs, Finalität, Governance, Upgrades und verbundene Chains bleiben relevant. Siehe L1/L2-Gas-Trade-offs.

Was gehört in den Pre-Launch-Review?

1. Assets, Nachrichten und Authority dokumentieren.
2. Safety- und Liveness-Annahmen je Route festhalten.
3. Contracts, Agenten und ihre Naht gemeinsam testen.
4. Keys und Berechtigungen unabhängig verwahren, rotieren und widerrufen.
5. Auswirkungen mit Limits, Delays, Circuit Breakers, Rollouts und Collateral begrenzen.
6. Supply, Escrow, Nachrichten, Signaturen, Liquidität und Withdrawals überwachen.
7. Upgrades als Security-Events mit Tests, Review und Rollback behandeln.
8. Incident- und Nutzerkommunikation vorbereiten.

"Ein Bridge-Review beginnt mit Authority und Schadensbegrenzung: Wer kann die Ziel-Chain handeln lassen, und was begrenzt den Schaden?"

Q&A: Canonical Bridge oder Drittanbieter?

Es gibt keinen universellen Default. Eine L2-Bridge kann zusätzliche Annahmen minimieren, aber Upgrade-Governance, Pause-Rechte, Proof-Reife oder Delays enthalten. Drittanbieter bieten andere Routen und fügen Validatoren, Solver, Liquidität oder Contracts hinzu. Vergleiche aktuelle Routendokumentation.

Q&A: Reicht ein Multisig?

Ein Multisig kann eine Kontrolle sein, doch der Threshold belegt weder Unabhängigkeit noch Verwahrungsqualität, Monitoring oder Schadensbegrenzung. Prüfe Key-Kontrolle, Quorum, Berechtigungsablauf, Limits, Delays, Pausen und Alerts.

Q&A: Garantieren Audits Sicherheit?

Nein. Ein Audit gilt für Scope, Version, Umgebung und Zeitpunkt. Es garantiert keine künftigen Upgrades, Key-Verwahrung, Governance, Chain, Liquidität oder Betrieb. Nomad zeigt die Bedeutung exakter Versionen und Deployment-Kontrollen. Siehe Pre-Audit-Checkliste.

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

In der Regel nur, wenn Cross-Chain-Verifikation oder Settlement das differenzierende Kernprodukt ist und bestehende Routen nicht genügen. Sonst vermeidet Single-Chain oder eine geprüfte Route eine große dauerhafte Pflicht. Siehe Blockchain Engineering und Glossar.