World Chain liefert EIP-7928 vor Ethereum

Wer Validator-Infrastruktur auf einem stark ausgelasteten L2 betreibt, kennt den echten Engpass: nicht die EVM, sondern das sequenzielle Verifizieren eines Blocks nach seiner Zusammenstellung. Diese Einschränkung begrenzt den Durchsatz auf jeder OP-Stack-Chain im Produktionsbetrieb. World Chain hat jetzt eine Änderung ausgeliefert, die genau hier ansetzt – und das ohne einen Hard Fork.

Für Plattformverantwortliche, die in den nächsten 18 Monaten entscheiden, auf welchem L2 sie Zahlungsinfrastruktur aufbauen, ist dieses Deployment wichtiger als die Schlagzeile vermuten lässt. Es ist ein Live-Test einer Technologie, die Ethereum selbst noch nicht implementiert hat.

Das Problem

Validatoren auf Rollups warten heute. Sie warten, bis ein Block zusammengestellt ist, dann spielen sie ihn nach, dann verifizieren sie ihn. Der Durchsatz skaliert, indem Blöcke größer oder Maschinen schneller werden. Beide Wege verdrängen mit der Zeit Hobbyisten-Node-Betreiber und konzentrieren die Validierung bei jenen, die sich die größten Server leisten können. Das ist der Dezentralisierungspreis, den niemand gerne einrechnet.

Wie Cryptonews.net berichtet hat, ist World Chain die erste Layer-2, die gestreamte EIP-7928 Block Access Lists auf dem Mainnet deployed – Validatoren erhalten alle 200 Millisekunden Access-List-Daten über die Flashblocks-Architektur des Netzwerks. Unabhängige Transaktionen können parallel verifiziert werden, während der Block noch zusammengestellt wird. Das ist ein wesentlich anderes Ausführungsmodell als das, was die meisten OP-Stack-Chains heute liefern.

EIP-7928 selbst ist Teil der langfristigen Ethereum-Roadmap und soll im künftigen Glamsterdam-Upgrade enthalten sein. Den Stand dieser Arbeit kann man im übergeordneten EIP-Index nachlesen. World Chain hat nicht gewartet. Der Vorschlag wurde über Flashblocks erweitert und via Runtime-Flag aktiviert, sodass Node-Betreiber upgraden können, ohne eine netzwerkweite Protokolländerung zu koordinieren.

Warum ist das für einen CTO relevant? Weil der operative Aufwand von Hard Forks enorm ist. Produktionsvorfälle rund um Fork-Koordination entstehen meist nicht durch den Fork selbst, sondern durch wochenlangen Client-Versions-Drift im Umfeld. Runtime-Flags drehen diese Dynamik um. Man testet, flippt den Flag, und rollt zurück, wenn die Telemetrie Probleme zeigt. Das ist ein Operator-Release-Modell, kein Protokoll-Politikum.

Die Skalierungs-Schlagzeile ist ebenfalls real. Interne Benchmarks in der Testumgebung zeigten, dass die Validierungslatenz weitgehend stabil blieb, während der Durchsatz auf ca. ein Gigagas pro Sekunde auf Standard-Cloud-Hardware skalierte. Ein Gigagas pro Sekunde auf handelsüblicher Cloud-Hardware – das ist die Zahl, die jeden Payments-Engineer aufhorchen lassen sollte. Sie sagt: Wenn das auf dem Mainnet hält, braucht man keine Bare-Metal-Server, um mitzuhalten.

Die Optionen auf dem Tisch

Wer ein L2-Substrat für Stablecoin-Settlement, Remittance-Flows oder ein identitätsgesteuertes Zahlungsprodukt auswählt, hat es derzeit nicht leicht. Jede Option hat ihre Schwächen.

Option 1: Standard OP-Stack-Chains (Base, Optimism, andere). Ausgereifte Tooling-Landschaft, große Entwickler-Community, vorhersehbare Roadmap gekoppelt an Ethereums Upgrade-Kadenz. Der Nachteil: Man erbt Ethereums Durchsatzdecke, bis Glamsterdam landet – und das ist nicht nächstes Quartal. Man baut auf einer Chain, deren Skalierungsmodell auf Hardware-Wachstum setzt.

