Bitget App
Trade smarter
Krypto KaufenMärkteTradenFuturesCopyBotsEarn

Liebe und Leid der Archive Nodes

BitcoinblogBitcoinblog2024/09/23 13:01
Von:Christoph Bergmann

Matthias, genannt „Ghostie“, kennt sich mit Full Nodes aus. Auch mit denen, die Festplatte, CPU und Arbeitsspeicher quälen. In einem Gastbeitrag erzählt er von seinen Erfahrungen.

Von Ghostie

Der Betrieb eines Archive Nodes für Blockchains wie Ethereum oder Polyon ist aufwändig und teuer. Es ist mehr oder weniger die Königsklasse beim Aufsetzen von Nodes. Der Node braucht gute Hardware, Wartung (gutes Monitoring) und auch Zeit – zumindest immer dann, wenn das Monitoring anspringt oder ein neues Release ansteht. Das nimmt man in der Regel nur in Kauf, wenn man einen Grund dafür hat.

Ein Archive Node ist mehr als ein Full Node . Ein Full Node speichert „nur“ die gesamte Blockchain, während ein Archive Node zusätzlich jeden Zustand speichert, den jeder Smart Contract und jede Transaktion jemals (d.h. auf jeder Blockhöhe) hatte. Aus den Daten eines Full Nodes können jedoch die zusätzlichen Daten eines Archive Nodes rekonstruiert werden.

Da dies auf Twitter, bzw. X und auch in Online-Foren immer wieder zu Diskussionen führt, bringe ich gerne eine Analogie zu Bitcoin: Ein Archive-Node für Ethereum wäre für Bitcoin ein Node, der zu jeder Blockhöhe das auf dieser Blockhöhe gültige UTXO-Set speichert. Das ist natürlich kein besonders interessanter Anwendungsfall für Bitcoin, weil diese Daten (a) bei Bitcoin viel schneller rekonstruiert werden können und (b) auch keinen besonderen Informationsgehalt haben. Bei Ethereum ist das anders, weil es dort Smart Contracts gibt und die Speicherung der Zwischenzustände hier bedeutet, dass man z.B. direkt abfragen kann, wie viel USDT welcher Account zu welchem Zeitpunkt (also auf welcher Blockhöhe) hatte.

Meinen ersten Archive Node für das Ethereum Ökosystem habe ich 2019 synchronisiert. Damals aus reiner Neugier: Ich hatte für ein Projekt viel Server-Hardware (96 Cores, 768 GiB RAM, über 40 TiB SSD-Speicher) gekauft und wollte diese ausreizen. Also habe ich einen Archive Node für Ethereum mit geth synchronisiert, was ziemlich genau 7 Tage und 22 Stunden gedauert hat. Ich weiß das heute noch so genau, weil ich das Thema auf coinforum.de diskutiert und meinen Fortschritt dokumentiert habe.

Langfristig braucht es aber bessere Gründe. Das ist ein großer Unterschied zwischen Ethereum und Bitcoin. Bitcoiner synchronisieren die gesamte Blockchain aus Idealismus. Bei Ethereum nutzen die meisten Nutzer Knotenanbieter wie Infura oder Alchemy. Diese erlauben ca. 100.000 kostenlose API-Aufrufe, was für kleinere Projekte und Wallets mehr als ausreichend ist.

Wann und für wen ist ein Archive Node sinnvoll?

Kritisch wird es aber, wenn man Blockchain-Analysen durchführen will oder muss. Will man beispielsweise wissen, welche Accounts wann welche Guthaben eines Tokens auf Ethereum hatten, muss man durch blockweises Scannen der Blockchain alle Adressen herausfinden und dann für jede ERC20-Transaktion die historischen Guthaben abfragen. Das übersteigt selbst in einfachen Fällen die kostenlosen API-Aufrufe von Alchemy und Infura und wird schnell teuer. In solchen Fällen lohnt sich ein Archive Node, da allein das Scannen durch alle Blöcke zu so vielen API-Aufrufen führt, wie es aktuell Blöcke in der Blockchain gibt. Und Ethereum hat derzeit über 20 Millionen Blöcke.

