Theoretischer Rahmen und Methodik

Dieses Kapitel legt das theoretische und methodische Fundament der Arbeit dar. Abschnitt 2.1 verortet die Forschungsfrage in der Infrastrukturtheorie. Abschnitt 2.2 begründet, warum ein eigener Bewertungsrahmen entwickelt werden muss, dokumentiert die Forschungslücke und grenzt gegen bestehende Ansätze ab. Abschnitt 2.3 präsentiert den Bewertungsrahmen vollständig, von der Bewertungslogik über die zwölf Kriterien bis zu den Scope-Grenzen. Die Arbeit verfolgt dabei ein doppeltes Ziel: Sie liefert ein begründetes Urteil zur Forschungsfrage und dokumentiert gleichzeitig Evidenz und Schlussfolgerungen so transparent, dass der Leser zu einem eigenständigen, möglicherweise abweichenden Urteil gelangen kann.

2.1 Was ist Infrastruktur?

Die Forschungsfrage dieser Arbeit lautet, ob Ethereums Architektur die Anforderungen erfüllt, die an eine fundamentale digitale Infrastruktur zu stellen sind. Bevor diese Frage beantwortet werden kann, muss geklärt werden, was der Begriff Infrastruktur in einem akademischen Kontext bedeutet. Im politischen und medialen Sprachgebrauch ist der Begriff inflationär geworden: Breitbandnetze werden als digitale Infrastruktur bezeichnet, Bildungssysteme als gesellschaftliche Infrastruktur, Ladestationen als Ladeinfrastruktur, und in der Kryptoindustrie firmiert jedes Protokoll mit mehr als einer Handvoll Nutzern als Infrastruktur. Die Alltagsverwendung folgt einer impliziten Heuristik, nach der jedes System, das wichtig erscheint und von vielen genutzt wird, den Titel Infrastruktur verdient. Für eine akademische Bewertung reicht diese Heuristik nicht aus, weil sie keine Trennlinie zwischen Infrastruktur und Nicht-Infrastruktur zieht und damit die Forschungsfrage unbeantwortbar macht. Die folgenden theoretischen Perspektiven liefern die begriffliche Schärfe, die eine solche Trennlinie ermöglicht.

Die ökonomische Definition

Brett Frischmann hat 2012 in Infrastructure: The Social Value of Shared Resources eine grundlegende ökonomische Infrastrukturdefinition vorgelegt.¹ Seine zentrale Einsicht verschiebt den analytischen Fokus: Infrastruktur definiert sich durch das, was sie ermöglicht, nicht durch das, was sie ist. Ob ein System physisch oder digital, groß oder klein, teuer oder günstig ist, sagt nach Frischmann nichts darüber aus, ob es Infrastruktur ist. Entscheidend sind drei funktionale Kriterien. Das erste Kriterium ist Nicht-Rivalität im Konsum bis zu einer Kapazitätsschwelle: Die Nutzung durch einen Akteur schließt die gleichzeitige Nutzung durch andere nicht aus, solange das System nicht an seine Kapazitätsgrenze stößt. Das zweite Kriterium betrifft die Nachfragestruktur: Die Nachfrage nach dem System wird primär von produktiven Aktivitäten getrieben, die das System als Input benötigen, wobei der gesellschaftliche Gesamtnutzen den individuellen Nutzen übersteigt. Das dritte Kriterium ist Input-Charakter: Das System dient als Produktionsfaktor für weiterführende Aktivitäten und ist kein Endprodukt.

Das Straßennetz veranschaulicht die drei Kriterien. Es ist nicht-rival, solange kein Stau herrscht, denn die Fahrt eines Nutzers schließt die Fahrt eines anderen nicht aus, bis die Kapazitätsgrenze der Straße erreicht ist. Es generiert produktive Nachfrage, weil Handel, Arbeitsmobilität und gesellschaftliche Teilhabe auf einem funktionierenden Straßennetz aufbauen und der gesellschaftliche Gesamtnutzen den individuellen Fahrnutzen übersteigt. Es hat Input-Charakter, weil ohne Straßen weder ein Logistiksektor noch ein flächendeckender Einzelhandel noch ein Arbeitsmarkt mit Pendlerbewegungen existieren könnte. Frischmanns drei Kriterien beschreiben damit eine spezifische ökonomische Rolle: Infrastruktur ist eine Ermöglichungsstruktur, deren Wert sich in den Aktivitäten realisiert, die sie ermöglicht.

Aus der Einsicht zieht Frischmann eine ordnungspolitische Konsequenz, die für den Gegenstand dieser Arbeit unmittelbar relevant ist. Weil Infrastruktur ihren Wert durch Ermöglichung erzeugt und der Wert mit der Breite der Nutzung steigt, ist Commons-Management, also nicht-diskriminierender offener Zugang, in vielen Fällen ökonomisch effizienter als die Einschränkung des Zugangs durch private Eigentumsrechte.² Ethereums Permissionless-Design, das jedem Akteur die Nutzung des Netzwerks ohne Genehmigung eines Gatekeepers ermöglicht, ist eine technische Implementierung genau dieses Arguments. Der Zusammenhang zwischen Frischmanns Infrastrukturtheorie und Blockchain-Systemen ist dabei kein Analogieschluss dieser Arbeit: James Grimmelmann und A. Jason Windawi haben 2023 im William & Mary Law Review, einem angesehenen amerikanischen Law Review, gezeigt, dass Blockchains Frischmanns Infrastrukturkriterien erfüllen und gleichzeitig als Semicommons funktionieren, also als Systeme mit verschränkter privater und gemeinsamer Ressourcennutzung.³⁴ Die vorliegende Arbeit baut auf der akademisch etablierten Verbindung auf.

Die soziologische Erweiterung

Frischmanns Definition ist ökonomisch und funktioniert für Systeme, deren Wertschöpfung messbar ist. Susan Leigh Star hat 1999 in The Ethnography of Infrastructure eine Perspektive eingeführt, die über die ökonomische Funktionsbestimmung hinausgeht.⁵ Ihre zentrale Einsicht lautet: Infrastruktur ist relational. Sie entsteht nicht durch objektive Eigenschaften eines Systems, sondern in Relation zu organisierten Praktiken. Was für den Ingenieur, der das Glasfasernetz wartet, ein Arbeitsobjekt ist, ist für den Nutzer, der über das Netz eine Videokonferenz führt, unsichtbare Infrastruktur. Was für den Bewohner eines Industrielandes selbstverständliche Infrastruktur ist, kann für den Bewohner eines anderen Landes ein unerreichbares Gut sein. Star hat eine weitere Eigenschaft identifiziert, die zum Standardrepertoire der Infrastrukturforschung gehört: Infrastruktur wird sichtbar beim Zusammenbruch. Solange sie funktioniert, ist sie unsichtbar. Niemand denkt an das Stromnetz, bis der Strom ausfällt, und niemand denkt an das Domain Name System, bis eine Website nicht mehr erreichbar ist.

Stars Perspektive verändert die Forschungsfrage dieser Arbeit auf eine Weise, die den gesamten Bewertungsrahmen prägt. Wenn Infrastruktur relational ist, dann lässt sich die Frage, ob Ethereum Infrastruktur ist, nicht binär beantworten, weil die Antwort davon abhängt, für wen und in welchem Anwendungskontext sie gestellt wird. Für einen DeFi-Entwickler, dessen gesamte Geschäftslogik auf Ethereum-Smart-Contracts aufbaut, ist Ethereum bereits heute Infrastruktur im Sinne Stars, denn das System ist für seine organisierte Praxis unsichtbare Voraussetzung. Für einen Nutzer, der eine einzelne Transaktion tätigt, ist es eher ein Werkzeug. Genau diese Kontextabhängigkeit operationalisiert das Meta-Muster, das die gesamte Bewertungslogik dieser Arbeit prägt: Die Ausprägung muss zum Anspruch passen. Der Bewertungsrahmen bewertet nicht, ob Ethereum Infrastruktur in einem absoluten Sinne ist, sondern ob es die Anforderungen erfüllt, die an eine fundamentale digitale Infrastruktur zu stellen sind, also kontextbezogen und anspruchskalibriert.

