LayerZero vs. Chainlink CCIP vs. Wormhole: Wie sich die kettenübergreifende Interoperabilität wirklich unterscheidet

Stellen Sie sich eine hypothetische DeFi-Anwendung namens Atlas Treasury vor. Dieses Beispiel ist fiktiv und dient lediglich der Veranschaulichung der Architektur. Atlas verwahrt Sicherheiten auf Ethereum, möchte Strategielogik auf einer anderen Blockchain auslösen und muss gelegentlich eine Token-Repräsentation zusammen mit einer Nachricht übertragen. Die Entwickler ziehen drei weit verbreitete Interoperabilitäts-Stacks in Betracht: LayerZero, Chainlink CCIP und Wormhole.

Auf den ersten Blick scheinen alle drei Protokolle dasselbe Problem zu lösen: den Transfer von Informationen oder Assets von einer Blockchain zur anderen. In der Praxis greift diese Beschreibung jedoch zu kurz. Ein Cross-Chain-Protokoll muss diverse Fragen beantworten: Wer überwacht die Quell-Chain? Welche Nachweise überzeugen die Ziel-Chain von der Gültigkeit einer Nachricht? Wer trägt die Kosten für Zustellung und Ausführung? Wie werden Token-Transfers abgebildet? Welche Konfigurationsmöglichkeiten bietet die Anwendung, und welche Sicherheitsannahmen bleiben bestehen?

Beginnen Sie mit dem Problem, nicht mit dem Protokollnamen.

Für Atlas Treasury ist eine Anforderung wie „Unterstützung mehrerer Blockchains“ nicht präzise genug. Das Team sollte seine Bedürfnisse zunächst in mindestens drei Kategorien unterteilen: beliebige Nachrichtenübermittlung, Token-Transaktionen und Ausführung auf der Ziel-Blockchain.

Beliebige Nachrichtenübermittlung könnte bedeuten, dass ein Ethereum-Smart-Contract die Anweisung sendet: „Aktualisiere das Kreditlimit für Konto X.“ Token-Transaktionen sind anders: Werte müssen kettenübergreifend gesperrt, verbrannt, neu erzeugt, freigegeben oder anderweitig verbucht werden. Die Ausführung fügt eine weitere Ebene hinzu, da die Zieltransaktion Gas, Reihenfolgeregeln, Fehlerbehandlung und eine klare Regel benötigt, wer den empfangenden Smart-Contract aufrufen darf.

Diese Unterscheidung ist wichtig, da LayerZero, Chainlink CCIP und Wormhole nicht einfach austauschbare Brücken sind. Jedes ist ein umfassenderes Interoperabilitätsframework mit einer anderen Verifizierungs- und Bereitstellungsarchitektur.

LayerZero: Anwendungskonfigurierbare Verifizierung und Ausführung

LayerZero V2 organisiert die kettenübergreifende Kommunikation mithilfe unveränderlicher Endpoint-Verträge, die auf unterstützten Blockchains bereitgestellt werden. Eine Anwendung sendet über einen Quell-Endpoint, und der Ziel-Endpoint übermittelt die verifizierte Nachricht schließlich an die empfangende Anwendung. Die offizielle LayerZero V2-Protokollübersicht beschreibt einen Kanal anhand von Sender, Quell-Endpoint-ID, Ziel-Endpoint-ID und Empfänger.

Die besondere Designentscheidung liegt in der Trennung von Verifizierung und Ausführung. LayerZero bezeichnet seine unabhängigen Verifizierungsdienste als Decentralized Verifier Networks (DVNs). Eine Anwendung kann erforderliche und optionale DVNs, einschließlich Schwellenwertregeln, konfigurieren, während Executors die Zustellung an das Ziel übernehmen, nachdem die Nachricht ihre Verifizierungsanforderungen erfüllt hat. Die offizielle Architekturdokumentation beschreibt dies als ein X-von-Y-von-N-Verifizierungsmodell mit austauschbaren Message Libraries, DVNs und Executors.

