Projekthintergrund

1. Schicht 1 und geschlossene Insel

• Schicht 1 bezieht sich auf die zugrunde liegende Blockchain

• Einschließlich Ethereum, Bitcoin, Solana, Polkadot, Near, Cosmos, Aptos, Sui usw.

• sind die Hauptnetzwerke in ihren jeweiligen Ökosystemen

• Layer 1 kann Transaktionen auf seiner eigenen Blockchain verarbeiten und abschließen und verfügt außerdem über einen eigenen nativen Token zur Zahlung von Transaktionsgebühren.

• Ethereum ist ein Riese, aber es kann nicht der einzige sein.

https://defillama.com/chains

• Das L1-Ökosystem boomt und greift immer weiter in den ökologischen Anteil der ETH ein

Aus technischen, ökologischen, wettbewerbstechnischen und anderen Gründen sind die Hauptketten isolierte Inseln, die nicht miteinander kommunizieren können und Vermögenswerte nicht übertragen werden können.

II. Kreuzkette

• Cross-Chain: Interoperabilität zwischen mehreren Blockchains, insbesondere Token-Tausch, Token-Transfer und Informationstransfer.

• Der aktuelle Zustand isolierter Blockchains schränkt die Vielfalt der Nutzerbedürfnisse und die Skalierbarkeit der Blockchain ein.

• Mit der zunehmenden Anzahl neuer dApps müssen Assets transferiert und Daten miteinander verknüpft werden.

• Die Cross-Chain-Technologie gilt als der heilige Gral der Blockchain-Forschung, eine Schlüsseltechnologie zur Erreichung der Interoperabilität zwischen verschiedenen Blockchains.

• Seine Bedeutung ist vergleichbar mit der von TCP/IP im Internet; es verwandelt die miteinander verbundenen Netzwerke in das Internet.

• Die enorme Nachfrage nach Web3

1. Die für Web3 erforderliche Gesamtanzahl an Transaktionen pro Sekunde (TPS) kann in die Milliarden gehen, was selbst zahlreiche L1-Server zusammen möglicherweise nicht bewältigen können.

2. Es besteht ein dringender Bedarf, alle L1-Ebenen zu einer einzigen Ebene zusammenzufassen.

III. Cross-Chain-Paradigma

1. Atomarer Tausch basierend auf Hash-Zeitsperre

• Einfaches Prinzip

Benutzer A generiert ein zufälliges Passwort r, berechnet den Hashwert von r m=hash(r) und sendet den Wert von m an Benutzer B;

Unterdessen initiiert Nutzer A eine Transaktion zur Überweisung von 1 BTC an Nutzer B. Der Erfolg dieser Transaktion ist bedingt; sie erfordert...

Benutzer B muss das Passwort r angeben, damit die Transaktion erfolgreich ist; andernfalls schlägt die Transaktion nach Ablauf einer voreingestellten Zeit automatisch fehl.

Nachdem Benutzer B die von Benutzer A initiierte Transaktion gesehen hatte, initiierte er ebenfalls eine Transaktion und überwies 10 ETH an Benutzer A.

Der Erfolg ist bedingt; Benutzer A muss r präsentieren, damit es gelingt.

Nachdem Benutzer A die von B initiierte Transaktion gesehen hat, gibt er den Wert r an, wodurch die Transaktion erfolgreich wird und er 10 aus Bs Überweisung erhält.

Für eine ETH wird der Wert von r offengelegt;

Auch Benutzer B erhielt den von A im vorherigen Schritt angezeigten r-Wert, wodurch die von A initiierte Transaktion erfolgreich war und er 1 BTC von A überwiesen erhielt;

Wird die voreingestellte Zeit (Hash-Zeitsperre) überschritten, schlägt die Transaktion automatisch fehl.

• Hashwerte und Zeitsperren ermöglichen atomare Transaktionen zwischen zwei Vermittlern über verschiedene Ketten hinweg ohne jegliche Vertrauensannahmen, da Hash-Operationen irreversibel sind; die Kenntnis von m erlaubt es nicht, r abzuleiten.

• Sie sind zu einem einzigen Ereignis verknüpft; entweder die gesamte Transaktion ist erfolgreich oder sie schlägt fehl. Es ist unmöglich, dass eine Überweisung von A nach B erfolgreich ist, während eine Überweisung von B nach A fehlschlägt.

• Beide Transaktionsparteien müssen gleichzeitig online sein und den Teilnahmeprozess strikt einhalten. Kann keine Online-Gegenpartei gefunden werden, muss die Transaktion verschoben werden.

• Die Transaktionsgebühren sind relativ hoch.

• Token-Transfer und umfassenderer kettenübergreifender Informationstransfer konnten nicht realisiert werden.

• Häufig verwendet in Kombination mit anderen Cross-Chain-Technologien

2. Mehrere Zeugen

• Die Auswahl der Zeugen kann entweder über einwilligungsbasierte oder frei zugängliche Verfahren erfolgen.

• Das Vertrauen des Nutzers in den Zeugen kann auf dessen eigener Kreditwürdigkeit oder auf dessen übermäßiger Besicherung beruhen.

• Zeugen können benannt, abwechselnd oder nach dem Zufallsprinzip ausgewählt werden.

• Das Zeugenmuster ist eine relativ einfach zu implementierende, äußerst vielseitige und kostengünstige Cross-Chain-Methode.

• Wenn es einem Hacker gelingt, in den Server des Zeugen einzudringen, kann er alle in den Blockchains gesperrten Gelder stehlen.

