Blockchain-Node-Infrastruktur

Ein Full Node hält den aktuellen Zustand der Kette und genug jüngere Historie zur Prüfung, validiert jeden eingehenden Block und jede Transaktion gegen die Konsensregeln und verwirft, was nicht passt, die Eigenschaft, die einen Full Node von einem Client mit fremder Kopie trennt. Bei Ethereum sind das rund 500 Gigabyte Speicher mit steigender Tendenz, denn der Node schneidet älteren Zustand weg, den er zur Prüfung nicht mehr braucht.

Ein Archive Node tut alles, was ein Full Node tut, und hält zusätzlich den vollen historischen Zustand ab dem Genesis-Block, jeder Saldo und jeder Vertragszustand zu jedem früheren Block ist also abfragbar. Das ist der teure: Ein Ethereum-Archive-Node läuft ab etwa zwei Terabyte mit einem speichersparenden Client wie Erigon und bis zu zwölf Terabyte und mehr mit Geth. Ein Light Client lädt nur Blockköpfe und fragt alles Weitere bei volleren Nodes nach; das betreibt eine Mobil-Wallet, und sie vertraut dem gefragten Node. Ein RPC-Node ist ein Full oder Archive Node mit JSON-RPC-Schnittstelle für Anwendungen; in dieser Form konsumieren die meisten Häuser, dazu die Seite RPC-Anbieter.

Seit dem Merge ist ein Ethereum-Node zwei Programme, die miteinander reden. Der Execution Client hält den Zustand, führt Transaktionen aus und liefert die JSON-RPC-Schnittstelle, mit Geth, Nethermind, Besu und Erigon als eingesetzten Umsetzungen. Der Consensus Client folgt der Proof-of-Stake-Kette und bearbeitet Attestierungen und Blockvorschläge, mit Prysm, Lighthouse, Teku, Nimbus und Lodestar auf dieser Seite.

Einen Node betreiben heißt also, zwei Programme mit getrennten Releasezyklen zu betreiben, zu aktualisieren und zu überwachen, und ein Missverhältnis zwischen ihnen nimmt den Node vom Netz. Diese Teilung ist der häufigste Grund, dass ein selbst betriebener Node hinter die Kette fällt, und Zurückfallen ist schlimmer als Ausfall: Ein Node, der veraltete Daten liefert, ohne es zu sagen, gibt einer Anwendung eine Antwort, die gültig aussieht und es nicht ist.

Die zwei Wörter werden vertauscht gebraucht und bezeichnen nicht dasselbe. Ein Node-Betreiber betreibt Node-Infrastruktur: die Maschinen, die Clients, die Überwachung, die Updates. Ein Validator nimmt am Konsens teil, setzt in einem Proof-of-Stake-Netz also den Token des Netzes als Sicherheit ein, schlägt Blöcke vor, attestiert die Blöcke anderer und wird bestraft, wenn er es nicht tut.

Einen Ethereum-Node zu betreiben macht den Betreiber nicht zum Validator. Dazu braucht es Validator-Software, einen Einsatz und einen Schlüsselsatz, und es bringt eine wirtschaftliche Aussetzung, die der reine Node-Betreiber nicht hat. Oft macht ein Haus beides, daher die Verwechslung, und die Unterscheidung zählt, weil die Risiken nicht zusammenhängen: Das Risiko eines Betreibers ist Verfügbarkeit, das eines Validators schließt Kapitalverlust ein. Die Seite Validator-Ökonomie behandelt Erträge und Strafen, Krypto-Staking die Funktionsweise von Proof of Stake.

