Scroll – zkEVM-Rollup mit rekursiven Proofs im Detail

Wenn eine dApp auf Ethereum sicher laufen soll, aber im Alltag an Gebühren und Durchsatz scheitert, landet die Architekturfrage schnell bei Rollups. Scroll gehört zur Klasse der Zero-Knowledge-Rollups, die EVM-Transaktionen außerhalb von Ethereum ausführen und anschließend kryptografisch beweisen. Ziel ist Kompatibilität: bestehende Solidity-Contracts und Tooling sollen mit minimalen Änderungen funktionieren.

Technisch interessant ist dabei weniger ein „neues“ Ausführungsmodell, sondern die Frage, wie die EVM selbst in einen beweisbaren Rechenprozess überführt wird. Genau hier setzt Scroll an: mit einer zkEVM, die EVM-Bytecode in ZK-Schaltkreisen (Circuits) abbildet und daraus Beweise (Proofs) für korrektes State-Transitioning erzeugt.

Was Scroll im Rollup-Stack eigentlich löst

Warum ZK-Rollups anders absichern als Optimistic Rollups

Bei Optimistic Rollups gilt: Transaktionen werden „optimistisch“ akzeptiert, solange niemand innerhalb eines Zeitfensters (Challenge-Period) widerspricht. ZK-Rollups drehen das Prinzip um: Ein Batch gilt erst dann als final korrekt, wenn ein gültiger Beweis vorliegt, der die Ausführung bestätigt. Damit verschiebt sich der Sicherheitsnachweis von „Betrug finden“ zu „Korrektheit beweisen“.

In der Praxis bedeutet das: weniger Abhängigkeit von Watchern, kürzere Withdrawal-Pfade (abhängig vom Bridge-Design) und ein anderer Engineering-Schwerpunkt: Circuits, Prover-Performance und zuverlässige Datenverfügbarkeit.

Kompatibilität als Produktentscheidung

Scroll setzt auf EVM-Nähe, damit bestehende Anwendungen mit vertrauten Libraries, Wallets und RPC-Methoden laufen. Diese Nähe ist kein Marketingdetail, sondern beeinflusst die gesamte Architektur: Je genauer die EVM nachgebildet wird, desto komplexer wird die Beweislogik. Gleichzeitig sinkt der Migrationsaufwand für Teams.

Architekturüberblick: Komponenten und Verantwortlichkeiten

Sequencer, Batch-Builder und die Rolle des L1

Ein typischer Scroll-Transaktionspfad startet beim Sequencer. Er nimmt Nutzertransaktionen entgegen, ordnet sie, führt sie in der L2-EVM aus und erzeugt daraus L2-Blöcke. Mehrere Blöcke werden zu Batches zusammengefasst, die später auf Ethereum referenziert werden.

Ethereum (L1) dient dabei als Verankerung: Es speichert die für die Verifikation nötigen Daten/Commitments und verifiziert die Beweise über Smart Contracts. Dieses „Anker“-Prinzip entspricht dem üblichen Rollup-Modell: Ausführung off-chain, Sicherheit und finaler Konsens on-chain.

Prover und Verifier: Beweise statt Vertrauen

Der Prover erzeugt aus der EVM-Ausführung und den dazugehörigen Witness-Daten einen Zero-Knowledge-Beweis. Der Verifier ist ein Smart Contract auf Ethereum, der diesen Beweis prüft. Wichtig: Der Verifier prüft nicht „alle Rechenschritte“, sondern bestätigt mathematisch, dass die Ausführung genau den Regeln der zkEVM-Circuits folgte.

Damit wird ein Batch für Ethereum akzeptabel, ohne dass Ethereum selbst jede Transaktion erneut ausführen muss.

Datenverfügbarkeit und warum sie nicht „nur Storage“ ist

Ein Rollup braucht für Sicherheit nicht nur korrekte Ausführung, sondern auch die Fähigkeit, den L2-State aus veröffentlichten Daten zu rekonstruieren. Je nach Design werden dafür Transaktionsdaten (oder komprimierte Repräsentationen) auf L1 veröffentlicht. Ohne ausreichende Datenverfügbarkeit könnten Nutzer den aktuellen State nicht mehr nachbilden, selbst wenn Beweise korrekt sind.

