Ethereum-Archivknoten

Ein Archivknoten ist eine Instanz eines Ethereum-Clients, die so konfiguriert ist, dass sie ein Archiv aller historischen Zustände aufbaut. Er ist ein nützliches Werkzeug für bestimmte Anwendungsfälle, aber möglicherweise schwieriger zu betreiben als ein Full Node.

Voraussetzungen

Sie sollten das Konzept eines Ethereum-Knotens, seine Architektur, Synchronisierungsstrategien sowie die Praktiken für deren Betrieb und Nutzung verstehen.

Was ist ein Archivknoten?

Um die Bedeutung eines Archivknotens zu verstehen, lassen Sie uns das Konzept des „Zustands“ (State) klären. Ethereum kann als transaktionsbasierte Zustandsmaschine bezeichnet werden. Es besteht aus Konten und Anwendungen, die Transaktionen ausführen, welche ihren Zustand ändern. Die globalen Daten mit Informationen über jedes Konto und jeden Vertrag werden in einer Trie-Datenbank gespeichert, die als Zustand bezeichnet wird. Dies wird vom Client der Ausführungsschicht (Execution Layer, EL) gehandhabt und umfasst:

Kontostände und Nonces
Vertrags-Code und -Speicher
Konsensbezogene Daten, z. B. der Staking-Einlage-Vertrag (Staking Deposit Contract)

Um mit dem Netzwerk zu interagieren, neue Blöcke zu verifizieren und zu produzieren, müssen Ethereum-Clients mit den neuesten Änderungen (der Spitze der Chain) und somit dem aktuellen Zustand Schritt halten. Ein als Full Node konfigurierter Client der Ausführungsschicht verifiziert und verfolgt den neuesten Zustand des Netzwerks, speichert jedoch nur die letzten paar Zustände zwischen, z. B. den Zustand, der mit den letzten 128 Blöcken verknüpft ist, damit er Chain-Reorganisationen bewältigen und schnellen Zugriff auf aktuelle Daten bieten kann. Der aktuelle Zustand ist das, was alle Clients benötigen, um eingehende Transaktionen zu verifizieren und das Netzwerk zu nutzen.

Sie können sich den Zustand als eine momentane Momentaufnahme (Snapshot) des Netzwerks bei einem bestimmten Block und das Archiv als eine Wiederholung der Historie vorstellen.

Historische Zustände können sicher bereinigt (pruned) werden, da sie für den Betrieb des Netzwerks nicht erforderlich sind und es für den Client nutzlos redundant wäre, alle veralteten Daten aufzubewahren. Zustände, die vor einem bestimmten kürzlichen Block existierten (z. B. 128 Blöcke vor dem Head), werden effektiv verworfen. Full Nodes behalten nur historische Blockchain-Daten (Blöcke und Transaktionen) und gelegentliche historische Snapshots, die sie verwenden können, um ältere Zustände auf Anfrage neu zu generieren. Sie tun dies, indem sie vergangene Transaktionen in der EVM erneut ausführen, was rechenintensiv sein kann, wenn der gewünschte Zustand weit vom nächsten Snapshot entfernt ist.

Dies bedeutet jedoch, dass der Zugriff auf einen historischen Zustand auf einem Full Node viel Rechenleistung verbraucht. Der Client muss möglicherweise alle vergangenen Transaktionen ausführen und einen historischen Zustand ab dem Genesis-Block berechnen. Archivknoten lösen dies, indem sie nicht nur die neuesten Zustände speichern, sondern jeden historischen Zustand, der nach jedem Block erstellt wurde. Im Grunde genommen ist dies ein Kompromiss, der einen größeren Speicherplatzbedarf mit sich bringt.

Es ist wichtig zu beachten, dass das Netzwerk nicht auf Archivknoten angewiesen ist, um alle historischen Daten aufzubewahren und bereitzustellen. Wie oben erwähnt, können alle historischen Zwischenzustände auf einem Full Node abgeleitet werden. Transaktionen werden von jedem Full Node gespeichert (derzeit weniger als 400 GB) und können erneut abgespielt werden, um das gesamte Archiv aufzubauen.

Anwendungsfälle

Die reguläre Nutzung von Ethereum, wie das Senden von Transaktionen, das Bereitstellen von Verträgen, das Verifizieren des Konsenses usw., erfordert keinen Zugriff auf historische Zustände. Benutzer benötigen für eine Standardinteraktion mit dem Netzwerk niemals einen Archivknoten.

Der Hauptvorteil eines Zustandsarchivs ist der schnelle Zugriff auf Abfragen zu historischen Zuständen. Ein Archivknoten würde beispielsweise umgehend Ergebnisse liefern wie:

Wie hoch war der ETH-Kontostand des Kontos 0x1337... bei Block 15537393?
Wie hoch ist der Bestand des Tokens 0x im Vertrag 0x bei Block 1920000?