Digitale Infrastruktur als eigenständige Kategorie

Die bisherige Theorie beschreibt überwiegend physische Infrastruktur, und die Übertragung auf digitale Systeme erfordert eine eigenständige konzeptionelle Grundlage. Ole Hanseth und Kalle Lyytinen haben 2010 Informationsinfrastrukturen als geteilte, offene, heterogene und evolvierende soziotechnische Systeme definiert und zwei fundamentale Designprobleme identifiziert, die digitale von physischer Infrastruktur unterscheiden.⁶ Das Bootstrap-Problem beschreibt die Herausforderung, dass eine Infrastruktur frühen Nutzern sofort nützlich sein muss, um überhaupt die Dynamik zu gewinnen, die spätere Netzwerkeffekte ermöglicht. Das Adaptabilitätsproblem beschreibt die Herausforderung, dass lokale Designentscheidungen unbegrenztes Wachstum und funktionale Unsicherheit berücksichtigen müssen, weil die zukünftigen Nutzungsformen der Infrastruktur zum Zeitpunkt des Designs nicht vorhersehbar sind. Tilson, Lyytinen und Sørensen haben im selben Jahr argumentiert, dass digitale Infrastruktur eine eigene analytische Kategorie darstellt, mit eigenen Paradoxien, insbesondere der Spannung zwischen Offenheit und Kontrolle, und eigenen Forschungsfragen, die sich aus der Verschränkung von technischen und institutionellen Dynamiken ergeben.⁷

Beide Probleme manifestieren sich im Gegenstand dieser Arbeit. Ethereum musste 2015, finanziert durch einen Crowdsale von 18,3 Millionen US-Dollar, mit einem konkreten Anwendungsfall starten, der frühen Nutzern sofort nützlich war: der Möglichkeit, Smart Contracts bereitzustellen und auszuführen. Die EVM, Ethereums virtuelle Maschine, lieferte vom ersten Tag an ein programmierbares Ausführungsumfeld, das über reine Zahlungstransaktionen hinausging und damit die Grundlage für die Netzwerkeffekte schuf, die das System heute tragen. Das Adaptabilitätsproblem manifestiert sich in der Roadmap-Komplexität, die Kapitel 5 dieser Arbeit im Detail beschreibt: Das System muss sich weiterentwickeln, um den wachsenden Anforderungen an Skalierung, Datenverfügbarkeit und Nutzerzugang gerecht zu werden, ohne die bestehende Nutzerbasis und die auf dem System aufbauenden Anwendungen zu brechen.

Der begriffliche Boden der Bewertungskriterien

Die drei Perspektiven definieren zusammen den analytischen Rahmen, in dem die Forschungsfrage steht. Frischmann liefert die ökonomische Grundlage: Infrastruktur ist eine Ermöglichungsstruktur, deren offener Zugang sich ökonomisch begründen lässt. Star liefert die soziologische Vertiefung: Infrastruktur ist relational und kontextabhängig, was eine binäre Beantwortung der Forschungsfrage ausschließt und eine anspruchskalibrierte Bewertung erfordert. Hanseth und Lyytinen liefern die informationstechnische Spezifizierung: Digitale Infrastruktur unterliegt eigenen Designproblemen, die bei der Bewertung eines konkreten Systems berücksichtigt werden müssen. Die Frage, ob Ethereum fundamentale digitale Infrastruktur ist, lässt sich vor diesem Hintergrund als eine Frage stellen, die akademisch bearbeitbar ist: Sie fragt, ob ein konkretes System die Eigenschaften aufweist, die reale Infrastrukturen teilen. Die drei Perspektiven liefern damit den begrifflichen Boden, aus dem die Bewertungskriterien analytisch gewonnen werden. Was fundamentale digitale Infrastruktur konstitutiv auszeichnet, bestimmt sich aus dem Zusammenspiel der ökonomischen, der relationalen und der informationstechnischen Bestimmung des Infrastrukturbegriffs. Kapitel 3 prüft die so hergeleiteten Kriterien anschließend an sieben realen Infrastrukturen. Die Theorie liefert den Rahmen und die Herleitung, die sieben Referenzsysteme liefern den empirischen Prüfstein.

Für eine deutschsprachige Arbeit ist ergänzend die Tradition der großen technischen Systeme relevant. Renate Mayntz hat 1993 große technische Systeme als Komponenten funktionsspezifischer Infrastruktursysteme konzipiert und die Spannung zwischen Steuerung und Selbstorganisation als zentrales Forschungsproblem identifiziert.⁸ Die Spannung beschreibt einen Grundkonflikt, der in jeder Infrastruktur angelegt ist: Je größer und komplexer das System, desto schwieriger wird zentrale Steuerung, und desto stärker wird die Eigendynamik des Systems. Ethereums Governance-Modell, das dezentral und ohne formale Steuerungsinstanz operiert und auf dem Prinzip des Rough Consensus beruht, ist ein Extremfall der Spannung. Es gibt keine zentrale Instanz, die Protokolländerungen anordnen kann. Jede Änderung muss von einer Mehrheit der Node-Betreiber freiwillig übernommen werden. Die Frage, ob dieses Modell die Anforderungen an adaptive Governance erfüllt, die an fundamentale Infrastruktur zu stellen sind, ist eine der zwölf Bewertungsdimensionen des Bewertungsrahmens dieser Arbeit.

Eine institutionenökonomische Perspektive ergänzt den Rahmen. Sinclair Davidson, Primavera De Filippi und Jason Potts haben 2018 argumentiert, dass Blockchain eine institutionelle Innovation darstellt, die Oliver Williamsons Governance-Framework über die Dichotomie von Märkten und Hierarchien hinaus erweitert.⁹ Ethereum kann in dieser Perspektive als ein System gelesen werden, das eine dritte Governance-Form realisiert: protokollbasierte Koordination durch algorithmische Regeln, die weder marktlich verhandelt noch hierarchisch angeordnet werden, sondern durch den Konsens der Netzwerkteilnehmer entstehen.

2.2 Warum ein eigener Bewertungsrahmen?

Die Forschungslücke

Die im vorigen Abschnitt dargestellte Infrastrukturtheorie bietet einen ausgereiften begrifflichen Apparat, um die Frage nach Infrastruktureignung zu stellen. Für Blockchain-Systeme im Allgemeinen und Ethereum im Speziellen ist dieser Apparat bislang nicht systematisch angewandt worden. Svein Ølnes und Arild Jansen haben 2018 und 2021 die relationale Infrastrukturdefinition von Star und Ruhleder sowie die Informationsinfrastruktur-Theorie von Hanseth und Lyytinen auf Blockchain allgemein übertragen und gezeigt, dass Blockchain-Systeme als Informationsinfrastrukturen konzipiert werden können.¹⁰¹¹ Ihre Arbeiten identifizieren Eigenschaften, die Blockchain mit den in der IS-Forschung beschriebenen Informationsinfrastrukturen teilt, etwa die Offenheit und die Heterogenität der Nutzer, und schließen daraus, dass das Vokabular der Infrastrukturforschung auf Blockchain anwendbar ist. Die Arbeiten beschreiben Blockchain als Infrastruktur. Ob ein konkretes System die Anforderungen fundamentaler Infrastruktur erfüllt, prüfen sie nicht: Es fehlen operationalisierte Kriterien, Schwellenwerte und ein Bewertungsmechanismus. Kelsie Nabben hat 2023 Web3 als self-infrastructuring analysiert, also als einen Prozess, in dem die Community die Infrastruktur, die sie nutzt, selbst hervorbringt und fortlaufend verändert.¹² Ihre Analyse arbeitet mit dem Vokabular der Infrastructure Studies und liefert Einsichten in die Entstehungsdynamik dezentraler Infrastruktur, zielt aber auf die Prozessbeschreibung, nicht auf die Eignungsbewertung. Paul Dylan-Ennis, Donncha Kavanagh und Luis Araujo haben 2023 Ethereum als soziotechnisches Projekt mit drei Imaginaries untersucht, drei Vorstellungswelten, die die Ethereum-Community antreiben: Ethereum als Weltcomputer, als dezentrale Finanzinfrastruktur und als Koordinationsprotokoll.¹³ Ihre soziologische Analyse gibt Aufschluss über die Selbstbeschreibung und die inneren Spannungen der Community. Eine Bewertung der Architektur oder der Infrastruktureignung anhand überprüfbarer Kriterien leistet sie nicht.

