Delta, Grenzen und Gesamturteil

6.1 Das Delta

6.1-A Der Profil-Vergleich

Die IST-Bewertung aus Kapitel 4 und die SOLL-Bewertung aus Kapitel 5 ergeben zwei numerische Profile, die sich in ihrer Zusammensetzung deutlich unterscheiden, in ihrer Konsequenz aber präzise gelesen werden müssen.

Das IST-Profil lautet 0-11-1-0: kein Kriterium auf „Erfüllt”, elf Kriterien auf „Erfüllt mit Einschränkung”, ein Kriterium auf „Bedingt erfüllt” (Neutralität und Zensurresistenz, II.1), kein Kriterium auf „Offen”.¹ Das SOLL-Profil lautet 6-6-0-0: sechs Kriterien auf „Erfüllt”, sechs auf „Erfüllt mit Einschränkung”, kein Kriterium auf „Bedingt erfüllt”, kein Kriterium auf „Offen”.²

Kriterium	IST	SOLL	Änderung
I.1 Funktionale Unersetzbarkeit	Erfüllt mit Einschränkung	Erfüllt	↑
I.2 Sicherheits- und Vertrauenslast	Erfüllt mit Einschränkung	Erfüllt mit Einschränkung	—
I.3 Koordinationsfunktion	Erfüllt mit Einschränkung	Erfüllt	↑
I.4 Minimale tragfähige Garantien	Erfüllt mit Einschränkung	Erfüllt	↑
II.1 Neutralität und Zensurresistenz	Bedingt erfüllt	Erfüllt mit Einschränkung	↑↑
II.2 Offene Generativität	Erfüllt mit Einschränkung	Erfüllt mit Einschränkung	—
II.3 Unabhängige Verifizierbarkeit	Erfüllt mit Einschränkung	Erfüllt mit Einschränkung	—
II.4 Niedrigschwellige Inklusivität	Erfüllt mit Einschränkung	Erfüllt mit Einschränkung	—
III.1 Langfristige Stabilität	Erfüllt mit Einschränkung	Erfüllt	↑
III.2 Adaptive Governance	Erfüllt mit Einschränkung	Erfüllt	↑
III.3 Souveräne Portabilität	Erfüllt mit Einschränkung	Erfüllt	↑
III.4 Hardware-Agnostik	Erfüllt mit Einschränkung	Erfüllt mit Einschränkung	—

Sieben Kriterien verbessern sich, fünf bleiben unverändert, keines verschlechtert sich.

6.1-B Der Sprung bei II.1

Die wichtigste Einzelveränderung zwischen IST und SOLL ist der Anstieg von Neutralität und Zensurresistenz (II.1) von „Bedingt erfüllt” auf „Erfüllt mit Einschränkung”. Dieser Aufstieg ist nicht graduell — er markiert den Übergang von einem strukturellen Defekt zu einer qualifizierten Stärke.

Im IST-Zustand ist die Neutralität emergent: Kein Protokollmechanismus erzwingt die Transaktionsinklusion. Die Transaktionsaufnahme hängt von der Marktstruktur der Block Builder ab, deren Konzentration bei drei Akteuren 93,3 Prozent betrug.³ Das ist „Bedingt erfüllt” in der M3-Kaskade: Die Kerneigenschaft der protokollären Neutralitätsgarantie ist erkennbar angesteuert, aber nicht realisiert.

Im SOLL-Zustand bildet ein dreischichtiges System die protokolläre Grundlage. FOCIL (EIP-7805) erzwingt die Inklusion über ein 2.000-köpfiges Committee, dessen 1-of-N-Honesty-Modell die Korruption strukturell unattrativ macht.⁴ ePBS (EIP-7732) eliminiert die Relay-Abhängigkeit und trennt Proposer und Builder in getrennte, protokollär koordinierte Rollen.⁵ Der Encrypted Mempool adressiert als Forschungsreserve Pre-Inclusion-Privacy und schließt den verbleibenden Offenbarungskanal.⁶

