Direkt zum Hauptinhalt

Die Evolution von zkEVMs: Abwägung von Kompatibilität und Performance bei der Skalierung von Ethereum

· 9 Min. Lesezeit
Dora Noda
Dora Noda
Software Engineer

Im Jahr 2022 stellte Vitalik Buterin eine einfache Frage, die die nächsten vier Jahre der Ethereum-Skalierung definieren sollte: Wie viel Ethereum-Kompatibilität sind Sie bereit zu opfern, um schnellere Zero-Knowledge-Beweise zu erhalten? Seine Antwort kam in Form eines Klassifizierungssystems mit fünf Typen für zkEVMs, das seitdem zum Industriestandard für die Bewertung dieser kritischen Skalierungslösungen geworden ist.

Springen wir vor ins Jahr 2026, und die Antwort ist nicht mehr so einfach. Die Beweiszeiten sind von 16 Minuten auf 16 Sekunden eingebrochen. Die Kosten sind um das 45-fache gesunken. Mehrere Teams haben eine Echtzeit-Beweisgenerierung demonstriert, die schneller ist als die 12-sekündigen Blockzeiten von Ethereum. Dennoch bleibt der grundlegende Kompromiss bestehen, den Vitalik identifiziert hat – und ihn zu verstehen ist für jeden Entwickler oder jedes Projekt, das vor der Wahl steht, wo es bauen soll, unerlässlich.

Die Vitalik-Klassifizierung: Typ 1 bis 4​

Vitaliks Framework kategorisiert zkEVMs entlang eines Spektrums von perfekter Ethereum-Äquivalenz bis hin zu maximaler Beweiseffizienz. Höhere Typennummern bedeuten schnellere Beweise, aber weniger Kompatibilität mit der bestehenden Ethereum-Infrastruktur.

Typ 1: Vollständig Ethereum-äquivalent​

Typ 1 zkEVMs ändern nichts an Ethereum. Sie beweisen exakt dieselbe Ausführungsumgebung, die das Ethereum L1 verwendet – dieselben Opcodes, dieselben Datenstrukturen, einfach alles.

Der Vorteil: Perfekte Kompatibilität. Ethereum-Execution-Clients funktionieren wie sie sind. Jedes Tool, jeder Vertrag und jedes Stück Infrastruktur lässt sich direkt übertragen. Dies ist letztlich das, was Ethereum benötigt, um L1 selbst skalierbarer zu machen.

Der Nachteil: Ethereum wurde nicht für Zero-Knowledge-Beweise entwickelt. Die stackbasierte Architektur der EVM ist bekanntermaßen ineffizient für die ZK-Beweisgenerierung. Frühe Typ-1-Implementierungen benötigten Stunden, um einen einzigen Beweis zu generieren.

Führendes Projekt: Taiko strebt Typ-1-Äquivalenz als Based Rollup an und nutzt die Validatoren von Ethereum für das Sequencing, was eine synchrone Komponierbarkeit mit anderen Based Rollups ermöglicht.

Typ 2: Vollständig EVM-äquivalent​

Typ 2 zkEVMs behalten die volle EVM-Kompatibilität bei, ändern jedoch interne Darstellungen – wie der Status gespeichert wird, wie Datenstrukturen organisiert sind –, um die Beweisgenerierung zu verbessern.

Der Vorteil: Für Ethereum geschriebene Smart Contracts laufen ohne Modifikation. Die Entwicklererfahrung bleibt identisch. Der Migrationsaufwand geht gegen Null.

Der Nachteil: Block-Explorer und Debugging-Tools müssen möglicherweise angepasst werden. Statusbeweise (State Proofs) funktionieren anders als auf dem Ethereum L1.

Führende Projekte: Scroll und Linea zielen auf Typ-2-Kompatibilität ab und erreichen eine nahezu perfekte EVM-Äquivalenz auf VM-Ebene ohne Transpiler oder benutzerdefinierte Compiler.

Typ 2.5: EVM-äquivalent mit Änderungen der Gaskosten​

Typ 2.5 ist ein pragmatischer Mittelweg. Die zkEVM bleibt EVM-kompatibel, erhöht jedoch die Gaskosten für Operationen, deren Beweis in Zero-Knowledge besonders teuer ist.

