Autor: MIDDLE.X

Originaltitel: „Paka Labs Cross-Chain-Forschungsbericht (3/4) | Verbindung isolierter Inseln zu Kontinenten: Interpretation von 20 Cross-Chain-Brücken und 4 Cross-Chain-Technologieparadigmen“

 

Cross-Chain-Brücken werden im Allgemeinen in drei technische Paradigmen zusammengefasst, nämlich Light-Client-Cross-Chain, externe Zeugen-Cross-Chain und Atomic Swap basierend auf Hash-Time-Lock. Gemäß der Einführung von Arjun Bhuptani können diese drei technischen Paradigmen auch als native Verifizierung, externe Verifizierung bzw. lokale Verifizierung bezeichnet werden.

Fast alle der beliebtesten Cross-Chain-Brücken, die derzeit auf dem Markt sind (wie LayerZero, Multichain, Axelar und Hyperlane), sind externe Zeugenbrücken.

Obwohl externe Zeugen über Kettenbrücken hinweg besser kompatibel sind, können sie relativ einfach auf weitere Blockchains erweitert werden. Aber es führt unweigerlich zu neuen Vertrauensannahmen. Benutzer müssen darauf vertrauen, dass die externen Zeugen kein Böses tun. Im Gegensatz dazu ist die Vertrauensschicht von Light-Client-Brücken stärker und es besteht keine Notwendigkeit, neue Vertrauensannahmen einzuführen. Solange die Kette sicher ist, ist die Brücke sicher. In einigen Szenarien, in denen nur zwei Ketten (oder etwas mehr als zwei Ketten) verbunden werden müssen, sind leichte Client-Brücken besser geeignet.

In diesem Artikel werden wir eine Bestandsaufnahme der wichtigsten derzeit auf dem Markt befindlichen Light-Client-Bridges und des Entwicklungsstands der kettenübergreifenden Light-Client-Bridge-Technologie vornehmen.

 

Light-Client-Prinzip

 

Lassen Sie uns zunächst einen grundlegenden Überblick über die Prinzipien von Light Clients geben. Light Clients, auch Light Nodes genannt, werden oft in Form von Light Smart Contracts in der Kette präsentiert. Das Grundprinzip der Light-Client-Cross-Chain besteht darin, den Light-Node-Vertrag der Quellkette auf der Zielkette bereitzustellen, um die Nachrichten von der Quellkette zu überprüfen. Wenn Sie eine bidirektionale Cross-Chain erreichen möchten, müssen Sie die Light-Node-Verträge der anderen Kette auf den beiden Ketten bereitstellen.

Im Vergleich zu Full Nodes handelt es sich bei Light Nodes um Lightweight Nodes, die nicht die Abfolge kompletter Blöcke, sondern nur die Abfolge der Blockheader speichern. Obwohl der Blockheader klein ist, enthält er eine kryptografische Zusammenfassung der vollständigen Daten im Block. Wenn ein Light Node wissen muss, ob eine Transaktion in der Kette enthalten ist, kann er eine SPV-Verifizierung der Transaktion über den Blockheader des Blocks, in dem sich die Transaktion befindet, und den Merkle-Pfad der Transaktion durchführen.

Um die in der Zielkette bereitgestellten leichten Knoten der Quellkette aufrechtzuerhalten, muss der Off-Chain-Agent die Blockheader der Quellkette kontinuierlich mit der Zielkette synchronisieren. Light-Node-Verträge setzen kein Vertrauen in den Off-Chain-Agenten voraus, der für die Synchronisierung der Blockheader verantwortlich ist. Da Light-Node-Verträge eine Überprüfung der Blockheader durchführen, die sie synchronisieren, können Off-Chain-Proxys Light-Nodes nicht täuschen.

Die Logik der Light-Node-Überprüfung von Blockheadern ist dieselbe wie die von Full-Nodes und Miner-Nodes und gliedert sich in zwei Teile: Gültigkeitsüberprüfung und Endgültigkeitsüberprüfung.

Für die PoW-Kette bezieht sich die Gültigkeitsüberprüfung hauptsächlich auf die Überprüfung des Arbeitsnachweises des Blocks, und die Endgültigkeitsüberprüfung besteht darin, festzustellen, ob nach dem Blockheader weitere gültige Blöcke hinzugefügt werden (in der BTC-Kette wird allgemein davon ausgegangen, dass 6 hinzugefügt wird). Anzahl der Blöcke kann die Endgültigkeit eines Blocks bestätigen. In Ethereum wird allgemein angenommen, dass das Hinzufügen von 25 Blöcken die Endgültigkeit eines Blocks bestätigen kann.

Bei PoS-Ketten bezieht sich die Gültigkeitsüberprüfung auf die Überprüfung, ob der Block von einem zufällig ausgewählten Blockproduzenten generiert wurde, und die Endgültigkeitsüberprüfung besteht darin, festzustellen, ob der Block von Prüfern mit mehr als 2/3 der Abstimmungsgewichtung signiert wurde. PoS-Light-Knoten müssen jedoch nicht die Gültigkeit, sondern nur die Endgültigkeit überprüfen. Denn in der PoS-Kette muss der letzte Block gültig sein, in der PoW-Kette jedoch nicht.

Im Folgenden beginnen wir mit der Bestandsaufnahme:

 

BTC-Relais

 

BTC-Relay ist der früheste Light-Node-Vertrag und die früheste Light-Client-Cross-Chain-Brücke. Das Funktionsprinzip ist sehr einfach: Es wird ein BTC-SPV-Light-Knoten auf Ethereum bereitgestellt, um die SPV-Verifizierung von Transaktionen in der BTC-Kette durchzuführen.

Die Off-Chain-Rolle „Relayer“ ist für die kontinuierliche Weitergabe des Blockheaders der BTC-Kette an den Light-Node-Vertrag verantwortlich. Der Light-Node-Vertrag akzeptiert den Blockheader offiziell, nachdem er seine Gültigkeit und Endgültigkeit überprüft hat.

