Eine kurze Geschichte von Cross-Chain: Erläuterung von neun verschiedenen Cross-Chain-Lösungen

Kettenübergreifende Lösungen waren das meistdiskutierte Thema des vergangenen Jahres. Mit dem Aufkommen öffentlicher Ketteninfrastrukturen gab es ein massives Interesse daran, wie verschiedene Ketten sprechen und kommunizieren. Lösungen wurden vorgeschlagen und implementiert, aber keine davon löst die grundlegenden Probleme ohne drastische Kompromisse. Jetzt untersuchen wir die verschiedenen Cross-Chain-Ansätze und verraten, warum und wie sie die Zukunft der Cross-Chain-Infrastruktur prägen werden.

Lassen Sie uns zunächst besprechen, was Cross-Chain-Technologie ist und warum sie benötigt wird. Grund für die Verwendung: Ketten sind heterogen und erfordern viel Zeit für Entwickler, um die Unterschiede und Herausforderungen beim Verschieben von Assets zu verfolgen. Bridges sind weniger sicher und können nicht zu 100 % vertrauenswürdig sein, da sie normalerweise den Blockchain-Projektteams gehören und stark zentralisiert sind (chaotisch ohne Koordination von jedem Team). Das Ziel der Layer-1-Blockchain ist die Standardisierung, aber die Segmentierung der Layer-1-Ketten führt dazu, dass eine kettenübergreifende Infrastrukturschicht erforderlich ist, die sogar unter den Layer-1s liegt.

Die Geschichte der Cross-Chain-Mechanismen muss dargelegt und verglichen werden, um die Cross-Chain-Lösungen zu verstehen und ihre Unterschiede und Attribute zu vergleichen.

Manuelle Übertragung

 
Die allererste Cross-Chain-Lösung ist eine manuelle Übertragung von Vermögenswerten. Der Prozess beginnt damit, dass der Benutzer Vermögenswerte an eine bestimmte Brieftasche in Kette A überträgt, und eine zentrale Einheit überwacht die Brieftasche auf Übertragungen und zeichnet sie in Excel auf. Dann, nach einer begrenzten Zeit (normalerweise zu Überwachungszwecken), schreibt das Unternehmen Vermögenswerte nach Überprüfung der Kette B gut. Der Vorteil dieses Ansatzes ist die einfache Implementierung, aber er ist anfällig für menschliche Fehler und hat eine sehr geringe Sicherheitsgarantie. Auch bei diesem Ansatz gibt es keine Dezentralisierung.

Halbautomatische Übertragung

Die nächste Iteration verbessert sich, indem der Benutzer Vermögenswerte an eine bestimmte Brieftasche und/oder einen Smart Contract in Kette A überträgt. Dann überwacht ein zentralisiertes Programm die Adresse auf Übertragungen. Ein solches Programm sendet nach der Verifizierung automatisch Assets an Kette B. Der Vorteil ist immer noch die einfache Implementierung ohne zu viel Komplexität oder Codierung, und die Aufzeichnungen können in der Kette statt lokal aufbewahrt werden. Der Nachteil ist, dass das zentralisierte Programm fehlerhaft oder fehlerhaft sein kann. Auch dem zentralen Guthabenkonto könnte das Guthaben ausgehen. Auch die Sicherheitsgarantie ist gering und es gibt keine Dezentralisierung.

Zentrale Börse

Wenn die einfachen Cross-Chain-Lösungen nicht skalierbar sind, gedeihen zentralisierte Börsen auf den Cross-Chain-Anforderungen. Sie funktionieren, indem Benutzer Vermögenswerte in ihre zentralisierte Börse übertragen und dann mithilfe des „internen“ Swaps der Börse „Vermögen X“ in Kette A in „Vermögen Y“ in Kette B durch Aufzeichnungen umwandeln. Der Vorteil liegt auf der Hand – es ist die am einfachsten zu verwendende Lösung – es ist keine Codierung erforderlich, und es gibt eine hohe Zuverlässigkeit bei Tier-1-Börsen. Aber das Problem zeigt den gegenteiligen Nachteil – eine zentrale Kontrolle darüber, wann Einzahlungen/Auszahlungen verfügbar sind. Der zentralisierte Austausch bietet hohe Sicherheit mit dem Nachteil der geringsten Dezentralisierung.

Zentralisierte Brücke

Der nächste Fortschritt verbessert sich durch eine separate Infrastruktur für die Übertragung von Vermögenswerten über Ketten hinweg – eine Brücke. Eine zentralisierte Bridge funktioniert so, dass der Benutzer Assets überträgt und dann mithilfe der Übertragungsfunktion der Bridge die Übertragung von Assets X in Kette A in Assets Y in Kette B einleitet. Ein zentralisierter (oder eine Gruppe von) Relayer ist für den Prozess verantwortlich:

