Monero Full Node im Jahr 2026 selbst betreiben: Der komplette Self-Hosting-Leitfaden

Jedes Mal, wenn du eine Monero-Wallet öffnest, die auf einen Remote-Node zeigt, stellst du im Stillen einem Fremden drei Fragen: „Ist dieser Blockchain-Stand korrekt?", „Wirst du meine IP-Adresse für dich behalten?" und „Wirst du online sein, wenn ich dich brauche?". Erstaunlich viele Anwender vertrauen 2026 noch immer dem Node, der standardmäßig in der GUI-Wallet hinterlegt ist – obwohl die Monero-Blockchain Ende 2025 / Anfang 2026 die 200-GB-Marke überschritten hat und ein moderner Desktop sie an einem Wochenende synchronisiert. Eine eigene monerod-Instanz zu betreiben ist das größte Privatsphäre-Upgrade, das man als Monero-Nutzer nach dem korrekten Umgang mit Schlüsseln vornehmen kann. Dieser Leitfaden geht jeden Schritt durch: Hardware-Auswahl, Installation von monerod auf Linux, macOS und Windows, der erste Sync, das Härten des RPC-Interfaces und – wenn du großzügig bist – den eigenen Knoten als öffentliches Relay anzubieten, damit Wallets wie die, die ihre Coins über MoneroSwapper tauschen, auf einen community-betriebenen Server statt auf einen zentralisierten zurückgreifen können.

Warum ein eigener Monero-Node 2026 wichtig ist

Eine Monero-Wallet benötigt von einem Node nur drei Dinge: die aktuelle Blockchain-Höhe, die Möglichkeit, Blöcke nach eingehenden Transaktionen zu scannen, und einen Weg, ausgehende Transaktionen zu broadcasten. Bei einem Remote-Node leaken alle drei Interaktionen Metadaten. Der Betreiber sieht, welche IP welche Blöcke abgefragt hat, weiß, dass du Monero nutzt, und kann Transaktions-Broadcasts mit der sendenden IP korrelieren. Die Privatsphäre-Garantien auf Protokollebene (Ring Signatures, Stealth Addresses, RingCT, Bulletproofs, Dandelion++) verschleiern On-Chain-Daten hervorragend – aber sie können nicht verbergen, in welcher Beziehung du zu der Node-Software stehst, die du abfragst.

• Privatsphäre auf der Netzwerkschicht: Ein selbst gehosteter Node bedeutet, dass deine Wallet mit localhost spricht. Nichts über dein Scan-Muster, deine Restore-Height oder deine Adress-Abonnements verlässt deinen Rechner.
• Zensurresistenz: Remote-Nodes können sich weigern, deine Transaktionen weiterzuleiten, oder dir veraltete Chain-Daten liefern. Dein eigener monerod lügt dich nicht an.
• Trustless Verification: Nur ein Node, den du kontrollierst, verifiziert unabhängig, dass die Coins, die du empfängst, tatsächlich auf der kanonischen Chain existieren und nicht von einem manipulierten Remote-Server erfunden wurden.
• Verfügbarkeit: Öffentliche Remote-Nodes gehen offline, ändern Ports oder rate-limiten Clients. Dein monerod ist so lange erreichbar wie deine Hardware.
• Beitrag zur Netzwerkstärke: Jeder Full Node stärkt das Peer-to-Peer-Netz von Monero – selbst einer, der nur deinen eigenen Wallets dient, entlastet die Freiwilligen, die öffentliche Knoten betreiben.

Kurz gesagt: Ein Remote-Node löst ein Bequemlichkeitsproblem und schafft dafür ein Metadaten-Problem. monerod selbst zu betreiben löst beides – und 2026 kostet die nötige Hardware weniger als eine einzelne Hardware-Wallet.

Hardware-Anforderungen für einen Monero Full Node

Monero ist im Vergleich zu anderen Layer-1-Knoten ungewöhnlich genügsam. Die Blockchain ist groß, aber nicht riesig; der Sync ist überwiegend I/O-lastig statt CPU-lastig; und der Daemon wurde über die 0.18.x-Releases stetig optimiert. Die folgende Tabelle zeigt, was du wirklich brauchst, und was den Betrieb angenehm macht.

