Einen Ethereum-Node einrichten (Anleitung 2026)

Ein Ethereum-Node gibt Ihnen direkten Zugriff auf das Netzwerk: Ihren eigenen JSON-RPC-Endpoint, keine Rate Limits, keine dritte Partei, die Ihre Abfragen mitliest. Diese Anleitung führt Sie von einem leeren Ubuntu-Server zu einem synchronisierten Node mit Copy-paste-Befehlen — Geth als Execution-Client, Lighthouse als Consensus-Client, beide von systemd verwaltet. Sie deckt außerdem ab, was die meisten Tutorials auslassen: Hardware im Jahr 2026, Sync-Dauer, monatliche Kosten und wann Sie mit einer API besser fahren.

Was ist ein Ethereum-Node?

Ein Ethereum-Node ist ein Computer, der Ethereum-Client-Software ausführt, eine Kopie der Blockchain speichert, jeden eingehenden Block gegen die Protokollregeln prüft und eine JSON-RPC-Schnittstelle bereitstellt, die Wallets und Anwendungen zum Lesen der Chain und Senden von Transaktionen nutzen.

Seit dem Merge im September 2022 ist „der Client” eigentlich zwei Programme, die Seite an Seite laufen müssen. Der Execution-Client (Geth, Nethermind, Besu, Erigon oder Reth) hält den State, führt Transaktionen aus und beantwortet JSON-RPC-Aufrufe. Der Consensus-Client (Lighthouse, Prysm, Teku, Nimbus oder Lodestar) kümmert sich um Proof of Stake: Er folgt der Beacon Chain und teilt dem Execution-Client mit, welcher Block der aktuelle Head ist. Die beiden sprechen über einen authentifizierten lokalen Port (8551) und identifizieren sich gegenseitig mit einem gemeinsamen JWT-Secret. Einer ohne den anderen ist kein funktionierender Node. Dieses Detail stolpert die meisten Erstbetreiber.

Es gibt drei Storage-Profile. Ein Full Node hält aktuellen State und prunt alte Daten; Geth braucht Mitte 2026 rund 1,2–1,4 TB. Ein Archive-Node hält jeden historischen State — weit über 10 TB auf Geths klassischem Hash-basiertem Layout, oder etwa 2–3 TB auf dafür gebauten Clients wie Erigon und Reth. Ein Light Node lädt nur Header herunter; das klingt attraktiv, aber fast keine Peers bedienen Light Clients im Mainnet, sodass es kein praktikabler Zugriffsweg ist.

Ethereum-Node-Anforderungen

Die folgenden Zahlen beschreiben einen Full Node im Jahr 2026. Ein Archive-Node ist ein eigenes Projekt, und ein Validator fügt keine zusätzliche Hardware zu einem soliden Full Node hinzu.

Zwei Zeilen verdienen eine Erklärung.

Storage muss NVMe sein. Das Syncen schreibt kleine zufällige Datenblöcke mit hoher Rate. SATA-SSDs bleiben regelmäßig tagelang in Geths State-Heal-Phase hängen, und Cloud-Volumes mit Standard-IOPS werden oft überhaupt nicht fertig. Eine TLC-NVMe-Platte mit DRAM-Cache ist die sichere Wahl. Zur Kapazität: Geths Datenbank liegt bei etwa 1,2 TB und Lighthouse fügt rund 200–250 GB hinzu, sodass 2 TB heute funktionieren, aber wenig Spielraum lassen — 4 TB kaufen Ihnen Jahre.

Auch der Traffic summiert sich. Ein Node bewegt in der Größenordnung von 1 TB pro Monat. Heimanschlüsse verkraften das problemlos; VPS-Pläne mit engen Traffic-Limits nicht.

Linux, macOS und Windows funktionieren alle. Jeder Befehl unten geht von Ubuntu 24.04 aus, einem verbreiteten Server-Standard.

Wege, einen Node zu betreiben