• Projektmanager könnten Gelder veruntreuen.

• Der gesamte Verifizierungsprozess kann das Risiko böswilligen Verhaltens nicht vollständig ausschließen.

• Cross-Chain-Brücken erlitten im Jahr 2022 Diebstähle in Höhe von 2 Milliarden US-Dollar, wobei Projekte, die die Cross-Chain-Technologie von MPC nutzten, den größten Teil der Verluste zu tragen hatten.

• Gängige Cross-Chain-Infrastrukturen wie Multichain, Celer und Axelar nutzen alle MPC.

3. Quasi-zentralisierte Orakel

• Orakel und Repeater arbeiten unabhängig voneinander und überprüfen sich gegenseitig.

• Chainlinks Oracle übermittelt Cross-Chain-Informationen (Quittungen) von der Quellkette an die Hauptkette. Gleichzeitig übermittelt die Relayer-Kette ebenfalls Cross-Chain-Informationen (Blockhash und BlockreceiptsRoot) an die Hauptkette. Der Transaktionsverifizierungsvertrag der Hauptkette prüft die Übereinstimmung zwischen der von der Relayer-Kette übermittelten Quittung und dem von Chainlink Oracle übermittelten ReceiptsRoot (diese sind nicht sequenziell und müssen bestätigt werden). Bei erfolgreicher Verifizierung gilt die Quittung als gültig und wird an das Protokoll der höheren Schicht weitergeleitet, wodurch nachfolgende Cross-Chain-Transaktionen ausgelöst werden.

• Es muss davon ausgegangen werden, dass Relayer und Oracle unabhängig voneinander agieren, doch diese Vertrauensannahme kann nicht ewig Bestand haben und lässt sich grundsätzlich nicht auflösen.

• Die obigen Ausführungen garantieren, dass die beiden Parteien sich nicht zu einer Verschwörung gegen das Böse verschwören werden.

• Relayer verwendet Einsatzbeträge für ein maßgebliches Ranking. Obwohl die Auswahl zufällig erfolgt, repräsentiert sie dennoch maßgebliche Persönlichkeiten, und das Risiko von Absprachen zwischen dem Orakel und diesen maßgeblichen Persönlichkeiten bleibt bestehen.

• Gleichzeitig ist die kettenübergreifende Datenzufuhr über Orakel nicht genau genug, und der Mangel an Dezentralisierung verhindert die Bereitstellung kryptografischer Beweise, wodurch die Möglichkeit böswilliger Absprachen durch Dritte entsteht.

• Das Token-Projekt heißt LayerZero.

• Nicht absolut dezentralisiert

4. Lichtknoten

4.1 Lichtknoten

• 即 light client

• Es handelt sich dabei um einen kleinen Knoten, der ausschließlich Blockheaderinformationen speichert.

• Light Nodes speichern nicht alle Transaktionen auf der Blockchain, können aber die Authentizität von Nachrichten aus der Quellkette anhand der Block-Header-Informationen überprüfen.

• Der Ablauf ist in etwa wie folgt:

Wenn die Quellkette A (z. B. SOL) die Übermittlung einer kettenübergreifenden Transaktion an die Zielkette B (z. B. ETH) anfordert, übermittelt der Transaktionsinitiator die Transaktionsdetails, die Blockhöhe und den Transaktions-SPV-Nachweis (der sich auf den Mekre-Pfad der Transaktion bezieht) an Kette B.

Der Light-Node-Vertrag der Kette A, der auf Kette B bereitgestellt wird, berechnet den Block-Header-Hashwert des Blocks, in dem sich die Börse befindet, mittels SPV-Beweis neu.

Der ermittelte Hashwert wird mit dem entsprechenden Blockheader-Hashwert im Light Node verglichen. Stimmen sie überein, bedeutet dies, dass die Transaktion tatsächlich im Block stattgefunden hat. Stimmen sie nicht überein, bedeutet dies, dass die Transaktion nicht im Block existiert.

4.2 Doppelketten-Bidirektional-verankerter Leichtbauknoten

• Beide Ketten sind Hauptketten, beide verfügen über Konsensmechanismen und native Token und beide haben ihre eigenen Sicherheitsgarantien.

• Die Beziehung zwischen einer Quellkette und einer Zielkette ist relativ; zwei Ketten können jeweils die Quellkette der anderen sein.

• Bei einem Cross-Chain-Messaging-Ereignis wird die Ursprungskette der Nachricht oft als Quellkette bezeichnet, während die Empfängerkette als Zielkette bezeichnet wird.

• Kettenübergreifende Entitäten können auf die Informationen der jeweils anderen zugreifen und kommunizieren, indem sie die Light Nodes der anderen einbetten. Dieser Mechanismus wird als bidirektionales Pegging bezeichnet.

• Die Relais-Teams in beiden Richtungen sind dafür verantwortlich, Informationen aneinander weiterzuleiten.

• Das repräsentative Projekt ist das MAP-Protokoll, das bidirektional an jede beliebige Kette angebunden werden kann.

4.3 Bidirektionale Verankerung von Teilketten

• Informationen werden zwischen den Subchains und der Hauptkette über Light Nodes ausgetauscht, beispielsweise zwischen dem Polkadot-Mainnet und seinen Subchains, zwischen Cosmos und seinen Subchains sowie zwischen Aurora und seinen Subchains.