Wie sich das auf Atlas Treasury auswirken würde

Angenommen, Atlas wünscht sich unterschiedliche Sicherheitsrichtlinien für verschiedene kettenübergreifende Aktionen. Eine Statusaktualisierung mit geringem Wert könnte eine Konfiguration verwenden, während eine Nachricht, die erhebliche Sicherheiten freigeben kann, mehrere unabhängige DVNs erfordern könnte. Diese Flexibilität ist ein zentrales Merkmal von LayerZero: Die Anwendung wählt ihren Sicherheits-Stack selbst, anstatt für jeden Pfad einen universellen Verifizierersatz zu übernehmen.

Flexibilität schafft auch Verantwortung. Die OApp-Dokumentation von LayerZero besagt, dass Produktionsumgebungen mehrere erforderliche DVNs von unabhängigen Betreibern nutzen sollten, da eine Konfiguration mit nur einer DVN den Pfad von einem einzigen Verifizierer abhängig macht. Atlas kann die Protokollintegration daher nicht als einmalige API-Entscheidung behandeln; DVN-Auswahl, Peers, Message Libraries, Executor-Einstellungen, Besitzverhältnisse und Upgrade-Verfahren werden Teil des Sicherheitskonzepts. Die entsprechenden Hinweise finden Sie in der LayerZero OApp-Dokumentation .

Wenn Atlas lediglich den Transfer fungibler Token anstelle beliebiger Geschäftslogik benötigt, bietet LayerZero mit seinem Omnichain Fungible Token-Standard ebenfalls eine Lösung an. Dieser sollte getrennt von einer generischen OApp-Integration evaluiert werden, da Token-Transfer-Semantik und Anwendungsnachrichten nicht dasselbe Problem darstellen.

Chainlink CCIP: DON-basierte Nachrichtenübermittlung mit spurspezifischen Kontrollen

Chainlink CCIP verwendet ein anderes Modell. In CCIP ist eine „Lane“ ein unidirektionaler Pfad von einer Blockchain zu einer anderen. Die umgekehrte Richtung bildet eine separate Lane, deren Eigenschaften sich unterscheiden können. Chainlinks CCIP-Schlüsselkonzepte erklären, dass Finalität wichtig ist, da das Ziel nicht auf ein Quellereignis reagieren sollte, das noch reorganisiert werden könnte.

Wie in der aktuellen CCIP-Architektur v1.6 dokumentiert, verwendet ein Role Decentralized Oracle Network (Role DON) zwei Offchain-Reporting-Plugins. Der Commit-OCR-Prozess erzielt einen Konsens über die Nachrichten der Quellkette und überträgt Merkle-Roots an die Zielkette. Der Executing-OCR-Prozess validiert anschließend die ausstehenden Ausführungen und führt die Nachrichten auf der Zielkette aus. Die offizielle CCIP-Offchain-Architekturseite beschreibt diesen Ablauf detailliert.

Es gibt eine wichtige Änderung in der Dokumentation von 2026, die beim Lesen älterer Materialien leicht übersehen werden kann. Chainlink gibt aktuell an, dass die automatisierte Off-Chain-Funktion des Risk Management Network (RMN) in den derzeitigen CCIP-Implementierungen nicht mehr aktiv ist und voraussichtlich in zukünftigen Versionen als optionale Validierungsebene zurückkehren wird. Der On-Chain-RMN-Vertrag dient weiterhin als Notfallschutz für bestimmte Funktionen, während andere Kontrollmechanismen konfigurierbare Ratenbegrenzungen, Token-Attestierungen und Überwachung umfassen. Jeder Artikel, der das alte Off-Chain-RMN als stets aktives, unabhängiges Validierungsnetzwerk beschreibt, ist daher für aktuelle Implementierungen überholt.

Wie sich das auf Atlas Treasury auswirken würde

