Entschlüsselung der Technologie von Merlin: Wie sie funktioniert

Seit dem „Sommer der Inschriften“ im Jahr 2023 stehen die Layer2-Technologien von Bitcoin an vorderster Front der Web3-Revolution. Trotz des späteren Einstiegs in das Feld im Vergleich zu den Layer2-Lösungen von Ethereum hat Bitcoin den einzigartigen Reiz von POW und den reibungslosen Start von Spot-ETFs genutzt, die frei von „Verbriefungs“-Risiken sind, um innerhalb von nur sechs Monaten Milliarden von Dollar in diesen aufstrebenden Sektor zu ziehen. Unter diesen sticht Merlin als die bedeutendste und meistverfolgte Entität in der Bitcoin Layer2-Landschaft hervor und verwaltet Milliarden an Gesamtwert gesperrt (TVL). Dank klarer Staking-Anreize und beeindruckender Renditen hat sich Merlin schnell in den Vordergrund geschoben und übertraf sogar das bekannte Blast-Ökosystem innerhalb weniger Monate. Mit dem wachsenden Trubel um Merlin hat die Erkundung seiner technischen Infrastruktur ein immer größer werdendes Publikum fasziniert. In diesem Artikel konzentriert sich Geek Web3 darauf, die technischen Strategien hinter Merlin Chain zu entschlüsseln. Durch die Aufschlüsselung der öffentlich verfügbaren Dokumente und der Überlegungen hinter seinem Protokolldesign zielen wir darauf ab, die operativen Prozesse von Merlin zu entschlüsseln und das Verständnis seines Sicherheitsrahmens zu verbessern, um einen klareren Einblick in die Funktionsweise dieser führenden Bitcoin Layer2-Lösung zu geben.

Merlins Dezentrales Orakelnetzwerk: Ein offenes Off-Chain-DAC-Komitee

Für jede Layer2-Technologie bleibt die Bewältigung der Datenverfügbarkeit (DA) und der Kosten für die Datenveröffentlichung eine entscheidende Herausforderung, unabhängig davon, ob es sich um Ethereum Layer2 oder Bitcoin Layer2 handelt. Angesichts der inhärenten Einschränkungen des Bitcoin-Netzwerks, das mit einem großen Datendurchsatz zu kämpfen hat, ist es eine bedeutende Herausforderung für die Kreativität der Layer2-Entwickler, die effiziente Nutzung des wertvollen DA-Raums zu planen.

Es ist offensichtlich, dass Layer2-Projekte, wenn sie Rohtransaktionsdaten direkt auf die Bitcoin-Blockchain veröffentlichen würden, weder hohe Durchsatzraten noch niedrige Gebühren erreichen könnten. Die vorherrschenden Lösungen umfassen eine hochgradige Komprimierung der Daten, um ihre Größe signifikant zu reduzieren, bevor sie auf die Bitcoin-Blockchain hochgeladen werden, oder die Entscheidung, die Daten off-chain zu veröffentlichen.

Unter denjenigen, die die erste Strategie anwenden, sticht Citrea heraus. Ihr Ziel ist es, Änderungen in den Layer2-Staaten in bestimmten Intervallen hochzuladen, was die Aufzeichnung der Ergebnisse von Zustandsänderungen über mehrere Konten hinweg sowie der entsprechenden Zero-Knowledge Proofs (ZKPs) auf die Bitcoin-Blockchain beinhaltet. Unter dieser Vereinbarung kann jeder die Zustandsunterschiede und ZKPs vom Bitcoin-Hauptnetz aus abrufen, um Citreas Zustandsänderungen nachzuverfolgen. Dieser Ansatz reduziert effektiv die Größe der auf die Blockchain hochgeladenen Daten um über 90 %.

Obwohl dies die Datengröße erheblich komprimieren kann, ist der Engpass immer noch offensichtlich. Wenn in kurzer Zeit eine große Anzahl von Konten ihren Status ändert, muss Layer 2 alle Änderungen in diesen Konten zusammenfassen und auf die Bitcoin-Kette hochladen. Die endgültigen Datenveröffentlichungskosten können nicht sehr niedrig gehalten werden. Dies trifft auf viele Ethereums zu. Dies ist bei ZK Rollup zu sehen.