• Subchains besitzen keinen eigenen Konsensmechanismus und keine eigenen Token; ihre Sicherheit hängt vollständig von der Hauptkette ab, was eine unidirektionale Beziehung darstellt. Im Gegensatz dazu ist eine Sidechain eine unabhängig operierende Blockchain. Die Beziehung zwischen einer Sidechain und der Hauptkette ist relativ und bidirektional.

4.4 Relaiskette

• Durch die Einrichtung bidirektionaler, verankerter Lichtknoten zwischen je zwei Ketten steigen die Anzahl der Verbindungen und die Anpassungskosten exponentiell mit der Anzahl der Ketten.

• Relaiskette: Es wird eine Relaiskette mit den leichten Knoten aller anderen Hauptketten aufgebaut. Anschließend werden die leichten Knoten jeder Kette aufgebaut. Alle anderen Ketten werden mit der Relaiskette verbunden. Die Kosten sinken dadurch sofort von n(n-1)/2 auf n (wobei n die Anzahl der Ketten ist).

4.5 Vorteile von leichten Relaisknoten

• Gemeinsame Mainnet-Sicherheit

Das Relay-Schema ist eine Variante des Zwei-Wege-Verankerungssystems und nutzt die Sicherheit der Hauptkette mit.

Die Transaktionsinformationen werden anhand der Block-Header verifiziert und ihre Zuverlässigkeit kryptografisch garantiert. Ob eine Transaktion existiert, ist für den Verifizierer irrelevant, wodurch das Verfahren vollständig dezentralisiert ist.

Der Verifizierungsprozess für Light Nodes ist exakt derselbe wie der für das Source Chain Network, sodass sie die gleiche Sicherheit wie das Source Network genießen;

Die von Relayern übergebenen Block-Header können nicht gefälscht werden, da der Light-Node-Vertrag eine strenge Überprüfung der Blöcke durchführen kann, genau wie ein Full Node, und gefälschte Block-Header die Überprüfung nicht bestehen.

Wenn bösartige Relayer zusammenarbeiten, um Böses zu tun, ist der einzig praktikable Weg, den Blockheader eines Blocks auf einer abgespaltenen Kette weiterzugeben, aber in einem gesunden Netzwerk wird eine abgespaltene Kette irgendwann nicht zur längsten Kette werden.

Nur wenn die Quellkette oder die Zielkette selbst reorganisiert wird, wird die Sicherheit des Light-Node-Vertrags beeinträchtigt;

• Vollständig dezentralisiert

Der Unterschied zwischen einem Relayer und einem Witness besteht darin, dass ein Relayer durch einen Vertrag kontrolliert wird und nicht zentralisiert ist.

Es stützt sich nicht auf privilegierte oder autorisierte Dritte zur Überprüfung der Legitimität;

• Niedrigere Betriebskosten, eine stärker dezentralisierte Zukunft

In einer Lightweight-Node-Sidechain muss der Relayer nicht wie ein Witness überbesichert sein und kann die Ausgabe von mehr kettenübergreifend verankerten Assets zu geringeren Kosten erreichen.

Light Nodes benötigen keine leistungsstarke Hardware oder die hohe Bandbreite, die für den Betrieb eines Full Nodes erforderlich ist; die Teilnahme kann einfach durch Ausleihen eines Mobiltelefons oder eines eingebetteten Geräts erfolgen, was der Dezentralisierung förderlicher ist.

• Eine einfache Methode, um schnell die Rechtmäßigkeit einer Transaktion im gesamten Hauptbuch zu überprüfen.

• Lichtknoten verifizieren Verträge, indem sie gegenseitig ihre Lichtknoten einbetten und somit über unabhängige Selbstverifizierungsfähigkeiten verfügen.

• Es zeichnet sich durch hohe Skalierbarkeit aus und ist derzeit die am weitesten verbreitete Cross-Chain-Lösung.

4.6 Nachteile von Relaisketten

• Es müssen unterschiedliche Anpassungskonzepte entwickelt werden, die auf den Eigenschaften verschiedener Zugriffsketten basieren, und es muss eine proaktive Kompatibilität implementiert werden, was einen erheblichen Arbeitsaufwand mit sich bringt.

• Unterschiedliche Blockchains weisen unterschiedliche Sicherheitsniveaus auf, was bei der Verbindung verschiedener Blockchains zu kettenübergreifenden Vertrauensproblemen führt, um die Sicherheit des gesamten kettenübergreifenden Netzwerks zu gewährleisten.

• Ständig entstehen neue Blockchains, und wenn eine neue Blockchain mit neuen Funktionen auftaucht, müssen neue Anpassungsmethoden entwickelt werden.

4.7 Blaupause für die Bildung einer Relaiskette – Vollständige Kette

• Die Full-Chain-Architektur ist die Zukunft der Multi-Chain-Architektur und bietet eine dauerhafte Lösung für kettenübergreifende Probleme.

• Die tatsächliche Vernetzung aller Blockchains erreichen

• Eine bestimmte Relay-Kette wird zur Schicht 0 in der Blockchain-Welt, und andere Ketten verbinden sich als Schicht 1, Schicht 2 usw.

• Die Relay-Kette ist nicht nur eine Brücke, sondern ein zentraler Knotenpunkt (Chain-Hub). Neben der Übertragung von Nachrichten zwischen verschiedenen Ketten muss der Chain-Hub auch Aspekte wie das Routing und die zeitliche Abstimmung von Nachrichten zwischen den Ketten bewältigen.

• Die nahtlose Interaktion zwischen dApps, Protokollen und Nutzern über verschiedene Hauptketten hinweg führt zu einem überlegenen Benutzererlebnis.

