Der Zielzustand

Das IST-Urteil in Kapitel 4 hat Ethereum als Infrastruktur eingestuft, die ihre grundsätzliche Eignung unter erheblichen Bedingungen nachweist — Bedingungen, die im Protokoll selbst angelegt, aber noch nicht eingelöst sind. Kapitel 5 beschreibt den Zielzustand, auf den die Roadmap zielt: nicht den wünschenswerten, sondern den technisch spezifizierten. Die Bewertung folgt denselben zwölf Kriterien und derselben M3-Kaskade. Der Stichtag für alle Roadmap-Reifegrade ist der Stand der Ethereum Foundation Protocol Priorities vom Februar 2026 sowie der Fusaka-Spezifikation vom Dezember 2025.

5.1 Strategischer Pivot und normatives Fundament

Der strategische Pivot

Im Februar 2026 vollzieht Vitalik Buterin in zwei X-Beiträgen vom 3. und 5. Februar und in den EF Protocol Priorities vom Januar 2026 einen strategischen Richtungswechsel, der die Skalierungsstrategie des Protokolls von Grund auf neu ausrichtet.¹ Die bisherige Rollup-centric Roadmap, die Buterin 2021 formuliert hatte, hatte die Layer 1 als Datenverfügbarkeits-Schicht konzipiert, auf der Execution-Umgebungen der zweiten Schicht operieren, ohne dass die Basisschicht selbst nennenswerte Ausführungskapazität aufbauen müsste.² Diese Strategie hatte sich empirisch an zwei Punkten als unzureichend erwiesen: Der Fortschritt der Rollups zu Stage 2, der vollständig trustless betriebenen Stufe, verlief weit langsamer und schwieriger als erwartet; und der eigenständige Wert der Layer 1 als Settlement- und Koordinationsschicht war in der rollup-zentrischen Konzeption systematisch unterschätzt worden.³

Die neue Strategie macht die Layer 1 direkt zur Skalierungsebene. Das Ziel lautet, den L1-Durchsatz alle zwei Jahre zu verzehnfachen, von derzeit 15 bis 30 Transaktionen pro Sekunde auf schrittweise 300 bis 500 Millionen Gas pro Block im Endzustand. Layer-2-Systeme behalten ihre Rolle als Execution-Umgebungen mit niedrigen Gebühren und schnellen Bestätigungen, treten aber strukturell näher an das Protokoll heran, statt von ihm getrennt zu operieren. Begleitend dazu lanciert die Ethereum Foundation das Lean-Ethereum-Programm, ein Protokoll-Verschlankungsprogramm, das unnötige Komplexität abbaut und die Wartbarkeit des Systems dauerhaft verbessert.⁴

Das normative Fundament

Parallel zum strategischen Pivot schärft Buterin das normative Fundament des Protokolls über den walkaway test: Ein System ist dann trustless, wenn ein Nutzer es jederzeit verlassen kann, ohne dass identifizierbare Akteure seine Handlungsfähigkeit blockieren oder zensieren können.⁵ Dieser operative Test bestimmt die Zielrichtung für mehrere Roadmap-Stränge: Zensurresistenz auf Protokollebene, verifizierbarer Zugang ohne privilegierte Intermediäre und Persistenz des Zustandszugangs unabhängig von Betreiberpräsenz.

Im Rahmen des Fusaka-Upgrades rückt Privacy als Roadmap-Headliner in das Zentrum: Der Encrypted Mempool, der Transaktionen vor der Aufnahme in einen Block vor dem Lesezugriff von Buildern und Proposern schützt, befindet sich im Forschungsstatus; EIP-7786 normiert die Cross-Chain-Messaging-Infrastruktur, die Privacy-preserving Interoperabilität erst ermöglicht.⁶ Die Beam Chain — die vollständige Neugestaltung der Consensus-Schicht mit SNARK-basierter Aggregation, Drei-Slot-Finalität und einer neuen Validator-Ökonomie — bildet den langfristigen Endzustand des Protokolls als reinen Forschungspfad ohne Fork-Termin, angesetzt auf einen Zeithorizont jenseits 2029.⁷

Das Spektrum der Vertrauensmodelle

Das Stage-Schema von L2BEAT — Stage 0 erlaubt dem Betreiber vollständigen Eingriff, Stage 1 verlangt ein funktionierendes Proof-System mit beschränktem Security Council, Stage 2 untersagt jeden privilegierten Eingriff — übersetzt das normative Fundament in ein operatives Dezentralisierungs-Stufenschema, das im Zielzustand als Bewertungsrahmen für alle L2-Systeme dient.⁸ Die Layer 1 steht dabei außerhalb der Stage-Skala: Sie ist der Referenzpunkt vollständiger Trustlessness, dem alle Stufensysteme asymptotisch zustreben, ohne ihn je vollständig zu erreichen.⁹

Der strategische Pivot von der rollup-zentrischen zur L1-orientierten Strategie hat unmittelbare Konsequenzen für die Mindestanforderungen an Rollups: Stage 1 wird zur Mindestschwelle für Rollups, die Ethereum-native Assets verwalten. Rollups, die diesen Standard nicht erreichen, sind im SOLL-Konzept strukturell defizitär — nicht weil das Protokoll sie ausschließt, sondern weil das normative Fundament des Pivots sie in eine andere Vertrauensklasse einordnet.¹⁰ Lean Ethereum schließt diesen Rahmen normativ ab: Das Verschlankungsprogramm eliminiert nicht nur technische Komplexität, sondern reduziert auch den Vertrauensaufwand, den Nutzer in die Korrektheit nicht verifizierbarer Protokollteile setzen müssen.¹¹ Der Zielzustand ist damit zugleich schlanker und verifizierbarer als der IST-Zustand, und der walkaway test wird zur messbaren Zielgröße für alle zwölf Bewertungskriterien.¹²

5.2 Execution und Skalierung

Die Abhängigkeitskette: BALs, ePBS, zkEVM

Die Execution-Skalierung des Zielzustands hängt an drei Protokollmechanismen, die sequentiell aufeinander aufbauen und nur gemeinsam ihren vollen Effekt entfalten. Den Anfang bilden die Blob Accumulation Ledgers (BALs, RES), die eine stabile, protokollseitige Verwaltung der Blob-Infrastruktur sicherstellen und den Unterbau für alle nachgelagerten Datenverfügbarkeits-Mechanismen legen.¹³

Die enshrined Proposer-Builder-Separation (ePBS, EIP-7732, PLAN, SFI Glamsterdam) baut auf dieser Infrastruktur auf und erfüllt im Zielzustand eine dreifache Funktion: Sie eliminiert die Abhängigkeit von externen Relays, indem sie die Builder-Proposer-Interaktion protokollseitig regelt; sie verbessert die Neutralität des Transaktionsprozesses durch die Trennung der Blöcke in Header und Body; und sie schafft das Proving-Window im Slot N+1, das die zkEVM-Integration erst möglich macht.¹⁴

Am Ende der Kette steht der L1-zkEVM — die protokollseitige Verifikation von Ethereum-Blöcken durch Zero-Knowledge-Beweise statt durch Re-Execution (EIP-8025, Optional Execution Proofs, PLAN). Jeder Validator muss den Block nicht mehr selbst ausführen, um ihn zu validieren; ein kryptographischer Beweis übernimmt diese Funktion und reduziert die Rechenanforderungen für die Verifikation drastisch.¹⁵ Die Kausalkette ist dabei nicht austauschbar: ohne stabile Blob-Infrastruktur kein ePBS in der geplanten Form; ohne ePBS kein Proving-Window für den zkEVM; ohne zkEVM kein skalierbarer L1 über die 60-Millionen-Gas-Schwelle hinaus.¹⁶ Die zkEVM-Abhängigkeit von ePBS bestimmt damit auch den Zeitplan der gesamten Skalierungstrajektorie.¹⁷

Der gestaffelte Skalierungspfad

Der Skalierungspfad des Zielzustands folgt fünf definierten Schwellenwerten, die je nach Protokollreifegrad unterschiedliche Mechanismen zur Voraussetzung haben. Den ersten Schritt von 15 Millionen auf 30 Millionen Gas pro Block vollzieht das Netzwerk über das informelle Validator-Signaling, ohne Hard Fork: Validatoren einigen sich, das Gas Limit schrittweise anzuheben, wie es bereits im Lauf des Jahres 2025 praktiziert wurde.¹⁸

Der Sprung auf 60 Millionen Gas pro Block setzt die Aktivierung von ePBS und die ausreichende Reife des zkEVM voraus, weil erst dann die Verifikation auf der Validatorenseite nicht mehr die volle Re-Execution aller Transaktionen erfordert und die Netzwerkbelastung pro Validator trotz doppelter Kapazität beherrschbar bleibt.¹⁹ Die Schwellenwerte 120 Millionen und 240 Millionen Gas folgen demselben Muster gestufter Kapazitätserweiterung mit wachsender Proving-Reife als Voraussetzung.²⁰ Den Endzustand bildet das Full-Danksharding-Regime mit 300 bis 500 Millionen Gas pro Block, das erst dann erreichbar ist, wenn die gesamte DA-Infrastruktur einschließlich der 2D-Daten-Sampling-Mechanismen vollständig operativ ist.²¹ Die fünf Schwellenwerte sind keine willkürlichen Etappen, sondern technische Realitäten: Jede Stufe setzt die protokollseitige Reife der jeweils vorgelagerten Mechanismen voraus, und das Überspringen einer Stufe würde die Dezentralisierungs-Eigenschaften des Netzwerks gefährden.²²

Lean Ethereum und Protokoll-Verschlankung

Das Lean-Ethereum-Programm flankiert die Kapazitätsskalierung durch eine systematische Reduktion der Protokollkomplexität. Den operativen Kern bildet die Execution Layer Specification (ELS): eine ausführbare Referenzimplementierung der EVM-Semantik in Python, die die Yellow-Paper-Spezifikation von Gavin Wood durch ein maschinenverifizierbares Äquivalent ersetzt und künftig als verbindlicher Standard für neue Protokollfeatures dient.²³ Begleitend werden historisch gewachsene Precompiles bereinigt und die EVM-Opcode-Menge um nicht mehr genutzte Befehle reduziert, was sowohl die Implementierungslast für Client-Teams als auch die Angriffsfläche des Protokolls verkleinert.²⁴