Der Relayer zahlt Ethereum die Gasgebühr für die Speicherung und Überprüfung des Blockheaders. Gleichzeitig erhält der Relayer Gebühren als Entschädigung von dem Benutzer, der die kettenübergreifende Anfrage initiiert hat, und erzielt entsprechende Gewinne. Jeder kann ein Relayer werden und den Gebührenstandard für jeden Anruf festlegen. Wenn andere ein Relayer werden möchten, können sie eine kleine Gebühr an den aktuellen Relayer zahlen und stattdessen einen niedrigeren Gebührenstandard festlegen , Hoch, Sie können den Relayer-Dienst auch selbst ausführen.

Es ist zu beachten, dass BTC Relay eine Einwegbrücke ist, die nur die Überprüfung von BTC-Informationen auf Ethereum unterstützt und keine Informationsüberprüfung in die entgegengesetzte Richtung unterstützt. Daher gibt BTC Relay keine kettenübergreifenden derivativen Vermögenswerte von BTC aus und sein Anwendungsfall beschränkt sich auf die Unterstützung von Benutzern bei der Verwendung von Bitcoin zur Zahlung von Gebühren auf Ethereum.

Natürlich kann BTC Relay als Baustein und unidirektionale Vertrauensschicht verwendet werden, um Transaktionsverifizierungsdienste in der Richtung BTC → Ethereum für andere kettenübergreifende BTC-Derivate bereitzustellen.

Offizielle Website von BTC Relay: http://btcrelay.org/BTC Relay-Dokumentation: https://github.com/ethereum/btcrelay

 

Waterloo-Brücke

 

WaterLoo Bridge ist eine von Kyber Network entwickelte Cross-Chain-Bridge. Sie ist auch die erste Cross-Chain-Brücke, die eine bidirektionale Light-Client-Verifizierung implementiert. Obwohl die WaterLoo Bridge aufgrund des Niedergangs von EOS wenig Beachtung gefunden hat, ist ihre technische Lösung immer noch repräsentativ.

Waterloo Bridge implementiert den Light Client von EOS über Ethereum Smart Contracts und implementiert auch den Light Client von Ethereum über EOS Smart Contracts.

Da Ethereum relativ langsam Blöcke produziert und die Rechen- und Speicherressourcen auf EOS relativ ausreichend sind, handelt es sich bei dem von WaterLoo auf EOS eingerichteten Ethereum-Light-Node-Vertrag um einen SPV-Light-Node. Er steht im Einklang mit dem BTC-Relay-Prinzip und speichert das Ethereum Block-Header. Nacheinander mit Light-Node-Verträgen synchronisieren.

Allerdings werden EOS-Blöcke sehr schnell produziert und die Ressourcen auf Ethereum sind knapp. Daher ist der EOS-Light-Node-Vertrag auf Ethereum darauf ausgelegt, Blöcke nur mit Änderungen im BP-Set (Blockproduzenten-Set) zu synchronisieren, und nicht einzeln. Synchronisieren Sie kontinuierlich alle Blöcke. Ein solches Design muss jedoch zwei Probleme lösen:

  • So überprüfen Sie historische Blockheader: Wenn sich die zu überprüfende Transaktion nicht im gespeicherten Block befindet, muss der Light-Node-Vertrag zunächst den entsprechenden Blockheader vom vollständigen Knoten abrufen. Hier ist jedoch noch ein Überprüfungsprozess erforderlich. Wie überprüft der Light-Node-Vertrag diese erhaltenen Blockheader?

  • So überprüfen Sie den neuesten Blockheader: Wie kann die Endgültigkeit des neuesten synchronisierten Blockheaders überprüft werden, ohne den vollständigen Verlauf des Blockheaders zu haben?

So überprüfen Sie historische Blockheader

Der Light-Node-Vertrag muss in der Lage sein, den vom vollständigen Knoten erhaltenen Blockheader anhand des gespeicherten Blockheaders zu überprüfen. Wie macht man das? Wir müssen verstehen, dass das Konsensprotokoll von EOS DPoS ist. Der Staker von $EOS wählt abwechselnd 21 BPs, um Blöcke zu generieren, und zwar jedes Mal, wenn ein Block generiert wird von 21 BPs verarbeitet werden, gelten Blöcke, die von mehr als 15 BPs signiert wurden, als endgültig und diese Signaturen werden im Blockheader widergespiegelt.

Obwohl EOS Blöcke schneller produziert, ändert sich der BP-Satz nicht sehr häufig. Solange der Light-Client über die Liste der BP-Sätze (Liste öffentlicher Schlüssel) verfügt, kann er alle Blockheader innerhalb der Laufzeit des BP-Satzes überprüfen. Mit anderen Worten: Wenn der vom Vollknoten erhaltene Blockheader in der entsprechenden Laufzeit von 15 BPs signiert wurde, wird er vom Light-Client-Vertrag akzeptiert.

So überprüfen Sie den neuesten Blockheader

Da die Wahlabstimmung für den BP-Satz in der Kette erfolgt, werden die Abstimmungsergebnisse im Blockheader eines bestimmten Blocks Block{i} widergespiegelt. Der Blockheader von Block{i} spiegelt die Liste des BP-Satzes und ihrer wider Bedingungen. . Wenn Block{i} und der darin enthaltene neue BP-Satz generiert werden, ist der neue BP-Satz noch nicht wirksam und Block{i} wird vom alten BP-Satz signiert.

Einfach ausgedrückt können wir auch verstehen, dass die alte BP-Gruppe die neue BP-Gruppe genehmigt hat, indem sie einen Block mit den Wahlergebnissen der neuen BP-Gruppe unterzeichnet hat. Solange der Light-Client den anfänglichen BP-Satz korrekt erfasst und den Block erfasst, in dem sich der BP-Satz jedes Mal ändert, kann er über eine solche „Genehmigungsbeziehungskette“ bis zum neuesten BP-Satz zurückverfolgt werden. Indem Sie den neuesten BP-Satz beherrschen, können Sie den neuesten Block überprüfen.