Sie müssen nicht alles selbst zusammenbauen. Plug-and-play-Boxen wie DappNode und Avado sind vorkonfigurierte Maschinen mit Dashboard: kaufen, anschließen, dem Assistenten folgen. ARM-Boards funktionieren ebenfalls — Ethereum on ARM veröffentlicht fertige Images für Boards der Raspberry-Pi-5-Klasse mit NVMe-Speicher, günstig im Betrieb, aber langsamer beim Sync. Launcher automatisieren den manuellen Weg: eth-docker (Docker-basiert, Terminal-Kenntnisse erforderlich), Stereum (installiert Clients auf einem entfernten Server per SSH mit GUI), NiceNode (Client wählen, in wenigen Klicks starten) und Sedge (ein CLI-Assistent von Nethermind, der eine Docker-Konfiguration generiert).

Cloud oder lokal? Ein VPS ist für die Entwicklung in Ordnung. Ist Zensurresistenz Teil Ihrer Motivation, betreiben Sie den Node auf eigener Hardware — ein Node innerhalb einer großen Cloud-Region erbt die Rechtsprechung und AGB dieses Anbieters.

Der Rest dieser Anleitung führt das manuelle Setup durch. Es lehrt Sie am meisten, und alles, was Sie lernen, überträgt sich auf die Launcher.

Schritt für Schritt: Geth + Lighthouse auf Ubuntu

1. Server vorbereiten

sudo apt update && sudo apt upgrade -y
sudo useradd --no-create-home --shell /usr/sbin/nologin geth
sudo useradd --no-create-home --shell /usr/sbin/nologin lighthouse
sudo mkdir -p /var/lib/geth /var/lib/lighthouse
sudo chown geth:geth /var/lib/geth
sudo chown lighthouse:lighthouse /var/lib/lighthouse

Öffnen Sie die Peer-to-Peer-Ports und nichts weiter:

sudo ufw allow 30303 comment 'geth p2p'
sudo ufw allow 9000 comment 'lighthouse p2p'
sudo ufw allow 9001/udp comment 'lighthouse quic'

Die Ports 8545 (JSON-RPC) und 8551 (Engine API) bleiben nach außen geschlossen; beide binden unten in den Units an localhost.

2. Geth installieren

sudo add-apt-repository -y ppa:ethereum/ethereum
sudo apt update
sudo apt install -y ethereum
geth version

3. Lighthouse installieren

Lighthouse wird als statisches Binary ausgeliefert. Dieser Snippet holt immer das neueste Release:

LH=$(curl -s https://api.github.com/repos/sigp/lighthouse/releases/latest | grep -m1 '"tag_name"' | cut -d '"' -f 4)
curl -LO "https://github.com/sigp/lighthouse/releases/download/${LH}/lighthouse-${LH}-x86_64-unknown-linux-gnu.tar.gz"
tar xzf "lighthouse-${LH}-x86_64-unknown-linux-gnu.tar.gz"
sudo mv lighthouse /usr/local/bin/
lighthouse --version

Überprüfen Sie den Download: Jede Release-Seite listet SHA-256-Prüfsummen und eine PGP-Signatur; führen Sie sha256sum aus und vergleichen Sie, oder importieren Sie Sigma Primes Key und nutzen Sie gpg --verify. Vertauschte Binaries sind ein realer Angriffsvektor, und die Prüfung dauert eine Minute.

4. JWT-Secret erstellen

sudo mkdir -p /var/lib/jwt
openssl rand -hex 32 | sudo tee /var/lib/jwt/jwt.hex > /dev/null

Beide Clients lesen diese Datei. Sehen sie unterschiedliche Secrets, verweigern sie das Gespräch miteinander (siehe Troubleshooting).

5. systemd-Unit für Geth

Erstellen Sie /etc/systemd/system/geth.service:

[Unit]
Description=Geth execution client (mainnet)
After=network-online.target
Wants=network-online.target

[Service]
User=geth
Group=geth
Type=simple
Restart=always
RestartSec=5
TimeoutStopSec=600
ExecStart=/usr/bin/geth \
  --mainnet \
  --syncmode snap \
  --datadir /var/lib/geth \
  --http --http.addr 127.0.0.1 --http.port 8545 \
  --http.api eth,net,web3,txpool \
  --authrpc.addr 127.0.0.1 --authrpc.port 8551 \
  --authrpc.vhosts localhost \
  --authrpc.jwtsecret /var/lib/jwt/jwt.hex

[Install]
WantedBy=multi-user.target

TimeoutStopSec=600 ist wichtig: Geth schreibt den State beim Herunterfahren auf die Platte, und ein zu frühes Beenden ist der klassische Weg, die Datenbank zu beschädigen.

6. systemd-Unit für Lighthouse

Erstellen Sie /etc/systemd/system/lighthouse.service:

[Unit]
Description=Lighthouse consensus client (mainnet)
After=network-online.target geth.service
Wants=network-online.target

[Service]
User=lighthouse
Group=lighthouse
Type=simple
Restart=always
RestartSec=5
ExecStart=/usr/local/bin/lighthouse bn \
  --network mainnet \
  --datadir /var/lib/lighthouse \
  --execution-endpoint http://127.0.0.1:8551 \
  --execution-jwt /var/lib/jwt/jwt.hex \
  --checkpoint-sync-url https://mainnet.checkpoint.sigp.io \
  --http

[Install]
WantedBy=multi-user.target

Die Checkpoint-Sync-URL lässt Lighthouse von einem aktuellen finalisierten State starten, statt die Beacon Chain vom Genesis-Block an neu abzuspielen: Sekunden statt Tage. Sie vertrauen diesem Endpoint für Ihren Startpunkt; prüfen Sie den State-Root gegen eine zweite Quelle wie beaconstate.info, falls Sie das stört.

7. Starten und beobachten

sudo systemctl daemon-reload
sudo systemctl enable --now geth lighthouse
journalctl -fu geth

Geth protokolliert zunächst Header-Downloads, dann einen endlosen Strom von „Imported new chain segment”-Zeilen; Lighthouse meldet synchronisierte Slots innerhalb von Minuten. Sync-Fortschritt prüfen:

curl -s -X POST -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}' \
  http://127.0.0.1:8545