Die Lücke, die diese Arbeit füllt, ist damit spezifisch: Es existiert keine rahmenbasierte Bewertung, die operationalisierte Kriterien definiert, transparente Schwellenwerte setzt und ein reproduzierbares Bewertungsverfahren anwendet, um zu prüfen, ob Ethereum die Anforderungen einer fundamentalen Infrastruktur erfüllt. Die genannten Arbeiten steuern Vorarbeiten bei, auf denen diese Arbeit aufbaut, aber keine von ihnen beantwortet die Forschungsfrage.

Abgrenzung gegen bestehende Blockchain-Bewertungsansätze

Der Bedarf an einem eigenständigen Bewertungsrahmen wird deutlicher, wenn man die bestehenden Bewertungsansätze aus der Blockchain-Literatur betrachtet. Was die Ansätze verbindet, ist eine gemeinsame Stoßrichtung: Sie messen Dezentralisierung oder organisationale Eignung, aber sie bewerten keine Infrastruktureigenschaften im infrastrukturtheoretischen Sinne.

Balaji Srinivasan und Leland Lee haben 2017 den Nakamoto-Koeffizienten vorgeschlagen, der den Dezentralisierungsgrad eines Systems als die minimale Anzahl von Akteuren misst, die zusammenwirken müssten, um das System zu kompromittieren.¹⁴ Der Koeffizient erfasst eine wichtige Eigenschaft, sagt aber nichts über Infrastruktureignung aus: SWIFT, das globale Finanznachrichtensystem, hat einen Nakamoto-Koeffizienten nahe eins, weil es von einer einzigen Organisation betrieben wird, und ist dennoch fundamentale Infrastruktur des internationalen Zahlungsverkehrs. Adem Efe Gencer und Kollegen haben 2018 eine empirische Dezentralisierungsmessung über Mining-Verteilung und Netzwerktopologie vorgelegt, die den operativen Dezentralisierungsgrad quantifiziert, aber weder Governance-Dimensionen noch institutionelle Einbettung erfasst.¹⁵ Die jüngste Systematisierung des Forschungsstrangs, eine 2025 publizierte SoK-Studie (Systematization of Knowledge) zur Messung von Blockchain-Dezentralisierung, inventarisiert alle existierenden Dezentralisierungsmetriken und macht damit sichtbar, dass der gesamte Forschungsstrang auf Dezentralisierungsmessung ausgerichtet ist.¹⁶ Die Frage, ob ein System die Anforderungen an Infrastruktur erfüllt, wird von keiner der Metriken behandelt.

Neben der Dezentralisierungsmessung existieren Ansätze, die Blockchain-Eignung aus organisationaler Perspektive bewerten. Spencer-Hicken und Kollegen haben 2023 ein Blockchain Feasibility Assessment für Organisationen entwickelt, das bewertet, ob ein Unternehmen Blockchain-Technologie einsetzen sollte. Es trifft damit eine Übernahmeentscheidung und bewertet keine Infrastruktureignung.¹⁷ Jensen und Kollegen haben 2021 die Governance-Dezentralisierung von DeFi-Protokollen untersucht, die auf der Anwendungsschicht operieren, nicht auf der Basisschicht, die diese Arbeit bewertet.¹⁸ Pincheira und Kollegen haben 2023 die Infrastrukturkosten von Blockchain-Systemen analysiert, wobei sie den Begriff Infrastruktur im IT-technischen Sinne verwenden, als Oberbegriff für Server, Speicher und Netzwerkressourcen, nicht im gesellschaftlichen Sinne einer Ermöglichungsstruktur nach Frischmann.¹⁹

Die Konsequenz aus der Bestandsaufnahme ist eindeutig: Die bestehenden Ansätze fragen, wie dezentral ein System ist oder ob Blockchain für eine bestimmte Organisation geeignet ist. Die Forschungsfrage dieser Arbeit lautet, ob ein System die Anforderungen erfüllt, die an fundamentale Infrastruktur zu stellen sind. Diese Arbeit beantwortet die Frage mittels eines Bewertungsrahmens, der Infrastruktureigenschaften operationalisiert, gestützt auf die Infrastrukturtheorie und validiert an realen Infrastrukturen. Ein Bewertungsrahmen, der aus der Blockchain-Literatur stammt und Dezentralisierungsmetriken aggregiert, kann die Forschungsfrage nicht beantworten, weil er die falsche Eigenschaft misst.

Die Methodik der Konstruktion des Bewertungsrahmens

Die Arbeit validiert ihren Bewertungsrahmen an sieben Referenzinfrastrukturen: Stromnetz, Internet (TCP/IP), Straßennetz, SWIFT, GPS, Cloud-Infrastruktur und Rechtssystem. Die sieben Fälle wurden gewählt, weil sie fünf Infrastrukturtypen abdecken: physisch (Stromnetz, Straßennetz), digital-offen (Internet/TCP-IP), digital-geschlossen (SWIFT, GPS), hybrid (Cloud-Infrastruktur) und institutionell (Rechtssystem). Diese Heterogenität repräsentiert die Breite des Infrastrukturbegriffs und stärkt die Validierungskraft der Auswahl, weil ein Kriterium, das sich in derart unterschiedlichen Systemen wiederfindet, mit höherer Plausibilität als konstitutiv für Infrastruktur gelten kann.

Der analytische Ansatz wurde bewusst gewählt, weil es keinen etablierten Bewertungsrahmen für die Bewertung kryptographischer Infrastruktur gibt. Bestehende Bewertungsansätze aus der Telekommunikation oder der Energiewirtschaft sind auf institutionelle Infrastruktur zugeschnitten, die von zentralen Organisationen betrieben und in regulatorische Rahmenbedingungen eingebettet ist, sodass ihre Übertragung auf ein permissionless System ohne zentrale Betreiberorganisation nach Einschätzung der Arbeit kategoriale Fehlannahmen erzeugen kann. Die Arbeit entwickelt ihren Bewertungsrahmen deshalb eigenständig, und zwar analytisch-deduktiv. Sie zerlegt den Begriff der fundamentalen digitalen Infrastruktur, wie ihn der theoretische Rahmen des vorigen Abschnitts bestimmt, in die konstitutiven Eigenschaften, die ein System aufweisen muss, um dem Anspruch zu genügen. Sie operationalisiert jede dieser Eigenschaften als überprüfbares Kriterium mit eigener Definition, eigenen Indikatoren und eigenen Schwellenwerten.