Viele Bitcoin Layer 2 gehen einfach den zweiten Weg: Sie nutzen direkt die DA-Lösung unter der Bitcoin-Kette, entweder bauen sie eine DA-Ebene selbst auf oder nutzen Celestia, EigenDA usw. B^Square, BitLayer und der Protagonist dieses Artikels, Merlin, nutzen alle diese Off-Chain-DA-Erweiterungslösung.

Vorheriger Artikel in Geek Web3——"Analyse des B^2 New Version Technology Roadmap: Die Notwendigkeit der DA und Verifizierungsebene unter der Bitcoin-Kette"haben wir erwähnt, dass B^2 Celestia direkt imitiert und ein DA-Netzwerk aufgebaut hat, das die Datenabtastfunktion unter der Kette unterstützt, genannt B^2 Hub. "DA-Daten" wie Transaktionsdaten oder Status-Diff werden unter der Bitcoin-Kette gespeichert, und nur der Datahash / Merkle-Root wird in das Bitcoin-Mainnet hochgeladen.

Dies behandelt im Wesentlichen Bitcoin als ein vertrauenswürdiges schwarzes Brett: Jeder kann den Datahash aus der Bitcoin-Kette lesen. Nachdem Sie die DA-Daten vom Off-Chain-Datenanbieter erhalten haben, können Sie überprüfen, ob sie dem On-Chain-Datahash entsprechen, d. h. Hash(data1) == Datahash1? Wenn es eine Übereinstimmung zwischen den beiden gibt, bedeutet dies, dass die Daten, die Ihnen vom Off-Chain-Datenanbieter gegeben wurden, korrekt sind.

DA Layer in Bitcoins Layer2 erklärt:

(Bildquelle: Geek web3)

Dieses System stellt sicher, dass Daten von Off-Chain-Knoten mit spezifischen „Hinweisen“ oder Beweisen auf Layer1 korrelieren, um sich gegen das potenzielle Problem zu schützen, dass die DA-Schicht falsche Informationen liefert. Es entsteht jedoch eine erhebliche Sorge, wenn der Ursprung der Daten – der Sequenzer – versäumt, die tatsächlichen Daten in Bezug auf einen Datenhash zu verteilen. Angenommen, der Sequenzer überträgt nur den Datenhash an die Bitcoin-Blockchain, während er die entsprechenden Daten vorsätzlich nicht öffentlich zugänglich macht. Was passiert dann?

Betrachten Sie Szenarien, in denen nur der ZK-Proof und der StateRoot öffentlich gemacht werden, aber die begleitenden DA-Daten (wie Zustandsunterschiede oder Transaktionsdaten) nicht veröffentlicht werden. Obwohl es möglich ist, den ZK-Proof zu validieren und sicherzustellen, dass der Übergang vom Vorherigen_Stateroot zum Neuen_Stateroot korrekt ist, bleibt unbekannt, welche Kontenstände sich geändert haben. Unter diesen Umständen, obwohl die Vermögenswerte der Benutzer sicher bleiben, bleibt der tatsächliche Zustand des Netzwerks unklar. Niemand weiß, welche Transaktionen in die Blockchain eingeflossen sind oder welche Vertragszustände aktualisiert wurden, was Layer2 effektiv inoperative macht, fast so, als wäre es offline gegangen.

Diese Praxis wird als "Daten zurückhalten" bezeichnet. Im August 2023 initiierte Dankrad von der Ethereum Foundation eine Diskussion auf Twitter über ein Konzept, das als "DAC" bekannt ist.

In vielen Ethereum Layer2-Setups, die Off-Chain-Datenverfügbarkeitslösungen (DA) nutzen, gibt es oft einige Knoten mit besonderen Privilegien, die ein Gremium bilden, das als Datenverfügbarkeitskomitee (DAC) bekannt ist. Dieses Gremium dient als Garant und stellt sicher, dass der Sequenzer tatsächlich vollständige DA-Daten (Transaktionsdaten oder Zustandsunterschiede) off-chain veröffentlicht hat. Die DAC-Mitglieder erstellen dann eine gemeinsame Multisignatur. Wenn diese Multisignatur den erforderlichen Schwellenwert erreicht (zum Beispiel 2 von 4), sind die entsprechenden Verträge auf Layer1 so konzipiert, dass davon ausgegangen wird, dass der Sequenzer die Verifizierungsstandards des DAC erfüllt hat und die vollständigen DA-Daten tatsächlich off-chain veröffentlicht hat.

