Ursprünglicher Autor: PSE Trading Analyst @cryptohawk

TL;DR

  1. Eine virtuelle Maschine ist ein softwareemuliertes Computersystem, das eine Ausführungsumgebung für Programme bereitstellt. Es kann verschiedene Hardwaregeräte simulieren und die Ausführung von Programmen in einer kontrollierten und kompatiblen Umgebung ermöglichen.

  2. Die Ethereum Virtual Machine (EVM) ist eine stapelbasierte virtuelle Maschine, die zur Ausführung intelligenter Ethereum-Verträge verwendet wird. zkEVM hat bestimmte zk-sichere Effizienzoptimierungen hinsichtlich der EVM-Äquivalenz/Kompatibilität vorgenommen;

    zkVM gibt die EVM-Äquivalenz/-Kompatibilität auf und erhöht die Priorität der ZK-Freundlichkeit;

    Datenschutz zkVM überlagert zkVM mit nativen Datenschutzfunktionen;

    SVM, FuelVM und MoveVM haben das gemeinsame Streben nach ultimativer Leistung durch parallele Ausführung, sie weisen jedoch ihre eigenen Merkmale in Designdetails auf;

    ESC VM und BitVM haben bestimmte innovative Computing-Layer-Experimente auf der ETH- bzw. BTC-Kette durchgeführt, aber der tatsächliche Bedarf an Implementierung ist im aktuellen Umfeld gering.

  3. Die enorme Benutzerökologie von EVM bestimmt, dass es für jedes Blockchain-Netzwerk, das darauf verzichtet, kurzfristig schwierig sein wird, mit ihr zu konkurrieren. Daher führt die Nicht-EVM-Ökologie EVM-ökologische Benutzer über Übersetzer/Compiler/Bytecode-Interpreter und sogar VM-Kompatibilitätsschichten ein Nutzen Sie Nicht-EVM. Die Verwendung von Funktionen virtueller Maschinen zum Aufbau einer neuen ökologischen Erzählung kann ein notwendiger Weg zum Erfolg sein.

1.1 Was ist VM?

Eine virtuelle Maschine (VM) ist ein Baustein virtualisierter Computerressourcen, der fast die gleichen Funktionen wie ein Computer ausführt, einschließlich der Ausführung von Anwendungen und Betriebssystemen. Das Konzept virtueller Maschinen ist nicht neu und die Technologie ist in vielen Technologie-Ökosystemen weit verbreitet.

Im Kontext der Blockchain ist eine virtuelle Maschine (VM) eine Software, die Programme ausführt, oft auch als Laufzeitumgebung bezeichnet, die Blockchain-Smart Contracts ausführt. Virtuelle Maschinen stellen normalerweise eine virtuelle Computerumgebung bereit, indem sie verschiedene Hardwaregeräte simulieren. Die Hardwaregeräte, die verschiedene virtuelle Maschinen simulieren können, variieren, umfassen jedoch normalerweise CPU, Speicher, Festplatte, Netzwerkschnittstelle usw. Wenn eine On-Chain-Transaktion übermittelt wird, ist die virtuelle Maschine für die Verarbeitung der Transaktion und die Aktualisierung des Blockchain-Status (des aktuellen globalen Status des gesamten Netzwerks) verantwortlich, der von der Ausführung der Transaktion betroffen ist. Die spezifischen Regeln zum Ändern des Netzwerkstatus werden von der VM definiert. Bei der Verarbeitung einer Transaktion wandelt die VM den Smart-Contract-Code in ein Format um, das die Knoten-/Validator-Hardware ausführen kann.

Der wichtigste Kernel unter den VMs ist LLVM (Low-Level-Virtual-Machine), der als wichtigster Kernel des Compilers angesehen werden kann. Das Bild zeigt das ursprüngliche EVM-Betriebsschema. Der Smart-Vertrag wird über den Zwischencode von LLVM IR konvertiert und in Bytecode umgewandelt. Diese Bytecodes werden auf der Blockchain gespeichert. Wenn der Smart Contract aufgerufen wird, werden die Bytecodes in entsprechende Opcodes umgewandelt, die dann von der EVM und der Knotenhardware ausgeführt werden.