Solange daher bei der Initialisierung der korrekte anfängliche BP-Satz in den Light-Client-Vertrag eingegeben wird, kann der Light-Client die nachfolgenden Verifizierungsarbeiten selbstständig durchführen.

Nachrichtenüberprüfungsprozess

Wenn auf EOS eine Nachricht vorhanden ist, die kettenübergreifend an Ethereum übertragen werden muss, wird Waterloo Bridge Folgendes tun: ① Überprüfen Sie, ob der Blockheader des Blocks, in dem sich die Nachricht befindet, bereits im Light-Client vorhanden ist. Fahren Sie mit Schritt ② fort. Der Relayer ruft den Blockheader ab, in dem sich die Nachricht befindet, und übermittelt ihn an den Light-Client Mit anderen Worten: Der Light-Client prüft den Blockheader, indem er feststellt, ob er von mehr als 2/3 des BP-Sets signiert ist Verifizierung, um eine SPV-Verifizierung für die Nachricht durchzuführen.

Der Konsensmechanismus von EOS gehört zum Konsensmechanismus vom BFT-Typ, und die Light-Client-Implementierungsmethode von EOS ist zu einem typischen Paradigma für öffentliche Chain-Light-Clients vom BFT-Typ geworden.

Einführung in WaterLoo Bridge (Teil 1) https://blog.kyber.network/waterloo-a-decentralized-practical-bridge-between-eos-and-ethereum-1c230ac65524 Einführung in WaterLoo Bridge (Teil 2) https://blog .kyber.network/waterloo-a-decentralized-practical-bridge-between-eos-and-ethereum-c25b1698f010

 

Regenbogenbrücke

 

Rainbow Bridge ist die offizielle Cross-Chain-Brücke, die von Near entwickelt wurde, um das Near-Ökosystem und das Ethereum-Ökosystem zu verbinden. In der Rainbow-Bridge-Dokumentation wird Folgendes erwähnt: Der Hauptdesigner von Rainbow Bridge ist Anton Bukov, der jetzt CTO von 1 Zoll ist. Obwohl er nicht mehr hauptberuflich bei Near arbeitet, leitet er immer noch die Entwicklung von Rainbow Bridge.

Struktur

Die Kernkomponenten von Rainbow Bridge sind zwei On-Chain-Verträge und drei Off-Chain-Agenten:

On-Chain-Vertrag:

  • EthOnNearClient: Ethereum-Light-Knoten, implementiert als Near-Vertrag in Rust

  • NearOnEthClient: Near Light Node, implementiert als Ethereum-Vertrag in Solidity

Off-Chain-Proxy:

  • Eth2NearRelay: Verantwortlich für die Übergabe des Ethereum-Blockheaders an EthOnNearClient

  • Near2EthRelay: Verantwortlich für die Übergabe des Near-Block-Headers an NearOnEthClient

  • Watchdog: Verantwortlich für die Herausforderung von Near2EthRelay, das ungültige Blockheader übermittelt, Details später

EthOnNearClient muss jeden Blockheader auf Ethereum verfolgen. NearOnEthClient muss nur einen Blockheader für jede Epoche verfolgen. Eine Epoche von Near umfasst etwa 43.000 Blöcke, was etwa 4 Stunden dauert. Es wäre unrealistisch, sie alle zu synchronisieren. Der Validatorsatz von Near ändert sich nur einmal pro Epoche, und jede Epoche verfügt nur über einen Blockheader, der die Auswahlinformationen des Validatorsatzes enthält. Das Design von NearOnEthClient basiert stark auf EosOnEthClient in WaterLoo Bridge und verwendet sogar einen Teil des Codes von WaterLoo Bridge wieder.

Für NearOnEthClient gibt es jedoch immer noch ein technisches Problem: Ethereum ist nicht mit dem von Near verwendeten Signaturformat Ed25519 kompatibel, was die Überprüfung der Near-Blockheader durch NearOnEthClient sehr problematisch macht. Daher führt Rainbow Bridge ein optimistisches Verifizierungsschema ein.

Wenn Near2EthRelay den Block-Header an NearOnEthClient übermittelt, muss es einige $NEAR in der Near-Kette hinterlegen. Während des 4-Stunden-Fensters können Challenger, die als Watchdogs bezeichnet werden, Challenges auslösen Der Blockheader wird von NearOnEthClient offiziell akzeptiert. Wenn ein Watchdog eine Herausforderung stellt und die Herausforderung erfolgreich ist, zahlt das Near2EthRelay, das den ungültigen Block-Header übermittelt hat, einen finanziellen Preis, die Hälfte seiner Sicherheiten wird vernichtet und die verbleibende Hälfte wird zum Kopfgeld des Watchdogs, der die Herausforderung gestellt hat .

Die Einführung der optimistischen Verifizierung bringt eine neue Vertrauensannahme mit sich: Mindestens ein Watchdog ist loyal.

Im BTC-Relay läuft nur ein Relayer gleichzeitig, aber in Rainbow Bridge, egal ob Eth2NearRelay oder Near2EthRelay, dürfen mehrere gleichzeitig laufen. Mehrere Relayer können miteinander konkurrieren und gleichzeitig versuchen, denselben Block einzureichen. Mehrere Relayer können jeweils auch Backups füreinander bilden Senden Sie es, was die Möglichkeit der Nichtverfügbarkeit des Dienstes verringert.

Anreize

Derzeit bietet Rainbow Bridge keine wirtschaftlichen Anreize für die beiden Gruppen von Relay-Diensten, die Blockheader weiterleiten, da Near davon ausgeht, dass die Hauptanwendungen, die auf Rainbow Bridge ausgeführt werden (zum Beispiel: $ETH Asset Bridge, $NEAR Asset Bridge, ERC20 Asset Bridge, NFT Bridge) führt automatisch Relay-Dienste aus, und mindestens ein Paar Relay-Dienste werden offiziell von Near betrieben. Zukünftige Versionen von Rainbow Bridge könnten die wirtschaftlichen Anreize für Relay-Dienste erhöhen und entsprechende Gebührenmechanismen für kettenübergreifende Benutzer/Anwendungen verbessern.