Das Verfahren folgt der Conceptual Framework Analysis, die Yosef Jabareen beschrieben hat. Diese qualitative Methode zur Framework-Konstruktion führt in systematischen Phasen von der Identifikation der relevanten begrifflichen und theoretischen Quellen über die Extraktion der tragenden Konzepte bis zu ihrer Integration in ein kohärentes Instrument.²⁰ Der Prüfstein eines so konstruierten Bewertungsrahmens ist nicht seine Herkunft aus einer Fallmenge, sondern seine innere Kohärenz, die Vollständigkeit seiner Dimensionen und seine analytische Produktivität, also die Frage, ob er die Unterscheidungen trifft, auf die es bei der Bewertung ankommt. Jedes der zwölf Kriterien trägt sich über seine eigene begriffliche Herleitung, und keines beansprucht Geltung aus der Häufigkeit, mit der eine Eigenschaft in einer Stichprobe realer Systeme auftritt.

Weil ein analytisch hergeleiteter Bewertungsrahmen Gefahr läuft, an der Realität etablierter Infrastruktur vorbeizukonstruieren, validiert Kapitel 3 die zwölf Kriterien. Es prüft sie an sieben strukturell heterogenen Referenzinfrastrukturen und fragt, ob die deduktiv gewonnenen Anforderungen der Konfrontation mit Systemen standhalten, die sich historisch als fundamentale Infrastruktur etabliert haben. Diese Prüfung ist keine nachträgliche Illustration, sondern der empirische Härtetest des Bewertungsrahmens, dessen Ergebnisse in Kapitel 3 vollständig dokumentiert werden.

2.3 Der Bewertungsrahmen

Der Bewertungsrahmen ist das Instrument, mit dem die Forschungsfrage beantwortet wird.

2.3.1 Bewertungslogik

Drei Grundprinzipien bestimmen die Architektur des Bewertungsrahmens. Das erste Prinzip ist die konditionale Struktur der Bewertung. Die Forschungsfrage ist konditional formuliert: Sie fragt, ob die Architektur den Anspruch einlöst, den sie erhebt. Das Ergebnis ist ein Spektrum, das von „Geeignet” über „Geeignet mit Bedingungen” und „Geeignet unter erheblichen Bedingungen” bis zu „Bedingt geeignet” und „Nicht geeignet” reicht. Jede Kategorie ist definiert, und die Zuordnung zu einer Kategorie folgt aus expliziten Regeln, die im Bewertungsmechanismus (M3-Kaskade) festgelegt sind.

Das zweite Prinzip ist das in Abschnitt 2.1 eingeführte Meta-Muster, dass die Ausprägung zum Anspruch passen muss. Es bestätigt sich in der Validierung an den sieben Referenzinfrastrukturen in Kapitel 3. GPS bietet maximale Inklusivität, denn jeder Empfänger weltweit kann das Signal nutzen, aber keine Neutralität, denn das System steht unter unilateraler Kontrolle der US-Regierung, die das Signal selektiv abschalten oder drosseln kann. SWIFT bietet globale Koordination im Finanznachrichtenverkehr, aber keinen offenen Zugang und keine Zensurresistenz, denn Staaten können einzelne Teilnehmer vom System ausschließen. Beide Systeme sind fundamentale Infrastruktur, obwohl keines von ihnen alle denkbaren Infrastruktureigenschaften in maximaler Ausprägung erfüllt. Das Meta-Muster verhindert den Fehlschluss, dass Ethereum jedes Kriterium in maximaler Ausprägung erfüllen muss, um als Infrastruktur zu gelten. Zugleich verhindert es den umgekehrten Fehlschluss, dass jede beliebige Ausprägung akzeptabel ist: Die Ausprägung muss zum spezifischen Anspruch passen, und der Anspruch, den Ethereum erhebt, ist der einer neutralen, permissionless, zensurresistenten Infrastruktur.

Das dritte Prinzip ist eine bewusste Designentscheidung: Die Bewertung ist hierarchisch-regelbasiert, nicht additiv. Die Arbeit verwendet kein gewichtetes Scoring-Modell, bei dem jedes Kriterium einen Prozentwert erhält und die Gesamtbewertung aus der Summe der gewichteten Einzelwerte folgt. Stattdessen operiert eine regelbasierte Hierarchie, in der Kritische Bedingungen als Schwelle fungieren: Wenn eine Kritische Bedingung nicht auf dem erforderlichen Niveau erfüllt ist, begrenzt das die bestmögliche Gesamtbewertung, unabhängig davon, wie gut die übrigen Kriterien abschneiden. In einem additiven Modell könnte ein System, das bei der Neutralität, einer Kritischen Bedingung, auf der Stufe „Offen” steht, aber bei allen anderen elf Kriterien die Stufe „Erfüllt” erreicht, trotzdem ein gutes Gesamtergebnis erzielen. Das widerspricht der Infrastrukturlogik: Ein System, das nicht neutral zugänglich ist, kann den Anspruch einer fundamentalen Infrastruktur nicht einlösen, unabhängig von seiner Leistung in anderen Dimensionen. Die Hierarchie bildet diese Logik ab. Sie tauscht Akkumulationssensitivität, also die Fähigkeit, viele kleine Einschränkungen zu einem schlechteren Gesamtergebnis zu aggregieren, gegen Reproduzierbarkeit und Transparenz: Ein zweiter Forscher, der dasselbe Material bewertet, kommt zum selben Ergebnis, weil die Regeln explizit sind und keine impliziten Gewichtungsentscheidungen erfordern.

2.3.2 Die Drei-Ebenen-Logik

Jedes der zwölf Kriterien wird auf drei Ebenen geprüft. Die Protokollebene fragt, was die Architektur ermöglicht. Die operative Ebene fragt, was davon tatsächlich realisiert ist. Die Infrastrukturebene fragt, ob das Zusammenspiel aus architektonischer Möglichkeit und operativer Realität den Infrastrukturanspruch einlöst. Diese Drei-Ebenen-Logik ist das zentrale Analysewerkzeug der gesamten Arbeit. Sie verhindert, dass die Bewertung bei der Architektur stehen bleibt und die operative Realität ignoriert, was zu einer Überbewertung führen würde, weil jedes gut entworfene Protokoll auf der Architekturebene die richtigen Eigenschaften aufweist. Sie schließt umgekehrt aus, dass die operative Realität ohne Berücksichtigung des architektonischen Potenzials bewertet wird, was zu einer Unterbewertung führen würde, weil operative Defizite durch Protokolländerungen behebbar sein können. Die Infrastrukturebene synthetisiert beide Perspektiven und erzwingt die Frage, die für den Infrastrukturanspruch entscheidend ist: Reicht das, was architektonisch möglich und operativ realisiert ist, für den Anspruch aus?

Ein Beispiel macht die drei Ebenen greifbar. Zensurresistenz, eines der Kriterien der Kategorie Kritische Bedingungen, operiert auf allen drei Ebenen mit unterschiedlichen Befunden. Auf der Protokollebene ermöglicht Ethereums Architektur, dass jede valide Transaktion in einen Block aufgenommen werden kann: Das Protokoll selbst enthält keinen Mechanismus, der Transaktionen nach Inhalt oder Absender diskriminiert. Auf der operativen Ebene zeigt sich eine abweichende Realität: Der Großteil der Blöcke wird von wenigen Buildern produziert, die theoretisch Transaktionen ausschließen könnten, und ein beträchtlicher Anteil der Blöcke wird unter Berücksichtigung von OFAC-Sanktionslisten gebaut. Auf der Infrastrukturebene stellt sich die entscheidende Frage: Reicht die protokollseitige Möglichkeit der Inklusion aus, oder muss die operative Zensurresistenz gegeben sein, damit das System den Anspruch einer neutralen Infrastruktur einlöst? Die Antwort, die Kapitel 4 im Detail begründet, hängt davon ab, ob die operative Diskrepanz den Infrastrukturanspruch untergräbt oder ob Mitigationsmechanismen, etwa protokollseitige Inclusion Lists (FOCIL), die Lücke zwischen Protokolldesign und operativer Realität schließen können. Die abschließende Bewertung folgt dem Prinzip des schwächsten Glieds: Die Ebene mit dem niedrigsten Erfüllungsgrad bestimmt die Gesamtbewertung des Kriteriums.