1.2 Mainstream-VM

1.2.1 EVM – Blockchain VM hat insgesamt einen Stein, EVM hat ausschließlich acht Buckets und der Rest ist in zwei Buckets unterteilt.

Repräsentative Projekte: Optimismus, Arbitrum

Als Blockchain-Ökosystem mit den aktivsten Entwicklerbenutzern in der Branche ist die Ethereum Virtual Machine (EVM) eine stapelbasierte virtuelle Maschine, die eine virtuelle Computerumgebung bereitstellt, indem sie Hardwaregeräte wie CPU, Speicher, Speicher und Stapel simuliert. um die Anweisungen des Smart Contracts auszuführen und den Status und die Daten des Smart Contracts zu speichern. Der Befehlssatz von EVM umfasst verschiedene Operationscodes Opcode, wie z. B. arithmetische Operationen, logische Operationen, Speicheroperationen, Sprungoperationen usw.

Der von EVM simulierte Speicher und Speicher sind Geräte, die zum Speichern des Status und der Daten intelligenter Verträge verwendet werden. EVM behandelt Speicher und Speicher als zwei verschiedene Bereiche und kann durch Lesen und Schreiben von Speicher und Speicher auf den Status und die Daten intelligenter Verträge zugreifen.

Der simulierte EVM-Stack wird zum Speichern der Operanden und Ergebnisse von Anweisungen verwendet. Die meisten Anweisungen im Befehlssatz des EVM sind stapelbasiert, lesen Operanden vom Stapel und legen das Ergebnis zurück auf den Stapel.

Der Entwurfsprozess von EVM erfolgt offensichtlich von unten nach oben. Zuerst wird die simulierte Hardwareumgebung (Stack, Speicher) fertiggestellt und dann ein eigener Satz von Assemblerbefehlen (Opcode) und Bytecode (Bytecode) entsprechend der entsprechenden Umgebung entworfen. . Die Ethereum-Community hat zwei kompilierte Hochsprachen – Solidity und Vyper – für die EVM-Ausführungseffizienz entwickelt. Es versteht sich von selbst, dass Solidity eine EVM-Hochsprache ist, die von Vitalik entwickelt wurde, um einige der in Solidity bestehenden Mängel zu beheben. Sie fand jedoch keine große Akzeptanz in der Community und verschwand daher allmählich die Bühne der Geschichte.

1.2.2 zkEVM – Ich will alles: kompatibel mit der EVM-Umgebung + unterstützt globale Status-Root-Transformation, um ZK-Proof zu generieren

Repräsentative Projekte: Taiko, Scroll, Polygon zkEVM

Da die EVM nicht im Hinblick auf zk-sichere Berechnungen entwickelt wurde, weist sie Eigenschaften auf, die für Prüfschaltungen ungünstig sind, insbesondere im Hinblick auf spezielle Opcodes, stapelbasierte Architektur, Speicheraufwand und Prüfkosten. zkEVM ist eine virtuelle Maschine, die intelligente Verträge auf eine Weise ausführt, die mit zk-proof-Berechnungen kompatibel ist, sodass der Ausführungsprozess von EVM durch zk-proof/validity-proof effizienter und kostengünstiger überprüft werden kann. Im Vergleich zu OP Rollup muss die Ausführungsschicht nur EVM kopieren, und der Aufbau von EVM, um ZK-freundlich zu sein, stellt für ZK Rollup eine zusätzliche Herausforderung dar.

ZK-Rollups sind nicht ohne weiteres mit der Ethereum Virtual Machine (EVM) kompatibel. Der Nachweis allgemeiner EVM-Berechnungen in einer Schaltung ist schwieriger und ressourcenintensiver als der Nachweis einfacher Berechnungen (wie der zuvor beschriebenen Token-Übertragung).

