• Vitalik Buterin sagt, ein eigener Ethereum-Node müsse sich weniger wie „Rocket Science“ anfühlen und kritisiert die heutige Zwei-Daemon-Architektur.
  • Er reagierte auf einen Nimbus-„Unified Node“-Pull-Request, der zwei Softwarekomponenten in einem leichter zu betreibenden Programm zusammenführen soll.

Vitalik Buterin will, dass Ethereum wieder einfacher wird, zumindest für die Leute, die es selbst betreiben. Der Mitgründer kommentierte jüngst einen „Unified Node“-Pull-Request rund um Nimbus aus dem Status-im-Umfeld, der zwei getrennte Softwarekomponenten zu einem einzigen, leichter laufenden Programm bündeln soll.

Ein Prozess statt zwei, weniger Koordination im Alltag

Buterins Argument ist erstaunlich bodenständig. „Running two daemons and getting them to talk to each other is far more difficult than running one daemon“, schrieb er. Heute müssen Node-Runner üblicherweise zwei getrennte Programme starten, konfigurieren und synchron halten.

Eines spricht mit der Konsensschicht, das andere mit der Ausführungsschicht. Dann müssen beide noch zuverlässig miteinander kommunizieren. Wer das einmal eingerichtet hat, weiß, wie schnell es an Kleinigkeiten hängt.

Der Nimbus-Ansatz würde diese Koordinationsarbeit in ein einheitliches Setup packen. Das heißt nicht automatisch, dass Ethereum „nur noch einen Client“ hat. Es geht eher um Packaging und UX, also um die Frage, wie viel DevOps ein normaler Nutzer mitbringen muss, bevor überhaupt ein Node läuft.

Selbstverwahrung braucht gute UX, sagt Buterin

Buterin knüpft das Thema an ein größeres Ziel. Ethereum soll für selbstsouveräne Nutzung eine gute Benutzererfahrung bieten. In vielen Fällen heißt das eben: eigener Node, damit man nicht bei jeder Abfrage auf Dritte angewiesen ist. Die aktuelle Herangehensweise füge „needless complexity“ hinzu, so Buterin.

Das ist eine ziemlich direkte Kritik am Status quo, aber nicht an der Architektur als solcher. Ethereum hat gute Gründe, Konsens und Ausführung getrennt zu halten. Die Frage ist nur, ob diese Trennung beim Endnutzer als zwei separate Daemons sichtbar bleiben muss. Genau dort setzt die Unified-Node-Idee an.

Wenn die Community hier wirklich liefert, wäre das für Dezentralisierung praktisch relevant. Je niedriger die Hürde, desto mehr Leute betreiben selbst. Und desto weniger hängt das Netzwerk im Alltag an professionellen Infrastrukturanbietern.