RISC-V als alternative Execution-Umgebung befindet sich im Forschungsstatus (RES), ohne Governance-Verankerung und ohne Roadmap-Commitment: Die Idee, den EVM-Bytecode durch eine standardisierte RISC-V-ISA zu ergänzen, ist konzeptionell attraktiv, weil RISC-V-Programme nativ in Zero-Knowledge-Beweissystemen verifiziert werden können, liegt aber außerhalb des planbaren Zeithorizonts des Zielzustands.²⁵ Das Ethereum Object Format (EOF), das die EVM-Bytecode-Struktur durch ein explizites Containerformat ersetzen sollte, wurde nach intensiver Diskussion aus dem Fusaka-Upgrade zurückgezogen, weil die Komplexitätszunahme im Übergang den Lean-Ethereum-Zielen widersprach.²⁶ Das Lean-Ethereum-Programm insgesamt richtet die Protokollentwicklung nach einem Prinzip aus, das die EF Protocol Priorities vom Februar 2026 als leitend benennen: Einfachheit vor Vollständigkeit, Verifikation vor Funktionsumfang.²⁷

Datenverfügbarkeit — Blob-Skalierung und PeerDAS

Die Datenverfügbarkeits-Infrastruktur durchläuft im Zielzustand einen mehrstufigen Skalierungspfad. Den Ausgangspunkt bildet Dencun (März 2024) mit drei Blob-Slots als Zielwert und sechs als Maximum pro Block.²⁸ Pectra (7. Mai 2025) erhöht die Parameter auf sechs als Ziel und neun als Maximum; Blob Parameter Optimization Round 1 (BPO1), das im Fusaka-Upgrade enthalten ist, erhöht sie erneut und markiert den nächsten planbaren Schritt.²⁹ BPO2, der darauffolgende Schritt ohne festgelegten Zeitplan, setzt die Verdoppelungstrajektorie fort, bevor das System in die PeerDAS-Phase eintritt.³⁰

PeerDAS (EIP-7594, DEPL seit Fusaka, 3. Dezember 2025) verändert die Architektur der Datenverfügbarkeit grundlegend: Anstatt dass jeder Validator jeden Blob vollständig herunterlädt, übernimmt ein Peer-to-Peer-Sampling-Verfahren die Verifikation. Validatoren laden nur noch Stichproben der Blob-Daten herunter, verifizieren deren Verfügbarkeit statistisch und reduzieren damit ihre individuelle Bandbreitenbelastung um rund 85 Prozent gegenüber dem Volllast-Modell.³¹ Das Sampling-Verfahren basiert auf KZG-Polynomial-Commitments, die mathematisch garantieren, dass eine Stichprobe von ausreichender Größe die Rekonstruierbarkeit des gesamten Blobs belegt.³²

Im Full-Danksharding-Endzustand werden die KZG-Commitments durch STARK-basierte Beweissysteme ersetzt.³³ Dieser Übergang ist nicht allein durch Kapazitätsgründe motiviert: STARKs sind hash-basiert und damit post-quanten-sicher, während KZG-Commitments auf elliptischen Kurven beruhen, die durch ausreichend leistungsstarke Quantencomputer gebrochen werden könnten. Die Migration der DA-Schicht von KZG auf STARK ist damit ein integraler Teil der Post-Quantum-Strategie des Protokolls.³⁴ Die Blob-Kapazität im Zielzustand — nach abgeschlossenem Full Danksharding mit 128 und mehr Blobs pro Block — übertrifft die heutige DA-Kapazität um mehr als eine Größenordnung und bildet die strukturelle Grundlage für alle nachgelagerten Skalierungsgewinne auf der Layer 2.³⁵

Full Danksharding und Endzustand

Full Danksharding (RES) ist der Endzustand der Datenverfügbarkeits-Architektur. Mit 128 und mehr Blobs pro Block und einem zweidimensionalen Daten-Sampling-Verfahren erreicht die Layer 1 eine DA-Kapazität, die keine individuelle vollständige Blob-Speicherung bei Validatoren mehr voraussetzt.³⁶ Das Erasure-Coding-Verfahren, das Full Danksharding zugrunde liegt, stellt sicher, dass bei 75 Prozent verfügbarer Daten die vollständige Rekonstruktion möglich ist — eine Eigenschaft, die die DA-Sicherheit des Systems auch unter Netzwerkpartitionen und Ausfällen erhält.³⁷

Die Wirkung auf die Layer-2-Ökonomie ist strukturell: Günstige DA auf der Layer 1 ist die wichtigste Kostenkomponente für Rollups. Dencun hat die L2-Transaktionsgebühren um rund 90 Prozent reduziert; Full Danksharding wiederholt diesen Effekt in einer anderen Größenordnung und ermöglicht Rollup-Kapazitäten, die mit den heutigen DA-Kapazitäten nicht erreichbar wären.³⁸ Der zeitliche Horizont für Full Danksharding liegt außerhalb des planbaren Zeitrahmens der aktuellen Roadmap; PeerDAS als Zwischenstufe und die BPO-Runden sind die Schritte, die in der Planungsperiode bis 2028 gesetzt werden.³⁹ Die Validatoren-Bandbreite im Endzustand skaliert sublinear mit der Block-Kapazität, weil das Sampling-Verfahren die individuelle Last von der Gesamtkapazität entkoppelt — eine systemische Eigenschaft, die Dezentralisierung und Kapazität erstmals in einem konstruktiven statt konkurrierenden Verhältnis hält.⁴⁰

5.3 Verifikation und Zugang

Die L1-zkEVM

Der L1-zkEVM — die protokollseitige Zero-Knowledge-Verifikation von Ethereum-Blöcken — ist das technisch anspruchsvollste Element des Zielzustands und zugleich das, von dem die meisten anderen Fortschritte in der Kriterienerfüllung abhängen. EIP-8025 spezifiziert Optional Execution Proofs: Validatoren können wählen, ob sie einen Block durch Re-Execution oder durch die Verifikation eines ZK-Beweises validieren, wobei der Beweis von einem dezentralen Prover-Netzwerk erzeugt wird.⁵¹

Das Prover-Netzwerk ist als 3-of-5-Multi-Prover über die Client-Diversität aufgebaut: Fünf unabhängige Proving-Implementierungen in unterschiedlichen Technologie-Stacks müssen mindestens drei übereinstimmende Beweise liefern, bevor ein Block als verifiziert gilt. Diese Struktur überträgt das Client-Diversitäts-Prinzip der Consensus- und Execution-Schicht auf die Proving-Schicht und verhindert, dass ein Fehler in einem einzelnen Proof-System die Verifikation des gesamten Netzwerks kompromittiert.⁵²

Das Realtime-Proving-Ziel — 99 Prozent der Blöcke werden in unter zehn Sekunden bewiesen — wurde im Dezember 2025 erreicht. Die Proving-Latenz sank von 16 Minuten auf 16 Sekunden, die Proving-Kosten reduzierten sich um den Faktor 45 gegenüber dem Stand von 2024.⁵³ Diese Zahlen markieren einen qualitativen Sprung: Realtime-Proving bedeutet, dass Blöcke vollständig bewiesen sind, bevor der nächste Slot beginnt — eine Voraussetzung für die praktische Nutzbarkeit der zkEVM auf Mainnet-Ebene ohne Latenzeinbußen für Nutzer.⁵⁴

Die formale Sicherheitshärtung läuft in gestuften Meilensteinen: 100-Bit-Sicherheitsniveau bis Glamsterdam, 128-Bit bis Ende 2026. Unterhalb des 128-Bit-Niveaus gilt der Prover-Circuit als noch nicht vollständig gegen die Proving-Conjecture gehärtet — die Möglichkeit, dass ein adversarialer Prover einen falschen Zustandsübergang beweisen kann, ist nicht ausgeschlossen, aber liegt außerhalb der bekannten Angriffsszenarien.⁵⁵ Die ePBS-Abhängigkeit des zkEVM ist strukturell: Das Proving-Window im Slot N+1, das ePBS schafft, gibt dem Prover-Netzwerk die Zeit, den Block des vorherigen Slots zu beweisen, bevor der nächste Block produziert wird. Ohne dieses Window müsste der Beweis innerhalb des 12-Sekunden-Slots selbst entstehen — eine Anforderung, die die aktuelle Prover-Technologie nicht erfüllt.⁵⁶

Die dreifache Wirkung des zkEVM auf den Vertrauensstapel ist der entscheidende Fortschritt gegenüber dem IST-Zustand: Validatoren müssen dem Prover-Netzwerk vertrauen statt der Korrektheit aller Client-Implementierungen; Light Clients können Blöcke ohne Download des State verifizieren; und L2-Rollups können sich auf eine protokollseitige Verifikationsinfrastruktur stützen, statt eigene Proof-Systeme zu unterhalten.⁵⁷ Vitalik Buterin koppelt die Zeitlinien ausdrücklich: Die L1-zkEVM-Adoption und die Einführung der Native-Rollup-Precompiles verlaufen im Wesentlichen synchron, weil beide auf dieselbe Prover-Infrastruktur aufbauen.⁵⁸

Hash-basierte Aggregation und secp256r1

Die Aggregations-Infrastruktur des Zielzustands baut auf hash-basierten rekursiven SNARKs auf — einer Technologie, die sowohl die PQ-Sicherheit der Consensus-Signaturen als auch die DA-Verifikation und die L1-zkEVM-Beweise in einer gemeinsamen kryptographischen Grundlage verbindet.⁵⁹ Rekursive SNARKs erlauben es, mehrere Beweise zu einem einzigen zusammenzufassen, ohne dass der Gesamtbeweis linear mit der Anzahl der Teilbeweise wächst — eine Eigenschaft, die für die Skalierung der Consensus-Aggregation entscheidend ist, wenn im Beam-Chain-Szenario die Validator-Signaturen auf hash-basierte Verfahren umgestellt werden.⁶⁰