neuesten Fortschritt

Near hat die EVM-kompatible Umgebung Aurora veröffentlicht. Derzeit unterstützt Rainbow Bridge 2.0 die Cross-Chain zwischen Ethereum und Aurora. Wenn Sie von Ethereum zu Near wechseln müssen, müssen Sie den Aurora-Transfer durchführen. Es ist zu beachten, dass Aurora zwar ein unabhängiges Ledger unterhält und über einen unabhängigen Blockchain-Browser verfügt, es sich jedoch nicht um eine unabhängige Blockchain handelt, eine Laufzeit auf Near Aurora jedoch nicht über einen unabhängigen Validatorsatz verfügt -Kettenbrücke, sondern eine Brücke zwischen Laufzeiten. Wir müssen auch beachten, dass Ethereum zum Zeitpunkt des Schreibens dieses Artikels gerade seine PoS-Transformation abgeschlossen hat. Daher werden die Ethereum-Light-Clients, die für die PoW-Version in Rainbow Bridge und WaterLoo Bridge entwickelt wurden, möglicherweise in naher Zukunft neu gestaltet.

Näheres Einführungsdokument:

https://near.org/blog/eth-near-rainbow-bridge/

 

Schneebrücke (Schneegabel)

 

SnowBridge ist ein offizielles Cross-Chain-Bridge-Projekt mit Polkadot, das vom Snowfork-Team entwickelt wurde. Sein Zweck besteht darin, eine native Verifizierungsbrücke zwischen dem Polkadot-Ökosystem und Ethereum zu schaffen.

Snowbridge ist ein Projekt, das sich noch in der Entwicklung befindet, und zwar aus der aktuellen Dokumentation von SnowBridge, die an manchen Stellen immer noch „in Kürze verfügbar“ zu sein scheint . Analyse durchführen.

Snowbridge wird über eine eigene Parachain verfügen, die künftig als Gemeinwohl-Parachain betrieben wird. Diese Parachain wird für den Aufbau einer Brücke mit Ethereum verantwortlich sein. Andere Parachains werden indirekt über SnowBridge Parachain eine Brücke schlagen. Dies bedeutet, dass der Light Node Pallet von Ethereum auf der SnowBridge Parachain ausgeführt wird.

  • In Substrate gibt es kein Vertragskonzept. Entwickler stellen Anwendungen in der Kette bereit, indem sie Paletten hinzufügen, aber ihr Wesen ist dasselbe wie bei Verträgen, und beide sind Laufzeiten in der Kette.

Snowbridge besteht aus den folgenden Modulen

Auf Ethereum bereitgestellte Verträge:

  • Polkadot RPC: Wird zur Bearbeitung kettenübergreifender Anfragen auf Ethereum verwendet

  • POLKADOT UND PARACHAIN ​​​​LIGHT CLIENT VERIFIER

Auf Snowbridge Parachain eingesetzte Palette:

  • ETHEREUM RPC wird zur Bearbeitung kettenübergreifender Anfragen auf Polkadot verwendet

  • Ethereum LIGHT CLIENT VERIFIER

Ethereum Light-Client auf Snowbridge Parachain

Laut der aktuellen Dokumentation von Snowbridge (2022.10.14) ist der Ethereum Light-Client als SPV-Light-Knoten konzipiert. Der Relayer ist für die Synchronisierung der Ethereum-Blockheader nacheinander verantwortlich. Der Light-Client Pallet prüft den Arbeitsnachweis und folgt ihm Der schwerste Split. (Aber um sich nach der Umstellung auf PoS an Ethereum anzupassen, sollte Snowbridge über neue Lösungen verfügen.)

Polkadot Light-Client auf Ethereum

Es ist zu beachten, dass der Light-Client den Block-Header der Relay-Kette und nicht den Block-Header von SnowBridge Parachain synchronisiert, da die Relay-Kette für den Konsens von SnowBridge Parachain verantwortlich ist. Um den Überblick über die neuesten Informationen zum Validatorsatz zu behalten, muss der Blockheader, der die Neuauswahl des Validatorsatzes enthält, synchronisiert werden, was bedeutet, dass in jeder Epoche mindestens ein Blockheader synchronisiert werden muss. Wenn es eine Transaktion gibt, die überprüft werden muss, wird der SnowBridge Parachain-Blockheader bei Bedarf von der Relay-Kette angefordert und seine Endgültigkeit wird anhand des Relay-Chain-Blockheaders überprüft, der ihn enthält.

Im Vergleich zu WaterLoo steht Snowfork vor einem neuen Problem: EOS hat nur 21 Validatoren, aber Polkadot hat etwa 1.000 Validatoren. Selbst wenn nur 2/3 der Validatoren einen Block signiert haben, werden in Ethereum 600 verifiziert Auch die Anzahl der Unterschriften ist unverschämt hoch. Rainbow Bridge umgeht dieses Problem durch optimistische Authentifizierung, während Snowfork sich dafür entscheidet, es direkt anzugehen.

Die Lösung von Snowbridge besteht darin, einen Stichprobenmechanismus anzuwenden: Beim Abrufen des Blockheaders wählt der Light-Client zufällig eine Teilmenge aus der Menge der Validatoren aus, die dem Blockheader entspricht. Der Light-Client überprüft nur die Signaturen dieser Teilmenge, ohne alle überprüfen zu müssen. s Unterschrift. Laut der Untersuchung von Snowfork muss die Anzahl der Validatoren in dieser Teilmenge nur ceil(log2(3*N)) betragen (N ist die Gesamtzahl der Validierungen). Wenn N 1000 ist, müssen nur 12 Validatorsignaturen extrahiert werden.

