Warum Cross-Chain-Messaging schwieriger ist, als es aussieht
Einen Token von Ethereum nach Solana oder von einer Cosmos App-Chain zu einem Rollup zu bewegen, sieht an der Oberfläche wie eine einfache Übertragung aus. Unter der Haube muss die Ziel-Chain dem Wort eines fremden Systems vertrauen, dass eine Einzahlung, ein Burn oder eine Abstimmung wirklich stattgefunden hat. Dieses Wort ist eine Nachricht, und die Art, wie sie verifiziert wird, ist das gesamte Sicherheitsmodell der Bridge.
Der naive Ansatz besteht darin, die Aufgabe einer Multisig-Wallet zu übergeben. Eine Gruppe bekannter Validatoren signiert die Nachricht, und die Ziel-Chain akzeptiert sie, sobald ein Schwellenwert an Signaturen vorliegt. Das ist schnell, flexibel und zugleich das Designmuster hinter den meisten der größten Bridge-Exploits in der Krypto-Geschichte. Wenn eine Multisig die Vertrauenswurzel ist, ist die Bridge nur so sicher wie die kleinste Anzahl kompromittierter Schlüssel, die sie toleriert.
Der tiefere Ansatz besteht darin, die Ziel-Chain die Quell-Chain direkt verifizieren zu lassen, so wie eine Person einen Reisepass prüft, indem sie den Stempel des ausstellenden Landes liest, statt dem Wort eines Dritten zu vertrauen. Genau das macht ein Light Client. Es ist außerdem teuer, langsam auszuliefern und auf Chains beschränkt, die die Verifizierungslogik der jeweils anderen ausführen können. Die drei Stacks in diesem Artikel liegen auf einem Spektrum zwischen diesen beiden Extremen, und die Unterschiede sind wichtiger, als die Marketingseiten nahelegen.
Risiken, die jeder Cross-Chain-Nutzer zuerst akzeptieren sollte
Bevor man Funktionen vergleicht, lautet die ehrliche Einordnung: Jede Cross-Chain-Nachricht trägt Risiken, die die zugrunde liegenden Chains nicht haben. Ein Token, der von Ethereum in ein anderes Netzwerk gebridged wird, ist streng genommen nicht mehr der Ethereum-Token. Er ist ein gewrappter oder geminteter Schuldschein, den die Ziel-Chain nur einlösen kann, wenn das Sicherheitsmodell der Bridge hält. Bridges waren drei Jahre in Folge die größte einzelne Quelle von Krypto-Verlusten nach Kategorie.
Die historische Bilanz ist ernüchternd. Die Ronin-Bridge verlor 2022 rund 625 Millionen Dollar, nachdem fünf von neun Validatorenschlüsseln kompromittiert worden waren. Die Wormhole-Bridge verlor 2022 etwa 320 Millionen Dollar, als ein Angreifer die Signaturverifizierung auf Solana umging. Die Harmony Horizon-Bridge verlor 2022 rund 100 Millionen Dollar. Die Nomad-Bridge verlor Anfang 2023 nahezu 190 Millionen Dollar. Insgesamt entfallen auf Cross-Chain-Bridges mehr als zwei Milliarden Dollar an dokumentierten Verlusten, und diese Zahl zeichnet das Bild noch zu niedrig, weil manche Vorfälle still absorbiert werden.
Für Nutzer fallen die praktischen Risiken in einige Kategorien. Smart-Contract-Risiken auf der Ziel-Chain können es einem Angreifer ermöglichen, nicht gedeckte Vermögenswerte zu minten. Eine Kompromittierung von Validatoren auf der Quellseite kann es einem Dieb ermöglichen, eine gefälschte Einzahlung zu genehmigen. Replay- oder Finality-Probleme können dazu führen, dass eine Nachricht akzeptiert wird, bevor die Quell-Chain wirklich finalisiert ist. Governance-Übernahme kann die Regeln nachträglich ändern. Nichts davon ist theoretisch. All das ist bereits passiert, und deshalb ist ein Vergleich der Vertrauensmodelle nützlicher als eine Funktions-Checkliste.
Cosmos IBC und das Light-Client-Vertrauensmodell
IBC, das Inter-Blockchain Communication-Protokoll, ist das, was die Branche einem kryptografisch nativen Cross-Chain-Standard am nächsten kommt. Es wurde von der Interchain Foundation spezifiziert und im Cosmos SDK ausgeliefert, und seit 2021 überträgt es live reale Vermögenswerte und Nachrichten zwischen unabhängigen App-Chains. ATOM, der native Token des Cosmos Hub, spielt in diesem Ökosystem eine koordinierende Rolle, auch wenn viele IBC-fähige Chains kaum oder gar keine direkte ATOM-Exponierung haben.
Die zentrale Idee hinter IBC ist, dass die Ziel-Chain einen Light Client der Quell-Chain ausführt und die Quell-Chain einen Light Client der Ziel-Chain ausführt. Ein Light Client ist ein kleines Stück Code, das Block-Header einer anderen Chain nur anhand der Konsensregeln dieser Chain verifiziert. Wenn Chain A ein Paket an Chain B senden möchte, schreibt sie das Paket in ihren eigenen Merkle-Baum fest. Anschließend verifiziert Chain B diese Festschreibung, indem sie den von Chain A gesendeten Header prüft, der vom Validator-Set von A signiert wurde. Es gibt keine externe Multisig, kein Oracle und keinen Drittanbieter-Relayer mit der Macht, eine Nachricht zu fälschen. Die Sicherheit der Bridge ist die Sicherheit der beiden beteiligten Chains.
Dieses Modell hat echte Konsequenzen. Eine Cosmos App-Chain und eine andere Cosmos App-Chain, die beide einen Konsens im Tendermint-Stil ausführen, können mit wenigen Konfigurationszeilen verbunden werden und sehr starke Garantien übernehmen. Die Verbindung zu einer Chain mit einem anderen Konsensalgorithmus wie Ethereum erfordert das Schreiben eines eigenen Light Clients in Solidity und einen Relayer, der auf beiden Seiten Gas bezahlen kann. Diese Arbeit wurde für Ethereum erledigt, und die daraus entstandenen Verbindungen im Stil von ICS-27 Neutron sind nutzbar, aber der Aufwand ist höher als bei den anderen Stacks in diesem Artikel.
Die begrenzte Reichweite ist der Kompromiss. IBC sichert nicht auf magische Weise beliebige Rollups und Alt-L1s ab. Jede Verbindung ist maßgeschneidert, und jede verbundene Chain wird Teil der Vertrauensfläche. Aus Sicherheitssicht ist das eine Stärke, weil das Vertrauensmodell lokal bleibt, und aus Ökosystemsicht eine Einschränkung, weil es nicht so leicht skaliert wie ein permissioned Message Bus.
Shared Security und die App-Chain-Perspektive
Die App-Chain-These hinter Cosmos lautet, dass ernsthafte Anwendungen ihre eigene Blockchain verdienen, mit eigenem Validator-Set und eigenem Fee-Token. IBC ist das verbindende Gewebe, das diese These praktikabel macht, weil es vielen souveränen Chains ermöglicht, miteinander zu interagieren, ohne Souveränität aufzugeben. Replicated Security und ihr Nachfolger Interchain Security ermöglichen kleineren App-Chains, das Validator-Set des Cosmos Hub zu mieten. Das verbessert ihre Sicherheit, während IBC die Cross-Chain-Schicht bleibt. Das Ergebnis ist ein Modell, bei dem die Vertrauensannahmen für eine Cross-Chain-Nachricht explizit, lokal und prüfbar sind, der Preis dafür aber Fragmentierung über viele Chains mit unterschiedlicher Validator-Qualität ist.
LayerZero und der konfigurierbare DVN-Stack
LayerZero wählt einen anderen Designweg. Statt vollständige Light Clients auf jeder Chain auszuführen, nutzt es einen Ultra Light Node, einen minimalistischen Endpoint, der Block-Header nur bei Bedarf speichert und sich ansonsten auf einen Off-Chain-Relayer sowie einen separaten Stack aus Decentralized Verifier Networks, sogenannten DVNs, stützt, um eine Nachricht zu attestieren. Die Ziel-Chain akzeptiert eine Nachricht, wenn die konfigurierten DVNs übereinstimmen, dass die Transaktion der Quell-Chain gültig ist.
Dies ist insofern eine vertrauensminimierte Architektur, als keine einzelne Partei die Nachrichtenübermittlung kontrolliert, aber sie ist zugleich konfigurierbar. Die Anwendung, die einen LayerZero Endpoint bereitstellt, kann auswählen, welche DVNs ihre Nachrichten verifizieren. Die Standardkonfiguration nutzt ein bestimmtes Set, aber ein Entwickler kann einen anderen DVN-Stack einsetzen, um das Sicherheitsprofil einer bestimmten Bridge zu verändern. Einige Teams haben mit einem einzigen DVN ausgeliefert, was in der Praxis näher an einer Multisig liegt, während andere mehrere DVNs von unabhängigen Betreibern verwenden.
Kritiker von LayerZero haben argumentiert, dass genau diese Flexibilität ein Risiko darstellt. Wenn eine Anwendung mit schwachen DVNs bereitgestellt wird, um Kosten oder Latenz zu sparen, ist die Sicherheit dieser Bridge konstruktionsbedingt schwach. Das LayerZero-Team hat darauf reagiert, indem es den DVN-Marktplatz erweitert und auf Standardkonfigurationen mit unabhängigen Verifizierern gedrängt hat, und die V2-Neugestaltung des Protokolls setzt stärker auf eine explizite DVN-Zusammensetzung. Dennoch liegt die Verantwortung für die Wahl des Verifizierer-Stacks letztlich beim Anwendungsteam. Das bedeutet, dass ein Nutzer, der über eine LayerZero Bridge transagiert, sowohl dem Protokoll als auch den Entscheidungen dieses Teams vertrauen muss.
Die Reichweite von LayerZero ist groß. Es ist auf den meisten großen EVM-Chains, auf Solana und auf mehreren Nicht-EVM-Netzwerken live, und es wurde von großen Anwendungen genutzt, darunter Stargate, ein Cross-Chain-Liquiditätsrouter, sowie mehrere Stablecoin-Emittenten. Diese Reichweite ist ein echter Vorteil, geht aber mit einem komplexeren mentalen Modell einher: Die Sicherheit einer bestimmten Bridge hängt von den ausgewählten DVNs, dem Anwendungskontrakt, der die Verifizierung durchsetzt, und der verwendeten On-Chain-Endpoint-Version ab.
Wie DVNs die Vertrauensrechnung verändern
Die einfachste Art, über einen DVN-Stack nachzudenken, ist als steckbares Signaturschema. Jedes DVN kann ein zk-Proof-System, ein auf Restaking basierender Verifizierer, ein zentralisierter Attestierungsdienst oder eine von einem bekannten Betreiber geführte Multisig sein. Das Stapeln unabhängiger DVNs mit unterschiedlichen Vertrauenswurzeln ist eine sinnvolle Verteidigung, weil ein Angreifer mehr als einen Verifizierer gleichzeitig kompromittieren müsste. Das Stapeln korrelierter DVNs, die Infrastruktur oder Governance teilen, kommt eher einem einzelnen Ausfallpunkt gleich, der als viele ausgegeben wird. Anwendungsteams, die mit billigen, korrelierten DVNs ausliefern, bekommen das Marketing der Dezentralisierung und das Risikoprofil einer Multisig.
Wormhole und die Guardian-Multisig
Wormhole, ursprünglich von Certus One entwickelt und heute von der Wormhole Foundation betreut, ist der dritte große Stack. Es verbindet Ethereum, Solana, BNB Chain, Aptos, Sui und eine lange Reihe weiterer Netzwerke, und es war historisch eines der Bridge-Designs mit dem höchsten TVL in der Branche. Sein Design ist außerdem am einfachsten zu beschreiben und aus Sicherheitssicht am umstrittensten.
Nachrichten auf Wormhole werden von einem permissioned Set aus 19 Guardians attestiert, von denen jeder einen Node betreibt, der die Quell-Chain beobachtet und beobachtete Ereignisse signiert. Wenn 13 von 19 Guardians dieselbe Nachricht signieren, wird sie auf der Ziel-Chain akzeptiert. Die Guardians sind bekannte Betreiber aus der gesamten Branche, und das Set wird durch Governance kontrolliert. Das bedeutet, dass neue Guardians durch die Wormhole DAO hinzugefügt oder entfernt werden können.
Das Vertrauensmodell ist eine Multisig mit hohem Schwellenwert. Wenn 7 von 19 Guardians kolludieren oder wenn die Schlüssel von 7 Guardians kompromittiert werden, ist die Bridge vollständig kompromittiert. Das ist ein bedeutender Zentralisierungspunkt, und der Exploit von 2022 machte die Konsequenzen konkret. Ein Angreifer fand einen Weg, eine Signaturprüfung auf der Solana-Seite von Wormhole zu fälschen, wodurch er 120.000 wrapped ETH prägen konnte, die nicht durch Einlagen auf Ethereum gedeckt waren. Der Verlust betrug damals etwa 320 Millionen Dollar und wurde von Jump Crypto abgesichert, das ein Guardian-Betreiber gewesen war und einsprang, um die Bridge zu rekapitalisieren.
Wormhole hat seitdem eine Guardian-Firewall hinzugefügt, seine On-Chain-Verifizierungslogik verschärft und zusätzliche Sicherheitsprüfungen vorangetrieben. Nichts davon ändert die zugrunde liegende Vertrauensannahme, nämlich dass eine permissioned Multisig mit einem Schwellenwert von 13 von 19 die Wurzel der Cross-Chain-Sicherheit ist. Für Nutzer lautet die praktische Frage, ob das Guardian-Set ausreichend dezentralisiert ist, ob die Anreize der Guardians mit ehrlichem Betrieb übereinstimmen und ob die Anwendung auf der Ziel-Chain den Verifizierungspfad korrekt durchsetzt.
Warum das TVL-Ranking irreführend ist
Der TVL von Wormhole wurde oft als Näherungswert für seine Sicherheit verwendet, nach der impliziten Logik, dass mehr Geld, das einer Bridge vertraut, bedeutet, dass die Bridge vertrauenswürdiger ist. Die historische Bilanz spricht in die andere Richtung. Bridges mit dem höchsten TVL sind die attraktivsten Ziele, und Wormholes Position nahe der Spitze dieser Liste ist der Grund dafür, dass seine Exploits so groß waren. Ein Nutzer, der auf die gesamten Einlagen schaut, sieht nicht das Sicherheitsmodell, sondern nur den Preis, der einem Angreifer winkt.
Wie IBC, LayerZero und Wormhole in den entscheidenden Dimensionen abschneiden
Das Vertrauensmodell ist die wichtigste Dimension, und auf dieser Achse ist IBC konstruktionsbedingt am sichersten, weil jede Chain die andere durch Konsens verifiziert. LayerZero liegt an zweiter Stelle, weil der DVN-Stack so konfiguriert werden kann, dass er kryptografisch robust ist, aber nur, wenn die Anwendung Verifizierer auswählt, die es tatsächlich sind. Wormhole liegt an dritter Stelle, weil die Vertrauenswurzel eine permissioned Guardian-Multisig ist, die bereits einmal kompromittiert wurde und sich nur so schnell verbessert, wie das Guardian-Set dezentralisiert und rotiert wird.
Reichweite und Konnektivität sprechen für Wormhole und LayerZero. Beide werden sofort auf Dutzenden von Chains ausgeliefert, und ein Entwickler kann auf beiden eine Cross-Chain-Anwendung bereitstellen, ohne einen eigenen Light Client zu schreiben. IBC erfordert dagegen eine Einrichtung pro Verbindung, und eine Verbindung zu einer Chain mit unbekanntem Konsens ist ein ernsthaftes Engineering-Projekt. Für eine Anwendung, die schnell jedes große Netzwerk erreichen muss, ist das ein echter Kostenfaktor.
Die Entwicklererfahrung ist heute bei LayerZero und Wormhole ungefähr gleichwertig, da beide einen relativ unkomplizierten Endpoint und erprobte Bereitstellungspfade bieten. Das IBC-Tooling hat sich stark verbessert, mit Bibliotheken wie ibc-go und Hermes-Relayern, aber der On-Chain-Footprint auf der Ethereum-Seite ist größer und das EVM-Tooling weniger ausgereift als bei den Alternativen.
Latenz und Kosten lassen sich schwer verallgemeinern. IBC-Verbindungen zwischen Tendermint-Chains sind schnell und günstig, weil der Relayer lediglich vorhandene Header einreicht. Die Latenz von LayerZero hängt von der DVN-Konfiguration und davon ab, wie oft der Ultra Light Node seinen Zustand aktualisieren muss. Die Latenz von Wormhole hängt von der Aggregation der Guardian-Signaturen ab. Für Transfers in Retail-Größe sind alle drei konkurrenzfähig; für hochfrequente Cross-Chain-Arbitrage können die Unterschiede bei Finalität und Gas relevant sein.
Governance- und Upgrade-Pfade sind eine unterschätzte Risikofläche. IBC-Upgrades erfolgen auf Protokollebene und erfordern Koordination zwischen verbundenen Chains. LayerZero wurde aktiv weiterentwickelt, wobei V2 das Vertrauensmodell hin zu einer expliziteren DVN-Zusammensetzung umgestaltet. Die Governance von Wormhole liegt bei der Wormhole Foundation und dem Guardian-Set, wobei der Vorfall von 2022 zu einer sichtbareren Sicherheits-Roadmap geführt hat. Keiner dieser Governance-Pfade ist vollständig trustless, und ein Nutzer sollte wissen, wer die Regeln ändern kann.
Praktische Auswirkungen für Builder und DeFi-Nutzer
Für Builder lautet die ehrliche Erkenntnis, dass die Wahl des Cross-Chain-Stacks die Wahl einer Vertrauensbasis ist, und diese Entscheidung sollte getroffen werden, bevor auch nur eine einzige Zeile Geschäftslogik geschrieben wird. Eine Anwendung, die die stärkstmöglichen Garantien benötigt und gerne in einer Cosmos-ähnlichen Umgebung bleibt, wird feststellen, dass IBC kaum zu schlagen ist. Eine Anwendung, die eine große Reichweite braucht und bereit ist, die DVN-Zusammensetzung sorgfältig zu verwalten, wird LayerZero als flexibel empfinden. Eine Anwendung, die eine schnelle Markteinführung priorisiert und mit einem permissioned Guardian-Set zurechtkommt, wird Wormhole schnell ausliefern können, mit dem Verständnis, dass das Vertrauensmodell genau der Teil ist, den die Marketingseite meist auslässt.
Für DeFi-Nutzer ist die praktische Checkliste kurz. Finde heraus, welche Bridge ein Token nutzt, um sich zwischen den Chains zu bewegen, die für dich wichtig sind. Lies nach, wie diese Bridge Nachrichten verifiziert. Wenn die Antwort eine Multisig ist, frage, wie viele Signers erforderlich sind, wer sie sind und wie sie verwaltet werden. Wenn die Antwort ein Light Client ist, frage, ob die Ziel-Chain diesen Client tatsächlich ausführt und wie oft er aktualisiert wird. Wenn die Antwort ein DVN-Stack ist, frage, welche DVNs im Stack enthalten sind und ob sie unabhängig sind. Ein wrapped oder bridged Asset ist nur so sicher wie der schwächste Teil dieser Antwort, und das bridged Token hat selten dasselbe Risikoprofil wie der zugrunde liegende Vermögenswert auf seiner Home-Chain.
Es ist auch wichtig, sich daran zu erinnern, dass Cross-Chain-Risiken nicht statisch sind. Das Guardian-Set einer Bridge von heute ist morgen möglicherweise nicht mehr dasselbe Guardian-Set. Die DVN-Zusammensetzung einer LayerZero-Anwendung von heute kann morgen neu konfiguriert werden. Die Light Clients einer IBC-Verbindung von heute hängen von Validator-Sets ab, die sich durch Governance ändern können. Vertrauensannahmen sind lebendig, und ein ehrlicher Vergleich spricht das klar aus.
Wie du Cross-Chain-Risiken clever verfolgst
Cross-Chain-Infrastruktur entwickelt sich schnell, und das gilt auch für die Nachrichten rund um ihre Sicherheit. Bridge-Audits, Guardian-Rotationen, DVN-Änderungen und Offenlegungen von Exploits manuell zu verfolgen, ist ein aussichtsloses Spiel. Zippfeed zeigt Cross-Chain-Schlagzeilen mit Sentiment-Bewertung, bullish, neutral oder bearish, sowie einer Wichtigkeitseinstufung, damit du erkennen kannst, welche Bridge-Ereignisse die Märkte tatsächlich bewegt haben und welche nur Rauschen waren. Kombiniere das mit der Gewohnheit, jedes Mal zu fragen, welchem Validator-Set du die Nachricht anvertraust, und du bist den meisten Privatanlegern voraus, die Bridges immer noch als routinemäßige Infrastruktur betrachten.
Crypto Rank News
