Autor: STANFORD BLOCKCHAIN CLUB Zusammengestellt von: Cointime: QDD.
Einführung
Die Zukunft ist Multi-Chain. Das Streben nach Skalierbarkeit führt Ethereum zu rollierenden Lösungen. Der Übergang zu modularen Blockchains hat das Interesse an Anwendungsketten erneuert. Am Horizont hören wir Gerüchte über anwendungsspezifische Rolling-Lösungen, Layer-3-Lösungen und souveräne Ketten. Dies alles geht jedoch mit der Fragmentierung einher, da die Funktionalität aktueller Bridges häufig eingeschränkt ist und sie sich zur Gewährleistung der Sicherheit auf vertrauenswürdige Signaturparteien verlassen.
Wie wird die endgültige Form der Vernetzung im Internet 3.0 aussehen? Wir glauben, dass sich Bridges irgendwann zu Cross-Chain-Messaging- oder Arbitrary Message Passing (AMP)-Protokollen entwickeln werden, um neue Anwendungsfälle zu erschließen, die es Anwendungen ermöglichen, beliebige Nachrichten zwischen Quell- und Zielketten zu übertragen. Wir werden auch den Aufstieg einer „Vertrauenslandschaft“ erleben, in der Entwickler verschiedene Kompromisse in Bezug auf Benutzerfreundlichkeit, Komplexität und Sicherheit eingehen.
Jede AMP-Lösung erfordert zwei Schlüsselfunktionen:
1. Überprüfung: Überprüfen Sie die Gültigkeit der Quellkettennachricht in der Zielkette.
2. Überlebensfähigkeit: die Fähigkeit, Informationen von der Quellkette zur Zielkette zu übertragen.
Leider ist eine 100 % vertrauenslose Verifizierung unrealistisch und Benutzer müssen Code, Spieltheorie, Menschen (oder Entitäten) oder einer Kombination davon vertrauen, je nachdem, ob die Verifizierung in der Kette oder außerhalb der Kette erfolgt.
In diesem Artikel werden wir die gesamte Interoperabilitätslandschaft basierend auf den verwendeten Vertrauensmechanismen und Integrationsarchitekturen vertikal und horizontal unterteilen.
Vertrauensmechanismus:
1. Vertrauen Sie auf den Code und die Mathematik: Für diese Lösungen gibt es On-Chain-Beweise, die von jedem überprüft werden können. Diese Lösungen basieren normalerweise auf Light Clients, um den Konsens der Quellkette auf der Zielkette oder die Gültigkeit des Zustandsübergangs der Quellkette auf der Zielkette zu überprüfen. Zero-Knowledge-Beweise können die leichte Client-Verifizierung effizienter machen, indem sie beliebig lange Offline-Berechnungen komprimieren und eine einfache Verifizierung in der Kette ermöglichen, um die Berechnung zu beweisen.
2. Vertrauensspieltheorie: Wenn ein Benutzer/eine Anwendung einem Dritten oder einer Gruppe von Dritten vertrauen muss, um die Authentizität einer Transaktion zu garantieren, gibt es zusätzliche Vertrauensannahmen. Diese Mechanismen können durch die Kombination wirtschaftlicher Anreize und Spieltheorie, wie beispielsweise optimistische Sicherheit durch erlaubnisfreie Netzwerke, sicherer gemacht werden.
3. Vertrauen in Menschen: Diese Lösungen basieren auf der Ehrlichkeit der Mehrheit der Prüfer oder der Unabhängigkeit der Stellen, die verschiedene Informationen weitergeben. Neben dem Vertrauen in den Konsens der beiden interagierenden Ketten ist auch Vertrauen in eine dritte Partei erforderlich. Dabei kommt es ausschließlich auf die Reputation der beteiligten Unternehmen an. Wenn genügend teilnehmende Einheiten eine Transaktion für gültig erachten, gilt sie als gültig.
Es ist wichtig zu beachten, dass alle Lösungen ein gewisses Maß an Vertrauen sowohl in den Code als auch in die Menschen erfordern. Jede Lösung mit fehlerhaftem Code kann von Hackern ausgenutzt werden und bei jeder Lösung ist ein gewisser menschlicher Faktor beim Einrichten, Aktualisieren oder Warten der Codebasis erforderlich.
Integrierte Architektur:
1. Peer-to-Peer-Modell: Zwischen jeder Quellkette und jeder Zielkette muss ein dedizierter Kommunikationskanal eingerichtet werden.
2. Zentrales Hub-Modell: Es muss ein Kommunikationskanal mit einem zentralen Hub eingerichtet werden, der alle anderen mit dem Hub verbundenen Blockchains verbindet.
Das Peer-to-Peer-Modell ist relativ schwierig zu skalieren, da jede verbundene Blockchain einen paarweisen Kommunikationskanal benötigt. Die Entwicklung dieser Kanäle kann für Blockchains mit unterschiedlichen Konsensen und Rahmenbedingungen eine Herausforderung darstellen. Falls gewünscht, kann jedoch auch ein hybrider Ansatz gewählt werden, beispielsweise die Verwendung des Inter-Blockchain Communication-Protokolls (IBC) für Multi-Hop-Routing über einen zentralen Hub. Dadurch entfällt die Notwendigkeit einer direkten Punkt-zu-Punkt-Kommunikation, es entsteht jedoch eine höhere Komplexität hinsichtlich Sicherheit, Latenz und Kosten.
Vertrauen in Code und Mathematik
Um sich bei Vertrauensannahmen nur auf Code/Mathematik zu verlassen, kann ein Light-Client verwendet werden, um den Konsens der Quellkette in der Zielkette zu überprüfen. Ein Light Client/Node ist eine Software, die eine Verbindung zu einem Full Node herstellt, um mit der Blockchain zu interagieren. Light-Clients in der Zielkette speichern normalerweise die Blockheader der Quellkette (in der richtigen Reihenfolge), was zur Überprüfung von Transaktionen ausreicht. In ähnlicher Weise überwachen Off-Chain-Agenten (wie z. B. Relayer) in der Quellkette Ereignisse, generieren kryptografische Einschlussnachweise und leiten diese zusammen mit Blockheadern an Light Clients in der Zielkette weiter. Da Light-Clients Blockheader der Reihe nach speichern, können sie Transaktionen überprüfen, da jeder Blockheader einen Merkle-Root-Hash enthält, der den Status beweist. Im Folgenden finden Sie eine Übersicht über die wichtigsten Merkmale dieses Ansatzes:
Sicherheit
Vertrauensannahmen werden während des Light-Client-Initialisierungsprozesses eingeführt. Wenn ein neuer Light-Client erstellt wird, wird er mit einem Blockheader in einer bestimmten Höhe initialisiert. Allerdings können die bereitgestellten Blockheader falsch sein und es ist möglich, Light-Clients durch Fälschen von Blockheadern zu täuschen. Sobald der Light-Client initialisiert ist, werden keine weiteren Vertrauensannahmen eingeführt. Es ist jedoch zu beachten, dass dieser Initialisierungsprozess auf einer schwächeren Vertrauensannahme beruht, da ihn jeder überprüfen kann. Darüber hinaus ist auch die Kontinuität des Relais eine Vertrauensannahme, da es für die Übermittlung der Informationen verantwortlich ist.
erreichen
Die Implementierung von Light-Clients hängt von der Verfügbarkeit der für die Authentifizierung erforderlichen kryptografischen Grundelemente ab. Wenn die verbundenen Ketten vom gleichen Typ sind, d. h. wenn sie dasselbe Anwendungsframework und denselben Konsensalgorithmus verwenden, sind die Light-Client-Implementierungen auf beiden Seiten gleich. Beispielsweise verwenden alle auf dem Cosmos SDK basierenden Ketten das Inter-Blockchain Communication (IBC)-Protokoll. Wenn Sie hingegen zwei unterschiedliche Kettentypen verbinden, etwa unterschiedliche Anwendungsframeworks oder Konsenstypen, wird die Implementierung des Light-Clients anders sein. Ein Beispiel ist Composable Finance, das daran arbeitet, die Cosmos SDK-Kette über IBC mit dem Substrate des Polkadot-Ökosystems zu verbinden. Dies erfordert das Hinzufügen eines Tendermint-Light-Clients zur Substrate-Kette und eines „leistungsstarken“ Light-Clients zur Cosmos SDK-Kette. Vor Kurzem haben sie über IBC die erste Verbindung zwischen Polkadot und Kusama hergestellt.
Herausforderung
Die Ressourcenintensität stellt eine große Herausforderung dar. Das Ausführen von Paaren leichter Clients auf allen Ketten kann teuer sein, da Schreibvorgänge in der Blockchain teuer sind. Darüber hinaus ist es nicht möglich, Light Clients auf Ketten mit dynamischen Validator-Sets wie Ethereum auszuführen.
Eine weitere Herausforderung ist die Skalierbarkeit. Light-Client-Implementierungen variieren je nach Architektur der Kette, was die Skalierung und Verbindung verschiedener Ökosysteme erschwert.
Die Ausnutzung des Codes stellt ein potenzielles Risiko dar, da Fehler im Code zu Sicherheitslücken führen können. Ein Beispiel ist die Sicherheitslücke in der BNB-Kette im Oktober 2022, die eine kritische Sicherheitslücke aufdeckte, die alle IBC-fähigen Ketten betraf[1].
Um die Kosten und die Praktikabilität des Ausführens von Paaren leichter Clients auf allen Ketten zu berücksichtigen, bieten Alternativen wie Zero-Knowledge-Beweise (ZK) eine Möglichkeit, das Vertrauen in Dritte überflüssig zu machen.
Zero-Knowledge-Proof als Lösung für das Vertrauen Dritter
Mit ZK-Beweisen kann die Gültigkeit von Zustandsübergängen in der Quellkette zur Zielkette überprüft werden. Anstatt die gesamte Berechnung in der Kette durchzuführen, ist es besser, nur die Überprüfung der Berechnung in der Kette durchzuführen, während der eigentliche Berechnungsprozess außerhalb der Kette ausgeführt wird. Dieser Ansatz kann schneller und energieeffizienter sein als die erneute Ausführung der ursprünglichen Berechnungen. Einige Beispiele sind Polymer ZK-IBC von Polymer Labs und Telepathy von Succinct Labs. Polymer entwickelt IBC mit Unterstützung für Multi-Hop, um die Konnektivität zu verbessern und die Anzahl der erforderlichen paarweisen Verbindungen zu reduzieren.
Zu den wichtigsten Aspekten des Mechanismus gehören:
Sicherheit
Die Sicherheit von zk-SNARKs basiert auf elliptischen Kurven, während zk-STARKs auf Hash-Funktionen basiert. zk-SNARKs erfordern möglicherweise einen vertrauenswürdigen Einrichtungsprozess, bei dem anfängliche Schlüssel für die bei der Überprüfung verwendeten Nachweise erstellt werden. Es ist wichtig, dass der geheime Schlüssel, der das Setup-Ereignis zerstört, geheim gehalten wird, um zu verhindern, dass Transaktionen durch gefälschte Verifizierung durchgeführt werden. Sobald die vertrauenswürdige Einrichtung abgeschlossen ist, werden keine weiteren Vertrauensannahmen eingeführt. Darüber hinaus machen neue ZK-Frameworks wie Halo und Halo2 die Notwendigkeit eines vertrauenswürdigen Setups vollständig überflüssig.
erreichen
Es gibt verschiedene ZK-Beweisschemata wie SNARK, STARK, VPD und SNARG, wobei SNARK derzeit am weitesten verbreitet ist. Verschiedene SNARK-Beweisframeworks wie Groth16, Plonk, Marlin, Halo und Halo2 weisen Kompromisse hinsichtlich der Beweisgröße, der Beweiszeit, der Verifizierungszeit, des Speicherbedarfs und der Notwendigkeit eines vertrauenswürdigen Setups auf. Darüber hinaus sind rekursive ZK-Beweise entstanden, die es ermöglichen, den Arbeitsaufwand für Beweise auf mehrere Computer statt nur auf einen zu verteilen. Um einen Gültigkeitsnachweis zu generieren, müssen die folgenden Kernprimitiven implementiert werden: Überprüfung des vom Validierer verwendeten Signaturschemas, einschließlich des Nachweises des öffentlichen Schlüssels des Validierers in der in der Kette gespeicherten Validierersatzverpflichtung, und Nachverfolgung des Validierersatzes, der sich häufig ändern kann.
Herausforderung
Die Implementierung verschiedener Signaturschemata in zkSNARKs erfordert die Implementierung von Arithmetik außerhalb des Bereichs und komplexer elliptischer Kurvenoperationen, was nicht trivial ist und je nach Rahmen und Konsens der Kette unterschiedliche Implementierungen für jede Kette erfordern kann. Die Prüfung von ZK-Schaltkreisen ist eine anspruchsvolle und fehleranfällige Aufgabe. Entwickler müssen sich mit domänenspezifischen Sprachen wie Circom, Cairo und Noir vertraut machen oder die Schaltkreise einfach selbst implementieren. Beides kann eine Herausforderung darstellen und die Akzeptanz verlangsamen. Dies kann zu einer Zentralisierung führen, wenn sich der Zeit- und Arbeitsaufwand als sehr hoch erweist und nur ein dediziertes Team mit spezieller Hardware bewältigen kann. Auch längere Nachweiserstellungszeiten können zu Verzögerungen führen. Techniken wie Incremental Verifiable Computation (IVC) können die Beweiszeiten verbessern, viele davon befinden sich jedoch noch in der Forschungsphase und warten auf ihre Implementierung. Längere Verifizierungszeiten und Arbeitsbelastungen erhöhen die Kosten in der Kette.
Vertrauensspieltheorie
Spieltheoretische Interoperabilitätsprotokolle lassen sich grob in zwei Kategorien unterteilen, je nachdem, wie sie ehrliches Verhalten der teilnehmenden Einheiten fördern:
Der erste ist die wirtschaftliche Sicherheit, bei der mehrere externe Akteure (wie etwa Validierer) zusammenarbeiten, um einen Konsens über den aktualisierten Status der Quellkette zu erzielen. Um Validierer zu werden, müssen die Teilnehmer eine bestimmte Anzahl an Token einsetzen, die im Falle böswilliger Aktivitäten gekürzt werden kann. In einer erlaubnisfreien Umgebung kann jeder einen Anteil anhäufen und zum Validierer werden. Darüber hinaus werden den Validierern finanzielle Anreize in Form von Blockbelohnungen geboten, sich an das Protokoll zu halten, wodurch finanzielle Anreize für ehrliches Verhalten gewährleistet werden. Wenn der potenziell zu stehlende Betrag jedoch den eingesetzten Betrag übersteigt, können die Teilnehmer gemeinsame Sache machen, um Geld zu stehlen. Beispiele für Protokolle, die wirtschaftliche Sicherheitsmechanismen verwenden, sind Axelar und Celer IM.
Die zweite Kategorie ist optimistische Sicherheit, bei der die Lösung auf der Annahme basiert, dass nur eine Minderheit der Blockchain-Teilnehmer ehrlich ist und die Regeln des Protokolls befolgt. Bei diesem Ansatz kann ein einzelner ehrlicher Teilnehmer als Sicherheit fungieren. Eine optimale Lösung würde es beispielsweise jedem ermöglichen, Beweise für einen Betrug vorzulegen. Obwohl ein finanzieller Anreiz besteht, kann es sein, dass ehrliche Beobachter betrügerische Transaktionen übersehen. Auch Optimistic Roll-up übernimmt diesen Mechanismus. Nomad und ChainLink CCIP sind Beispiele für Protokolle, die optimistische Sicherheit verwenden. Im Fall von Nomad konnten Beobachter trotz des Whitelist-Status zum Zeitpunkt des Schreibens Betrug nachweisen. ChainLink CCIP plant, ein Betrugsbekämpfungsnetzwerk zu nutzen, das aus einem dezentralen Oracle-Netzwerk besteht, um böswillige Aktivitäten zu überwachen. Die Implementierung des Betrugsbekämpfungsnetzwerks von CCIP muss jedoch noch entschieden werden.
Sicherheit
In Bezug auf die Sicherheit beruhen beide Mechanismen auf der erlaubnisfreien Teilnahme von Validierern und Beobachtern, um die Gültigkeit der Spieltheorie sicherzustellen. Wenn bei einem wirtschaftlichen Sicherheitsmechanismus der eingesetzte Betrag niedriger ist als der potenziell stehlbare Betrag, sind die Gelder anfälliger für Angriffe. Andererseits kann bei optimistischen Sicherheitsmechanismen die Annahme des Minderheitsvertrauens ausgenutzt werden, wenn niemand Betrugsnachweise vorlegt oder wenn der Autoritätsbeobachter kompromittiert oder entfernt wird. Im Gegensatz dazu sind wirtschaftliche Sicherheitsmechanismen zur Aufrechterhaltung der Sicherheit weniger von Lebendigkeit abhängig.
Durchführung
Ein Ansatz zur Implementierung besteht in einer Zwischenkette mit eigenen Validierern. In diesem Setup überwacht eine Gruppe externer Validierer die Quellkette und erzielt einen Konsens über die Gültigkeit von Transaktionen, wenn ein Anruf erkannt wird. Sobald ein Konsens erreicht ist, liefern sie Beweise für die Zielkette. Von Validierern wird normalerweise verlangt, eine bestimmte Anzahl an Token einzusetzen, und ihre Befugnisse können gekürzt werden, wenn böswillige Aktivitäten erkannt werden. Beispiele für Protokolle, die diese Implementierung verwenden, sind Axelar Network und Celer IM.
Eine andere Implementierungsmethode beinhaltet die Verwendung eines Off-Chain-Proxys. Off-Chain-Proxys werden verwendet, um Lösungen zu implementieren, die optimistischen Rollups ähneln. Innerhalb eines vordefinierten Zeitfensters dürfen diese Off-Chain-Proxys Betrugsnachweise vorlegen und Transaktionen bei Bedarf rückgängig machen. Beispielsweise verlässt sich Nomad 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 nachzuweisen.
Vorteile und Herausforderungen
Ein wesentlicher Vorteil von Game Theory AMP ist die Ressourcenoptimierung, da der Verifizierungsprozess normalerweise nicht in der Kette stattfindet, wodurch der Ressourcenbedarf reduziert wird. Darüber hinaus sind diese Mechanismen skalierbar, da der Konsensmechanismus für verschiedene Kettentypen gleich bleibt und problemlos auf heterogene Blockchains erweitert werden kann.
Diese Mechanismen sind jedoch auch mit einigen Herausforderungen konfrontiert. Wenn eine Mehrheit der Prüfer zusammenarbeitet, kann die Vertrauensannahme ausgenutzt werden, um Gelder zu stehlen, was den Einsatz von Gegenmaßnahmen wie quadratischen Abstimmungen und Betrugsnachweisen erfordert. Darüber hinaus führen Lösungen, die auf optimistischer Sicherheit basieren, zu Komplexität hinsichtlich Endgültigkeit und Lebendigkeit, da Benutzer und Anwendungen auf ein Betrugsfenster warten müssen, um die Gültigkeit von Transaktionen sicherzustellen.
Vertrauen in den Menschen
Lösungen, die Vertrauen in eine menschliche Entität erfordern, können ebenfalls grob in zwei Kategorien unterteilt werden:
1. Reputationssicherheit: Diese Lösungen basieren auf Implementierungen mit mehreren Signaturen, bei denen mehrere Entitäten Transaktionen überprüfen und signieren. Sobald der Mindestbetrag erreicht ist, gilt die Transaktion als gültig. Dabei wird davon ausgegangen, dass die Mehrheit der Entitäten ehrlich ist und dass eine bestimmte Transaktion gültig ist, wenn die Mehrheit dieser Entitäten sie unterzeichnet. Einige Beispiele hierfür sind Multichain (Anycall V6) und Wormhole. Schwachstellen in Smart Contracts können immer noch ausgenutzt werden, wie der Wormhole-Hack Anfang 2022 gezeigt hat.
2. Unabhängigkeit: Diese Lösungen unterteilen den gesamten Messaging-Prozess in zwei Teile und verlassen sich auf verschiedene unabhängige Einheiten, um die beiden Prozesse zu verwalten. Dabei wird davon ausgegangen, dass die beiden Entitäten voneinander unabhängig sind und keine geheimen Absprachen treffen. LayerZero ist ein Beispiel. Blockheader können auf Anfrage von dezentralen Orakeln übertragen werden und Transaktionsnachweise werden über Relayer gesendet. Wenn der Nachweis mit dem Blockheader ü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. Auf LayerZero erstellte Anwendungen können ihre Orakel und Relayer auswählen (oder ihre eigenen Orakel/Relays hosten), wodurch das Risiko einer Absprache zwischen einzelnen Orakeln/Relays begrenzt wird. Endbenutzer müssen darauf vertrauen, dass LayerZero, Dritte oder die Anwendung selbst das Orakel und den Relayer unabhängig und ohne böswillige Absicht betreiben.
Bei beiden Ansätzen verringert der Ruf der beteiligten Drittparteien den Anreiz, böswillig zu handeln. Sie sind in der Validator- und Oracle-Community häufig hoch angesehen und müssen bei böswilligem Verhalten mit Reputationsschäden und negativen Auswirkungen auf ihre sonstigen Geschäftsaktivitäten rechnen.
Über die Vertrauensannahme hinaus: 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 grundlegenden Mechanismen hinausgehen. Da es sich hierbei um bewegliche Teile handelt, die sich im Laufe der Zeit verändern können, haben wir diese nicht in den Gesamtvergleich einbezogen.
Code-Integrität
Bei den jüngsten Hackerangriffen wurden Codefehler ausgenutzt, was die Notwendigkeit zuverlässiger Audits, Bug-Bounties und vielfältiger Client-Implementierungen unterstreicht. Wenn alle Validierer (bei wirtschaftlicher/optimistischer/reputativer Sicherheit) denselben Client (zur Validierung verwendete Software) ausführen, erhöht dies die Abhängigkeit von einer einzigen Codebasis und verringert die Client-Vielfalt. Beispielsweise verlässt sich Ethereum auf mehrere Ausführungsclients wie Geth, Nethermind, Erigon, Besu und Akula. Mehrere Implementierungen in mehreren Sprachen könnten die Vielfalt erhöhen, ohne dass ein einzelner Client das Netzwerk dominiert, wodurch potenzielle einzelne Fehlerquellen eliminiert würden. Das Vorhandensein mehrerer Clients kann auch zur Verbesserung der Lebendigkeit beitragen. Wenn einige Validierer/Signierer/Light-Clients aufgrund eines Fehlers/Angriffs in einer bestimmten Implementierung ausfallen, sind die anderen weiterhin verfügbar.
Einrichtung und Upgradefähigkeit
Benutzer und Entwickler müssen verstehen, ob Validierer/Beobachter dem Netzwerk ohne Erlaubnis beitreten können, da sonst das Vertrauen durch die ausgewählten autorisierten Entitäten verborgen wird. Durch Upgrades von Smart Contracts können auch Fehler entstehen, die zu Angriffen führen oder sogar Vertrauensannahmen ändern können. Zur Minderung dieser Risiken können verschiedene Lösungen implementiert werden. Beispielsweise kann das Axelar Gateway in der aktuellen Instanziierung auf der Grundlage der Genehmigung durch ein Offline-Komitee (4/8-Schwelle) aktualisiert werden. Axelar plant jedoch, in naher Zukunft von allen Validierern die gemeinsame Genehmigung aller Upgrades des Gateways zu verlangen. 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 Upgrades zu vermeiden. Es können jedoch neue Bibliotheken eingeführt werden und dApps, die die Standardeinstellungen verwenden, erhalten die aktualisierte Version. dApps, die die Version manuell festlegen, müssen sie auf die neue Version einstellen.
Maximal extrahierbarer Wert (MEV)
Verschiedene Blockchains werden über eine gemeinsame Uhr synchronisiert und haben unterschiedliche Endgültigkeitszeiten. Daher können die Ausführungsreihenfolge und der Zeitpunkt auf der Zielkette von Kette zu Kette unterschiedlich sein. In der Cross-Chain-Welt ist eine klare Definition von MEV eine Herausforderung. Es führt zu einem Kompromiss zwischen Lebendigkeit und Ausführungsreihenfolge. Ein geordneter Kanal gewährleistet die geordnete Zustellung von Nachrichten. Wenn jedoch bei einer Nachricht das Zeitlimit abläuft, wird der Kanal geschlossen. Eine andere Anwendung möchte möglicherweise keine Sortierung verlangen, ohne die Zustellung anderer Nachrichten zu beeinträchtigen.
Endgültigkeit der Quellkette
Idealerweise sollte eine AMP-Lösung warten, bis eine Quellkette die Finalität erreicht hat, bevor Statusinformationen von der Quellkette an eine oder mehrere Zielketten übertragen werden. Dadurch wird sichergestellt, dass Blöcke in der Quellkette praktisch nicht rückgängig gemacht oder geändert werden können. Um jedoch das beste Benutzererlebnis zu bieten, bieten viele Lösungen Instant Messaging an und gehen von Vertrauensannahmen hinsichtlich der Endgültigkeit aus. In diesem Fall kann es zu einer doppelten Ausgabe von Geldern kommen, wenn die Quellkette nach der Zustellung der Nachricht und der Überbrückung der Gelder zurückgesetzt wird. AMP-Lösungen können dieses Risiko auf verschiedene Weise managen, beispielsweise durch die Verwendung unterschiedlicher Finalitätsannahmen für verschiedene Ketten und die Abwägung von Geschwindigkeit und Sicherheit basierend auf dem Dezentralisierungsgrad der Kette. Brücken, die die AMP-Lösung nutzen, können Grenzen für die Anzahl der Assets festlegen, die überbrückt werden können, bevor die Quellkette die Endgültigkeit erreicht.
Trends und Zukunftsaussichten
Anpassbare und erhöhte Sicherheit
Um verschiedenen Anwendungsfällen besser gerecht zu werden, werden bei AMP-Lösungen Anreize geschaffen, mehr Entwicklungsflexibilität zu bieten. Axelar führt eine Methode zur Aufrüstbarkeit von Messaging und Authentifizierung ein, ohne die Logik der Anwendungsschicht zu ändern. HyperLane V2 führt Module ein, die es Entwicklern ermöglichen, aus mehreren Optionen auszuwählen, darunter wirtschaftliche Sicherheit, optimistische Sicherheit, dynamische Sicherheit und hybride Sicherheit. Neben der wirtschaftlichen Sicherheit bietet CelerIM auch zusätzliche optimistische Sicherheit. Viele Lösungen warten auf eine vordefinierte Mindestanzahl von Blockbestätigungen in der Quellkette, bevor sie eine Nachricht übertragen. LayerZero ermöglicht Entwicklern, diese Parameter zu aktualisieren. Wir gehen davon aus, dass einige AMP-Lösungen weiterhin mehr Flexibilität bieten werden, diese Designentscheidungen erfordern jedoch einige Diskussionen. Können Anwendungen ihre Sicherheit konfigurieren, in welchem Umfang und was passiert, wenn die Anwendung nicht optimal aufgebaut ist? Das Bewusstsein der Benutzer für die grundlegenden Konzepte der Sicherheit könnte zunehmend wichtiger werden. Letztendlich sehen wir eine Aggregation und Abstraktion von AMP-Lösungen voraus, möglicherweise in Form einer kombinierten oder „hinzugefügten“ Sicherheit.
Die Reife des Mechanismus „Vertrauen in Code und Mathematik“
Im idealen Endziel wird bei der gesamten kettenübergreifenden Nachrichtenübermittlung das Vertrauen durch die Verwendung von Zero-Knowledge-Beweisen minimiert. Wir beobachten diesen Wandel bereits bei Projekten wie Polymer Labs und Succinct Labs. Multichain hat außerdem ein Whitepaper namens zkRouter veröffentlicht, das Interoperabilität durch ZK-Proofs ermöglicht. Mit der kürzlich angekündigten Axelar Virtual Machine können Entwickler den Interchain Amplifier nutzen, um ohne Genehmigung neue Verbindungen zum Axelar-Netzwerk herzustellen. Sobald beispielsweise robuste Light Clients und ZK-Proofs des Ethereum-Status entwickelt sind, können Entwickler diese problemlos in das Axelar-Netzwerk integrieren, um bestehende Verbindungen zu ersetzen oder zu verbessern. Celer Network kündigte eine ZK-Cross-Chain-Datennachweisplattform namens Brevis an, die es dApps und Smart Contracts ermöglicht, auf beliebige Daten auf mehreren Blockchains zuzugreifen, diese zu berechnen und zu nutzen. Celer verwendet ZK Light-Client-Schaltungen, um ein für den Benutzer sichtbares Asset zkBridge zu implementieren und so die Testnetze Ethereum Goerli und BNB Chain zu überbrücken. LayerZero spricht in seiner Dokumentation über die Möglichkeit, in Zukunft neue optimierte Proof-Message-Bibliotheken hinzuzufügen. Neue Projekte wie Lagrange untersuchen die Möglichkeit, mehrere Beweise aus mehreren Quellketten zu aggregieren, während Herodotus den Speichernachweis über ZK-Beweise ermöglicht. Dieser Übergang wird jedoch einige Zeit in Anspruch nehmen, da dieser Ansatz auf Blockchains, die auf unterschiedlichen Konsensmechanismen und Frameworks basieren, nur schwer skalierbar ist.
ZK ist eine relativ neue und komplexe Technologie, die schwer zu prüfen ist, und die aktuellen Kosten für die Überprüfung und Nachweiserstellung sind nicht optimal. Wir glauben, dass viele AMP-Lösungen langfristig wahrscheinlich vertrauenswürdige menschliche Entitäten mit überprüfbarer Software kombinieren werden, um hochskalierbare Cross-Chain-Anwendungen auf Blockchains zu unterstützen, und zwar aus den folgenden Gründen:
1. Durch Audits und Bug-Bounties kann die Möglichkeit der Code-Ausnutzung minimiert werden. Da ihre Historie als Sicherheitsnachweis dient, wird es mit der Zeit einfacher, diesen Systemen zu vertrauen.
2. Die Kosten für die Erstellung von ZK-Beweisen werden reduziert. Mit mehr Forschung und Entwicklung im Bereich ZKPs, rekursivem ZK, Beweisaggregation, Faltschemata und Spezialhardware erwarten wir, dass sich der Zeit- und Kostenaufwand für die Beweisgenerierung und -überprüfung erheblich verringern wird, was diesen Ansatz kostengünstiger macht.
3. Blockchain wird ZK-freundlicher. In Zukunft 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 die Ausführung und den Konsens der Quellkette problemlos überprüfen können. In der letzten Phase von Ethereum ist geplant, „alles in zk-SNARKs umzuwandeln“, einschließlich des Konsenses.
Menschen, Ruf und Identität
Die Sicherheit eines komplexen Systems wie der AMP-Lösung kann nicht durch ein einziges Framework gekapselt werden und erfordert eine mehrschichtige Lösung. Beispielsweise implementiert Axelar zusätzlich zu wirtschaftlichen Anreizen auch einen quadratischen Abstimmungsmechanismus, um die Konzentration der Stimmrechte auf eine Teilmenge von Knoten zu verhindern und die Dezentralisierung zu fördern. Auch andere Personen-, Reputations- und Identitätsnachweise können die Einstellungs- und Berechtigungsmechanismen ergänzen.
abschließend
Aufbauend auf dem offenen Geist von Web3 erleben wir möglicherweise eine Zukunft, in der mehrere Ansätze nebeneinander existieren. In der Praxis können Anwendungen auf die Verwendung mehrerer Interoperabilitätslösungen setzen, entweder in redundanter Weise oder um Benutzern die Möglichkeit zu geben, diese mit Kompromissen zu kombinieren. Punkt-zu-Punkt-Lösungen können zwischen stark frequentierten Routen priorisiert werden, während Hub-and-Spoke-Modelle im langen Ende der Kette dominieren können. Letztendlich liegt es an uns als Community aus Benutzern, Entwicklern und Mitwirkenden, die Landschaft eines vernetzten Web3 zu gestalten.
Verweise
https://forum.cosmos.network/t/ibc-security-advisory-dragonberry/7702
https://polymerlabs.medium.com/the-multi-hop-ibc-upgrade-will-take-ibc-to-ethereum-and-beyond-b4bee43523e
https://cointelegraph.com/news/wormhole-hack-illustrates-danger-of-defi-cross-chain-bridges
https://axelar.network/blog/future-proof-interop-path-adaptability-for-cross-chain-dapps
https://ethresear.ch/t/hashi-a-principled-approach-to-bridges/14725
https://twitter.com/MultichainOrg/status/1613830754458533888?s=20&t=MoDGESqOdcjMQDMFQqzTyQ
https://axelar.network/blog/axelar-virtual-machine-future-of-interoperability
https://twitter.com/CelerNetwork/status/1638330932603109379?s=20
https://axelar.network/blog/axelar-implements-quadratic-voting-with-maeve-upgrade