2.3.3 Die drei Bausteine des Bewertungsrahmens

Der Bewertungsrahmen besteht aus drei ineinandergreifenden Bausteinen: der Implementierungsstatus-Taxonomie (M1), den Schwellenwerten für die zwölf Kriterien (M2) sowie der Kriterien-Hierarchie und dem Bewertungsmechanismus (M3-Kaskade).

Implementierungsstatus-Taxonomie (M1)

Die Taxonomie klassifiziert alle Ethereum-Features nach ihrer Umsetzungsreife in fünf Stufen. Features mit dem Status IMPL (implementiert) sind auf dem Mainnet aktiv und produktiv genutzt, seit mindestens drei Monaten stabil und ohne kritische Bugs. Features mit dem Status DEPL (in Deployment) sind in Client-Releases implementiert und auf Testnets aktiv, mit einem angekündigten Mainnet-Datum. Features mit dem Status PLAN (geplant) haben ein akzeptiertes EIP, befinden sich im Status Review oder Last Call, sind in der offiziellen Roadmap und haben einen geschätzten Zeithorizont von weniger als 24 Monaten. Features mit dem Status RES (Research) sind in Roadmap-Dokumenten erwähnt und Gegenstand aktiver Forschung, aber ohne finale Spezifikation. Features mit dem Status DEP (Deprioritized) sind explizit zurückgestellt oder verworfen.

Die Grenze zwischen DEPL und PLAN ist die zentrale epistemische Trennlinie der Arbeit. IMPL und DEPL werden als vorhanden oder gesichert behandelt, weil ihre Umsetzung operativ belegt oder unmittelbar bevorstehend ist. PLAN und RES werden als bedingt behandelt, mit expliziter Unsicherheitskennzeichnung, weil ihre Realisierung von zukünftigen Governance-Entscheidungen, technischer Machbarkeit und Community-Konsens abhängt. Alles unterhalb von DEPL ist Projektion, und die Taxonomie weist den Grad der Projektion aus. Fünf Stufen wurden gewählt, weil sie die relevanten epistemischen Abstufungen abbilden, ohne unnötige Granularität zu erzeugen: Drei Stufen (implementiert, geplant, nicht geplant) würden die Differenz zwischen einem Feature in Testnet-Deployment und einem Feature in früher Forschungsphase einebnen, die für die Belastbarkeit der Bewertung entscheidend ist. Die Taxonomie erzeugt ein Gewissheitsgefälle, das die gesamte Arbeit bestimmt und in der integrierten Belastbarkeitsbewertung in Abschnitt 6.1 nach dem Reifegrad der tragenden Features operationalisiert wird.

Schwellenwerte: Zwölf Kriterien in drei Kategorien (M2)

Die zwölf Kriterien gliedern sich in drei Kategorien, die in der Hierarchie des Bewertungsrahmens unterschiedliche Rollen spielen. Jedes Kriterium wird auf einer vierstufigen Skala bewertet. „Erfüllt” bedeutet, dass die Anforderung vollständig umgesetzt ist und keine strukturellen Einschränkungen bestehen. „Erfüllt mit Einschränkung” bedeutet, dass die Anforderung grundsätzlich erfüllt ist, mit identifizierten Einschränkungen, die den Anspruch nicht grundlegend untergraben. „Bedingt erfüllt” bedeutet, dass die Erfüllung von Bedingungen abhängt, die noch nicht gesichert sind, für die aber ein erkennbarer Pfad besteht. „Offen” bedeutet, dass die Anforderung nicht erfüllt ist und kein operativer Pfad zur Erfüllung existiert. Die Kriterienbewertung ergibt sich aus der argumentativen Synthese der Indikatoren entlang der Drei-Ebenen-Logik. Die Indikatoren liefern die Evidenzbasis, aber die Bewertung folgt keiner mechanischen Zählregel, weil die Indikatoren eines Kriteriums unterschiedliches Gewicht für den Infrastrukturanspruch haben. Eine Zählregel, die etwa drei von vier Indikatoren auf „Erfüllt” als hinreichend für ein „Erfüllt” des Gesamtkriteriums werten würde, behandelt alle Indikatoren als gleichwertig, was sachlich nicht haltbar ist. Die argumentative Synthese erzwingt stattdessen eine strukturierte Begründung, die in jeder Einzelbewertung transparent dokumentiert wird. Der Leser kann die Evidenz und die Schlussfolgerung unabhängig beurteilen. Verändert sich ein Indikator zwischen zwei Bewertungszeitpunkten nicht, bleibt seine Stufe erhalten. Ein unveränderter Indikator kann nicht unter seine im Ausgangszustand erreichte Stufe absteigen.

Die folgenden Absätze stellen die zwölf Kriterien in der Reihenfolge ihrer hierarchischen Funktion vor. Zuerst kommen die Kritischen Bedingungen, die das Fundament des Infrastrukturanspruchs bilden und deren Nicht-Erfüllung die bestmögliche Gesamtbewertung begrenzt. Dann folgen die Strukturellen Bedingungen, die die Tragfähigkeit des Systems bestimmen. Schließlich kommen die Qualitativen Kriterien, die den Grad der Eignung innerhalb der erreichten Kategorie differenzieren.

Sicherheits- und Vertrauenslast (I.2) operiert auf zwei Dimensionen. Die erste Dimension fragt, ob Angriffe auf Ethereum ökonomisch undurchführbar sind. Die ökonomische Sicherheit wird über die Kosten einer 34-Prozent-Attacke gemessen, für die die Schwelle bei über 30 Milliarden US-Dollar für die Stufe „Erfüllt” liegt, abgeleitet aus der CoinMetrics-Studie „Breaking BFT” von 2024. Die 34-Prozent-Schwelle ergibt sich direkt aus der Blocking Minority des Casper-FFG-Konsensalgorithmus: Ein Angreifer, der 34 Prozent des gestakten ETH kontrolliert, kann die Finalisierung blockieren. Die zweite Dimension fragt, wie viel Restvertrauen in Dritte der Nutzer aufbringen muss, um das System sicher zu nutzen. Diese Dimension ist komplementär zu Kriterium II.3 (Unabhängige Verifizierbarkeit): Während II.3 fragt, ob die Möglichkeit zur Verifikation existiert, fragt I.2, wie viel Restvertrauen trotz dieser Möglichkeit bleibt. Die Antworten können auseinanderfallen, weil ein System, das Verifikation ermöglicht, dennoch eine hohe Vertrauenslast erzeugen kann, wenn die Mehrheit der Nutzer über zentralisierte Intermediäre wie RPC-Anbieter auf das System zugreift.

Minimale tragfähige Garantien (I.4) fragt, ob Ethereum ein Mindestset an Garantien bietet, die auch unter Stress aufrechterhalten werden. Dazu zählen Finality, also die Irreversibilität finalisierter Transaktionen, Liveness, also die Fähigkeit, unter Stress weiter Blöcke zu produzieren, ein Degradation Mode für den Fall eines Validatoren-Ausfalls und Zensurresistenz unter Angriff, die über einen Querverweis zu Kriterium II.1 mitbewertet wird. Die Time-to-Finality-Schwelle von unter 15 Minuten für „Erfüllt” leitet sich direkt aus der Beacon-Chain-Spezifikation ab, die zwei Epochs mit je 32 Slots à 12 Sekunden, also rund 12,8 Minuten, für die Finalisierung vorsieht.