Fortschritte in der Zero-Knowledge-Technologie (öffnet sich in einem neuen Tab) haben jedoch das Interesse daran, EVM-Berechnungen in Zero-Knowledge-Beweise zu verpacken, neu entfacht. Diese Bemühungen zielen darauf ab, eine wissensfreie EVM-Implementierung (zkEVM) zu erstellen, die die Korrektheit der Programmausführung effizient überprüfen kann. .

Wie EVM wechselt zkEVM zwischen Zuständen, nachdem Berechnungen für bestimmte Eingaben durchgeführt wurden. Der Unterschied besteht darin, dass zkEVM auch wissensfreie Beweise erstellt, um die Richtigkeit jedes Schritts in der Programmausführung zu überprüfen. Gültigkeitsnachweise überprüfen die Korrektheit von Vorgängen, die den Status der virtuellen Maschine (Speicher, Stapel, Speicher) und die Berechnung selbst betreffen (d. h. hat die Operation die richtigen Opcodes aufgerufen und sie korrekt ausgeführt?).

Die Idee ist schön, aber die Realität ist sehr dürftig. Derzeit ist es für Rollup schwierig, sowohl ZK-Freundlichkeit als auch EVM-Kompatibilität (oder sogar Äquivalenz) zu erreichen, das heißt, es muss entweder die Ethereum L1-Ausführungsschicht so vollständig wie möglich kopieren. einschließlich Hash, Zustandsbaum und Transaktionsbaum, Vorkompilierung usw., sodass der Ethereum L1-Ausführungsclient unverändert verwendet werden kann, um Rollup-Blöcke zu verarbeiten oder die EVM-Kompatibilität zu verwerfen und den vorhandenen Opcode für die In-Circuit-Bescheinigung/Verifizierung neu zu erstellen , was eine intelligente Vertragsausführung ermöglicht.

1.2.3 zkVM – Sie können Ihren Kuchen nicht haben und ihn auch essen: zk-sichere, effizienzorientierte, nicht-evm-virtuelle Maschine

Repräsentative Projekte: Starknet, Zksync, RISC ZERO

zkVM verzichtet auf die EVM-Kompatibilität, betrachtet Datennachweise und Statusaktualisierungen als seine Kernziele und findet einen gemeinsamen Nenner zwischen Kryptographie und Hochsprachen, um ein gemeinsames Framework für verschiedene Anwendungen bereitzustellen.

Da Starkware früher im gesamten ZK-Bereich gestartet ist, hat es ausreichend Technologie angesammelt und verfügt über einen gewissen technologischen Vorsprung. Es handelt sich um eine repräsentative ZK-zentrierte technische Architektur, und Cairo VM und Cairo Language basieren auf ZK. Der Nachteil besteht darin, dass die Lernkosten in Kairo relativ hoch sind.

Das Framework von ZKsync ist mit den Eigenschaften von EVM und ZK kompatibel, integriert Solidity mit seiner selbst entwickelten Schaltkreissprache Zinc und vereint beide auf IR-Ebene innerhalb des Compilers. Der Vorteil besteht darin, dass der Compilerkern LLVM mit mehreren Sprachen kompatibel ist.

RISC Zero nutzt die RISC-V-Architektur, um einen Simulator zu erstellen, der es Programmierern ermöglicht, Programme für zkVM in gängigen Sprachen wie Rust, C/C++ und Go zu schreiben. Dies bedeutet, dass die Anwendungslogik nicht auf was beschränkt werden muss kann in Solidity ausgedrückt werden, was das Schreiben und Verketten von irrelevantem Code ermöglicht.

1.2.4 Datenschutz zkVM – zk-freundliche + native Datenschutzunterstützung versucht, einen neuen ökologischen Funken zu entfachen

Repräsentative Projekte: Aleo, Ola, Polygon Miden

