Polygon zkEVM erklärt – Zero-Knowledge-Rollup für Ethereum

Ethereum ist beliebt, aber im Alltag oft teuer und langsam, sobald viele Menschen gleichzeitig Transaktionen senden. Genau hier setzen Rollups an: Sie verlagern einen Großteil der Ausführung in eine zweite Ebene und nutzen Ethereum weiterhin als Sicherheitsanker. Polygon zkEVM ist ein solcher Ansatz, der zusätzlich auf Zero-Knowledge-Beweise setzt. Das Ziel: Ethereum-kompatible Apps (EVM) mit deutlich mehr Durchsatz – ohne die Sicherheit von Ethereum komplett neu erfinden zu müssen.

Warum Rollups gebraucht werden: Ausführung vs. Absicherung

Bei Ethereum passieren zwei Dinge im selben System: Transaktionen werden ausgeführt (Smart Contracts rechnen Zustände aus), und das Ergebnis wird abgesichert (Konsens und Datenverfügbarkeit sorgen dafür, dass alle denselben Zustand akzeptieren). Das ist robust, skaliert aber nur begrenzt, weil jede Node sehr viel Arbeit wiederholen muss.

Rollups trennen diese Aufgaben:

• Die Ausführung läuft überwiegend außerhalb von Ethereum (auf Layer 2).
• Ethereum bleibt die Instanz, die Ergebnisse finalisiert und Streitfälle verhindert.

Damit das sicher ist, muss ein Rollup nachweisen können, dass sein Zustand korrekt aus den eingereichten Transaktionen abgeleitet wurde. Bei zk-Rollups passiert das über kryptografische Beweise.

Wie Polygon zkEVM technisch funktioniert

Polygon zkEVM gehört zur Familie der zk-Rollups. „zk“ steht für Zero Knowledge: Eine Partei kann beweisen, dass eine Rechnung korrekt ist, ohne alle Rechenschritte offenlegen zu müssen. Für Rollups ist das praktisch, weil Ethereum nicht jede einzelne Transaktion nachrechnen muss.

Transaktionen bündeln und als Batch verarbeiten

Statt jede Transaktion einzeln auf Ethereum zu schreiben, sammelt ein Betreiber (häufig „Sequencer“ genannt) viele Transaktionen und ordnet sie zu einem Batch. Innerhalb dieses Batches werden Smart-Contract-Aufrufe wie auf Ethereum ausgeführt: Kontostände ändern sich, NFTs werden transferiert, DeFi-Positionen aktualisieren sich.

Wichtig: Der Batch verändert den Layer-2-Zustand (State). Entscheidend ist, dass dieser neue Zustand später gegenüber Ethereum als korrekt belegt wird.

Der kryptografische Beweis: Zero-Knowledge-Proof

Für jeden Batch wird ein Beweis erzeugt, der bestätigt: „Wenn man mit dem alten Zustand startet und diese Transaktionen ausführt, kommt genau dieser neue Zustand heraus.“ Dieser Zero-Knowledge-Proof wird zusammen mit kompakten Daten auf Ethereum veröffentlicht. Ethereum muss dann nur noch den Beweis verifizieren – das ist viel günstiger als jede Ausführung nachzubauen.

Alltagsbild: Statt einen kompletten Taschenrechner-Verlauf vorzulegen, liefert man eine Quittung, die kryptografisch garantiert, dass das Ergebnis stimmt.

Was „EVM-kompatibel“ hier bedeutet

Viele Entwickler:innen kennen die Ethereum Virtual Machine (EVM) als Laufzeitumgebung für Smart Contracts. „zkEVM“ meint, dass die Umgebung so nah an der EVM ist, dass bestehende Tools und Solidity-Verträge mit wenig Reibung funktionieren. In der Praxis kann es trotzdem Unterschiede geben (z. B. bei sehr speziellen Opcodes, Precompiles oder Edge-Cases), weshalb Projekte vor dem Mainnet-Einsatz Tests einplanen sollten.

Die wichtigsten Bausteine in der Architektur

Ein zkEVM-System besteht nicht nur aus „Rollup + Beweis“. Mehrere Komponenten greifen ineinander, damit Nutzer:innen Transaktionen senden können, Apps zuverlässig laufen und Ethereum am Ende die Sicherheit liefert.

Sequencer: Reihenfolge und schnelle Bestätigungen