Ich betreibe solche Knoten mittlerweile für Kunden. Die Gründe sind manchmal absurd. Eine Firma bietet zum Beispiel Hilfe bei der Erfüllung von EU-Vorschriften an. Diese verlangen, dass man für jedes Crypto-Asset den CO2-Verbrauch nachweisen muss. Wenn man nun einen Token auf Ethereum hat, muss man sämtliche vergangenen Transaktionen und Swaps zurückverfolgen, um zu berechnen, wie viel Gas der Token verbraucht hat. Das Gas entspricht der benötigten Rechenleistung und ist somit ein Indikator für den CO2-Verbrauch.

Das ist natürlich haarsträubend. Als Proof-of-Stake-Blockchain verbraucht Ethereum ohnehin sehr wenig Energie, und die Synchronisation eines Archive Nodes verursacht wahrscheinlich viel mehr CO2, als man durch die Regulierung jemals einsparen könnte (wenn überhaupt). Aber es ist nicht meine Aufgabe, solche Fragen zu stellen, sondern Nodes aufzusetzen.

Welche Ressourcen werden für den Betrieb eines Ethereum-Archive-Nodes benötigt?

Die Unterschiede zwischen den Nodes und Clienten sind teilweise enorm. Ich habe Erfahrung mit Ethereum, Polygon und Solana.

Ethereum benötigt mit dem Client Nethermind etwa 15 Terabyte Festplattenspeicher für die Daten des Execution-Layers, 8 CPU-Kerne (besser 16 für die Synchronisation) und 128 Gigabyte RAM. Ein alternativer Client ist Erigon, der mit nur drei Terabyte Daten auskommt. Erigon speichert die Daten im Vergleich zu Nethermind mit einem anderen Datenbankmodell, das neben einer sehr flachen Architektur nur Deltas zwischen einigen Blöcken speichert. Dies hat allerdings zur Folge, dass historische Abfragen in manchen Fällen etwas länger dauern können, aber auch viel Platz gespart wird.

Für einen Server ist der Bedarf überschaubar. Wenn man einmal synchronisiert hat, braucht man weniger. Die größte Herausforderung sind die Festplatten, oder besser gesagt die SSDs. Um das zu verstehen, muss man wissen, wie Smart Contracts mit der Ethereum Virtual Machine (EVM) funktionieren. Ich will euch damit nicht langweilen, also nur so viel: Jeder Smart Contract hat seinen eigenen virtuellen Speicherbereich, der je nach Account einen anderen Teil davon nachladen muss. Das führt ständig (mit jedem neuen Block) zu vielen Lese- und während der Synchronisation auch Schreiboperationen (I/O).

Deshalb sind klassische Festplatten (HDDs) nicht mehr zeitgemäß, man braucht SSDs. Wer Nethermind nutzt, muss mehrere zusammenschalten, um die mindestens 15 Terabyte zu speichern. Wenn man das mit AWS macht, kostet das schnell einen vierstelligen Betrag. Mit Erigon kann man im Prinzip auch einen Archive Node auf einem leistungsfähigen PC synchronisieren.

Polygon und Solana

Dabei ist Ethereum noch relativ ressourcenschonend! Andere EVM-kompatible Blockchains wie Polygon oder auch nicht-EVM-kompatible wie Solana haben die gleichen oder sehr ähnliche Probleme: Um sich zu synchronisieren, muss Zustand für Zustand berechnet und gespeichert werden, und jede Abfrage eines Smart Contracts erfordert extrem viele I/O-Operationen.

Man kann sich vorstellen, was passiert, wenn man wie bei Polygon die Blockzeiten verkürzt: Man braucht noch bessere Festplatten, um die Anfragen zu verarbeiten. Bei Ethereum reichen 6.000 IOPS, bei Polygon sind es schon 20.000 IOPS, die für die Synchronisation mit Erigon empfohlen werden. Das treibt die Kosten bei AWS weiter in die Höhe, ich schätze, wir sind jetzt schon bei 8.000 Euro im Monat, wenn wir uns an die Systemanforderungen für einen Archive Node halten.