{"result":false} bedeutet vollständig synchronisiert. Während des Syncens erhalten Sie stattdessen ein Progress-Objekt.

Wie lange dauert der Sync?

Ethereum hat keine offiziellen Datenbank-Snapshots zum Herunterladen, und braucht sie auch nicht — die schnellen Pfade sind in die Clients eingebaut.

Lighthouse erreicht mit Checkpoint-Sync den Chain-Head in unter einer Minute und füllt historische Blocks im Hintergrund auf. Geth im Snap-Sync-Modus (dem Standard) zieht etwa 800 GB bis 1 TB aus dem Netzwerk und baut dann den State-Trie lokal wieder auf. Auf der empfohlenen Hardware planen Sie ein bis zwei Tage; auf Minimum-Hardware mit mittelmäßiger Platte drei bis fünf. Das Ende der Strecke ist die „State-Heal”-Phase, und läuft sie tagelang ohne Abschluss, ist Ihre Platte zu langsam — siehe Troubleshooting.

Nach dem initialen Sync beruhigt sich die Lage. Seit Version 1.13 prunt Geth den State fortlaufend (path-based State Storage), sodass die Datenbank nicht mehr unbegrenzt wächst, wie ältere Anleitungen warnen. Geth 1.16 und neuer kann außerdem Pre-Merge-Historie fallen lassen (--history.chain postmerge), was einige hundert GB freimacht, falls der Platz eng wird.

Sync-Modi: snap, full und archive

Das Flag --syncmode in der Geth-Unit entscheidet, wie viel der Chain Sie selbst verifizieren und wie viel Speicherplatz Sie dafür bezahlen. Es gibt drei Modi, und der richtige folgt aus den Fragen, die der Node beantworten soll.

Snap-Sync ist der Standard und was diese Anleitung verwendet. Geth lädt den aktuellen State direkt von Peers herunter, verifiziert Block-Header zurück bis zum Genesis-Block und heilt dann den State-Trie. Ergebnis: ein bedienbarer Full Node in ein bis zwei Tagen und eine Datenbank von etwa 1,2–1,4 TB Mitte 2026, die von dort aus wächst.

Full-Sync (--syncmode full) führt jede Transaktion seit 2015 erneut aus, statt State herunterzuladen. Das Endergebnis auf der Platte ist dieselbe geprunte Datenbank, aber der Sync läuft selbst auf starker Hardware wochenlang. Sie wählen ihn aus einem Grund: Sie weigern sich, dem State-Download zu vertrauen, und wollen die gesamte Historie auf der eigenen Maschine neu berechnen. Das ist eine Forschungshaltung, keine betriebliche Notwendigkeit.