Der Sequencer nimmt Transaktionen an, sortiert sie und gibt schnelle Rückmeldungen (oft „soft confirmations“). Diese Bestätigungen sind praktisch für UX, aber sie sind nicht dasselbe wie eine endgültige Finalität auf Ethereum. Endgültig wird ein Batch erst, wenn der Beweis auf Ethereum akzeptiert wurde.

Prover: Rechenarbeit für die Beweiserstellung

Die Beweiserstellung ist rechenintensiv. Der Prover berechnet aus Ausführungsspuren einen Beweis, den Ethereum später prüfen kann. Weil dieser Schritt teuer ist, arbeiten zk-Rollups oft mit optimierten Schaltkreisen (Circuits) und spezieller Infrastruktur, um Proofs schnell und zuverlässig zu erzeugen.

Smart Contracts auf Ethereum: Brücke, Verifikation, Zustandsanker

Auf Ethereum liegen Verträge, die typischerweise drei Aufgaben abdecken:

• Proof-Verifikation: Prüfen, ob der gelieferte Beweis gültig ist.
• Zustandsverwaltung: Speichern, welcher Layer-2-State aktuell als final gilt.
• Bridging: Ein- und Auszahlungen zwischen Ethereum und dem Rollup ermöglichen.

Damit bleibt Ethereum der Ort, an dem letztlich feststeht, welcher Layer-2-Zustand „wahr“ ist.

Einzahlungen, Auszahlungen und die Rolle der Datenverfügbarkeit

Rollups sind nur dann sicher, wenn Nutzer:innen ihre Guthaben notfalls unabhängig vom Betreiber bewegen können. Dafür sind zwei Dinge entscheidend: Bridging-Logik und Datenverfügbarkeit.

Bridge-Ablauf: von Ethereum nach zkEVM und zurück

Bei einer Einzahlung werden Token in einem Ethereum-Vertrag gesperrt und auf Layer 2 entsprechend gutgeschrieben. Bei einer Auszahlung wird umgekehrt nachgewiesen, dass auf Layer 2 ein Anspruch entstanden ist, und der Ethereum-Vertrag gibt die Token frei.

Der entscheidende Vorteil bei zk-Rollups: Auszahlungen müssen nicht auf eine Betrugsfrist warten (wie bei Optimistic Rollups), sondern können nach Proof-Finalisierung möglich werden. In der Praxis hängen die genauen Zeiten dennoch von der Batch- und Proof-Frequenz ab.

Warum Datenverfügbarkeit mehr ist als „Daten posten“

Damit jede Person den Layer-2-Zustand rekonstruieren kann, müssen die notwendigen Transaktionsdaten verfügbar sein. Bei Rollups ist die Idee: Die Daten (oder zumindest die für die Rekonstruktion nötigen Teile) werden auf Ethereum veröffentlicht, sodass ein unabhängiger Nachbau möglich bleibt. Das schützt vor dem Worst-Case, dass ein Betreiber verschwindet oder zensiert.

Merksatz: Ein Beweis sagt „korrekt“, Datenverfügbarkeit sorgt dafür, dass man es selbst überprüfen und fortsetzen könnte.

Wofür eignet sich Polygon zkEVM im Web3-Alltag?

Der Nutzen entsteht vor allem dort, wo viele Transaktionen anfallen oder Interaktionen häufig sind. Typische Beispiele:

• Smart Contracts für DeFi-Workflows mit vielen Einzelschritten (Swaps, Collateral-Management, Rebalancing).
• On-chain Games, bei denen viele kleine Aktionen stattfinden.
• NFT-Anwendungen, bei denen Minting und Transfers günstig bleiben sollen.
• Web3-Apps, die Ethereum-Tools nutzen wollen, aber die Kosten senken müssen.

Wer grundsätzlich verstehen will, warum externe Datenquellen für Verträge wichtig sind, hilft auch der Blick auf Oracles, etwa im Artikel Chainlink Oracles verstehen – Datenbrücke für Smart Contracts.

Ein technischer Ablauf in 7 Schritten (vom Klick bis zur Finalität)

Der folgende Ablauf hilft, die Stationen einer typischen Interaktion einzuordnen – unabhängig davon, welche Wallet oder dApp genutzt wird:

• Eine Wallet signiert eine Transaktion und sendet sie an den Sequencer.
• Der Sequencer nimmt die Transaktion an und ordnet sie in eine Reihenfolge ein.
• Der Batch wird auf Layer 2 ausgeführt; der neue Zustand entsteht.
• Ein Prover erzeugt einen Beweis über die korrekte Ausführung des Batches.
• Der Batch (und die nötigen Daten) sowie der Beweis werden an Ethereum übermittelt.
• Ethereum verifiziert den Beweis und akzeptiert den neuen Layer-2-State als final.
• Bridging-Aktionen (z. B. Auszahlungen) können auf Basis dieser Finalität abgewickelt werden.

Wichtige Unterschiede zu Optimistic Rollups und Sidechains

Viele verwechseln L2-Rollups mit Sidechains. Das ist verständlich, aber technisch relevant: Sidechains sichern sich meist mit eigenem Konsens ab. Rollups erben Sicherheit von Ethereum, weil Ethereum die Zustandsübergänge absichert.

zk-Rollup vs. Optimistic Rollup

Optimistic Rollups gehen zunächst davon aus, dass Batches korrekt sind („optimistisch“) und geben Zeit für Einsprüche. zk-Rollups liefern stattdessen direkt einen gültigen Beweis. Daraus ergeben sich typische Trade-offs:

• zk: Schnellere kryptografische Finalität nach Proof, dafür komplexe Proof-Infrastruktur.
• Optimistic: Einfachere Ausführung, dafür potenziell längere Auszahlungswege wegen Challenge-Period.

zkEVM vs. eigene VM

Manche L2s setzen auf eigene virtuelle Maschinen statt EVM-Nähe. zkEVM priorisiert Kompatibilität zu Ethereum-Tooling. Das kann Migration vereinfachen, zwingt aber dazu, die EVM-Logik „beweisbar“ nachzubilden – eine anspruchsvolle Ingenieursaufgabe.

Grenzen und typische Stolpersteine in der Praxis

Auch wenn zkEVM viel verspricht, bleiben praktische Punkte, die Nutzer:innen und Entwickler:innen kennen sollten:

Zentralisierungspunkte am Anfang

Viele Rollups starten mit einem eher zentralen Sequencer oder Prover-Setup, um Stabilität zu gewährleisten. Das ist nicht automatisch unsicher, aber es bedeutet: Zensurresistenz und Ausfallsicherheit hängen an der Betriebsarchitektur und deren Weiterentwicklung (z. B. Multi-Sequencer-Ansätze).

Kompatibilität ist selten „100%“

EVM-Kompatibilität reduziert Reibung, ersetzt aber keine Tests. Manche Anwendungen nutzen Randbereiche (z. B. Gas-Mikrooptimierungen, spezielle Precompiles, Low-Level-Calls), die auf zkEVM anders wirken können. Gute Praxis ist, kritische Verträge zuerst in Testumgebungen laufen zu lassen und Monitoring einzuplanen.

Gebührenmodell: nicht nur „billiger“

Gebühren setzen sich oft aus mehreren Teilen zusammen: Ausführung auf Layer 2, Datenkosten auf Ethereum und anteilige Proof-Kosten. Für Nutzer:innen erscheint das als eine Zahl, technisch sind es aber verschiedene Kostenblöcke. Das erklärt auch, warum Gebühren je nach Netzlast auf Ethereum schwanken können, selbst wenn Layer 2 stabil läuft.

Kurze Einordnung im Ethereum-Ökosystem

Ethereum verfolgt seit Jahren eine klare Richtung: Skalierung über Layer 2. zkEVM-Ansätze passen dazu, weil sie die Sicherheit von Ethereum nutzen und gleichzeitig die Ausführung auslagern. Für den Alltag bedeutet das: Viele Anwendungen können günstiger werden, ohne komplett auf neue Sicherheitsannahmen umzustellen.

Wer sich beim Nutzen von L2s orientieren möchte, sollte vor allem auf drei Dinge achten: Wie werden Daten veröffentlicht, wie transparent ist der Sequencer-Betrieb und wie gut sind Bridge-Mechanismen dokumentiert. Genau diese technischen Details entscheiden darüber, wie robust ein System im Ernstfall ist.

Quellen

• Offizielle Projekt-Dokumentation und Entwicklerressourcen von Polygon zkEVM
• Allgemeine Ethereum-Rollup-Grundlagen (Layer-2-Architektur, Datenverfügbarkeit, Proof-Verifikation)