Der Kompromiss: Da Ethereum ein Gaslimit pro Block hat, bedeutet die Erhöhung der Gaskosten für spezifische Opcodes, dass weniger dieser Opcodes pro Block ausgeführt werden können. Anwendungen funktionieren, aber bestimmte Rechenmuster werden unverhältnismäßig teuer.

Typ 3: Fast EVM-äquivalent​

Typ 3 zkEVMs opfern spezifische EVM-Funktionen – oft im Zusammenhang mit Precompiles, der Speicherverwaltung oder der Behandlung von Vertragscode –, um die Beweisgenerierung drastisch zu verbessern.

Der Vorteil: Schnellere Beweise, geringere Kosten, bessere Performance.

Der Nachteil: Einige Ethereum-Anwendungen funktionieren nicht ohne Modifikation. Entwickler müssen möglicherweise Verträge umschreiben, die auf nicht unterstützten Funktionen basieren.

Realitätscheck: Kein Team möchte tatsächlich bei Typ 3 bleiben. Es wird als Übergangsphase verstanden, während die Teams an der komplexen Precompile-Unterstützung arbeiten, die erforderlich ist, um Typ 2.5 oder Typ 2 zu erreichen. Sowohl Scroll als auch Polygon zkEVM agierten als Typ 3, bevor sie auf der Kompatibilitätsleiter aufstiegen.

Typ 4: Kompatibel mit Hochsprachen​

Typ-4-Systeme geben die EVM-Kompatibilität auf Bytecode-Ebene vollständig auf. Stattdessen kompilieren sie Solidity oder Vyper in eine benutzerdefinierte VM, die speziell für effiziente ZK-Beweise entwickelt wurde.

Der Vorteil: Schnellste Beweisgenerierung. Niedrigste Kosten. Maximale Performance.

Der Nachteil: Verträge verhalten sich möglicherweise anders. Adressen stimmen eventuell nicht mit Ethereum-Deployments überein. Debugging-Tools erfordern komplette Neuentwicklungen. Die Migration erfordert sorgfältige Tests.

Führende Projekte: zkSync Era und StarkNet repräsentieren den Typ-4-Ansatz. zkSync transpiliert Solidity in benutzerdefinierten Bytecode, der für ZK optimiert ist. StarkNet verwendet Cairo, eine völlig neue Sprache, die auf Beweisbarkeit ausgelegt ist.

Performance-Benchmarks: Wo wir im Jahr 2026 stehen​

Die Zahlen haben sich seit Vitaliks ursprünglichem Beitrag dramatisch verändert. Was 2022 theoretisch war, ist 2026 Produktionsrealität.

Beweiszeiten​

Frühe zkEVMs benötigten etwa 16 Minuten, um Beweise zu generieren. Aktuelle Implementierungen schließen denselben Prozess in etwa 16 Sekunden ab – eine 60-fache Verbesserung. Mehrere Teams haben eine Beweisgenerierung in weniger als 2 Sekunden demonstriert, was schneller ist als die 12-sekündigen Blockzeiten von Ethereum.

Die Ethereum Foundation hat sich ein ehrgeiziges Ziel gesetzt: 99 % der Mainnet-Blöcke in weniger als 10 Sekunden zu beweisen, unter Einsatz von Hardware im Wert von weniger als 100.000 $ und einem Stromverbrauch von 10 kW. Mehrere Teams haben bereits Fähigkeiten demonstriert, die nahe an diesem Ziel liegen.

Transaktionskosten​

Das Dencun-Upgrade im März 2024 (EIP-4844 zur Einführung von „Blobs“) reduzierte die L2-Gebühren um 75–90 %, wodurch alle Rollups dramatisch kosteneffizienter wurden. Aktuelle Benchmarks zeigen:

PlattformTransaktionskostenAnmerkungen
Polygon zkEVM$ 0,00275Pro Transaktion für vollständige Batches
zkSync Era$ 0,00378Mediane Transaktionskosten
Linea$ 0,05–0,15Durchschnittliche Transaktion

Durchsatz​

Die reale Performance variiert erheblich je nach Transaktionskomplexität:

PlattformTPS (Komplexes DeFi)Anmerkungen
Polygon zkEVM5,4 tx / sAMM-Swap-Benchmark
zkSync Era71 TPSKomplexe DeFi-Swaps
Theoretisch (Linea)100.000 TPSMit fortgeschrittenem Sharding

Diese Zahlen werden sich weiter verbessern, wenn Hardware-Beschleunigung, Parallelisierung und algorithmische Optimierungen reifen.

Marktadoption: TVL und Entwickler-Traktion​

Die zkEVM-Landschaft hat sich um mehrere klare Marktführer konsolidiert, die jeweils unterschiedliche Punkte auf dem Typen-Spektrum repräsentieren:

Aktuelle TVL-Rankings (2025)​

  • Scroll: $ 748 Millionen TVL, größte reine zkEVM
  • StarkNet: $ 826 Millionen TVS
  • zkSync Era: $ 569 Millionen TVL, 270+ bereitgestellte dApps
  • Linea: ~ $ 963 Millionen TVS, 400 % + Wachstum bei täglich aktiven Adressen

Das gesamte Layer-2-Ökosystem hat ein TVL von 70 Milliarden US-Dollar erreicht, wobei ZK-Rollups zunehmend Marktanteile gewinnen, da die Beweiskosten (Proving Costs) weiter sinken.

Signale für die Entwickler-Adoption​

  • Über 65 % der neuen Smart Contracts im Jahr 2025 wurden auf Layer-2-Netzwerken bereitgestellt
  • zkSync Era zog etwa $ 1,9 Milliarden an tokenisierten Real-World-Assets (RWA) an und sicherte sich damit ~ 25 % des On-Chain-RWA-Marktanteils
  • Layer-2-Netzwerke verarbeiteten im Jahr 2025 schätzungsweise 1,9 Millionen tägliche Transaktionen

Das Abwägen zwischen Kompatibilität und Performance in der Praxis​

Das Verständnis der theoretischen Typen ist nützlich, aber entscheidend sind die praktischen Auswirkungen für Entwickler.

Typ 1-2: Keine Migrationsreibung​

Für Scroll und Linea (Typ 2) bedeutet Migration buchstäblich null Codeänderungen für die meisten Anwendungen. Stellen Sie denselben Solidity-Bytecode bereit, verwenden Sie dieselben Tools (MetaMask, Hardhat, Remix) und erwarten Sie dasselbe Verhalten.

Bestens geeignet für: Bestehende Ethereum-Anwendungen, die eine nahtlose Migration priorisieren; Projekte, bei denen bewährter, geprüfter Code unverändert bleiben muss; Teams ohne Ressourcen für umfangreiche Tests und Modifikationen.

Typ 3: Sorgfältige Tests erforderlich​

Für Polygon zkEVM und ähnliche Typ-3-Implementierungen funktionieren die meisten Anwendungen, aber es existieren Edge-Cases. Bestimmte Precompiles verhalten sich möglicherweise anders oder werden nicht unterstützt.

Bestens geeignet für: Teams mit Ressourcen für eine gründliche Testnet-Validierung; Projekte, die nicht auf exotische EVM-Funktionen angewiesen sind; Anwendungen, die Kosteneffizienz über perfekte Kompatibilität stellen.

Typ 4: Ein anderes mentales Modell​

Für zkSync Era und StarkNet unterscheidet sich die Entwicklungserfahrung deutlich von Ethereum:

zkSync Era unterstützt Solidity, transpiliert es jedoch in einen benutzerdefinierten Bytecode. Verträge lassen sich kompilieren und ausführen, aber das Verhalten kann in feinen Details abweichen. Es gibt keine Garantie, dass Adressen mit Ethereum-Bereitstellungen übereinstimmen.

StarkNet verwendet Cairo, was von Entwicklern verlangt, eine völlig neue Sprache zu lernen – allerdings eine, die speziell für beweisbare Berechnungen (provable computation) entwickelt wurde.

Bestens geeignet für: Greenfield-Projekte, die nicht durch bestehenden Code eingeschränkt sind; Anwendungen, bei denen maximale Performance die Investition in Tooling rechtfertigt; Teams, die bereit sind, in spezialisierte Entwicklung und Tests zu investieren.