Archive-Modus liegt auf einer anderen Achse: --gcmode archive auf einem Full-Sync hält jeden Zwischenstate statt zu prunen. Nur ein Archive-Node beantwortet „wie hoch war dieser Kontostand bei Block 15.000.000” oder führt tiefe Traces ohne Neuberechnung aus, was Indexer, Steuer-Tools und Analytics-Plattformen brauchen. Auf Geths klassischem Hash-basiertem Layout kostet das weit über 10 TB. Erigon und Reth speichern Historie anders und landen Archive-Nodes Mitte 2026 im Bereich von 2–3 TB, sodass fast jedes neue Archive-Deployment mit einem der beiden startet; Geths neuerer path-based Archive-Modus spielt in derselben Größenklasse, hat aber weniger Produktionserfahrung.

Für ein Payment-Backend beantwortet Snap-Sync alles: aktuelle Guthaben, neue Blocks, Transaction Receipts. Archive ist für den Tag, an dem Sie die Vergangenheit rekonstruieren müssen.

Client-Wahl und Vielfalt

Geth plus Lighthouse ist eine solide Standardwahl, und genau seine Popularität ist der Haken. Ethereums Sicherheitsmodell setzt voraus, dass kein Client zu viel vom Netzwerk kontrolliert: Ein Consensus-Bug in einem Client mit mehr als zwei Dritteln der Validatoren könnte eine kaputte Chain finalisieren — der eine Fehler, den das Protokoll nicht sauber rückgängig machen kann. Selbst ein Ein-Drittel-Anteil ist unangenehm, weil das Ausfallen dieses Clients allein die Finalität stoppen würde.

Wo das Netzwerk Mitte 2026 steht: Geth führt die Execution-Ebene weiterhin an mit einem Anteil, den Messungen zwischen einem Drittel und etwa 40 Prozent verorten, Nethermind folgt in den Zwanzigern bis Dreißigern, Besu und Reth halten niedrige zweistellige Werte, Erigon einige Prozent. Auf der Consensus-Seite ist Lighthouse nach den meisten Zählungen über die Ein-Drittel-Komfortlinie hinausgewachsen, Prysm folgt an zweiter Stelle, dahinter Teku und Nimbus. Das Netzwerk wird jedes Mal sicherer, wenn ein Betreiber einen Minderheits-Client wählt, und der Betreiber gibt dabei wenig auf — alle Execution-Clients sprechen dieselbe JSON-RPC, alle Consensus-Clients dieselbe Beacon-API.

Ende 2025 wurde das Argument konkret. Kurz nach dem Fusaka-Upgrade erzwang ein Bug in einem weitverbreiteten Consensus-Client Notfall-Patches, während Nodes auf den anderen Clients ohne Unterbrechung weiter validierten. Betreiber auf Minderheits-Kombinationen lasen über diesen Vorfall, statt ihn managen zu müssen.

Für einen ersten Node ist die Kombination in dieser Anleitung in Ordnung. Für einen zweiten Node, oder alles Professionelle, wählen Sie eine Minderheits-Kombination wie Nethermind mit Teku oder Reth mit Nimbus. Das Setup oben überträgt sich fast eins zu eins — jede Kombination braucht dasselbe JWT-Secret und dieselbe Engine-API-Verkabelung; nur Binaries, Flags und Datenverzeichnisse ändern sich.

Was der Betrieb eines Ethereum-Nodes kostet

Keine exakten Preise hier; sie ändern sich monatlich und variieren nach Land. Stattdessen die Rechnung, um es selbst durchzuführen.

Eigene Hardware: Ein Mini-PC in der Anforderungsklasse (8 Kerne, 32 GB RAM, 2–4 TB NVMe) ist eine einmalige Anschaffung im mittleren dreistelligen Euro-Bereich. Die Leistungsaufnahme liegt bei etwa 30–60 W. Die Rechnung: 0,03–0,06 kW × 720 h ≈ 20–45 kWh pro Monat; multiplizieren Sie mit Ihrem Strompreis. Bei 0,30 €/kWh sind das 6–13 € pro Monat zusätzlich zum Internetanschluss, den Sie ohnehin bezahlen.