FLEISCH

Um die Überbrückung mit anderen öffentlichen Ketten besser zu unterstützen, hat Polkadot ein letztes Gadget namens BEEFY entwickelt, das auf dem GRANDPA-Konsens basiert (zum Zeitpunkt dieses Schreibens wird der Code von BEEFY noch verbessert). Nachdem der Block der Polkadot-Relay-Kette von GRANDPA beendet wurde, wird es einen BEEFY-Konsens-Signatur-Link geben. In diesem Link muss der Validator MMR-Rooting zum Block-Header hinzufügen und dann eine separate Runde der Konsens-Signatur für den Block durchführen Header.

Mit BEEFY müssen Light-Kunden die Feinheiten von GRANDPA nicht verstehen und müssen lediglich die BEEFY-Signatur überprüfen. Das Wichtigste ist, dass das BEEFY-Signaturformat vollständig mit Ethereum kompatibel ist, sodass es auf Ethereum-Seite leicht verifiziert werden kann.

Anreize

SnowBridge wird in zwei Phasen veröffentlicht. Diese Phase verfügt bereits über die Grundfunktionen einer Cross-Chain-Brücke, es gibt jedoch keine Anreize für Head Relayer und Message Relayer. Wenn Benutzer/Anwendungen sicherstellen möchten, dass ihre Nachrichten erfolgreich weitergeleitet werden, müssen sie den Relayer-Dienst selbst ausführen. Die zweite Phase wird zur Incentive Bridge übergehen, die Anreize für Relayer schaffen wird.

Anwendungsschicht

Im Plan des Snowfork-Teams werden nach der Online-Schaltung von SnowBridge bald drei Asset Bridges veröffentlicht, nämlich DOT Asset Bridge: unterstützt die Erstellung von snowDOT ETH Asset Bridge auf Ethereum; unterstützt die Erstellung von snowETH auf der Polkadot-Seite; Erstellen Sie auf der Polkadot-Seite eine zugeordnete Version des ERC20-Assets mit dem Namensformat: snow-[Asset-Name].

Snowbridge-Dokumentation

https://snowbridge-docs.snowfork.com/

Tolle Dokumentation

https://github.com/paritytech/grandpa-bridge-gadget/blob/master/docs/walkthrough.md

 

LCMP (Darwinien)

 

LCMP (Light-Client Cross-Chain Messaging Protocol) ist ein heterogenes Cross-Chain-Protokoll, das von Darwinia entwickelt wurde. Es handelt sich um ein universelles und offenes Cross-Chain-Übertragungsprotokoll, das auf einer Light-Client-Lösung basiert. Das Protokoll liegt derzeit in Form eines SDK vor, sodass Dapps frei integriert werden können. In der von Darwinia aufgebauten kettenübergreifenden ökologischen Struktur gibt es zwei Ketten, Darwinia Chain und Darwinia Parachain. Beide haben entsprechende kanarische Netzwerke, Crab Chain und Crab Parachain, von denen Crab Parachain Kusama ist. von parallelen Ketten.

Auf Darwinia Chain wird eine EVM-kompatible Umgebung namens Darwinia Smart Chain bereitgestellt. Sie heißt Chain, weil Darwinia Smart Chain über eine unabhängige Zustandsmaschine und einen unabhängigen Browser verfügt, es sich jedoch nicht um eine unabhängige Blockchain handelt. (Siehe die Beziehung zwischen Aurora und Near) Dementsprechend gibt es auf Crab Chain eine EVM-kompatible Umgebung namens Crab Smart Chain.

Leichtes Client-Design

Zum jetzigen Zeitpunkt wurde LCMP implementiert

  • Die Brücke zwischen Darwinia Chain und Ethereum

  • Überbrückung von Krabbenkette und Krabbenparachain

Unter ihnen ist die von letzterem verwendete Light-Client-Lösung dieselbe wie die von Waterloo. Wir konzentrieren uns auf die Light-Client-Lösung, die zur Überbrückung von Darwinia Chain und Ethereum verwendet wird. Darwinia-Chain-Client auf Eth Da Beefy noch nicht verfügbar ist, ist die Block-Header-Signatur der auf Basis von Substrate entwickelten Darwinia-Chain nicht mit Ethereum kompatibel.

Darwinia verabschiedet derzeit einen Übergangsplan und wählt durch die Leitung des Parlaments eine Unterzeichnergruppe, die für die Unterzeichnung des Blockheaders der Darwinia-Kette verantwortlich ist. Der Light-Client überprüft, ob der Blockheader legal ist, indem er die Signatur der Gruppe überprüft. Obwohl es auf der Darwinia-Kette mehr als 100 Validatoren gibt, beträgt die Unterzeichnergruppe nicht mehr als 10 Personen, und die wirtschaftlichen Kosten auf der Ethereum-Seite für die Überprüfung dieser Signaturen sind akzeptabel.

ETH-Client in der Darwinia-Kette

Die zusammengeführte Ethereum-Beacon-Kette verfügt als PoS-Kette über Hunderttausende Validatoren, und es ist offensichtlich unrealistisch, deren Signaturen zu überprüfen. Daher hat Ethereum in einem Upgrade namens Altair einen neuen Konsenslink hinzugefügt. Nach dem Altair-Upgrade wird alle 256 Epochen (ca. 27 Stunden) ein Gremium von 512 Validatoren aus der Ethereum-Kette ausgewählt. Sie sind für die Unterzeichnung des endgültigen Blockheaders verantwortlich. Der Light-Client muss lediglich überprüfen, ob 2/3 des Komitees es unterzeichnet haben, um einen Blockheader zu überprüfen. Allerdings ist 512 immer noch etwas zu viel, daher nutzt Ethereum auch die BLS-Technologie, um die zahlreichen Signaturen des Komitees in einer Signatur zusammenzufassen, was die Verifizierungskosten von Light-Clients weiter senkt.