Als Client für den Polygon Archive Node wird in der Regel Erigon verwendet. Während Erigon bei Ethereum nur 3 Terabyte Speicher benötigt, sind es bei Polygon bereits 10 Terabyte. Dabei ist Polygon wesentlich jünger als Ethereum. Man kann sich also schon ausrechnen, wie der Ressourcenverbrauch in Zukunft aussehen wird und wie viel Speicher ein Polygon Archive Node hypothetisch mit einem anderen Client benötigen würde.

Solana ist noch extremer. Dafür habe ich einmal zwei Nodes betrieben, für Mainnet und Testnet, um am Solana Grant teilzunehmen. Das waren aber keine Archivknoten, sondern nur Validatoren. Schon für die braucht man eine CPU mit mindestens 12 Kernen und für das Testnet mindestens 128 GiB RAM, für das Mainnet sogar mindestens 256 GiB RAM (zum besseren Vergleich: Mindestens einer der Solana-Ausfälle wurde dadurch verursacht, dass zu viele der Validatoren „nur“ 128 GiB RAM hatten). Auch die Netzwerkanbindung sollte gut sein, laut Systemanforderungen mindestens 1 Gbit/s synchron (zwei Validatoren verursachen eine konstante Auslastung von 300 Mbit/s), mit einem Trafficvolumen von knappen 100 TiB pro Monat pro Validator. Das hat man in Deutschland an den wenigsten Orten.

Ein normaler Solana Node benötigt bereits 2 Terabyte, ein Archive Node laut Internet ca. 100 Terabyte. Die Kosten sind bereits enorm.

Kann das langfristig gut gehen?

Es gibt Zweifel, ob das auf Dauer gut gehen kann. Ich persönlich glaube schon, ich glaube an den technischen Fortschritt. Ein Beispiel verdeutlicht das: Als ich 2019 meinen Geth-Node synchronisiert habe, hat das gut eine Woche gedauert. Heute dauert es mit leistungsfähigerer Hardware kaum länger, obwohl die Blockchain viel größer geworden ist. Das liegt nicht nur an besserer Hardware, sondern auch an besseren Algorithmen, die zum Beispiel bei Nethermind mit der Version 1.26 zu einer 30 bis 50 Prozent schnelleren Blockverarbeitung geführt haben.

Hard- und Software werden immer leistungsfähiger, was sich besonders bei Servern zeigt. Aber schon heute genügt es, hypothetisch 250.000 Euro zu investieren, um einen Archive Node für Solana für die nächsten zehn Jahre betreiben zu können. Solange es einen Grund und ein Geschäftsmodell gibt, wird es auch jemand machen. Deshalb mache ich mir keine Sorgen, dass es irgendwann keine Archive Nodes mehr geben wird.

Es reicht jedoch nicht aus, einfach mehr Geld in Hardware zu investieren, um zu skalieren. Sobald eine Blockchain weit verbreitet ist, stößt sie von selbst an Grenzen der Skalierbarkeit. Ohne viele Accounts erreichen viele Projekte in synthetischen Benchmarks leicht eine fünf- oder sogar sechsstellige Anzahl von Transaktionen pro Sekunde. Dies liegt daran, dass Accounts und aktuelle Zustände leicht in den CPU-Cache passen und Benchmarks aus Marketinggründen oft optimal parallelisierbar aufgebaut sind.

Aber sobald man mehr Nutzer hat, wie bei Bitcoin, wird es eng. Selbst hier wird es bei nur 7 Transaktionen pro Sekunde schon bei 4 Gigabyte Arbeitsspeicher kritisch, weil das UTXO-Set so groß ist. Und dieses – bzw. der Zustand (State) – ist bei anderen Blockchains noch viel größer und komplexer. Deshalb sollte man den Versprechungen der Blockchain-Entwickler aus dem Labor nicht glauben. In der Praxis wird es immer schwieriger.

