Zum Hauptinhalt springen

Cross-Chain-Messaging und geteilte Liquidität: Sicherheitsmodelle von LayerZero v2, Hyperlane und IBC 3.0

· 51 Minuten Lesezeit
Dora Noda
Dora Noda
Software Engineer

Interoperabilitätsprotokolle wie LayerZero v2, Hyperlane und IBC 3.0 entwickeln sich zu kritischer Infrastruktur für ein Multi-Chain-DeFi-Ökosystem. Jedes verfolgt einen anderen Ansatz für Cross-Chain-Messaging und geteilte Liquidität, mit unterschiedlichen Sicherheitsmodellen:

  • LayerZero v2 – ein Proof-Aggregationsmodell unter Verwendung von Decentralized Verifier Networks (DVNs)
  • Hyperlane – ein modulares Framework, das oft ein Multisig-Validator-Komitee verwendet
  • IBC 3.0 – ein Light-Client-Protokoll mit vertrauensminimierten Relayern im Cosmos-Ökosystem

Dieser Bericht analysiert die Sicherheitsmechanismen jedes Protokolls, vergleicht die Vor- und Nachteile von Light Clients vs. Multisigs vs. Proof-Aggregation und untersucht deren Auswirkungen auf DeFi-Komponierbarkeit und Liquidität. Wir überprüfen auch aktuelle Implementierungen, Bedrohungsmodelle und Adoptionsraten und schließen mit einem Ausblick darauf, wie diese Designentscheidungen die langfristige Lebensfähigkeit von Multi-Chain-DeFi beeinflussen.

Sicherheitsmechanismen führender Cross-Chain-Protokolle​

LayerZero v2: Proof-Aggregation mit Decentralized Verifier Networks (DVNs)​

LayerZero v2 ist ein Omnichain-Messaging-Protokoll, das eine modulare, anwendungs konfigurierbare Sicherheitsebene betont. Die Kernidee ist, Anwendungen die Möglichkeit zu geben, Nachrichten mit einem oder mehreren unabhängigen Decentralized Verifier Networks (DVNs) zu sichern, die gemeinsam Cross-Chain-Nachrichten bestätigen. Im Proof-Aggregationsmodell von LayerZero ist jedes DVN im Wesentlichen eine Reihe von Verifizierern, die eine Nachricht unabhängig validieren können (z. B. durch Überprüfung eines Block-Proofs oder einer Signatur). Eine Anwendung kann aggregierte Proofs von mehreren DVNs verlangen, bevor sie eine Nachricht akzeptiert, wodurch ein Schwellenwert-„Sicherheits-Stack“ gebildet wird.

Standardmäßig bietet LayerZero einige DVNs sofort einsatzbereit an – zum Beispiel ein von LayerZero Labs betriebenes DVN, das eine 2-von-3-Multisig-Validierung verwendet, und ein von Google Cloud betriebenes DVN. Entscheidend ist jedoch, dass Entwickler DVNs kombinieren können: z. B. könnte eine „1 von 3 von 5“-Konfiguration bedeuten, dass ein bestimmtes DVN signieren muss, plus 2 von 5 anderen. Diese Flexibilität ermöglicht die Kombination verschiedener Verifizierungsmethoden (Light Clients, zkProofs, Oracles usw.) in einem aggregierten Proof. Im Grunde verallgemeinert LayerZero v2 das Ultra-Light-Node-Modell von v1 (das auf einem Relayer + einem Oracle basierte) zu einer X-von-Y-von-N-Multisig-Aggregation über DVNs. Der LayerZero Endpoint-Vertrag einer Anwendung auf jeder Chain liefert eine Nachricht nur dann aus, wenn das erforderliche DVN-Quorum gültige Bestätigungen für diese Nachricht geschrieben hat.

Sicherheitsmerkmale: Der Ansatz von LayerZero ist in dem Maße vertrauensminimiert, als mindestens ein DVN im erforderlichen Satz ehrlich ist (oder ein zk-Proof gültig ist usw.). Indem LayerZero Anwendungen erlaubt, ihr eigenes DVN als erforderlichen Signierer zu betreiben, ermöglicht es sogar, dass eine App jede Nachricht veto einlegt, es sei denn, sie wird vom Verifizierer des App-Teams genehmigt. Dies kann die Sicherheit erheblich erhöhen (auf Kosten der Zentralisierung), indem sichergestellt wird, dass keine Cross-Chain-Nachricht ohne die Signatur der App ausgeführt wird. Andererseits können Entwickler ein dezentraleres DVN-Quorum (z. B. 5 von 15 unabhängigen Netzwerken) für eine stärkere Vertrauensverteilung wählen. LayerZero nennt dies „anwendungseigene Sicherheit“: Jede App wählt den Kompromiss zwischen Sicherheit, Kosten und Leistung, indem sie ihre DVNs konfiguriert. Alle DVN-Bestätigungen werden letztendlich On-Chain von unveränderlichen LayerZero Endpoint-Verträgen verifiziert, wodurch eine genehmigungslose Transportschicht erhalten bleibt. Der Nachteil ist, dass die Sicherheit nur so stark ist wie die gewählten DVNs – wenn die konfigurierten DVNs kolludieren oder kompromittiert werden, könnten sie eine betrügerische Cross-Chain-Nachricht genehmigen. Daher liegt die Last bei jeder Anwendung, robuste DVNs auszuwählen oder ein höheres Sicherheitsrisiko einzugehen.

Hyperlane: Multisig-Validator-Modell mit modularen ISMs​

Hyperlane ist ein Interoperabilitäts-Framework, das sich auf ein On-Chain-Interchain Security Module (ISM) konzentriert, das Nachrichten verifiziert, bevor sie auf der Ziel-Chain zugestellt werden. In der einfachsten (und standardmäßigen) Konfiguration verwendet Hyperlanes ISM einen Multisignatur-Validator-Satz: Ein Komitee von Off-Chain-Validatoren signiert Bestätigungen (oft einen Merkle-Root aller ausgehenden Nachrichten) von der Quell-Chain, und ein Schwellenwert von Signaturen ist am Ziel erforderlich. Mit anderen Worten, Hyperlane verlässt sich auf ein genehmigtes Validator-Quorum, um zu bestätigen, dass „Nachricht X tatsächlich auf Chain A gesendet wurde“, analog zum Konsens einer Blockchain, aber auf Brücken-Ebene. Zum Beispiel verwendet Wormhole 19 Guardians mit einer 13-von-19-Multisig – Hyperlanes Ansatz ist im Geiste ähnlich (obwohl Hyperlane sich von Wormhole unterscheidet).

Ein Hauptmerkmal ist, dass Hyperlane keinen einzigen festgeschriebenen Validator-Satz auf Protokollebene hat. Stattdessen kann jeder einen Validator betreiben, und verschiedene Anwendungen können ISM-Verträge mit unterschiedlichen Validator-Listen und Schwellenwerten bereitstellen. Das Hyperlane-Protokoll bietet Standard-ISM-Bereitstellungen (mit einem Satz von Validatoren, die das Team bootstrapped hat), aber Entwickler können den Validator-Satz oder sogar das Sicherheitsmodell für ihre App frei anpassen. Tatsächlich unterstützt Hyperlane mehrere Arten von ISMs, einschließlich eines Aggregation ISM, das mehrere Verifizierungsmethoden kombiniert, und eines Routing ISM, das ein ISM basierend auf Nachrichtenparametern auswählt. Zum Beispiel könnte eine App sowohl eine Hyperlane-Multisig als auch eine externe Brücke (wie Wormhole oder Axelar) verlangen, um zu signieren – wodurch eine höhere Sicherheitsstufe durch Redundanz erreicht wird.

Sicherheitsmerkmale: Die grundlegende Sicherheit von Hyperlanes Multisig-Modell beruht auf der Ehrlichkeit einer Mehrheit seiner Validatoren. Wenn der Schwellenwert (z. B. 5 von 8) der Validatoren kolludieren, könnten sie eine betrügerische Nachricht signieren, sodass die Vertrauensannahme ungefähr N-von-M-Multisig-Vertrauen ist. Hyperlane begegnet diesem Risiko durch die Integration mit EigenLayer Restaking, wodurch ein Economic Security Module (ESM) geschaffen wird, das Validatoren dazu verpflichtet, gestaktes ETH zu hinterlegen, das bei Fehlverhalten geslasht werden kann. Dieser „Actively Validated Service (AVS)“ bedeutet, dass, wenn ein Hyperlane-Validator eine ungültige Nachricht signiert (eine, die nicht tatsächlich in der Historie der Quell-Chain enthalten ist), jeder einen Proof auf Ethereum vorlegen kann, um den Stake dieses Validators zu slashen. Dies stärkt das Sicherheitsmodell erheblich, indem Betrug wirtschaftlich unattraktiv gemacht wird – Hyperlanes Cross-Chain-Nachrichten werden durch das wirtschaftliche Gewicht von Ethereum gesichert, nicht nur durch den sozialen Ruf der Validatoren. Ein Kompromiss ist jedoch, dass die Abhängigkeit von Ethereum für das Slashing eine Abhängigkeit von Ethereums Liveness einführt und davon ausgeht, dass Betrugs-Proofs rechtzeitig eingereicht werden können. In Bezug auf die Liveness warnt Hyperlane, dass die Nachrichtenzustellung zum Erliegen kommen kann, wenn nicht genügend Validatoren online sind, um den Schwellenwert zu erreichen. Das Protokoll mindert dies, indem es eine flexible Schwellenwertkonfiguration ermöglicht – z. B. die Verwendung eines größeren Validator-Satzes, damit gelegentliche Ausfallzeiten das Netzwerk nicht zum Stillstand bringen. Insgesamt bietet Hyperlanes modulares Multisig-Ansatz Flexibilität und Upgradefähigkeit (Apps wählen ihre eigene Sicherheit oder kombinieren mehrere Quellen) auf Kosten des zusätzlichen Vertrauens in einen Validator-Satz. Dies ist ein schwächeres Vertrauensmodell als ein echter Light Client, aber mit jüngsten Innovationen (wie Restaked Collateral und Slashing) kann es in der Praxis ähnliche Sicherheitsgarantien erreichen, während es einfacher über viele Chains hinweg bereitgestellt werden kann.

IBC 3.0: Light Clients mit vertrauensminimierten Relayern​