Eine SSD ist der größte Beschleuniger. Die LMDB-Datenbank von Monero führt beim Sync Millionen zufälliger Lesezugriffe aus; eine klassische Festplatte streckt einen eintägigen SSD-Sync auf eine Woche. Eine 500-GB-Consumer-SSD (Samsung 870 EVO, Crucial MX500, WD Blue) reicht mehr als aus und kostet derzeit weniger als die Gebühren eines einzigen fehlgeschlagenen Swaps. Ein Raspberry Pi 4 mit externer SSD funktioniert ebenfalls, allerdings sollte man dann mit 4–7 Tagen Sync-Zeit rechnen.

Was ist mit Cuprate?

2026 hat Cuprate – die Rust-Neuimplementierung von monerod – einen nutzbaren Pre-Release-Status erreicht. Es ist aber noch kein Drop-in-Ersatz, und die meisten Nutzer sollten beim offiziellen C++-monerod von getmonero.org bleiben. Cuprate ist wichtig für die Diversität (eine zweite unabhängige Implementierung reduziert das Monokultur-Risiko auf Protokollebene) und lohnt sich zu beobachten – aber dieser Leitfaden konzentriert sich auf monerod als die geprüfte, produktionsreife Referenz.

monerod Schritt für Schritt installieren

Der Ablauf ist plattformunabhängig: offizielles Archiv herunterladen, GPG-Signatur gegen eine von binaryFates wohlbekanntem Schlüssel signierte Hash-Datei verifizieren, entpacken, Konfigurationsdatei anlegen, starten, Sync beobachten. Niemals ein Binary aus einem zufälligen GitHub-Fork, Mirror oder „Easy Installer" verwenden. Die einzige kanonische Quelle ist getmonero.org/downloads. In Deutschland legt das BSI in seinen Veröffentlichungen zur Software-Lieferkette nahe, jede Binary explizit zu verifizieren – bei kryptobezogenen Daemons gilt das doppelt.

1. Lade das offizielle Binary für deine Plattform von getmonero.org/downloads herunter. Wähle das statische Linux-x64-Build, das macOS-Universal-Build oder das Windows-64-Bit-Installer/ZIP. Lade von derselben Seite zusätzlich die hashes.txt.
2. Verifiziere die GPG-Signatur. Die hashes.txt ist mit binaryFates Schlüssel signiert (Fingerprint auf der Monero-Website und KeyOxide veröffentlicht). Importiere den Schlüssel, führe gpg --verify hashes.txt aus und bestätige die Zeile „Good signature". Berechne anschließend shasum -a 256 (macOS/Linux) bzw. certutil -hashfile (Windows) über das Archiv und vergleiche mit der entsprechenden Zeile in hashes.txt. Stimmen die Hashes nicht überein, stop – das Archiv wurde manipuliert.
3. Entpacke das Archiv an einen festen Ort, z. B. /opt/monero auf Linux, /Applications/monero auf macOS oder C:\Monero auf Windows. Der Ordner enthält monerod, monero-wallet-cli und weitere Tools als reine Binaries – kein Installer fasst Systemdateien an.
4. Lege ein Datenverzeichnis getrennt von den Binaries an, z. B. ~/.bitmonero auf Linux/macOS (Default) oder D:\monero-data auf Windows. Hier liegt die Blockchain-Datenbank.
5. Erstelle eine monerod.conf im Datenverzeichnis. Eine vernünftige Minimalkonfiguration: data-dir=/var/lib/monero, log-file=/var/log/monero/monerod.log, log-level=0, no-igd=1, hide-my-port=1, rpc-bind-ip=127.0.0.1, rpc-bind-port=18081, restricted-rpc=1, confirm-external-bind=0. RPC-Hardening folgt weiter unten im Detail.
6. Starte monerod zum ersten Mal. Linux: ./monerod --config-file ~/.bitmonero/monerod.conf --detach. macOS: identisch im Terminal. Windows: monerod.exe in einer Eingabeaufforderung starten oder per NSSM als Dienst einbinden.
7. Als Dienst einrichten, damit der Node nach einem Neustart automatisch hochfährt. Linux: systemd-Unit unter /etc/systemd/system/monerod.service anlegen mit ExecStart=/opt/monero/monerod --config-file /etc/monerod.conf --non-interactive, dann systemctl enable --now monerod. macOS: launchd-Plist in ~/Library/LaunchAgents/. Windows: NSSM (nssm install monerod).
8. Überwache den Sync. Per ./monerod status aus einer zweiten Shell oder per curl gegen http://127.0.0.1:18081/get_info. target_height sollte sich an height annähern und synchronized auf true umschalten.
9. Härte den RPC-Port. Prüfe mit ss -tlnp | grep 18081 (Linux) bzw. netstat -an | findstr 18081 (Windows), dass der Daemon auf 127.0.0.1 lauscht – nicht auf 0.0.0.0. Lauscht er auf 0.0.0.0 ohne Authentifizierung, betreibst du versehentlich einen offenen Node – Konfiguration sofort korrigieren.
10. Richte deine Wallet auf 127.0.0.1:18081 und prüfe, dass eine neue Wallet Blöcke scannen kann. Funktioniert das, ist das lokale Setup fertig.