Der Aufstieg ist strukturell bedeutsam, weil er die zweite Kaskaden-Deckelung in der M3-Logik entfernt. Im IST hat eine Kritische Bedingung das Urteil auf „Geeignet unter erheblichen Bedingungen” gedrückt. Im SOLL existiert keine Kritische Bedingung mehr auf „Bedingt erfüllt” — die Deckelung fällt weg, und das Gesamturteil kann eine Stufe steigen.

6.1-C Die sechs Aufstiege auf der strukturellen und qualitativen Ebene

Sechs Kriterien steigen von „Erfüllt mit Einschränkung” auf „Erfüllt”. Diese Aufstiege folgen unterschiedlichen Treibern.

I.1 Funktionale Unersetzbarkeit. Der SOLL-Aufstieg ruht auf zwei sich verstärkenden Mechanismen. Native Rollups (EIP-8079) binden L2-Execution protokollär an L1 — ein Rollup, das native Verifikation nutzt, kann nicht auf eine andere L1 migrieren, ohne das Sicherheitsmodell grundlegend zu wechseln.⁷ Gleichzeitig expandiert die Reichweite: Die L1-zkEVM (EIP-8025) macht L1-Blöcke leichtgewichtig verifizierbar und erschließt neue Nutzungskategorien. Der EVM-Standard hat alle Top-10-L2s eingebunden und ist damit kein bloß nominaler Standard mehr.

I.3 Koordinationsfunktion. Der gestaffelte Finalitäts-Stack (Based Preconfirmations, Fast Confirmation Rule, Drei-Slot-Finalität) liefert im SOLL eine Koordinationsinfrastruktur über alle Zeithorizonte, die im IST nicht existiert.⁸ Native Rollups erhöhen die Wechselkosten strukturell: Tokenisierte Werte, die über EXECUTE-Verifikation gesichert sind, sind systemisch in Ethereum verankert.

I.4 Minimale tragfähige Garantien. Der Aufstieg ruht auf drei unabhängigen Mechanismen. FOCIL garantiert Zensurresistenz protokollär. Der Inactivity Leak gewährleistet automatisierte Selbstheilung ohne externe Koordination. Der gestaffelte Finalitäts-Stack liefert ökonomische Finalisierung innerhalb von zwei Sekunden — schneller als jede Clearing-Infrastruktur des traditionellen Finanzsystems.⁹

III.1 Langfristige Stabilität. Das Tiered State (Active, Hibernated, Dead) adressiert das State-Growth-Problem strukturell, nicht nur durch beschleunigte Außerdienststellung.¹⁰ History Expiry (EIP-4444, Phase 1 DEPL) reduziert die Node-Größenanforderungen. Der Fusaka-Upgrade-Zyklus ist erstmals im halbjährlichen Zeitplan geblieben — ein Reifegradindikator für die Upgrade-Koordination.

III.2 Adaptive Governance. Der strategische Pivot (Februar 2026) ist der stärkste Beleg: Ein paradigmatischer Richtungswechsel von Rollup-centric zu L1-first wurde ohne Krise, ohne Fork und ohne Autoritätsentzug vollzogen.¹¹ Das ist operativer Beweis für Governance-Kapazität über den Track Record taktischer Forks hinaus. Der Lean Ethereum Prozess zeigt die Fähigkeit zur Selbstverschlankung, nicht nur zur Addition.

III.3 Souveräne Portabilität. Die SOLL-Roadmap löst drei dokumentierte IST-Abhängigkeiten auf: die Relay-Abhängigkeit durch ePBS, die L2-Proof-Abhängigkeit durch Native Rollups und die RPC-Abhängigkeit durch Stateless Clients und Trustless RPC.¹² Diese drei Auflösungen transformieren operative Soft-Lock-ins in protokollär eliminierte Abhängigkeiten.

6.1-D Die fünf Kontinuitäten

Fünf Kriterien bleiben bei „Erfüllt mit Einschränkung”. In vier von fünf Fällen verbessert sich die Substanz der Erfüllung, ohne die Stufengrenze zu überschreiten.