Blockchain dient als öffentliches Buchhaltungssystem und alle Transaktionen werden in der Kette durchgeführt, was bedeutet, dass Zustandsänderungen, die Vermögensinformationen zu Adressen oder Konten enthalten, offen und transparent sind. Daher glauben einige Blockchain-Teams, dass neben der Arbeit an Skalierungslösungen auch der Datenschutz als nächstes wichtiges Feature implementiert werden muss.

Datenschutz zkVM Zusätzlich zu den Funktionen der zk-freundlichen Erweiterungsunterstützung können Anwendungsentwickler der oberen Ebene aufgrund der Datenschutzfunktionen, die nativ von der eigenen Programmiersprache unterstützt werden, datenschutzbezogene Dapps entwickeln, die neue Anwendungsszenarien und großartige Erzählungen bringen. Lösen Sie beispielsweise das MEV-Problem vollständig und schützen Sie das Eigentum an Benutzerdaten. Natürlich erfordert die Komplexität des Privacy-zkVM-Designs ein größeres technisches Team, um es zu implementieren, und es kann mehrere Jahre dauern, bis es fertig ist.

1.2.5 SVM – Nachdem die Flut zurückgegangen ist, gibt es immer noch Glut: eine Ausführungsumgebung, in der das Leistungsdesign das Äußerste erreicht hat

Repräsentative Projekte: Eclipse Mainnet, Nitro, MakerDAO Chain (vielleicht)

SVM, die virtuelle Maschine von Solana, konzentriert sich auf eine leistungsstarke Ausführungsumgebung, und intelligente Verträge werden hauptsächlich in der Sprache Rust geschrieben. Im Vergleich zu den Single-Thread-Ausführungsumgebungen EVM und EOS WASM implementiert SVM die gleichzeitige Ausführung nicht überlappender Transaktionen und Transaktionen, die nur denselben Status lesen, indem Solana-Transaktionen alle Zustände beschreiben müssen, die eine Transaktion bei der Ausführung liest oder schreibt.

Um eine schnelle Verifizierung/Übertragung großer Transaktionsblöcke zu ermöglichen, nutzt der Transaktionsverifizierungsprozess im Solana-Netzwerk außerdem in großem Umfang Pipeline-Optimierungen, die im CPU-Design üblich sind. Um die Situation zu erfüllen, in der der Eingabedatenfluss in einer Reihe von Schritten verarbeitet wird und für jeden Schritt unterschiedliche Hardware verantwortlich ist. Ein typischer Vergleich ist eine Waschmaschine und ein Trockner, die mehrere Ladungen Wäsche nacheinander waschen/trocknen/falten. Die Reinigung muss vor dem Trocknen erfolgen und das Falten muss vor dem Trocknen erfolgen, aber jeder dieser drei Vorgänge wird von einer separaten Einheit durchgeführt.

Darüber hinaus ist SVM registerbasiert und verfügt über einen viel kleineren Befehlssatz als EVM, wodurch sich die Ausführung von SVM in ZK einfacher nachweisen lässt. Für optimistische Rollups erleichtert ein registerbasiertes Design das Setzen von Prüfpunkten.

1.2.6 Fuel VM – Buff Stack: Parallele virtuelle Maschine im UTXO-Framework

Repräsentatives Projekt: Kraftstoff

Fuel VM ist eine Verbesserung, die auf dem technischen Framework von EVM, Solana, WASM und BTC Cosmos basiert. Im Vergleich zu EVM weist es die folgenden Eigenschaften auf:

Das Einzigartigste ist, dass Fuel nicht nur Zugriffslisten ähnlich wie SVM erstellt, sondern auch die Möglichkeit hat, Transaktionen parallel zu nicht überlappenden Transaktionen auszuführen. Darüber hinaus übernimmt es das UTXO-Modell, das in Token-UTXO und Vertrags-UTXO unterteilt ist Verbesserung der Zugriffseffizienz und des Rechendurchsatzes.

