Ursprünglicher Autor: Shi Khai Wei, Raghav Agarwal
Originalzusammenstellung: Kxp, BlockBeats
Einführung
Multi-Chain ist der zukünftige Entwicklungstrend, und das Streben nach Skalierbarkeit hat Ethereum zum Aufbau der Rollup-Technologie geführt. Bei der Umstellung auf modulare Blockchains wurde erneut auf Lisk geachtet. Und in nicht allzu ferner Zukunft hören wir Gerüchte über anwendungsspezifische Rollups, L3s und Souveräne Ketten. Dies alles geht jedoch mit der Fragmentierung einher, und aktuelle Cross-Chain-Brücken sind oft in ihrer Funktionalität eingeschränkt und verlassen sich aus Sicherheitsgründen auf vertrauenswürdige Unterzeichner.
Wie wird das vernetzte Web3 letztendlich aussehen? Wir glauben, dass sich Cross-Chain-Brücken letztendlich zu Cross-Chain-Messaging- oder „Arbitrary Messaging“ (AMP)-Protokollen entwickeln werden, um neue Anwendungsszenarien zu erschließen, die es Anwendungen ermöglichen, beliebige Nachrichten zwischen der Quellkette und der Zielkette zu übertragen. Wir werden auch die Entstehung einer „Vertrauensmechanismuslandschaft“ erleben, in der Entwickler verschiedene Kompromisse zwischen Benutzerfreundlichkeit, Komplexität und Sicherheit eingehen werden.
Jede AMP-Lösung muss zwei Schlüsselfunktionen implementieren:
- Überprüfung: Möglichkeit, die Gültigkeit von Nachrichten aus der Quellkette in der Zielkette zu überprüfen
- Lebendigkeit: die Fähigkeit, Informationen von der Quellkette an die Zielkette weiterzugeben
Leider ist eine 100 % vertrauenswürdige Verifizierung nicht realistisch. Benutzer müssen sich dafür entscheiden, Code, Spieltheorie, Menschen (oder Entitäten) oder einer Kombination davon zu vertrauen, je nachdem, ob die Verifizierung in der Kette oder außerhalb der Kette erfolgt.
In diesem Artikel unterteilen wir den gesamten Interoperabilitätsbereich vertikal in vertrauensbasierte Mechanismen und integrationsbasierte Architekturen.
Vertrauensmechanismus:
-
Vertrauen Sie Code und Mathematik: Für diese Lösungen gibt es einen On-Chain-Beweis, den jeder überprüfen kann. Diese Lösungen basieren normalerweise auf Light Clients, um den Konsens der Quellkette in der Zielkette oder die Gültigkeit des Zustandsübergangs der Quellkette in der Zielkette zu überprüfen. Die Verifizierung durch Light-Clients kann die Effizienz durch wissensfreie Beweise verbessern, indem beliebig lange Berechnungen für die Offline-Durchführung komprimiert werden und gleichzeitig eine einfache On-Chain-Verifizierung zum Nachweis der Berechnungsergebnisse bereitgestellt wird.
-
Vertrauensspieltheorie: Wenn ein Benutzer/eine Anwendung einem Dritten oder einem Drittnetzwerk vertrauen muss, um die Authentizität einer Transaktion zu gewährleisten, sind zusätzliche Vertrauensannahmen erforderlich. Die Sicherheit dieser Mechanismen kann durch den Einsatz erlaubnisloser Netzwerke und Spieltheorien wie wirtschaftlicher Anreize und optimistischer Sicherheit verbessert werden.
-
Vertrauen in Menschen: Diese Lösungen basieren auf der Ehrlichkeit oder Unabhängigkeit der Mehrheit der Validatoren, die unterschiedliche Informationen kommunizieren. Sie müssen nicht nur dem Konsens der beiden interaktiven Ketten vertrauen, sondern auch einem Dritten vertrauen. Das einzige Risiko besteht in diesem Fall in der Reputation der beteiligten Unternehmen. Eine Transaktion gilt als gültig, wenn genügend beteiligte Unternehmen der Gültigkeit zustimmen.
Es ist erwähnenswert, dass alle Lösungen ein gewisses Maß an Vertrauen in Code und Menschen erfordern. Jede Lösung mit fehlerhaftem Code kann von Hackern ausgenutzt werden, und jede Lösung enthält einen menschlichen Faktor bei der Einrichtung, Aktualisierung oder Wartung der Codebasis.
Integrierte Architektur:
-
Peer-to-Peer-Modell: Zwischen jeder Quellkette und jeder Zielkette muss ein dedizierter Kommunikationskanal eingerichtet werden.
-
Zentrales Hub-Modell: Es muss ein Kommunikationskanal mit dem zentralen Hub eingerichtet werden, um eine Verbindung mit allen anderen mit dem Hub verbundenen Blockchains zu erreichen.
Das Peer-to-Peer-Modell ist relativ schwer zu skalieren, da jede verbundene Blockchain einen gepaarten Kommunikationskanal erfordert. Die Entwicklung dieser Kanäle kann für Blockchains mit unterschiedlichem Konsens und Frameworks eine Herausforderung darstellen. Gepaarte Bridges bieten jedoch mehr Flexibilität, um die Konfiguration bei Bedarf anzupassen. Es sind auch hybride Ansätze möglich, wie etwa Multi-Hop-Routing über Relays unter Verwendung des Inter-Blockchain Communication (IBC)-Protokolls, das die Notwendigkeit einer direkten Peer-to-Peer-Kommunikation überflüssig macht, aber höhere Komplexitäten in Bezug auf Sicherheit, Latenz usw. mit sich bringt kosten.
Vertrauenskodex und Mathematik
Um sich bei Vertrauensannahmen nur auf Code/Mathematik zu verlassen, können Light-Clients verwendet werden, um den Konsens der Quellkette in der Zielkette zu überprüfen. Light-Clients/Nodes sind Software, die sich mit vollständigen Nodes verbinden, um mit der Blockchain zu interagieren. Light-Clients in der Zielkette speichern normalerweise einen Verlauf (in der Reihenfolge) der Blockheader der Quellkette, der zur Überprüfung von Transaktionen ausreicht. Ein Off-Chain-Proxy (wie ein Relay) überwacht Ereignisse in der Quellkette, generiert kryptografische Einschlussnachweise und leitet sie zusammen mit Blockheadern an Light-Clients in der Zielkette weiter. Da Light-Clients Blockheader nacheinander speichern, wobei jeder einen Merkle-Root-Hash enthält, der zum Nachweis des Status verwendet werden kann, sind sie in der Lage, Transaktionen zu verifizieren. Hier finden Sie einen Überblick über die Hauptmerkmale dieses Ansatzes:
Sicherheit
Bei der Initialisierung von Light-Clients werden Vertrauensannahmen eingeführt. Beim Erstellen eines neuen Light-Clients wird dieser ab einer bestimmten Höhe in der anderen Kette mit einem Blockheader initialisiert. Es besteht jedoch die Möglichkeit, dass die bereitgestellten Blockheader falsch sind, sodass Light-Clients mit gefälschten Blockheadern getäuscht werden können. Sobald ein Light-Client initialisiert ist, werden keine weiteren Vertrauensannahmen eingeführt. Es ist jedoch zu beachten, dass dieser Initialisierungsprozess auf einer schwachen Vertrauensannahme beruht, da er von jedem überprüft werden kann. Darüber hinaus besteht eine Lebendigkeitsannahme für die kontinuierliche Informationsübertragung des Relais.
implementieren
Die Implementierung von Light Clients hängt von der Verfügbarkeit der für die Authentifizierung erforderlichen kryptografischen Grundelemente ab. Wenn Ketten des gleichen Typs verbunden sind, das heißt, dass sie das gleiche Anwendungsframework und den gleichen Konsensalgorithmus verwenden, sind die Light-Client-Implementierungen an beiden Enden gleich. Beispielsweise verwenden alle Cosmos SDK-basierten Ketten das Inter-Blockchain Communication (IBC)-Protokoll. Andererseits sind Implementierungen wie Light Clients auf die Unterstützung der für die Authentifizierung erforderlichen kryptografischen Grundelemente angewiesen. Wenn die gleichen Kettentypen verbunden sind, d. h. sie das gleiche Anwendungsframework und den gleichen Konsensalgorithmus verwenden, sind die Light-Client-Implementierungen auf beiden Seiten gleich. Beispielsweise wird das Inter-Blockchain Communication (IBC)-Protokoll für alle Cosmos SDK-basierten Ketten verwendet. Wenn andererseits zwei verschiedene Arten von Ketten verbunden sind, beispielsweise unterschiedliche Anwendungsframeworks oder Konsenstypen, wird die Light-Client-Implementierung unterschiedlich sein. Ein Beispiel ist Composable Finance, das daran arbeitet, die Cosmos SDK-Kette über IBC mit dem Substrate-Anwendungsframework des Polkadot-Ökosystems zu verbinden. Dies erfordert einen Tendermint Light-Client in der Substrate-Kette und einen „beefy“ Light-Client in der Cosmos SDK-Kette. Kürzlich stellten sie die erste Verbindung zwischen Polkadot und Kusama über IBC her.
Herausforderung
Die Ressourcenintensität ist eine wichtige Herausforderung. Das Ausführen von Light-Client-Paaren in allen Ketten kann teuer sein, da Schreibvorgänge auf der Blockchain teuer sind. Darüber hinaus ist die Ressourcenintensität bei dynamischen Verifizierern eine wichtige Herausforderung. Es kann teuer sein, gepaarte Light-Clients auf allen Ketten auszuführen, da Schreibvorgänge auf der Blockchain teuer sind. Außerdem ist es für Ketten mit dynamischen Validatorsätzen (wie Ethereum) nicht möglich, Light-Clients auszuführen.
Die Skalierbarkeit ist eine weitere Herausforderung. Die Implementierung von Light Clients variiert je nach Architektur der Kette, was die Skalierung und Verbindung verschiedener Ökosysteme erschwert.
Code-Schwachstellen stellen ein potenzielles Risiko dar, da Fehler im Code zu Schwachstellen führen können. Beispielsweise hat der BNB-Kettenverstoß im Oktober 2022 eine kritische Sicherheitslücke aufgedeckt, die alle IBC-fähigen Ketten betrifft.
Um die Kosten und die Praktikabilität der Ausführung paarweiser Light-Clients in allen Ketten zu berücksichtigen, können alternative Lösungen wie Zero-Knowledge (ZK)-Proofs eingesetzt werden, um die Notwendigkeit des Vertrauens Dritter zu beseitigen.
Wissensfreie Beweise als Lösung für das Vertrauen Dritter
Mithilfe wissensfreier Beweise kann die Gültigkeit von Zustandsübergängen der Quellkette in der Zielkette überprüft werden. Im Vergleich zur Durchführung der gesamten Berechnung in der Kette führen ZK-Beweise nur den Verifizierungsteil der Berechnung in der Kette durch, während die eigentliche Berechnung außerhalb der Kette erfolgt. Dieser Ansatz ermöglicht eine schnellere und effizientere Überprüfung als die erneute Ausführung der ursprünglichen Berechnung. Einige Beispiele sind Polymer Labs‘; Polymer ZK-IBC; und Succinct Labs‘; Telepathy. Polymer entwickelt Multi-Hop-IBCs, um die Konnektivität zu verbessern und die Anzahl der erforderlichen gepaarten Verbindungen zu reduzieren.
Zu den wichtigsten Aspekten des Mechanismus gehören:
Sicherheit
Die Sicherheit von zk-SNARKs beruht auf elliptischen Kurven, während zk-STARKs auf Hash-Funktionen basieren. zk-SNARKs erfordern möglicherweise eine vertrauenswürdige Einrichtung, einschließlich der Erstellung von Anfangsschlüsseln, die zum Generieren von Beweisen für die Verifizierung verwendet werden. Der Schlüssel besteht darin, das Geheimnis des Setup-Ereignisses zu zerstören, um zu verhindern, dass Transaktionen durch Fälschung authentifiziert werden. Sobald die vertrauenswürdige Einrichtung abgeschlossen ist, werden keine weiteren Vertrauensannahmen eingeführt. Darüber hinaus machen neuere ZK-Frameworks (wie Halo und Halo;2;) die Notwendigkeit einer vertrauenswürdigen Einrichtung vollständig überflüssig.
implementieren
Es gibt eine Vielzahl von ZK-Prüfschemata wie SNARK, STARK, VPD und SNARG, wobei SNARK derzeit das am weitesten verbreitete ist. Verschiedene SNARK-Prüfungsframeworks wie Groth;16, Plonk, Marlin, Halo und Halo;2; bieten Kompromisse in Bezug auf Beweisgröße, Beweiszeit, Überprüfungszeit, Speicherbedarf und vertrauenswürdige Setup-Anforderungen. Es sind auch rekursive ZK-Beweise entstanden, die es ermöglichen, die Beweisarbeitslast auf mehrere Computer statt auf einen einzelnen zu verteilen. Um Gültigkeitsnachweise zu generieren, müssen die folgenden Kernprimitive implementiert werden: Überprüfen des von einem Validator verwendeten Signaturschemas, Speichern von Beweisen des öffentlichen Schlüssels des Validators in der in der Kette gespeicherten Validator-Set-Verpflichtung und Verfolgen des Validator-Sets, was möglicherweise der Fall ist häufig ändern.
Herausforderung
Die Implementierung verschiedener Signaturschemata in zkSNARKs erfordert die Implementierung von Arithmetik außerhalb der Domäne und komplexer elliptischer Kurvenoperationen, was nicht trivial ist und je nach Framework und Konsens verschiedener Ketten unterschiedliche Implementierungen erfordern kann. Die Prüfung von ZK-Schaltkreisen ist eine anspruchsvolle und fehleranfällige Aufgabe. Entwickler müssen mit domänenspezifischen Sprachen wie Circom, Cairo und Noir vertraut sein oder Schaltkreise direkt implementieren, was beides eine Herausforderung sein und die Einführung verlangsamen kann. Wenn sich der Zeit- und Arbeitsaufwand als sehr hoch erweist, kann es sein, dass er nur von dedizierten Teams und dedizierter Hardware bearbeitet wird, was möglicherweise zu einer Zentralisierung führt. Auch längere Proof-Erstellungszeiten führen zu Verzögerungen. Techniken wie Incrementally Verifiable Computation (IVC) können die Beweiszeiten optimieren, viele davon befinden sich jedoch noch in der Forschungsphase und warten auf ihre Implementierung. Längere Überprüfungszeiten und Arbeitsbelastungen erhöhen die Kosten in der Kette.
Vertrauensspieltheorie
Auf der Spieltheorie basierende Interoperabilitätsprotokolle können grob in zwei Kategorien unterteilt werden, je nachdem, wie sie Anreize für ehrliches Verhalten der teilnehmenden Einheiten schaffen:
Die erste Kategorie ist ein wirtschaftlicher Sicherheitsmechanismus, bei dem mehrere externe Akteure (z. B. Validatoren) zusammenarbeiten, um einen Konsens zur Bestimmung des aktualisierten Zustands der Quellkette zu erzielen. Um ein Validator zu werden, müssen die Teilnehmer eine bestimmte Menge an Token einsetzen, die im Falle böswilliger Aktivitäten reduziert werden kann. In einem erlaubnislosen Setup kann jeder Anteile sammeln und Validator werden. Darüber hinaus werden den Prüfern, die das Protokoll befolgen, wirtschaftliche Anreize wie Blockbelohnungen geboten, um wirtschaftliche Anreize für ehrliches Verhalten zu gewährleisten. Wenn jedoch der potenziell gestohlene Betrag den eingesetzten Betrag übersteigt, können die Teilnehmer Absprachen treffen, um Gelder zu stehlen. Beispiele für Protokolle, die wirtschaftliche Sicherheitsmechanismen nutzen, sind Axelar und Celer IM.
Die zweite Kategorie sind optimistische Sicherheitsmechanismen, bei denen die Lösung auf der Annahme beruht, dass nur eine kleine Anzahl von Blockchain-Teilnehmern ehrlich ist und die Regeln des Protokolls befolgt. Bei diesem Ansatz fungiert ein ehrlicher Teilnehmer als Garant. Eine optimale Lösung ermöglicht es beispielsweise jedem, Betrugsnachweise einzureichen. Obwohl ein finanzieller Anreiz besteht, kann ein ehrlicher Beobachter eine betrügerische Transaktion übersehen. Auch optimistische Rollups nutzen diesen Mechanismus. Nomad und ChainLink CCIP sind Beispiele für Protokolle, die optimistische Sicherheitsmechanismen verwenden. Im Fall von Nomad konnten Beobachter Betrug nachweisen, obwohl sie zum Zeitpunkt des Schreibens auf der Whitelist standen. ChainLink CCIP plant, ein Betrugsbekämpfungsnetzwerk zu nutzen, das aus einem verteilten Oracle-Netzwerk besteht, um böswillige Aktivitäten zu erkennen. Die Implementierung des Betrugsbekämpfungsnetzwerks von CCIP ist jedoch unbekannt.
Sicherheit
Im Hinblick auf die Sicherheit beruhen beide Mechanismen auf der erlaubnisfreien Beteiligung von Prüfern und Beobachtern, um die spieltheoretische Gültigkeit sicherzustellen. Bei einem wirtschaftlichen Sicherheitsmechanismus sind Gelder anfälliger, wenn der eingesetzte Betrag geringer ist als der Betrag, der gestohlen werden könnte. Andererseits kann bei optimistischen Sicherheitsmechanismen die Annahme des Minderheitenvertrauens ausgenutzt werden, wenn niemand einen Betrugsbeweis vorlegt oder wenn Beobachter von Berechtigungen kompromittiert oder entfernt werden. Im Gegensatz dazu sind wirtschaftliche Sicherheitsmechanismen zur Aufrechterhaltung der Sicherheit weniger auf Lebendigkeit angewiesen.
implementieren
Hinsichtlich der Implementierung sieht ein Ansatz eine Zwischenkette mit eigenen Validatoren vor. Bei diesem Setup überwacht eine Gruppe externer Validatoren die Quellkette und erzielt einen Konsens über die Gültigkeit einer Transaktion, wenn ein Aufruf erkannt wird. Sobald ein Konsens erreicht ist, liefern sie Beweise für die Zielkette. Validatoren müssen in der Regel eine bestimmte Menge an Token einsetzen, die reduziert werden kann, wenn böswillige Aktivitäten erkannt werden. Beispiele für Protokolle, die diese Implementierungsmethode verwenden, sind Axelar Network und Celer IM.
Eine andere Implementierungsmethode beinhaltet die Verwendung von Off-Chain-Proxys. Off-Chain-Proxys werden verwendet, um optimistische Rollups-ähnliche Lösungen zu implementieren. Innerhalb eines vordefinierten Zeitfensters können diese Off-Chain-Proxys Betrugsnachweise vorlegen und bei Bedarf Transaktionen rückgängig machen. Nomad verlässt sich beispielsweise auf unabhängige Off-Chain-Proxys, um Header und kryptografische Beweise weiterzuleiten. Andererseits plant ChainLink CCIP, sein bestehendes Oracle-Netzwerk zu nutzen, um kettenübergreifende Transaktionen zu überwachen und zu bestätigen.
Stärken und Herausforderungen
Ein wesentlicher Vorteil spieltheoretischer AMP-Lösungen ist die Ressourcenoptimierung, da der Verifizierungsprozess typischerweise außerhalb der Kette erfolgt, wodurch der Ressourcenbedarf reduziert wird. Darüber hinaus sind diese Mechanismen skalierbar, da der Konsensmechanismus für verschiedene Arten von Ketten gleich bleibt und problemlos auf heterogene Blockchains erweitert werden kann.
Mit diesen Mechanismen sind auch mehrere Herausforderungen verbunden. Wenn die Mehrheit der Prüfer zusammenarbeitet, können Vertrauensannahmen ausgenutzt werden, um Gelder zu stehlen, was Gegenmaßnahmen wie quadratische Abstimmungen und Betrugsnachweise erfordert. Darüber hinaus bringen Lösungen, die auf optimistischer Sicherheit basieren, Komplexitäten in Bezug auf Endgültigkeit und Lebendigkeit mit sich, da Benutzer und Anwendungen auf betrügerische Fenster warten müssen, um die Gültigkeit von Transaktionen sicherzustellen.
Vertraue den Menschen
Lösungen, die Vertrauen in menschliche Wesen erfordern, können ebenfalls grob in zwei Kategorien unterteilt werden:
-
Reputationssicherheit: Diese Lösungen basieren auf Multi-Signatur-Implementierungen, bei denen mehrere Entitäten Transaktionen überprüfen und signieren. Sobald der Mindestschwellenwert erreicht ist, gilt die Transaktion als gültig. Hierbei wird davon ausgegangen, dass die meisten Unternehmen ehrlich sind und dass die Transaktion gültig ist, wenn die Mehrheit dieser Unternehmen eine bestimmte Transaktion unterzeichnet. Hier steht lediglich die Reputation der beteiligten Unternehmen auf dem Spiel. Einige Beispiele sind: Multichain (Anycall V;6;) und Wormhole. Aufgrund von Smart-Contract-Schwachstellen können immer noch Schwachstellen bestehen, wie der Wormhole-Hack Anfang 2022 gezeigt hat.
-
Unabhängigkeit: Diese Lösungen teilen den gesamten Messaging-Prozess in zwei Teile auf und verlassen sich auf verschiedene unabhängige Einheiten, um die beiden Prozesse zu verwalten. Hierbei wird davon ausgegangen, dass diese beiden Einheiten unabhängig voneinander sind und nicht kooperieren können. LayerZero ist ein Beispiel. Blockheader werden bei Bedarf über verteilte Orakel übertragen und Transaktionsnachweise werden über Relayer gesendet. Wenn der Nachweis mit dem Header übereinstimmt, gilt die Transaktion als gültig. Während der Nachweis einer Übereinstimmung auf Code/Mathematik beruht, müssen die Teilnehmer darauf vertrauen, dass diese Entitäten unabhängig bleiben und keine böswilligen Absichten verfolgen. Anwendungen, die auf „LayerZero“ basieren, können ihre Oracles und Relays auswählen (oder ihre eigenen Oracles/Relays hosten) und so das Risiko für einzelne Oracles/Relays begrenzen. Endbenutzer müssen darauf vertrauen, dass LayerZero, Dritte oder die Anwendung selbst Oracles und Relays unabhängig und ohne böswillige Absicht ausführen.
Bei beiden Ansätzen verhindert die Reputation der beteiligten Drittparteien böswilliges Verhalten. Hierbei handelt es sich in der Regel um angesehene Einheiten in der Validator- und Oracle-Community. Wenn sie sich böswillig verhalten, riskieren sie einen Reputationsschaden und negative Auswirkungen auf andere Geschäftsaktivitäten.
Zusätzliche Überlegungen zu AMP-Lösungen
Bei der Betrachtung der Sicherheit und Benutzerfreundlichkeit einer AMP-Lösung müssen wir auch Details berücksichtigen, die über die grundlegende Mechanik hinausgehen. Da es sich um Komponenten handelt, die sich im Laufe der Zeit ändern können, haben wir sie nicht in den Gesamtvergleich einbezogen.
Codeintegrität
Bei jüngsten Hacks wurden Codefehler ausgenutzt, was die Notwendigkeit einer robusten Prüfung, Fehlerprämien und vielfältiger Client-Implementierungen verdeutlichte. Wenn alle Verifizierer (in wirtschaftlicher/optimistischer/Reputationssicherheit) denselben Client (Software zur Verifizierung) ausführen, erhöht dies die Abhängigkeit von einer einzigen Codebasis und verringert die Clientvielfalt. Beispielsweise verlässt sich Ethereum auf mehrere Ausführungsclients wie Geth, Netermind, Erigon, Besu, Akula. Mehrere Implementierungen in verschiedenen Sprachen können die Vielfalt erhöhen, da kein einzelner Client das Netzwerk dominiert, wodurch ein potenzieller Single Point of Failure eliminiert wird. Mehrere Clients können auch dazu beitragen, die Lebensfähigkeit aufrechtzuerhalten, falls eine kleine Anzahl von Validatoren/Unterzeichnern/Light-Clients aufgrund eines Fehlers/Angriffs in einer bestimmten Implementierung ausfällt.
Einrichtung und Aufrüstbarkeit
Benutzer und Entwickler müssen wissen, ob Validatoren/Beobachter dem Netzwerk ohne Erlaubnis beitreten können, andernfalls wird das Vertrauen von Entitäten verborgen, die sich für die Erlaubnis entscheiden. Upgrades auf Smart Contracts können auch Schwachstellen mit sich bringen, die zu Angriffen führen und möglicherweise sogar Vertrauensannahmen verändern können. Zur Minderung dieser Risiken können verschiedene Lösungen implementiert werden. Beispielsweise kann in der aktuellen Instanziierung das Axelar-Gateway aktualisiert werden, erfordert jedoch die Genehmigung des Offline-Komitees (4/8-Schwelle). In naher Zukunft plant Axelar jedoch, von allen Validatoren zu verlangen, dass sie alle Upgrades des Gateways gemeinsam genehmigen. Die Kernverträge von Wormhole sind aktualisierbar und werden über das On-Chain-Governance-System von Wormhole verwaltet. LayerZero verlässt sich auf unveränderliche Smart Contracts und unveränderliche Bibliotheken, um jegliche Upgrades zu vermeiden, aber neue Bibliotheken können gepusht werden, Dapps, die Standardeinstellungen festlegen, erhalten neuere Versionen, Dapps, die die Version manuell festlegen, müssen sie auf die neue Version setzen.
Maximaler extrahierbarer Wert (MEV)
Unterschiedliche Blockchains werden nicht durch eine gemeinsame Uhr synchronisiert und haben unterschiedliche Endgültigkeitszeiten. Daher können die Ausführungsreihenfolge und das Timing auf der Zielkette von Kette zu Kette variieren. In einer kettenübergreifenden Welt ist MEV schwer klar zu definieren. Es führt einen Kompromiss zwischen Lebendigkeit und Ausführungsreihenfolge ein. Ein geordneter Kanal gewährleistet die Zustellung von Nachrichten in der richtigen Reihenfolge. Wenn bei einer Nachricht jedoch eine Zeitüberschreitung auftritt, wird der Kanal geschlossen. Eine andere Anwendung bevorzugt möglicherweise keine Bestellung, die Zustellung anderer Nachrichten bleibt jedoch davon unberührt.
Sicherheit der Lieferkette
Idealerweise sollten AMP-Lösungen warten, bis die Quellkette ihre Endgültigkeit erreicht hat, bevor sie die Statusinformationen der Quellkette an eine oder mehrere Zielketten übertragen. Dadurch wird sichergestellt, dass Blöcke in der Quellkette kaum rückgängig gemacht oder geändert werden können. Viele Lösungen bieten jedoch Instant Messaging und gehen von Vertrauensannahmen hinsichtlich der Endgültigkeit aus, um das beste Benutzererlebnis zu bieten. Wenn in diesem Fall die Quellkette nach der Zustellung der Nachricht und der Übergabe des Bridge-Assets einem Status-Rollback unterzogen wird, kann dies zu Situationen wie einer doppelten Ausgabe der Bridge-Mittel führen. AMP-Lösungen können dieses Risiko auf verschiedene Arten bewältigen, indem sie beispielsweise unterschiedliche Endgültigkeitsannahmen für verschiedene Ketten festlegen, je nachdem, wie dezentralisiert die Kette ist, oder indem sie Kompromisse zwischen Geschwindigkeit und Sicherheit eingehen. Bridges, die AMP-Lösungen nutzen, können die Menge der überbrückten Assets begrenzen, bevor die Quellkette ihre Endgültigkeit erreicht.
Trends und Zukunftsaussichten Anpassbare und anbaubare Sicherheit
Um vielfältige Anwendungsfälle besser bedienen zu können, werden AMP-Lösungen dazu angeregt, Entwicklern mehr Flexibilität zu bieten. Axelar führt eine Methode ein, um die Skalierbarkeit von Nachrichten und Validierung zu ermöglichen, ohne die Logik der Anwendungsebene zu ändern. HyperLane V2 führt Module ein, die es Entwicklern ermöglichen, aus mehreren Optionen wie ökonomischer Sicherheit, optimistischer Sicherheit, dynamischer Sicherheit und hybrider Sicherheit zu wählen. CelerIM bietet zusätzlich zur wirtschaftlichen Sicherheit zusätzliche optimistische Sicherheit. Viele Lösungen warten auf eine vordefinierte Mindestanzahl von Blockbestätigungen in der Quellkette, bevor sie eine Nachricht übermitteln. Mit LayerZero können Entwickler diese Parameter aktualisieren. Wir gehen davon aus, dass einige AMP-Lösungen weiterhin mehr Flexibilität bieten werden, aber diese Designoptionen erfordern einige Diskussionen. Sollten Anwendungen in der Lage sein, ihre Sicherheit zu konfigurieren, in welchem Umfang und was passiert, wenn Anwendungen mit einem suboptimalen Design entworfen werden? Das Bewusstsein der Benutzer für die grundlegenden Konzepte hinter der Sicherheit wird wahrscheinlich immer wichtiger. Letztendlich sehen wir eine Aggregation und Abstraktion von AMP-Lösungen vor, möglicherweise in Form einer Kompositions- oder „Add-on“-Sicherheit.
Die Reife des „Trust Code and Math“-Mechanismus
In einem idealen Endstadium werden alle kettenübergreifenden Nachrichten durch den Einsatz von Zero-Knowledge-Beweisen (ZK) vertrauenswürdig minimiert. Wir haben gesehen, wie ähnliche Projekte wie Polymer Labs und Succinct Labs entstanden sind. Multichain hat außerdem ein zkRouter-Whitepaper zur Interoperabilität über ZK-Proofs veröffentlicht. Mit der kürzlich angekündigten Axelar Virtual Machine können Entwickler den Interchain Amplifier nutzen, um ohne Erlaubnis neue Verbindungen zum Axelar-Netzwerk herzustellen. Sobald beispielsweise starke Light-Clients und ZK-Proofs für den Stand von Ethereum entwickelt wurden, können Entwickler diese problemlos in das Axelar-Netzwerk integrieren, um bestehende Verbindungen zu ersetzen oder zu verbessern. Celer Network kündigte Brevis an, eine kettenübergreifende ZK-Datennachweisplattform, die es dApps und Smart Contracts ermöglicht, auf beliebige Daten auf mehreren Blockchains zuzugreifen, diese zu berechnen und zu nutzen. Celer implementierte ein benutzerorientiertes Asset zkBridge unter Verwendung der ZK-Light-Client-Schaltung für die kettenübergreifende Verbindung zwischen dem Ethereum-Goerli-Testnetz und dem BNB-Chain-Testnetz. LayerZero diskutiert in seiner Dokumentation die Möglichkeit, in Zukunft neue optimierte Proof-Message-Bibliotheken hinzuzufügen. Neuere Projekte wie Lagrange untersuchen die Aggregation mehrerer Beweise aus mehreren Quellketten, während Herodotus die Speicherung von Beweisen mit ZK-Beweisen ermöglicht. Dieser Übergang wird jedoch einige Zeit dauern, da dieser Ansatz nur schwer auf Blockchains zu skalieren ist, die auf unterschiedlichen Konsensmechanismen und Frameworks basieren.
ZK ist eine relativ neue und komplexe Technologie, die schwer zu prüfen ist, und die aktuellen Kosten für die Verifizierung und Beweiserstellung sind nicht optimal. Wir glauben, dass viele AMP-Lösungen auf lange Sicht zur Unterstützung hochskalierbarer Cross-Chain-Anwendungen auf Blockchains wahrscheinlich überprüfbare Software mit vertrauenswürdigen Personen und Einheiten kombinieren werden, weil:
-
Durch Auditing und Bug Bountys kann die Möglichkeit einer Codeausnutzung minimiert werden. Mit der Zeit wird es einfacher, diesen Systemen zu vertrauen, da ihre Geschichte zum Beweis ihrer Sicherheit wird.
-
Die Kosten für die Erstellung von ZK-Proofs werden reduziert. Mit mehr Forschung und Entwicklung zu ZKPs, rekursiven ZKPs, Beweisaggregation, Faltungsschemata und spezieller Hardware gehen wir davon aus, dass der Zeitaufwand für die Beweiserstellung und -verifizierung erheblich sinken wird, was diesen Ansatz zu einem kostengünstigeren Ansatz macht.
-
Die Blockchain wird ZK stärker unterstützen. Zukünftig wird zkEVM in der Lage sein, prägnante Beweise für die Gültigkeit der Ausführung zu liefern, und leichte clientbasierte Lösungen werden in der Lage sein, die Ausführung und den Konsens der Quellkette einfach zu überprüfen. In der Endphase von Ethereum ist außerdem geplant, „alles zk-SNARK“ zu machen, einschließlich des Konsensmechanismus.
Menschliche Referenzen, Reputation und Identität
Die Sicherheit eines komplexen Systems wie einer AMP-Lösung kann nicht durch ein einzelnes Framework allein gekapselt werden und erfordert eine mehrschichtige Lösung. Zusätzlich zu wirtschaftlichen Anreizen implementiert Axelar beispielsweise einen quadratischen Abstimmungsmechanismus, um die Konzentration der Abstimmungsmacht auf eine Teilmenge von Knoten zu verhindern und die Dezentralisierung zu fördern. Andere menschliche Beweise, Reputationen und Identitäten können ebenfalls Einrichtungs- und Berechtigungsmechanismen ergänzen.
abschließend
Im offenen Geist von Web3 können wir eine pluralistische Zukunft sehen, in der mehrere Ansätze nebeneinander existieren. Tatsächlich kann sich eine Anwendung dafür entscheiden, mehrere Interoperabilitätslösungen zu verwenden, entweder in redundanter Form oder indem der Benutzer eine Kombination basierend auf Kompromissen wählt. Zwischen „stark frequentierten“ Routen können Punkt-zu-Punkt-Lösungen Vorrang haben, während Hub-and-Spoke-Modelle den langen Teil der Kette dominieren können. Letztendlich werden wir als Gemeinschaft von Benutzern, Entwicklern und Mitwirkenden die Grundform des Web3-Internets gestalten.
Ursprünglicher Link