I.2 Sicherheits- und Vertrauenslast. ePBS und die L1-zkEVM adressieren die Trust-Minimierung substantiell. Die verbleibende Einschränkung liegt an zwei Residualfaktoren: der Proving-Konjektur (die Sicherheit des SNARK-Systems hängt von Soundness-Annahmen ab, die noch kein formales Verifikationsäquivalent zu ECDSA haben) und der Access-Schicht (Helios und Trustless RPC sind DEPL bzw. PLAN, nicht breit deployt).

II.2 Offene Generativität. Die SOLL-Roadmap erweitert die generative Kapazität auf drei Ebenen: Compute (RISC-V als alternative Execution-Umgebung, RES), UX (NAA und Passkeys, DEPL) und L2-Erzeugung (Native Rollups). Die Einschränkung bleibt, weil RISC-V keine Governance-Verankerung hat und EOF — das wichtigste EVM-Erweiterungspaket — aus Fusaka zurückgezogen wurde.¹³

II.3 Unabhängige Verifizierbarkeit. Die Execution Layer Specification (ELS) als ausführbare Referenzimplementierung ist ein substantieller Fortschritt. Die Einschränkung liegt an einem methodischen Grenzproblem: Die formale Verifikation eines vollständigen zkEVM-Provers übersteigt den Stand der aktuellen Methoden.¹⁴ Das ist keine Roadmap-Lücke, sondern eine Grenze des Fachs.

II.4 Niedrigschwellige Inklusivität. Die NAA-Transformation (EIP-7702, EIP-8141) und das PeerDAS-Bandbreitenmodell verbessern Inklusivität auf Nutzer- und Verifizierer-Ebene substantiell. Die 32-ETH-Solo-Staking-Schwelle bleibt unverändert. Rainbow Staking — der einzige konzeptionelle Lösungspfad — befindet sich im Status RES ohne Implementierungscommitment. Das ist das einzige Kriterium, bei dem der IST-Defizit durch die SOLL-Roadmap nicht adressiert wird.

III.4 Hardware-Agnostik. Die protokolläre Hardware-Agnostik wird im SOLL durch PeerDAS (Bandbreitenreduktion ~85%) und Stateless Clients weiter verbessert. Die Cloud-Konzentration (~59% auf drei Providern) bleibt unverändert — ePBS und zkEVM adressieren die Protokollebene, nicht die physische Infrastrukturschicht.

6.1-E Die Urteilsverschiebung

Die M3-Kaskade im SOLL-Zustand durchläuft fünf Schritte.¹⁵ Keine Kritische Bedingung steht auf „Offen” — die Kaskade passiert den ersten Schritt. Keine Kritische Bedingung steht auf „Bedingt erfüllt” — die zweite Deckelung, die im IST das Urteil auf „Geeignet unter erheblichen Bedingungen” gesetzt hat, fällt weg. Die drei Strukturellen Bedingungen (I.1, I.3, III.1) stehen alle auf „Erfüllt” — der dritte Schritt setzt keine Deckelung. I.2 und II.1 stehen auf „Erfüllt mit Einschränkung”, nicht auf vollem „Erfüllt” — das Urteil bleibt unterhalb des schlichten „Geeignet”. Das Ergebnis ist „Geeignet mit Bedingungen”.

Der Grad wird separat bestimmt. Die sechs Qualitativen Kriterien (I.2, II.1, II.2, II.3, II.4, III.4) stehen alle auf mindestens „Erfüllt mit Einschränkung” — der Grad bleibt „Gut”.¹⁶

Die Verschiebung liegt im Fundament der Eignung, nicht in der Feinqualität. Der Grad verändert sich nicht — das System erfüllt die Qualitativen Kriterien in derselben Stärke wie im IST. Was sich verändert, ist die Sicherheit der Grundlage: Der Übergang von „Geeignet unter erheblichen Bedingungen” zu „Geeignet mit Bedingungen” bedeutet, dass die Kernfunktionen der Infrastruktur im SOLL-Zustand auf einer protokollär fundierteren Basis stehen.