Atlas kann CCIP nutzen, um beliebige Daten, Token oder programmierbare Token-Transfers zu senden, abhängig vom unterstützten Quell-Ziel-Paar und der Integration. Anstatt eine eigene DVN-Zusammensetzung zu wählen, integriert sich Atlas primär in die CCIP-Verträge und das Sicherheitsmodell der CCIP-DON-Architektur und führt anschließend Prüfungen auf Anwendungsebene hinsichtlich vertrauenswürdiger Blockchains, Absender, Router und Nachrichtenverarbeitung durch.

Diese Prüfungen sind nicht optional. Die Best-Practice-Dokumentation von Chainlink für CCIP EVM empfiehlt ausdrücklich, Zielketten vor dem Senden zu validieren, Quellketten und Absender beim Empfangen zu validieren, Routeradressen gegebenenfalls zu überprüfen, den Nachrichtenempfang von der Kernlogik zu trennen, unter widrigen Bedingungen zu testen und auf ungewöhnliches Verhalten zu achten.

Für Token-Emittenten bietet CCIP zudem eine Cross-Chain-Token-Infrastruktur auf Basis von Token-Pools und Verwaltungsregeln. Da sich Ratenbegrenzungen für Token-Pools konfigurieren lassen, sollte Atlas die Token-Architektur getrennt von der einfachen Nachrichtenübermittlung bewerten, anstatt anzunehmen, eine Konfiguration sei für beides geeignet.

Wurmloch: Wächterbescheinigungen produzieren tragbare VAAs

Das Messaging-System von Wormhole basiert auf seinem Guardian-Netzwerk und verifizierbaren Aktionsgenehmigungen (VAAs). Ein Quellvertrag sendet eine Nachricht über den Wormhole-Kernvertrag. Die Guardians beobachten und signieren diese Nachricht, und sobald das erforderliche Quorum erreicht ist, kann die resultierende VAA zur Verifizierung an die Ziel-Chain übermittelt werden.

Die aktuelle Wormhole Guardian-Dokumentation beschreibt einen kanonischen Satz von 19 Guardians und eine standardmäßige 13-von-19-Multisignatur-VAA. Auf einigen Chains führt eine delegierte Teilmenge direkte Beobachtungen durch, während die kanonischen Guardians das konfigurierte Delegiertenquorum abwarten, bevor sie dieselbe standardmäßige 13-von-19-VAA erzeugen.

Zustellung und Gültigkeit sind bewusst getrennt. Die Übersicht zum Messaging von Wormhole erklärt, dass eine VAA an den Zielort transportiert und dort verifiziert wird. Das neuere Executor-Framework bietet ein erlaubnisfreies Anfrage-und-Angebot-Modell für die Nachrichtenausführung. Auch die Sicherheitsdokumentation macht eine wichtige Unterscheidung: Ein Relayer kann zwar die Verfügbarkeit oder das Timing beeinflussen, aber keine VAA fälschen, da die Gültigkeit durch die Guardian-Signaturen sichergestellt wird.

Wie sich das auf Atlas Treasury auswirken würde

Atlas könnte eine Ethereum-Nachricht senden, auf die Bestätigung durch Guardian warten und anschließend einen Relayer oder Executor beauftragen, die VAA an den Zielvertrag zu übermitteln. Der Empfänger müsste die Herkunft der Nachricht validieren und eine replay-sichere Anwendungslogik implementieren. Benötigt Atlas Token anstelle von Nachrichten, unterscheidet Wormhole zwischen Native Token Transfers (NTT) und Wrapped Token Transfers (WTT). Die offizielle Übersicht zu Token-Transfers erklärt, dass NTT und WTT zwar die Guardian-Messaging-Schicht gemeinsam nutzen, sich aber in der Darstellung und Ausgabe bzw. Prägung von Token unterscheiden.