Die Ethereum Layer2 DAC-Komitees halten sich überwiegend an das Proof of Authority (POA)-Modell, das die Mitgliedschaft auf eine ausgewählte Gruppe von Knoten beschränkt, die KYC bestanden haben oder offiziell festgelegt wurden. Dieser Ansatz hat den DAC effektiv als ein Zeichen für „Zentralisierung“ und „Konsortial-Blockchain“ gebrandmarkt. Darüber hinaus verteilt in bestimmten Ethereum Layer2, die den DAC-Ansatz nutzen, der Sequenzer DA-Daten ausschließlich an DAC-Mitgliedsknoten, mit minimaler externer Verbreitung. Folglich muss jeder, der DA-Daten sucht, die Genehmigung des DAC einholen, ähnlich wie bei der Arbeit innerhalb einer Konsortial-Blockchain.

Es ist klar, dass DACs dezentralisiert sein müssen. Obwohl Layer2 möglicherweise nicht erforderlich ist, um DA-Daten direkt auf Layer1 hochzuladen, sollte der Mitgliederzugang des DAC öffentlich zugänglich sein, um Kollusion und Fehlverhalten einiger Individuen zu vermeiden. (Für weitere Informationen zu diesem Thema siehe Dankrads frühere Diskussionen auf Twitter.)

Celestias Vorschlag von BlobStream zielt grundsätzlich darauf ab, eine zentralisierte DAC durch Celestia zu ersetzen. Unter diesem Modell würde ein Ethereum L2-Sequenzer DA-Daten an die Celestia-Blockchain senden. Wenn zwei Drittel der Knoten von Celestia diese Daten validieren, würde der spezialisierte Layer2-Vertrag auf Ethereum validieren, dass der Sequenzer die DA-Daten korrekt veröffentlicht hat, wodurch die Celestia-Knoten als Garanten positioniert werden. Angesichts der Tatsache, dass Celestia mit Hunderten von Validatorknoten arbeitet, wird diese größere DAC-Konfiguration als relativ dezentral betrachtet.

Die von Merlin übernommene DA-Lösung ist tatsächlich relativ nah an Celestias BlobStream, die beide den Zugang zu DAC über POS öffnen und es so mehr dezentralisieren. Jeder kann einen DAC-Knoten betreiben, solange er genügend Vermögenswerte einsetzt. In der Dokumentation von Merlin wird der oben genannte DAC-Knoten als Oracle bezeichnet, und es wird darauf hingewiesen, dass er die Vermögenswerte von BTC, MERL und sogar BRC-20-Token unterstützen wird, um einen flexiblen Pflegemechanismus umzusetzen und auch Proxy-Pflege ähnlich wie Lido zu unterstützen. (Die POS-Pflegevereinbarung der Oracle-Maschine ist im Grunde genommen eine der nächsten Kerngeschichten von Merlin, und die bereitgestellten Pflegezinsen sind relativ hoch)

Hier beschreiben wir kurz den Arbeitsablauf von Merlin (siehe Bild unten):

1. Nachdem der Sequenzer eine große Anzahl von Transaktionsanfragen erhalten hat, aggregiert er sie und generiert einen Datenbatch (Datenbatch), der an den Prover-Knoten und den Oracle-Knoten (dezentralisierter DAC) übergeben wird.

2. Merlins Prover-Knoten ist dezentralisiert und verwendet lumozs Prover as a Service-Dienst. Nachdem mehrere Datenchargen empfangen wurden, wird der Prover-Mining-Pool entsprechende Zero-Knowledge-Beweise generieren. Anschließend werden die ZKP zur Überprüfung an den Oracle-Knoten gesendet.