Woran das SOLL-Urteil hängt

Das SOLL-Urteil beruht auf der Annahme, dass die Roadmap liefert, und genau diese Annahme bildet die größte Angriffsfläche der Bewertung. Die integrierte Belastbarkeitsbewertung beantwortet den Einwand mit einer Aussage über den heutigen Reifegrad jeder tragenden Komponente. Das Urteil über die Neutralität und Zensurresistenz (II.1) beruht auf FOCIL und ePBS, die beide den Planungs-Status tragen, und es ist damit das am wenigsten gesicherte der drei Kritischen Bedingungen. Das Urteil über die Minimalen tragfähigen Garantien (I.4) setzt in seiner Finalitäts-Schicht teils bereits deployten Based Preconfirmations und die in Client-Implementierung befindliche Confirmation Rule voraus, und damit, da die Based Preconfirmations die L2-Bestätigung bereits im Sekundenbereich liefern, während die L1-Bestätigung an der Confirmation Rule hängt, hält es auch in konservativer Lesart. Der Reifegrad sortiert die Verbesserungen, ohne ihr Eintreten zu datieren.

Die größte konzentrierte Abhängigkeit der Roadmap liegt in der zkEVM, die auf der aktiven EF-Roadmap zwischen ungesicherter Forschung und Planungs-Verankerung steht und fünf Kriterien zugleich trägt. Sie senkt die Validator-Vertrauenslast (I.2), trägt mit der protokollseitigen Verifikation ein viertes Koordinationsprimitiv neben Settlement, Execution und Datenverfügbarkeit (I.3), verstärkt den Ausführungsdeterminismus der Mindestgarantien (I.4), entkoppelt die Validierungskosten von der Execution-Kapazität (III.1) und entlastet die Validator-Hardware (III.4). Drei der fünf Kriterien sind Verbesserungen, die ohne die zkEVM nicht auf Erfüllt kämen: die Koordinationsfunktion (I.3), deren erweiterte Reichweite zusätzlich auf ePBS und der Native-Rollup-Bindung beruht, die Mindestgarantien (I.4) und die Langfristige Stabilität (III.1). Eine verzögerte oder ausbleibende zkEVM schwächte deshalb die Belastbarkeit der drei Hebungen, ohne bei den beiden Konstanten eine Verbesserung zu gefährden. Kein anderes Einzelfeature bündelt eine vergleichbare Querschnittswirkung, weshalb die konzentrierte Abhängigkeit der präziseste technische Ausdruck des größten Implementierungsrisikos ist.²¹

Die Reifegrad-Logik greift über die zkEVM hinaus und sortiert die sieben Verbesserungen nach der Reife ihrer schwächsten tragenden Komponente, wobei die Spanne weit auseinanderläuft. Am robustesten steht die Adaptive Governance (III.2), deren Fundament ein rein demonstrierter Prozess ist, getragen vom strategischen L1-Pivot des Februars 2026 und von einer Hard-Fork-Kadenz ohne Kettenspaltung. Die Adaptive Governance fällt selbst im pessimistischsten Teillieferungs-Szenario nicht zurück. Am schwächsten steht die Langfristige Stabilität (III.1), deren zentrales Element, das Tiered State System, auf ungesicherter Forschung ohne eigenes EIP beruht und sie zur taxonomisch fraglichsten Verbesserung des Deltas macht. Zwischen den Polen liegen die tragenden Komponenten mittlerer Reife, ePBS mit seiner Planungs-Verankerung ohne garantierten Fork-Slot und die Native Account Abstraction, die inkrementell auf der bereits deployten EIP-7702 aufsetzt.²² Näher am schwachen Pol liegen die Funktionale Unersetzbarkeit (I.1) und die Koordinationsfunktion (I.3), deren Hebung an den Native Rollups (EIP-8079) hängt. Diese stehen als Draft-EIP im Forschungsstatus schwächer verankert als die Planungsstufe von ePBS, aber stärker als das Tiered State System ohne eigenes EIP. Die Verteilung der Reife und die Verteilung der Urteilslast laufen gegeneinander. Die Adaptive Governance, die robusteste der sieben Verbesserungen, trägt das Gesamturteil nicht, weil sie als Qualitatives Kriterium allein den Grad berührt, der schon im Ausgangszustand gesichert war. Urteilstragend sind neben der Neutralität und Zensurresistenz (II.1) gerade jene Bewegungen, die am schwachen Pol liegen: die Funktionale Unersetzbarkeit (I.1), die Koordinationsfunktion (I.3) und die Langfristige Stabilität (III.1). Von den dreien genügen zwei, weil der dritte Kaskadenschritt erst bei zwei schwachen Ausprägungen unter die erreichte Kategorie deckelt. Das SOLL-Urteil ruht damit auf einer unersetzlichen Bewegung und auf zwei von drei weiteren, die an Forschungslinien ohne finalisierte Spezifikation hängen, und es ist von unfertigerer Arbeit abhängiger, als die Reifesortierung für sich genommen erkennen lässt.