• Durch die Vernetzung aller Nutzer und Assets über verschiedene Blockchains hinweg sind Multi-Chain-Ledger nicht länger fragmentiert.

• Es ist die beste Wachstumslösung für dApps in einer Multi-Chain-Koexistenzumgebung und der Schlüssel zum Wachstum von Web3.

• In einer Zukunft, in der der Wettbewerb zwischen mehreren Blockchains zunimmt, könnte eine durchgängige Infrastruktur eine wichtigere Lösung für die Skalierung von Blockchains darstellen als L2.

4.8 Dominante Relaisketten Polkdot und Cosmos

• Die parallelen Slots von Polkadot und die Hubs von Cosmos sind typische Beispiele für „bidirektionale Verankerung“, die beide das Relais-Konzept verkörpern und auf Interkonnektivität abzielen.

• Das Cross-Chain-Messaging-Protokoll von Cosmos, Integer Block (IB), nutzt weiterhin Light-Node-Verträge in der empfangenden Blockchain, um Cross-Chain-Nachrichten zu verifizieren. Das Cross-Chain-Messaging-Protokoll von Polkadot, XCMP, verzichtet hingegen auf Light-Node-Technologie zur Überprüfung der Legitimität von Cross-Chain-Nachrichten und verwendet stattdessen einen gemeinsamen Validator.

• Polkadot Relay Chain und Cosmos Hub sind nicht Turing-vollständig und können daher keine Smart Contracts kompilieren. Polkadot entwickelte Substrate, Cosmos das Cosmos SDK. Cross-Chain-SDKs erfordern die Einbettung anderer Blockchains auf der Ebene der zugrundeliegenden Kette. Das bedeutet, dass bei Blockchains wie Ethereum, BNB, Klaytn, Polygon und Avax, deren Struktur aktiv modifiziert werden muss, um isomorph zu Polkadot Relay Chain und Cosmos Hub zu sein, Cross-Chain-Funktionalität nur durch die Einbettung des SDKs in die zugrundeliegende Kette erreicht werden kann. Die Modifizierung der zugrundeliegenden Struktur ist jedoch eine äußerst komplexe Herausforderung, weshalb derzeit keine etablierte L1-Blockchain Interoperabilität mit Polkadot Relay Chain und Cosmos Hub erreicht.

• Um eine Verbindung zur Polkadot-Relay-Chain herzustellen, muss das Recht zur Aufzeichnung von Transaktionen an die Relay-Chain übertragen werden, was auch bedeutet, die Sicherheit der Relay-Chain anzuvertrauen. Dies ist etwas, was andere etablierte L1-Ökosysteme nicht akzeptieren können.

• Für dApp-Entwickler erfordert die Nutzung von Polkadot und Cosmos zunächst den Aufbau einer eigenen dedizierten L1-Plattform und anschließend die Bereitstellung der dApp auf dieser Plattform. Der Aufbau einer eigenen L1-Plattform ist jedoch nicht die Kernvoraussetzung für dApps; vielmehr ist die Abdeckung einer größeren Anzahl von Nutzern und Assets entscheidend. Aus Sicht der Entwicklungskosten, des Lernaufwands und der Sicherheit ist der Aufbau einer L1-Plattform und die anschließende Suche nach Cross-Chain-Konnektivität mit anderen Blockchains für Nutzer-Assets kein lohnenswerter Entwicklungsweg.

• Polkadot und Cosmos nutzen zwar ressourcenschonende Cross-Chain-Mechanismen und sind hochsicher, scheinen aber eher ein umfangreiches internes Ökosystem aufzubauen, als echte Interoperabilität zu erreichen und das dApp-Ökosystem zu erweitern. Ihr Design und ihre technischen Mechanismen erschweren die Interoperabilität mit etablierten Blockchains wie Ethereum und BNB. Für dApps bieten sie zwar komfortable Tools zur Blockchain-Erstellung, erfüllen aber nicht deren Anforderungen an die Abdeckung von Nutzern und Assets.

• Eine Hauptkette, die eine Verbindung zu Polkadot oder Cosmos herstellen möchte, kann dies nur tun, indem sie aktiv für Kompatibilität sorgt.

• Es gibt nach wie vor keinerlei Anzeichen für eine Motivation oder Absicht beider Seiten, Kompatibilität herzustellen.

MAP-Protokoll-Projektanalyse

I. Projekteinführung

• Die MAP-Protokoll-Hauptkette, die Relay-Kette, ist eine Relay-Kette, die Light Nodes aus allen anderen Hauptketten enthält.

• Auf der Hauptkette wurden MAP-Protokoll-Light-Nodes installiert.

• Das MAP-Protokoll kompiliert proaktiv die Vertragsschicht auf der Hauptkette, der Relay Chain, mit den integrierten Signatur- und Hash-Algorithmen verschiedener L1-Caches vor.

• Verbindet sich vollständig mit gängigen EVMs und Nicht-EVMs wie Ethereum/Polygon/BNB Smart Chain/Klaytn/NEAR und stellt MAP Protocol Mainnet Relay Chain Light Nodes auf verschiedenen L1-Servern in Form von Smart Contracts bereit.

• Durch die Verbindung von Light Nodes mit der Hauptkette, auf der Relay Chain Light Nodes installiert sind, werden alle L1-Nodes zu isomorphen Ketten mit Relay Chain, wodurch gleichzeitig eine kettenübergreifende Gültigkeitsprüfung zwischen Light Nodes ermöglicht wird.

II. Projektstruktur