Das Inter-Blockchain Communication (IBC)-Protokoll, das im Cosmos-Ökosystem weit verbreitet ist, verfolgt einen grundlegend anderen Ansatz: Es verwendet On-Chain-Light Clients, um Cross-Chain-Zustände zu verifizieren, anstatt einen neuen Validator-Satz einzuführen. In IBC stellt jedes Chain-Paar eine Verbindung her, bei der Chain B einen Light Client von Chain A (und umgekehrt) hält. Dieser Light Client ist im Wesentlichen eine vereinfachte Replik des Konsenses der anderen Chain (z. B. Verfolgung von Validator-Satz-Signaturen oder Block-Hashes). Wenn Chain A eine Nachricht (ein IBC-Paket) an Chain B sendet, übermittelt ein Relayer (ein Off-Chain-Akteur) einen Proof (Merkle-Proof des Pakets und des neuesten Block-Headers) an Chain B. Das IBC-Modul von Chain B verwendet dann den On-Chain-Light Client, um zu verifizieren, dass der Proof gemäß den Konsensregeln von Chain A gültig ist. Wenn der Proof stimmt (d. h. das Paket wurde in einem finalisierten Block auf A committet), wird die Nachricht akzeptiert und an das Zielmodul auf B zugestellt. Im Wesentlichen vertraut Chain B direkt dem Konsens von Chain A, nicht einem Vermittler – deshalb wird IBC oft als vertrauensminimierte Interoperabilität bezeichnet.

IBC 3.0 bezieht sich auf die neueste Entwicklung dieses Protokolls (ca. 2025), die Leistungs- und Funktionsverbesserungen einführt: paralleles Relaying für geringere Latenz, benutzerdefinierte Kanaltypen für spezialisierte Anwendungsfälle und Interchain Queries zum Lesen von Remote-Zuständen. Bemerkenswerterweise ändert keiner davon das Kern-Light-Client-Sicherheitsmodell – sie verbessern Geschwindigkeit und Funktionalität. Zum Beispiel bedeutet paralleles Relaying, dass mehrere Relayer Pakete gleichzeitig transportieren können, um Engpässe zu vermeiden, was die Liveness verbessert, ohne die Sicherheit zu opfern. Interchain Queries (ICQ) ermöglichen es einem Vertrag auf Chain A, Chain B um Daten zu bitten (mit einem Proof), die dann vom Light Client von A für B verifiziert werden. Dies erweitert die Fähigkeiten von IBC über Token-Transfers hinaus auf einen allgemeineren Cross-Chain-Datenzugriff, der immer noch durch verifizierte Light-Client-Proofs untermauert wird.

Sicherheitsmerkmale: Die Sicherheitsgarantie von IBC ist so stark wie die Integrität der Quell-Chain. Wenn Chain A eine ehrliche Mehrheit (oder den konfigurierten Konsens-Schwellenwert) hat und der Light Client von Chain B für A aktuell ist, dann muss jedes akzeptierte Paket von einem gültigen Block auf A stammen. Es ist nicht notwendig, Brücken-Validatoren oder Oracles zu vertrauen – die einzigen Vertrauensannahmen sind der native Konsens der beiden Chains und einige Parameter wie die Vertrauensperiode des Light Clients (nach der alte Header ablaufen). Relayer in IBC müssen nicht vertraut werden; sie können keine gültigen Header oder Pakete fälschen, da diese die Verifizierung nicht bestehen würden. Im schlimmsten Fall kann ein bösartiger oder Offline-Relayer Nachrichten zensieren oder verzögern, aber jeder kann einen Relayer betreiben, sodass die Liveness schließlich erreicht wird, wenn mindestens ein ehrlicher Relayer existiert. Dies ist ein sehr starkes Sicherheitsmodell: effektiv standardmäßig dezentralisiert und genehmigungslos, was die Eigenschaften der Chains selbst widerspiegelt. Die Kompromisse liegen in Kosten und Komplexität – das Betreiben eines Light Clients (insbesondere einer High-Throughput-Chain) auf einer anderen Chain kann ressourcenintensiv sein (Speichern von Validator-Satz-Änderungen, Verifizieren von Signaturen usw.). Für Cosmos SDK-Chains, die Tendermint/BFT verwenden, sind diese Kosten überschaubar und IBC ist sehr effizient; aber die Integration heterogener Chains (wie Ethereum oder Solana) erfordert komplexe Client-Implementierungen oder neue Kryptographie. Tatsächlich war die Überbrückung von Nicht-Cosmos-Chains über IBC langsamer – Projekte wie Polymer und Composable arbeiten an Light Clients oder zk-Proofs, um IBC auf Ethereum und andere auszudehnen. Die Verbesserungen von IBC 3.0 (z. B. optimierte Light Clients, Unterstützung für verschiedene Verifizierungsmethoden) zielen darauf ab, diese Kosten zu senken. Zusammenfassend bietet das Light-Client-Modell von IBC die stärksten Vertrauensgarantien (überhaupt keine externen Validatoren) und eine solide Liveness (angesichts mehrerer Relayer), auf Kosten einer höheren Implementierungskomplexität und Einschränkungen, dass alle teilnehmenden Chains das IBC-Protokoll unterstützen müssen.

Vergleich von Light Clients, Multisigs und Proof-Aggregation​

Jedes Sicherheitsmodell – Light Clients (IBC), Validator-Multisigs (Hyperlane) und aggregierte Proofs (LayerZero) – hat unterschiedliche Vor- und Nachteile. Im Folgenden vergleichen wir sie anhand wichtiger Dimensionen:

Sicherheitsgarantien​

  • Light Clients (IBC): Bietet höchste Sicherheit, indem die On-Chain-Verifizierung an den Konsens der Quell-Chain gebunden wird. Es gibt keine neue Vertrauensebene; wenn Sie der Quell-Blockchain (z. B. Cosmos Hub oder Ethereum) vertrauen, keine Blöcke doppelt zu produzieren, vertrauen Sie den Nachrichten, die sie sendet. Dies minimiert zusätzliche Vertrauensannahmen und Angriffsflächen. Wenn jedoch der Validator-Satz der Quell-Chain korrumpiert ist (z. B. >⅓ in Tendermint oder >½ in einer PoS-Chain werden bösartig), kann der Light Client mit einem betrügerischen Header gefüttert werden. In der Praxis werden IBC-Kanäle normalerweise zwischen wirtschaftlich sicheren Chains eingerichtet, und Light Clients können Parameter (wie Vertrauensperiode und Blockfinalitätsanforderungen) haben, um Risiken zu mindern. Insgesamt ist die Vertrauensminimierung der stärkste Vorteil des Light-Client-Modells – es gibt einen kryptographischen Proof der Gültigkeit für jede Nachricht.

  • Multisig-Validatoren (Hyperlane & ähnliche Brücken): Die Sicherheit hängt von der Ehrlichkeit einer Reihe von Off-Chain-Signierern ab. Ein typischer Schwellenwert (z. B. ⅔ der Validatoren) muss jede Cross-Chain-Nachricht oder jeden Status-Checkpoint abzeichnen. Der Vorteil ist, dass dies mit ausreichend seriösen oder wirtschaftlich gestakten Validatoren angemessen sicher gemacht werden kann. Zum Beispiel müssen Wormholes 19 Guardians oder Hyperlanes Standardkomitee kollektiv kolludieren, um das System zu kompromittieren. Der Nachteil ist, dass dies eine neue Vertrauensannahme einführt: Benutzer müssen dem Komitee der Brücke zusätzlich zu den Chains vertrauen. Dies hat sich bei einigen Hacks als Schwachstelle erwiesen (z. B. wenn private Schlüssel gestohlen werden oder wenn Insider kolludieren). Initiativen wie Hyperlanes Restaked-ETH-Collateral fügen diesem Modell wirtschaftliche Sicherheit hinzu – Validatoren, die ungültige Daten signieren, können automatisch auf Ethereum geslasht werden. Dies rückt Multisig-Brücken näher an die Sicherheit einer Blockchain heran (durch finanzielle Bestrafung von Betrug), ist aber immer noch nicht so vertrauensminimiert wie ein Light Client. Kurz gesagt, Multisigs sind schwächer in Bezug auf Vertrauensgarantien: Man verlässt sich auf eine Mehrheit einer kleinen Gruppe, obwohl Slashing und Audits das Vertrauen stärken können.

  • Proof-Aggregation (LayerZero v2): Dies ist gewissermaßen ein Mittelweg. Wenn eine Anwendung ihren Security Stack so konfiguriert, dass er einen Light-Client-DVN oder einen zk-Proof-DVN enthält, kann die Garantie für diese Prüfungen das IBC-Niveau erreichen (Mathematik und Chain-Konsens). Wenn sie ein komitee-basiertes DVN verwendet (wie LayerZeros 2-von-3-Standard oder einen Axelar-Adapter), erbt sie die Vertrauensannahmen dieses Multisigs. Die Stärke von LayerZeros Modell ist, dass Sie mehrere Verifizierer unabhängig kombinieren können. Zum Beispiel könnte die Anforderung, dass sowohl „ein zk-Proof gültig ist“ als auch „Chainlink Oracle sagt, der Block-Header ist X“ als auch „unser eigener Validator signiert ab“, die Angriffsmöglichkeiten dramatisch reduzieren (ein Angreifer müsste alle auf einmal brechen). Indem LayerZero einer App erlaubt, ihr eigenes DVN vorzuschreiben, stellt es außerdem sicher, dass keine Nachricht ohne die Zustimmung der App ausgeführt wird, wenn dies so konfiguriert ist. Die Schwäche ist, dass, wenn Entwickler eine laxe Sicherheitskonfiguration wählen (für günstigere Gebühren oder Geschwindigkeit), sie die Sicherheit untergraben könnten – z. B. die Verwendung eines einzelnen DVNs, das von einer unbekannten Partei betrieben wird, wäre ähnlich wie das Vertrauen in einen einzelnen Validator. LayerZero selbst ist meinungsunabhängig und überlässt diese Entscheidungen den App-Entwicklern, was bedeutet, dass die Sicherheit nur so gut ist wie die gewählten DVNs. Zusammenfassend kann Proof-Aggregation sehr starke Sicherheit bieten (sogar höher als ein einzelner Light Client, indem mehrere unabhängige Proofs erforderlich sind), ermöglicht aber auch schwache Setups, wenn falsch konfiguriert. Es ist flexibel: Eine App kann die Sicherheit für hochwertige Transaktionen erhöhen (z. B. mehrere große DVNs erfordern) und für geringwertige Transaktionen reduzieren.