Gemieteter Server: VPS-Pläne mit ehrlichen 2 TB NVMe sind selten, sodass Sie in der Praxis bei einem Einstiegs-Dedicated-Server landen. Das bringt Sie in den niedrigen dreistelligen Euro-Bereich pro Monat — eine Größenordnung, kein Angebot. Cloud-Instanzen mit provisionierten IOPS kosten spürbar mehr als die vergleichbare dedizierte Box.

Ihre Zeit: Das erste Setup ist ein Nachmittag mit dieser Anleitung; laufend Client-Updates und ein gelegentlicher Blick in die Logs, rechnen Sie eine Stunde pro Monat. Wenn Sie Ihre Zeit verrechnen, gehört diese Zeile auch in die Gesamtrechnung.

Monitoring und Health Checks

Drei Fragen decken die Node-Gesundheit ab: Läuft der Prozess, ist er synchronisiert, hat er Peers. systemd beantwortet die erste mit systemctl is-active geth lighthouse. Die anderen beiden haben Endpoints auf beiden Ebenen:

# execution: peer count as hex; eth_syncing from step 7 covers sync state
curl -s -X POST -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","method":"net_peerCount","params":[],"id":1}' \
  http://127.0.0.1:8545

# consensus: HTTP 200 = synced, 206 = still syncing
curl -s -o /dev/null -w '%{http_code}\n' \
  http://127.0.0.1:5052/eth/v1/node/health

Lighthouses REST-API lauscht über das bereits in der Unit gesetzte --http-Flag auf Port 5052. Der Endpoint /eth/v1/node/health kodiert den Sync-State im HTTP-Status-Code, was ihn zu einer natürlichen Prüfung für Skripte und Load Balancer macht; /eth/v1/node/syncing gibt die Distanz in Slots zurück, falls Sie die Zahl wollen. Ein Cron-Job, der diese Checks plus df -h /var/lib/geth ausführt und bei Anomalien eine Mail schickt, ist vollständiges Monitoring für einen persönlichen Node.

Für Dashboards fügen Sie --metrics bei Geth (Prometheus-Endpoint auf Port 6060) und --metrics bei Lighthouse (Port 5054) hinzu, halten Sie beide auf localhost, und importieren Sie die Grafana-Dashboards, die beide Projekte veröffentlichen. Was auch immer Sie bauen, setzen Sie zwei Alerts vor allen anderen: Speichernutzung über 85 Prozent, und Block-Höhe zehn Minuten lang unverändert. Diese beiden fangen fast jeden echten Ausfall, bevor Ihre Nutzer ihn bemerken.

Wartung und Upgrades

Client-Updates sind nicht optional. Hard Forks erfordern neue Software, und ein Node auf einer alten Version hört am Fork-Block einfach auf, der Chain zu folgen. Abonnieren Sie die Geth- und Lighthouse-Release-Feeds auf GitHub und den Blog der Ethereum Foundation — das Netzwerk liefert derzeit etwa ein größeres Upgrade pro Jahr, mit Client-Releases dazwischen.

Der Ablauf bleibt kurz. Geth aus dem PPA aktualisiert sich mit sudo apt upgrade und sudo systemctl restart geth; bestätigen Sie mit geth version. Lighthouse ist ein einzelnes Binary: Wiederholen Sie den Download aus Schritt 3, ersetzen Sie /usr/local/bin/lighthouse, starten Sie die Unit neu. Lesen Sie die Release Notes vor dem Neustart — Flags werden gelegentlich umbenannt, und ein umbenanntes Flag in einer systemd-Unit bedeutet einen Dienst, der um 2 Uhr nachts den Start verweigert.

Planen Sie auch Speicherwachstum ein. Ein Geth-Full-Node fügt Mitte 2026 in der Größenordnung von 10–15 GB pro Woche hinzu; Lighthouse wächst langsamer. Auf einer 2-TB-Platte ist das ein Countdown, den Sie zurücksetzen können — Pre-Merge-History-Expiry macht einige hundert GB frei (siehe Troubleshooting), und ein frischer Snap-Sync baut in ein bis zwei Tagen eine vollständig kompaktierte Datenbank neu auf. Bei 4 TB ist Wachstum eine jährliche statt einer vierteljährlichen Angelegenheit. Der Node muss nicht jede Sekunde online sein, aber je länger er offline ist, desto länger braucht er zum Aufholen.

Ein Full Node ist kein Validator