Sperren Sie Assets X auf Kette A
Verify
Mint-Assets Y auf Kette B
Der Vorteil dieser Brücke ist der vollautomatische Ablauf ohne manuelle Unterbrechung. Und der Nachteil ist immer noch die zentrale Kontrolle, wann Einzahlungen/Auszahlungen verfügbar sind. Außerdem kann die Brücke heruntergefahren oder gehackt werden, was sie von Zeit zu Zeit unbrauchbar macht. Die Sicherheit ist also mittel, und es gibt noch keine Dezentralisierung.

Dezentrale Bridge mit MPC

Die nächste Iteration ist die Dezentralisierung des Verifikationsmodells anstelle einer zentralisierten Brücke. Eine MPC-Bridge (Multi-Party Computation) beginnt damit, dass Benutzer Assets darauf übertragen. Mit der Übertragungsfunktion der Bridge initiiert sie die Übertragung von Assets X in Kette A in Assets Y in Kette B. Normalerweise ist ein dezentraler Satz von Relayern für den Prozess verantwortlich:

Sperren Sie Assets X in Kette A mit MPC
Überprüfen Sie mit MPC
Mint Assets Y auf Kette B mit MPC
Der Vorteil von MPC ist der vollautomatische Prozess ohne manuelle Unterbrechung, und die Relaisknoten müssen nicht zentralisiert werden. Der Nachteil sind die hohen Rechen- und Kommunikationskosten von MPC. Außerdem können die Knoten kompromittiert oder abgesprochen werden. Die Sicherheit ist mittel, während die Dezentralisierung ebenfalls mittel ist.

Atomic Swap Bridge mit HTLC

Eine weitere Klasse von Bridges entsteht in Abhängigkeit von der Atomic Swap (Lightning Network)-Technologie. Es funktioniert folgendermaßen: Der Benutzer überträgt Assets in eine Atomic Swap Bridge und initiiert dann mithilfe der Übertragungsfunktion der Bridge die Übertragung von Assets X in Kette A in Assets Y in Kette B:

Erstellen Sie einen neuen HTLC – Hash Lock Timed Contract
Hinterlegen Sie Vermögenswerte X in Vertrag auf Kette A
Hash-Lock-Schlüssel generieren + ein Geheimnis für die endgültige Auszahlung innerhalb der Zeit T in Kette B verschlüsseln
Präsentieren Sie ein verschlüsseltes Geheimnis für den Vertrag auf Kette B, um Vermögenswerte Y abzuheben
ODER die Zeit T ist abgelaufen, und erhalte Vermögenswerte X aus dem Vertrag in Kette A mit dem verschlüsselten Geheimnis
Der wesentliche Vorteil besteht darin, dass es keinen zentralisierten Knoten/Prozess gibt, der die Bridge-Übertragung steuert. Und der Nachteil ist relativ häufig – hohe Kosten für die Bereitstellung von HTLC und die Ausführung von HTLC-Aufrufen. Aufgrund der Vertrauenslosigkeit ist die Aufrechterhaltung einer hohen Sicherheit und des Audit-Trails eine Herausforderung. Die Sicherheit dieses Ansatzes ist hoch, und die Dezentralisierung ist angesichts der oben genannten Nachteile ebenfalls hoch.

Kettenübergreifende Interoperabilität mit Light Client + Oracle

Nach den kostenintensiven Bridge-Ansätzen werden weitere Implementierungen entwickelt, um diese Kosten zu reduzieren. Die Light-Client-Technologie ist zur neuesten Norm geworden, um kettenübergreifende Überprüfungen zu vereinfachen. Der Ablauf ist wie folgt:

Zunächst überträgt der Benutzer Assets X in den Vertrag eines Cross-Chain-Interoperabilitätsprotokolls auf Chain A
Eine Übertragungsnachricht wird vertraglich festgelegt und von dezentralen Relayer-Knoten abgeholt
Knoten senden Beweise an den Vertrag des Protokolls in Kette B
Aktualisierungen von Block-Headern (Light Client) werden vom Oracle-Netzwerk verarbeitet, um die Zustellung und Gültigkeit sicherzustellen
Der Benutzer entzieht nach der Validierung Vermögenswerte Y aus dem Vertrag des Protokolls in Kette B
Der Vorteil dieses Ansatzes besteht darin, dass von der Übertragung bis zum Abschluss kein zwischengeschaltetes Token oder eine Kette benötigt wird. Sofortige Bestätigung ist möglich, nachdem Blockheader aktualisiert wurden. Die Nachteile sind 1) Kollusionsrisiken von Oracles, 2) aufgrund von Vertrauenslosigkeit, der Aufrechterhaltung hoher Sicherheit und der Audit-Trail ist eine Herausforderung. Die Sicherheit dieses Ansatzes ist mittel, während die Dezentralisierung hoch ist.