Liveness und Verfügbarkeit​

  • Light Clients (IBC): Die Liveness hängt von Relayern und der Aktualisierung des Light Clients ab. Positiv ist, dass jeder einen Relayer betreiben kann, sodass das System nicht von einem bestimmten Satz von Nodes abhängt – wenn ein Relayer stoppt, kann ein anderer die Arbeit übernehmen. IBC 3.0s paralleles Relaying verbessert die Verfügbarkeit weiter, indem nicht alle Pakete über einen Pfad serialisiert werden. In der Praxis waren IBC-Verbindungen sehr zuverlässig, aber es gibt Szenarien, in denen die Liveness leiden kann: z. B. wenn kein Relayer lange Zeit ein Update postet, könnte ein Light Client ablaufen (z. B. wenn die Vertrauensperiode ohne Verlängerung abläuft) und dann der Kanal aus Sicherheitsgründen geschlossen werden. Solche Fälle sind jedoch selten und werden durch aktive Relayer-Netzwerke gemindert. Eine weitere Liveness-Überlegung: IBC-Pakete unterliegen der Finalität der Quell-Chain – z. B. das Warten von 1-2 Blöcken in Tendermint (einige Sekunden) ist Standard. Insgesamt bietet IBC hohe Verfügbarkeit, solange mindestens ein aktiver Relayer vorhanden ist, und die Latenz ist typischerweise gering (Sekunden) für finalisierte Blöcke. Es gibt kein Konzept eines Quorums von Validatoren, die offline gehen, wie bei Multisig; die Finalität des Konsenses der Blockchain selbst ist der Hauptlatenzfaktor.

  • Multisig-Validatoren (Hyperlane): Die Liveness kann eine Schwäche sein, wenn der Validator-Satz klein ist. Wenn zum Beispiel eine Brücke eine 5-von-8-Multisig hat und 4 Validatoren offline oder unerreichbar sind, stoppt das Cross-Chain-Messaging, weil der Schwellenwert nicht erreicht werden kann. Die Hyperlane-Dokumentation weist darauf hin, dass die Ausfallzeit von Validatoren die Nachrichtenzustellung stoppen kann, abhängig vom konfigurierten Schwellenwert. Dies ist teilweise der Grund, warum ein größeres Komitee oder ein niedrigerer Schwellenwert (mit Sicherheitskompromiss) gewählt werden könnte, um die Betriebszeit zu verbessern. Hyperlanes Design ermöglicht die Bereitstellung neuer Validatoren oder den Wechsel des ISM bei Bedarf, aber solche Änderungen könnten Koordination/Governance erfordern. Der Vorteil von Multisig-Brücken ist typischerweise eine schnelle Bestätigung, sobald Schwellenwert-Signaturen gesammelt wurden – es muss nicht auf die Blockfinalität einer Quell-Chain auf der Ziel-Chain gewartet werden, da die Multisig-Bestätigung die Finalität ist. In der Praxis signieren und relayen viele Multisig-Brücken Nachrichten innerhalb von Sekunden. Die Latenz kann also für einige Chains vergleichbar oder sogar geringer sein als bei Light Clients. Der Engpass ist, wenn Validatoren langsam oder geografisch verteilt sind oder wenn manuelle Schritte erforderlich sind. Zusammenfassend können Multisig-Modelle meistens sehr live und latenzarm sein, aber sie haben ein Liveness-Risiko, das sich im Validator-Satz konzentriert – wenn zu viele Validatoren abstürzen oder eine Netzwerkpartition unter ihnen auftritt, ist die Brücke effektiv ausgefallen.

  • Proof-Aggregation (LayerZero): Die Liveness hängt hier von der Verfügbarkeit jedes DVN und des Relayers ab. Eine Nachricht muss Signaturen/Proofs von den erforderlichen DVNs sammeln und dann an die Ziel-Chain weitergeleitet werden. Der schöne Aspekt ist, dass DVNs unabhängig voneinander arbeiten – wenn ein DVN (aus einem Satz) ausgefallen ist und nicht erforderlich ist (nur Teil eines „M von N“), kann die Nachricht trotzdem fortgesetzt werden, solange der Schwellenwert erreicht ist. LayerZeros Modell erlaubt explizit die Konfiguration von Quoren, um einige DVN-Ausfälle zu tolerieren. Zum Beispiel kann ein „2 von 5“-DVN-Satz 3 DVNs, die offline sind, handhaben, ohne das Protokoll zu stoppen. Da außerdem jeder die endgültige Executor/Relayer-Rolle übernehmen kann, gibt es keinen Single Point of Failure für die Nachrichtenzustellung – wenn der primäre Relayer ausfällt, kann ein Benutzer oder eine andere Partei den Vertrag mit den Proofs aufrufen (dies ist analog zum genehmigungslosen Relayer-Konzept in IBC). Somit strebt LayerZero v2 Zensurresistenz und Liveness an, indem es das System nicht an einen Mittelsmann bindet. Wenn jedoch erforderliche DVNs Teil des Sicherheits-Stacks sind (z. B. eine App verlangt, dass ihr eigenes DVN immer signiert), dann ist dieses DVN eine Liveness-Abhängigkeit: Wenn es offline geht, pausieren Nachrichten, bis es wieder online ist oder die Sicherheitsrichtlinie geändert wird. Im Allgemeinen kann Proof-Aggregation so konfiguriert werden, dass sie robust ist (mit redundanten DVNs und Relaying durch jede Partei), sodass es unwahrscheinlich ist, dass alle Verifizierer gleichzeitig ausfallen. Der Kompromiss ist, dass die Kontaktaufnahme mit mehreren DVNs etwas mehr Latenz verursachen könnte (z. B. Warten auf mehrere Signaturen) im Vergleich zu einem einzelnen schnelleren Multisig. Aber diese DVNs könnten parallel laufen, und viele DVNs (wie ein Oracle-Netzwerk oder ein Light Client) können schnell reagieren. Daher kann LayerZero hohe Liveness und geringe Latenz erreichen, aber die genaue Leistung hängt davon ab, wie die DVNs eingerichtet sind (einige könnten auf einige Blockbestätigungen auf der Quell-Chain warten usw., was aus Sicherheitsgründen zu Verzögerungen führen könnte).

Kosten und Komplexität​

  • Light Clients (IBC): Dieser Ansatz ist tendenziell komplex in der Implementierung, aber günstig in der Nutzung, sobald er auf kompatiblen Chains eingerichtet ist. Die Komplexität liegt in der korrekten Implementierung eines Light Clients für jeden Blockchain-Typ – im Wesentlichen kodieren Sie die Konsensregeln von Chain A in einen Smart Contract auf Chain B. Für Cosmos SDK-Chains mit ähnlichem Konsens war dies unkompliziert, aber die Erweiterung von IBC über Cosmos hinaus erforderte umfangreiche Ingenieursarbeit (z. B. den Bau eines Light Clients für Polkadots GRANDPA-Finalität oder Pläne für Ethereum Light Clients mit zk-Proofs). Diese Implementierungen sind nicht trivial und müssen hochsicher sein. Es gibt auch einen On-Chain-Speicher-Overhead: Der Light Client muss aktuelle Validator-Satz- oder State-Root-Informationen für die andere Chain speichern. Dies kann die State-Größe und die Kosten für die Proof-Verifizierung On-Chain erhöhen. Infolgedessen wäre das direkte Ausführen von IBC auf, sagen wir, Ethereum Mainnet (Verifizieren von Cosmos-Headern) gasmäßig teuer – ein Grund, warum Projekte wie Polymer ein Ethereum-Rollup erstellen, um diese Light Clients Off-Mainnet zu hosten. Innerhalb des Cosmos-Ökosystems sind IBC-Transaktionen sehr effizient (oft nur wenige Cent Gas), da die Light-Client-Verifizierung (ed25519-Signaturen, Merkle-Proofs) auf Protokollebene gut optimiert ist. Die Nutzung von IBC ist für Benutzer relativ kostengünstig, und Relayer zahlen nur normale Transaktionsgebühren auf Ziel-Chains (sie können über ICS-29-Middleware mit Gebühren incentiviert werden). Zusammenfassend sind die Kosten von IBC in der Entwicklungskomplexität vorab investiert, aber einmal in Betrieb, bietet es einen nativen, gebühreneffizienten Transport. Die vielen verbundenen Cosmos-Chains (über 100 Zonen) teilen eine gemeinsame Implementierung, was hilft, die Komplexität durch Standardisierung zu verwalten.

  • Multisig-Brücken (Hyperlane/Wormhole/etc.): Die Implementierungskomplexität ist hier oft geringer – die Kern-Brückenverträge müssen hauptsächlich eine Reihe von Signaturen gegen gespeicherte öffentliche Schlüssel verifizieren. Diese Logik ist einfacher als ein vollständiger Light Client. Die Off-Chain-Validator-Software führt zwar operationelle Komplexität ein (Server, die Chain-Ereignisse beobachten, einen Merkle-Baum von Nachrichten pflegen, die Sammlung von Signaturen koordinieren usw.), aber dies wird von den Brückenbetreibern verwaltet und Off-Chain gehalten. On-Chain-Kosten: Das Verifizieren einiger Signaturen (z. B. 2 oder 5 ECDSA-Signaturen) ist nicht zu teuer, aber es ist sicherlich mehr Gas als eine einzelne Schwellenwert-Signatur oder eine Hash-Prüfung. Einige Brücken verwenden aggregierte Signaturschemata (z. B. BLS), um die On-Chain-Kosten auf 1 Signaturverifizierung zu reduzieren. Im Allgemeinen ist die Multisig-Verifizierung auf Ethereum oder ähnlichen Chains mäßig kostspielig (jede ECDSA-Signaturprüfung kostet ~3000 Gas). Wenn eine Brücke 10 Signaturen erfordert, sind das ~30.000 Gas allein für die Verifizierung, plus jegliche Speicherung eines neuen Merkle-Roots usw. Dies ist in der Regel akzeptabel, da Cross-Chain-Transfers hochwertige Operationen sind, aber es kann sich summieren. Aus Entwickler-/Benutzersicht ist die Interaktion mit einer Multisig-Brücke unkompliziert: Sie zahlen ein oder rufen eine Sendefunktion auf, und der Rest wird Off-Chain von den Validatoren/Relayern erledigt, dann wird ein Proof eingereicht. Für App-Entwickler gibt es minimale Komplexität, da sie nur die API/den Vertrag der Brücke integrieren. Eine Komplexitätsüberlegung ist das Hinzufügen neuer Chains – jeder Validator muss einen Node oder Indexer für jede neue Chain betreiben, um Nachrichten zu beobachten, was ein Koordinationsproblem sein kann (dies wurde als Engpass für die Expansion in einigen Multisig-Designs festgestellt). Hyperlanes Antwort sind genehmigungslose Validatoren (jeder kann für eine Chain beitreten, wenn das ISM sie enthält), aber die Anwendung, die das ISM bereitstellt, muss diese Schlüssel zunächst einrichten. Insgesamt sind Multisig-Modelle einfacher über heterogene Chains hinweg zu bootstrappen (keine Notwendigkeit für einen maßgeschneiderten Light Client pro Chain), was sie schneller auf den Markt bringt, aber sie verursachen operationelle Komplexität Off-Chain und moderate On-Chain-Verifizierungskosten.

  • Proof-Aggregation (LayerZero): Die Komplexität liegt hier in der Koordination vieler möglicher Verifizierungsmethoden. LayerZero bietet eine standardisierte Schnittstelle (die Endpoint- & MessageLib-Verträge) und erwartet, dass DVNs einer bestimmten Verifizierungs-API entsprechen. Aus Sicht einer Anwendung ist die Verwendung von LayerZero recht einfach (man ruft einfach lzSend auf und implementiert lzReceive-Callbacks), aber unter der Haube passiert viel. Jedes DVN kann seine eigene Off-Chain-Infrastruktur haben (einige DVNs sind im Wesentlichen selbst Mini-Brücken, wie ein Axelar-Netzwerk oder ein Chainlink-Oracle-Dienst). Das Protokoll selbst ist komplex, da es disparate Proof-Typen sicher aggregieren muss – z. B. könnte ein DVN einen EVM-Block-Proof liefern, ein anderer einen SNARK, ein anderer eine Signatur usw., und der Vertrag muss jeden der Reihe nach verifizieren. Der Vorteil ist, dass ein Großteil dieser Komplexität durch LayerZeros Framework abstrahiert wird. Die Kosten hängen davon ab, wie viele und welche Art von Proofs erforderlich sind: Das Verifizieren eines SNARKs kann teuer sein (On-Chain-zk-Proof-Verifizierung kann Hunderttausende von Gas kosten), während das Verifizieren einiger Signaturen billiger ist. LayerZero lässt die App entscheiden, wie viel sie für die Sicherheit pro Nachricht bezahlen möchte. Es gibt auch ein Konzept der Bezahlung von DVNs für ihre Arbeit – die Nachrichtennutzlast enthält eine Gebühr für DVN-Dienste. Zum Beispiel kann eine App Gebühren anfügen, die DVNs und Executoren dazu anregen, die Nachricht umgehend zu verarbeiten. Dies fügt eine Kostendimension hinzu: Eine sicherere Konfiguration (mit vielen DVNs oder teuren Proofs) kostet mehr an Gebühren, während ein einfaches 1-von-1-DVN (wie ein einzelner Relayer) sehr billig, aber weniger sicher sein könnte. Upgradefähigkeit und Governance sind ebenfalls Teil der Komplexität: Da Apps ihren Sicherheits-Stack ändern können, muss es einen Governance-Prozess oder einen Admin-Schlüssel geben, um dies zu tun – was selbst ein Vertrauens-/Komplexitätspunkt ist, der verwaltet werden muss. Zusammenfassend ist die Proof-Aggregation über LayerZero hochflexibel, aber unter der Haube komplex. Die Kosten pro Nachricht können durch die Wahl effizienter DVNs optimiert werden (z. B. durch die Verwendung eines optimierten Ultra-Light-Clients oder die Nutzung der Skaleneffekte eines bestehenden Oracle-Netzwerks). Viele Entwickler werden die Plug-and-Play-Natur (mit bereitgestellten Standardeinstellungen) ansprechend finden – z. B. einfach den Standard-DVN-Satz zur Vereinfachung verwenden – aber das kann wiederum zu suboptimalen Vertrauensannahmen führen, wenn es nicht verstanden wird.