Neutralität und Zensurresistenz (II.1) ist das Kriterium mit dem größten Indikator-Set im Bewertungsrahmen. Sieben Indikatoren prüfen Neutralität auf zwei Ebenen: auf der Transaktionsebene, ob einzelne Transaktionen durch Builder, Relays oder Regulierung zensiert oder verzögert werden, und auf der Systemebene, ob ein Staat oder eine Akteursgruppe Ethereum als Ganzes instrumentalisieren kann. Die OFAC-Compliance-Rate der Blöcke, die Builder-Konzentration, die Existenz eines protokollseitigen Zensurresistenzmechanismus, die maximale Zensur-Verzögerung, die geopolitische Jurisdiktions-Diversität der Validatoren, der Marktanteil des größten Liquid-Staking-Providers und die kumulierte Konzentration der drei größten Staking-Anbieter, unabhängig davon, ob sie als Liquid-Staking-Protokoll oder als verwahrender Dienst auftreten, werden einzeln gemessen und in der Drei-Ebenen-Logik synthetisiert. Die 50-Prozent-Schwelle für OFAC-konforme Blöcke als Grenze zur Stufe „Erfüllt” geht auf die Watershed-Analyse von Uri Klarman zurück. Die 33-Prozent- und 66-Prozent-Schwellen für die Staking-Konzentration leiten sich aus der Blocking Minority und der Supermajority des Casper-FFG-Konsensalgorithmus ab.

Funktionale Unersetzbarkeit (I.1) zielt auf die Verankerungstiefe, gemessen an Netzwerkeffekten, Liquiditätskonzentration und Ökosystem-Bindung. Sie fragt ausdrücklich nicht nach Substituierbarkeit durch alternative Systeme, weil die Arbeit Ethereum isoliert gegen seinen eigenen Anspruch prüft, nicht gegen Konkurrenten. Drei Indikatoren prüfen sie: die Dominanz im DeFi Total Value Locked über alle Layer-1-Systeme, den Anteil an der globalen Stablecoin-Emission und die Größe des Entwickler-Ökosystems gemessen an öffentlicher Repository-Aktivität. Die Schwellen sind so gesetzt, dass eine Dominanz von über 50 Prozent die Stufe „Erfüllt” erreicht und ein Absinken unter 30 Prozent die Stufe „Offen” auslöst. Der dritte Indikator, das Entwickler-Ökosystem, ist transparent-normativ fundiert, weil die Datenquelle, der Electric Capital Developer Report, öffentliche Repository-Aktivität als Proxy für Entwickler-Netzwerkeffekte misst, eine Off-Chain-Metrik mit höherer Messunschärfe als die on-chain verifizierbaren TVL- und Stablecoin-Daten.

Koordinationsfunktion (I.3) fragt, ob Ethereum eine Koordinationsleistung bereitstellt, die ohne das System nicht oder nur mit signifikant höherem Aufwand erbracht werden könnte. Der Kriterienname und das übergreifende Muster aus der Infrastruktur-Kontextualisierung orientieren sich an der Funktion realer Infrastrukturen: Stromnetze koordinieren Angebot und Nachfrage, SWIFT koordiniert Finanznachrichten zwischen Banken, das Internet koordiniert Paketrouting zwischen Netzwerken. Drei Indikatoren operationalisieren diese Frage. Der erste ist der Koordinations-Scope, der die Breite der Koordinationsleistung misst, von reiner Settlement-Funktion bis zu Settlement, Execution, Verification und Data Availability. Der zweite ist die Layer-2-Settlement-Abhängigkeit, die misst, wie viele Layer-2-Systeme Ethereum als Koordinationspunkt nutzen. Der dritte ist die Cross-Layer-2-Composability, die die Kohärenz der Koordination erfasst, weil Ethereums stärkste Koordinationseigenschaft, die atomare Composability innerhalb einer Transaktion, auf Layer-2-Ebene verloren geht und damit die Koordinationsleistung fragmentiert.

Langfristige Stabilität (III.1) fragt, ob Ethereum über Dekaden hinweg operieren kann, ohne dass inhärente Designentscheidungen das System destabilisieren. Dieses Kriterium hat innerhalb der Strukturellen Bedingungen eine Sonderstellung als kritischste Langfrist-Bedingung, weil ohne Lösung für State Growth und Client Diversity die langfristige Tragfähigkeit nicht gewährleistet ist. Die fünf Indikatoren messen die Client-Diversität der Execution-Schicht, die Client-Diversität der Consensus-Schicht, die Existenz einer State-Growth-Mitigation-Lösung, die Stabilität der letzten fünf Protokoll-Upgrades und die Konzentration der zehn größten Validatoren. Die Grenze zur Stufe „Erfüllt” bildet die 33-Prozent-Schwelle der Blocking Minority aus Casper FFG.

Die Qualitativen Kriterien differenzieren den Grad der Eignung innerhalb der erreichten Kategorie. Sie entscheiden über das Wie, nicht über das Ob.

Offene Generativität (II.2) fragt, ob jeder permissionless auf Ethereum bauen und innovieren kann, ob also neue Anwendungen, Protokolle und Geschäftsmodelle ohne Gatekeeper auf dem System aufbauen können. Die drei Indikatoren messen Permissionless Deployment (kann jeder ohne Genehmigung bereitstellen?), atomare Composability (können Smart Contracts innerhalb einer Transaktion miteinander interagieren?) und Open-Source-Tooling (sind die wichtigsten Entwicklungswerkzeuge quelloffen?). Die Schwelle zwischen „Erfüllt” und „Erfüllt mit Einschränkung” liegt bei dokumentierten Gas-Limitationen und Cross-Layer-2-Einschränkungen, die die Composability fragmentieren.

Unabhängige Verifizierbarkeit (II.3) fragt, ob die Korrektheit von Smart Contracts und Protokollzustand ohne Vertrauen in Dritte überprüft werden kann. Dieses Kriterium bildet die Angebotsseite zur Vertrauenslast (I.2), deren Komplementarität dort erläutert wurde. Die Indikatoren messen die Verfügbarkeit formaler Verifikationstools, die Existenz einer formalen EVM-Spezifikation und die Verbreitung von Sicherheitsaudits als Standard vor der Veröffentlichung von DeFi-Protokollen.

Niedrigschwellige Inklusivität (II.4) fragt, ob die Teilnahme an Ethereum als Nutzer, Entwickler, Validator oder Verifizierer ohne prohibitive Barrieren möglich ist. Mit fünf Indikatoren führt dieses Kriterium neben der Langfristigen Stabilität (III.1) das zweitgrößte Indikator-Set im Bewertungsrahmen, weil Inklusivität an der Schnittstelle mehrerer Barrierentypen operiert: die Hardwareanforderungen für den Betrieb eines Full Node, die Hardwareanforderungen für den Betrieb eines Validators, der Staking-Zugang unterhalb der 32-ETH-Schwelle, die Layer-2-Transaktionskosten im Vergleich zu traditionellen Transaktionskosten und die Nutzbarkeit ohne kryptographisches Vorwissen. Der letzte Indikator ist an den Implementierungsstatus von Account Abstraction (EIP-7702) gebunden und misst die Komplexitätsbarriere: Kann ein Nutzer, der Online-Banking und App-Stores bedienen kann, aber noch nie mit Kryptowährungen interagiert hat, Ethereum nutzen? Die Fundierung dieses Indikators ist transparent-normativ, was bedeutet, dass der Leser seine Aussagekraft anders gewichten darf.

Adaptive Governance (III.2) fragt, ob Ethereum sich an veränderte Anforderungen anpassen kann, ohne dass der Anpassungsprozess selbst das System destabilisiert. Die drei Indikatoren messen die Funktionalität des EIP-Prozesses als dokumentierten Governance-Mechanismus, die Hotfix-Fähigkeit bei kritischen Bugs innerhalb von 48 bis 72 Stunden und die Fähigkeit, kontroverse Entscheidungen ohne Chain-Split zu lösen, was seit dem DAO-Fork von 2016 empirisch belegt ist.