Darwinia wurde auf Basis von Altair aktualisiert und hat einen Light-Client von Ethereum auf der Darwinia-Kette implementiert. Der Light-Client muss nur alle 27 Stunden einen Blockheader synchronisieren. Dies sollte der erste On-Chain-Light-Client sein, der nach der PoS-Transformation auf Ethereum implementiert wird.

Gebühren und Anreize

Der kettenübergreifende Initiator (der ein Benutzer oder ein Dapp sein kann) muss beim Senden einer kettenübergreifenden Nachricht eine Gebühr zahlen. Die Gebühr besteht aus drei Teilen:

  • Gasgebühren für die Durchführung von Transaktionen in der Lieferkette.

  • An Relayer gezahlte Gebühren.

Die konkrete Preisgestaltung wird vom Markt bestimmt und zahlreiche Relayer können preislich konkurrieren. Es ist zu beachten, dass der Relayer die Gasgebühr für die Zielkette zahlen muss und dass der Relayer diese Kosten in der Preisgestaltung widerspiegelt. Mit anderen Worten: Der kettenübergreifende Initiator muss die Gasgebühr für die Zielkette nicht mehr zahlen separat.

  • An Treasure gezahlte Gebühren.

Ein bestimmter Prozentsatz der von Cross-Chain-Initiatoren gezahlten Cross-Chain-Gebühren fließt in Darwinia Treasure. Treasure wird einen Teil seiner Mittel zur Subventionierung von Head Relayer verwenden.

Darwinia-Dokumente:

https://docs.darwinia.network/lcmp-overview

Weitere Altair-Forkshttps://blockdaemon.com/blog/ethereum-altair-hard-folk-light-clients-sync-committees/

 

zkBrücke

 

Zum jetzigen Zeitpunkt handelt es sich bei zkBridge um ein junges Projekt, dessen Entwicklung erst in geringem Umfang abgeschlossen ist. Dieses Projekt ist jedoch eines der wenigen Projekte, das bisher wissensfreie Technologie für den Bau von Cross-Chain-Brücken nutzt. zkBridge verwendet ZK-SNARK-Proof für die Erweiterung von Lichtknoten.

Derzeit hat zkBridge mithilfe von Solidity eine Instanz des Cosmos Client auf Ethereum implementiert. Tests zufolge kann es in 2 Minuten ein ZK-SNARK-Zertifikat für den Cosmos Zone-Blockheader generieren und es dann auf der Ethereum-Seite verifizieren, indem es nur 220.000 Gas ausgibt Wenn dagegen kein ZK-SNARK-Nachweis verwendet wird, belaufen sich die Kosten auf 64 Millionen Gas.

Die wichtigsten Neuerungen von zkBridge sind:

  • deVirgo: Verwenden Sie eine verteilte Methode, um ZK-SNARK-Beweise zu generieren. Diese Methode verbessert die Effizienz der Off-Chain-Erstellung von ZK-SNARK-Beweisen erheblich, indem sie die Berechnungszeit aufteilt.

  • Rekursiver Beweis: Um die Kosten in der Kette zu senken, verwendet zkBridge ein rekursives Beweisschema (ein Beweis, der einen Beweis generiert), um den ZK-SNARK-Beweis durch zwei Rekursionen auf etwa 131 Bytes zu komprimieren.

  • Stapelverarbeitung: zkBridge implementiert einen Blockheader-Aktualisierungsvertrag, der die Blockhöhe als Eingabe verwendet und den entsprechenden Blockheader zurückgibt. Allerdings ruft zkBridge den Aktualisierungsvertrag nicht auf, wenn jeder neue Block generiert wird. Der Prüfer kann zunächst N Blockheader sammeln, um einen einzelnen Beweis zu generieren. Der N-Wert kann eingestellt werden. Je größer N, desto länger ist die Wartezeit des Benutzers, aber desto niedriger sind die Systembetriebskosten.

Man muss sagen, dass die wissensfreie Technologie eine Technologie ist, die Wunder bewirken kann. Der größte Engpass, der ihre Einführung einschränkt, ist die hohe technische Hürde und die Schwierigkeit bei der Entwicklung. Bei der Entwicklung einer wissensfreien Technologie sind jedoch die Belohnungen und Anstrengungen immer angemessen.

zkBridge Twitter langer Beitrag: https://twitter.com/dawnsongtweets/status/1574775723767783424

zkbridge-Papier:

https://rdi.berkeley.edu/zkp/zkBridge/uploads/paper.pdf

 

MAP-Protokoll

 

Das MAP-Protokoll ist ein allgemeines heterogenes Cross-Chain-Protokoll, das auf Light Clients und Relay Chains basiert.

Im Gegensatz zu vielen der oben genannten Projekte entschied sich MAP für die Einrichtung einer Relay-Kette MAP Chain als Übergabestation für die kettenübergreifende Nachrichtenübertragung. Zugriffsketten müssen nicht direkt miteinander verbunden sein, sondern sind alle mit der MAP-Kette verbunden. Das heißt: Jede Zugriffskette muss nur den Light-Node-Vertrag der MAP-Kette und die Light-Knoten jedes Zugriffs bereitstellen Chain werden im MAP-Chain-Vertrag bereitgestellt.

Die Architektur des MAP-Protokolls ist in drei Schichten unterteilt, nämlich Protokollschicht, kettenübergreifende Serviceschicht und Anwendungsschicht. In:

  • Protokollschicht: Wir können sie als Vertrauensschicht verstehen, einschließlich der MAP-Kette und jedes Light-Client-Programms für die Zugriffskette.

  • Kettenübergreifende Serviceschicht: Stellen Sie einige gemeinsame Module für die Anwendungsschicht bereit, damit die Anwendungsschicht nicht „das Rad neu erfinden“ muss. Beispielsweise kann ein gemeinsames Vault-Modul Gelder für einige Asset-Bridge-Anwendungen sperren, aber Anwendungen können auch auswählen um eigene Tresore zu erstellen. Dieses Modul wird nicht verwendet.

  • Anwendungsschicht: Bezieht sich auf Anwendungen, die das MAP-Protokoll als kettenübergreifendes Nachrichtenübertragungsmedium verwenden.