Upgradefähigkeit und Governance​

  • Light Clients (IBC): IBC-Verbindungen und Clients können über On-Chain-Governance-Vorschläge auf den teilnehmenden Chains aktualisiert werden (insbesondere wenn der Light Client eine Korrektur oder ein Update für einen Hardfork in der Quell-Chain benötigt). Das Upgrade des IBC-Protokolls selbst (z. B. von IBC 2.0 auf 3.0-Funktionen) erfordert ebenfalls die Annahme neuer Softwareversionen durch die Chain-Governance. Dies bedeutet, dass IBC einen bewussten Upgrade-Pfad hat – Änderungen sind langsam und erfordern Konsens, aber das steht im Einklang mit seinem sicherheitsorientierten Ansatz. Es gibt keine einzelne Entität, die einen Schalter umlegen kann; die Governance jeder Chain muss Änderungen an Clients oder Parametern genehmigen. Das Positive ist, dass dies einseitige Änderungen verhindert, die Schwachstellen einführen könnten. Das Negative ist weniger Agilität – z. B. könnte es bei einem Fehler in einem Light Client koordinierte Governance-Abstimmungen über viele Chains hinweg erfordern, um ihn zu patchen (obwohl es Notfall-Koordinationsmechanismen gibt). Aus dApp-Sicht hat IBC keine „App-Level-Governance“ – es ist eine von der Chain bereitgestellte Infrastruktur. Anwendungen verwenden einfach IBC-Module (wie Token-Transfer oder Interchain-Accounts) und verlassen sich auf die Sicherheit der Chain. Die Governance und Upgrades erfolgen also auf Blockchain-Ebene (Hub- und Zonen-Governance). Ein interessantes neues IBC-Feature sind benutzerdefinierte Kanäle und Routing (z. B. Hubs wie Polymer oder Nexus), die das Umschalten der zugrunde liegenden Verifizierungsmethoden ohne Unterbrechung der Apps ermöglichen können. Aber im Großen und Ganzen ist IBC stabil und standardisiert – Upgradefähigkeit ist möglich, aber selten, was zu seiner Zuverlässigkeit beiträgt.

  • Multisig-Brücken (Hyperlane/Wormhole): Diese Systeme verfügen oft über einen Admin- oder Governance-Mechanismus, um Verträge zu aktualisieren, Validator-Sätze zu ändern oder Parameter zu modifizieren. Zum Beispiel könnte das Hinzufügen eines neuen Validators zum Satz oder das Rotieren von Schlüsseln eine Multisig des Brückenbesitzers oder eine DAO-Abstimmung erfordern. Da Hyperlane genehmigungslos ist, könnte jeder Benutzer sein eigenes ISM mit einem benutzerdefinierten Validator-Satz bereitstellen, aber wenn der Standard verwendet wird, kontrolliert wahrscheinlich das Hyperlane-Team oder die Community die Updates. Upgradefähigkeit ist ein zweischneidiges Schwert: Einerseits einfach zu aktualisieren/verbessern, andererseits kann es ein Zentralisierungsrisiko darstellen (wenn ein privilegierter Schlüssel die Brückenverträge aktualisieren kann, könnte dieser Schlüssel theoretisch die Brücke rug-pullen). Ein gut geführtes Protokoll wird dies einschränken (z. B. Time-Lock-Upgrades oder die Verwendung einer dezentralen Governance). Hyperlanes Philosophie ist Modularität – so könnte eine App sogar eine fehlerhafte Komponente umgehen, indem sie ISMs wechselt usw. Dies gibt Entwicklern die Möglichkeit, auf Bedrohungen zu reagieren (z. B. wenn ein Satz von Validatoren als kompromittiert verdächtigt wird, könnte eine App schnell zu einem anderen Sicherheitsmodell wechseln). Der Governance-Overhead besteht darin, dass Apps ihr Sicherheitsmodell selbst bestimmen und möglicherweise Schlüssel für ihre eigenen Validatoren verwalten oder auf Updates des Hyperlane-Kernprotokolls achten müssen. Zusammenfassend sind Multisig-basierte Systeme leichter aktualisierbar (die Verträge sind oft aktualisierbar und die Komitees konfigurierbar), was gut für schnelle Verbesserungen und das Hinzufügen neuer Chains ist, aber es erfordert Vertrauen in den Governance-Prozess. Viele Brücken-Exploits in der Vergangenheit sind durch kompromittierte Upgrade-Schlüssel oder fehlerhafte Governance aufgetreten, daher muss dieser Bereich sorgfältig behandelt werden. Positiv ist, dass das Hinzufügen der Unterstützung für eine neue Chain so einfach sein könnte wie das Bereitstellen der Verträge und das Veranlassen der Validatoren, Nodes dafür zu betreiben – keine grundlegende Protokolländerung erforderlich.

  • Proof-Aggregation (LayerZero): LayerZero bewirbt eine unveränderliche Transportschicht (die Endpoint-Verträge sind nicht aktualisierbar), aber die Verifizierungsmodule (Message Libraries und DVN-Adapter) sind nur zum Anhängen und konfigurierbar. In der Praxis bedeutet dies, dass der LayerZero-Kernvertrag auf jeder Chain fest bleibt (eine stabile Schnittstelle bereitstellt), während neue DVNs oder Verifizierungsoptionen im Laufe der Zeit hinzugefügt werden können, ohne den Kern zu ändern. Anwendungsentwickler haben die Kontrolle über ihren Security Stack: Sie können DVNs hinzufügen oder entfernen, die Bestätigungsblocktiefe ändern usw. Dies ist eine Form der Upgradefähigkeit auf App-Ebene. Wenn beispielsweise ein bestimmtes DVN veraltet ist oder ein neues, besseres entsteht (wie ein schnellerer zk-Client), kann das App-Team dies in seine Konfiguration integrieren – was die dApp zukunftssicher macht. Der Vorteil ist offensichtlich: Apps sind nicht an die Sicherheitstechnologie von gestern gebunden; sie können sich (mit entsprechender Vorsicht) an neue Entwicklungen anpassen. Dies wirft jedoch Governance-Fragen auf: Wer innerhalb der App entscheidet, den DVN-Satz zu ändern? Idealerweise, wenn die App dezentralisiert ist, würden Änderungen durch Governance gehen oder hartkodiert sein, wenn sie Unveränderlichkeit wünschen. Wenn ein einzelner Admin den Sicherheits-Stack ändern kann, ist das ein Vertrauenspunkt (er könnte die Sicherheitsanforderungen in einem bösartigen Upgrade reduzieren). LayerZeros eigene Anleitung ermutigt dazu, eine robuste Governance für solche Änderungen einzurichten oder bestimmte Aspekte bei Bedarf sogar unveränderlich zu machen. Ein weiterer Governance-Aspekt ist das Gebührenmanagement – die Bezahlung von DVNs und Relayern könnte angepasst werden, und falsch ausgerichtete Anreize könnten die Leistung beeinträchtigen (obwohl standardmäßig Marktkräfte die Gebühren anpassen sollten). Zusammenfassend ist LayerZeros Modell hochgradig erweiterbar und aktualisierbar in Bezug auf das Hinzufügen neuer Verifizierungsmethoden (was großartig für die langfristige Interoperabilität ist), doch die Verantwortung liegt bei jeder Anwendung, diese Upgrades verantwortungsvoll zu verwalten. Die Basisverträge von LayerZero sind unveränderlich, um sicherzustellen, dass die Transportschicht nicht rug-pulled oder zensiert werden kann, was Vertrauen schafft, dass die Messaging-Pipeline selbst durch Upgrades intakt bleibt.

Um den Vergleich zusammenzufassen, hebt die folgende Tabelle die wichtigsten Unterschiede hervor:

AspektIBC (Light Clients)Hyperlane (Multisig)LayerZero v2 (Aggregation)
VertrauensmodellVertraut dem Konsens der Quell-Chain (kein zusätzliches Vertrauen).Vertraut einem Komitee von Brücken-Validatoren (z. B. Multisig-Schwellenwert). Slashing kann das Risiko mindern.Vertrauen hängt von den gewählten DVNs ab. Kann Light Client oder Multisig emulieren oder mischen (vertraut mindestens einem der gewählten Verifizierer).
SicherheitHöchste – kryptographischer Proof der Gültigkeit über Light Client. Angriffe erfordern Kompromittierung der Quell-Chain oder des Light Clients.Stark, wenn das Komitee eine ehrliche Mehrheit hat, aber schwächer als Light Client. Komitee-Kollusion oder Schlüsselkompromittierung ist die Hauptbedrohung.Potenziell sehr hoch – kann mehrere unabhängige Proofs erfordern (z. B. zk + Multisig + Oracle). Aber konfigurierbare Sicherheit bedeutet, dass sie nur so stark ist wie die schwächsten gewählten DVNs.
LivenessSehr gut, solange mindestens ein Relayer aktiv ist. Parallele Relayer und schnelle Finalitäts-Chains ermöglichen nahezu Echtzeit-Zustellung.Gut unter normalen Bedingungen (schnelle Signaturen). Aber abhängig von der Betriebszeit der Validatoren. Ausfall des Schwellenwert-Quorums = Stillstand. Expansion auf neue Chains erfordert Komitee-Unterstützung.Sehr gut; mehrere DVNs bieten Redundanz, und jeder Benutzer kann Transaktionen relayen. Erforderliche DVNs können bei Fehlkonfiguration Single Points of Failure sein. Latenz kann angepasst werden (z. B. Warten auf Bestätigungen vs. Geschwindigkeit).
KostenAnfängliche Komplexität bei der Implementierung von Clients. On-Chain-Verifizierung des Konsenses (Signaturen, Merkle-Proofs), aber in Cosmos optimiert. Geringe Kosten pro Nachricht in IBC-nativen Umgebungen; potenziell teuer auf nicht-nativen Chains ohne spezielle Lösungen.Geringere Entwicklungskomplexität für Kernverträge. On-Chain-Kosten skalieren mit der Anzahl der Signaturen pro Nachricht. Off-Chain-Betriebskosten für Validatoren (Nodes auf jeder Chain). Möglicherweise höhere Gasgebühren als Light Client bei vielen Signaturen, aber oft überschaubar.Moderat bis hoch in der Komplexität. Kosten pro Nachricht variieren: jeder DVN-Proof (Signatur oder SNARK) erhöht die Verifizierungs-Gasgebühren. Apps zahlen DVN-Gebühren für den Dienst. Kosten können durch die Wahl weniger oder günstigerer Proofs für geringwertige Nachrichten optimiert werden.
UpgradefähigkeitProtokoll entwickelt sich über Chain-Governance (langsam, konservativ). Light-Client-Updates erfordern Koordination, aber Standardisierung hält es stabil. Das Hinzufügen neuer Chains erfordert das Erstellen/Genehmigen neuer Client-Typen.Flexibel – Validator-Sätze und ISMs können über Governance oder Admin geändert werden. Einfacher, neue Chains schnell zu integrieren. Risiko, wenn Upgrade-Schlüssel oder Governance kompromittiert werden. Typischerweise aktualisierbare Verträge (erfordert Vertrauen in Administratoren).Hochgradig modular – neue DVNs/Verifizierungsmethoden können hinzugefügt werden, ohne den Kern zu ändern. Apps können die Sicherheitskonfiguration bei Bedarf ändern. Kern-Endpoints unveränderlich (keine zentralen Upgrades), aber App-Level-Governance für Sicherheitsänderungen erforderlich, um Missbrauch zu vermeiden.

Auswirkungen auf Komponierbarkeit und geteilte Liquidität in DeFi​

Cross-Chain-Messaging ermöglicht leistungsstarke neue Muster für die Komponierbarkeit – die Fähigkeit von DeFi-Verträgen auf verschiedenen Chains, miteinander zu interagieren – und ermöglicht geteilte Liquidität – das Pooling von Assets über Chains hinweg, als ob sie sich in einem Markt befänden. Die oben diskutierten Sicherheitsmodelle beeinflussen, wie zuversichtlich und nahtlos Protokolle Cross-Chain-Funktionen nutzen können. Im Folgenden untersuchen wir, wie jeder Ansatz Multi-Chain-DeFi unterstützt, mit realen Beispielen:

  • Omnichain-DeFi über LayerZero (Stargate, Radiant, Tapioca): LayerZeros generisches Messaging und der Omnichain Fungible Token (OFT)-Standard sind darauf ausgelegt, Liquiditätssilos aufzubrechen. Zum Beispiel verwendet Stargate Finance LayerZero, um einen einheitlichen Liquiditätspool für native Asset-Bridging zu implementieren – anstatt fragmentierter Pools auf jeder Chain greifen Stargate-Verträge auf allen Chains auf einen gemeinsamen Pool zu, und LayerZero-Nachrichten handhaben die Sperr-/Freigabe-Logik über Chains hinweg. Dies führte zu einem monatlichen Volumen von über 800 Millionen US-Dollar in Stargates Brücken, was eine signifikante geteilte Liquidität demonstriert. Indem sie sich auf LayerZeros Sicherheit verlassen (wobei Stargate vermutlich einen robusten DVN-Satz verwendet), können Benutzer Assets mit hoher Zuversicht in die Nachrichtenauthentizität übertragen. Radiant Capital ist ein weiteres Beispiel – ein Cross-Chain-Lending-Protokoll, bei dem Benutzer auf einer Chain einzahlen und auf einer anderen leihen können. Es nutzt LayerZero-Nachrichten, um den Kontostand über Chains hinweg zu koordinieren und so effektiv einen Lending-Markt über mehrere Netzwerke hinweg zu schaffen. Ähnlich verwendet Tapioca (ein Omnichain-Geldmarkt) LayerZero v2 und betreibt sogar sein eigenes DVN als erforderlichen Verifizierer, um seine Nachrichten zu sichern. Diese Beispiele zeigen, dass LayerZero mit flexibler Sicherheit komplexe Cross-Chain-Operationen wie Kreditprüfungen, Kollateralbewegungen und Liquidationen über Chains hinweg unterstützen kann. Die Komponierbarkeit ergibt sich aus LayerZeros „OApp“-Standard (Omnichain Application), der es Entwicklern ermöglicht, denselben Vertrag auf vielen Chains bereitzustellen und diese über Messaging zu koordinieren. Ein Benutzer interagiert mit der Instanz jeder Chain und erlebt die Anwendung als ein einheitliches System. Das Sicherheitsmodell ermöglicht eine Feinabstimmung: z. B. könnten große Transfers oder Liquidationen mehr DVN-Signaturen erfordern (aus Sicherheitsgründen), während kleine Aktionen schnellere/günstigere Pfade durchlaufen. Diese Flexibilität stellt sicher, dass weder Sicherheit noch UX eine Einheitslösung sein müssen. In der Praxis hat LayerZeros Modell die geteilte Liquidität erheblich verbessert, was durch Dutzende von Projekten belegt wird, die OFT für Token verwenden (sodass ein Token „Omnichain“ existieren kann, anstatt als separate Wrapped Assets). Zum Beispiel können Stablecoins und Governance-Token OFT verwenden, um eine einzige Gesamtversorgung über alle Chains hinweg aufrechtzuerhalten – wodurch Liquiditätsfragmentierung und Arbitrage-Probleme vermieden werden, die frühere Wrapped Tokens plagten. Insgesamt hat LayerZero durch die Bereitstellung einer zuverlässigen Messaging-Schicht und die Möglichkeit für Apps, das Vertrauensmodell zu kontrollieren, neue Multi-Chain-DeFi-Designs katalysiert, die mehrere Chains als ein Ökosystem behandeln. Der Kompromiss ist, dass Benutzer und Projekte die Vertrauensannahme jeder Omnichain-App verstehen müssen (da sie sich unterscheiden können). Aber Standards wie OFT und weit verbreitete Standard-DVNs tragen dazu bei, dies einheitlicher zu gestalten.

  • Interchain-Accounts und -Dienste in IBC (Cosmos DeFi): In der Cosmos-Welt hat IBC eine reiche Vielfalt an Cross-Chain-Funktionalität ermöglicht, die über Token-Transfers hinausgeht. Ein Flaggschiff-Feature sind Interchain Accounts (ICA), die es einer Blockchain (oder einem Benutzer auf Chain A) ermöglichen, ein Konto auf Chain B zu kontrollieren, als ob es lokal wäre. Dies geschieht über IBC-Pakete, die Transaktionen übertragen. Zum Beispiel kann der Cosmos Hub ein Interchain-Konto auf Osmosis verwenden, um Token im Namen eines Benutzers zu staken oder zu swappen – alles vom Hub aus initiiert. Ein konkreter DeFi-Anwendungsfall ist Strides Liquid Staking-Protokoll: Stride (eine Chain) empfängt Token wie ATOM von Benutzern und staket diese ATOM über ICA remote auf dem Cosmos Hub und gibt dann stATOM (liquid gestakte ATOM) an die Benutzer zurück. Der gesamte Fluss ist vertrauenslos und automatisiert über IBC – Strides Modul steuert ein Konto auf dem Hub, das Delegate- und Undelegate-Transaktionen ausführt, wobei Bestätigungen und Timeouts die Sicherheit gewährleisten. Dies demonstriert Cross-Chain-Komponierbarkeit: zwei souveräne Chains führen einen gemeinsamen Workflow (hier staken, dort Token minten) nahtlos aus. Ein weiteres Beispiel ist Osmosis (eine DEX-Chain), die IBC verwendet, um Assets von über 95 verbundenen Chains anzuziehen. Benutzer aus jeder Zone können auf Osmosis swappen, indem sie ihre Token über IBC senden. Dank der hohen Sicherheit von IBC behandeln Osmosis und andere IBC-Token zuversichtlich als echt (ohne vertrauenswürdige Verwahrer zu benötigen). Dies hat dazu geführt, dass Osmosis zu einer der größten Interchain-DEXes geworden ist, mit einem täglichen IBC-Transfervolumen, das Berichten zufolge das vieler Brückensysteme übersteigt. Darüber hinaus kann mit Interchain Queries (ICQ) in IBC 3.0 ein Smart Contract auf einer Chain Daten (wie Preise, Zinssätze oder Positionen) von einer anderen Chain auf vertrauensminimierte Weise abrufen. Dies könnte beispielsweise einen Interchain-Yield-Aggregator ermöglichen, der Yield-Raten auf mehreren Zonen abfragt und Assets entsprechend neu zuweist, alles über IBC-Nachrichten. Die Hauptauswirkung des IBC-Light-Client-Modells auf die Komponierbarkeit ist Vertrauen und Neutralität: Chains bleiben souverän, können aber ohne Angst vor einem Drittanbieter-Brückenrisiko interagieren. Projekte wie Composable Finance und Polymer erweitern IBC sogar auf Nicht-Cosmos-Ökosysteme (Polkadot, Ethereum), um diese Fähigkeiten zu nutzen. Das Ergebnis könnte eine Zukunft sein, in der jede Chain, die einen IBC-Client-Standard annimmt, sich in ein „universelles Internet der Blockchains“ einklinken kann. Geteilte Liquidität in Cosmos ist bereits signifikant – z. B. verlassen sich der native DEX des Cosmos Hub (Gravity DEX) und andere auf IBC, um Liquidität aus verschiedenen Zonen zu bündeln. Eine Einschränkung bisher ist jedoch, dass Cosmos DeFi meist asynchron ist: Sie initiieren auf einer Chain, das Ergebnis erfolgt auf einer anderen mit einer leichten Verzögerung (Sekunden). Dies ist für Dinge wie Trades und Staking in Ordnung, aber komplexere synchrone Komponierbarkeit (wie Flash Loans über Chains hinweg) bleibt aufgrund der grundlegenden Latenz außerhalb des Rahmens. Dennoch ist das Spektrum des durch IBC ermöglichten Cross-Chain-DeFi breit: Multi-Chain-Yield-Farming (Gelder dorthin bewegen, wo der Yield am höchsten ist), Cross-Chain-Governance (eine Chain stimmt ab, um Aktionen auf einer anderen über Governance-Pakete auszuführen) und sogar Interchain Security, bei der eine Consumer-Chain den Validator-Satz einer Provider-Chain nutzt (durch IBC-Validierungspakete). Zusammenfassend haben die sicheren Kanäle von IBC eine Interchain-Wirtschaft in Cosmos gefördert – eine, in der Projekte sich auf separaten Chains spezialisieren und dennoch fließend über vertrauensminimierte Nachrichten zusammenarbeiten können. Die geteilte Liquidität zeigt sich in Dingen wie dem Fluss von Assets zu Osmosis und dem Aufkommen von Cosmos-nativen Stablecoins, die sich frei zwischen den Zonen bewegen.

  • Hybride und andere Multi-Chain-Ansätze (Hyperlane und darüber hinaus): Hyperlanes Vision der genehmigungslosen Konnektivität hat zu Konzepten wie Warp Routes für das Bridging von Assets und Interchain-dApps geführt, die verschiedene Ökosysteme umfassen. Zum Beispiel könnte eine Warp Route es einem ERC-20-Token auf Ethereum ermöglichen, zu einem Solana-Programm teleportiert zu werden, wobei Hyperlanes Nachrichtenschicht im Hintergrund verwendet wird. Eine konkrete benutzerorientierte Implementierung ist Hyperlanes Nexus-Brücke, die eine Benutzeroberfläche für die Übertragung von Assets zwischen vielen Chains über Hyperlanes Infrastruktur bietet. Durch die Verwendung eines modularen Sicherheitsmodells kann Hyperlane die Sicherheit pro Route anpassen: Ein kleiner Transfer könnte über einen einfachen, schnellen Pfad gehen (nur Hyperlane-Validatoren signieren), während ein großer Transfer ein aggregiertes ISM erfordern könnte (Hyperlane + Wormhole + Axelar bestätigen alle). Dies stellt sicher, dass hochwertige Liquiditätsbewegungen durch mehrere Brücken gesichert sind – was das Vertrauen erhöht, z. B. 10 Millionen US-Dollar eines Assets Cross-Chain zu bewegen (es würde die Kompromittierung mehrerer Netzwerke erfordern, um es zu stehlen), auf Kosten höherer Komplexität/Gebühren. In Bezug auf die Komponierbarkeit ermöglicht Hyperlane das, was sie „Vertragsinteroperabilität“ nennen – ein Smart Contract auf Chain A kann eine Funktion auf Chain B aufrufen, als ob sie lokal wäre, sobald Nachrichten zugestellt werden. Entwickler integrieren das Hyperlane SDK, um diese Cross-Chain-Aufrufe einfach zu versenden. Ein Beispiel könnte ein Cross-Chain-DEX-Aggregator sein, der teilweise auf Ethereum und teilweise auf der BNB Chain läuft und Hyperlane-Nachrichten verwendet, um zwischen den beiden zu arbitragieren. Da Hyperlane EVM- und Nicht-EVM-Chains unterstützt (sogar frühe Arbeiten an CosmWasm- und MoveVM-Integration), strebt es an, „jede Chain, jede VM“ zu verbinden. Diese breite Reichweite kann die geteilte Liquidität erhöhen, indem Ökosysteme überbrückt werden, die sonst nicht einfach verbunden werden können. Die tatsächliche Akzeptanz von Hyperlane im großen DeFi-Bereich wächst jedoch noch. Es hat noch nicht das Volumen von Wormhole oder LayerZero im Bridging, aber seine genehmigungslose Natur hat Experimente angezogen. Zum Beispiel haben einige Appchain-Teams Hyperlane verwendet, um ihre Chain schnell mit Ethereum zu verbinden, da sie ihren eigenen Validator-Satz einrichten und nicht auf komplexe Light-Client-Lösungen warten mussten. Wenn Restaking (EigenLayer) wächst, könnte Hyperlane mehr Akzeptanz finden, indem es Ethereum-ähnliche Sicherheit für jedes Rollup mit relativ geringer Latenz bietet. Dies könnte neue Multi-Chain-Kompositionen beschleunigen – z. B. ein Optimism-Rollup und ein Polygon-zk-Rollup, die Nachrichten über Hyperlane AVS austauschen, wobei jede Nachricht durch geslashtes ETH abgesichert ist, wenn sie betrügerisch ist. Die Auswirkung auf die Komponierbarkeit ist, dass selbst Ökosysteme ohne gemeinsamen Standard (wie Ethereum und ein beliebiges L2) einen Brückenvertrag erhalten können, dem beide Seiten vertrauen (weil er wirtschaftlich gesichert ist). Im Laufe der Zeit könnte dies ein Netz miteinander verbundener DeFi-Apps hervorbringen, bei denen die Komponierbarkeit vom Entwickler „eingestellt“ wird (indem er wählt, welche Sicherheitsmodule für welche Aufrufe verwendet werden sollen).