6.2 Persistente Grenzen des Systems

6.2-A Die Krisen-Reaktions-Lücke

Ein Muster durchzieht drei Kriterien des SOLL-Profils und bildet eine quer-schneidende Lücke, die im SOLL-Urteil nicht einzeln lokalisiert ist, aber systemische Relevanz hat.

Builder-Konzentration. ePBS löst die protokolläre Relay-Abhängigkeit und erzwingt die korrekte Zahlungsabwicklung zwischen Proposer und Builder. Was ePBS nicht adressiert, sind die ökonomischen Wurzeln der Builder-Konzentration: Latenzvorteile durch geographische Nähe zu Börsen-Systemen, Cross-Domain-Arbitrage-Kapazitäten und Exclusive Order Flow, der rund 54 Prozent des Blockwerts ausmacht.¹⁷ Selbst bei vollständig aktiviertem ePBS können drei bis fünf Builder durch ökonomische Überlegenheit mehr als 70 Prozent der Block-Produktion kontrollieren. Attested Program Sequencing (APS) und MEV Burn befinden sich im Status RES und bieten keinen operativen Lösungspfad.¹⁸

Liquid Staking. Lido hält rund 23 Prozent des gestakten ETH — nach dem Rückgang von über 32 Prozent. Ein protokolläres Cap, das bei einem bestimmten Marktanteil eine strukturelle Rückkopplungsschranke setzt, existiert nicht.¹⁹ DVT (Obol, SSV) wächst — 547.968 ETH unter DVT bei Lido allein, plus 57 Prozent QoQ-Wachstum — aber DVT ist eine Dezentralisierungsmaßnahme auf Validator-Ebene, kein Substitut für ein Staking-Cap auf Betreiberebene. Rainbow Staking (RES) könnte eine strukturelle Lösung bieten, hat aber kein Implementierungscommitment.

Emergency Response Plan. Das Ethereum-Ökosystem hat in der Reaktion auf den Prysm-Bug im Dezember 2025 demonstriert, dass schnelle Koordination möglich ist — aber die Koordination erfolgte durch informelle Netzwerke und EF-Kommunikationskanäle, nicht durch einen protokollär verankerten Mechanismus.²⁰ Der Emergency Response Plan ist dokumentiert, die Koordinationsverpflichtung ist nicht erzwingbar. In einem System, das sich als souveränitätsresistente Infrastruktur versteht, ist informelle Krisenkoordination eine strukturelle Lücke zwischen Anspruch und Realität.

