base/node: Einen Base-Node mit Docker betreiben
Alles, was Sie zum Betrieb Ihres eigenen Basisknotens benötigen. Dieses Repository enthält einen Docker-Build zum Ausführen eines Basisknotens mit base-reth-node und base-consensus.
Auf einen Blick
- Was ist das?
- Das Repository base/node liefert einen Docker-Build für einen Base-Node auf dem OP Stack, mit base-reth-node als Ausführungsclient und base-consensus für den Konsens. Wir gehen Hardware, Konfiguration und optionale Modi durch.
- Für wen ist es gedacht?
- base/node richtet sich an Betreiber, die einen eigenen Base-Node unter Docker fahren und bereits einen Ethereum-L1-RPC samt Beacon-Endpunkt besitzen. Wer ohne L1-Zugang oder mit wenig NVMe-Speicher arbeitet, sollte sich erst an Testnet unter .env.sepolia wagen.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Nein. Die Eigentümer haben das Repository auf GitHub archiviert; es ist schreibgeschützt und erhält keine Änderungen mehr.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Shell, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
base/node: ein Docker-Build mit base-reth-node und base-consensus
Base ist laut README ein sicheres, kostengünstiges und entwicklerfreundliches Ethereum-L2, das auf dem OP Stack von Optimism aufbaut. Das Repository base/node enthält genau das, was zum Betrieb eines eigenen Nodes nötig ist, und zwar als Docker-Build mit zwei Clients: base-reth-node für die Ausführung und base-consensus für den Konsens. Die Shell-basierte Codebasis hat mit über 68.000 Sternen ein bemerkenswertes Gewicht, bei 3.258 Forks und nur 17 offenen Issues.
Das Repository löst ein klares Problem: Den Weg von der L2-Teilnahme über Drittinfrastruktur hin zum eigenen Knoten. Statt Binärpakete oder komplizierte Build-Pipelines zu pflegen, setzt das Projekt auf Docker Compose, was den Betrieb auf eigenem Server oder Cloud-Instanz gleich gestaltet. Ein Quellcode-Build wird im README nicht beschrieben, die Docker-Route ist der dokumentierte Weg.
Support läuft über einen Discord-Kanal namens node-operators oder über GitHub-Issues. Der Haftungsausschluss verdient Beachtung: Die Node-Software wird wie besehen bereitgestellt, ohne Garantie, und es wird ausdrücklich keine Zusicherung zu Vermögensschutz oder Sicherheit gemacht. Diese Kombination aus etablierter Infrastruktur und klarem Vorbehalt prägt das ganze Projekt.
Schnellstart mit .env.mainnet und docker compose up --build
Der Schnellstart beginnt mit einer Voraussetzung, die leicht unterschätzt wird: Ein eigener Ethereum-L1-Vollknoten-RPC und ein Beacon-Endpunkt müssen bereits verfügbar sein. Ohne L1-Anbindung startet der Base-Node nicht, denn das L2 hängt für Datenverfügbarkeit am Layer 1. Wer nur einen öffentlichen RPC einträgt, riskiert eine instabile Synchronisation.
Die Netzwerkwahl erfolgt über Umgebungsdateien: Für das Mainnet dient .env.mainnet als Basis, für das Testnet .env.sepolia. Darin werden BASE_NODE_L1_ETH_RPC und BASE_NODE_L1_BEACON auf die eigenen Endpunkte gesetzt. Gestartet wird mit docker compose up --build für das Mainnet beziehungsweise mit vorangestelltem NETWORK_ENV=.env.sepolia für das Testnet.
Dieser Ablauf hält die Erstinstallation bewusst kurz. Die eigentliche betriebliche Arbeit verschiebt sich in die Konfiguration und in die Hardwareplanung, denn der Node ist nach dem Start nur so gut wie die L1-Endpunkte und der lokale Datenträger. Wer das Testnet zuerst probiert, kann die Latenz zwischen L1-Beacon und L2-Sync beobachten, bevor echte Fehler im Mainnet teuer werden.
Speicherformel und AWS i7i.12xlarge in der Produktion
Die Mindestanforderungen klingen moderat: eine moderne Mehrkern-CPU, 32 GB RAM mit 64 GB empfohlen, eine NVMe-SSD sowie Docker und Docker Compose. Der eigentliche Engpass ist der Speicherplatz. Das README gibt eine Formel vor: das Doppelte der aktuellen Kettengröße plus die Snapshot-Größe plus 20 Prozent Puffer, um künftiges Wachstum abzufedern. Aktuelle Zahlen liefert die verlinkte Statistik unter base.org/stats und eine separate Website zur Snapshot-Größe.
Für die Produktion legt das README eine konkrete Referenzhardware offen: eine AWS-Instanz i7i.12xlarge mit RAID 0 über alle lokalen NVMe-Laufwerke unter /dev/nvme* und einem ext4-Dateisystem, empfohlen für den Reth-Archivknoten. Damit wird die Erwartungshaltung klar, dass ein Archivknoten auf Base kein Hobby-Nebenprodukt auf alter Hardware ist.
Auffällig ist, was das README nicht spezifiziert: eine Hardwareempfehlung für einen Produktions-Konsensknoten fehlt. Wer also neben der Ausführung auch Konsens betreiben will, muss die Ressourcen selbst ermitteln und überwachen. Ein Blick auf die eigene IOPS-Last und das RAID-0-Risiko, das einer Plattenfehler mitsamt Resync mit sich bringt, gehört zur Planung.
BASE_NODE_L1_ETH_RPC, RETH_CHAIN und die Sequencer-URLs
Vier Einstellungen sind laut README verpflichtend: BASE_NODE_L1_ETH_RPC für den L1-RPC, BASE_NODE_L1_BEACON für den Beacon-Endpunkt, BASE_NODE_NETWORK und RETH_CHAIN. Für das Mainnet werden beide letzteren auf base gesetzt, für Sepolia auf base-sepolia. Die beiden Netzwerkvariablen decken Konsens- und Ausführungsseite getrennt ab, was Fehlerquellen offenlegt, wenn nur eine davon geändert wird.
Das README listet darüber hinaus Sequencer-URLs für beide Netzwerke, https://mainnet-sequencer.base.org und https://sepolia-sequencer.base.org, erläutert aber nicht, wie diese URLs im Node-Setup konkret verwendet werden. Der Verweis auf die vollständigen Konfigurationsoptionen führt in die Dateien .env.mainnet und .env.sepolia selbst, die das README nicht reproduziert. Vor einem Update sollte man also einen diff über diese Dateien laufen lassen, weil neue Variablen dort auftauchen können.
Diese Struktur hat Vor- und Nachteile. Sie hält die README kurz und zwingt den Betreiber zur Quelle, vermeidet aber veraltete Duplikate. Wer den Node automatisiert aufsetzt, versioniert besser eine eigene Kopie der Umgebungsdateien und prüft bei jedem Release-Update, welche Variablen dazugekommen sind.
Flashblocks mit RETH_FB_WEBSOCKET_URL auf localhost:8545
Drei optionale Funktionen erweitern den Grundbetrieb. Der Flashblocks-Modus wird durch Setzen von RETH_FB_WEBSOCKET_URL aktiviert: Ist die Variable gesetzt, läuft der Ausführungsclient im Flashblocks-Modus, sonst im Vanilla-Modus. In diesem Modus lassen sich ausstehende Blöcke über die Flashblocks-RPC abfragen, und das README zeigt dafür ein konkretes curl-Beispiel: ein POST mit der JSON-RPC-Methode eth_getBlockByNumber und den Parametern pending und false an http://localhost:8545.
Der Follow-Modus entsteht durch Setzen von BASE_NODE_SOURCE_L2_RPC, dessen Verhalten das README nicht weiter erklärt. Wer diese Variante erwägt, muss also die Details aus den .env-Dateien oder der Dokumentation ziehen. Das Pruning schließlich wird über RETH_PRUNING_ARGS gesteuert, ohne dass das README eine Syntax vorgibt.
Für Betreiber, die niedrigere Latenzen beim Lesen frischer Blöcke brauchen, ist der Flashblocks-Pfad der interessanteste Hebel, weil sich der Zustand vor Blockfinalisierung abfragen lässt. Die Prüfung mit dem curl-Aufruf gegen Port 8545 ist dabei der einfachste Rauchtest: Liefert der Endpoint einen ausstehenden Block, steht die Verbindung. Pruning und Follow-Modus betreffen dagegen Datenvolumen und Synchronisationsstrategie und verdienen genauere Beobachtung im Testnet.
Snapshots, Release v1.2.0 und der Haftungsausschluss
Snapshots sollen die Synchronisation beschleunigen, aber das README liefert keine direkte URL oder Prüfsumme. Der Verweis führt auf docs.base.org unter der Seite run-a-base-node mit einem Anker zu Snapshots. Dort finden sich Links und Wiederherstellungsanleitungen. Die Snapshot-Kadenz und -Größe bleiben im README offen und gehören zur speicherformelbasierten Kapazitätsplanung, denn die Formel rechnet die Snapshot-Größe ja explizit ein.
Die Release-Historie zeigt ein ruhiges Tempo: v1.2.0 erschien am 22. Juli 2026, davor v1.1.1 am 19. Juni und v1.1.0 am 12. Juni 2026. Der letzte Push liegt ebenfalls Ende Juli 2026, das Projekt ist aktiv, aber nicht chaotisch. Die Tabelle der unterstützten Netzwerke kennt nur Mainnet und Testnet, beide mit Häkchen.
Als Alternative zum eigenen Node bleibt der Zugriff über fremde RPC-Anbieter, die Base-Endpunkte anbieten. Der Unterschied ist grundsätzlich: Ein RPC-Anbieter spart Hardware und Wartung, ein eigener Node aus base/node liefert dagegen selbst verifizierte Daten, ohne Vertrauen in fremde Endpunkte, zum Preis von 32 bis 64 GB RAM und NVMe-Speicher nach der Formel. Wer nur gelegentlich Lesezugriffe braucht, fährt mit einem fremden Endpoint günstiger, wer Kontrollen, Indexierung oder hohe Abfragelasten hat, gewinnt mit dem eigenen Knoten.
Redaktionelles Fazit
base/node richtet sich an Betreiber, die einen eigenen Base-Node unter Docker fahren und bereits einen Ethereum-L1-RPC samt Beacon-Endpunkt besitzen. Wer ohne L1-Zugang oder mit wenig NVMe-Speicher arbeitet, sollte sich erst an Testnet unter .env.sepolia wagen. Vor dem Mainnet-Start lohnt ein Blick auf die Snapshot-Dokumentation von docs.base.org und die aktuelle Kettenstatistik, denn die Speicherformel hängt von laufenden Zahlen ab.
Community-Notizen