Darüber hinaus bietet Fuel VM durch seine eigene domänenspezifische Sprache Sway und die unterstützende Toolkette Force ein leistungsstarkes und reibungsloses Entwicklererlebnis. Die Entwicklungsumgebung behält die Vorteile intelligenter Vertragssprachen wie Solidity bei und übernimmt gleichzeitig das in eingeführte Paradigma das Rust-Tool-Ökosystem.

Zukünftig wird Fuel VM auch Sway-Sprach-Upgrades implementieren, einschließlich Compiler-Optimierung hinsichtlich der Bytecode-Größe, Sway wird mehr Backends unterstützen (das EVM-Backend befindet sich bereits in der Entwicklung), die Abstraktion wird wirtschaftlicher sein und es werden mehr Anwendungen verfügbar sein. Migration von Solidity/Vyper zu Sway, Verbesserung der Wiedereintrittsanalyse auf Compilerebene und mehr.

1.2.7 ESC VM – der Nachfolger von Ordinal/Smartweave: die Rechenschicht auf Ethereum

Repräsentatives Projekt: Ethscriptions Protocol

ESC VM oder Ethscriptions Virtual Machine ist eine vom Ethscriptions Protocol vorgeschlagene intelligente Vertragslösung. Das Ethscriptions Protocol selbst ist ein Protokoll ähnlich dem BTC Ordinal in der Ethereum-Kette und konzentriert sich auf die Erforschung kostengünstiger Alternativen, die sich von Smart Contracts und L2 unterscheiden.

Mit Ethscriptions können Benutzer die Speicherung und Ausführung intelligenter Verträge zu sehr geringen Kosten umgehen und die Anrufdaten in Tx zur Berechnung über die im Voraus vereinbarten Protokollregeln verwenden. Einfach ausgedrückt: Solange es eine erfolgreiche Ethereum-Transaktion gibt, ihre Aufrufdaten den angegebenen gültigen Datenspezifikationen entsprechen und die eindeutige „An“-Adresse nicht 0 ist, kann davon ausgegangen werden, dass eine Ethscription rechtmäßig erstellt wurde, die „Von“-Adresse ist der Ersteller und die „an“-Adresse gehört dem Eigentümer.

Zu Beginn des Entwurfs bevorzugt jede Ethscription die Form von NFT, z. B. Bild-NFT. Der Bildinhalt wird direkt in CallData im Base-64-Format geschrieben:

Das kürzlich beliebte eths basiert auf der Protokollspezifikation brc-20 und wurde mit Ethscription erstellt:

Der von ESC VM eingeführte Smart Contract wird als dummer Vertrag bezeichnet, der als logischer Vertrag veröffentlicht wird, aber nicht in Form von EVM in der Kette interagiert. Darüber hinaus fügt ESC VM auch einen speziellen Format-Computerbefehl hinzu. Mit diesem Format erstellte Ethskriptionen werden von ESC VM erkannt und interagieren mit dummen Verträgen, wie z. B. Deploy – dumme Verträge bereitstellen, Call – dumme Verträge aufrufen.

Diese Lösung weist einige Einschränkungen auf. Erstens ist die Funktion des dummen Vertrags nicht zahlbar. Das heißt, wenn Sie ETH über den dummen Vertrag senden möchten, müssen Sie einen „Brückenvertrag“ abschließen. selbst birgt Risiken von Kontrollmissbrauch und Vermögensdiebstahl; zweitens gibt es Eintrittsbarrieren in das Ökosystem, die die willkürliche Schaffung von dummen Verträgen nicht zulassen, und ihre Codes müssen durch den Governance-Vorschlag des Ethscriptions-Protokolls definiert werden.

