Sophon erreicht EVM-Äquivalenz und führt erweiterte Entwicklerfunktionen ein

Auf Unterhaltung ausgerichtete Blockchain-Plattform Sophon kündigte die Einführung einer Kerntechnologie an, die von Matter Labs für das Ethereum Layer 2 Rollup ZKsync Dadurch hat die Plattform die Äquivalenz zur Ethereum Virtual Machine (EVM) erreicht.

EVM-Äquivalenz bezieht sich auf das Ausmaß, in dem eine andere Blockchain-Umgebung das Verhalten der virtuellen Maschine von Ethereum exakt replizieren kann, einschließlich der Kompatibilität auf Bytecode-Ebene.

Sophon Entwickler, die keine zusätzlichen Funktionen der benutzerdefinierten EraVM nutzen möchten, können weiterhin standardmäßige EVM-Smart Contracts mit herkömmlichen Ethereum-Entwicklungstools implementieren. Diese Erweiterung soll die Entwicklung vereinfachen und die Erstellung praktischerer Anwendungen für Endbenutzer unterstützen.

Hauptfunktionen des Bytecode-Interpreters virtueller Maschinen

Zero-Knowledge-Chains (ZK) wie Era nutzen EraVM, eine speziell für ZK-Anwendungen entwickelte virtuelle Maschine, die sich von der EVM hinsichtlich ihres Befehlssatzes und Ausführungsmodells unterscheidet. Obwohl Smart Contracts, die in Solidity oder Vyper geschrieben sind, für EraVM kompiliert werden können, erforderten bestimmte Ausführungsunterschiede und Tool-Einschränkungen in der Vergangenheit Anpassungen.

Um diese Herausforderungen zu meistern, hat ZKsync einen EVM-Ausführungsmodus mit einem EVM-Bytecode-Interpreter implementiert. Dadurch kann unveränderter EVM-Bytecode auf ZK-Chains ausgeführt werden, ohne dass eine Neukompilierung oder Änderungen an den Entwicklungstools erforderlich sind. Diese Kompatibilität ermöglicht es, dass Anwendungen, die ursprünglich für Ethereum entwickelt wurden, auf ZKsync ausgeführt werden können, während EraVM weiterhin als zugrunde liegende Ausführungs-Engine dient.

Der EVM-Interpreter ersetzt EraVM nicht; er fungiert vielmehr als Kompatibilitätsschicht, die die Ausführung von Ethereum-basiertem Bytecode innerhalb der EraVM-Infrastruktur ermöglicht. Beim Einsatz eines EVM-Vertrags wird dessen Bytecode-Hash mit einer spezifischen Kennung versehen, die dem System signalisiert, ihn über den Interpreter und nicht nativ über EraVM auszuführen.

Während der Ausführung werden EVM-Opcodes zur Laufzeit vom Interpreter verarbeitet, der sie den entsprechenden EraVM-Anweisungen zuordnet und dabei versucht, das Verhalten von Ethereum so genau wie möglich nachzubilden. Was die Ressourcennutzung betrifft, so wird die Ausführung zwar mit der nativen Gaseinheit von EraVM berechnet, das EVM-Gasmodell wird jedoch für die interne Abrechnung im Interpreter verwaltet.

Solidity- und Vyper-Verträge können direkt und ohne Neukompilierung mit Tools wie zksolc oder zkvyper bereitgestellt werden. Die Kompatibilität mit dem ursprünglichen Ethereum-Bytecode bleibt dabei erhalten. Dies ermöglicht eine einfache Migration oder parallele Bereitstellung bestehender Smart Contracts. Das System unterstützt außerdem standardmäßige Ethereum-Entwicklungsumgebungen, sodass Entwickler Frameworks wie Foundry, Hardhat und Remix ohne benutzerdefinierte Plugins oder zusätzliche Konfiguration nutzen können. Dies trägt dazu bei, vertraute Arbeitsabläufe beizubehalten und die Integration zu vereinfachen.

Die Adressableitung entspricht den Ethereum-Spezifikationen. Das bedeutet, dass die Operationen „create“ und „create2“ identische Vertragsadressen erzeugen wie im Ethereum-Mainnet. Dies gewährleistet Vorhersehbarkeit und Kompatibilität. Darüber hinaus sind mehrere Verträge auf Systemebene vorinstalliert und sofort einsatzbereit, darunter Implementierungen wie „create2“, „multicall3“ und „singletonFactory“ (konform mit ERC-2470). Diese Vorabverfügbarkeit vereinfacht die Entwicklung, indem sie den Einrichtungsaufwand reduziert und sofort einsatzbereite Infrastrukturkomponenten bereitstellt.

Obwohl der Interpreter die Ausführung von für Ethereum geschriebenen Verträgen ohne Änderungen ermöglicht, gibt es bemerkenswerte Unterschiede zwischen dieser Konfiguration und der direkten Ausführung von Verträgen im Ethereum-Netzwerk. 

Beispielsweise werden Gasgebühren in Erg – der nativen Einheit von EraVM – und nicht in Ethereums Gas bezahlt. Einige EVM-Operationen wie CALLCODE und SELFDESTRUCT werden aufgrund technischer Einschränkungen in EraVM nicht unterstützt. Darüber hinaus führt der Übersetzungsprozess zu höheren Transaktionskosten, die oft 1.5- bis 4-mal höher sind als bei nativen EraVM-Verträgen.

Auch die Cross-Kompatibilität ist eingeschränkt, da Funktionen wie „delegatecall“ zwischen EVM- und EraVM-Verträgen nicht funktionieren. Obwohl der EVM-Interpreter für Teams, die Ethereum-Kompatibilität anstreben, Komfort bietet, sind speziell für EraVM geschriebene Verträge im Allgemeinen kostengünstiger und leistungsfähiger. Entwicklern wird empfohlen, die native EraVM-Bereitstellung zu verwenden, wenn optimale Ausführungseffizienz Priorität hat.