Option 2: zkEVM-Rollups (zkSync, Scroll, Linea, Polygon zkEVM). Anderes Sicherheitsmodell, starke theoretische Skalierungsgeschichte, aber die Prover-Ökonomie verschiebt sich alle paar Monate. Meine Einschätzung: Bei allem, was regulierte Zahlungen berührt, ist Prover-Zentralisierung eine Governance-Frage, die man Auditoren beantworten muss – und die Antwort ändert sich ständig.

Option 3: World Chain und andere Flashblocks-erweiterte OP-Stack-Varianten. Man bekommt gestreamte Access Lists heute im Produktionsbetrieb. Dazu kommt das World-ID-Proof-of-Human-System, das auf Chain-Ebene integriert ist – je nach Produkt entweder ein Feature oder ein Kopplungsproblem. World Chain basiert auf dem OP Stack, wird durch Ethereum gesichert und ist Teil des breiteren Superchain-Ökosystems, sodass die OP-Komposabilität erhalten bleibt.

Option 4: App-spezifische Chains oder Alt-L1s. Maximale Kontrolle, maximaler operativer Aufwand. Sinnvoll, wenn ein Team vorhanden ist, das Validator-Infrastruktur betreiben möchte. Die meisten Fintech- und iGaming-Teams, mit denen ich gearbeitet habe, unterschätzen diesen Aufwand um etwa eine Größenordnung.

Der Trade-off, klar ausgedrückt: World Chain bietet früheren Zugang zu Skalierungsprimitiven – auf einer Chain, deren Produktidentität an World ID und Proof-of-Human geknüpft ist. Wer Remittances, Stablecoins oder identitätsverknüpfte Zahlungen baut, dem hilft diese Ausrichtung. Wer ein generisches DeFi-Protokoll ohne meinungsstarke Identity-Infrastruktur aufbaut, wird darin Reibung erleben.

Die unbequeme Wahrheit: Die meisten Teams wählen ein L2 nach TVL und Bridge-Liquidität, nicht nach Durchsatz-Headroom. Das funktioniert – bis das Produkt echte Nutzer bekommt, und dann wird die Durchsatzdecke zur Roadmap.

Was Crypto und DeFi wirklich tun sollten

Hört auf, die L2-Auswahl als einmalige Entscheidung zu behandeln. Chains, die Features via Runtime-Flags ausliefern, werden sich von Chains trennen, die auf Ethereum-Hard-Forks warten – und die Lücke wird sich bis 2026 vergrößern. Portabilität ist wichtiger als Loyalität.

Konkret drei Maßnahmen: Erstens, Contracts und Infrastruktur so schreiben, dass eine Deployment auf mindestens zwei L2s innerhalb von zwölf Monaten möglich ist. Das bedeutet: keine chain-spezifischen Precompiles, es sei denn, sie lassen sich hinter einem Interface kapseln. Die Ethereum-Entwicklerdokumentation ist nach wie vor die sicherste Grundlage; alles jenseits der Standard-EVM ist ein Portabilitätspreis, den man bezahlt.

Zweitens, auf der Ziel-Chain mit dem eigenen Workload benchmarken, bevor man sich festlegt. World Chains Ein-Gigagas-pro-Sekunde-Zahl stammt aus internen Test-Benchmarks auf Cloud-Hardware, nicht aus adversarialen Mainnet-Bedingungen mit umkämpftem State. Teams, mit denen ich gearbeitet habe, sehen beim Wechsel von synthetischen Benchmarks zu echten Workloads mit heißen Storage-Slots regelmäßig 30 bis 60 Prozent weniger Leistung. Hier gilt dasselbe.