Zusammenfassend lässt sich sagen, dass ESC VM eine Rechenschicht ist, die auf Ethereum L1 als Datenspeicherschicht aufbaut. Sie wird durch die Platzierung von Vertragslogik, Vertragsaufrufen, Vertragsaufrufen und anderen Dateninhalten in den Anrufdaten von Ethereum ESC VM implementiert Der Statuskonsens ist der ESC-VM-Client-Konsens, der der SmartWeave-Implementierungslogik von Arweave ähnelt, mit der Ausnahme, dass die Datenspeicherschicht von SmartWeave Arweave ist.

1.2.8 Bit VM – Ein interessantes Forschungsexperiment: Peer-to-Peer-Ausführungskanal auf BTC

Repräsentatives Projekt: ZeroSync

ZeroSync-Gründer Robin Linus veröffentlichte am 9. Oktober ein Whitepaper „BitVM: Compute Anything On Bitcoin“. Genauer gesagt handelt es sich dabei nicht um eine VM, sondern um den Versuch, einen Turing-vollständigen Rechenraum zu schaffen, dessen Verträge in Bitcoin On-Chain gespeichert werden , aber die Logik des Vertrags wird außerhalb der Kette ausgeführt. Wenn Sie glauben, dass die andere Partei gegen den Vertrag verstoßen hat, können Sie eine Anfechtung in der Kette einleiten. Wenn die andere Partei nicht richtig reagieren kann, können Sie alle Gelder im Vertrag einziehen.

Der Vorteil besteht darin, dass Bitcoin ohne Änderungen am Bitcoin-Protokoll, ohne neue Opcodes, ohne Soft Forks mit Turing-Vollständigkeit ausgestattet werden kann und jederzeit angewendet werden kann.

Seine Mängel sind ebenfalls offensichtlich. Erstens unterstützt es nur Transaktionen zwischen zwei Parteien (eine Partei zertifiziert und eine Partei überprüft). Zweitens erfordert die Erstellung eines Vertrags eine große Menge an Daten und die Vorabunterzeichnung einer großen Anzahl von Transaktionen Die Speicherung von Informationen außerhalb der Kette ist riesig.

Das Folgende ist eine kurze Einführung in die technische Logik:

(1) Klicken Sie hier, um die Verpflichtung einzugeben

Mit der Punkteingabe-Verpflichtung kann der Prüfer den Eingabewert 0 oder 1 für das Logikgatter festlegen. Bei dieser Verpflichtung gibt es zwei Hash-Werte H(A 0) und H(A 1). B. A 0 , wird der Eingabewert auf 0 gesetzt, und wenn A 1 angezeigt wird, wird der Eingabewert auf 1 gesetzt.

(2) Logikgatter-Bestätigung

Sobald Sie den Eingabewert haben, können Sie jedes Logikgatter im Bitcoin-Skript kombinieren, indem Sie Bitcoins AND, NOT und andere Opcodes kombinieren.

(3) Binärschaltungsverpflichtung

Turing-Vollständigkeit kann erreicht werden, indem Hunderte Millionen Logikgatter in einer Binärschaltung zusammengefasst werden. Um diese binäre Schaltung an das Bitcoin-Netzwerk zu übergeben, müssen alle Logikgatter in einem Blattknoten an einer Taproot-Adresse platziert werden.

(4) Challenge-Response-Link

Es reicht nicht aus, die Schaltung in der Kette festzulegen. Beide Parteien benötigen eine wirksame Möglichkeit, um zu überprüfen, ob die Berechnungsergebnisse des Vertrags korrekt sind. In einer idealen Welt läuft der Vertrag außerhalb der Kette und beide Parteien sind zufrieden, wenn sie kooperativ sind und keinen Streit über das Ergebnis haben. Wenn es jedoch zu Streitigkeiten zwischen den beiden Parteien der Transaktion kommt, müssen sie den Challenge-Response-Link eingeben, um die Berechnungsergebnisse zu überprüfen und die Verteilung des Kanalsaldos über Bitcoin-Skripte zu erzwingen.