In all diesen Fällen ist das Zusammenspiel zwischen Sicherheitsmodell und Komponierbarkeit offensichtlich. Projekte werden große Liquiditätspools nur dann Cross-Chain-Systemen anvertrauen, wenn die Sicherheit felsenfest ist – daher der Drang zu vertrauensminimierten oder wirtschaftlich gesicherten Designs. Gleichzeitig beeinflussen die einfache Integration (Entwicklererfahrung) und Flexibilität, wie kreativ Teams bei der Nutzung mehrerer Chains sein können. LayerZero und Hyperlane konzentrieren sich auf Einfachheit für Entwickler (einfach ein SDK importieren und vertraute Sende-/Empfangsaufrufe verwenden), während IBC, da es auf niedrigerer Ebene angesiedelt ist, mehr Verständnis für Module erfordert und eher von Chain-Entwicklern als von Anwendungsentwicklern gehandhabt werden könnte. Dennoch streben alle drei eine Zukunft an, in der Benutzer mit Multi-Chain-dApps interagieren, ohne wissen zu müssen, auf welcher Chain sie sich befinden – die App greift nahtlos auf Liquidität und Funktionalität von überall her zu. Zum Beispiel könnte ein Benutzer einer Lending-App auf Chain A einzahlen und nicht einmal merken, dass die Ausleihe aus einem Pool auf Chain B erfolgte – alles abgedeckt durch Cross-Chain-Nachrichten und ordnungsgemäße Validierung.

Implementierungen, Bedrohungsmodelle und Adoption in der Praxis​