1. Protokollschicht – Kerngrundlage

• Es besteht aus der MAP Replay Chain, auf jeder Chain eingesetzten Light Nodes und dem Maintainer, einem Message-Passing-Programm zwischen den Chains.

• Die virtuelle Maschinenschicht der MAP Relay Chain integriert erfolgreich verschiedene L1-Signaturalgorithmen, Hash-Algorithmen und Merkle-Baum-Beweise durch vorkompilierte Verträge. Dadurch agiert die MAP Relay Chain wie eine Super-Sprachmaschine, die mehrere Sprachen fließend beherrscht und die Kommunikation zwischen verschiedenen Chains ermöglicht. Dies schafft eine homogene Grundlage für die Interoperabilität zwischen Chains.

• Light Nodes zeichnen sich durch unabhängige Selbstverifizierung und sofortige Finalitätsgarantien aus. Basierend auf der isomorphen Grundlage der MAP Relay Chain kann das Light-Node-Cross-Validierungsnetzwerk dieselbe Datensprache verwenden und lässt sich in Form von Smart Contracts problemlos auf jeder entsprechenden Layer-1-Kette bereitstellen, wodurch eine dezentrale, kettenübergreifende Gültigkeitsprüfung ermöglicht wird.

• Der Maintainer ist ein unabhängiges Inter-Chain-Messaging-Programm, das für die Aktualisierung des aktuellen Status der Light Nodes zuständig ist. Er schreibt die Informationen des Konsens-Layer-Blockheaders (Validator-Signatur) jeder Chain in den Smart Contract der Light Nodes der Ursprungs-Chain auf der Ziel-Chain in Form einer Transaktion. Dadurch wird sichergestellt, dass die Light Nodes der Ursprungs-Chain auf der Ziel-Chain über konsistente Validator-Informationen mit den Light Nodes der Ursprungs-Chain verfügen.

2. MOS Full-Chain-Service-Layer

• MAP Omnichain als Serviceschicht

• Ähnlich wie Google Mobile Services für das Android-Ökosystem bietet es Entwicklern von dezentralen Anwendungen (dApps) umfassende Entwicklungsdienstleistungen.

• Diese Schicht enthält kettenübergreifende Smart Contracts zur Sperrung von Vermögenswerten sowie Komponenten für die kettenübergreifende Nachrichtenübermittlung (Messenger), die auf verschiedenen Blockchains bereitgestellt werden. Entwickler können diese Schicht direkt nutzen, um vollständige Anwendungsszenarien für die gesamte Blockchain zu erstellen oder sie ihren Bedürfnissen entsprechend weiter zu kompilieren. Dadurch sparen sie die Entwicklungs- und Lernkosten für die gesamte Blockchain.

• Die Smart Contracts in dieser Schicht sind allesamt Open-Source-Komponenten, die von CertiK geprüft wurden und von dApp-Entwicklern direkt verwendet werden können, ohne sich Gedanken über Sicherheit oder Entwicklungskosten machen zu müssen.

3. Vollständige Anwendungsschicht

• Omnichain-Anwendungsschicht

• Dezentrale Derivate und synthetische Assets lassen sich am Beispiel dieser Beispiele verdeutlichen: Beide sind derzeit durch die Preise und Mengen anderer On-Chain-Assets eingeschränkt. Sie können über Off-Chain-Orakel keine genauen und zeitnahen Asset-Daten abrufen, was zu geringer Liquidität und einer schlechten Nutzererfahrung führt.

• Eine Multi-Chain-Bereitstellung kann dieses Problem zwar lösen, der Prozess ist jedoch zeitaufwändig und arbeitsintensiv und führt zu unnötigen Entwicklungskosten.

• Sobald dezentrale Derivate und synthetische Assets auf der MAP Replay Chain eingesetzt werden, können sie präzise Multi-Chain-Daten vom On-Chain-Orakel des MAP-Protokolls beziehen und sind nicht länger durch Datenflussbarrieren eingeschränkt, wodurch auf einfache Weise eine vollständige Asset-Liquidität erreicht wird.

• Ähnliche Anwendungsszenarien umfassen Full-Chain-DID, Full-Chain-Kreditvergabe, Full-Chain-Swap, Full-Chain-GameFi, Full-Chain-DAO-Governance, Full-Chain-Token und Full-Chain-NFTs. Unabhängig davon, auf welcher L1-Schicht der Hauptvertrag der dApp implementiert ist, können Entwickler mithilfe des MAP-Protokolls problemlos Full-Chain-Anwendungen erstellen, die alle Nutzer und Assets der Blockchain abdecken.

4. Anwendung der zk-Technologie

• Signaturprüfungen: Merkle-Proof-Prüfungen für eine bestimmte Merkle-Root sowie Hash-Chaining- und Cumulative-Work-Prüfungen eignen sich alle für die Authentifizierung über zkSNARK.

• Im Hinblick auf den Aufbau von leichtgewichtigen Knoten vereinfacht es die Speicherung großer Mengen an Validatorgruppeninformationen oder Blockheadern.

• Ein Commitment bezieht sich auf die Menge der Validatoren (PoS) oder die neueste Menge der Blockköpfe (PoW) und wird jedes Mal aktualisiert, wenn sich die Menge ändert.

• zkSNARK wird verwendet, um zu beweisen, dass die Änderung vom alten Commitment zum neuen Commitment eine gültige Änderung im Validator-Set oder Block-Head-Set widerspiegelt.