3. Der Oracle-Knoten wird überprüfen, ob der von Lmuozs ZK-Mining-Pool gesendete ZK-Beweis mit den vom Sequenzer gesendeten Datenbatches übereinstimmt. Wenn die beiden übereinstimmen und keine anderen Fehler enthalten, wird die Überprüfung bestanden. Während dieses Prozesses werden dezentrale Oracle-Knoten durch Schwellwertschreiben Mehrfachsignaturen generieren und nach außen hin erklären, dass der Sequenzer die DA-Daten vollständig gesendet hat und der entsprechende ZKP gültig ist und die Überprüfung der Oracle-Knoten bestanden hat.

4. Der Sequenzer sammelt Multi-Signatur-Ergebnisse von Oracle-Knoten. Wenn die Anzahl der Signaturen die Schwellenanforderungen erfüllt, werden die Signaturinformationen zusammen mit dem Datahash der DA-Daten (Datenpaket) an die Bitcoin-Chain gesendet und der Außenwelt zur Lektüre und Bestätigung übergeben.

(Merlin-Arbeitsprinzip-Diagrammquelle: Geek web3)

1. Oracle-Knoten führen eine spezielle Verarbeitung des Berechnungsprozesses zur Überprüfung des ZK-Beweises durch, erzeugen Commitment-Verpflichtungen und senden sie an die Bitcoin-Kette, damit jeder die 'Verpflichtung' herausfordern kann. Der Prozess hier ist im Wesentlichen derselbe wie das Betrugsnachweisprotokoll von bitVM. Wenn die Herausforderung erfolgreich ist, wird der Oracle-Knoten, der das Commitment ausgestellt hat, finanziell bestraft. Natürlich umfasst die Daten, die Oracle auf die Bitcoin-Kette veröffentlichen möchte, auch den Hash des aktuellen Layer-2-Status - StateRoot sowie den ZKP selbst, der zur externen Erkennung auf die Bitcoin-Kette veröffentlicht werden muss.

Verweise:Eine minimalistische Interpretation von BitVM: Wie man Betrugsnachweise auf der BTC-Kette überprüft

Es gibt mehrere Details, die hier näher erläutert werden müssen. Zunächst wird im Merlin-Roadmap erwähnt, dass Oracle in Zukunft die DA-Daten zur Celestia sichern wird. Auf diese Weise können Oracle-Knoten lokale historische Daten ordnungsgemäß beseitigen, ohne dass die Daten lokal bestehen bleiben müssen. Gleichzeitig ist das von Oracle Network generierte Commitment tatsächlich die Wurzel eines Merkle-Baums. Es reicht nicht aus, die Wurzel nach außen hin offenzulegen. Das vollständige Datenset, das dem Commitment entspricht, muss öffentlich zugänglich gemacht werden. Dies erfordert die Suche nach einer Drittanbieter-DA-Plattform. Diese Plattform kann Celestia oder EigenDA sein oder andere DA-Schichten.

Verweise:„Analyse des B^2 New Version Technology Roadmap: Die Notwendigkeit der DA und Verifikationsschicht unter der Bitcoin-Kette“

Sicherheitsmodellanalyse: Optimistisches ZKRollup + Cobos MPC-Dienst

Oben haben wir den Workflow von Merlin kurz beschrieben, und ich glaube, Sie haben bereits die grundlegende Struktur gemeistert. Es ist nicht schwer zu erkennen, dass Merlin, B^Square, BitLayer und Citrea im Grunde dem gleichen Sicherheitsmodell - optimistischen ZK-Rollup - folgen.

Beim ersten Lesen dieses Wortes fühlen sich viele Ethereum-Enthusiasten möglicherweise seltsam. Was ist „optimistischer ZK-Rollup“? In der Auffassung der Ethereum-Community basiert das „theoretische Modell“ von ZK Rollup vollständig auf der Zuverlässigkeit kryptographischer Berechnungen und erfordert nicht die Einführung von Vertrauensannahmen. Das Wort „optimistisch“ führt genau die Vertrauensannahme ein, was bedeutet, dass die meisten Menschen optimistisch sind, dass Rollup keine Fehler aufweist und zuverlässig ist. Wenn ein Fehler auftritt, kann der Rollup-Betreiber durch den Betrugsnachweis bestraft werden. Dies ist der Ursprung des Namens Optimistic Rollup, auch bekannt als OP Rollup.

