Ethereum L2 Starknet – STARK-Rollups und Cairo im Stack

Wer Anwendungen auf Ethereum baut, trifft schnell auf zwei Grenzen: begrenzte Blockkapazität und damit verbundene Gebühren. Layer-2-Netzwerke verlagern Berechnungen und Datenverarbeitung aus dem L1 heraus, ohne die Sicherheitsbasis von Ethereum aufzugeben. Starknet setzt dafür auf zk-Rollups mit STARK-Beweisen und einer eigenen Ausführungsumgebung rund um Cairo.

Der technische Kern: Transaktionen werden außerhalb von Ethereum ausgeführt, anschließend wird ein Beweis erzeugt, der die Korrektheit der Zustandsänderung zeigt. Ethereum muss dann nicht jede einzelne Ausführung nachrechnen, sondern verifiziert den Beweis und übernimmt das Ergebnis. Das verändert Performance, Kostenstruktur und auch das Entwickler-Erlebnis – inklusive neuer Werkzeuge, neuer Debugging-Pfade und anderer Angriffsflächen.

Wofür Starknet im Ethereum-Stack gedacht ist

Warum „Rechnen off-chain, verifizieren on-chain“ so viel bewirkt

Ethereum ist bewusst konservativ: Jede Ausführung muss deterministisch auf vielen Nodes laufen. Das schützt die Integrität, bremst aber Durchsatz und macht komplexe Logik teuer. Starknet verschiebt die teure Arbeit in ein L2-Netzwerk: Sequencing, Ausführung, State-Updates und Beweiserzeugung passieren dort. Auf Ethereum landet anschließend ein komprimierter Nachweis plus die minimal nötigen Daten, damit das L1 den neuen Zustand akzeptieren kann.

Das Prinzip ähnelt einer Buchhaltung: Einzelne Belege bleiben im Nebenbuch (L2), aber das Hauptbuch (L1) bekommt eine mathematisch abgesicherte Zusammenfassung, die sich prüfen lässt. Für viele Anwendungen ist das der entscheidende Hebel: mehr Interaktionen pro Zeit, weniger Kosten pro Interaktion, ohne eine eigene Sicherheitsannahme wie bei klassischen Sidechains.

Abgrenzung zu Optimistic Rollups

Optimistic Rollups (z. B. im Kontext von Arbitrum und Nitro) veröffentlichen typischerweise Ausführungsdaten und setzen auf eine Challenge-Phase: Ergebnisse gelten „optimistisch“, bis ein Betrugsnachweis kommt. Starknet gehört zur Familie der Validity Rollups: Ein gültiger kryptografischer Beweis macht eine Challenge-Phase für die Korrektheit der Ausführung prinzipiell überflüssig. Das hat Auswirkungen auf Auszahlungszeiten, Komplexität der Verifikation und die Engineering-Aufgaben rund um Prover/Verifier.

Wie Starknet als STARK-Rollup technisch aufgebaut ist

Komponenten: Sequencer, Prover, Verifier

Ein Rollup besteht praktisch aus drei Rollen, die in Implementierungen auch auf mehrere Systeme verteilt sein können:

• Sequencer: nimmt Transaktionen an, ordnet sie, erzeugt Batches und stellt eine zeitnahe „UX-Sicht“ auf den aktuellen L2-Zustand bereit.
• Prover: erzeugt aus Ausführungstraces kryptografische Beweise (STARKs), die die korrekte Ausführung der Batch-Transition belegen.
• Verifier (auf Ethereum): prüft Beweise und akzeptiert State-Updates, wenn der Beweis gültig ist.

Wichtig für die Praxis: Die L2-„Finalität“ aus Sicht der Nutzeroberfläche (Sequencer bestätigt) ist nicht identisch mit der L1-Finalität (Beweis verifiziert und State-Update auf Ethereum). Anwendungen sollten daher sauber zwischen „soft confirmation“ und „L1 settled“ unterscheiden, etwa bei Auszahlungen oder kreditbasierten Workflows.

Was STARKs in diesem Kontext leisten

STARKs (Scalable Transparent ARguments of Knowledge) sind Zero-Knowledge-Beweise, die ohne „trusted setup“ auskommen und für sehr große Rechenlasten skaliert werden können. Im Rollup-Kontext beweisen sie: „Dieser neue State-Root ist das Ergebnis der korrekten Ausführung dieser Transaktionsliste auf dem vorherigen State-Root.“ Die Verifikation auf Ethereum ist vergleichsweise günstig, während das Erzeugen des Beweises rechenintensiv ist und spezialisierte Infrastruktur erfordert.