Drittens, Runtime-Flag-Upgrades als operatives Feature behandeln, nicht als Kuriosität. Wenn ein L2 Änderungen ohne Hard Forks ausliefern kann, verkleinert sich das Incident-Response-Fenster. Das ist gut für Betreiber und schlecht für alle, die ihr Monitoring auf quartalsweise Upgrade-Zyklen ausgelegt haben. Runbooks entsprechend aktualisieren.

Speziell für Zahlungs- und Remittance-Produkte ist das gestreamte Access-List-Modell wirklich interessant, weil es den Durchsatz von der Validator-Hardware entkoppelt. Das ist genau die Eigenschaft, die man bei burstigen, grenzüberschreitenden Loads benötigt. Meine Einschätzung: Wenn World Chains Mainnet-Zahlen auch nur annähernd an den Benchmark heranreichen, wird es die Standard-Antwort für Stablecoin-Korridore, die unter Last konsistente Settlement-Latenz brauchen.

Fallstricke und Sonderfälle

Benchmark-Zahlen aus Testumgebungen sind Marketing, bis das Gegenteil bewiesen ist. Ein Gigagas pro Sekunde auf Standard-Cloud-Hardware ist beeindruckend, aber die Testbedingungen sind entscheidend. Man sollte die Mainnet-Zahlen unter umkämpftem State-Zugriff, adversarialem Transaction-Ordering und MEV-schweren Blöcken beobachten. Parallele Verifizierung ist am einfachsten, wenn Transaktionen sich gegenseitig wirklich nicht berühren. Echte DeFi-Workloads berühren sich ständig gegenseitig.

Das Runtime-Flag-Aktivierungsmodell ist ein zweischneidiges Schwert. Ja, Node-Betreiber können ohne Hard Fork upgraden. Das bedeutet aber auch, dass sich das Netzwerkverhalten mit weniger öffentlicher Koordination ändern kann als bei einem typischen Fork. Wer Monitoring betreibt, muss wissen, wann Flags gesetzt werden. Man sollte beim World-Chain-Team nach der Benachrichtigungsfrequenz fragen und sie ins Runbook aufnehmen.

Gestreamte Access Lists verändern, was Validatoren mid-block sehen. Wer Off-Chain-Systeme betreibt, die Zwischenzustand lesen – von Indexern bis zu Bridge-Relayern – sollte sicherstellen, dass diese gegen gestreamte Daten korrekt funktionieren. Produktionsvorfälle bei L2-Upgrades entstehen fast immer in Off-Chain-Infrastruktur, die Annahmen über Block-Finalität getroffen hat, die stillschweigend nicht mehr galten.

Schließlich ist EIP-7928 auf Ethereums Seite noch ein Vorschlag. Wenn Glamsterdam eine wesentlich andere Version der Spezifikation ausliefert, muss World Chain seine erweiterte Flashblocks-Implementierung mit dem abgleichen, was in der Mainline landet. Das ist ein Kompatibilitätsrisiko, das in jede langfristige Architekturentscheidung eingepreist werden sollte.

Wichtigste Erkenntnisse

• World Chain ist die erste L2, die gestreamte EIP-7928 Block Access Lists auf dem Mainnet deployed – Validatoren erhalten alle 200 Millisekunden Access-List-Daten via Flashblocks.
• Die Aktivierung via Runtime-Flag statt Hard Fork ist die operative Geschichte, die Engineers am meisten interessieren sollte: schnellere Iteration, geringerer Koordinationsaufwand.
• Test-Benchmarks erreichten ca. ein Gigagas pro Sekunde auf Standard-Cloud-Hardware bei stabiler Validierungslatenz. Das ist als Obergrenze zu verstehen, nicht als Untergrenze – bis das Mainnet es beweist.
• Für Zahlungs-, Stablecoin- und Remittance-Produkte entkoppeln gestreamte Access Lists den Durchsatz von der Validator-Hardware – genau die Eigenschaft, die bei burstiger Last wirklich zählt.
• Für L2-Portabilität designen. Runtime-Flag-Chains werden sich bis 2026 von Hard-Fork-Chains unterscheiden, und man möchte in keinem der beiden Lager feststecken.