Darüber hinaus umfasst das MAP-Protokoll drei Off-Chain-Rollen

  • Betreuer: Verantwortlich für die Aktualisierung der Blockheader jedes Light-Node-Vertrags und kann $MAP-Inflationsprämien erhalten.

  • Messenger: Verantwortlich für die Zustellung kettenübergreifender Nachrichten und kann von Benutzern gezahlte kettenübergreifende Gebühren erhalten, muss jedoch die Gasgebühren auf der Zielkette und der Relay-Kette vorstrecken.

  • Validator der MAP-Kette: Verantwortlich für den Konsensprozess der MAP-Kette und muss $MAP verpfänden, um $MAP-Inflationsprämien zu erhalten. MAP Chain verwendet derzeit den IBFT-PoS-Konsensmechanismus.

Kettenübergreifender Nachrichtenfluss

Das MAP-Protokolldokument erwähnt nicht viel über den Nachrichtenübertragungsmechanismus. Aus den aktuellen Worten sollte der Nachrichtenfluss wie folgt aussehen: Wenn die Anwendung in der Quellkette eine kettenübergreifende Anforderung initiiert, ist die kettenübergreifende Nachricht M enthalten In der Transaktion T1 wird sie vom Messenger an die Relay-Kette gesendet. Nach dem Empfang der Transaktion T1 leitet die Relay-Kette die Nachricht M in die Transaktion T2 weiter Die Zielkette empfängt sie an T2 und sendet sie nach der Überprüfung an die Zielanwendung.

Obwohl das MAP-Protokoll ein im Jahr 2019 gestartetes Projekt ist, sind die einzigen unterstützten Ketten bisher Ethereum, BSC und Polygon. Das Wort „universell“ ist seines Namens nicht würdig. Da Light-Node-Verträge bei der Erweiterung auf verschiedene Ketten nicht wiederverwendet werden können und separat entwickelt werden müssen, ist es schwierig, kettenübergreifende Brücken zu erstellen, die auf Light-Node-Verträgen basieren und „universell“ sind.

Dokumentation zum MAP-Protokoll https://docs.maplabs.io/

 

Cosmos IBC

 

IBC ist ein sehr gut konzipiertes isomorphes Cross-Chain-Protokoll und ein wichtiger Teil des Cosmos-Cross-Chain-Netzwerks. Das Cosmos-Cross-Chain-Netzwerk besteht hauptsächlich aus Hub und Zone und Hub wird durch das IBC-Protokoll (InterBlcokChain) überbrückt . Zonen und Brücken werden zwischen Zonen eingerichtet, wobei der Hub als Relais dient. Das Cosmos-Cross-Chain-Netzwerk umfasst auch Peg Zone und heterogene Bridging-Teile, die nicht in den Geltungsbereich von IBC fallen. Sowohl Hub als auch Zone sind für den Zugriff offen. Jede Blockchain, die auf dem Cosmos SDK basiert, kann zu einem Hub oder zu einer Zone werden und sich als Zugriffskette bei jedem Hub registrieren. Im Gegensatz zur Relay-Kette von Polkadot ist der Hub von Cosmos nicht einzigartig.

leichter Kunde

Jede beim Hub registrierte Zone muss ein IBC-Modul bereitstellen, das den Light-Client-Vertrag des Hubs enthält. Das IBC-Modul im Hub integriert auch den Light-Client-Vertrag jeder verbundenen Zone.

Im Tendermint-Konsensmechanismus gibt es kein Epochenkonzept, und jeder Block kann zu Änderungen bei den Validatoren führen. Der Light-Client-Vertrag in IBC verfügt jedoch über das Konzept der TrustPeriod (Vertrauensperiode), einem Parameter, den der Light-Client während der Initialisierung festlegen muss. Innerhalb einer TrustPeriod darf der Verifizierersatz geringfügige Änderungen vornehmen und einzelne Verifizierer Sie Sie können beitreten oder austreten, es wird jedoch keine wesentlichen Änderungen geben.

Diese kleine Änderung ist akzeptabel, da jede Signatur selten genau 2/3 der Stimmrechte hat und es immer zu einem gewissen Überlauf kommt. Auch wenn einzelne Validatoren beitreten oder austreten, wird der Light-Client die Überprüfung vor der Änderung durchführen Wenn der Benutzer den Blockkopf überprüft, besteht eine hohe Wahrscheinlichkeit, dass immer noch festgestellt werden kann, dass 2/3 der Stimmrechte unterzeichnet wurden.

Daher muss der Light-Client-Vertrag in IBC die Validator-Set-Informationen nur einmal pro TrustPeriod aktualisieren, was bedeutet, dass jeder TrustPeriod nur einen Blockheader synchronisieren muss.

Die Synchronisierung der Blockheader wird von Relayer übernommen.

Kernkonzepte und Prinzipien

IBC konstruiert drei abstrakte Konzepte, nämlich Verbindung, Kanal und Paket.

  • Verbindung

Unter „Verbindung“ versteht man die Verbindung zwischen zwei Zonen. Zu diesem Zeitpunkt fordern die beiden Zonen jeweils den neuesten Blockheader vom Hub an. Der Verbindungsaufbau erfolgt nach dem Drei-Wege-Handshake-Prinzip (die Handshake-Kommunikation wird durch Relayer ausgelöst). Nach Abschluss des Handshakes wird die Verbindung geöffnet.