Daher ist BitVM weit davon entfernt, eine Art Bitcoin-Rollup oder L2 zu sein, da es keine vollständige Ausführungsumgebung für virtuelle Maschinen, keinen globalen Status und keine Hochsprache für die Veröffentlichung komplexer intelligenter Verträge hat und auch keiner Anzahl von Benutzern die einfache Interaktion mit diesen Verträgen ermöglicht . Lassen Sie uns ein sehr beliebtes Beispiel zur Veranschaulichung verwenden: BitVM ist wie der Bau eines riesigen Computers, der größer als ein Raum ist, in einer Zeit, in der jeder ein mobiles Endgerät nutzen kann.

1.2.9 MoveVM – Das Produkt der genetischen Vererbung von Facebook Web2

Repräsentative Projekte: Aptos, Sui

Move ist eine Programmiersprache zum Schreiben sicherer Smart Contracts. Sie wurde ursprünglich von Facebook entwickelt, um die Diem-Blockchain zu unterstützen. Nach der Einstellung des Diem-Blockchain-Projekts verwendeten die von Aptos und Sui vertretenen Projekte weiterhin die Move-Sprache. Das größte Merkmal der Move-Blockchain besteht darin, dass die Datenspeicherung einen globalen Speicher verwendet, der aus einem Baum besteht, der an der Kontoadresse verwurzelt ist. Jede Adresse kann Ressourcendaten und Modulcode speichern.

Move verfügt über zwei verschiedene Arten von Programmen: Module und Skripte. Module sind Bibliotheken, die Strukturtypen und Funktionen definieren, die mit diesen Typen arbeiten. Der Strukturtyp definiert den globalen Speichermodus von Move und die Modulfunktion definiert die Regeln für die Aktualisierung des Speichers. Die Module selbst werden ebenfalls im globalen Speicher abgelegt. Das Skript ist der Einstiegspunkt der ausführbaren Datei, ähnlich der Hauptfunktion in herkömmlichen Sprachen, und ein temporäres Codefragment, das nicht im globalen Speicher veröffentlicht wird.

Zusammenfassend ähnelt das Move-Modul dem dynamischen Bibliotheksmodul, das beim Ausführen der ausführbaren Systemdatei geladen wird, und das Skript ähnelt dem Hauptprogramm. Benutzer können ihre eigenen Skripts schreiben, um auf den globalen Speicher zuzugreifen, einschließlich des Aufrufs von Modulen, während das Veröffentlichen von Modulen oder das Ausführen von Skripts über die Move VM erfolgt.

1.3 Ökologische Entwicklungstrends

Da der EVM-Netzwerkeffekt so stark ist, ist die Migration von EVM-Benutzern zur Nicht-EVM-Kettenökologie zum größten Wachstumspunkt für aufstrebende Blockchain-Projekte geworden. Dies wird in Zukunft zu mehr Dapp-Zusammensetzbarkeit und größerer Konnektivität führen Wachstum.

1.3.1 Wallet-Frontend-Kompatibilität

Das Onboarding von EVM-Benutzern in Nicht-EVM-Ketten war in der Vergangenheit eine große Hürde, aber der kürzlich eingeführte Metamask Snap wird diese Hürde überwinden. EVM-Benutzer können MetaMask weiterhin verwenden, ohne die Wallet zu wechseln. Dank der Open-Source-Beiträge von Drift zum Aufbau der hervorragenden MetaMask Snap-Implementierung entspricht die UX der Interaktion mit jeder EVM-Kette. Benutzer des Eclipse-Mainnets können mit nativen Anwendungen in MetaMask interagieren oder native Solana-Wallets wie Salmon verwenden.

1.3.2 VM-Backend-Kompatibilität

1.3.2.1 Übersetzer/Compiler

Repräsentatives Projekt: Wrap