• Die von zkSNARK auferlegten Beschränkungen umfassen in erster Linie die Prüfung, ob eine ausreichende Anzahl bestehender Validatoren das neue Set genehmigt hat und ob die Stimmgewichte einen bestimmten Schwellenwert überschritten haben.

III. Anwendungsbeispiele der gesamten Wertschöpfungskette

1. Cross-Chain-Kreditvergabe

• Aktuell muss ein Nutzer, der Guthaben auf Chain A besitzt, aber auf Chain B minen möchte, neun Schritte durchlaufen.

Staking auf Chain A -> Ausleihen -> Cross-Chain-Brücke (Gebühren) -> Tauschen (Gebühren) -> Mining auf der Ziel-Chain -> Zurücktauschen (Gebühren) -> Cross-Chain-Rückgabe (Gebühren) -> Rückzahlung des Darlehens -> Unstaking;

• Mit dem MAP-Protokoll können Sie auf Chain A staken, leihen, minen, zurückzahlen und Ihren Staking-Betrag auf der Ziel-Chain freigeben, wodurch die Gebühren von vier Cross-Chain-Bridges und Swaps entfallen.

2. Vollständiger Kettentausch

• Full-Chain Swap ermöglicht den Tokentausch zu deutlich niedrigeren Gebühren als bei herkömmlichen DeFi-Börsen durch die Anbindung an die besten Cross-Chain-DeFi-Protokolle.

• Mithilfe des MAP-Protokolls können Entwickler eine wirklich dezentrale, vollständige Blockchain-Börse aufbauen, die es Benutzern ermöglicht, beliebige Token auf jeder Blockchain zu tauschen.

• Durch die Anbindung an die Liquidität gängiger DEXs kann auch ein aggregierter Austausch über die gesamte Blockchain hinweg erreicht werden.

• Bestehende Asset-Management-Modelle (AMMs) können so angepasst werden, dass sie vollständige Blockchain-Swaps von einem Asset zum anderen durchführen können, ohne dass dafür bestehender Code verändert werden muss.

• Nutzer können ETH auf Ethereum gegen NEAR tauschen, wofür nur eine einzige Transaktion auf der Quellkette erforderlich ist.

• Bei einer Full-Chain-Börse, die mit dem MAP-Protokoll aufgebaut ist, können Benutzer die Liquidität für Token mehrerer Ketten in einem einzigen Pool erhöhen, wodurch es möglich wird, einem Tokenpaar aus verschiedenen Ketten Liquidität bereitzustellen.

• Nutzer können einen Token direkt gegen einen anderen Token auf einer anderen Blockchain tauschen, ohne Zwischentoken wie Stablecoins zu verwenden. Dadurch wird der kürzeste Weg für vollständige Blockchain-Swaps erreicht.

• Butter Swap ist das erste wirklich dezentrale Cross-Chain-Netzwerk, das es Nutzern ermöglicht, beliebige Token auf beliebigen Blockchains zu tauschen. Es befindet sich derzeit in der Testphase und wird in Kürze veröffentlicht.

3. GameFi-Links

• Durch das MAP-Protokoll kann das GameFi-Projekt seine Token auf mehreren Blockchains bereitstellen, wodurch Benutzer anderer Blockchains ihre Vermögenswerte effizient und sicher auf die Blockchain ihres Projekts übertragen können.

• Ein Beispiel: Ein GameFi-Projekt der BNB Chain stellt seine Token auf den Polygon- und WAX-Chains bereit. Nutzer von Polygon und BSC können ihre Assets über eine Cross-Chain-Bridge zu WAX transferieren und an GameFi teilnehmen, wodurch sich die Nutzerbasis vervielfacht.

• Eine weitere Möglichkeit, Skalierbarkeit und ein optimales Spielerlebnis zu gewährleisten, ist die direkte Bereitstellung auf der MAPO Relay Chain. Dank der Interoperabilität der MAPO Relay Chain können GameFi-Projekte durch die Bereitstellung auf dieser Chain automatisch und sicher eine Verbindung zu allen EVM- und Nicht-EVM-Chains herstellen. Die MAPO Relay Chain verbindet sich proaktiv mit allen zukünftigen Chains, sodass sich GameFi-Projekte auf das Nutzererlebnis konzentrieren können, ohne sich Gedanken über Skalierbarkeit und Sicherheit machen zu müssen.

4. On-Chain-Daten: On-Chain-Orakel und Derivate

• Das MAPP-Protokoll ermöglicht den kettenübergreifenden Datentransfer und fördert einen neuen Oracle-Markt – On-Chain-Orakel.

• Durch den Einsatz auf der MAPO-Relay-Chain können Derivate- und Synthetik-Asset-Anwendungen auf einfache Weise zuverlässige Multi-Chain-Daten von On-Chain-Orakeln beziehen.

5. Governance der gesamten Wertschöpfungskette

• Nehmen wir Aave als Beispiel

• Wie die Entwickler erklärten, wird ein im Ethereum-Netzwerk (ETH) ausgeführter Vorschlag an Polygon FxPortal gesendet. Dieser Mechanismus liest die Ethereum-Daten und leitet sie zur Verifizierung an das Polygon-Netzwerk weiter. Anschließend empfängt der Aave-Cross-Chain-Governance-Bridge-Smart-Contract diese Daten, dekodiert sie und reiht die Aktion in die Warteschlange ein, bis ein Zeitlimit erreicht ist. Die Aave-Cross-Chain-Governance-Bridge ist universell aufgebaut und lässt sich problemlos an jede Blockchain anpassen, die EVM und Cross-Chain-Messaging unterstützt.