Darüber hinaus gibt es eine natürliche Barriere, die Latenzzeit. Der Datenverkehr benötigt eine bestimmte Zeit, um von einem Knoten zum anderen zu gelangen. Es gibt eine physikalische Barriere, die durch die Lichtgeschwindigkeit definiert ist. Ein Forschungspapier (Information Propagation in the Bitcoin Network) kam zu dem Schluss, dass ein Blockintervall von mindestens 12,6 Sekunden erforderlich ist, damit sich ein Block zu den meisten Knoten auf der Welt ausbreiten kann. Daraus leitet sich bis heute das Blockintervall von Ethereum ab. Modernere Blockchains wie Solana haben deutlich kürzere Intervalle, weshalb sich die Nodes bereits in Europa und den USA sowie in Rechenzentren konzentrieren.

Damit sind wir wieder bei der alten Frage der Dezentralität und Skalierbarkeit. Wenn ich nur wenige Nodes habe, die alle nahe beieinander liegen, kann ich gut skalieren. Aber man muss kein Bitcoin-Maximalist sein, um sich zu wünschen, dass Full und Archive Nodes über die ganze Welt verteilt sein können.

Und keiner weiß davon…

Kürzlich habe ich wieder einen Ethereum (Nethermind) und einen Polygon (Erigon) Archive Node synchronisiert. Beide Clients hatten einen Bug, der die Synchronisation als Archive Node verhinderte. Während sich bei Nethermind durch die oben erwähnte Optimierung ein Bug eingeschlichen hatte, der nach einer kurzen Entschuldigung („ja, wir optimieren nicht für den Betrieb als Archive Node“) auch behoben wurde, bleibt der Bug bei Erigon offen, obwohl seit 3 Wochen ein Entwickler zugeordnet ist. Scheint wohl nicht so wichtig zu sein.

Die Bugs wurden durch Upgrades verursacht, die die Blockverarbeitung verändert haben. Man bemerkt sie nicht, wenn ein Archive Node läuft, und man bemerkt sie nicht, wenn man einen normalen Node synchronisiert. Erst wenn man sich die Mühe macht, einen Archive Node neu zu synchronisieren, merkt man es, je nach Server auch erst nach Wochen.

Die Tatsache, dass die Bugs in beiden Fällen bereits seit Wochen bestanden, zeigt, wie selten es vorkommt, dass jemand einen Archive Node neu synchronisiert. Dies hat zur Folge, dass solche Fehler lange Zeit unbemerkt bleiben und es in Zukunft zu einer Situation kommen kann, in der die Software die Synchronisation neuer Archive Nodes unmöglich macht und niemand davon weiß – weil es so selten vorkommt, dass ein neuer Archive Node erstellt wird.

In meinem Fall hat es gut funktioniert. Ich habe den Fehler an Nethermind gemeldet und den Entwicklern geholfen, ihn zu beheben. Bei Erigon war der Fehler schon bekannt, wurde aber für eine spätere Version gemeldet, als er bei mir auftrat. Hier benutze ich jetzt einfach eine ältere Version – bei Polygon ist das nicht so schlimm. Aber wenn sich so ein Bug tiefer eingräbt, weil die Archive Nodes noch seltener synchronisiert werden und das CI/CD der Node-Entwickler nicht verbessert wird, kann es sein, dass er nicht mehr so einfach zu beheben ist.

Es bleibt also möglich – aber eine Herausforderung, die im Lauf der Zeit nicht kleiner werden wird.

0

Haftungsausschluss: Der Inhalt dieses Artikels gibt ausschließlich die Meinung des Autors wieder und repräsentiert nicht die Plattform in irgendeiner Form. Dieser Artikel ist nicht dazu gedacht, als Referenz für Investitionsentscheidungen zu dienen.

PoolX: Stake to Earn
APR von bis zu 10%. Mehr verdienen, indem Sie mehr staken.
Jetzt staken!