Den unrestricted RPC-Port (Default 18081) niemals an eine öffentliche IP binden. Das Flag --restricted-rpc existiert aus gutem Grund: Die volle RPC bietet Methoden, die missbraucht werden können (Transaktionssuche, Mempool-Abfragen, erzwungenes Wallet-Rescan). Öffentliche Knoten müssen --rpc-restricted-bind-port=18089 --rpc-bind-ip=127.0.0.1 nutzen und ausschließlich 18089 ins Internet exponieren.

Der initiale Blockchain-Sync: Was dich erwartet

Der Initial Block Download (IBD) ist der längste und empfindlichste Teil des Node-Betriebs. Auf einem modernen Desktop mit SSD und 100-Mbit-Anschluss rechne mit 12–36 Stunden. Auf einem Pi 4 mit USB-3-SSD eher mit 4–7 Tagen. Auf jeder Magnetplatte: irgendwann aufgeben und eine SSD kaufen.

Der Vorgang läuft in Phasen. Zunächst verbindet sich monerod mit Seed-Nodes und lernt seine Peer-Liste. Dann lädt er Blöcke in Batches herunter, schreibt sie in die LMDB und verifiziert dabei Ring Signatures, RingCT-Beweise und Bulletproofs. Die CPU-Last steigt bei der Verifikation jüngerer Blöcke (die schwerere Bulletproofs+ enthalten), während ältere Legacy-Blöcke vor allem I/O-lastig sind.

Häufige Sync-Probleme und Lösungen:

• Sync bleibt bei einer bestimmten Höhe stehen: meist ein korrumpierter Block in der LMDB. monerod stoppen, dann entweder monerod --reorg-notify nutzen oder schlicht den Ordner lmdb/ löschen und neu starten – du lädst die Chain neu herunter, aber das ist der sauberste Weg.
• „Failed to verify block"-Fehler: fast immer ein Festplattenproblem. SMART-Status der SSD prüfen. Billige USB-Gehäuse verlieren manchmal stillschweigend Schreibvorgänge.
• Sehr langsame Peer-Discovery: explizite Peers ergänzen, z. B. --add-peer node.moneroworld.com:18080 oder ähnliche aus der Community-Peer-Liste.
• Hoher Speicherverbrauch gegen Ende des Sync: db-sync-mode=safe:sync statt des Defaults fast-async setzen – etwas langsamer, aber flacheres Speicherprofil.
• Wallet zeigt falschen Saldo während des Sync: der Node hat noch nicht aufgeholt. Auf synchronized: true in get_info warten, bevor du Salden vertraust.

Eine wichtige Anmerkung für 2026: Mit der FCMP++-Vorbereitung im Testnet und laufender Protokollforschung sind häufigere Point-Releases der 0.18.x-Reihe zu erwarten als in den Vorjahren. Setze dir einen monatlichen Erinnerungstermin, prüfe Updates und lies stets die Release Notes – manche Updates enthalten konsensrelevante Änderungen, die vor einem Hard Fork installiert sein müssen.

Pruned Node vs. Full Node: Abwägungen

monerod unterstützt zwei Modi: einen Full Node, der die komplette Blockchain auf der Platte hält, und einen Pruned Node, der etwa zwei Drittel der Daten verwirft (konkret den größten Teil der Ring-Signature-Daten unterhalb einer bestimmten Tiefe, die für die Validierung neuer Blöcke nicht mehr benötigt werden).