Wer das größere Bild einordnen will, findet bei Datenverfügbarkeit als Basis für Rollups eine passende Vertiefung zu DA-Schichten und ihren Trade-offs.

Wie Scroll eine EVM-Ausführung beweisbar macht

Vom Bytecode zum Circuit: Was in einer zkEVM modelliert wird

Eine EVM-Transaktion verändert den State: Konten, Nonces, Balances, Storage-Slots, Logs. Eine zkEVM muss diese Regeln so modellieren, dass sie in ZK-Circuits überprüfbar sind. Dazu gehören unter anderem:

• Opcode-Semantik (z. B. ADD, SSTORE, CALL) als Constraints im Circuit
• Gas-Regeln und Abbruchbedingungen (Out-of-Gas)
• Speicher- und Stack-Übergänge pro Schritt
• State-Zugriffe (Account/Storage) über geeignete Merkle-Strukturen

Das Ergebnis ist eine beweisbare State-Transition: aus einem „Pre-State-Root“ wird nach Anwendung eines Batches ein „Post-State-Root“ – inklusive Nachweis, dass jeder Schritt regelkonform war.

Rekursion: Warum Proofs oft in Proofs verschachtelt werden

Da ein Batch viele Transaktionen enthalten kann, wären einzelne Beweise pro Block/Chunk schnell zu groß und teuer zu verifizieren. Viele ZK-Rollups nutzen deshalb rekursive Proofs: Mehrere Teilbeweise werden zu einem aggregierten Beweis zusammengeführt. Rekursion reduziert Verifikationskosten auf L1 und stabilisiert die Pipeline, weil ein „finaler“ Proof nur noch ein kompaktes Objekt ist.

Der genaue Proof-System-Stack (z. B. konkrete Kurven, Commitment-Schemata) ist implementierungsabhängig; für das Verständnis reicht die technische Konsequenz: Rekursion verschiebt Aufwand in den Prover, entlastet aber Ethereum bei der Verifikation.

Transaktionslebenszyklus: von der Signatur bis zur Finalität

Schrittfolge im Alltag

Ein typischer Ablauf lässt sich als Kette beschreiben:

• Nutzer signiert eine Transaktion und sendet sie an einen L2-RPC/Sequencer.
• Sequencer ordnet Transaktionen und führt sie in der L2-EVM aus.
• Ausführung erzeugt neue L2-Blöcke; Batches werden gebildet.
• Prover erstellt Beweise über die Batch-Ausführung.
• Batch-Daten/Commitments und Proof werden an L1 übermittelt.
• L1-Verifier prüft den Proof; bei Erfolg wird der neue State-Root akzeptiert.

Für Nutzer ist vor allem relevant, dass es zwei „Finalitäten“ geben kann: eine schnelle, sequencerbasierte Bestätigung (für UX) und die strengere, beweisbasierte Finalität nach L1-Verifikation.

Bridging und Auszahlungslogik

Assets wandern typischerweise über eine Bridge zwischen Ethereum und Scroll. Technisch ist entscheidend, welche Daten als „Nachweis“ für L2-Ereignisse auf L1 akzeptiert werden. Bei ZK-Rollups stützt sich diese Akzeptanz auf die Beweise: Ein L2-Withdrawal wird auf L1 erst dann als gültig angesehen, wenn er Teil eines bewiesenen Zustandsübergangs ist.

Zur Einordnung, wie Rollups generell mit Ethereum interagieren, hilft auch der Blick auf Arbitrum und Optimistic Rollups, weil Unterschiede bei Challenge vs. Proof die Bridge-UX stark prägen.

Technische Eigenschaften und typische Trade-offs

Kompatibilität vs. Prover-Kosten

Je näher eine zkEVM an der „echten“ EVM bleibt, desto mehr Sonderfälle müssen in Circuits gegossen werden: Gas-Ecken, Precompiles, CALL-Varianten, Speicherexpansion. Das erhöht Entwicklungs- und Wartungskomplexität. Gleichzeitig wird es für Teams einfacher, vorhandene Smart Contracts wiederzuverwenden. Dieser Trade-off ist zentral für Scrolls Positionierung.

Zentralisierungsrisiken im Sequencing

