Kürzlich haben mehrere ZK-Rollup-Projekte Pläne für ein eigenes Mainnet oder Testnet angekündigt, welches ZK-EVM unterstützten soll. In der Zwischenzeit, Anfang August 2022, veröffentlichte Ethereum-Gründer Vitalik einen Blog, in dem er verschiedene Arten von ZK-EVM vergleicht.
Der heilige Gral des ZK-Rollup, der ein mächtiges Werkzeug für die Skalierung von Ethereum sein könnte, ist ins Rampenlicht des Marktes zurückgekehrt.
Ethereum-Skalierung, ein häufig diskutiertes Thema, wird von vielen Krypto-Nutzern erwartet. Es ist ein weit verbreiteter Irrglaube, dass der für Ende September geplante Ethereum Merge das Netzwerk nicht nur von PoW auf PoS umstellen, sondern auch seine Leistung verbessern wird.
Tatsächlich wird der Merge die Blockgröße nicht verändern, und die durchschnittliche Blockzeit wird nur von 13 Sekunden auf 12 Sekunden reduziert. Daher hält sich die Leistungsverbesserung sehr in Grenzen. Kurzfristig wird Ethereum daher auf Rollups zur Skalierung angewiesen sein.
Von den zwei primären Arten von Rollups, d.h. Optimistic Rollups und ZK-Rollups, bevorzugen viele Nutzer letztere. ZK-Rollups können auch die Transaktionsgebühren reduzieren, indem sie mehrere Off-Chain-Transaktionen zusammenfassen.
Aber noch wichtiger ist, dass sie einen Gültigkeitsnachweis durch Zero-Knowledge-Proof berechnen und an Ethereum übermitteln können, um die Sicherheitseigenschaften des Netzwerks zu übernehmen, ohne eine Challenge-Periode wie Optimistic Rollups einrichten zu müssen.
Die kostenpflichtigen ZK-Rollups
In der Anfangszeit wurden ZK-Rollups jedoch vor allem wegen ihrer Inkompatibilität mit EVM- und Smart-Contract-Funktionen kritisiert. Zum Beispiel unterstützt zkSync 1.0, die primäre Zahlungsmethode für Spenden in Gitcoin, nur Standardfunktionen wie Überweisungen.
Derzeit sind die bestehenden ZK-Anwendungen wie dYdX maßgeschneiderte Anwendungen, die keine universelle Nutzung unterstützen, was es schwierig macht, sie zu entwickeln und zu ändern.
Da verschiedene ZK-Anwendungen mit spezifischen Kreisläufen ausgestattet sind, können sie nicht miteinander interagieren, was zu einer schlechten Kompatibilität führt. Folglich besteht ein dringender Bedarf an ZK-Rollups, die Ethereum-basierte Smart Contracts unterstützen.
Außerdem ist die Kompatibilität mit virtuellen Maschinen, die Zero-Knowledge-Proof unterstützen, der Schlüssel. Glücklicherweise haben mehrere ZK-Rollup-Projekte kürzlich Pläne zur Unterstützung des ZK-EVM-Hauptnetzes oder Testnetzes angekündigt.
Heute werden wir uns mit EVM, ZK-EVM, den wichtigsten ZK-EVM-Projekten und ihren Unterschieden beschäftigen.
Was ist EVM?
Die EVM (Ethereum Virtual Machine) fungiert als Ausführungsengine und ist die Laufzeitumgebung für Smart Contracts auf Ethereum. Die Entwickler schreiben die Business-Logik (Code) in Hochsprachen wie Solidity, und der Compiler kompiliert den Code dann in einen Bytecode auf niedriger Ebene.
Anschließend parst die EVM den Bytecode in maschinenlesbare Anweisungen (Opcodes) und führt den entsprechenden Befehl aus, um den Zustand des Systems zu ändern.
EVM ist eine Stack-Maschine; es handelt sich um eine virtuelle Maschine, die auf einer Stack-Struktur basiert und daher bei der Ausführung von Opcodes mit Stack, Speicher und Storage interagieren muss.
Für Ethereum, Skalierungsprotokolle und seine Public-Chain-Konkurrenten ist EVM fast zum Synonym für das Ethereum-Ökosystem geworden. EVM steht für die Entwickler, Anwendungen und Tools des Ethereum-Ökosystems.
Wenn eine Public Chain EVM nicht unterstützt, müsste sie die Entwickler in ihrem eigenen Ökosystem von Grund auf neu ausbilden, und diese Entwickler müssten neue Anwendungen und Tools entwickeln. Jemand verglich einmal Optimism und Arbitrum, die beiden Giganten des Optimistic Rollup, und wies darauf hin, dass der eine zu 99% EVM-kompatibel ist, während der andere zu 100%. Das bedeutet, dass in dem heiß umkämpften Ethereum-Ökosystem selbst ein Unterschied von 1 % zu klaren Vor- und Nachteilen führt.
Dies zeigt auch, dass die Kompatibilität eines Projekts mit EVM direkt bestimmt, wie kompatibel es mit dem Ethereum-Ökosystem ist. Nur EVM-kompatible Projekte können eine nahtlose Migration bestehender Ethereum-Verträge sowie einen reibungslosen Zugang zu den vielen im Ethereum-Ökosystem verfügbaren Tools ermöglichen.
Die künftige ZK-EVM
Trotz der Schlüsselrolle, die EVM im Ethereum-Ökosystem spielt, ist die Entwicklung von ZK-EVM ein sehr komplexer Prozess. ZK-EVM-Projekte sind mit EVM kompatibel und ermöglichen es Entwicklern, ZK-Proofs zu erzeugen.
Mit solchen Projekten können Entwickler direkt Ethereum-Smart Contracts einsetzen und ausführen, ohne irgendwelche Änderungen vornehmen zu müssen. Gleichzeitig kann die Gültigkeit von Berechnungen, die den Betrieb von Programmen betreffen, durch Zero-Knowledge nachgewiesen werden.
Die Entwickler von EVM berücksichtigten ZK nicht von Anfang an, denn als EVM entwickelt wurde, hatte ZK noch keine Durchbrüche erzielt und wurde daher vom Mainstream nicht anerkannt.
Im Jahr 2016 hat Zcash zk-SNARK eingeführt, was die erste Einführung eines Zero-Knowledge-Proof-Algorithmus darstellte. Einige EVM-Operationen sind nicht ZK-kompatibel. Mit anderen Worten: Die Erzeugung von ZK-Proofs mit EVM ist schwierig oder ineffizient, oder die erzeugten ZK-Proofs sind zu groß.
Die Entwicklung von ZK, die für ihre große Komplexität bekannt ist, erfordert Fachwissen in den Bereichen Kryptografie, Mathematik und Hardware. Die Entwicklung von ZK-EVMs ist sogar noch anspruchsvoller, da diese EVM-kompatibel und gleichzeitig ZK-freundlich sein müssen. Glücklicherweise gab es in den letzten Jahren auf dem Gebiet der ZK immer mehr große Durchbrüche, und Projekte wie Starkware, zkSync 2.0, Polygon und Scroll haben die Entwicklung von ZK-EVMs vorangetrieben. Insbesondere die drei letztgenannten Projekte haben kürzlich Pläne für den Start des Testnetzes angekündigt.
Am 19. Juli veröffentlichte Scroll das Pre-Alpha-Testnetz, in dem Nutzer Demoprogramme wie Uniswap (Fork-Version) und Metamask ausprobieren können. Am 20. Juli kündigte Matter Labs an, dass das EVM-kompatible zkSync 2.0 im November im Mainnet verfügbar sein wird und veröffentlichte die Roadmap. Am selben Tag kündigte Polygon an, dass sein ZK-EVM-Testnetz ebenfalls bald an den Start gehen wird.
Vergleich von verschiedenen ZK-EVMs
Da es keine einheitlichen Design-Spezifikationen oder Kriterien für ZK-EVM gibt, entwickelt jedes Projektteam seine Lösung, indem es Kompromisse zwischen EVM-Kompatibilität und ZK-Unterstützung aus verschiedenen Blickwinkeln eingeht. Gegenwärtig verfolgen die meisten ZK-EVM-Projekte einen der beiden folgenden Ansätze:
- Unterstützung auf Sprachebene: Entwurf kundenspezifischer EVM-Opcodes; Erstellung neuer virtueller Maschinen mit unterschiedlichen Architekturen durch Extraktion ZK-freundlicher Operationen; Übertragung von Solidity auf neue Opcodes für virtuelle Maschinen durch den Compiler.
- Unterstützung auf Bytecode-Ebene: Unterstützung nativer EVM-Opcodes.
Zu den Projekten, die den ersten Ansatz verfolgen, gehören Starkware’s StarkNet und zkSync 2.0. StarkNet, die universelle ZK-Rollup-Lösung von Starkware, kann jede Ethereum dApp ausführen.
Entwickler können einen Compiler verwenden, um Solidity in Cairo (die Smart-Contract-Sprache von StarkNet) zu kompilieren und dann die dApp auf der ZK-freundlichen VM bereitzustellen.
Ähnlich wie Starkware erreicht zkSync 2.0 die ZK-EVM-Funktionen durch die Entwicklung zweier Compiler-Frontends: Yul und Zinc. Yul ist eine Solidity-Zwischendarstellung, die zu Bytecode für verschiedene Backends kompiliert werden kann, während Zinc eine Rust-basierte Sprache für Smart Contracts und allgemeine Zero-Knowledge-Proof-Schaltungen ist.
Da beide auf dem Open-Source-Framework LLVM basieren, erzeugen sie den effizientesten zkEVM-Bytecode.
Diese Projekte sind auf Sprachebene mit Solidity kompatibel, und Entwickler können in Solidity geschriebene Smart Contracts durch Migration einsetzen und ausführen. Ihre zugrunde liegende VM-Architektur ist jedoch nicht EVM.
Streng genommen verwenden diese Projekte eine Art zkVM. Außerdem können einige vorhandene Entwicklungstools nicht direkt verwendet werden, da sie mit unterschiedlichen Befehlen für die zugrunde liegende virtuelle Maschine arbeiten.
Dennoch sind diese Projekte ZK-freundlich und können effizienter Zero-Knowledge-Beweise erzeugen.
Zu den Projekten, die den zweiten Ansatz verfolgen, gehören Polygon ZK-EVM und Scroll. Polygon ZK-EVM heißt uVM und ist eine zkCircuit-optimierte VM mit maßgeschneiderten Opcodes zur Optimierung der EVM-Interpretation.
Der EVM-Bytecode wird zunächst in “Micro-Opcode” kompiliert und dann in der uVM ausgeführt. Polygon ZK-EVM plant, alle EVM-Opcodes zu unterstützen und ist eine ZK-Skalierungslösung, die vollständig mit Ethereum kompatibel ist:
Sie funktioniert nahtlos mit allen bestehenden Smart Contracts, Entwickler-Tools und Wallets. Wie Polygon wird auch Scroll für jeden Bytecode einen Kreislauf entwerfen, bei dem jeder von EVM ausgeführte Schritt verifiziert wird, einschließlich des Ladens von Bytecode, der Ausführung von Opcode, der Aktualisierung des Speichers usw.
In seinem Blogbeitrag unterteilt Vitalik die ZK-EVM in mehrere Typen. Insbesondere ZK-EVMs des Typs 1 werden direkt auf Ethereum entwickelt, was einen übermäßig komplizierten und ineffizienten Entwicklungsprozess mit sich bringt, und die Ethereum Foundation befasst sich nun mit dieser Angelegenheit.
Typ 2, Typ 2.5 und Typ 3 ZK-EVMs sind Äquivalente von EVM. Scroll und Polygon Hermez entwickeln sich in Richtung Typ 2 oder sogar Typ 2.5 ZK-EVMs, aber im Moment sollten beide Projekte als Typ 3 angesehen werden.
ZK-EVMs vom Typ 4, wie Starkware und zkSync, sind mit Hochsprachen kompatibel. Die Typen sind nicht unbedingt “besser” oder “schlechter” als andere Typen, und es gibt keine einheitlichen Kriterien für die Bewertung von ZK-EVMs.
Wie Vitalik es ausdrückt:
Theoretisch gibt es für Ethereum keine Notwendigkeit, eine einzige ZK-EVM-Implementierung für die L1-Nutzung zu standardisieren; verschiedene Clients könnten verschiedene Proofs verwenden, so dass wir weiterhin von Code-Redundanz profitieren.
Fazit
Da die Codes noch nicht quelloffen sind, sind die Konzepte von ZK-EVM nicht kategorisch besser oder schlechter als andere Konzepte, da wir ihre Effizienz in diesem Stadium nicht vergleichen können.
Ethereum, die größte Smart-Contract-Plattform, verfügt über ein starkes Ökosystem und einen großen Netzwerkeinfluss. Deshalb ist ZK-EVM der heilige Gral für ZK-Rollups.
ZK-Rollups können das Ethereum-Ökosystem und den Einfluss von Ethereum nur durch ZK-EVM nutzen, da sie dadurch die Sicherheit von Ethereum erben und leichteren Zugang zu einem lebendigen Entwickler-Ökosystem sowie zu bewährten Codebasen und Tools erhalten können.
Anfang 2021 sagte Vitalik in einem Blogpost, dass “kurzfristig Optimistic Rollups wahrscheinlich für allgemeine EVM-Berechnungen und ZK-Rollups vermutlich für einfache Zahlungen, Austausch und andere anwendungsspezifische Einsatzbereiche gewinnen werden, aber mittel- bis langfristig werden ZK-Rollups in allen Anwendungsfällen gewinnen, da sich die ZK-SNARK-Technologie verbessert.”
Da das Testnet/Mainnet verschiedener ZK-EVM-Projekte in Betrieb geht, wird die Layer-2-Skalierung von Ethereum in naher Zukunft äußerst interessant sein.