• Dieses Repository unterstützt aktuell die Vertragsanbindung an Polygon und Arbitrum. Auf Aave können Nutzer Aave Improvement Protocols (AIPs) für verschiedene Funktionen der DeFi-Plattform einreichen. Dank der Interoperabilität des MAP-Protokolls mit allen Blockchains lässt sich die vollständige Verwaltung aller EVMs und heterogenen Blockchains über eine sichere Cross-Chain-Infrastruktur realisieren.

6. Flipped Tokens und NFT-Brücken

• Cross-Chain-Bridges und Cross-Chain-NFT-Bridges benötigen keine eigene Infrastruktur mehr und müssen keine MPCs mehr verwenden.

• Durch die Nutzung des zugrunde liegenden Cross-Chain-Verifizierungsnetzwerks von MAPO mit sofortiger Finalität und des MOS Application Developer Service Packs können Cross-Chain-Bridge-Entwickler auf einfache Weise ihre NFT- oder Fungible-Token-Bridge-Anwendungen erstellen.

IV. Projektvorteile

1. Vollständige Kettenverbindung und kettenübergreifende Funktionalität im gesamten Netzwerk

• Im Gegensatz zu Cosmos, Polkadot und Aurora ist die MAP Relay Chain isomorph zu allen Blockchains und verbindet alle Layer 1 (L1)-Ebenen, anstatt nur isomorphe Blockchains innerhalb ihres Ökosystems. Sie ist die einzige Full-Chain-Infrastruktur auf dem Markt, die alle Blockchains abdeckt und höchste Sicherheit bietet.

• Die Relay-Chain integriert alle fragmentierten öffentlichen Blockchain-Ledger in ein einziges verteiltes Ledger.

• NEARs Rainbow Bridge, Polkadot, Cosmos IBC und das Full-Chain-MAP-Protokoll nutzen alle den Satoshi-Nakamoto-Konsens und eine mathematisch bewiesene, unabhängige und selbstverifizierende Cross-Chain-Technologie mit Light-Clients. Polkadot, Cosmos IBC und NEARs Rainbow Bridge können jedoch nicht alle Blockchains abdecken; sie sind auf ihre jeweiligen Ökosysteme beschränkt. Beispielsweise unterstützen Polkadot und Cosmos IBC keine Cross-Chain-Kommunikation mit heterogenen Blockchains wie Ethereum, BNB Chain und Polygon. Aktuell kann Rainbow Bridge nur mit Aurora (NEARs EVM) kommunizieren.

2. Vollständig dezentralisiert, ohne Privilegien und zu 100% auf dem Konsensmechanismus von Satoshi Nakamoto basierend.

• Der Light Node, der Maintainer und der Messenger verifizieren sich gegenseitig und gewährleisten so die Authentizität und Sicherheit der kettenübergreifenden Verifizierung in jeder Hinsicht. Dieser Mechanismus schließt böswilliges Verhalten seitens Messenger und Maintainer aus. Er nutzt eine vollständig auf dem Satoshi-Nakamoto-Konsens basierende, kettenübergreifende Verifizierungstechnologie auf Blockchain-Ebene. Der gesamte Verifizierungsprozess ist unabhängig von externen Datenverifizierungen und privilegierten Dritten und stellt somit einen vollständig nachweisbaren, dezentralen Mechanismus für kettenübergreifende Verifizierung dar.

• LayerZero beinhaltet Light Nodes, diese dienen jedoch nur der Verifizierung innerhalb derselben Kette, nicht der kettenübergreifenden Verifizierung, und stellen zudem mehrdeutige privilegierte Rollen (Orakel) dar.

3. Gemeinsame Sicherheit der Hauptkette

• MAP Replay Chain nutzt ein Relay-Schema mit bidirektionaler Verankerung von Light Nodes. Die Verifizierungsverfahren für Light Nodes sind identisch mit denen des Quellnetzwerks. Dieser vollständig duale Mainnet-Verifizierungsmechanismus ist kryptografisch garantiert, sodass nur bösartige Forks die Sicherheit der Light-Node-Verträge beeinträchtigen können. Er ist derzeit die sicherste Cross-Chain-Lösung.

4. Kompatibel mit EVM- und Nicht-EVM-Ketten

• Die Relay-Chain erstellt Signatur- und Hash-Algorithmen für verschiedene öffentliche Blockchains vor und ermöglicht so nicht nur die Erweiterung auf mehrere Blockchains, sondern auch die Verknüpfung von EVM-Chains mit Nicht-EVM-Chains. Dies unterstützt die kettenübergreifende Kommunikation und einen sicheren, nahtlosen Asset-Transfer.

5. Sehr entwicklerfreundlich

• Kompatibel mit nahezu allen Blockchains und unterstützt die native Bereitstellung von DApps auf der Relay-Chain.

• Ein auf Light Nodes basierendes Cross-Chain Light Client SDK ermöglicht es verschiedenen Blockchains, sich direkt auf der zugrundeliegenden Ebene zu verbinden.

• Die Bereitstellung eines selbstentwickelten SDKs reduziert die Komplexität für Entwickler, die dApps erstellen.

• Das einzigartige, auf Zero-Knowledge-Beweisen basierende, leichtgewichtige Client-Design reduziert den Entwicklungsaufwand für heterogene Blockchains und gewährleistet gleichzeitig die Sicherheit der kettenübergreifenden Nachrichtenübertragung.