In vielen L2-Designs ist der Sequencer anfangs ein klar definierter Operator. Das hat Vorteile: konsistente UX, schnelle Bestätigungen, Schutz vor bestimmten MEV- und DoS-Problemen durch kontrollierte Mempool-Politik. Es hat aber auch Nachteile: Zensurresistenz und Ausfallsicherheit hängen vom Sequencer-Setup ab. Moderne Rollups arbeiten daher oft an Plänen für mehr Dezentralisierung (z. B. mehrere Sequencer oder alternative Proposer-Modelle).

Für MEV-Mechanik und Ausführungsdetails ist auch der Vergleich mit Hochdurchsatzketten interessant, etwa Solanas paralleler Ausführung, selbst wenn das Sicherheitsmodell ein anderes ist.

Gebührenmodell: wofür in einem ZK-Rollup gezahlt wird

L2-Gebühren bestehen in der Regel aus zwei Komponenten: Kosten für L2-Ausführung (Compute, Storage, State-Access) und anteilige L1-Kosten (Datenveröffentlichung und Proof-Verifikation). Bei ZK-Rollups kommt hinzu, dass Proving-Rechenzeit eine echte Ressource ist. Deshalb ist das Gebührenmodell eng mit Kompression, Batch-Größe und Prover-Durchsatz verknüpft.

Übersicht als Entscheidungshilfe für Teams

Praktische Schritte für Deployment und Tests

Vorgehen für eine bestehende Ethereum-dApp

• RPC-Endpoint für Scroll in der Wallet/Toolchain konfigurieren (Chain-ID und Explorer passend setzen).
• Contracts mit demselben Solidity-Code kompilieren, aber Gas- und Fee-Parameter im Deployment-Skript an L2 anpassen.
• Abhängigkeiten prüfen: Oracle-Zugriff, Cross-Chain-Calls, L1-spezifische Annahmen (z. B. block.number/ timestamp) testen.
• Bridging-Flows im Testnetz simulieren: Einzahlen, Interaktion, Auszahlen.
• Monitoring ergänzen: Reorg-/Finalitätsannahmen dokumentieren, Events und Logs auf L2-Explorer gegenprüfen.

Ein kleiner Tipp aus der Praxis: Viele Probleme in der Migration sind keine „ZK-Probleme“, sondern Annahmen über L1-Blockzeiten, Gaslimits oder die Verfügbarkeit bestimmter Infrastruktur (Oracles, Indexer). Wer Oracles nutzt, sollte die Datenpipeline gezielt validieren; dafür kann ein Blick auf Pull-Oracles und Preisfeeds helfen, um Modelle und Latenzen sauber einzuordnen.

Grenzen und typische Missverständnisse

ZK bedeutet nicht automatisch „privat“

Zero-Knowledge-Technik kann Privatsphäre ermöglichen, aber ein ZK-Rollup für Skalierung veröffentlicht typischerweise Transaktionsdaten (oder ableitbare Informationen) so, dass State-Rekonstruktion möglich ist. Standard-Transfers und Contract-Calls sind daher nicht per se verborgen. Privacy erfordert zusätzliche Protokollschichten oder spezielle Transaktionsformate.

„Günstig“ ist relativ zu L1-Datenkosten

Auch wenn L2-Ausführung effizient ist, bleiben L1-Kosten für Daten ein struktureller Preisanker. Kompression und Batch-Strategien können viel optimieren, aber nicht alles eliminieren. Anwendungen mit sehr vielen Bytes pro Transaktion (z. B. umfangreiche Calldata) spüren diesen Effekt stärker.

Beweisfinalität ersetzt kein gutes UX-Design

Apps sollten klar zwischen schneller L2-Bestätigung und endgültiger L1-gesicherter Finalität unterscheiden. Das gilt besonders für Bridges, größere Beträge oder Protokollfunktionen, die von unwiderruflichen Zustandswechseln abhängen. Saubere Statusanzeigen, Retry-Logik und Timeouts sind Teil der „Rollup-Realität“.

Scroll positioniert sich als technisch konsequenter Weg, Ethereum-Apps mit hoher Code-Nähe in ein beweisgestütztes L2-Setup zu bringen. Der Kernnutzen entsteht dort, wo EVM-Ökosystem und ZK-Sicherheit zusammenkommen: bekannte Developer Experience plus mathematisch abgesicherte State-Transitions auf Ethereum.