Diese drei Befunde liegen quer über II.1, III.1 und III.2. Das SOLL-Urteil ist „Geeignet mit Bedingungen, Grad Gut” — die Krisen-Reaktions-Lücke drückt keinen dieser Befunde auf eine niedrigere Stufe, qualifiziert aber jeden. Die Frage, ob Ethereum in einer systemischen Krise — einem koordinierten Staker-Austritt, einem kritischen Fehler in einem dominierten Client, einem simultanen Angriff auf mehrere Ebenen — die Resilienz demonstrieren kann, die ein fundamentaler Infrastrukturanspruch erfordert, bleibt im SOLL-Rahmen beantwortet, aber unter Vorbehalt.

6.3 Grenzen des Bewertungsrahmens: Was kein Kriterium misst

Die Krisen-Reaktions-Lücke des vorigen Abschnitts ist eine Grenze, die der Bewertungsrahmen noch erfasst, weil sie quer über drei seiner Kriterien liegt und als deren gemeinsamer Befund eintritt. Eine zweite Grenze betrifft die Reichweite des Instruments und nicht das System, weil vier Eigenschaften Ethereums außerhalb dessen liegen, worauf überhaupt eines der zwölf Kriterien zielt. Das Urteil über die Eignung als Infrastruktur hat sie nicht schwach bewertet, sondern gar nicht adressiert, und über das, was kein Kriterium misst, kann es nichts aussagen.

Vier Eigenschaften außerhalb des Rasters

Permissionless Composability erscheint im Bewertungsrahmen, doch nur in einer Verengung. Das zweite Kriterium der zweiten Dimension (II.2) prüft die atomare Composability als binären Indikator, ob Smart Contracts innerhalb einer Transaktion miteinander interagieren können. Das Kriterium ergänzt den Indikator um die erlaubnisfreie Deployment-Möglichkeit und das offene Tooling. Außerhalb der Messung liegt die Composability als kombinatorische Systemeigenschaft, das exponentielle und erlaubnisfreie Zusammenspiel beliebig vieler Contracts zu Konstruktionen, die niemand vorhergesehen hat. In den sogenannten Money Legos der DeFi-Protokolle nimmt das Zusammenspiel Gestalt an. Das Kriterium erfasst, ob Contracts interagieren können, und nicht die generative Mächtigkeit ihrer offenen Kombinierbarkeit als eigene Qualität. Über diese Mächtigkeit macht das Urteil keine Aussage, weil das Kriterium sie auf eine Ja-Nein-Frage zurückführt, die ihr Bestehen voraussetzt, ohne ihre Reichweite zu messen.

Die kryptographische Systemzustandsverifikation steht dem Bewertungsrahmen näher und bleibt ihm doch entzogen. Das dritte Kriterium der zweiten Dimension (II.3) prüft, ob Verifikation überhaupt möglich ist. Das Kriterium liest das aus formalen Verifikationswerkzeugen, einer formalen EVM-Spezifikation und der Verbreitung von Audits, als Angebotsseite zur Vertrauenslast (I.2). Jenseits der bloßen Möglichkeit liegt die beweisgestützte Form der Verifikation, in der das System seinen eigenen Gesamtzustand mathematisch beweist, über zkEVM und Stateless Clients, statt ihn über institutionelles Vertrauen abzusichern. Das Kriterium misst, ob ein Contract sich prüfen lässt, und nicht, dass das System den kryptographischen Beweis seiner Korrektheit in sich trägt. Über die Verschiebung von institutionellem zu mathematischem Vertrauen sagt das Urteil nichts, weil das Kriterium die Möglichkeit der Verifikation erfasst und nicht den Grund, auf dem sie beruht.

Die dezentrale Selbstentwicklungsfähigkeit findet im Bewertungsrahmen ein Kriterium, das an ihr vorbeigreift. Das zweite Kriterium der dritten Dimension (III.2) prüft, ob die Governance adaptiv ist, ob das System sich weiterentwickeln und auf neue Anforderungen reagieren kann. Außerhalb der Adaptivität liegt die Selbstentwicklung ohne Zentrum, die Weiterentwicklung über Rough Consensus ohne eine Instanz, die Änderungen anordnen könnte. Jede Änderung muss freiwillig von einer Mehrheit der Node-Betreiber übernommen werden. Kapitel 2 nennt dieses Modell selbst einen Extremfall der Mayntz-Spannung zwischen Steuerung und Selbstorganisation, weil das System sich entwickelt, ohne dass eine zentrale Stelle es lenkt. Das Kriterium erfasst, ob adaptive Governance vorliegt, und nicht die zentrumslose Selbstentwicklung, sodass das Urteil das Fehlen einer Steuerungsinstanz nicht in den Blick bekommt.