Die 32 ETH, von denen jeder gehört hat, gehören zum Staking, nicht zum Node-Betrieb. Der Node in dieser Anleitung braucht überhaupt kein ETH — er validiert Blocks im Sinne des Prüfens, was Hardware kostet, keinen Stake.

Ein Validator ist ein drittes Programm neben den beiden Clients: Er hält Signing-Keys, produziert Attestations und Blocks und verdient dafür Belohnungen, mit einer Fee-Recipient-Adresse, die für das Einkommen konfiguriert ist. Die 32 ETH sind Sicherheiten, die das Protokoll bei nachweisbarem Fehlverhalten einziehen kann. Auch der operative Maßstab verschiebt sich — ein RPC-Node, der ein Wochenende offline ist, holt am Montag einfach auf, während ein offline stehender Validator jede Epoche kleine Strafen erleidet.

Mit weniger als 32 ETH ist gepooltes Staking der Einstieg: Rocket Pool und ähnliche Protokolle erlauben es permissionless Betreibern, Validatoren mit einem kleineren Bond zu betreiben, und manche Pool-Setups laufen auf genau dem oben gebauten Node. Ein reiner Full Node verdient nichts. Sie betreiben ihn für Unabhängigkeit und Privatsphäre, zur Entwicklung, oder als die Basis, auf der später ein Validator steht.

Sicherheit: Das Port-Layout ist die Policy

Das gesamte Sicherheitsmodell dieses Setups ist in den Firewall-Regeln aus Schritt 1 sichtbar. Die Ports 30303 und 9000/9001 sind offen, weil Peer-to-Peer Fremde braucht; 8545 und 8551 binden an 127.0.0.1, weil nichts außerhalb der Maschine dort etwas zu suchen hat. Das JWT-Secret authentifiziert die Engine-API auf 8551, aber behandeln Sie es als zweite Schicht, nicht als Grund, den Port zu öffnen.

Ein offener 8545 ist der schlimmere Fehler, weil JSON-RPC überhaupt keine Authentifizierung hat. Scanner finden exponierte Ethereum-RPC-Ports schnell, und der Schaden geht über Trittbrettfahren hinaus: Mit den falschen Namespaces aktiviert, bekommen Außenstehende Debugging-Interna und Mempool-Inhalte, die sie nie sehen sollten. Halten Sie --http.api bei den vier Namespaces aus der Unit; admin, debug und personal bleiben auf jeder Maschine aus, deren RPC-Port jemals erreichbar sein könnte.

Wenn andere Maschinen legitim die RPC brauchen, tunneln Sie statt zu exponieren: WireGuard oder ein SSH-Tunnel für Sie selbst, nginx oder Caddy mit TLS und einer IP-Allowlist für ein kleines Team. Die Clients laufen bereits als No-Login-Systembenutzer aus Schritt 1, sodass ein kompromittierter Client-Prozess keinen Shell-Account erbt, in den er sich einnisten könnte. Fügen Sie unattended-upgrades für OS-Patches hinzu, und der langweilige Teil der Serversicherheit kümmert sich von selbst.

Troubleshooting

Lighthouse erreicht Geth nicht (“Unable to connect to execution endpoint”)

Entweder ist Geth down (systemctl status geth), oder die JWT-Secrets unterscheiden sich. Bestätigen Sie, dass beide Units auf denselben jwt.hex-Pfad zeigen. Im Zweifel regenerieren Sie das Secret einmal und starten beide Dienste neu.

Geth hängt tagelang bei “State heal in progress”

Die State-Heal-Phase jagt dem Chain-Head hinterher, und eine Platte mit schwacher Random-Write-Performance holt nie auf. Benchmarken Sie mit fio; Sie wollen zehntausende 4k-IOPS. SATA-SSDs und Standard-Cloud-Volumes sind die üblichen Übeltäter. Die Lösung ist echter NVMe-Speicher — kein Flag rettet eine langsame Platte.

Peer-Anzahl bleibt bei null

Port 30303 (TCP und UDP) ist blockiert oder nicht durch Ihr NAT weitergeleitet. Prüfen Sie auch die Systemuhr: timedatectl sollte aktive NTP-Synchronisation zeigen, weil eine verschobene Uhr Peer-Handshakes auf der Consensus-Seite bricht.

Die Platte läuft voll