Kettenübergreifende Interoperabilität mit Relaiskette

Nach den Lehren des Oracle-Ansatzes ist auch eine reine Relay-Chain-Lösung vorhanden. Der Ablauf ist etwas anders:

Der Benutzer überträgt Vermögenswerte X in den Vertrag eines kettenübergreifenden Interoperabilitätsprotokolls auf Kette A
Eine Übertragungsnachricht wird vertraglich festgelegt und von dezentralen Relayer-Knoten abgeholt
Knoten senden Nachweise an den Vertrag der Relaiskette
Zugrunde liegende Relay-Ketten-Validatoren verarbeiten Blockaktualisierungen, um die Zustellung und Gültigkeit sicherzustellen
Nach der Validierung leiten Relayer-Knoten die Übertragungsnachricht an den Vertrag des Protokolls in Kette B weiter
Der Benutzer zieht Vermögenswerte Y aus dem Vertrag des Protokolls in Kette B ab
Der Vorteil dieses Ansatzes gegenüber der einfachen Oracle-Lösung sind die günstigeren Gebühren von Relaisketten, die den größten Teil der Kosten verbrauchen. Eine sofortige Bestätigung ist möglich, nachdem Blöcke aktualisiert wurden, was entscheidend ist, um längere Verzögerungszeiten zu lösen. Das Problem ist, dass das Protokoll selbst möglicherweise kein All-Chain-Ökosystem unterstützt. Die Sicherheit ist hoch (innerhalb des Ökosystems), und die Dezentralisierung ist ebenfalls hoch.

Kettenübergreifende Infrastrukturebene mit Light Client + Relay Chain

Die Lösung der nächsten Generation konzentriert sich auf die kettenübergreifende Infrastrukturebene und löst alle oben genannten grundlegenden Probleme. Es kombiniert die Light-Client-Technologie mit einer Relaiskette, um alle Ketten einzubinden:

Der Benutzer überträgt Assets X in den Interoperabilitätsvertrag einer kettenübergreifenden Infrastrukturschicht auf Kette A
Eine Übertragungsnachricht wird vertraglich festgelegt und von dezentralen Relayer-Knoten abgeholt
Knoten senden Nachweise an den Interoperabilitätsvertrag der Relaiskette
Aktualisierungen von Block-Headern (Light Client) werden von dezentralen Betreuerknoten gehandhabt, um die Zustellung und Gültigkeit sicherzustellen
Nach der Validierung leiten die Relayer-Knoten die Übertragungsnachricht an den Interoperabilitätsvertrag in Kette B weiter
Der Benutzer zieht Assets Y aus dem Interoperabilitätsvertrag in Kette B zurück
Diese Lösung gewährleistet Interoperabilität mit sehr günstigen Gebühren aufgrund einer Relaiskettenimplementierung. Es gibt auch eine sofortige Bestätigung, nachdem die Blockheader aktualisiert wurden. Die größte Herausforderung ist die hohe Komplexität der Optimierung von Light Clients in der Relaiskette. Durch ausreichende Forschung und Entwicklung sollten diese Optimierungen die Vorteile unterstützen, die andere nicht lösen können. Die Sicherheit ist sehr hoch, und die Dezentralisierung ist hoch.

Über das MAP-Protokoll

Von den Cross-Chain-Lösungen müssen wir noch eine sehen, die alle oben genannten Probleme löst. Bis das MAP-Protokoll implementiert ist. Nach 3 Jahren komplexer Forschung und Entwicklung hat das MAP-Protokoll endlich die Omnichain-Schicht mit Light Client + Relay-Chain-Technologie ohne Kompromisse erreicht. MAP hat die Omnichain-Prinzipien mit folgenden Eigenschaften implementiert:

Entwickler bereit
All-Chain-Abdeckung
Mindestkosten
Endgültigkeit der Sicherheit
sofortige Bestätigung

Das MAP-Protokoll ist die Infrastrukturschicht zur Unterstützung des Aufbaus von Bridges, DEXes, Interoperabilitätsprotokollen und mehr. Es unterstützt die Verifizierung durch Light Clients direkt in der MAP-Relay-Kette – um Kosten zu reduzieren. Und es bietet Incentives, die in jede Komponente integriert sind, damit Dapp-Entwickler verdienen oder Endbenutzern präsentieren können. MAP unterstützt EVM- und Nicht-EVM-Ketten – die Protokollschicht ist mit allen Ketten isomorph.

Für die Zukunft ist MAP die Infrastruktur hinter allen Ketten, die die neue Basisschicht sein werden. Entwickler sind nicht länger durch ihre Auswahlkette eingeschränkt und können sich auf das Dapp-Produkt selbst konzentrieren. Die Zukunft ist Omnichain, und mehr Modularisierung und Anreize sind der Weg in die Zukunft.