Die secp256r1-Precompile (EIP-7951, DEPL seit Fusaka) öffnet das Protokoll für FIDO2- und WebAuthn-kompatible Passkeys: Hardware-Sicherheitsschlüssel und geräteseitige Authentifikation, die auf der P-256-Kurve operieren, können ab Fusaka direkt für Ethereum-Transaktionen genutzt werden, ohne dass ein Umweg über ECDSA-Schlüssel erforderlich ist.⁶¹ Die Wirkung auf die Zugänglichkeit ist erheblich: Nutzer können Ethereum-Wallets ohne separate Seed-Phrase-Verwaltung betreiben, weil die Authentifikation durch geräteseitige Hardware erfolgt — ein Zugänglichkeitsfortschritt, der insbesondere für Nutzer relevant ist, die nicht bereit oder in der Lage sind, kryptographische Schlüsselverwaltung zu betreiben.⁶² Dass secp256r1 als Precompile deployt ist und nicht als Protokoll-native Signatur, bedeutet zugleich, dass der Übergang zu diesem Verfahren keinen Hard Fork erforderte und das Lean-Ethereum-Prinzip — Protokollerweiterung ohne Komplexitätszunahme im Kern — praktisch umsetzt.⁶³

Stateless Clients und State-Unabhängigkeit

Stateless Clients sind das zweite große Verifikationsprinzip des Zielzustands: Ein Client, der einen Block validieren kann, ohne den vollständigen State lokal vorzuhalten. Dieses Prinzip setzt eine State-Struktur voraus, die kompakte Witnesses — kryptographische Beweise über den Zustand einzelner State-Einträge — in einer Größenordnung erzeugt, die über das Netzwerk praktikabel übertragbar ist.⁶⁴

Der Migrationspfad zur stateless-kompatiblen State-Struktur bietet zwei Optionen: Verkle Trees (PLAN, SFI) als der primär verfolgte Ansatz und Binary Trees (RES) als STARK-kompatible Alternative, die im Rahmen der Post-Quantum-Strategie an Bedeutung gewonnen hat. Das Migrations-Bundle EIP-7612/7748/4762 ist gegenüber der Tree-Wahl invariant: Es spezifiziert die Migrations-Mechanik, nicht die Zielstruktur, und bleibt damit gültig unabhängig davon, welcher Tree-Typ letztlich gewählt wird.⁶⁵

Verkle Trees ermöglichen Witnesses in der Größenordnung von einigen Kilobytes pro Block, verglichen mit den Megabytes, die Merkle-Patricia-Tries erfordern. Diese Kompression ist die Voraussetzung dafür, dass Witnesses in der Netzwerkkommunikation zwischen Peers mitgeführt werden können, ohne die Netzwerkbandbreite zu sättigen.⁶⁶ Binary Trees bieten als Alternative den Vorteil nativer STARK-Kompatibilität: Die Hash-basierte Struktur lässt sich direkt in STARK-Beweissystemen verarbeiten, was im Kontext der Post-Quantum-Migration relevant ist, weil STARKs die bevorzugte PQ-sichere Beweistechnologie für den Ethereum-Endzustand sind.⁶⁷

Den Übergang begleitet Helios (DEPL) als Light-Client-Implementierung, die bereits heute ohne vollständigen State-Download Ethereum-Blöcke verifizieren kann — nicht durch Stateless-Client-Mechanismen, sondern durch die Verifikation von Beacon-Chain-Sync-Committees. Helios ist damit eine Vorstufe der vollständigen Stateless-Client-Welt: Sie demonstriert, dass ressourcenbeschränkte Geräte Ethereum verifizieren können, auch wenn die endgültige Witness-basierte Verifikation noch nicht deployt ist.⁶⁸

Native Account Abstraction

Das Account-Modell des Zielzustands überwindet die historische Trennung zwischen Externally Owned Accounts, die durch einen einzelnen ECDSA-Schlüssel kontrolliert werden, und Contract Accounts, die beliebige Validierungslogik ausführen können. Der erste Schritt, EIP-7702 (DEPL seit Pectra, 7. Mai 2025), erlaubt EOAs, temporär die Logik eines Smart Contracts zu delegieren — ein Upgrade, das Session Keys, Gas Sponsoring, Social Recovery und Multi-Sig auf Protokollebene implementierbar macht, ohne dass Nutzer auf Contract-Wallets migrieren müssen.⁶⁹