Sicherheit: Die unverhandelbare Einschränkung​

Die Ethereum Foundation führte 2025 klare kryptografische Sicherheitsanforderungen für zkEVM-Entwickler ein:

  • 100-Bit beweisbare Sicherheit bis Mai 2026
  • 128-Bit Sicherheit bis Ende 2026

Diese Anforderungen spiegeln die Realität wider, dass schnellere Beweise nichts bedeuten, wenn die zugrunde liegende Kryptografie nicht absolut sicher ist. Von den Teams wird erwartet, dass sie diese Schwellenwerte unabhängig von ihrer Typ-Klassifizierung erreichen.

Der Fokus auf Sicherheit hat einige Performance-Verbesserungen verlangsamt – die Ethereum Foundation hat sich bis 2026 explizit für Sicherheit vor Geschwindigkeit entschieden –, stellt aber sicher, dass das Fundament für die Massenadoption solide bleibt.

Die Wahl Ihrer zkEVM: Ein Entscheidungsrahmen​

Wählen Sie Typ 1-2 (Taiko, Scroll, Linea), wenn:​

  • Sie bestehende, kampferprobte Verträge migrieren
  • Audit-Kosten ein Faktor sind (keine erneute Prüfung erforderlich)
  • Ihr Team Ethereum-nativ ist und keine ZK-Expertise besitzt
  • Die Composability mit Ethereum L1 wichtig ist
  • Sie synchrone Interoperabilität mit anderen Based Rollups benötigen

Wählen Sie Typ 3 (Polygon zkEVM), wenn:​

  • Sie ein Gleichgewicht zwischen Kompatibilität und Performance suchen
  • Sie in eine gründliche Testnet-Validierung investieren können
  • Kosteneffizienz eine Priorität ist
  • Sie nicht auf exotische EVM-Precompiles angewiesen sind

Wählen Sie Typ 4 (zkSync Era, StarkNet), wenn:​

  • Sie neu bauen, ohne Einschränkungen durch Migration
  • Maximale Performance die Investition in Tools rechtfertigt
  • Ihr Anwendungsfall von ZK-nativen Designmustern profitiert
  • Sie über Ressourcen für spezialisierte Entwicklung verfügen

Was als Nächstes kommt​

Die Typ-Klassifizierungen werden nicht statisch bleiben. Vitalik bemerkte, dass zkEVM-Projekte „leicht bei Typen mit höheren Nummern beginnen und im Laufe der Zeit zu Typen mit niedrigeren Nummern springen“ können. Wir sehen dies in der Praxis – Projekte, die als Typ 3 starteten, entwickeln sich in Richtung Typ 2, während sie die Implementierung von Precompiles vervollständigen.

Noch interessanter ist: Sollte Ethereum L1 Modifikationen vornehmen, um ZK-freundlicher zu werden, könnten Typ-2- und Typ-3-Implementierungen zu Typ 1 werden, ohne ihren eigenen Code zu ändern.

Das Endziel scheint zunehmend klar: Die Beweiszeiten werden weiter sinken, die Kosten werden weiter fallen und die Unterscheidung zwischen den Typen wird verschwimmen, da Hardware-Beschleunigung und algorithmische Verbesserungen die Performance-Lücke schließen. Die Frage ist nicht, welcher Typ gewinnen wird – sondern wie schnell das gesamte Spektrum zu einer praktischen Äquivalenz konvergiert.

Vorerst bleibt der Rahmen wertvoll. Zu wissen, wo eine zkEVM im Kompatibilitäts-Performance-Spektrum steht, sagt Ihnen, was Sie während der Entwicklung, Bereitstellung und des Betriebs zu erwarten haben. Dieses Wissen ist für jedes Team unerlässlich, das an der ZK-gestützten Zukunft von Ethereum baut.

Bauen Sie auf einer zkEVM-Infrastruktur? BlockEden.xyz bietet hochperformante RPC-Endpunkte über mehrere zkEVM-Chains hinweg, darunter Polygon zkEVM, Scroll und Linea. Erkunden Sie unseren API-Marktplatz, um auf die Infrastrukturschicht zuzugreifen, die Ihre ZK-Anwendungen benötigen.

Share on Twitter