Souveräne Portabilität (III.3) fragt, ob Ethereum frei von proprietären Abhängigkeiten ist, die einen Vendor-Lock-in erzeugen könnten. Die Indikatoren prüfen, ob die vollständige Blockchain-Historie exportiert werden kann, ob das System vollständig Open Source mit mehreren unabhängigen Clients ist und ob Assets ohne Vertrauen in einzelne Bridges zwischen den Schichten bewegt werden können. Die Schwelle zwischen „Erfüllt” und „Erfüllt mit Einschränkung” liegt bei praktischen Hürden des Datenexports und bei Trust-Annahmen im Bridge-Design.

Hardware-Agnostik (III.4) fragt, ob Ethereum auf heterogener Hardware betrieben werden kann, ohne dass spezifische Hardware-Anforderungen die Teilnahme einschränken. Die drei Indikatoren messen Cloud-Unabhängigkeit (kein einzelner Provider über 50 Prozent), geographische Verteilung (Nodes über mindestens zehn Länder mit jeweils über einem Prozent) und Architektur-Support (alle großen Clients auf x86 und ARM). Dieses Kriterium nimmt unter den zwölf eine Sonderstellung ein. Keines der sieben Referenzsysteme weist das spezifische Risiko einer Cloud-Konzentration in der Form auf, wie es bei Ethereum existiert: Das Stromnetz und das Straßennetz sind physisch verteilt. Das Internet ist architektonisch dezentral. SWIFT und GPS operieren auf proprietärer Infrastruktur. Ethereum hingegen läuft auf Consumer-Hardware und Cloud-Servern, und eine Konzentration der Node-Infrastruktur auf wenige Cloud-Provider erzeugt eine physische Abhängigkeit, die die Dezentralisierung auf der logischen Schicht unterläuft. Das Kriterium ist anspruchsspezifisch motiviert: Es existiert, weil der Gegenstand es erfordert, und es ist funktional eine Voraussetzung für mehrere andere Kriterien, weil Client-Diversity (III.1) Hardware-Unabhängigkeit voraussetzt und Validator-Betrieb auf Consumer-Hardware möglich bleiben muss, um die Inklusivität (II.4) und die Jurisdiktions-Diversität (II.1) zu sichern. Die Arbeit markiert dieses Kriterium transparent als Sonderfall, dessen Berechtigung sich aus architektonischen Anforderungen des Gegenstands ergibt, die in keiner der sieben Referenzinfrastrukturen ein Analogon haben.

Kriterien-Hierarchie und Bewertungsmechanismus (M3-Kaskade)

Die M3-Kaskade überführt die zwölf Einzelbewertungen in ein Gesamturteil. Die zwölf Kriterien sind in drei hierarchische Stufen gegliedert, die die Bewertungslogik bestimmen. Auf der ersten Stufe stehen die drei Kritischen Bedingungen (I.2, I.4, II.1), die das Fundament des Infrastrukturanspruchs bilden. Auf der zweiten Stufe stehen die drei Strukturellen Bedingungen (I.1, I.3, III.1), die die Tragfähigkeit des Systems bestimmen. Auf der dritten Stufe stehen die sechs Qualitativen Kriterien (II.2, II.3, II.4, III.2, III.3, III.4), die den Grad der Eignung differenzieren.

Die Kaskade prüft in einer expliziten Reihenfolge von fünf Schritten. Im ersten Schritt wird geprüft, ob mindestens eine Kritische Bedingung auf der Stufe „Offen” steht. Wenn ja, ist das Gesamturteil auf „Bedingt geeignet” gedeckelt, unabhängig von allen anderen Bewertungen. Im zweiten Schritt wird geprüft, ob mindestens eine Kritische Bedingung auf „Bedingt erfüllt” steht. Wenn ja, ist das Gesamturteil auf „Geeignet unter erheblichen Bedingungen” begrenzt. Im dritten Schritt werden die Strukturellen Bedingungen nach der Zahl ihrer schwachen Ausprägungen geprüft. Als schwach gilt jede Bedingung auf „Erfüllt mit Einschränkung”, „Bedingt erfüllt” oder „Offen”. Steht keine der drei Strukturellen schwach, ist die oberste Kategorie erreichbar, sofern auch die Kritischen mindestens auf „Erfüllt” stehen. Steht genau eine schwach, ist das Urteil auf höchstens „Geeignet mit Bedingungen” begrenzt. Stehen zwei oder mehr schwach, ist es auf höchstens „Geeignet unter erheblichen Bedingungen” begrenzt. Die Deckelungsprüfungen der ersten drei Schritte gehen den Positivdefinitionen der Kategorien vor: Greift eine Deckelung, bestimmt sie die höchstmögliche Kategorie, und die Positivdefinition ordnet das Urteil innerhalb dieser Obergrenze zu. Im vierten Schritt bestimmen die Qualitativen Kriterien den Grad innerhalb der erreichten Eignungskategorie, nach einer Grad-Skala von Gut (alle sechs qualitativen Kriterien mindestens auf „Erfüllt mit Einschränkung”) über Befriedigend (vier oder fünf) und Ausreichend (zwei oder drei) bis Mangelhaft (weniger als zwei). Im fünften Schritt wird das Gesamturteil formuliert. Identifizierte Spannungen zwischen Kriterien gehen in die Kaskade ein, indem zu jeder Spannung der Mitigationspfad mit seinem Implementierungsstatus nach der M1-Taxonomie erfasst wird und der so bestimmte Erfüllungsgrad des betroffenen Kriteriums in den zuständigen Schritt einfließt.

Die Kaskadenregel im zweiten Schritt wurde während der Anwendung des Bewertungsrahmens ergänzt. In der ursprünglichen Fassung sah die Kaskade nur zwei Zustände für kritische Bedingungen vor: „Offen” als Deckelungsschwelle und alle Stufen darüber als passierbar. Die Anwendung des Bewertungsrahmens auf den IST-Zustand identifizierte eine Situation, die die binäre Unterscheidung nicht abbildete. Eine Kritische Bedingung auf „Bedingt erfüllt” ist qualitativ ein anderer Zustand als eine auf „Erfüllt mit Einschränkung”, weil die Kerneigenschaft des Infrastrukturanspruchs noch nicht auf dem erforderlichen Niveau protokollseitig gesichert ist. Die Hierarchie definiert Kritische Bedingungen als Fundament des Infrastrukturanspruchs. Ein Fundament auf „Bedingt erfüllt” bedeutet, dass der Pfad zur Erfüllung erkennbar, aber nicht gesichert ist, während ein Fundament auf „Erfüllt mit Einschränkung” bedeutet, dass die Eigenschaft grundsätzlich gegeben ist, mit dokumentierten Einschränkungen. Die Kaskade muss diesen Unterschied abbilden, und die Ergänzung tut dies durch eine eigenständige Urteilskategorie. Die Ergänzung ist generisch formuliert: Sie gilt für jede Anwendung des Bewertungsrahmens, in der eine Kritische Bedingung auf „Bedingt erfüllt” steht, unabhängig davon, welches Kriterium betroffen ist und welches System bewertet wird.