Für das Ethereum-Ökosystem an der Basis von Rollup mag der optimistische ZK-Rollup etwas unscheinbar sein, aber er passt genau zur aktuellen Situation von Bitcoin Layer 2. Aufgrund technischer Einschränkungen kann die Bitcoin-Chain den ZK-Beweis nicht vollständig verifizieren. Sie kann nur einen bestimmten Schritt des Berechnungsprozesses von ZKP unter speziellen Umständen überprüfen. Unter dieser Voraussetzung kann die Bitcoin-Chain tatsächlich nur das Betrugsnachweisprotokoll unterstützen. Es kann darauf hingewiesen werden, dass es einen Fehler in einem bestimmten Berechnungsschritt von ZKP während des Off-Chain-Verifizierungsprozesses gibt und durch Betrugsnachweis herausgefordert werden kann. Natürlich kann dies nicht mit dem Ethereum-Stil ZK Rollup verglichen werden, aber es ist bereits das Beste, was Bitcoin Layer 2 derzeit erreichen kann. Zuverlässiges und sicherstes Sicherheitsmodell.

Unter dem obigen optimistischen ZK-Rollup-Schema annehmen, dass es N Personen im Layer 2-Netzwerk gibt, die die Befugnis haben, Herausforderungen zu initiieren. Solange einer der N Herausforderer ehrlich und zuverlässig ist und Fehler erkennen und jederzeit einen Betrugsnachweis einleiten kann, ist der Layer 2-Zustandsübergang sicher. Natürlich muss das optimistische Rollup mit einem relativ hohen Abschlussgrad sicherstellen, dass auch seine Abzugbrücke durch das Betrugsnachweisprotokoll geschützt ist. Fast alle Bitcoin Layer 2 können derzeit jedoch nicht diese Prämisse erfüllen und müssen sich auf Multi-Signatur/MPC verlassen. Also, wie wählt man Multi-Signatur aus? Das Signieren der MPC-Lösung ist ein Thema, das eng mit der Sicherheit von Layer 2 zusammenhängt.

Merlin wählte Cobo's MPC-Dienst für die Brückenlösung. Unter Verwendung von Maßnahmen wie der Isolation von Hot- und Cold-Wallets werden die Brückenvermögenswerte gemeinsam von Cobo und Merlin Chain verwaltet. Jedes Abhebungsverhalten muss gemeinsam von den MPC-Teilnehmern von Cobo und Merlin Chain behandelt werden. Im Wesentlichen wird die Zuverlässigkeit der Abhebrücke durch die Kreditbürgschaft der Institution garantiert. Natürlich handelt es sich in diesem Stadium nur um eine Übergangslösung. Mit der allmählichen Verbesserung des Projekts kann die Abhebrücke durch die Einführung von BitVM und dem Betrugsnachweisprotokoll durch die „optimistische Brücke“ mit einer 1/N-Vertrauensannahme ersetzt werden. Die Umsetzung wird jedoch schwieriger sein. Große (fast alle offiziellen Layer 2-Brücken verlassen sich derzeit auf Mehrfachsignatur).

Insgesamt können wir es klären, Merlin stellte DAC auf POS-Basis vor, BitVM-basiertes optimistisches ZK-Rollup und Cobo-basierte MPC-Asset-Verwahrungslösung, löste das DA-Problem durch Öffnen der DAC-Berechtigungen; Sicherstellung der Sicherheit von Zustandsübergängen durch Einführung von BitVM und Betrugsnachweisprotokollen; Sicherstellung der Zuverlässigkeit der Abhebrücken durch Einführung des MPC-Dienstes der renommierten Vermögensverwaltungsplattform Cobo.

Lumoz's Zwei-Schritte-Verifizierung ZKP Einreichungsstrategie

In unseren früheren Diskussionen sind wir in das Sicherheitskonzept von Gate eingetaucht und haben das innovative Konzept der optimistischen ZK-Rollups erforscht. Ein Schlüsselelement in Merlins technologischer Entwicklung ist der dezentralisierte Prover. Diese Rolle ist entscheidend innerhalb der ZK-Rollup-Architektur, da sie damit beauftragt ist, ZK-Beweise für die vom Sequenzer freigegebenen Chargen zu generieren. Die Erstellung von Zero-Knowledge-Beweisen ist bemerkenswert ressourcenintensiv und stellt eine erhebliche Herausforderung dar.