Warp ist ein Solidity-Kairo-Übersetzer, der von Nethermind, einem bekannten Ethereum-Infrastrukturteam, entwickelt wurde. Warp kann Solidity-Code in Cairo übersetzen, das übersetzte Cairo-Programm muss jedoch häufig geändert und mit Cairo-Funktionen (z. B. Aufruf integrierter Funktionen, Optimierung des Speichers usw.) hinzugefügt werden, um die Ausführungseffizienz zu maximieren.

1.3.2.2 Bytecode-Interpreter/VM-Kompatibilitätsschicht

Repräsentative Projekte: Kakarot, Neon EVM

Kakarot ist ein in Kairo geschriebener und in Form von Smart Contracts implementierter EVM-Bytecode-Interpreter, der auf Starknet bereitgestellt wird. Er simuliert den Stack, den Speicher, die Ausführung und andere Aspekte von EVM in Form von Cairo Smart Contracts. Im Vergleich zur Codeübersetzung implementiert Kakarot die schrittweise Implementierung von Opcode und Pre-Compile hinter EVM und erstellt Komponenten wie Account Registry und Blockhash Registry, um zusätzliche Verarbeitungen bei der Zuordnung von Kontoadressen, der Erfassung von Blockinformationen usw. durchzuführen und so zu ermöglichen kakarot, um eine höhere native Kompatibilität zu erreichen.

Neon EVM ist ein EVM, das als Smart Contract läuft und in jeder SVM-Kette bereitgestellt werden kann. Das Eclipse-Mainnet selbst verwendet SVM als Ausführungsumgebung, bietet jedoch durch Neon EVM vollständige EVM-Kompatibilität (einschließlich EVM-Bytecode-Unterstützung und Ethereum JSON-RPC), und der Durchsatz ist höher als bei Single-Threaded-EVM. Darüber hinaus verfügt jede Neon-EVM-Instanz über einen eigenen lokalen Gebührenmarkt, d. h. es gibt eine Obergrenze für die Recheneinheiten im Zusammenhang mit der Interaktion einzelner Vertragskonten auf Blockhöhe (1/4 der Blockrecheneinheiten), also nur für Benutzer Sie müssen mit bestimmten heißen Verträgen interagieren. Oder Sie müssen eine Prioritätsgebühr zahlen, wenn der Block voll ist. In diesem Sinne können Anwendungen, die ihre eigenen Verträge bereitstellen, die Vorteile einer Anwendungskette nutzen und so den Schaden für die Benutzererfahrung, Sicherheit oder Liquidität des gesamten Netzwerks reduzieren, der durch die Überlastung einer bestimmten Vertragsinteraktion TX verursacht wird.

Referenzen:

1. „Kakarot: Exploring Starknet's EVM Compatibility Road“, von Cynic Starknet Astro

2. „BitVM löst hitzige Diskussion aus: Kann das Bitcoin-Netzwerk Turing-Vollständigkeit erreichen?“, von Haotian

3.https://ethereum.org/en/developers/docs/evm/

4. „Technische Architektur und ökologische Überprüfung von Starkware“, von Maxlion

5.https://twitter.com/muneeb/status/1712461799327416491

6. „Project Research丨Modular High-speed Execution Layer Fuel Research Report“, von Web3 CN

7.https://www.fuel.network/

8.https://docs.ethscriptions.com/overview/introducing-ethscriptions

9. „Analyse der ersten kritischen Sicherheitslücke von Aptos Move VM“，von Numen Cyber ​​Labs

10. https://ethereum.org/en/developers/docs/evm/

11. „Was ist SVM – die Solana Virtual Machine“ von Squads

12. „Einführung in Eclipse Mainnet: Das Ethereum SVM L2“ von Eclipse

13.https://john-hol.gitbook.io/bitvm/

14.https://bitvm.org/bitvm.pdf

15. „Die verschiedenen Arten von ZK-EVMs“ von Vitalik Buterin

16. „Cipholio Research Report: Diskussion über die Pläne und die Zukunft von ZkVM“, von YOLO SHEN, Cipholio Ventures