Die Unterstützung von Wormhole variiert je nach Produkt und kann sich ändern. Die Dokumentation zu den unterstützten Netzwerken ist daher verlässlicher als die Annahme, dass jedes Wormhole-Produkt auf jeder mit Wormhole verbundenen Blockchain funktioniert. Im August 2026 kündigte Wormhole zudem die Abschaffung weiterer Netzwerke an, was die Notwendigkeit unterstreicht, die aktuelle Unterstützung zu prüfen, bevor man sich für eine Route entscheidet.

LayerZero vs. CCIP vs. Wormhole: die praktischen Unterschiede

Diese Tabelle vergleicht die Architekturen der Protokolle, stellt aber keine Sicherheitsrangliste dar. Die Protokolle bieten unterschiedliche Konfigurationsmöglichkeiten, verwenden verschiedene Verifizierungsannahmen und entwickeln sich unterschiedlich schnell weiter. Ein Protokoll mit mehr Konfigurationsmöglichkeiten ist nicht automatisch sicherer, und ein Protokoll mit einem stärker auf bestimmte Verifizierungsmethoden ausgerichteten Protokoll ist nicht automatisch weniger flexibel. Die entscheidende Frage ist, ob das Sicherheitsmodell zur autorisierten Aktion passt.

Was das Atlas-Beispiel über das tatsächliche Integrationsrisiko aussagt

1. Die Cross-Chain-Sicherheit umfasst beide Ketten

Wenn Ethereum die Transaktion korrekt abschließt, die Zielkette jedoch anhält, sich reorganisiert oder unerwartet reagiert, liegt bei Atlas dennoch ein Cross-Chain-Vorfall vor. Jedes Protokoll hängt letztendlich von den Eigenschaften der verbundenen Netzwerke ab. Chainlink empfiehlt Entwicklern ausdrücklich, die Sicherheit und Zuverlässigkeit der verwendeten Netzwerke zu überprüfen. Dasselbe Prinzip gilt für die Integrationen von LayerZero und Wormhole.

2. Eine gültige Nachricht kann dennoch unsichere Anwendungslogik auslösen.

Interoperabilitätsprotokolle beweisen oder bestätigen, dass eine Nachricht den erwarteten Weg genommen hat. Sie gewährleisten jedoch nicht automatisch die Korrektheit der Geschäftslogik von Atlas. Eine an sich gültige Cross-Chain-Anweisung kann dennoch einen Fehler im empfangenden Smart Contract ausnutzen, wenn Atlas den Absender, den Zielkontext, den Betrag, die Nonce, den Replay-Status oder die zulässige Aktion nicht verifiziert.

3. Token-Bewegungen erfordern ein separates Bedrohungsmodell

Eine Meldung wie „Alice besitzt 100 Einheiten“ ist nicht dasselbe wie die Übertragung von 100 wirtschaftlich relevanten Token. Atlas sollte dokumentieren, ob das Cross-Chain-Asset verbrannt und neu geprägt, gesperrt und freigegeben, treuhänderisch verwahrt, verpackt oder nativ vom Emittenten kontrolliert wird. Außerdem sollte es offenlegen, wer die Prägeberechtigung besitzt, wer die Ratenbegrenzungen kontrolliert, wie Notfallpausen funktionieren und was passiert, wenn eine Seite der Route ausfällt.

4. Ein Lieferausfall sollte nicht zu einem Buchhaltungsausfall führen.

Cross-Chain-Systeme arbeiten asynchron. Lastspitzen, Kettenüberlastung, Verzögerungen bei der Finalisierung, Probleme mit Relayern oder Rücksetzungen am Zielsystem können die Fertigstellung verzögern. Atlas sollte die Zustände „gesendet“, „verifiziert“, „zugestellt“ und „Geschäftslogik abgeschlossen“ als separate Status modellieren, anstatt eine Quellkettentransaktion als endgültigen Beweis für den Erfolg der Zielaktion zu behandeln.

Wie ein Team zwischen ihnen auswählen sollte