Eine grundlegende Strategie zur Beschleunigung der Generierung von ZK-Beweisen besteht darin, die Aufgaben zu teilen und zu parallelisieren. Dieser Prozess, bekannt als Parallelisierung, beinhaltet die Aufteilung der ZK-Beweisgenerierung in verschiedene Teile. Jeder Teil wird von einem anderen Beweiser bearbeitet, und schließlich fügt ein Aggregator diese individuellen Beweise zu einem einheitlichen Ganzen zusammen. Dieser Ansatz beschleunigt nicht nur den Prozess, sondern verteilt auch die Rechenlast effektiv.

Um den Generierungsprozess des ZK-Beweises zu beschleunigen, wird Merlin die Prover von Lumoz als Service-Lösung übernehmen. Tatsächlich geht es darum, eine große Anzahl von Hardwaregeräten zusammenzufassen, um einen Mining-Pool zu bilden, und dann Rechenaufgaben auf verschiedene Geräte zu verteilen und entsprechende Anreize zuzuweisen, was in gewisser Weise dem POW-Mining ähnelt.

In dieser dezentralen Prover-Lösung gibt es einen Angriffsszenario-Typ, der allgemein als Front-Running-Angriff bekannt ist: Angenommen, ein Aggregator hat ZKP erstellt und sendet ZKP, um Belohnungen zu erhalten. Nachdem andere Aggregatoren den Inhalt von ZKP sehen, veröffentlichen sie denselben Inhalt vor ihm und behaupten, dass er zuerst den ZKP generiert hat. Wie löst man diese Situation?

Vielleicht die instinktivste Lösung, die jeder in Betracht zieht, ist die Zuweisung einer bestimmten Aufgabennummer an jeden Aggregator. Zum Beispiel kann nur Aggregator A Aufgabe 1 übernehmen, und andere erhalten keine Belohnungen, auch wenn sie Aufgabe 1 abschließen. Aber es gibt ein Problem mit diesem Ansatz, nämlich dass er einzelne Risiken nicht widerstehen kann. Wenn Aggregator A eine Leistungsstörung hat oder getrennt ist, bleibt Aufgabe 1 stecken und kann nicht abgeschlossen werden. Darüber hinaus kann diese Methode, Aufgaben an eine einzelne Entität zuzuweisen, die Produktivitätseffizienz nicht durch einen Wettbewerbsanreizmechanismus verbessern und ist kein guter Ansatz.

Polygon zkEVM hat einmal in einem Blog eine Methode namens Proof of Efficiency vorgeschlagen, in der darauf hingewiesen wurde, dass Wettbewerbsmittel eingesetzt werden sollten, um den Wettbewerb zwischen verschiedenen Aggregatoren zu fördern und Anreize auf First-Come, First-Served-Basis zuzuweisen. Der Aggregator, der zuerst den ZK-Proof an die Kette sendet, kann Belohnungen erhalten. Natürlich erwähnte er nicht, wie das MEV-Frontrunning-Problem gelöst werden soll.

Lumoz übernimmt eine Zwei-Schritte-Verifikation ZK-Zertifikat Einreichungsmethode. Nachdem ein Aggregator ein ZK-Zertifikat generiert, muss er nicht zuerst den vollständigen Inhalt senden, sondern veröffentlicht nur den ZKP-Hash. Mit anderen Worten, veröffentlicht den Hash (ZKP+Aggregator-Adresse). Auf diese Weise, auch wenn andere den Hash-Wert sehen, kennen sie nicht den entsprechenden ZKP-Inhalt und können nicht direkt vorgehen;

Wenn jemand einfach den gesamten Hash kopiert und zuerst veröffentlicht, hat das keinen Sinn, da der Hash die Adresse eines bestimmten Aggregators X enthält. Selbst wenn Aggregator A den Hash zuerst veröffentlicht, wenn das ursprüngliche Bild des Hashs offenbart wird, wird jeder auch sehen, dass die im Hash enthaltene Aggregatoradresse X ist, nicht A.

