Vitalik Vorschlag: Jede Familie soll ihren eigenen Ethereum-Knoten betreiben können

Ethereum-Mitbegründer Vitalik Buterin hat am Samstag einen Pull-Request an die Ethereum-Entwicklergemeinschaft eingereicht, in dem vorgeschlagen wird, die Backend-Programme der Ethereum-Beacon-Chain (zuständig für Konsens und Staking) mit der Ausführungsschicht des Protokolls zu einer einheitlichen Code-Struktur zusammenzuführen. Dieser Vorschlag zielt darauf ab, die technische Komplexität beim Betrieb eines Ethereum-Knotens grundlegend zu reduzieren, sodass normale Nutzer und Haushalte eigenständig ihre eigene Ethereum-Infrastruktur betreiben können, ohne auf Drittanbieter angewiesen zu sein.

Technischer Kern des Layer-2-Vorschlags: Warum „zwei Programme zu einem“ so wichtig ist

(Quelle: Ethereum Research)

Derzeit müssen Ethereum-Knotenbetreiber (Validatoren) zwei voneinander unabhängige Programme gleichzeitig verwalten: eines für die Konsensschicht (PoS-Validierungslogik der Beacon-Chain) und eines für die Ausführungsschicht (Smart Contracts und Transaktionen in der EVM-Umgebung). Diese beiden Programme erfordern jeweils eigene Einstellungen, Synchronisationen und kontinuierliche Kommunikationskoordination, um den Knoten stabil laufen zu lassen.

Technisch führt diese Doppel-Programm-Architektur direkt zu zwei Problemen: Erstens, die Konfiguration wird doppelt so komplex – Nutzer müssen zwei Systeme herunterladen, konfigurieren, aktualisieren und überwachen; zweitens, die Fehler- und Synchronisationsanfälligkeit steigt erheblich, jede Störung an einer Seite kann den gesamten Knoten zum Versagen bringen.

In einem Beitrag nach Einreichung des Vorschlags gab Buterin offen zu, dass die Ethereum-Community unbewusst eine implizite Entscheidung getroffen hat: „Das Betreiben eines Knotens ist eine äußerst anspruchsvolle DevOps-Aufgabe, die am besten Profis überlassen wird.“ Er äußerte klar seine Ablehnung dieser Situation: „Nicht so. Wir müssen das ändern. Auch bei hohen Hardware-Anforderungen darf das kein Grund sein, hohe DevOps-Kompetenz und Zeit zu verlangen – Knoten sollten sehr einfach einzurichten sein.“

Gefahr der Zentralisierung: RPC-Monopol und Zensurrisiken

Hinter diesem technischen Fortschritt steht ein tieferes Bewusstsein für die Gefahr der Dezentralisierung. Da die Hürde, einen eigenen Knoten zu betreiben, zu hoch ist, sind die meisten Ethereum-Nutzer (einschließlich DApp-Entwickler und normale Nutzer) auf wenige RPC-Dienste (Remote Procedure Call) wie Infura, Alchemy angewiesen, um mit dem Netzwerk zu interagieren.

Buterin weist in seinem Beitrag explizit auf die potenziellen Gefahren dieser Marktstruktur hin: „Ein Markt, der von wenigen RPC-Anbietern dominiert wird, steht unter großem Druck, Nutzer zu zensieren oder zu blockieren. Viele RPC-Anbieter haben bereits ganze Länder ausgeschlossen.“

Wenn RPC-Anbieter entscheiden, den Zugang für bestimmte Regionen oder Nutzer zu beschränken, verlieren diese vollständig die Möglichkeit, mit Ethereum zu interagieren. Das widerspricht dem Kernversprechen der Blockchain-Technologie: „ohne Erlaubnis, zensurresistent.“

Teilweise zustandslose Knoten: Ein weiterer technischer Weg zur Reduzierung der Einstiegshürde

Der Layer-2-Vorschlag ist nicht die erste Initiative von Buterin, um die Betriebshürden für Knoten zu senken. Im Mai 2025 stellte er das Konzept der „teilweise zustandslosen Knoten“ vor – Knoten, die keinen vollständigen Blockhistorie mehr vorhalten, sondern nur die Daten, die für den Betrieb notwendig sind.

Dieses Design ist speziell für „persönliche Knoten“ gedacht: Wenn Nutzer nur Transaktionen senden und die Blockchain verifizieren wollen, ohne vollständige historische Daten bereitzustellen, kann die benötigte Datenmenge erheblich reduziert werden. Laut Beschreibung von Go-Ethereum (GETH) ist der Festplattenspeicher die größte Engstelle für Knotenbetreiber – Blockchains wie Ethereum produzieren ständig große Datenmengen, die immer mehr Speicherplatz erfordern. Teilweise zustandslose Knoten brechen dieses „Daten-auf-unbestimmte-Zeit-Ansammeln“ direkt auf.

Gemeinsam wirken zwei Ansätze: Das Layer-Design reduziert die DevOps-Komplexität, die teilweise zustandslosen Knoten senken die Hardwarekosten – beides bildet die technische Grundlage für Buterins Vision, „dass jede Familie eigenständig einen Knoten betreiben kann.“

Häufig gestellte Fragen

Wie lange wird es dauern, bis Vitaliks Layer-2-Vorschlag umgesetzt wird?

Derzeit befindet sich der Vorschlag noch im Pull-Request-Status und muss die technische Prüfung sowie eine breite Diskussion in der Ethereum-Community durchlaufen. Ethereum-Protocol-Updates benötigen in der Regel mehrere Monate bis über ein Jahr für Entwicklung, Tests und Community-Consensus. Der genaue Zeitplan hängt von der Komplexität der Umsetzung, dem Feedback der technischen Prüfung und davon ab, ob es in die nächste Ethereum-Upgrade-Phase (wie nach Fusaka) integriert werden kann.

Welche Möglichkeiten haben normale Nutzer, vor der Umsetzung des Vorschlags leichter Ethereum-Knoten zu betreiben?

Derzeit gibt es Tools wie DAppNode, Stereum, die das Knoten-Deployment stark vereinfachen. Hardwareseitig können Low-Power-Geräte wie Raspberry Pi mit externen SSDs Ethereum-Knoten betreiben. Leichtgewichtige Clients (z.B. Helios) erlauben die Datenverifikation ohne vollständige Synchronisation. Zudem wird die Vielfalt der Ethereum-Clients kontinuierlich vorangetrieben, um die Deployment-Prozesse zu standardisieren und zu automatisieren.

Was bedeutet es für Nutzer, wenn RPC-Dienste bereits Länderblockaden umgesetzt haben?

Einige RPC-Anbieter (z.B. Infura) haben in bestimmten Fällen regionale Zugriffsblockaden implementiert, meist aus regulatorischen Gründen. Das bedeutet, dass Nutzer in eingeschränkten Regionen, die keinen Zugang zu alternativen RPC-Anbietern oder eigenen Knoten haben, keinen Zugriff auf Ethereum-Anwendungen mehr haben. Das ist genau der Grund, warum Buterin die Eigenständigkeit der Knoten betont: Nur wenn genügend Nutzer eigene Knoten betreiben, kann Ethereum sein Versprechen der „Zensurresistenz“ wirklich erfüllen.