Atlas sollte die Auswahl eines Protokolls anhand einer Checkliste mit markenspezifischen Funktionen vermeiden. Ein besseres Vorgehen besteht darin, jeden Kandidaten hinsichtlich des exakten Nachrichtenwegs und der möglichen Fehlermodi zu testen.

• Wählen Sie die genauen Quell- und Zielnetzwerke aus. Überprüfen Sie die aktuelle Unterstützung im offiziellen Verzeichnis des Protokolls, anstatt von einer Kompatibilität im gesamten Ökosystem auszugehen.
• Definiere, was die Grenze überschreitet. Sendet Atlas beliebige Bytes, ein Token, ein Token plus Anweisungen, Governance-Aktionen oder Zustandssynchronisierung?
• Notieren Sie die Verifizierungsannahme. Für LayerZero umfasst diese die gewählten DVNs und den Schwellenwert. Für CCIP umfasst sie die aktuelle DON-Architektur und das Lane-Verhalten. Für Wormhole umfasst sie das Guardian-Quorum und alle für die Kette relevanten delegierten Beobachtungskonfigurationen.
• Modellieren Sie die Zielausführung separat. Legen Sie fest, wer die Zustellung übernehmen kann, was bei einer Verzögerung passiert, wie die Gaskosten gedeckt werden und ob Nachrichten in einer bestimmten Reihenfolge verarbeitet werden müssen.
• Überprüfen Sie die Autorisierung auf Anwendungsebene. Beschränken Sie Quellketten, Senderverträge, Empfängerverträge, privilegierte Rollen und die Tokenverwaltung.
• Planen Sie betriebliche Änderungen ein. Netzwerkunterstützung, Protokollversionen, Servicebeschränkungen und empfohlene Konfigurationen können sich ändern. Die Produktionsüberwachung sollte daher Dokumentationsaktualisierungen und -abkündigungen als betriebliche Ereignisse behandeln.

Ein letzter Selbstcheck für die hypothetische Atlas-Schatzkammer

Bevor Atlas vom Testnetz in den realen Einsatz übergeht, sollte das Team die folgenden Fragen beantworten können, ohne auf Marketingfloskeln zurückzugreifen:

• Welche genauen Quell-Ziel-Routen werden heute unterstützt?
• Wer oder was verifiziert ein Quellkettenereignis für jede Route?
• Welche Schwelle oder Konsensregel macht die Botschaft akzeptabel?
• Wer kann die Zieltransaktion durchführen oder abschließen?
• Kann ein Zustelldienst eine Nachricht zensieren oder verzögern, und kann er sie fälschen?
• Welche Prüfungen auf Zielseite weisen eine unerwartete Kette, einen unerwarteten Absender, ein unerwartetes Token oder eine unerwartete Aktion zurück?
• Wie werden Wiederholungsversuche, Duplikate, Ausführung in falscher Reihenfolge und Zielumkehrungen behandelt?
• Wenn Token bewegt werden, welche Annahmen gelten für Prägung, Verbrennung, Sperrung, Freigabe, Ratenbegrenzung und Administration?
• Welche Notfallmaßnahmen stehen zur Verfügung und wer ist für deren Durchführung zuständig?
• Wie wird das Team Änderungen in den unterstützten Netzwerken oder der Protokollkonfiguration erkennen?

Kann Atlas diese Fragen nicht beantworten, hat es Interoperabilitätsprotokolle noch nicht auf der relevanten Ebene verglichen. LayerZero, Chainlink CCIP und Wormhole bieten zwar ausgereifte Methoden zur Koordination von Aktivitäten über Blockchains hinweg, verteilen jedoch Verifizierung, Zustellung, Konfiguration und operative Verantwortung unterschiedlich. Die praktische Entscheidung lautet daher nicht: „Welches Cross-Chain-Protokoll ist das beste?“, sondern: „Welches Sicherheits- und Ausführungsmodell passt am besten zu der Cross-Chain-Aktion, die diese Anwendung autorisieren möchte?“