Durch dieses Zwei-Schritte-Verifizierungs-ZKP-Einreichungsschema kann Merlin (Lumoz) das Front-Running-Problem lösen, das im ZKP-Einreichungsprozess besteht, und somit hochgradig wettbewerbsfähige Anreize zur Generierung von Zero-Knowledge-Proofs erreichen, was die Geschwindigkeit der ZKP-Generierung erhöht.

Merlins Phantom: Multi-Chain-Interoperabilität

Laut dem Technologie-Roadmap von Merlin werden sie auch die Interoperabilität zwischen Merlin und anderen EVM-Ketten unterstützen. Der Umsetzungspfad ist im Grunde derselbe wie die frühere Zetachain-Idee. Wenn Merlin als Ursprungskette und andere EVM-Ketten als Zielkette verwendet werden, wird der Merlin-Node, wenn er den cross-chain Interoperabilitätsanforderung des Benutzers erkennt, die nachfolgende Arbeit auf der Zielkette auslösen.

Zum Beispiel kann ein von Merlin-Netzwerk gesteuertes EOA-Konto auf Polygon bereitgestellt werden. Wenn ein Benutzer eine Anweisung zur Cross-Chain-Interoperabilität auf der Merlin-Chain ausgibt, analysiert das Merlin-Netzwerk zuerst dessen Inhalt und generiert einen Transaktionsdatensatz, der auf der Zielkette ausgeführt werden soll, und das Orakel-Netzwerk führt dann die MPC-Signaturverarbeitung auf der Transaktion durch, um die Transaktionsnummer zu generieren. Der Relayer-Knoten von Merlin gibt die Transaktion dann auf Polygon frei und führt anschließende Operationen über Merlins Vermögenswerte im EOA-Konto auf der Zielkette aus, wie z. B.

Wenn die vom Benutzer angeforderte Operation abgeschlossen ist, werden die entsprechenden Vermögenswerte direkt an die Adresse des Benutzers in der Zielkette weitergeleitet. Theoretisch können sie auch direkt an die Merlin Chain übertragen werden. Diese Lösung hat einige offensichtliche Vorteile: Sie kann die Bearbeitungsgebühren und den Verschleiß vermeiden, die durch Cross-Chain-Bridge-Verträge bei der übertragung traditioneller Vermögenswerte über verschiedene Ketten verursacht werden, und die Sicherheit der Cross-Chain-Operationen wird direkt von Merlins Oracle-Netzwerk garantiert, ohne dass auf externe Infrastruktur angewiesen werden muss. Solange Benutzer Merlin Chain vertrauen, kann davon ausgegangen werden, dass ein solches Cross-Chain-Interoperabilitätsverhalten kein Problem darstellt.

Zusammenfassen

In diesem Artikel interpretieren wir kurz die allgemeine technische Lösung von Merlin Chain, von der wir glauben, dass sie es mehr Menschen ermöglichen wird, den allgemeinen Arbeitsablauf von Merlin zu verstehen und ein klareres Verständnis seines Sicherheitsmodells zu haben. Angesichts dessen, dass das aktuelle Bitcoin-Ökosystem in vollem Gange ist, glauben wir, dass diese Art von Technologie-Popularisierungsaktivitäten wertvoll und von der Allgemeinheit benötigt werden. Wir werden in Zukunft langfristige Nachverfolgungen von Merlin, bitLayer, B^Square und anderen Projekten durchführen, um eine eingehendere Analyse ihrer technischen Lösungen zu erhalten. Also bleiben Sie dran!

Haftungsausschluss:

1. Dieser Artikel stammt aus [geek web3] liegt das Urheberrecht beim Originalautor [Faust], wenn Sie Einwände gegen den Nachdruck haben, kontaktieren Sie bitteGate Learn Team, das Team wird es so schnell wie möglich gemäß den entsprechenden Verfahren bearbeiten.

2. Die Ansichten und Meinungen, die in diesem Artikel zum Ausdruck gebracht werden, repräsentieren nur die persönlichen Ansichten des Autors und stellen keine Anlageberatung dar.

3. Andere Sprachversionen des Artikels werden vom Gate Learn-Team übersetzt. Ohne Bezugnahme Gate.com, das Kopieren, Verteilen oder Plagiieren der übersetzten Artikel ist verboten.