6. Niedrigere Betriebskosten, stärker dezentralisierte Zukunft

• Bei Lightweight Node Sidechains benötigen Relayer keine übermäßige Besicherung wie Zeugen, was die Ausgabe von mehr kettenübergreifend verankerten Vermögenswerten zu geringeren Kosten ermöglicht.

• Optimieren Sie die Kosten der Datenverifizierung und reduzieren Sie die Gasgebühren durch die Verwendung einer kettenübergreifenden Verifizierungsmethode auf Basis von Zero-Knowledge-Proofs (ZK) und Light Clients.

V. Team

• MAP Protocol wurde 2019 gegründet.

• Es handelt sich um ein Team, das vollständig von einer Kultur technikbegeisterter Ingenieure und Forscher geprägt ist.

VI. Soziale Interaktion und Förderung

• Twitter 106.000 Personen

• Die Tweets sind hochgradig interaktiv.

• Der Gründer beteiligt sich aktiv an verschiedenen Aktivitäten.

• Aktiv mit anderen Projektbeteiligten zusammenarbeiten

VII. Token-Ökonomiemodell

Das Gesamtangebot beträgt 10 Milliarden

• 15 % für Teamprämien

• 21 % gehören zum Ecosystem DAO.

• 12 % gehören der MAP Protocol Foundation.

• 22 % befinden sich im Besitz von Investoren und frühen Unterstützern.

• 30 % sind für Mining-Belohnungen vorgesehen.

VIII. Marktkapitalisierung

• Marktkapitalisierung: 22.342.490 US-Dollar

• Verteilungsmenge: 2.228.621.190

• Zirkulationsrate: 22,3 %

• Gesamtmarktkapitalisierung: 101.348.762 USD

IX. Bargeldbestände

10. Status der Codeentwicklung

• Der Code wird seit 2021 entwickelt und seitdem kontinuierlich und regelmäßig aktualisiert.

• Am Codieren waren 10 Personen beteiligt.

• Versionsaktualisierungs-Iteration 8 Mal

XI. Expertenbewertung

1. Bohao Tang, leitender Entwickler von Flow

• Das MAP-Protokoll unterstützt Flow beim Aufbau der Infrastruktur für ein nahtloses Anwendungserlebnis. Es bietet rollenbasierte Verifizierung ohne Berechtigungsanforderungen über verschiedene Blockchains hinweg und deckt alle EVM- und Nicht-EVM-Chains ab. Wir sind überzeugt, dass es dem Flow-Ökosystem vielfältigere und umfassendere Möglichkeiten eröffnet.

2. Professor Liu Yang, Direktor des Labors für Cybersicherheit an der Technischen Universität Nanyang

• Die vollständige Interoperabilität des MAP-Protokolls ist sicherer und kompatibler als andere Cross-Chain-Lösungen und eignet sich zudem besser für dezentrale Anwendungen (dApps). Das ausgereifte, innovative und stabile Design der Cross-Chain-Lösung des MAP-Protokolls ermöglicht eine sichere und nahtlose Kommunikation und den Transfer von Vermögenswerten zwischen EVM- und Nicht-EMV-Chains. Im Vergleich zu zentralisierten Cross-Chain-Lösungen ohne Relay-Chain, wie Axelar und Celer, erleichtert die Relay-Chain des MAP-Protokolls nicht nur die Erweiterung von Multi-Chain-Architekturen, sondern minimiert auch das Risiko von böswilligen Aktionen durch Superadministratoren, die die Inter-Chain-Kommunikation kontrollieren.

• Im Vergleich zu dezentralen Lösungen wie Polkadot und Cosmos, die Relay-Chains nutzen, verwendet das MAP-Protokoll als einziges ein Zero-Knowledge-Beweisverfahren. Dabei werden schlanke Clients in Form von Smart Contracts eingesetzt, um Nachrichten zwischen den Blockchains zu verifizieren. Diese ressourcenschonende Implementierung macht die Einbettung eines SDKs und die strukturelle Kompatibilität zwischen heterogenen Blockchains überflüssig und gewährleistet gleichzeitig die Sicherheit und Vertraulichkeit der Nachrichtenübertragung. Dadurch ist MAP mit nahezu allen Blockchains kompatibel und interoperabel.

• Das Wichtigste ist, dass das innovative Cross-Chain-Design des MAP-Protokolls die Entwicklung und native Bereitstellung von dApps direkt auf der Relay-Chain ermöglicht. Durch die Verbindung von Assets über verschiedene Blockchains hinweg wird die MAP Relay Chain zu einer Schlüsselkomponente für die kettenübergreifende Interaktion von Assets und Daten und hat das Potenzial, sich als die Zukunft kettenübergreifender Lösungen zu etablieren.

XII. Schlussfolgerung

• Eine überlegene Lösung für die kettenübergreifende Verbindung (gemeinsame Sicherheit der Hauptkette, Dezentralisierung)

• Die Cross-Chain-Technologie im gesamten Netzwerk und die Vernetzung aller Ketten bieten weitreichende Perspektiven.

• Die jahrelange engagierte Arbeit und die gesammelten Erfahrungen des Teams

• Das Projekt ist von hoher Qualität, aber die Bewertung ist zu niedrig.

Referenzen:

https://files.mapprotocol.io/pdf/mapprotocol_Litebook_cn.pdf

https://www.panewslab.com/zh/articledetails/D62579631.html

https://foresightnews.pro/article/h5Detail/19308 https://view.inews.qq.com/k/20230206A02IC400?web_channel=wap&openApp=false