EIP-8141 Validation Frames (CFI Hegotá Checkpoint #9, Non-Headliner) geht weiter: Accounts können ihre eigene Validierungslogik spezifizieren, die vom Protokoll bei jeder Transaktion ausgeführt wird. Dies ermöglicht volle Native Account Abstraction — beliebige Signaturalgorithmen, beliebige Zugangsbedingungen, beliebige Autorisierungsmodelle — ohne Beschränkung auf die ECDSA-Primitive, die das heutige Protokoll vorschreibt.⁷⁰

Die vier Fähigkeiten, die Native Account Abstraction im Zielzustand erschließt, sind nicht nur UX-Verbesserungen: Multi-Sig ist sicherheitskritisch für institutionelle Nutzer; Session Keys ermöglichen Anwendungen, die ohne permanente Wallet-Interaktion operieren; Gas Sponsoring erlaubt Anwendungen, die Transaktionskosten für ihre Nutzer übernehmen; Social Recovery ermöglicht die Schlüsselwiederherstellung über soziale Netzwerke statt kryptographische Backup-Verfahren.⁷¹ Der ERC-4337-Standard, der diese Fähigkeiten bereits vor EIP-7702 und EIP-8141 auf Application-Ebene realisiert hatte, dokumentiert mit über 25 Millionen Smart Accounts und mehr als 130 Millionen UserOperations die Marktnachfrage — und zeigt, dass die protokollseitige Implementierung eine Infrastruktur formalisiert, die sich bereits bewährt hat.⁷²

Der ECDSA-Exit-Pfad ist dabei mehr als ein Komfort-Feature: Er ist das zentrale Vehikel für die Post-Quantum-Migration. Wenn Accounts ihre Validierungslogik selbst spezifizieren können, können sie bei Bedarf auf post-quanten-sichere Signaturverfahren migrieren, ohne dass das Protokoll einen Hard Fork zur Änderung der Signatur-Primitive erfordert. EIP-8141 ist damit zugleich Zugänglichkeits-Upgrade und PQ-Migrationspfad in einem.⁷³

Post-Quantum-Migration und Inactivity Leak

Das quantenmechanische Risiko für Ethereum teilt sich in drei Schichten auf: die Consensus-Signaturen (BLS), die State-Verifikation (KZG-Commitments) und die Transaction-Signaturen (ECDSA). Jede Schicht hat im Zielzustand einen eigenen Migrationspfad, wobei die Schichten unterschiedliche Zeitdrücke und unterschiedliche technische Komplexitäten aufweisen.⁷⁴

Die Größenordnungen illustrieren die Herausforderung: ECDSA-Signaturen sind 64 Byte groß; ML-DSA-Signaturen (CRYSTALS-Dilithium, NIST PQC Standard), der bevorzugte post-quanten-sichere Kandidat für die Transaction-Ebene, liegen zwischen 2,4 und 4,6 Kilobyte; SLH-DSA-Signaturen zwischen 7,9 und 49,9 Kilobyte.⁷⁵ Für die Consensus-Schicht bedeutet der Übergang von BLS auf leanXMSS (die hash-basierte Signaturlinie, die im Beam-Chain-Forschungskontext entwickelt wird) eine Zunahme der Signaturgrößen um Größenordnungen, verbunden mit dem Verlust der nativen Aggregierbarkeit von BLS.⁷⁶

Der State-Bloat durch die PQ-Migration ist quantifiziert: Bei vollständiger Umstellung aller Accounts auf ML-DSA wächst der State um den Faktor 59 — eine Zahl, die verdeutlicht, dass die PQ-Migration nicht isoliert gedacht werden kann, sondern zwingend mit der State-Wachstum-Adressierung koordiniert werden muss.⁷⁷

Das EF Post-Quantum Research Team, das im Januar 2026 gegründet wurde, koordiniert alle drei Migrationspfade in zweiwöchentlichen All-Core-Developer-Calls. Der Emergency Response Plan, den Buterin im Februar 2026 publiziert hat, definiert Protokollierungsschritte für den Fall, dass ein kryptographisch relevanter Quantencomputer früher als erwartet verfügbar wird — er ist dokumentiert, aber nicht protokollär erzwungen.⁷⁸ Die Metaculus-Schätzung einer rund 20-prozentigen Wahrscheinlichkeit eines kryptographisch relevanten Quantencomputers vor 2030 ist der quantifizierte Rahmen, in dem die Migrationsdringlichkeit bewertet wird — eine Einschätzung, die die Arbeit als zitierten Reifegrad-Kontext aufnimmt, nicht als eigene Prognose.⁷⁹

Der Inactivity Leak ist in diesem Kontext ein Robustheitsmechanismus mit doppelter Funktion: Er stellt sicher, dass das Netzwerk nach einem Ausfall von mehr als einem Drittel der Validatoren automatisch die Finalisierung wiederherstellt, indem inaktiven Validatoren graduell Stake entzogen wird, bis die partizipierenden Validatoren eine Supermajorität bilden. Im PQ-Kontext ist der Inactivity Leak relevant, weil er auch bei einem koordinierten Schlüsselkompromiss — durch Quantenangriff oder anderweitig — die Selbstheilung des Netzwerks ermöglicht, ohne dass externe Koordination erforderlich ist.⁸⁰

Binary Trees (RES) als STARK-kompatible State-Struktur verbinden den Stateless-Client-Pfad mit der PQ-Migration: Eine State-Struktur, die nativ STARK-verifizierbar ist, beseitigt die Abhängigkeit von KZG-Commitments auch auf der State-Ebene und schließt damit den PQ-Migrationspfad für alle drei Schichten.⁸¹

Validation Frames

EIP-8141 Validation Frames (CFI Hegotá Checkpoint #9, Non-Headliner) ist das primäre Vehikel für den ECDSA-Ausstieg im Zielzustand. Das Prinzip ist einfach: Anstatt das Protokoll zu zwingen, eine spezifische Signaturlogik zu kennen und zu erzwingen, spezifiziert jeder Account seine eigene Validierungslogik in einem Frame — einem ausführbaren Code-Segment, das bei jeder Transaktion aufgerufen wird, bevor die Transaktion verarbeitet wird.⁸²

Die Reifegrad-Klassifikation CFI (Considered for Inclusion) Hegotá Non-Headliner bedeutet, dass EIP-8141 für das Hegotá-Upgrade vorgemerkt ist, aber nicht als Headliner-Feature behandelt wird — es konkurriert mit anderen CFI-Items um Implementierungskapazität und kann in nachgelagerte Upgrades verschoben werden, ohne dass die strategische Richtung in Frage gestellt wird.⁸³

Die strategische Bedeutung von EIP-8141 übersteigt seine technische Komplexität. Ein Account, der seine Validierungslogik selbst spezifizieren kann, kann bei Bedarf auf jede post-quanten-sichere Signaturmethode migrieren — ML-DSA, SLH-DSA, oder zukünftige Standards —, ohne dass das Ethereum-Protokoll dafür einen Hard Fork benötigt oder auch nur wissen muss, welches Signaturverfahren ein spezifischer Account verwendet. Die PQ-Migration der Transaction-Schicht wird damit dezentralisiert: Sie ist eine Entscheidung jedes einzelnen Accounts, nicht eine kollektive Protokollentscheidung.⁸⁴

5.4 State-Wachstum und Persistenz

Das Tiered State

Das State-Wachstum ist das zentrale Langzeitproblem der Ethereum-Architektur: Jeder deployte Contract, jedes neue Wallet, jeder geschriebene Storage-Slot akkumuliert permanent auf allen Full Nodes, ohne dass inaktive Einträge verfallen oder komprimiert werden. Im IST-Zustand umfasst der State in komprimierter Form 150 bis 200 Gigabyte; im Full-Node-Umfang 1.579 Gigabyte. Ohne Gegenmaßnahmen wächst dieser Wert linear mit der Nutzungsintensität des Netzwerks.⁸⁵

Das Tiered State (RES) ist der strukturelle Antwortmechanismus auf dieses Problem. Das System unterscheidet drei Stufen: Active State enthält Einträge, auf die in einem definierten Zeitfenster zugegriffen wurde; er wird von allen Full Nodes direkt vorgehalten und ist schnell zugänglich. Hibernated State enthält Einträge, die das Aktivitätskriterium nicht mehr erfüllen; sie werden nicht mehr von allen Nodes lokal gespeichert, können aber mit einem kryptographischen Witness — einem Merkle- oder Verkle-Proof — wiederhergestellt werden, wenn eine Transaktion sie reaktiviert. Dead State enthält Einträge, die seit einem protokollseitig definierten Zeitraum keinerlei Aktivität gezeigt haben; sie werden vergessen und sind nur noch über archivalische Quellen rekonstruierbar.⁸⁶

Die Übergangskriterien zwischen den Stufen sind protokollseitig definiert und deterministisch: Ein Eintrag wandert von Active nach Hibernated, wenn er seit einer bestimmten Anzahl von Epochs nicht gelesen oder geschrieben wurde; von Hibernated nach Dead, wenn auch das längere Zeitfenster abgelaufen ist. Die Wiederherstellung eines Hibernated-Eintrags ist möglich, erfordert aber das Mitliefern des Witnesses in der reaktivierenden Transaktion — was die Kosten für die Reaktivierung zu Lasten des Transaktors legt, nicht zu Lasten des Netzwerks als Ganzes.⁸⁷

Der Reifegrad RES bedeutet, dass das Tiered State noch in der Forschungsphase ist und kein Deployment-Commitment der Ethereum Foundation existiert. Die konzeptionelle Grundlage ist jedoch seit Jahren etabliert; die entscheidende technische Voraussetzung — eine State-Struktur, die kompakte Witnesses erzeugt — wird durch den Verkle- oder Binary-Trees-Migrationspfad geschaffen, der im Stateless-Client-Kontext ohnehin erforderlich ist. Das Tiered State ist damit kein isoliertes Feature, sondern ein Layer, der auf der State-Struktur-Migration aufbaut und sie um eine Persistenz-Governance-Schicht ergänzt.⁸⁸

Die State-Wachstum-Szenarien

Das State-Wachstum lässt sich unter drei Szenarien modellieren, die unterschiedliche Kombinationen aus Nutzungswachstum und Tiered-State-Wirkung abbilden. Szenario A (optimistisch) kombiniert moderates Nutzungswachstum mit vollständiger Tiered-State-Implementierung und der Migration auf Verkle oder Binary Trees: Der Active State stabilisiert sich bei einem Bruchteil des heutigen Full-State, weil ein Großteil der historisch akkumulierten, aber nicht mehr aktiv genutzten Einträge in den Hibernated oder Dead State wandert.⁸⁹

Szenario B (moderat) rechnet mit starkem Nutzungswachstum durch die Gas-Limit-Erhöhungen und die L2-Expansion, aber vollständiger Tiered-State-Wirkung: Der Active State wächst, bleibt aber durch den Ablaufmechanismus unterhalb des Wachstumspfads, der ohne Tiered State entstünde. Szenario C (pessimistisch) kombiniert starkes Nutzungswachstum mit einer verzögerten oder unvollständigen Tiered-State-Implementierung und zeigt, dass der State ohne strukturelle Gegenmaßnahmen in einer Größenordnung wächst, die Home-Staking und dezentrale Node-Betreiber strukturell ausschließt.⁹⁰

Die Szenarien sind nicht als exakte Prognosen zu verstehen, sondern als Sensitivitätsanalyse: Sie zeigen, welche Faktoren die State-Wachstumstrajektorie dominieren, und machen damit sichtbar, an welchen Hebeln die Roadmap ansetzen muss, um eine Dezentralisierungs-kompatible Hardware-Anforderungs-Trajektorie zu erreichen. Die kritische Variable ist nicht das Nutzungswachstum — das ist das Ziel der Skalierungsroadmap —, sondern die Rechtzeitigkeit der Tiered-State-Implementierung relativ zur Gas-Limit-Erhöhung.⁹¹

History Expiry und weitere Maßnahmen

Ergänzend zum Tiered State adressiert die Roadmap das State-Wachstum durch drei weitere Mechanismen, die unterschiedliche Schichten des State-Problems betreffen. History Expiry (EIP-4444, Phase 1 DEPL seit Juli 2025) entbindet Ethereum-Nodes davon, alte Blockhistorie lokal vorzuhalten: Ab Phase 1 müssen Nodes keine Blöcke älter als ein definiertes Zeitfenster mehr speichern. Die historischen Daten werden durch ein Peer-to-Peer-Archivierungsnetzwerk (Portal Network) verfügbar gehalten, aber nicht mehr von der Mehrheit der aktiven Nodes repliziert.⁹²

EIP-4444 adressiert damit nicht den State selbst, sondern die History — die Folge vergangener Blöcke, die für die laufende Verifikation nicht mehr benötigt wird, aber massive Storage-Anforderungen an Full Nodes stellt. Die Wirkung ist direkt auf die Hardware-Anforderungen der Node-Betreiber spürbar: Ein Node, der keine Blockhistorie ab Genesis vorhalten muss, kann mit erheblich kleinerem Storage betrieben werden.⁹³

Die SELFDESTRUCT-Limitation (EIP-6780, DEPL seit Dencun, März 2024) eliminiert eine der Hauptquellen von State-Komplexität: Der SELFDESTRUCT-Opcode, der einen Contract und seinen Storage aus dem State entfernt, wurde auf die Anwendbarkeit innerhalb derselben Transaktion beschränkt, in der der Contract erstellt wurde. Das verhindert das Neuanlegen von Contracts an derselben Adresse mit unterschiedlichem Code — ein Muster, das die State-Verifikation und die Beweis-Erzeugung erschwert.⁹⁴

State Rent — ein Mechanismus, der inaktive State-Einträge mit laufenden Kosten belegt, die bei Nichtbezahlung zur Löschung führen — befindet sich im Forschungsstatus ohne Deployment-Commitment. Der konzeptionelle Vorzug von State Rent gegenüber dem Tiered State ist die ökonomische Steuerbarkeit: Nutzer, die einen State-Eintrag langfristig vorhalten wollen, zahlen für diesen Service, was eine Preissignalwirkung für die Nutzung des knappen State-Speichers erzeugt. Die konzeptionellen Nachteile — Designkomplexität, Gefahr unbeabsichtigter Contract-Löschungen, Interoperabilitätsprobleme — haben die Priorität von State Rent in der Roadmap bisher gedrückt.⁹⁵

5.5 Neutralität und Finalität

ePBS und FOCIL — Neutralität durch Protokoll

Die Neutralitätseigenschaften des Zielzustands beruhen auf zwei komplementären Mechanismen, die unterschiedliche Angriffsvektoren auf die Transaktionsinklusion adressieren. Die enshrined Proposer-Builder-Separation (ePBS, EIP-7732, PLAN, SFI Glamsterdam) strukturiert die Block-Produktion protokollseitig um: Der Builder hinterlegt Bid und Header, der Proposer akzeptiert auf Basis des Bids, der Builder enthüllt anschließend den Body. Die Relay-Abhängigkeit, die im IST-Zustand den gesamten Block-Produktionsprozess durch wenige externe Intermediäre vermittelt, entfällt; das Vertrauen in Relay-Betreiber wird durch ein protokollseitiges Commitment-and-Reveal-Verfahren ersetzt.⁹⁶

Das Fork-Choice Enforced Inclusion List Protocol (FOCIL, EIP-7805, PLAN, SFI Hegotá Headliner) adressiert den Zensur-Angriff auf Ebene der Transaktionsinklusion: Rund 2.000 zufällig ausgewählte Committeeund-Mitglieder publizieren jeweils eine Inklusions-Liste mit bis zu 16 Transaktionen, die ihrer Ansicht nach aufgenommen werden sollen. Der Proposer des folgenden Slots ist protokollseitig verpflichtet, Transaktionen aus mindestens einer dieser Listen aufzunehmen — ein 1-of-N-Honesty-Modell, das Zensur durch einen einzelnen Proposer strukturell verhindert, solange mindestens ein Committee-Mitglied korrekt handelt.⁹⁷

Der Encrypted Mempool (RES) ergänzt diese beiden Mechanismen um Pre-Inclusion-Privacy: Transaktionen werden erst zum Zeitpunkt der Aufnahme in einen Block entschlüsselt, sodass Builder und Proposer ihren Inhalt vor der Inklusion nicht kennen. Das eliminiert die Möglichkeit des Content-based Frontrunnings und der content-basierten Zensur — Angriffsvektoren, die ePBS und FOCIL strukturell offen lassen, weil sie die Sichtbarkeit des Transaction-Inhalts nicht adressieren.⁹⁸

Die Kombination der drei Mechanismen bildet ein gestaffeltes Neutralitätssystem: ePBS beseitigt die Relay-Abhängigkeit und schafft ein protokollseitiges Commitment-Verfahren für die Block-Produktion; FOCIL erzwingt die Transaktionsinklusion durch das Committee-Modell; der Encrypted Mempool schützt den Transaktionsinhalt vor der Aufnahme. Kein einzelner Mechanismus löst alle Aspekte des Zensurproblems; die drei zusammen schließen die wesentlichen strukturellen Lücken.⁹⁹

Die Reifegrade sind abgestuft: ePBS ist PLAN mit SFI für Glamsterdam, hat damit einen definierten Einbautermin; FOCIL ist PLAN mit SFI für Hegotá und Headliner-Status, was eine hohe Implementierungspriorität signalisiert; der Encrypted Mempool ist RES ohne Einbauzusage und liegt zeitlich am weitesten entfernt.¹⁰⁰ Der Abstand zwischen dem erreichten dreischichtigen System und dem IST-Zustand ist erheblich: Im IST-Zustand ist FOCIL nicht implementiert, der Encrypted Mempool nicht existent, und die Relay-Abhängigkeit strukturell ungelöst. Der Sprung von FOCIL-fehlt zu FOCIL-deployt ist der kritische Fortschritt, der II.1 von Bedingt erfüllt auf Erfüllt mit Einschränkung hebt.¹⁰¹

MEV-Ökonomie

Die Maximal Extractable Value-Ökonomie des Zielzustands ist eine der Domänen, in denen der Fortschritt des Protokolls am stärksten durch externe Marktstrukturen begrenzt wird. Die Builder-Konzentration, die im IST-Zustand die Top-3-Builder auf über 90 Prozent Marktanteil konzentriert hat, ist bis 2026 auf rund 70 bis 80 Prozent zurückgegangen — eine Verbesserung, aber keine strukturelle Auflösung.¹⁰²

Die Ursachen der Builder-Konzentration sind struktureller Natur und werden durch ePBS nicht vollständig adressiert: Latenzvorteile für Builder mit direkter Colocierung nahe den Validator-Nodes, Cross-Domain-Arbitrage über mehrere DEX-Protokolle und Chains hinweg, und Exclusive Order Flow, der rund 54 Prozent des Block-Werts durch proprietäre Transaktionsquellen erklärt, die kleinen Buildern nicht zugänglich sind.¹⁰³

Das Attester-Proposer-Separation-Modell (APS, RES), das die Proposer-Rolle dauerhaft von Validatoren trennen und an spezialisierte Execution Ticket-Inhaber vergeben würde, ist eine konzeptionelle Antwort auf die MEV-Konzentration auf Builder-Ebene: Wenn die Proposer-Entscheidung kommerzialisiert und durch Auktionsmechanismen reguliert wird, können MEV-Erträge breiter verteilt werden.¹⁰⁴

MEV Burn (RES) verfolgt einen anderen Ansatz: Anstatt MEV-Erträge an Proposer oder Builder fließen zu lassen, werden sie durch Verbrennung dem gesamten ETH-Supply entzogen und damit in einen deflationären Mechanismus umgewandelt, der allen ETH-Haltern zugute kommt. Beide Mechanismen — APS und MEV Burn — befinden sich im Forschungsstatus ohne Deployment-Commitment und liegen damit außerhalb des planbaren Zielzustands.¹⁰⁵

Die drei Grenzen, die im Zielzustand unaufgelöst bleiben, sind konsistent mit dem Bewertungsergebnis für II.1: Builder-Konzentration als strukturelles Marktphänomen, das ePBS adressiert aber nicht auflöst; Liquid Staking als dominante Staking-Form ohne Protokoll-Cap; und Exclusive Order Flow als informationale Asymmetrie, die durch keine der geplanten Protokollmaßnahmen adressiert wird.¹⁰⁶

Die Wirkung von ePBS auf die MEV-Ökonomie ist dennoch nicht trivial: Die Protokollisierung des Builder-Proposer-Verfahrens schafft erstmals eine standardisierte Schnittstelle, über die Regulierung und weitere Protokollmaßnahmen greifen können. Was heute durch informelle Relay-Vereinbarungen und Marktmacht geregelt wird, wird durch ePBS zu einem definierten Protokollpunkt — ein Fortschritt, der zukünftige Interventionen strukturell ermöglicht, auch wenn er sie nicht selbst vornimmt.¹⁰⁷

Die Gesamteinschätzung für die MEV-Ökonomie des Zielzustands lautet: strukturell verbessert durch ePBS, aber nicht gelöst. Die Konzentration bleibt; die Anreize für Cross-Domain-Arbitrage und Exclusive Order Flow bleiben; die Forschungspfade APS und MEV Burn sind zu weit entfernt, um im SOLL-Zeitraum zu zählen.¹⁰⁸ Die Differenzierung von II.1 — Erfüllt mit Einschränkung statt Erfüllt — trägt diese Einschätzung direkt: FOCIL und ePBS liefern ein protokollseitig gestütztes Neutralitätssystem, aber die ökonomischen Wurzeln der Builder-Konzentration bleiben im SOLL-Zeitraum unbehandelt.¹⁰⁹

Staking-Ökonomie

Die Staking-Ökonomie des Zielzustands ist ein Bereich, in dem die Roadmap strukturelle Verbesserungen liefert, ohne das Kernproblem der Konzentration zu lösen. Das Security Budget — die Gesamtheit der ökonomischen Ressourcen, die das Netzwerk sichern — bleibt durch das Zusammenspiel von Issuance, Burn und Transaktionsgebühren stabil; die Verteilung dieser Ressourcen über das Validator-Set ist dagegen nach wie vor ungelöst.¹¹⁰

MaxEB (EIP-7251, DEPL seit Pectra, 7. Mai 2025) erhöht die maximale Effective Balance pro Validator von 32 auf 2.048 ETH. Die Wirkung ist zweifach: Große Staker können ihre Validatoren konsolidieren, was die Gesamtzahl der Validatoren reduziert und die Netzwerkkommunikation entlastet; und die Konsolidierung ist eine Voraussetzung für die schnelle Aggregation, die wiederum eine Voraussetzung für die Beam-Chain-Consensus-Architektur mit SNARK-Aggregation ist.¹¹¹

Distributed Validator Technology (DVT, implementiert durch Obol und SSV Network, DEPL) erlaubt es mehreren Betreibern, gemeinsam einen einzigen Validator zu betreiben. Das reduziert das Slashing-Risiko durch Single-Point-of-Failure und ermöglicht kleineren Stakern, die 32-ETH-Schwelle durch Pools zu erfüllen, ohne einen zentralen Staking-Anbieter zu nutzen.¹¹²

Rainbow Staking (RES) ist ein Forschungskonzept für eine differenzierte Staking-Architektur, die verschiedene Validator-Rollen mit unterschiedlichen Sicherheitsanforderungen und Ertragsstrukturen definiert — etwa eine leichte Attestor-Rolle mit niedrigem Kapital-Einsatz und eine schwerere Proposal-Rolle mit höherem Stake. Rainbow Staking adressiert die 32-ETH-Schwelle als strukturelle Barriere für Solo-Staking, liegt aber ohne Deployment-Commitment im Forschungsstatus.¹¹³

Die Konzentration bei Lido bleibt das ungelöste Strukturproblem: Mit rund 23 Prozent des gestakten ETH — rückläufig vom Höchststand über 32 Prozent, aber ohne implementierten Protokoll-Cap — ist Lido der dominante Liquid-Staking-Anbieter. Kein Roadmap-Feature adressiert diese Konzentration direkt; die Ethereum Foundation hat sich gegen einen protokollseitigen Staking-Cap ausgesprochen. Die geographische Konzentration von rund 39 Prozent der Nodes in den USA bleibt im Zielzustand ebenfalls unverändert.¹¹⁴

Die 32-ETH-Solo-Staking-Schwelle ist das Einschluss-Problem, das die Staking-Ökonomie des Zielzustands strukturell eingrenzt: Ohne eine Senkung dieser Schwelle bleibt Solo-Staking auf einen kleinen Teil der potenziellen Validator-Gemeinschaft beschränkt, und die Dezentralisierung des Validator-Sets bleibt von Liquid-Staking-Anbietern und institutionellen Akteuren abhängig. DVT mildert dieses Problem durch Pooling, löst es aber nicht strukturell.¹¹⁵

Der Gesamtbefund für die Staking-Ökonomie des Zielzustands: Das Security Budget ist stabil und die technische Infrastruktur verbessert sich durch MaxEB und DVT; die Verteilungsprobleme der Staking-Ökonomie sind im SOLL-Zeitraum nicht strukturell gelöst und begrenzen II.1 auf Erfüllt mit Einschränkung, da die Lido-Konzentration und die geographische Konzentration als Infrastrukturrisiken fortbestehen.¹¹⁶

Die Krisen-Reaktions-Lücke, die sich quer über II.1, III.1 und III.2 zieht, manifestiert sich in der Staking-Ökonomie als fehlender Protokoll-Cap: Im Fall einer Krise, die eine schnelle Umverteilung des Stakes erfordert, fehlt ein automatischer Mechanismus, der die Konzentration bei einzelnen Anbietern begrenzt. Der Emergency Response Plan adressiert dieses Szenario dokumentiert, aber nicht protokollär erzwungen.¹¹⁷

Drei-Slot-Finalität und Beam Chain

Die Finalitäts-Architektur des Zielzustands überwindet die heutige 12,8-Minuten-Finalisierung durch eine gestaffelte Reduktion der Finalitätslatenz, die auf drei unterschiedlichen Mechanismen mit unterschiedlichen Reifegraden beruht. Den langfristigen Endzustand bildet das, was unter dem Begriff Single-Slot-Finalität diskutiert wird, faktisch aber eine Drei-Slot-Finalität ist: Das Finalisierungsprotokoll benötigt drei Slots à 12 Sekunden — rund 36 Sekunden vom Zeitpunkt der Transaktionseinreichung bis zur unumkehrbaren Festschreibung.¹¹⁸

Die Beam Chain (RES, post-2029) absorbiert die Single-Slot-Finalität als einen ihrer zentralen Designpunkte. Sie ist die vollständige Neugestaltung der Consensus-Schicht: SNARK-basierte Consensus Proofs ersetzen die heutige BLS-Aggregation, die Validator-Ökonomie wird neu strukturiert, und die Finalitätslatenz sinkt auf die physikalisch minimale Grenze, die durch Netzwerklatenz und Slot-Struktur bestimmt wird. Die Beam Chain ist ohne Fork-Termin und liegt außerhalb des planbaren Zeithorizonts der aktuellen Roadmap.¹¹⁹

BLS, der heutige Consensus-Signaturalgorithmus, aggregiert die Signaturen der rund einer Million Validatoren nativ zu einer einzigen Signatur — eine Eigenschaft, die die schnelle Aggregation billig hält. Der Übergang zu leanXMSS, dem hash-basierten Signaturverfahren der PQ-Migration auf Consensus-Ebene, bricht diese Eigenschaft: leanXMSS-Signaturen sind um Größenordnungen größer als BLS-Signaturen und aggregieren nicht nativ.¹²⁰

Die Lösung ist leanVM: Ein minimaler zkVM faltet die größeren leanXMSS-Signaturen über einen rekursiven SNARK zu einem einzigen Beweis zusammen und komprimiert sie um etwa das 250-fache, sodass die Finalitätslatenz trotz der größeren Einzelsignaturen schnell bleibt. Der Mechanismus teilt das Aggregationsprinzip mit der hash-basierten Aggregation in Abschnitt 5.3 — beide nutzen rekursive SNARKs als Kompressionsmechanismus für kryptographische Objekte, die sich nicht nativ aggregieren lassen.¹²¹

5.6 L2-Architektur und Settlement

Native Rollups

Die Layer-2-Architektur des IST-Zustands ist durch ein Zweiklassenproblem gekennzeichnet: L1-Nutzer vertrauen dem Protokoll; L2-Nutzer vertrauen dem Protokoll und zusätzlich dem Betreiber des jeweiligen Rollup-Systems. Der Verifier Contract — das zentrale Element des heutigen Rollup-Sicherheitsmodells — wird vom Betreiber deployt, kontrolliert und ist upgradeable. Er ist damit eine vertrauenswürdige Partei, nicht ein vertrauensloser Mechanismus.¹²²

Das L2BEAT-Stage-System dokumentiert dieses Problem quantitativ: Kein großes Rollup hatte Stand Anfang 2026 Stage 2 erreicht — den Zustand, in dem jedweder privilegierter Eingriff ausgeschlossen ist und allein die mathematische Verifikation zählt. Arbitrum, Base, Optimism, Starknet und Scroll operieren auf Stage 1, zkSync Era und Linea auf Stage 0. Die technischen und regulatorischen Gründe, die Stage-2-Fortschritte blockieren, sind vielschichtig; Vitalik Buterin benennt den Fortschritt zu Stage 2 ausdrücklich als weit langsamer und schwieriger als ursprünglich erwartet — einen der empirischen Auslöser des strategischen Pivots.¹²³

Native Rollups (EIP-8079, RES) sind der protokollseitige Antwortmechanismus: Die EXECUTE-Precompile exponiert die State Transition Function der Layer 1 für den Zugriff durch Rollup-Betreiber. Ein Rollup-Betreiber ruft EXECUTE mit drei Inputs auf — pre_state_root, post_state_root und einem Witness Trace, der die gelesenen und geschriebenen State-Werte des Rollup-Blocks enthält. Dieselben rund eine Million Validatoren, die L1-Blöcke verifizieren, verifizieren damit auch Rollup-Blöcke — nicht durch proprietäre Verifier-Contracts, sondern durch das Protokoll selbst.¹²⁴

Die Folgen sind strukturell: Ein Security Council wird überflüssig, weil die Sicherheitsgarantie durch das Protokoll selbst erbracht wird; Hard-Fork-Kompatibilität ist automatisch, weil der Rollup dieselbe STF wie die Layer 1 nutzt; und die Bridge zwischen Layer 1 und Layer 2, die im heutigen Modell eine vertrauenswürdige Schicht darstellt, entfällt als eigenständige Sicherheitskomponente. Native Rollups sind auf EVM-äquivalente Systeme beschränkt — Rollups mit eigener Virtual Machine oder eigener Signatur-Infrastruktur können EIP-8079 nicht nutzen.¹²⁵

Der DA-Overhead des Witness Trace ist die zentrale technische Einschränkung des EXECUTE-Mechanismus: Eine typische Rollup-Batch liegt zwischen 125 und 750 Kilobyte; der Witness Trace liegt in der Größenordnung von drei Megabyte je EXECUTE-Invocation — ein Overhead vom Fünf- bis Zehnfachen der Batch. Mit der heutigen Merkle-Patricia-State-Struktur wären die Witnesses bei rund 300 Megabyte und damit prohibitiv; mit den kompakten Witnesses der Verkle- oder Binary-Trees-Migration ist der Overhead tragbar, weil die Datenverfügbarkeits-Kapazität der Layer 1 gleichzeitig strukturell wächst.¹²⁶

Based Sequencing und Preconfirmations

Das Sequencing-Problem der heutigen Rollup-Architektur konzentriert drei kritische Befugnisse beim zentralen Sequencer des jeweiligen Betreibers: die Macht zur Zensur einzelner Transaktionen, die Kontrolle über das Ordering und damit über die MEV-Extraktion, und die Liveness-Abhängigkeit — wenn der Sequencer ausfällt, steht das Rollup. Based Sequencing übergibt alle drei Befugnisse an die Layer 1.¹²⁷

Im Based-Sequencing-Modell nimmt der L1-Proposer des jeweiligen Slots — in Kollaboration mit den Buildern — den nächsten Rollup-Block in seinen L1-Block auf. Das Rollup erbt damit das Validator-Set der Layer 1 mit rund einer Million Validatoren als Sequencing-Infrastruktur, ohne eine eigene Sequencer-Komponente, ohne zusätzlichen Konsens und ohne Escape Hatch. Die Rollup-Regeln folgen automatisch den Hard Forks der Layer 1, weil der Rollup-Block ein Teil des L1-Blocks ist. Liveness ist gleichbedeutend mit L1-Liveness; das Sequencing ist permissionless.¹²⁸

Der Deterministic Proposer Lookahead (EIP-7917, DEPL seit Fusaka, 3. Dezember 2025) ist die notwendige Infrastruktur für Based Preconfirmations: Er berechnet die Proposer-Zuständigkeit kommender Slots deterministisch und protokollseitig, sodass die Identität des bevorstehenden L1-Proposers vorausberechenbar wird. Ohne diesen Lookahead ist es unmöglich, einem Nutzer zu versprechen, dass seine Transaktion im nächsten Slot aufgenommen wird — weil unklar ist, welcher Proposer zuständig sein wird.¹²⁹

Based Preconfirmations (DEPL partiell, Taiko Phase 1) bauen auf dem Lookahead auf: Ein Teil der Validatoren registriert sich über einen Registry Contract mit hinterlegtem Stake als Preconfirmer. Der Nutzer sendet die Transaktion an den zuständigen Preconfirmer, der eine Zusage in der Größenordnung von 100 Millisekunden bis 2 Sekunden macht. Wenn der Preconfirmer seine Zusage bricht, wird sein Stake durch Slashing vernichtet — die Preconfirmation ist damit ökonomisch besichert, wenn auch nicht protokollär garantiert.¹³⁰

Taiko Alethia ist der operative Existenzbeweis: Als erster Based Rollup seit Mai 2024 auf dem Mainnet hat Taiko bis April 2026 über 900 Millionen Transaktionen verarbeitet, ohne Ausfallzeit. Preconfirmations sind seit August 2025 in Phase 1 auf dem Mainnet aktiv — über eine permissioned Whitelist von Preconfirmern mit rund zwei Sekunden Bestätigungszeit.¹³¹

Drei strukturelle Grenzen des Based-Sequencing-Modells bleiben im Zielzustand offen: Die ökonomische Grenze — Rollup-Betreiber verlieren MEV-Erträge, weil das Ordering an den L1-Proposer übergeht; die DoS-Grenze — der Deterministic Proposer Lookahead steht in Spannung zur Single Secret Leader Election, die die Proposer-Identität bis zur Ausführung geheim hält; und die Richtungs-Trennung — der Lookahead schafft Vorhersehbarkeit, die DoS-Angriffe auf bekannte Proposer erleichtert, ein Zielkonflikt, der im SOLL-Zustand unaufgelöst bleibt.¹³²

Konvergenz — Ultrasound Rollup und Finalitäts-Stack

Die Kombination aus Native Rollups und Based Sequencing bildet den maximalen Anbindungsgrad eines Rollup an die Layer 1: Inclusion, Ordering und Execution stammen sämtlich vom Protokoll; das Rollup-System ist vollständig trustless. Im Ökosystem-Diskurs wird diese Bauform als Ultrasound Rollup bezeichnet. Taiko Gwyneth ist als Based Rollup mit synchroner Composability zu Ethereum in Entwicklung und zielt ausdrücklich auf diese Konvergenz.¹³³

ePBS ist der Konvergenzpunkt der Roadmap: Es ist das Mechanismus, von dem sowohl die Native-Rollup-Integration über die EXECUTE-Precompile als auch das Proving-Window des L1-zkEVM abhängen. Das erklärt, warum ePBS an drei Stellen des Zielzustands als kritische Voraussetzung auftaucht — in der Kapazitätsskalierung (5.2), der Neutralität (5.5) und der L2-Konvergenz (5.6).¹³⁴

Der Finalitäts-Stack des Zielzustands ist dreilagig. Die erste Schicht sind Based Preconfirmations mit rund zwei Sekunden Bestätigungszeit — ökonomisch besichert, auf der Ebene der Layer 2 deployt, mit Slashing als Sanktionsmechanismus. Die zweite Schicht ist die Fast Confirmation Rule (FCR, consensus-specs PR #4747, PLAN): Bei mindestens 75 Prozent ehrlichem Stake und einer Netzlatenz unter drei Sekunden gilt ein Block nach rund 13 Sekunden als deterministisch bestätigt — ohne Hard Fork, als reines Client-Feature, mit einem Rollout in den kommenden Monaten nach der Spezifikation im März 2026. Einzahlungen bei Börsen und das Bridging von Layer 1 auf Layer 2 beschleunigen sich um rund 98 Prozent.¹³⁵

Die dritte Schicht ist die Drei-Slot-Finalität — die unumkehrbare kryptographische Festschreibung nach rund 36 Sekunden, die im Rahmen der Beam-Chain-Architektur als Endzustand konzipiert ist. Sie ist unabhängig von ePBS und von der Fast Confirmation Rule und bildet die kryptographische Endgültigkeit über der deterministischen Bestätigung.¹³⁶

Cross-L2 und Settlement tokenisierter Werte

Die Cross-L2-Composability des Zielzustands lässt sich auf einer vierstufigen Skala verorten: Stufe 1 — atomare Composability innerhalb eines einzelnen Blocks — bleibt im SOLL-Zeitraum unerreichbar, weil sie eine gemeinsame Execution-Umgebung oder synchrone Kommunikation zwischen Rollups innerhalb eines Slots erfordern würde. Stufe 2 — asynchrone Composability mit deterministischen Finalitätsgarantien unterhalb einer Stunde — ist das erreichbare Ziel: Based Sequencing (DEPL) schafft gemeinsame Ordnung über alle Based Rollups im selben Slot; Native Rollup Verification (RES) schafft gemeinsame Finalität.¹³⁷

ERC-7683 Cross-Chain Intents (DEPL, auditierter Code seit Januar 2025) und das Open Intents Framework (OIF, DEPL, Ethereum Foundation seit Februar 2025) normieren die Anwendungsschicht über der technischen Composability: ERC-7683 definiert Order-Strukturen und Settler-Interfaces für Cross-L2-Intents mit über 70 integrierenden Projekten und Cross-Chain-Ausführung in rund zwei Sekunden; das OIF bündelt die Implementierungen von über 30 Teams. Die Fast Confirmation Rule beschleunigt das Settlement der Intents durch die deterministische L1-Bestätigung.¹³⁸

Der Markt für tokenisierte Werte — Real World Assets auf Ethereum — illustriert die praktische Relevanz dieser Infrastruktur: Über 17 Milliarden US-Dollar tokenisierter Werte lagen im Februar 2026 auf dem Mainnet, mit einem Jahreswachstum von rund 315 Prozent gegenüber rund 4,1 Milliarden im Vorjahr; der Marktanteil Ethereums liegt je nach Messmethode bei 34 bis über 50 Prozent des gesamten RWA-Markts.¹³⁹

BlackRock USD Institutional Digital Liquidity Fund (BUIDL) ist der Benchmark-Nachweis: Der tokenisierte Geldmarktfonds, aufgelegt im März 2024 auf Ethereum mit Securitize, erreichte Mitte Mai 2026 rund 2,5 Milliarden US-Dollar AUM und ist damit der größte tokenisierte Treasury-Fonds überhaupt — ein Datenpunkt, der zeigt, dass institutionelle Kapitalverwalter Ethereum als Settlement-Schicht für regulierte Kapitalmarktprodukte nutzen.¹⁴⁰

Der No-Action-Letter der SEC Division of Trading and Markets an die Depository Trust Company vom 11. Dezember 2025 öffnet die Kategorie regulatorisch: Ein Drei-Jahres-Pilot erlaubt Security Entitlements an US-Treasuries, Russell-1000-Aktien und ausgewählten Index-ETFs als Token auf zugelassenen, auch permissionless Blockchains. Der Letter weist keine Netzwerk-Zuordnung zu, schließt Ethereum als Settlement-Layer für Wertpapiertransaktionen aber erstmals explizit nicht aus.¹⁴¹

Forschungshorizont

Zwei Akteursklassen markieren die Grenzen des Zielzustands nach oben: heterogene Chains und autonome Agenten. Heterogene Chains — Blockchain-Systeme mit eigener Consensus-Schicht und eigener Execution-Umgebung — können ihre Blockhistorie periodisch auf Ethereum verankern und erhalten damit externe Finalität; aber sie können die EXECUTE-Precompile nicht nutzen, weil ihre STF nicht mit der Ethereum-STF identisch ist. Native Rollups sind für diese Klasse nicht verfügbar; sie verbleiben im Modus der externen Finalitätsverankerung, nicht der protokollseitigen Verifikation.¹⁴²

Autonome Agenten — KI-Systeme oder Software-Agenten, die wirtschaftliche Aktivität ohne menschliche Direktkontrolle ausführen — haben keine Möglichkeit, ein Bankkonto zu eröffnen, einen Vertrag zu unterzeichnen oder eine rechtliche Identität anzunehmen. Ein öffentliches, permissionless, persistentes Rechnungswesen ohne Vorbedingung für die Kontoeröffnung ist die einzige bekannte Infrastruktur, die diese Akteursklasse ohne institutionelle Vermittlung adressieren kann. ERC-8004 „Trustless Agents” (Draft seit August 2025) konkretisiert diesen Anwendungsfall mit drei On-Chain-Registern für Identität, Reputation und Validierung.¹⁴³

5.7 SOLL-Bewertung

Kritische Bedingungen

Die drei Kritischen Bedingungen — Sicherheits- und Vertrauenslast (I.2), Neutralität und Zensurresistenz (II.1) und Minimale tragfähige Garantien (I.4) — erfahren im Zielzustand unterschiedliche Verbesserungen.

I.2 steht im Zielzustand auf Erfüllt mit Einschränkung. Die Vertrauenslast-Reduktion verläuft über nahezu jede Protokollschicht: Relay-Trust-Elimination durch ePBS (PLAN/SFI Glamsterdam), Validator-Trust-Reduktion durch den L1-zkEVM (Aktive EF-Roadmap) und RPC-Trust-Reduktion durch Stateless Clients und Helios (DEPL/IMPL). Zwei Residualrisiken bleiben nicht protokollseitig erreichbar: die zkEVM-Proving-Conjecture — die Möglichkeit, dass ein adversarialer Prover einen falschen Zustandsübergang beweist — und die Access-Schicht, bestehend aus Wallets, Frontends und DNS, die sich der protokollseitigen Kontrolle prinzipiell entziehen.¹⁴⁴

Das Finalitätsprofil von I.4 ist im Zielzustand gestärkt durch den dreilagigen Stack: Based Preconfirmations rund zwei Sekunden (DEPL), Fast Confirmation Rule rund 13 Sekunden (PLAN, consensus-specs PR #4747) und Drei-Slot-Finalität rund 36 Sekunden (RES, Horizont post-2029). Liveness unter Angriff ist durch den Inactivity Leak als automatischen Selbstheilungsmechanismus gesichert; Zensurresistenz durch FOCIL (PLAN/SFI Hegotá-Headliner) als protokollseitig erzwungenes Inklusionsgebot. I.4 steht auf Erfüllt.¹⁴⁵ Die vier I.4-Aspekte — Finalität, Liveness, Degradation Mode und Zensurresistenz unter Angriff — sind im Zielzustand gestärkt oder gehalten.¹⁴⁶

II.1 erlebt den entscheidenden Stufensprung des Zielzustands: von Bedingt erfüllt im IST auf Erfüllt mit Einschränkung im SOLL. Das dreischichtige System aus FOCIL, ePBS und Encrypted Mempool adressiert die strukturellen Neutralitätslücken des IST-Zustands und hebt die einzige Kritische Bedingung, die im IST-Zustand die Kaskade auf die mittlere Eignungsstufe gedrückt hat.¹⁴⁷ Die verbleibenden Grenzen begrenzen die Stufe auf Erfüllt mit Einschränkung: Builder-Konzentration, die ePBS adressiert aber nicht auflöst; Lido mit rund 23 Prozent des gestakten ETH ohne Protokoll-Cap; und geographische Node-Verteilung mit rund 39 Prozent US-Nodes.¹⁴⁸

Das Post-Quantum-Inventar des Zielzustands ist querschnittlich über alle drei Kritischen Bedingungen relevant: Auf der Consensus-Schicht ist leanXMSS via Beam Chain (post-2029, RES) der Zielpfad; auf der DA-Schicht erfolgt der KZG-zu-STARK-Übergang im Full-Danksharding-Endzustand; auf der Execution-Schicht schafft ECDSA-Exit via NAA und Validation Frames (EIP-8141, CFI Hegotá Non-Headliner) den Migrationspfad. Als gemeinsame Schicht dient die hash-basierte Aggregation aus 5.3. Deployt sind secp256r1 (EIP-7951) und Helios; im Status PLAN befindet sich EIP-8141; im Status RES befinden sich EIP-7932 und Binary Trees.¹⁴⁹

Das PQ-Research-Team der Ethereum Foundation (Januar 2026) koordiniert alle Pfade; der Emergency Response Plan ist dokumentiert; Strawmap-Signaturgrößen zeigen ML-DSA bei 2,4 bis 4,6 Kilobyte und SLH-DSA bei 7,9 bis 49,9 Kilobyte gegen 64 Byte bei ECDSA, mit State-Bloat in der Größenordnung des 59-fachen bei ML-DSA.¹⁵⁰ Das PQ-Vor-Material insgesamt bewertet die Lage als: architektonisch angelegt, nicht gesichert; die Pfade sind für alle drei Schichten definiert, aber kein Pfad ist abgeschlossen und kein zeitkritischer Meilenstein ist garantiert.¹⁵¹ Die Metaculus-Schätzung einer rund 20-prozentigen Wahrscheinlichkeit eines kryptographisch relevanten Quantencomputers vor 2030 ist der quantifizierte Risikorahmen — eine externe Einschätzung, keine Prognose der Arbeit.¹⁵²

Strukturelle und Qualitative Kriterien

Die drei Strukturellen Bedingungen stehen im Zielzustand sämtlich auf Erfüllt.

I.1 (Funktionale Unersetzbarkeit): Alle drei Anker-Indikatoren — DeFi-TVL-Dominanz, Stablecoin-Issuance und Developer-Ökosystem — erreichen die höchste Ankerstufe oberhalb der 50-Prozent-Schwelle. Native Rollups binden die technische Wechseloption für EVM-äquivalente Rollups protokollseitig; Cloud-Konzentration bei rund 59 Prozent auf drei Providern qualifiziert die Stufe, ohne sie zu drücken.¹⁵³ Die Settlement-Attraktion durch ERC-7683 und Native Rollups ist die entscheidende Verbesserung gegenüber dem IST-Zustand.¹⁵⁴ Die Cloud-Konzentration ist gegenüber dem IST-Zustand unverändert: rund 59 Prozent der gehosteten Execution-Layer-Nodes auf drei Providern (AWS 35,5%, Hetzner 13,8%, OVHcloud 9,7%), seit 2022 rückläufig.¹⁵⁵

I.3 (Koordinationsfunktion): Die Reichweite des Protokolls als Koordinationsschicht expandiert im Zielzustand von Settlement und DA auf Execution-Verifikation und MEV-Ökonomie. Native Rollups erhöhen die Wechselkosten für EVM-äquivalente Rollups strukturell, weil ein Wechsel des Settlement-Layers die protokollseitige Verifikation aufgibt. Alle Top-10-L2s settlen im Zielzustand auf Ethereum.¹⁵⁶ Die Settlement-Funktion für tokenisierte Werte — RWA über 17 Milliarden US-Dollar, BUIDL als Benchmark — ist der neue qualitative Schicht der Koordinationsfunktion.¹⁵⁷

III.1 (Langfristige Stabilität): Drei Entkopplungen dokumentieren den Fortschritt — zkEVM entkoppelt die Verifikation von der Ausführung; Stateless Clients entkoppeln die Verifikation vom State-Vorhalten; Tiered State entkoppelt die Node-Anforderungen vom State-Wachstum. Der Upgrade-Track-Record — Shanghai, Dencun, Pectra und Fusaka ohne Mainnet-kritische Incidents, Fusaka mit erstmals eingehaltenem halbjährlichem Zeitplan — ist der empirische Stabilitätsnachweis.¹⁵⁸ Lido und die Validator-Konzentration bleiben strukturell unverändert — kein Roadmap-Feature adressiert die Konzentration direkt.¹⁵⁹

Die sechs Qualitativen Kriterien stehen im Zielzustand auf Erfüllt mit Einschränkung.

II.2 (Generative Kapazität): Drei Ebenen generativer Kapazität — Compute (zkEVM), UX (NAA+Passkeys) und L2-Erzeugung (Native Rollups) — belegen die Stufenzuweisung. Grenzen: RISC-V ohne Governance-Verankerung, EOF zurückgezogen. Die Validator-Konzentration ohne Cap ist das bleibende Strukturproblem.¹⁶⁰

II.3 (Technische Integrität): Die Execution Layer Specification ist die ausführbare Referenzimplementierung, die den Yellow Paper in der Spezifikationsrolle ablöst. Grenze: Formale Verifikation des zkEVM-Prover-Circuits übersteigt die Kapazität gegenwärtiger formaler Methoden.¹⁶¹ Die ELS als operative Spezifikationsreferenz — nicht als theoretisches Dokument — ist der qualitative Fortschritt für II.3.¹⁶²

II.4 (Zugänglichkeit): Drei Ebenen — Nutzer (NAA und Passkeys via EIP-7702 DEPL und EIP-7951 DEPL), Verifizierer (Stateless Clients, Helios) und Entwickler (stabiles EVM, ELS). Grenze: Die 32-ETH-Solo-Staking-Schwelle ist durch kein Roadmap-Feature direkt gesenkt; die Hardware-Entlastung erfolgt indirekt über zkEVM-basierte Attestation.¹⁶³

III.2 (Governance-Qualität): Der strategische Pivot vom Februar 2026 ist der stärkste Beleg für die Governance-Qualität — ein paradigmatischer Richtungswechsel ohne Krise oder Fork, vollzogen durch informellen Konsens und öffentliche Kommunikation.¹⁶⁴

III.3 (Interoperabilität ohne Lock-in): Drei Lock-in-Auflösungen — Relay-Abhängigkeit durch ePBS (PLAN), L2-Proof-Systeme durch Native Rollups (RES), RPC-Vertrauen durch Trustless RPC (RES/PLAN). Der EVM bleibt ein struktureller bilateraler Lock-in, der die Stufe nicht drückt.¹⁶⁵

III.4 (Hardware-Agnostik): Keine ASIC-Abhängigkeit; ARM-kompatibel; Stateless Clients als langfristiger Pfad bis Smartphone-Verifikation. Cloud-Konzentration unverändert gegenüber dem IST-Zustand; die IST-Stufe Erfüllt mit Einschränkung wird gehalten, nicht verbessert.¹⁶⁶

SOLL-Gesamtprofil

Tabelle 5.1 zeigt die Stufenverteilung der zwölf Kriterien im Zielzustand.

Stufe	Kriterien	Anzahl
Erfüllt	I.1, I.3, I.4, III.1, III.2, III.3	6
Erfüllt mit Einschränkung	I.2, II.1, II.2, II.3, II.4, III.4	6
Bedingt erfüllt	—	0
Offen	—	0

Das SOLL-Profil lautet 6-6-0-0. Alle sechs Qualitativen Kriterien stehen auf mindestens Erfüllt mit Einschränkung; damit ist die Bedingung für den Grad Gut erfüllt.¹⁶⁷

5.8 Gesamturteil

Die M3-Kaskade bestimmt das Gesamturteil anhand des SOLL-Profils in fünf Prüfungsschritten. Ausgangspunkt ist die Stufenverteilung in Tabelle 5.1.¹⁶⁸

Erster Schritt: Steht eine Kritische Bedingung auf Offen? — Nein. Die Deckelung auf Bedingt geeignet entfällt. Zweiter Schritt: Steht eine Kritische Bedingung auf Bedingt erfüllt? — Nein. Im IST-Zustand stand II.1 auf Bedingt erfüllt und setzte die Kaskade auf die mittlere Kategorie; im SOLL-Zustand ist II.1 auf Erfüllt mit Einschränkung gestiegen. Die zweite Kaskaden-Deckelung fällt damit weg. Das Urteil liegt oberhalb der mittleren Kategorie.¹⁶⁹

Dritter Schritt: Sind mindestens zwei Strukturelle Bedingungen geschwächt — also unterhalb von Erfüllt mit Einschränkung? — Nein. I.1, I.3 und III.1 stehen alle auf Erfüllt; keine dritte Deckelung. Vierter Schritt: Stehen I.2 und II.1 unterhalb von vollständigem Erfüllt? — Ja, beide stehen auf Erfüllt mit Einschränkung. Das schlichte Geeignet-Urteil ist damit ausgeschlossen; das Ergebnis ist die nächste Kategorie oberhalb der mittleren: Geeignet mit Bedingungen. Fünfter Schritt: Der Grad wird durch die Qualitativen Kriterien bestimmt. Alle sechs stehen auf mindestens Erfüllt mit Einschränkung — das ergibt Grad Gut.¹⁷⁰

Das SOLL-Urteil lautet: Geeignet mit Bedingungen, Grad Gut.

Der Vergleich mit dem IST-Urteil zeigt die Verschiebung: Der IST-Zustand erhielt das Urteil Geeignet unter erheblichen Bedingungen, Grad Gut. Der SOLL-Zustand steht eine Urteilsstufe höher, bei gleichem Grad. Der Fortschritt liegt im Fundament der Eignung — im Sprung von II.1 von Bedingt erfüllt zu Erfüllt mit Einschränkung —, nicht in der Feinqualität der qualitativen Kriterien, die in ihrer Gesamtheit stabil bleiben.

Eine Krisen-Reaktions-Lücke verläuft quer über die Grenzen mehrerer Kriterien und ist im SOLL-Urteil nicht vollständig eingepreist: Die Builder-Konzentration in der Block-Produktion ist durch ePBS nicht in ihren ökonomischen Wurzeln adressiert; die Lido-Konzentration mit rund 23 Prozent ohne Protokoll-Cap bleibt eine strukturelle Abhängigkeit ohne automatisierten Korrektiv; und der Emergency Response Plan ist als dokumentiertes Prozedere vorhanden, aber nicht als protokollärer Mechanismus erzwungen. Diese drei Aspekte konvergieren in einer Lücke, die II.1 und III.1 begrenzt und III.2 qualifiziert — und die der Gegenstand der Untersuchung in Kapitel 6 ist.¹⁷¹

Das SOLL-Urteil steht auf architektonischer Kohärenz bei abgestufter Implementierungsreife: Der Zielzustand ist technisch spezifiziert und in sich konsistent; die Post-Quantum-Migration ist architektonisch angelegt, aber nicht gesichert; und die Belastbarkeit des Systems unter Krisenbedingungen — die Frage, ob die Bedingungen, an die die Eignung geknüpft ist, auch in adversarialen Szenarien halten — ist die offene Frage, die Kapitel 6 untersucht.¹⁷²