An diesem Punkt kann der Kanal zusätzlich zur Verbindung eingerichtet werden. Channel Connection verbindet zwei Zonen, während Channel ein Anwendungspaar in den beiden Zonen verbindet (das Anwendungspaar kann aus derselben Anwendung oder aus unterschiedlichen Anwendungen stammen). Zwei Anwendungen richten einen Kanal über das Drei-Wege-Handshake-Prinzip ein (die Handshake-Kommunikation wird durch Relayer ausgelöst). Nachdem der Kanal eingerichtet ist, können die beiden Anwendungen Pakete aneinander senden.

  • Kanal

Channel ist das Kernkonzept von IBC, das es Anwendungen ermöglicht, direkt Verbindungen herzustellen. Als abstraktes Konzept existiert der Kanal nicht als Einheit. Für die empfangende Anwendung definiert der Kanal den Absender. Wenn Sie wissen, von welchem ​​Kanal die Nachricht stammt, wissen Sie, von welcher Anwendung die Nachricht stammt , Was Anwendungen betrifft, definiert der Kanal den Empfänger, an welche Anwendung Sie eine Nachricht senden möchten. Legen Sie die Nachricht in den entsprechenden Kanal.

Der Kanal definiert auch das Nachrichten-Timing. Nachrichten im selben Kanal folgen einer Warteschlange und haben eine strikte Zeitbeziehung. Die zuerst gesendete Nachricht kommt immer zuerst an. Es gibt keine zeitliche Beziehung zwischen Nachrichten in verschiedenen Kanälen.

Hierbei ist zu beachten, dass es für eine Anwendung am besten ist, einen Kanal stabil zu nutzen. Wenn beispielsweise eine Asset-Bridge-Anwendung mehrere Kanäle verwendet, um zugeordnete Assets in der Zielkette zu erstellen, generieren mehrere Kanäle unterschiedliche zugeordnete Assets, was unnötige Probleme verursacht.

  • Paket

Paket ist eine standardisierte Datenstruktur und ein vorgeschriebenes Format für kettenübergreifende Nachrichten, die im Kanal übertragen werden dürfen. Die Paketübertragung ist in drei Schritte unterteilt:

  • sendPacket: Die Anwendung auf der sendenden Seite erstellt ein Paket mit der Seriennummer N in der Quellkette und fügt es der Warteschlange hinzu.

  • recvPacket: Der Relayer leitet das Paket an die Zielkette weiter, wo es von der Anwendung auf der Empfängerseite gespeichert wird.

  • AcknowledgePacket: Der Relayer überträgt den Beweis, dass die empfangende Anwendung das Paket gespeichert hat, zurück an die Quellkette, und die Quellkette löscht das Paket mit der Seriennummer N in der Ausgangswarteschlange.

Wenn der empfangende Vertrag das Paket längere Zeit nicht speichert, gibt Relay eine Timeout-Meldung zurück. Es ist zu beachten, dass sich Cosmos IBC vom MAP-Protokoll unterscheidet. Pakete werden direkt von der Quellzone an die Zielzone gesendet und müssen nicht im Hub weitergeleitet werden. Dies liegt daran, dass die Zielzone den Hub direkt nach dem Blockheader der Quellzone abfragen und dann eine Überprüfung des Pakets durchführen kann. Das bedeutet, dass Hub nur den Blockheader weiterleiten muss.

Insbesondere gibt es einen Lichtknoten der Quellzone auf dem Hub, der den Blockheader der Quellzone überprüfen kann. Es gibt einen Lichtknoten des Hubs auf der Zielzone, der den Blockheader des Hubs überprüfen kann Die Zielzone erfordert einen bestimmten Quellzonenblock-Header SourceZoneBlockHead{i}. Sie können den Relayer ihn vom Hub abrufen lassen. Der Lichtknoten in der Zielzone überprüft HubBlockHead{i} und verwendet HubBlockHead{i}, um SourceZoneBlockHead{i} zu überprüfen }. Danach können Sie SourceZoneBlockHead{i} verwenden, um das Paket der Quellzone zu überprüfen.

Gebühren und Anreize

In IBC gibt es ein konfigurierbares Gebührenmodul, und der Initiator von Connection kann den Gebührenstandard und den Zahlungsstandard für Relayer anpassen. Nach unserer Beobachtung sind Zonenprojektparteien und Anwendungsprojektparteien jedoch häufig motiviert, Relayer selbst zu betreiben.

Cosmos IBC-Dokumente

https://ibc.cosmos.network/Cosmos IBC-Codeanalyse https://blog.csdn.net/mutourend/article/details/122576435

 

Zusammenfassung

 

Im Hinblick auf das Design von Light-Client-Lösungen basieren PoW-Light-Clients derzeit noch auf SPV-Light-Clients, die alle Blockheader der Quellkette einzeln synchronisieren, während PoS-Light-Clients meist ein Sprungsynchronisierungsschema für Blockheader verwenden Nur die Blockheader, die den Validatorsatz ändern, werden synchronisiert. Wir müssen den Light-Client die Änderungen im Validatorsatz nur dann erfassen lassen, wenn die Initialisierung korrekt ist, damit der Light-Client den neuesten Validatorsatz erfassen kann.

In der Praxis werden beim Aufbau von Light-Clients auch Probleme wie hohe Kosten für die Block-Header-Verifizierung und Inkompatibilität von Signaturschemata auftreten. Verschiedene Projekte werden unterschiedliche Methoden anwenden, um damit umzugehen, einschließlich optimistischer Verifizierung (RainbowBridge), Validator-Set-Sampling (Snowfork), Zero-Knowledge-Proofs (zkBridge) werden außerhalb der Kette generiert. Um Cross-Chains besser zu unterstützen, sind auch öffentliche Ketten motiviert, sich selbst zu transformieren und zu aktualisieren, wie zum Beispiel das Ethereum Altair-Upgrade und die Entwicklung des Beefy-Moduls durch Polkadot.

Kurz gesagt, die Light-Client-Technologie befindet sich immer noch in einer intensiven Entwicklung. Mit zunehmender Forschung und Erkundung wird die Schwierigkeit, Light-Clients zu erstellen, in Zukunft allmählich abnehmen.