Es ist wichtig zu beurteilen, wie sich diese Protokolle unter realen Bedingungen bewähren – ihre aktuellen Implementierungen, bekannten Bedrohungsvektoren und Adoptionsraten:

  • LayerZero v2 in Produktion: LayerZero v1 (mit dem 2-Entitäten-Oracle+Relayer-Modell) erlangte eine signifikante Akzeptanz und sicherte bis Mitte 2024 über 50 Milliarden US-Dollar an Transfervolumen und mehr als 134 Millionen Cross-Chain-Nachrichten. Es ist in über 60 Blockchains integriert, hauptsächlich EVM-Chains, aber auch Nicht-EVM-Chains wie Aptos, und experimentelle Unterstützung für Solana steht bevor. LayerZero v2 wurde Anfang 2024 eingeführt und führte DVNs und modulare Sicherheit ein. Bereits große Plattformen wie Radiant Capital, SushiXSwap, Stargate, PancakeSwap und andere haben begonnen, auf v2 zu migrieren oder darauf aufzubauen, um dessen Flexibilität zu nutzen. Eine bemerkenswerte Integration ist das Flare Network (ein Layer1, das sich auf Daten konzentriert), das LayerZero v2 übernommen hat, um sich gleichzeitig mit 75 Chains zu verbinden. Flare wurde von der Möglichkeit angezogen, die Sicherheit anzupassen: z. B. die Verwendung eines einzelnen schnellen DVN für geringwertige Nachrichten und die Anforderung mehrerer DVNs für hochwertige Nachrichten. Dies zeigt, dass Anwendungen in der Produktion tatsächlich den „Mix-and-Match“-Sicherheitsansatz als Verkaufsargument nutzen. Sicherheit und Audits: LayerZeros Verträge sind unveränderlich und wurden auditiert (v1 hatte mehrere Audits, v2 ebenfalls). Die Hauptbedrohung in v1 war die Oracle-Relayer-Kollusion – wenn die beiden Off-Chain-Parteien kolludierten, könnten sie eine Nachricht fälschen. In v2 wird diese Bedrohung auf die DVN-Kollusion verallgemeinert. Wenn alle DVNs, auf die eine App angewiesen ist, von einer Entität kompromittiert werden, könnte eine gefälschte Nachricht durchrutschen. LayerZeros Antwort ist, App-spezifische DVNs zu fördern (damit ein Angreifer auch das App-Team kompromittieren müsste) und die Vielfalt der Verifizierer zu erhöhen (was Kollusion erschwert). Ein weiteres potenzielles Problem ist die Fehlkonfiguration oder der Missbrauch von Upgrades – wenn ein App-Besitzer bösartig zu einem trivialen Security Stack wechselt (wie einem 1-von-1-DVN, das von ihm selbst kontrolliert wird), könnte er die Sicherheit umgehen, um seine eigenen Benutzer auszunutzen. Dies ist eher ein Governance-Risiko als ein Protokollfehler, und Communities müssen wachsam bleiben, wie die Sicherheit einer Omnichain-App eingerichtet ist (vorzugsweise mit Multi-Sig oder Community-Zustimmung für Änderungen). In Bezug auf die Adoption hat LayerZero derzeit wohl die größte Nutzung unter den Messaging-Protokollen in DeFi: Es treibt das Bridging für Stargate, Circles CCTP-Integration (für USDC-Transfers), Sushis Cross-Chain-Swap, viele NFT-Brücken und unzählige OFT-Token an (Projekte, die LayerZero wählen, um ihren Token auf mehreren Chains verfügbar zu machen). Die Netzwerkeffekte sind stark – je mehr Chains LayerZero-Endpoints integrieren, desto einfacher wird es für neue Chains, dem „Omnichain“-Netzwerk beizutreten. LayerZero Labs selbst betreibt ein DVN, und die Community (einschließlich Anbieter wie Google Cloud, Polyhedra für zk-Proofs usw.) hat bis 2024 über 15 DVNs gestartet. Bisher gab es keinen größeren Exploit des LayerZero-Kernprotokolls, was ein positives Zeichen ist (obwohl einige Hacks auf Anwendungsebene oder Benutzerfehler aufgetreten sind, wie bei jeder Technologie). Das Design des Protokolls, die Transportschicht einfach zu halten (im Wesentlichen nur Nachrichten zu speichern und Proofs zu verlangen), minimiert On-Chain-Schwachstellen und verlagert die meisten Komplexität Off-Chain auf die DVNs.

  • Hyperlane in Produktion: Hyperlane (ehemals Abacus) ist auf zahlreichen Chains live, darunter Ethereum, mehrere L2s (Optimism, Arbitrum, zkSync usw.), Cosmos-Chains wie Osmosis über ein Cosmos-SDK-Modul und sogar MoveVM-Chains (es ist in seiner Unterstützung recht breit aufgestellt). Seine Akzeptanz hinkt jedoch den etablierten Anbietern wie LayerZero und Wormhole in Bezug auf das Volumen hinterher. Hyperlane wird oft im Kontext einer „souveränen Brückenlösung“ erwähnt – d. h. ein Projekt kann Hyperlane bereitstellen, um eine eigene Brücke mit benutzerdefinierter Sicherheit zu haben. Zum Beispiel haben einige Appchain-Teams Hyperlane verwendet, um ihre Chain mit Ethereum zu verbinden, ohne sich auf eine geteilte Brücke zu verlassen. Eine bemerkenswerte Entwicklung ist der Mitte 2024 gestartete Hyperlane Active Validation Service (AVS), der eine der ersten Anwendungen des Ethereum-Restakings ist. Dabei staken Validatoren (viele davon Top-EigenLayer-Betreiber) ETH, um Hyperlane-Nachrichten zu sichern, wobei der Fokus zunächst auf schnellem Cross-Rollup-Messaging liegt. Dies sichert derzeit die Interoperabilität zwischen Ethereum L2-Rollups mit guten Ergebnissen – im Wesentlichen bietet es eine nahezu sofortige Nachrichtenübermittlung (schneller als das Warten auf optimistische Rollup-7-Tage-Exits) mit wirtschaftlicher Sicherheit, die an Ethereum gebunden ist. In Bezug auf das Bedrohungsmodell könnte Hyperlanes ursprünglicher Multisig-Ansatz angegriffen werden, wenn genügend Schlüssel von Validatoren kompromittiert werden (wie bei jeder Multisig-Brücke). Hyperlane hatte einen früheren Sicherheitsvorfall: Im August 2022, während eines frühen Testnetzes oder Starts, gab es einen Exploit, bei dem ein Angreifer den Deployer-Schlüssel einer Hyperlane-Token-Brücke auf einer Chain kapern und Token prägen konnte (Verlust von etwa 700.000 US-Dollar). Dies war kein Versagen des Multisigs selbst, sondern der operativen Sicherheit bei der Bereitstellung – es verdeutlichte die Risiken von Upgradefähigkeit und Schlüsselmanagement. Das Team erstattete Verluste und verbesserte Prozesse. Dies unterstreicht, dass Governance-Schlüssel Teil des Bedrohungsmodells sind – die Sicherung der Admin-Kontrollen ist ebenso wichtig wie die Validatoren. Mit AVS verschiebt sich das Bedrohungsmodell in einen EigenLayer-Kontext: Wenn jemand ein falsches Slashing verursachen oder trotz Fehlverhaltens ein Slashing vermeiden könnte, wäre das ein Problem; aber EigenLayers Protokoll handhabt die Slashing-Logik auf Ethereum, die robust ist, vorausgesetzt, die Betrugs-Proofs werden korrekt eingereicht. Hyperlanes aktuelle Akzeptanz wächst im Rollup-Bereich und bei einigen App-spezifischen Chains. Es mag noch nicht die Milliarden-Dollar-Flüsse einiger Konkurrenten verarbeiten, aber es erobert eine Nische, in der Entwickler volle Kontrolle und einfache Erweiterbarkeit wünschen. Das modulare ISM-Design bedeutet, dass wir kreative Sicherheits-Setups sehen könnten: z. B. könnte eine DAO nicht nur Hyperlane-Signaturen, sondern auch einen Time-Lock oder eine zweite Brückensignatur für jede Admin-Nachricht usw. verlangen. Hyperlanes genehmigungsloses Ethos (jeder kann einen Validator betreiben oder auf einer neuen Chain bereitstellen) könnte sich langfristig als mächtig erweisen, aber es bedeutet auch, dass das Ökosystem reifen muss (z. B. mehr Drittanbieter-Validatoren, die sich dem Standard-Satz anschließen, um ihn zu dezentralisieren; Stand 2025 ist unklar, wie dezentral der aktive Validator-Satz in der Praxis ist). Insgesamt ist Hyperlanes Trajektorie eine der Verbesserung der Sicherheit (mit Restaking) und Benutzerfreundlichkeit, aber es muss Widerstandsfähigkeit demonstrieren und große Liquidität anziehen, um das gleiche Maß an Community-Vertrauen wie IBC oder sogar LayerZero zu gewinnen.

  • IBC 3.0 und Cosmos Interop in Produktion: IBC ist seit 2021 live und im Cosmos-Ökosystem extrem kampferprobt. Bis 2025 verbindet es über 115 Zonen (einschließlich Cosmos Hub, Osmosis, Juno, Cronos, Axelar, Kujira usw.) mit Millionen von Transaktionen pro Monat und Multi-Milliarden-Dollar-Token-Flüssen. Es hatte beeindruckenderweise keine größeren Sicherheitsausfälle auf Protokollebene. Es gab einen bemerkenswerten IBC-bezogenen Vorfall: Im Oktober 2022 wurde eine kritische Schwachstelle im IBC-Code (die alle v2.0-Implementierungen betraf) entdeckt, die es einem Angreifer ermöglicht hätte, Wert von vielen IBC-verbundenen Chains abzuziehen. Sie wurde jedoch heimlich über koordinierte Upgrades behoben, bevor sie öffentlich bekannt gegeben wurde, und es kam zu keinem Exploit. Dies war ein Weckruf, dass selbst formal verifizierte Protokolle Fehler haben können. Seitdem wurde IBC weiter auditiert und gehärtet. Das Bedrohungsmodell für IBC betrifft hauptsächlich die Chain-Sicherheit: Wenn eine verbundene Chain feindselig ist oder einen 51%-Angriff erleidet, könnte sie versuchen, ungültige Daten an den Light Client eines Gegenübers zu senden. Minderungsmaßnahmen umfassen die Verwendung von Governance, um Verbindungen zu unsicheren Chains zu stoppen oder zu schließen (die Cosmos Hub Governance kann beispielsweise abstimmen, Client-Updates für eine bestimmte Chain abzuschalten, wenn sie als fehlerhaft erkannt wird). Außerdem haben IBC-Clients oft eine Angleichung der Unbonding-Periode oder Vertrauensperiode – z. B. akzeptiert ein Tendermint Light Client kein Validator-Satz-Update, das älter ist als die Unbonding-Periode (um Long-Range-Angriffe zu verhindern). Ein weiteres mögliches Problem ist die Relayer-Zensur – wenn kein Relayer Pakete zustellt, könnten Gelder in Timeouts stecken bleiben; aber da das Relaying genehmigungslos und oft incentiviert ist, ist dies typischerweise vorübergehend. Mit den Interchain Queries und neuen Funktionen von IBC 3.0 sehen wir eine Akzeptanz in Dingen wie Cross-Chain-DeX-Aggregatoren (z. B. Skip Protocol, das ICQ verwendet, um Preisdaten über Chains hinweg zu sammeln) und Cross-Chain-Governance (z. B. Cosmos Hub, das Interchain-Accounts verwendet, um Neutron, eine Consumer-Chain, zu verwalten). Die Adoption über Cosmos hinaus ist ebenfalls eine Geschichte: Projekte wie Polymer und Astria (ein Interop-Hub für Rollups) bringen IBC effektiv über ein Hub/Spoke-Modell zu Ethereum-Rollups, und Polkadots Parachains haben IBC erfolgreich genutzt, um sich mit Cosmos-Chains zu verbinden (z. B. die Centauri-Brücke zwischen Cosmos und Polkadot, gebaut von Composable Finance, verwendet IBC im Hintergrund mit einem GRANDPA-Light-Client auf der Cosmos-Seite). Es gibt sogar eine IBC-Solidity-Implementierung, die von Polymer und DataChain in Arbeit ist und es Ethereum-Smart-Contracts ermöglichen würde, IBC-Pakete zu verifizieren (unter Verwendung eines Light Clients oder von Validity Proofs). Wenn diese Bemühungen erfolgreich sind, könnte dies die Nutzung von IBC über Cosmos hinaus dramatisch erweitern und sein vertrauensminimiertes Modell in direkten Wettbewerb mit den stärker zentralisierten Brücken auf diesen Chains bringen. In Bezug auf die geteilte Liquidität war Cosmos' größte Einschränkung das Fehlen eines nativen Stablecoins oder einer tiefen Liquiditäts-DEX auf Augenhöhe mit Ethereum – das ändert sich mit dem Aufkommen von Cosmos-nativen Stablecoins (wie IST, CMST) und der Verbindung von Assets wie USDC (Axelar und Gravity Bridge brachten USDC, und jetzt startet Circle native USDC auf Cosmos über Noble). Wenn die Liquidität tiefer wird, könnte die Kombination aus hoher Sicherheit und nahtlosen IBC-Transfers Cosmos zu einem Knotenpunkt für den Multi-Chain-DeFi-Handel machen – tatsächlich stellte der Blockchain Capital-Bericht fest, dass IBC Anfang 2024 bereits mehr Volumen als LayerZero oder Wormhole abwickelte, wenn auch hauptsächlich aufgrund des Cosmos-zu-Cosmos-Verkehrs (was auf eine sehr aktive Interchain-Wirtschaft hindeutet). Zukünftig besteht die größte Herausforderung und Chance von IBC darin, auf heterogene Chains zu expandieren, ohne sein Sicherheits-Ethos zu opfern.

Zusammenfassend lässt sich sagen, dass jedes Protokoll Fortschritte macht: LayerZero integriert sich schnell in viele Chains und Anwendungen, priorisiert Flexibilität und Entwicklerakzeptanz und mindert Risiken, indem es Apps ermöglicht, Teil ihrer eigenen Sicherheit zu sein. Hyperlane innoviert mit Restaking und Modularität, um der einfachste Weg zu sein, neue Chains mit konfigurierbarer Sicherheit zu verbinden, obwohl es noch Vertrauen und Nutzung aufbauen muss. IBC ist der Goldstandard in Bezug auf Vertrauenslosigkeit in seinem Bereich, entwickelt sich nun schneller (IBC 3.0) und hofft, seinen Bereich über Cosmos hinaus auszudehnen, gestützt durch eine starke Erfolgsbilanz. Benutzer und Projekte tun gut daran, die Reife und Sicherheitsvorfälle jedes Protokolls zu berücksichtigen: IBC hat Jahre stabilen Betriebs (und enormes Volumen), ist aber auf bestimmte Ökosysteme beschränkt; LayerZero hat schnell an Nutzung gewonnen, erfordert aber das Verständnis benutzerdefinierter Sicherheitseinstellungen; Hyperlane ist in der Ausführung neuer, aber vielversprechend in seiner Vision, mit sorgfältigen Schritten in Richtung wirtschaftlicher Sicherheit.