Ein Pruned Node belegt ca. 60 GB statt ~200 GB, ist schneller synchronisiert und stellt für die Wallet dieselbe RPC zur Verfügung. Der Preis: Er kann anderen Peers keine alten Transaktionsdaten ausliefern – er verlässt sich darauf, dass es im Netz genug Full Nodes gibt. Aus Sicht von Privatsphäre und Validierung ist ein Pruned Node für dich als Wallet-Betreiber genauso gut. Aus Sicht der Netzgesundheit ist ein Full Node großzügiger.

Zum Aktivieren ergänze prune-blockchain=1 in der monerod.conf vor dem ersten Sync. Eine bestehende volle DB lässt sich nicht sauber prunen, ohne neu zu synchronisieren. Hast du reichlich Speicher, betreibe einen Full Node – dein Knoten hilft anderen Pruned-Nodes beim Aufholen. Ist Speicher knapp (Raspberry Pi, kleiner VPS), prune. Beide Optionen halten deine Wallet gleich privat.

Deine Wallet mit dem eigenen Node verbinden

Sobald der Daemon synchronized: true meldet, verbinde deine Wallet damit. In der offiziellen Monero-GUI: Einstellungen → Node → „Lokalen Node verwenden" wählen oder 127.0.0.1:18081 als Remote-Daemon mit leeren Zugangsdaten eintragen. In Feather Wallet: Settings → Node → „Custom" → 127.0.0.1:18081. In monero-wallet-cli: mit --daemon-address 127.0.0.1:18081 starten.

Für Mobile-Wallets wie Cake oder Monerujo gibt es zwei Wege: monerod auf einem Heimserver betreiben und vom Handy aus per Tailscale/WireGuard zugreifen (empfohlen), oder die restricted RPC über Tor als Hidden Service auf einem separaten Port veröffentlichen. Der Tor-Weg wahrt die Privatsphäre – das Handy erreicht den Node ausschließlich per .onion, niemals über Clearnet – erfordert aber etwas mehr Setup. Die Monero-Dokumentation enthält die genauen tor-service- und HiddenServiceDir-Anweisungen.

Wenn du Coins über MoneroSwapper tauschst, dient derselbe selbst gehostete Node als Verifikationsschicht für eingehende XMR: Nach Abschluss des Swaps bestätigt dein lokaler monerod den Eingang in deiner Wallet unabhängig, ohne einen Drittknoten danach fragen zu müssen, ob die Mittel echt sind. Genau darum geht es – End-to-End deiner eigenen Infrastruktur vertrauen.

Typische Fallen und Security-Hardening

Node-Betreiber laufen meist in eine von drei Fallen: offene RPC, veraltete Software oder ein dubioses „Easy Node"-Docker-Image. Gehen wir sie der Reihe nach durch.

Offene RPC ist der schlimmste Fehler

Setzt du rpc-bind-ip=0.0.0.0 ohne restricted-rpc=1 und --rpc-restricted-bind-port, betreibst du einen nicht authentifizierten öffentlichen Daemon mit Zugriff auf administrative RPC-Methoden. Jeder im Internet kann ihn scannen, deinen Mempool abfragen oder teure Operationen auslösen, die deinen Server lahmlegen. Nutze auf dem öffentlich erreichbaren Port immer restricted RPC; binde unrestricted RPC ausschließlich an 127.0.0.1. Auch das BSI weist in seinen IT-Grundschutz-Bausteinen darauf hin, administrative Schnittstellen niemals ohne Authentifizierung exponiert zu lassen – dieser Grundsatz gilt für Krypto-Daemons mindestens so streng.

Veraltete Daemons werden gebannt

Monero macht alle 6–12 Monate einen Hard Fork, und alte monerod-Versionen werden nach der Upgrade-Höhe vom Netz zwangsgetrennt. Abonniere die Monero-Release-Ankündigungen, behalte /r/Monero im Auge und aktualisiere vor dem nächsten Fork. Die 0.18.x-Reihe hat üblicherweise 2–4 Point-Releases pro Jahr – ein schnelles git pull oder Binary-Tausch, Dienst neu starten, fertig.

Drittanbieter-Node-Images meiden

„Monero in einem Klick"-Docker-Images und inoffizielle Installer sind ein regelmäßiger Vektor für bösartige Patches. Die Manipulationen sind oft subtil: ein modifizierter `monerod`, der IPs an einen Logging-Endpunkt leakt, oder eine Wallet, die mit einem geleakten Schlüssel signiert. Verwende ausschließlich Binaries von getmonero.org oder den Monero-GitHub-Releases – beide von binaryFate signiert.