Finden Sie zuerst das Wachstum: du -h --max-depth=2 /var/lib/geth. Ein vor Geth 1.13 erstelltes Datadir nutzt noch das alte Hash-basierte Layout; der saubere Fix ist ein frischer Resync, danach bleibt der State automatisch geprunt. Pre-Merge-History-Expiry zu aktivieren gibt einige hundert GB mehr frei, und der Ancient Store kann per --datadir.ancient auf eine günstige HDD umziehen.

Geth meldet Datenbank-Korruption nach einem Absturz

Stromausfall, kill -9 oder ein OOM-Kill mitten im Schreibvorgang hinterlässt beim nächsten Start Log-Zeilen über Korruption oder fehlende Daten. Manchmal heilt ein Neustart das; wiederholt sich der Log-Loop, hören Sie auf zu reparieren und resyncen Sie stattdessen — verschieben Sie das Datadir beiseite, starten Sie frisch, und Snap-Sync baut alles in ein bis zwei Tagen neu auf, meist schneller als jeder Reparaturversuch. Prävention steckt schon in der Unit: TimeoutStopSec=600 gibt Geth Zeit zum Flushen, und ein sauberes systemctl stop ist der einzige Weg, wie der Prozess je enden sollte.

Der OOM-Killer beendet Geth

journalctl -k | grep -i oom bestätigt den Verdacht. Geths --cache steht standardmäßig auf 4096 MB im Mainnet, und die reale Nutzung übersteigt während des Syncens den Wert; addieren Sie Lighthouse und das Betriebssystem, und eine 16-GB-Maschine läuft leer. Setzen Sie --cache 2048 auf kleinen Maschinen und halten Sie eine Swap-Datei als Puffer bereit — langsam schlägt getötet, weil ein getötetes Geth nichts flusht und den Korruptionsfall oben provoziert.

Eigenen Node betreiben — oder eine API nutzen?

Ein ehrlicher Vergleich, da Chaingateway die Alternative verkauft.

Der Node gewinnt, wenn Sie schweres, dauerhaftes rohes JSON-RPC brauchen: Archive-Abfragen, Tracing, Mempool-Beobachtung, oder maximale Privatsphäre und Zensurresistenz. Ein Node ist ein Fixkosten-Posten mit unbegrenzten Requests — beim niedrigen dreistelligen Euro-Betrag pro Monat aus dem Kostenabschnitt unterbietet er jedes abgerechnete RPC-Angebot, sobald Ihr Volumen hoch genug ist. Es ist auch der beste Weg, um zu verstehen, wie Ethereum tatsächlich funktioniert.

Die API gewinnt, wenn der Node nur Mittel zum Zweck wäre, was für die meisten Unternehmen Zahlungen bedeutet. Ein synchronisierter Node gibt Ihnen eth_sendRawTransaction und Event-Logs. Er gibt Ihnen keine Deposit-Adressen pro Kunde, keine Benachrichtigungen, wenn eine ERC-20-Zahlung eingeht, kein Key-Management oder Retry-Logik. Das ist Anwendungssoftware, die Sie obendrauf bauen und betreiben müssten, und das kostet meist mehr Stunden als der Node selbst.

Chaingateways Ethereum-API ist genau diese fehlende Schicht: Adressen erstellen und importieren (POST /api/v2/ethereum/addresses/import), ERC-20-Tokens senden (POST /api/v2/ethereum/transactions/erc20) und HMAC-signierte Webhooks für eingehende Deposits empfangen — fehlgeschlagene Zustellungen landen in einer abfragbaren Liste (GET /api/v2/ethereum/webhooks/notifications/failed) und können über den Retry-Endpoint erneut gesendet werden. Der Break-even ist Arithmetik: Serverkosten plus Ihre Bau- und Betriebsstunden gegen einen Plan auf /de/pricing/. Für Payment-Flows bleibt die API-Seite dieser Ungleichung bis weit über Hobby-Maßstab hinaus kleiner; für rohen RPC-Konsum gewinnt die Node-Seite früh. Starten Sie mit dem Quickstart und dem Webhook-Guide — der 7-tägige Test ohne KYC reicht, um einen Deposit-Flow Ende-zu-Ende zu testen (hier registrieren).

Betreiben Sie auch andere Chains? Sehen Sie sich die Anleitungen für BNB Smart Chain und TRON an.