Privacy fällt aus dem Bewertungsrahmen heraus, und im Unterschied zu den drei vorigen Grenzen verengt kein Kriterium sie, weil überhaupt keines auf sie zielt. Keine der drei Dimensionen, weder die Strukturelle Fundierung noch die Qualitative Tragfähigkeit noch die Resilienz und Souveränität, enthält eine Frage nach Vertraulichkeit. Bei den ersten drei Grenzen verengt ein Kriterium die Eigenschaft auf einen Indikator, hier fehlt der Messpunkt vollständig. Die Lücke besagt, es gebe gar kein Kriterium. Außerhalb des Bewertungsrahmens liegt die Vertraulichkeit als Protokolleigenschaft, in die Architektur eingebaut über Encrypted Mempool und Pre-Inclusion-Privacy. Privacy ist die einzige der vier Grenzen, die in der geprüften Roadmap ein Korrelat besitzt, verankert im Lean-Ethereum-Programm (5.1-B und 5.1-C). Über eine real angelegte Eigenschaft des Zielzustands verliert das Urteil dennoch kein Wort, weil das Instrument für sie keinen Messpunkt vorsieht.

Die vier Eigenschaften sind kein verstreuter Rest, den die Kriterien zufällig nicht trafen, denn sie teilen eine gemeinsame Lage, jeweils außerhalb dessen zu liegen, worauf die Bewertung überhaupt zielt. Jede von ihnen liegt dort, wo das System eine Eigenschaft trägt und das Instrument keine Frage stellt. Dass es vier sind und kein Einzelfall, verrät ein Muster, dessen Deutung über die Reichweite dieser Bewertung hinausweist und die Kapitel 7 aufnimmt.

6.4 Synthese und Beantwortung der Forschungsfrage

Ethereum trägt heute als Settlement- und Datenverfügbarkeits-Schicht ein Kapital in der Größenordnung von 100 Milliarden US-Dollar, das über 60 Prozent des gesamten On-Chain-gesicherten DeFi-Kapitals ausmacht. Auf derselben Infrastruktur werden Stablecoins im Wert von etwa 166 Milliarden US-Dollar emittiert, mehr als die Hälfte des globalen Stablecoin-Marktes, und rund 65 Prozent aller neuen Smart Contracts entstehen auf den Layer-2-Systemen, deren Settlement und Datenverfügbarkeit die Basisschicht trägt. Das System bindet über 31.000 aktive Entwickler und damit mehr als 70 Prozent aller Blockchain-Entwickler weltweit. Das ist die konkrete Substanz, um die es in der Bewertung geht, bevor die Frage nach ihrer Eignung beantwortet werden kann. Erfüllt diese Architektur die Anforderungen, die an eine fundamentale digitale Infrastruktur zu stellen sind? Die Antwort lautet ja, in beiden untersuchten Zuständen, aber in beiden nur bedingt.

Fast alle Anforderungen erfüllt das System schon heute, je mit Abstrichen, und die eine, die es am deutlichsten nach unten zieht, ist die Zensurresistenz auf der Ebene der Blockproduktion. Gegenwärtig laufen etwa 15 Prozent der Blöcke über Relays, die Transaktionen sanktionierter Adressen ausschließen, während Titan als größter Builder offen darauf verzichtet. Im November 2022 lag der Anteil bei 79 Prozent, was bedeutete, dass eine staatliche Sanktionsliste faktisch kontrollierte, welche Transaktionen ein erlaubnisfreies System verarbeitete. Dieser marktgetriebene Rückgang vollzog sich ohne jeden Eingriff in das Protokoll, allein weil nicht-zensierungs-gebundene Builder profitabler arbeiten und der Markt sich zu ihnen verschoben hat. Das ist die erhebliche Bedingung in einem Bild: Die Zensurresistenz funktioniert, doch sie beruht auf der Marktstruktur, und eine Marktstruktur kann sich umkehren.