Fazit und Ausblick: Interoperabilitätsarchitektur für die Multi-Chain-Zukunft​

Die langfristige Lebensfähigkeit und Interoperabilität der Multi-Chain-DeFi-Landschaft wird wahrscheinlich durch das Nebeneinander und sogar die Ergänzung aller drei Sicherheitsmodelle geprägt sein. Jeder Ansatz hat klare Stärken, und anstatt einer Einheitslösung könnten wir einen Stack sehen, bei dem das Light-Client-Modell (IBC) die höchste Zusicherungsgrundlage für Schlüsselrouten (insbesondere zwischen großen Chains) bietet, während Proof-aggregierte Systeme (LayerZero) universelle Konnektivität mit anpassbarem Vertrauen bereitstellen und Multisig-Modelle (Hyperlane und andere) Nischenbedürfnisse bedienen oder neue Ökosysteme schnell bootstrappen.

Kompromiss zwischen Sicherheit und Konnektivität: Light Clients wie IBC bieten das, was einem „Blockchain-Internet“ am nächsten kommt – eine neutrale, standardisierte Transportschicht, ähnlich wie TCP/IP. Sie stellen sicher, dass Interoperabilität keine neuen Schwachstellen einführt, was für die langfristige Nachhaltigkeit entscheidend ist. Sie erfordern jedoch eine breite Einigung über Standards und erhebliche technische Anstrengungen pro Chain, was die Geschwindigkeit, mit der neue Verbindungen hergestellt werden können, verlangsamt. LayerZero und Hyperlane hingegen priorisieren sofortige Konnektivität und Flexibilität und erkennen an, dass nicht jede Chain dasselbe Protokoll implementieren wird. Sie zielen darauf ab, „beliebig zu beliebig“ zu verbinden, auch wenn dies bedeutet, vorübergehend etwas mehr Vertrauen zu akzeptieren. Im Laufe der Zeit können wir erwarten, dass sich die Lücke schließt: LayerZero kann vertrauensminimiertere DVNs integrieren (sogar IBC selbst könnte in ein DVN eingewickelt werden), und Hyperlane kann wirtschaftliche Mechanismen nutzen, um die Sicherheit der nativen Verifizierung zu erreichen. Tatsächlich sieht das Polymer-Projekt vor, dass IBC und LayerZero keine Konkurrenten sein müssen, sondern geschichtet werden können – zum Beispiel könnte LayerZero einen IBC Light Client als eines seiner DVNs verwenden, wenn verfügbar. Eine solche gegenseitige Befruchtung ist wahrscheinlich, wenn der Bereich reift.

Komponierbarkeit und vereinheitlichte Liquidität: Aus der Sicht eines DeFi-Benutzers ist das ultimative Ziel, dass Liquidität Chain-agnostisch wird. Wir sehen bereits Schritte: Mit Omnichain-Token (OFTs) müssen Sie sich keine Sorgen machen, auf welcher Chain Ihre Token-Version ist, und mit Cross-Chain-Geldmärkten können Sie auf jeder Chain gegen Kollateral auf einer anderen leihen. Die architektonischen Entscheidungen beeinflussen direkt das Vertrauen der Benutzer in diese Systeme. Wenn ein Brücken-Hack auftritt (wie es historisch bei einigen Multisig-Brücken der Fall war), bricht dies das Vertrauen und damit die Liquidität – Benutzer ziehen sich an sicherere Orte zurück oder verlangen Risikoprämien. Daher werden Protokolle, die konsequent Sicherheit demonstrieren, die größten Liquiditätspools untermauern. Cosmos' Interchain Security und IBC haben einen Weg gezeigt: Mehrere Orderbücher und AMMs über Zonen hinweg bilden im Wesentlichen einen großen Markt, weil Transfers vertrauenslos und schnell sind. LayerZeros Stargate zeigte einen anderen: Ein vereinheitlichter Liquiditätspool kann die Transfers vieler Chains bedienen, aber es erforderte, dass Benutzer LayerZeros Sicherheitsannahme (Oracle+Relayer oder DVNs) vertrauen. Da LayerZero v2 jedem Pool ermöglicht, noch höhere Sicherheit einzustellen (z. B. die Verwendung mehrerer großer Validator-Netzwerke zur Verifizierung jedes Transfers), reduziert es die Vertrauenslücke. Die langfristige Lebensfähigkeit von Multi-Chain-DeFi hängt wahrscheinlich davon ab, dass Interoperabilitätsprotokolle unsichtbar und dennoch zuverlässig sind – ähnlich wie Internetnutzer nicht über TCP/IP nachdenken, sollten Krypto-Nutzer sich keine Sorgen machen müssen, welche Brücke oder welches Messaging-System eine dApp verwendet. Das wird geschehen, wenn Sicherheitsmodelle robust genug sind, dass Ausfälle äußerst selten sind und wenn es eine gewisse Konvergenz oder Komponierbarkeit zwischen diesen Interoperabilitätsnetzwerken gibt.

Interoperabilität der Interoperabilität: Es ist denkbar, dass wir in einigen Jahren nicht mehr von LayerZero vs. Hyperlane vs. IBC als getrennten Bereichen sprechen werden, sondern von einem geschichteten System. Zum Beispiel könnte ein Ethereum-Rollup über Polymer eine IBC-Verbindung zu einem Cosmos-Hub haben, und dieser Cosmos-Hub könnte auch einen LayerZero-Endpoint haben, der es ermöglicht, Nachrichten vom Rollup über einen sicheren IBC-Kanal in LayerZeros Netzwerk zu übertragen. Hyperlane könnte sogar als Fallback oder Aggregation fungieren: Eine App könnte sowohl einen IBC-Proof als auch eine Hyperlane AVS-Signatur für ultimative Sicherheit verlangen. Diese Art der Aggregation von Sicherheit über Protokolle hinweg könnte selbst die fortschrittlichsten Bedrohungsmodelle adressieren (es ist viel schwieriger, gleichzeitig einen IBC Light Client und eine unabhängige Restaked-Multisig usw. zu untergraben). Solche Kombinationen würden natürlich Komplexität und Kosten erhöhen, sodass sie für hochwertige Kontexte reserviert wären.

Governance und Dezentralisierung: Jedes Modell legt unterschiedliche Macht in die Hände verschiedener Akteure – IBC in die Hände der Chain-Governance, LayerZero in die Hände der App-Entwickler (und indirekt der von ihnen gewählten DVN-Betreiber) und Hyperlane in die Hände der Brücken-Validatoren und möglicherweise Restaker. Die langfristige interoperable Landschaft muss sicherstellen, dass keine einzelne Partei oder kein Kartell Cross-Chain-Transaktionen dominieren kann. Dies ist ein Risiko, zum Beispiel wenn ein Protokoll allgegenwärtig wird, aber von einer kleinen Gruppe von Akteuren kontrolliert wird; es könnte zu einem Engpass werden (analog zu zentralisierten Internetdienstanbietern). Der Weg, dies zu mindern, besteht darin, die Messaging-Netzwerke selbst zu dezentralisieren (mehr Relayer, mehr DVNs, mehr Validatoren – alle genehmigungslos beizutreten) und alternative Pfade zu haben. In dieser Hinsicht hat IBC den Vorteil, ein offener Standard mit vielen unabhängigen Teams zu sein, und LayerZero und Hyperlane bewegen sich beide darauf zu, die Beteiligung Dritter zu erhöhen (z. B. kann jeder ein LayerZero DVN oder einen Hyperlane Validator betreiben). Es ist wahrscheinlich, dass Wettbewerb und offene Beteiligung diese Dienste ehrlich halten werden, ähnlich wie Miner/Validatoren in L1s die Basisschicht dezentral halten. Der Markt wird auch mit den Füßen abstimmen: Wenn sich eine Lösung als unsicher oder zu zentralisiert erweist, können Entwickler zu einer anderen migrieren (insbesondere wenn Brückenstandards selbst interoperabler werden).

Zusammenfassend lässt sich sagen, dass die Sicherheitsarchitekturen von LayerZero v2, Hyperlane und IBC 3.0 jeweils dazu beitragen, die Vision von Multi-Chain-DeFi Wirklichkeit werden zu lassen, jedoch mit unterschiedlichen Philosophien. Light Clients priorisieren Vertrauenslosigkeit und Neutralität, Multisigs priorisieren Pragmatismus und einfache Integration, und aggregierte Ansätze priorisieren Anpassung und Adaptierbarkeit. Die Multi-Chain-DeFi-Landschaft der Zukunft wird wahrscheinlich eine Kombination dieser nutzen: kritische Infrastruktur und hochwertige Transfers, die durch vertrauensminimierte oder wirtschaftlich gesicherte Methoden gesichert sind, und flexible Middleware, um sich mit der langen Reihe neuer Chains und Apps zu verbinden. Mit diesen Elementen werden Benutzer vereinheitlichte Liquidität und Cross-Chain-Komponierbarkeit mit der gleichen Zuversicht und Leichtigkeit genießen, als würden sie eine einzige Chain verwenden. Der Weg nach vorne ist einer der Konvergenz – nicht unbedingt der Protokolle selbst, sondern der Ergebnisse: eine Welt, in der Interoperabilität sicher, nahtlos und Standard ist. Dies zu erreichen, erfordert weiterhin rigorose Ingenieursarbeit (um Exploits zu vermeiden), kollaborative Governance (um Standards wie IBC oder universelle Vertragsschnittstellen festzulegen) und vielleicht am wichtigsten, einen iterativen Sicherheitsansatz, der das Beste aus allen Welten vereint: Mathematik, wirtschaftliche Anreize und intelligentes Design. Der Endzustand könnte die oft zitierte Analogie wirklich erfüllen: Blockchains, die wie Netzwerke im Internet miteinander verbunden sind, wobei Protokolle wie LayerZero, Hyperlane und IBC die Omnichain-Autobahn bilden, auf der DeFi auf absehbare Zeit fahren wird.

Quellen:

  • LayerZero v2 Architektur und DVN-Sicherheit – LayerZero V2 Deep Dive; Flare x LayerZero V2 announcement
  • Hyperlane Multisig und modulares ISM – Hyperlane Docs: Validators; Tiger Research on Hyperlane; Hyperlane restaking (AVS) announcement
  • IBC 3.0 Light Clients und Funktionen – IBC Protocol Overview; 3Commas Cosmos 2025 (IBC 3.0)
  • Vergleich der Vertrauensannahmen – Nosleepjohn (Hyperlane) on bridge tradeoffs; IBC vs bridges (Polymer blog)
  • DeFi-Beispiele (Stargate, ICA, etc.) – Flare blog on LayerZero (Stargate volume); IBC use cases (Stride liquid staking); LayerZero Medium (OFT and OApp standards); Hyperlane use cases
  • Adoption und Statistiken – Flare x LayerZero (cross-chain messages, volume); Range.org on IBC volume; Blockchain Capital on IBC vs bridges; LayerZero blog (15+ DVNs); IBC testimonials (Osmosis, etc.).
Share on Twitter