Wie oben erklärt, müsste ein Full Node diese Daten durch EVM-Ausführung generieren, was die CPU beansprucht und Zeit in Anspruch nimmt. Archivknoten greifen auf der Festplatte darauf zu und liefern Antworten sofort. Dies ist eine nützliche Funktion für bestimmte Teile der Infrastruktur, zum Beispiel:

Dienstleister wie Block-Explorer
Forscher
Sicherheitsanalysten
Entwickler von dezentralen Anwendungen (Dapps)
Wirtschaftsprüfung und Compliance

Es gibt verschiedene kostenlose Dienste, die ebenfalls Zugriff auf historische Daten ermöglichen. Da der Betrieb eines Archivknotens anspruchsvoller ist, ist dieser Zugriff meist begrenzt und funktioniert nur für gelegentliche Abfragen. Wenn Ihr Projekt ständigen Zugriff auf historische Daten erfordert, sollten Sie in Erwägung ziehen, selbst einen zu betreiben.

Implementierungen und Nutzung

Archivknoten in diesem Kontext bedeutet Daten, die von benutzerorientierten Clients der Ausführungsschicht bereitgestellt werden, da diese die Zustandsdatenbank verwalten und JSON-RPC-Endpunkte bereitstellen. Konfigurationsoptionen, Synchronisierungszeit und Datenbankgröße können je nach Client variieren. Weitere Details finden Sie in der Dokumentation Ihres Clients.

Bevor Sie Ihren eigenen Archivknoten starten, informieren Sie sich über die Unterschiede zwischen den Clients und insbesondere über die verschiedenen Hardwareanforderungen. Die meisten Clients sind nicht für diese Funktion optimiert und ihre Archive benötigen mehr als 12 TB Speicherplatz. Im Gegensatz dazu können Implementierungen wie Erigon dieselben Daten in unter 3 TB speichern, was sie zur effektivsten Möglichkeit macht, einen Archivknoten zu betreiben.

Empfohlene Praktiken

Abgesehen von allgemeinen Empfehlungen für den Betrieb eines Knotens kann ein Archivknoten anspruchsvoller in Bezug auf Hardware und Wartung sein. In Anbetracht der Hauptmerkmale (opens in a new tab) von Erigon ist der praktischste Ansatz die Verwendung der Erigon-Client-Implementierung.

Hardware

Stellen Sie immer sicher, dass Sie die Hardwareanforderungen für einen bestimmten Modus in der Dokumentation eines Clients überprüfen. Die größte Anforderung für Archivknoten ist der Speicherplatz. Je nach Client variiert dieser von 3 TB bis 12 TB. Auch wenn HDDs als bessere Lösung für große Datenmengen angesehen werden könnten, erfordern die Synchronisierung und die ständige Aktualisierung der Spitze der Chain SSD-Laufwerke. SATA (opens in a new tab)-Laufwerke sind ausreichend, sollten aber von zuverlässiger Qualität sein, mindestens TLC (opens in a new tab). Festplatten können in einen Desktop-Computer oder einen Server mit genügend Steckplätzen eingebaut werden. Solche dedizierten Geräte sind ideal für den Betrieb eines Knotens mit hoher Verfügbarkeit. Es ist durchaus möglich, ihn auf einem Laptop auszuführen, aber die Portabilität ist mit zusätzlichen Kosten verbunden.

Alle Daten müssen auf ein einziges Volume passen, daher müssen Festplatten zusammengefasst werden, z. B. mit RAID0 (opens in a new tab) oder LVM. Es könnte sich auch lohnen, die Verwendung von ZFS (opens in a new tab) in Betracht zu ziehen, da es „Copy-on-Write“ unterstützt, was sicherstellt, dass Daten ohne Low-Level-Fehler korrekt auf die Festplatte geschrieben werden.

Für mehr Stabilität und Sicherheit bei der Vermeidung versehentlicher Datenbankbeschädigungen, insbesondere in einem professionellen Setup, sollten Sie die Verwendung von ECC-Speicher (opens in a new tab) in Betracht ziehen, falls Ihr System dies unterstützt. Die Größe des RAMs wird im Allgemeinen genauso empfohlen wie für einen Full Node, aber mehr RAM kann helfen, die Synchronisierung zu beschleunigen.

Während der anfänglichen Synchronisierung führen Clients im Archivmodus jede Transaktion seit dem Genesis-Block aus. Die Ausführungsgeschwindigkeit wird hauptsächlich durch die CPU begrenzt, sodass eine schnellere CPU bei der anfänglichen Synchronisierungszeit helfen kann. Auf einem durchschnittlichen Verbrauchercomputer kann die anfängliche Synchronisierung bis zu einem Monat dauern.