Genau an dieser Bedingung setzt die Roadmap an, und zwei Entwürfe würden sie protokollseitig auflösen. FOCIL, ein Validator-Komitee-basiertes Inclusion-List-System, würde die Aufnahme jeder benannten Transaktion protokollseitig erzwingen. ePBS, die protokollnative Verankerung der Proposer-Builder-Separation, würde die Relays als Off-Chain-Vermittler entfernen, über die das OFAC-Filtern heute überhaupt erst stattfindet. Beide tragen den Status PLAN, sind entworfen, aber nicht geliefert. Darin liegt der eigentliche Wandel, denn die Art der Bedingung selbst verschiebt sich: Heute hängt die Eignung daran, wie sich der Builder-Markt verhält, nach voller Umsetzung hinge sie daran, ob die geplanten Mechanismen halten, was ihr Entwurf vorsieht. Die Roadmap tauscht damit eine Marktabhängigkeit gegen eine Umsetzungsabhängigkeit, und die Bedingung wird dadurch nicht kleiner, sie wird von anderer Art.

Die Bedingtheit lässt sich nicht ablösen

Selbst die vollständige Umsetzung der Roadmap löst die Bedingtheit nicht auf, und ein einzelner fehlender Mechanismus macht das greifbar: Ethereum besitzt keine Pausetaste. Wie in 6.2 gezeigt, kann bei einem kritischen Bug niemand das Netzwerk anhalten. Die einzige Antwort bleibt ein aufwendiger Notfall-Hard-Fork. Die fehlende Pausetaste ist kein Feature, das eine spätere Roadmap nachreicht, sie ist die Kehrseite der Zentrumslosigkeit selbst. Wer die Bedingtheit auflösen wollte, müsste eine Instanz einführen, die im Krisenfall eingreift, anhält oder haftet, und gäbe genau die Eigenschaft auf, die Ethereum zu dem macht, was die Arbeit bewertet hat. Solange das System ohne Zentrum bleibt, bleibt seine Reaktion auf akute Krisen an soziale Koordination gebunden. Die Bedingtheit ist daher keine Unfertigkeit, die eine kommende Roadmap behebt, sondern eine Folge der Architekturentscheidung gegen ein Zentrum.

Ein Vorbehalt zum Instrument

Ein Vorbehalt gehört zum Urteil, und er betrifft das Instrument, nicht den Gegenstand. Das Bewertungsraster ist regelbasiert aufgebaut und nicht summierend, sodass kleine Einschränkungen unterhalb seiner Schwellen nicht ins Gesamturteil durchschlagen. Zwei Systeme von sehr verschiedener Substanz können deshalb das gleiche Urteil tragen, und der Ausgangszustand und der Zielzustand zeigen das aneinander: in der Substanz weit auseinander, im formalen Urteil nur einen Schritt. Wer allein das Urteil liest, übersieht, wie viel Substanz zwischen den beiden Zuständen liegt. Das ist keine Schwäche des Urteils, es ist eine Eigenschaft des Instruments, die der Leser mitführen muss.

Das Urteil steht damit fest: Ethereum ist als fundamentale digitale Infrastruktur geeignet, heute unter erheblichen, nach voller Umsetzung der Roadmap mit Bedingungen, in keinem der beiden Zustände unbedingt. Was die bedingte Eignung über das Bewertungsergebnis hinaus bedeutet, für die Akteure, die auf der Infrastruktur aufbauen, ihr vertrauen oder sie regulieren, nimmt Kapitel 7 auf. Das letzte Wort behält das Urteil, nicht der Vorbehalt.