Für Architekturen heißt das: Kosten werden vom L1 weg in Richtung Proving verschoben. Betreiber- und Ökosystem-Design müssen also sicherstellen, dass Proving-Kapazität zuverlässig verfügbar bleibt und dass das System auch bei Lastspitzen stabil batchen und beweisen kann.

Cairo und die Ausführungsumgebung: Was Entwickler wissen müssen

Warum eine eigene VM statt EVM-Identität

Starknet setzt auf Cairo als Programmiersprache und Ausführungsmodell, weil Beweise effizienter werden, wenn die Ausführung „proof-friendly“ strukturiert ist. Die EVM ist historisch gewachsen und nicht primär dafür entworfen, in ZK-Beweisen effizient abgebildet zu werden. Cairo und die zugehörige VM sind darauf ausgelegt, Ausführungstraces zu erzeugen, die gut in STARK-Proofs passen.

Das ist ein klarer Trade-off: maximale ZK-Effizienz gegen unmittelbare EVM-Kompatibilität. Für Teams bedeutet das, dass Smart-Contract-Code nicht einfach 1:1 von Solidity übernommen wird. Designentscheidungen – etwa Storage-Strukturen, Hashing, Signaturen oder Event-Logik – sollten von Beginn an auf die Zielumgebung abgestimmt sein.

Account-Abstraktion als Standardmodell

Starknet nutzt ein Account-Modell, in dem Accounts selbst Smart Contracts sind. Dadurch wird Account-Abstraktion nicht als „Add-on“, sondern als Grundprinzip genutzt. Praktisch eröffnet das Funktionen wie:

• flexible Signaturverfahren (z. B. Multisig, Hardware-Wallet-Policies, Social Recovery),
• Batching mehrerer Aktionen in einer User-Operation,
• Paymaster-Modelle (Gebühren durch Dritte) als Anwendungsfall, je nach Wallet/Protokoll-Design.

Für Produktteams ist das besonders relevant: Wallet-UX und Sicherheitskonzepte lassen sich oft stärker an die Anwendung anpassen als im klassischen EOA-Modell (externally owned accounts) der EVM-Welt.

Datenverfügbarkeit, State und Brücken: Sicherheitsannahmen richtig lesen

Welche Daten Ethereum sehen muss

Ein Rollup ist nur dann „ein Rollup“ im strengen Sinn, wenn genügend Daten auf dem L1 verfügbar sind, damit Dritte den L2-Zustand rekonstruieren können (Datenverfügbarkeit). In der Praxis werden dafür Zustandsänderungen und/oder Transaktionsdaten in komprimierter Form auf Ethereum veröffentlicht. Je weniger Daten auf L1 landen, desto günstiger wird es – aber desto größer wird das Risiko, dass unabhängige Rekonstruktion erschwert wird.

Wer L2s bewertet, sollte deshalb immer fragen: Welche Daten sind on-chain verfügbar, welche nur off-chain? Und welche Mechanismen existieren, falls ein Sequencer ausfällt oder sich bösartig verhält? Als ergänzende Perspektive lohnt der Blick auf modulare Ansätze wie Datenverfügbarkeitsschichten, weil sie genau diese Frage zum eigenständigen Modul machen.

Bridging: L1↔L2 ist mehr als „Token hin und her“

Brücken sind sicherheitskritische Systeme: Sie definieren, wann ein L2-Deposit auf L1 als gedeckt gilt und wann eine Auszahlung als final gilt. Bei Validity Rollups hängt die Auszahlungsfinalität an der Beweisverifikation auf Ethereum. Anwendungen sollten Bridging-Prozesse so modellieren, dass sie L1-Finalität abwarten, wenn wirtschaftliche Sicherheit nötig ist (z. B. bei großen Auszahlungen oder Kredit-Settlement).

Transaktionsfluss in Starknet: von der Signatur bis zum Proof

Ablauf in verständlichen Schritten

Ein typischer Flow lässt sich als Pipeline beschreiben:

• Wallet erstellt eine signierte L2-Transaktion (bei Contract-Accounts entscheidet die Account-Logik, was „gültig signiert“ bedeutet).
• Sequencer nimmt die Transaktion an, führt sie gegen den aktuellen L2-State aus und gibt eine schnelle Bestätigung zurück.
• Mehrere Transaktionen werden zu einem Batch zusammengefasst; daraus entsteht ein Ausführungstrace.
• Prover erzeugt einen STARK-Beweis über die korrekte State-Transition.
• Der Verifier-Contract auf Ethereum prüft den Beweis und akzeptiert den neuen State-Root; damit ist der Batch auf L1 abgesichert.

Für Entwickler ist besonders wichtig, wo Fehler auftreten können: in der Account-Validierung (Signatur/Nonce), in der Ausführung (Reverts/Assertions), im Sequencer-Mempool (Ordering/Fees) oder in der L1-Settlement-Phase (Batch-Verzögerungen). Monitoring sollte deshalb sowohl L2-Events als auch den L1-Verifier berücksichtigen.

Wann Starknet sinnvoll ist – und wann nicht

Vergleichsbox: typische Stärken und Grenzen

Praktische Einordnung im L2-Ökosystem

Starknet ist besonders interessant für Anwendungen, die viele Zustandsübergänge pro Nutzeraktion haben (z. B. On-chain-Games, komplexe DeFi-Strategien, Orderbuch-nahe Logik oder Identitäts-/Reputation-Module), weil genau dort ZK-basierte Verifikation ihr Profil ausspielt. Wer dagegen maximale EVM-Nähe, vorhandene Solidity-Codebases und sofortige Tooling-Kompatibilität priorisiert, wird häufig zuerst bei EVM-nahen Rollups evaluieren.

Als Architektur-Referenz hilft ein Blick auf alternative Skalierungs- und Modulsysteme: Subnet-Architekturen lösen Skalierung anders (eigene Ausführungsumgebungen), während Shared-Security-Modelle die Sicherheits- und Ausführungsdomäne anders verteilen. Starknet bleibt dabei klar im Ethereum-Rollup-Paradigma.

Konkrete Schritte für Teams, die Starknet evaluieren

So lässt sich ein Proof-of-Concept sauber aufsetzen

• Ziel definieren: Welche Teile der App sind kostenintensiv auf L1 (z. B. viele State-Writes, komplexe Berechnungen)?
• Domänenlogik isolieren: Kernlogik in ein Modul schneiden, das sich als Cairo-Contract abbilden lässt.
• Account- und Signaturmodell früh festlegen: Welche Policies sollen Accounts erzwingen (Multisig, Limits, Recovery)?
• Daten- und Event-Strategie planen: Welche Events braucht Indexing, welche Daten müssen für Audits nachvollziehbar bleiben?
• Settlement-Strategie designen: Welche Aktionen dürfen auf Sequencer-Bestätigung passieren, welche erst nach L1-Settlement?
• Observability bauen: Metriken für L2-Ausführung, Batch-Status und L1-Verifier-Updates kombinieren.

Ein hilfreicher Tipp aus der Praxis: Bei L2-Integrationen entstehen viele Fehler nicht in der Kryptografie, sondern in Zustandsannahmen. Wer in der Applikation konsequent zwischen „angenommen“, „ausgeführt“ und „auf L1 gesettled“ unterscheidet, vermeidet inkonsistente UI-Zustände und riskante Business-Logik.

Typische Missverständnisse bei ZK-Rollups

„Zero Knowledge“ bedeutet nicht automatisch „keine Daten on-chain“

Zero-Knowledge beschreibt eine Eigenschaft des Beweises (Wissen über Korrektheit ohne Offenlegung bestimmter Details). Für Rollups bleibt Datenverfügbarkeit ein separates Thema. Auch bei ZK-Rollups müssen genügend Daten so veröffentlicht werden, dass der Zustand rekonstruierbar ist. Verwechslungen dieser Ebenen führen oft zu falschen Annahmen über Sicherheitsmodelle.

„ZK“ ersetzt kein Security-Engineering

Ein gültiger Beweis schützt vor falscher Ausführung, aber nicht vor allen Risiken: fehlerhafte Contract-Logik, unsichere Upgrades, schwache Account-Policies, Bridge-Designfehler, MEV/Ordering-Probleme oder zentrale Infrastruktur-Bottlenecks bleiben echte Themen. Starknet reduziert eine Klasse von Risiken (falsche State-Transition ohne Nachweis), aber ein solides Threat-Modeling bleibt Pflicht.