Die Kaskade erzeugt fünf mögliche Urteilskategorien, deren Definitionen klären, was eine Kategorie bedeutet und was sie ausschließt. Der Grad wird für jede erreichte Kategorie durch die Qualitativen Kriterien bestimmt. Er differenziert die Eignung innerhalb der erreichten Kategorie, ohne die Kategorie selbst zu verschieben. „Geeignet” bedeutet, dass alle Kritischen und Strukturellen Bedingungen auf mindestens „Erfüllt” stehen. Es bedeutet ausdrücklich nicht operative Einsatzreife, globale Skalierung oder Vollständigkeit, weil diese Faktoren Markt- und Übernahmedynamiken beschreiben, keine Infrastruktur-Eigenschaften. „Geeignet mit Bedingungen” bedeutet, dass mindestens eine Kritische Bedingung oder genau eine Strukturelle Bedingung eine Einschränkung aufweist, solange keine Deckelungsregel einer höheren Stufe greift. Die Einschränkung qualifiziert den Anspruch, ohne ihn fundamental zu untergraben. „Geeignet unter erheblichen Bedingungen” bedeutet, dass mindestens eine Kritische Bedingung auf „Bedingt erfüllt” steht: Die Kerneigenschaft des Infrastrukturanspruchs ist noch nicht auf dem erforderlichen Niveau gesichert, und die Eignung ist an benannte, überprüfbare Bedingungen geknüpft. „Bedingt geeignet” bedeutet, dass mindestens eine Kritische Bedingung auf „Offen” steht und eine fundamentale Anforderung verfehlt wird, für die jedoch ein erkennbarer Pfad zur Erfüllung besteht. „Nicht geeignet” bedeutet, dass fundamentale Anforderungen ohne erkennbaren Pfad zur Erfüllung verfehlt werden.

2.3.4 Scope und Grenzen

Der Bewertungsrahmen operiert innerhalb expliziter Grenzen, die seine Aussagekraft definieren und seine Anwendbarkeit abgrenzen.

Die erste Grenze ist die Oracle-Grenze. Der Bewertungsrahmen bewertet den on-chain Zustand vollständig, also alle Eigenschaften, die protokollintern messbar sind. Was außerhalb des Protokolls liegt, kann der Bewertungsrahmen konzeptionell nicht bewerten. Die Qualität der Daten, die ins System gelangen, ist ein zentrales Beispiel: Ein Smart Contract kann die Logik einer Versicherungsauszahlung korrekt ausführen, aber wenn der Dateninput, der das auslösende Ereignis meldet, manipuliert ist, nützt die korrekte Ausführung nichts. Die regulatorische Umgebung, in der Ethereum operiert, und die gesellschaftliche Akzeptanz, die über die tatsächliche Nutzung als Infrastruktur entscheidet, sind weitere Variablen, die nicht protokollintern messbar sind und damit außerhalb des Bewertungsbereichs liegen. Die Oracle-Grenze ist eine Beschränkung zugunsten methodischer Sauberkeit: Der Bewertungsrahmen bewertet, was er bewerten kann, und dokumentiert, was er nicht bewerten kann.

Die zweite Grenze ist die Applikationsschicht-Trennlinie. Anwendungen, die auf Ethereum aufbauen, werden nur behandelt, soweit sie die Infrastruktur selbst beeinflussen. Die Trennlinie folgt einer Frage: Beeinflusst die Anwendung die Infrastruktureignung? Ein Liquid-Staking-Anbieter, dessen Marktanteil die Konsensschwellen des Protokolls berührt, ist relevant, weil seine Konzentration die Neutralität der Infrastruktur beeinflusst. Ein NFT-Marktplatz ist es nicht. Die Trennlinie wird dort angewandt, wo ein Befund über ihre Lage entscheidet, etwa an der Oracle-Grenze in Kapitel 4.

Die dritte Grenze ist die IST/SOLL-Zweiteilung. Die Arbeit bewertet zwei Zeitebenen mit demselben Bewertungsrahmen. Der IST-Zustand beschreibt, was Ethereum im ersten Quartal 2026 ist, und steht auf operativer Evidenz, also Features mit dem Taxonomie-Status IMPL. Features mit dem Status DEPL gehen ein, soweit sie das laufende System bereits prägen, tragen aber keine Bewertung allein. Der SOLL-Zustand beschreibt, was Ethereum unter Annahme vollständiger Roadmap-Umsetzung werden kann, und steht auf architektonischer Kohärenz mit abgestufter Implementierungsreife, also Features mit dem Status PLAN oder RES. Die Zweiteilung ist eine methodische Entscheidung: Ethereum ist ein evolvierendes System, dessen heutige Eigenschaften von den Eigenschaften abweichen, die die Roadmap in Aussicht stellt. Ohne die Zweiteilung müsste die Arbeit entweder den IST-Zustand bewerten und die Roadmap ignorieren, was die Dynamik des Systems ausblenden würde, oder den SOLL-Zustand als gegeben annehmen, was die epistemische Unsicherheit verbergen würde. Die Zweiteilung erlaubt dem Leser, zu unterscheiden, was heute operativ belegt ist und was die Roadmap in Aussicht stellt, und die Belastbarkeit dieses Vorhabens anhand der Taxonomie-Stufen einzuschätzen. Sie zeigt, dass der Sprung zwischen dem IST- und dem SOLL-Zustand an konkrete Implementierungen gebunden ist, deren Belastbarkeit Kapitel 6 eigens analysiert.

Infrastruktureignung ist eine multidimensionale Eigenschaft, die sich einer Reduktion auf eine einzelne Kennzahl entzieht. Die Arbeit hat deshalb einen qualitativen Ansatz gewählt. Eine quantitative Bewertung würde Gewichtungen zwischen den Kriterien erfordern, die entweder willkürlich gesetzt oder aus einer größeren Stichprobe statistisch abgeleitet werden müssten. Beides ist für den Gegenstand nicht möglich: Willkürliche Gewichtungen würden eine Scheinpräzision erzeugen, die die tatsächliche Unsicherheit verbirgt, und eine statistische Ableitung scheitert daran, dass die Grundgesamtheit kryptographischer Infrastruktursysteme zu klein für statistische Verfahren ist. Die Vollständigkeit der zwölf Kriterien wird in Abschnitt 6.3 reflektiert, wo vier Eigenschaften identifiziert werden, die der Bewertungsrahmen nicht messen kann: Permissionless Composability, kryptographische Systemzustandsverifikation, dezentrale Selbstentwicklungsfähigkeit und Privacy als architektonische Infrastruktureigenschaft. Diese vier dokumentierten Grenzen des Bewertungsrahmens markieren die Stelle, an der die Validierung am Referenzmaterial an ihre Grenze stößt und der Gegenstand Eigenschaften aufweist, die keine der sieben Infrastrukturen in vergleichbarer Form zeigt.

Dass die Kriterienbewertung auf argumentativer Synthese beruht und keiner Zählregel folgt, wurde im Abschnitt zur Bewertungslogik begründet. Die methodische Begründung für dieses Vorgehen liegt in der Natur qualitativer Anwendung des Bewertungsrahmens: Die Stärke einer regelbasierten, aber interpretativen Bewertung liegt in der theoriegeleiteten Abwägung der Indikatoren, nicht in ihrer mechanischen Aggregation zu einem Punktwert. Die Transparenz des Verfahrens ermöglicht dem Leser, jede Einzelbewertung anhand der dokumentierten Evidenz und der begründeten Schlussfolgerung unabhängig nachzuvollziehen und, falls gewünscht, zu einem abweichenden Urteil zu gelangen. Dieses doppelte Ziel, das in der Kapiteleinleitung eingeführt wurde, ist eine methodische Stärke, die einen häufigen Kritikpunkt an qualitativer Forschung entschärft: Die Arbeit ist auch dann nützlich, wenn der Leser dem Urteil nicht zustimmt, weil sie die Grundlage für ein eigenständiges Urteil liefert.

Eine letzte methodische Grenze ist der Survivorship Bias in der Validierungsbasis: Die sieben Referenzinfrastrukturen sind anerkannte Systeme, gescheiterte sind nicht enthalten, und die Validierung stützt deshalb nur die Lesart der zwölf Kriterien als notwendige Bedingungen. Abschnitt 3.3 führt diese Grenze aus. Kapitel 3 dokumentiert die Validierung der zwölf Kriterien und die methodischen Grenzen dieses Vorgehens. Die vollständigen Einzelanalysen der sieben Infrastrukturen stehen in Abschnitt 3.1, die Konsolidierung und die Validierungsergebnisse in Abschnitt 3.2.