Dateisystem und Backups

Die LMDB-Datenbank ist selbstheilend und braucht keine Backups – du kannst jederzeit neu synchronisieren. Was du sichern musst: deine monerod.conf und alle Wallet-Dateien, die du neben dem Node liegen hast. Wallet-Dateien (.keys) sind winzig und sollten verschlüsselt at-Rest gespeichert werden.

Regulatorischer Rahmen in Deutschland

Privates Betreiben eines Monero-Knotens ist in Deutschland keine erlaubnispflichtige Tätigkeit. Die BaFin reguliert das Erbringen von Finanzdienstleistungen mit Kryptowerten – etwa Kryptoverwahrung oder Krypto-Handelsplattformen – sie reguliert nicht das Validieren eines öffentlichen Blockchain-Protokolls auf der eigenen Hardware. Solange du keinen Tausch- oder Verwahrservice anbietest, sondern lediglich monerod laufen lässt, erbringst du keine BaFin-pflichtige Dienstleistung. Auch MiCA, das auf EU-Ebene ab 2024/2025 vollständig wirksam wurde, erfasst CASPs (Crypto-Asset Service Providers) – nicht private Validatoren oder Node-Betreiber.

Steuerlich behandelt das Bundeszentralamt für Steuern (BZSt) Monero – wie andere Kryptowährungen – bei Privatpersonen als „sonstiges Wirtschaftsgut" nach § 23 EStG. Der Betrieb eines Nodes löst für sich genommen keinen Steuertatbestand aus; relevant sind Käufe, Verkäufe und Tauschvorgänge. Wer Coins länger als ein Jahr hält, kann nach geltender Rechtslage steuerfrei veräußern – mit Blick auf DAC8 und kommende Meldepflichten lohnt aber sorgfältige Dokumentation. Für gewerbliches Mining oder Staking gelten andere Regeln; für reines Node-Hosting nicht.

Public Node: Einen öffentlichen Knoten für die Community betreiben

Wenn du unbegrenzte Bandbreite und einen stabilen Heimserver oder VPS hast, ziehe in Erwägung, deinen Node für das gesamte Monero-Ökosystem zu öffnen. Öffentliche Knoten sind in Community-Verzeichnissen gelistet (monero.fail, xmrnodes) und werden von Wallets genutzt, die selbst keinen monerod laufen lassen – also genau die Wallets, die ohne Freiwillige gar keine privatsphäre-respektierende Option hätten.

So hostest du öffentlich:

• Port 18080 (P2P) in Firewall und Router für eingehende Verbindungen öffnen. Das ist unauthentifizierter Peer-to-Peer-Verkehr und kann gefahrlos exponiert werden.
• Restricted RPC an ein öffentliches Interface auf einem separaten Port binden: rpc-restricted-bind-ip=0.0.0.0, rpc-restricted-bind-port=18089, dazu public-node=1.
• rpc-bind-ip=127.0.0.1 für den unrestricted Port beibehalten – 18081 NICHT öffentlich exponieren.
• confirm-external-bind=1 erst setzen, nachdem du verifiziert hast, dass der restricted Port aktiv ist.
• Optional eine .onion-Adresse veröffentlichen: Tor laufen lassen und eine HiddenService-Stanza auf 127.0.0.1:18089 zeigen lassen.
• Deinen Node bei monero.fail per Pull Request im GitHub-Repo eintragen oder bei xmrnodes selbst listen.

Ein bescheidener Public Node bedient täglich Dutzende bis Hunderte Wallet-Clients. Die meisten Betreiber berichten von weniger als 1 Mbit/s im Steady State – problemlos in jedem ordentlichen Heimanschluss unterzubringen.

FAQ

Brauche ich wirklich einen eigenen Full Node, oder reicht ein Remote-Node?

Für gelegentliche Nutzung kleiner Beträge ist ein Remote-Node vertretbar – Monero schützt On-Chain-Privatsphäre weiterhin. Für jede privatsphäresensible Nutzung, Geschäftsbestände oder regelmäßige hochwertige Swaps ist ein selbst gehosteter Node die einzige Möglichkeit, eine IP-zu-Transaktions-Korrelation gegenüber dem Remote-Betreiber zu vermeiden. Die Hardware-Hürde ist 2026 trivial.