Weil ein öffentlicher Endpunkt fremde Infrastruktur ist, die eine Frage beantwortet, für die das Haus einsteht. Die Gründe teilen sich in vier, und jeder trägt allein. Richtigkeit: Wer Blöcke selbst prüft, muss der Antwort eines Dritten über einen gemeldeten Bestand nicht glauben. Vertraulichkeit: Jede Abfrage an einen gehosteten Endpunkt sagt dem Betreiber, welche Adressen das Haus interessieren, für einen Vermögensverwalter also Positionsdaten. Verfügbarkeit: Ein öffentlicher Endpunkt kann drosseln, sich ändern oder verschwinden, und er schuldet dem Haus nichts. Und Aufsicht: Eine Abhängigkeit von einem externen Anbieter für eine wichtige Funktion ist eine IKT-Drittvereinbarung mit der zugehörigen Dokumentation, dazu die Seite DORA-Verordnung in Deutschland.

Dagegen steht der Betriebsalltag. Ein Node braucht die erste Synchronisierung, die Tage dauert, monatlich wachsenden Speicher, Client-Updates nach dem Fahrplan des Netzes und eine Überwachung, die ein Zurückfallen bemerkt. Die meisten Häuser betreiben einen eigenen Node für die wichtigen Abfragen und kaufen einen Anbieter für die Breite; das ist vertretbar, solange beide Wege dokumentiert sind.

Läuft ein Execution- oder Consensus-Client auf dem größten Teil eines Netzes und hat dieser Client einen Fehler, wird der Fehler zum Verhalten des Netzes, und die Nodes mit dem Minderheits-Client sind die, die korrekt verwerfen, was die Mehrheit annimmt. In einem Proof-of-Stake-Netz kann ein Fehler in einem Client mit Supermehrheit zudem dazu führen, dass die falsche Kette finalisiert wird; das ist ein Abwicklungsrisiko und keines in der Theorie.

Für ein Haus liest sich das als Anweisung zur Streuung mit Preis. Einen Minderheits-Client zu betreiben ist besser für das Netz und heißt, Software mit kleinerer Nutzerbasis, weniger Beispielen und anderem Fehlerprofil zu betreiben. Wer mehr als einen Node betreibt, sollte zumindest nicht überall dasselbe Client-Paar laufen lassen; das ist die billige Fassung derselben Einsicht und dieselbe Logik, die eine Bank bei ihren Lieferanten schon anwendet.

Häuser, die keine Nodes betreiben wollen, kaufen sie, und die Lieferanten teilen sich nach dem, was sie wirklich verkaufen. Blockdaemon betreibt Node- und Staking-Infrastruktur für institutionelle Kunden über viele Netze. Tangany ist ein deutscher Verwahranbieter, dessen Dienst den Kettenzugang hinter der Verwahrung enthält; das ist ein anderer Kauf, denn der Node kommt mit der regulierten Verwahrung und nicht allein.

Die Frage an einen Lieferanten ist schmal, und das Marketing beantwortet sie selten: ob der Node dediziert oder geteilt ist, ob es ein Archive Node ist, welche Client-Umsetzungen laufen, wo gehostet wird und was passiert, wenn er zurückfällt. Wer das Letzte nicht schriftlich beantwortet, verkauft einen Endpunkt und keine Infrastruktur.

Nein, und die meisten Anwendungen haben keinen. Eine Wallet, eine Anwendung oder eine Meldestrecke kann die Kette über einen gehosteten Anbieter lesen, und die große Mehrheit tut es. Der Grund für einen eigenen Node ist nicht die Funktion, sondern wer für die Antwort einsteht: Wer einen Bestand, eine Bewertung oder eine Transaktion gegenüber Aufsicht oder Prüfer erklären muss, steht anders da als eine Anwendung, die einem Nutzer einen Saldo anzeigt.

Die Hardware ist der kleine Teil. Ein Full Node braucht eine schnelle NVMe-Platte ab einem Terabyte, genug Arbeitsspeicher und eine Leitung mit echter Bandbreite nach außen, ein Archive Node ein Mehrfaches davon mit monatlicher Wachstumsrate. Der größere Posten ist ein Mensch: jemand, der die Client-Releases verfolgt, sie nach dem Fahrplan des Netzes einspielt, den Abstand des Nodes zur Kettenspitze beobachtet und erreichbar ist, wenn er stehenbleibt. Diese Zahl unterschätzt ein Haus, und darum gibt es den Hosting-Markt.