Wie lange dauert der initiale Sync 2026?

Auf einem Desktop mit SSD und 100-Mbit-Anschluss 12–36 Stunden. Auf einem Raspberry Pi 4 mit USB-3-SSD 4–7 Tage. Auf einer Magnetplatte Tage bis Wochen. Die größte Variable ist Disk-I/O, nicht CPU oder Bandbreite.

Darf ich vorübergehend einen Remote-Node nutzen, während meiner synchronisiert?

Ja. Die meisten Wallets erlauben einen Node-Wechsel im laufenden Betrieb. Nutze während der Wartezeit einen Tor-Hidden-Remote (.onion-Adressen in xmrnodes.org) und wechsle auf 127.0.0.1, sobald dein lokaler monerod aufgeholt hat.

Ist ein Pruned Node weniger privat als ein Full Node?

Nein. Pruning entfernt nur Daten, die zum Ausliefern älterer Blöcke an andere Peers nötig sind. Aus Sicht der Wallet validiert ein Pruned Node neue Transaktionen und broadcastet deine Sends mit identischen Privatsphäre-Eigenschaften wie ein Full Node.

Welche Ports muss ich öffnen?

Für einen Wallet-Only-Node keine eingehenden Ports. Ausgehend reicht 18080 (P2P). Für einen Public Node eingehend 18080 (P2P) und eingehend 18089 (restricted RPC) in Firewall und Router öffnen. 18081 (unrestricted RPC) niemals ins Internet exponieren.

Macht mich ein Node gegenüber meinem ISP deanonym?

Dein ISP sieht, dass du auf Port 18080 mit anderen Monero-Nodes sprichst. Wer auch das verbergen will, betreibt monerod über Tor mit --tx-proxy tor,127.0.0.1:9050 und --anonymous-inbound. Performance leidet leicht, dafür ist die Netzschicht-Privatsphäre deutlich stärker.

Wie passt mein Node zu Diensten wie MoneroSwapper?

Bei einem nicht-verwahrenden Swap-Aggregator wie MoneroSwapper sendet der Swap-Provider XMR an eine Adresse, die du kontrollierst. Dein selbst gehosteter Node bestätigt den Eingang unabhängig, ohne Drittpartei für den Chain-Status. Die Kombination – nicht-verwahrender Swap plus eigener Node – eliminiert zwei zentrale Vertrauensannahmen in einem Workflow. Siehe unseren anonymen Swap-Guide für den vollständigen Ablauf.

Sollte ich mir Sorgen machen, dass FCMP++ meinen Node bricht?

Nein. FCMP++ wird mit einem zukünftigen Monero-Hard-Fork auf einer geplanten Blockhöhe aktiv. Solange du monerod vor dieser Höhe aktualisierst – üblicherweise gibt es ein 2–3-monatiges Ankündigungsfenster – aktiviert dein Node die neuen Regeln automatisch. Das Update auszulassen ist der einzige Weg, etwas zu beschädigen.

Fazit

Einen Monero Full Node im Jahr 2026 zu betreiben ist nicht mehr das Wochenend-Projekt aus 2019. Eine saubere Linux-Installation kostet eine Stunde Aufmerksamkeit plus einen Tag Hintergrund-Sync; auf Windows oder macOS ist es ähnlich. Der Privatsphäre-Gewinn ist dauerhaft: Jede Wallet, die du je auf dieser Maschine betreibst, spricht mit localhost; jede Transaktion, die du je sendest, wird von deinem eigenen Daemon angekündigt; jeder Saldo, den du prüfst, wird unabhängig gegen die Chain verifiziert, der du vertraust. Wer bereits eine Monero-Hardware-Wallet eingerichtet hat, betrachtet einen Self-Hosted Node als logischen nächsten Schritt zum Eigentum am eigenen Privatsphäre-Stack. Wer regelmäßig andere Coins über MoneroSwapper in XMR tauscht, ergänzt damit das fehlende Puzzlestück, das aus einem privaten Swap einen vollständig souveränen macht. Die Monero-Community lebt von genau diesen kleinen Akten der Selbstständigkeit – und unbekannte Begriffe unterwegs im Glossar nachzuschlagen ist der Weg, den jeder Node-Betreiber irgendwann gegangen ist.