Monero Pruned Node einrichten: 60 GB sparen in 2026

Im Mai 2026 ist die Monero-Blockchain auf rund 215 GB angewachsen — ein Wert, der seit dem November-2025-Hardfork mit FCMP++ und täglichen Transaktionszahlen jenseits der 60.000-Marke nochmals deutlich zugelegt hat. Wer einen Node auf einem 256-GB-Laptop, einem Raspberry Pi 5 mit günstigem NVMe-Hat oder einem volumenbegrenzten vServer betreibt, kann eine vollständige Archivsynchronisation nicht mehr nebenbei laufen lassen. Ein Pruned Node löst genau dieses Problem elegant: Er verwirft rund zwei Drittel der historischen Ring-Signaturdaten, behält aber jeden Block-Header, jeden Transaction-Output und damit Ihre Fähigkeit, die gesamte Kette lokal und vertrauensfrei zu verifizieren. Das Ergebnis ist ein vollständig souveräner Monero-Daemon mit nur noch 85–95 GB Speicherbedarf statt 215 GB, der weiterhin Wallets per RPC bedient, sich im Peer-to-Peer-Schwarm beteiligt und Ihre eigenen Transaktionen über Dandelion++ broadcastet, ohne Metadaten an einen fremden Remote-Daemon zu verraten. Diese Anleitung führt Schritt für Schritt durch die Einrichtung unter Linux, Windows, macOS und auf einem headless betriebenen Raspberry Pi — inklusive einer systemd-Unit, die Neustarts übersteht, der Firewall-Regeln zum Schutz des RPC-Ports und einer praktikablen Resync-Strategie für den Fall, dass die Datenbank irgendwann doch beschädigt wird. Egal, ob Sie diesen Artikel nach einem KYC-freien Swap über MoneroSwapper gefunden haben oder gerade Ihren ersten eigenständigen Node aufsetzen — das Ziel ist dasselbe: weniger Speicherverbrauch, keine eingebüßte Privatsphäre.

Warum ein Pruned Node statt eines Remote Nodes

Gerade auf knapper Hardware ist die Versuchung groß, ganz auf einen eigenen Node zu verzichten und die Wallet stattdessen an einen Community-Node wie node.moneroworld.com oder eine der im Monero-Forum gelisteten .onion-Adressen zu hängen. Technisch funktioniert das. Es übergibt dem Betreiber dieses Nodes aber gleichzeitig ein detailliertes Protokoll darüber, welche Transaktionen Ihre Wallet scannt, wann Sie online gehen und — über Traffic-Korrelation — eine plausible Schätzung, welche Outputs Ihnen gehören. Remote Nodes sehen weder Ihren View Key noch Ihren Spend Key, aber sie können sehr wohl einen Verhaltens-Fingerabdruck aufbauen. Mehrere wissenschaftliche Arbeiten aus den Jahren 2024 und 2025 haben praktikable Deanonymisierungs-Angriffe auf Wallets demonstriert, die ausschließlich auf fremde Infrastruktur setzen.

Ein Pruned Node schließt diese Lücke, ohne dass Sie irgendwo ein freies Terabyte auftreiben müssten. Aus Sicht der Wallet sind die Datenschutzeigenschaften identisch zu einem Full Node, weil die Pruning-Logik ausschließlich redundante Ring-Signaturdaten verwirft — niemals einen Output, niemals ein Key Image, niemals einen Block-Header. Ihre Wallet scannt die Kette gegen lokal vorhandene Daten, Ihre Transaktionen gelangen über Ihre eigenen Peer-Verbindungen in den Mempool, und der RPC-Traffic verlässt zu keinem Zeitpunkt das Loopback-Interface.

• Kein fremder Betreiber sieht Ihre Wallet-Aktivität: Jeder Refresh, jeder Output-Scan, jede Gebührenschätzung passiert auf Ihrer eigenen Maschine.
• Sie helfen weiterhin dem Netzwerk: Ein Pruned Node liefert anderen Peers etwa ein Achtel der historischen Blöcke aus — und gemeinsam erreicht der Schwarm so eine vollständige Abdeckung, ohne dass jeder Node archivierend laufen müsste.
• Vernünftige Hardware-Untergrenze: 4 GB RAM, eine moderne Quad-Core-ARM- oder x86-CPU und 120 GB freier SSD-Speicher reichen mindestens bis 2027 auch bei konservativen Wachstumsannahmen.
• Wiederherstellung ist unkompliziert: Wenn die Datenbank irgendwann korrupt ist, dauert ein Resync von Null auf einer normalen Glasfaserleitung etwa sechs bis zwölf Stunden — gegenüber 18 bis 30 Stunden für einen vollständigen Archiv-Node.

Pruned Node vs. Full Node: Was sich tatsächlich unterscheidet

Der Monero-Pruning-Algorithmus, eingeführt mit v0.15 und schrittweise bis v0.18.4 in 2025 weiterentwickelt, teilt die Kette in acht „Pruning Stripes" zu je 4096 Blöcken. Ein Pruned Node behält die vollständigen Daten für genau einen dieser Stripes (beim ersten Start pseudo-zufällig pro Peer ausgewählt) sowie die letzten 5500 Blöcke vollständig. Für alle übrigen Blöcke speichert er weiterhin Header, Key Images, Output-Beträge und Miner-Daten. Lediglich die Ring-Signaturdaten — und genau die machen den Großteil des Speicherverbrauchs aus — werden für die sieben nicht gehosteten Stripes verworfen.

Da jeder Node einen anderen Stripe vorhält, behält der Schwarm in Summe die komplette historische Blockchain, selbst wenn jeder einzelne Node prunt. Eine frisch synchronisierende Wallet, die Ring-Signaturdaten für einen alten Block benötigt, lädt diese transparent von dem Pruned Peer nach, der zufällig den passenden Stripe hostet — ohne dass der Nutzer eingreifen müsste. Aus Verifikationssicht geht nichts verloren: Jeder Pruned Node validiert beim ersten Sync die gesamte Kette vollständig und prüft anschließend jeden neuen Block, der eintrifft.

Der einzige nennenswerte Kompromiss eines Pruned Nodes besteht darin, dass er nicht als Datenquelle für einen Block-Explorer oder für akademische Chain-Analyse-Tools dienen kann, die vollständige historische Ring-Signaturen benötigen. Solange das nicht auf Ihrer Roadmap steht — und für die überwiegende Mehrheit der selbst gehosteten Nutzer ist es das nicht — ist Pruning auf knapper Hardware schlicht die bessere Wahl.

Hardware- und Systemanforderungen in 2026

Die Hardware-Untergrenze für einen komfortabel laufenden Pruned Node ist seit der FCMP++-Aktivierung moderat gestiegen, vor allem weil die Verifikation der Membership Proofs eingehender Blöcke rund 18 % mehr CPU-Last verursacht als die alte CLSAG-Verifikation vor dem Fork. Die gute Nachricht: Jedes Gerät, das nach etwa 2021 gebaut wurde, schafft das mühelos. Die schlechte: Ältere Single-Board-Computer — der ursprüngliche Raspberry Pi 4 mit 2 GB RAM, stromsparende Atom-basierte Mini-PCs — kommen an Tagen mit hohem Transaktionsaufkommen nicht mehr mit der Chain-Spitze mit.

Empfohlene Basis

• CPU: Quad-Core ARM Cortex-A76 (Raspberry Pi 5) oder beliebige moderne x86-64-CPU mit AES-NI. 32-Bit-Hosts grundsätzlich meiden; die LMDB-Performance bricht ein, und mehrere Wallet-RPCs verhalten sich unsauber.
• RAM: 4 GB Minimum, 8 GB komfortabel. Das LMDB-Memory-Mapping profitiert spürbar von Reserve; bei knappem RAM läuft monerod zwar weiter, aber die Blockverifikation wird messbar langsamer.
• Speicher: 120 GB frei auf SSD oder NVMe. Eine klassische Festplatte funktioniert technisch — verwandelt einen 6-Stunden-Sync aber zuverlässig in eine 36-Stunden-Tortur. Das wahllose Zugriffsmuster von LMDB ist Gift für Magnetplatten.
• Netzwerk: 25 Mbit/s symmetrisch reichen für den Dauerbetrieb völlig aus. Der Erst-Sync sättigt jede Leitung, die Sie haben; rechnen Sie mit 90–110 GB Download für den Pruned-Bootstrap.
• Betriebssystem: Ubuntu 24.04 LTS, Debian 12, Fedora 41, macOS 14+ oder Windows 11. Für NixOS existiert ein gepflegtes Service-Modul, Arch-Nutzer finden monero-bin im AUR.

Wenn Sie auf einem Raspberry Pi 5 bereitstellen, verwenden Sie das offizielle NVMe-Base von Pimoroni oder einen vergleichbaren M.2-Hat. Der microSD-Slot taugt für das Betriebssystem, sollte aber niemals die Blockchain beherbergen: SD-Karten verschleißen unter dem Schreibmuster innerhalb weniger Monate, und die I/O-Latenz lässt den Daemon dauerhaft hinter der Spitze hinterherwirken, selbst wenn er längst durchsynchronisiert ist.

Schritt-für-Schritt-Einrichtung unter Linux

Der Referenzpfad ist Linux: am leichtesten reproduzierbar, das verbreitetste produktive Zielsystem und am einfachsten unbeaufsichtigt am Laufen zu halten. Anpassungen für macOS und Windows folgen am Ende.

1. Dedizierten Nutzer und Verzeichnis anlegen. Als root useradd -r -s /bin/false monero ausführen, anschließend mkdir -p /var/lib/monero/blockchain /var/log/monero und chown -R monero:monero /var/lib/monero /var/log/monero. monerod unter einem dedizierten Service-Account zu betreiben statt unter Ihrem eigenen Login ist der größte Härtungsgewinn überhaupt — und kostet nichts.
2. Offizielles Binary herunterladen. Auf getmonero.org/downloads die Linux-64-Bit-Tarball-Datei laden — zum Redaktionsschluss ist v0.18.4.2 aktuell. Wichtig: Auch die zugehörige hashes.txt herunterladen, anschließend die SHA-256-Summe mit shasum -a 256 monero-linux-x64-v0.18.4.2.tar.bz2 abgleichen und die Signatur der hashes.txt mit gpg --verify hashes.txt gegen den PGP-Schlüssel von binaryFate prüfen. Diese Verifikation zu überspringen, ist der typische Einstiegsvektor für Schadsoftware.
3. Entpacken und installieren. Mit tar xjf monero-linux-x64-v0.18.4.2.tar.bz2 entpacken, dann die Binärdateien mit install -m 755 monero-x86_64-linux-gnu-v0.18.4.2/monero* /usr/local/bin/ in den PATH legen. Das installiert monerod, monero-wallet-cli und monero-wallet-rpc systemweit.
4. Konfigurationsdatei anlegen. Legen Sie /etc/monero/monerod.conf mit folgendem Mindestinhalt an: data-dir=/var/lib/monero/blockchain, log-file=/var/log/monero/monerod.log, log-level=0, prune-blockchain=1, sync-pruned-blocks=1, rpc-bind-ip=127.0.0.1, rpc-bind-port=18081, p2p-bind-port=18080, out-peers=32, in-peers=64, limit-rate-up=1048576, no-igd=1, enable-dns-blocklist=1. Das Flag sync-pruned-blocks=1 ist entscheidend: Ohne diese Option lädt monerod die komplette Kette herunter und prunt erst lokal — das verschwendet sowohl Bandbreite als auch Zeit.
5. systemd-Unit erstellen. Speichern Sie unter /etc/systemd/system/monerod.service eine Unit mit einem [Unit]-Block (Description=Monero Full Node (pruned), After=network-online.target), einem [Service]-Block (User=monero, Group=monero, Type=simple, ExecStart=/usr/local/bin/monerod --config-file=/etc/monero/monerod.conf --non-interactive, Restart=on-failure, RestartSec=30, MemoryHigh=3G, MemoryMax=5G) und einem [Install]-Block (WantedBy=multi-user.target).
6. Dienst aktivieren und starten. Mit systemctl daemon-reload einlesen, dann systemctl enable --now monerod. Den Fortschritt verfolgen Sie über journalctl -u monerod -f oder direkt im Logfile. Der Erst-Sync eines Pruned Nodes von Null dauert auf einer 1-Gbit/s-Glasfaserleitung typischerweise 6–10 Stunden; auf einem Pi 5 mit NVMe rechnen Sie mit 14–20 Stunden, weil hier die Verifikation zum Flaschenhals wird, nicht der Download.
7. Den P2P-Port öffnen — nicht den RPC-Port. Wenn Sie eingehende Peer-Verbindungen erlauben möchten (gut für das Netzwerk und für Ihre eigene Peer-Diversität), geben Sie TCP 18080 in Router oder Firewall frei. Den Port 18081 niemals ins öffentliche Internet stellen — das ist Ihr Wallet-RPC und gehört auf 127.0.0.1. Für entfernten Wallet-Zugriff verwenden Sie SSH-Tunnel oder Tor, niemals eine offene Portweiterleitung.
8. Wallet auf den lokalen Daemon zeigen lassen. In der offiziellen GUI-Wallet wählen Sie „Mit lokalem Node verbinden" und tragen 127.0.0.1:18081 ein. Auf der Kommandozeile übergeben Sie --daemon-address=127.0.0.1:18081 an monero-wallet-cli. In Feather Wallet finden Sie den Local-Node-Schalter unter Einstellungen → Node, und Cake Wallet auf dem Desktop unterstützt das über Einstellungen → Privatsphäre → Custom Node.

monerod niemals mit --restricted-rpc=0 auf einem öffentlichen Interface laufen lassen. Innerhalb von 48 Stunden nach der Indexierung durch Shodan wird ein ungeschützter RPC-Endpunkt von Mining-Pool-Scrapern, Wallet-Scanning-Bots und Schlimmerem geflutet. Die voreingestellte Localhost-Bindung hat ihren Grund.

Anpassungen für andere Plattformen

Raspberry Pi 5 mit NVMe

Die obige Konfiguration läuft auf einem Pi 5 praktisch unverändert. Zwei sinnvolle Anpassungen: In der monerod.conf db-sync-mode=fast:async:250000000 setzen, um die Schreibvervielfachung auf der NVMe zu reduzieren (der Standardwert ist sicherer, aber langsamer), und out-peers auf 16 sowie in-peers auf 32 absenken, falls Sie an einem Haushaltsanschluss hängen, der bei dauerhaftem Upload drosselt. Der Quad-Cortex-A76 des Pi 5 verifiziert Blöcke mit etwa 60 % der Geschwindigkeit eines modernen Desktops — der Erst-Sync dauert entsprechend länger, der Dauerbetrieb hält die Chain-Spitze problemlos.

macOS

Installation über Homebrew mit brew install monero; auf Apple Silicon liegt monerod anschließend unter /opt/homebrew/bin/monerod. Statt einer systemd-Unit verwenden Sie ein launchd-plist unter ~/Library/LaunchAgents/io.getmonero.monerod.plist. Der Konfigurationsinhalt bleibt derselbe — setzen Sie lediglich data-dir auf einen Pfad innerhalb Ihres Home-Verzeichnisses, etwa ~/Library/Application Support/monero. Beim ersten Start fragt die macOS-Firewall nach Erlaubnissen; bestätigen Sie eingehende Verbindungen auf dem P2P-Port, wenn Sie als Peer dienen möchten.

Windows 11

Den Windows-64-Bit-Installer von getmonero.org herunterladen und ausführen; das Standard-Datenverzeichnis liegt anschließend unter C:\ProgramData\bitmonero. Um monerod als Dienst statt als Vordergrundprozess laufen zu lassen, verwenden Sie NSSM (den Non-Sucking Service Manager) und zeigen damit auf monerod.exe mit dem gleichen --config-file-Argument. Windows Defender markiert monerod gelegentlich als „Coin Mining" — der Daemon mint nicht, aber die Heuristik ist unzuverlässig, daher das Binärverzeichnis als Ausnahme eintragen.

Wartung, Monitoring und Wiederherstellung

Ein korrekt konfigurierter Pruned Node ist nahezu Set-and-forget — drei Gewohnheiten verhindern aber rund 90 % aller Probleme.

Erstens: monatlich den Plattenplatz prüfen. Die Pruned Chain wächst beim aktuellen Transaktionsaufkommen um etwa 4–6 GB pro Monat, und eine vollgelaufene Partition kann LMDB auf hässliche Weise beschädigen. Richten Sie einen einfachen monit-Job oder einen systemd-Timer ein, der Sie benachrichtigt, sobald unter /var/lib/monero weniger als 15 GB frei sind.

Zweitens: monerod aktuell halten. Netzwerk-Upgrades (Hardforks) erfolgen etwa alle 6–9 Monate, und ein Node, der noch die alte Protokollversion fährt, akzeptiert ab Aktivierungsblock keine neuen Blöcke mehr. Der Monero-Release-Fahrplan wird auf der GitHub-Releases-Seite gepflegt und typischerweise vier bis sechs Wochen im Voraus auf r/Monero und der offiziellen Mailingliste angekündigt. Aktualisieren Sie mindestens zwei Wochen vor dem Fork-Block, um sich einen Puffer zu verschaffen.

Drittens: den Resync-Vorgang kennen. Wenn LMDB jemals „MDB_CORRUPTED" wirft oder der Daemon nach einem Stromausfall nicht mehr startet, ist die Wiederherstellung brachial, aber zuverlässig: Dienst stoppen, den Inhalt von /var/lib/monero/blockchain löschen, neu starten. Der Node synchronisiert in 6–12 Stunden komplett neu. Ein inkrementelles Reparaturwerkzeug existiert nicht, weil LMDB so etwas nicht vorsieht — der saubere Resync ist die kanonische Lösung und funktioniert seit 2017 verlässlich.

Ein Beispiel aus der Praxis: Ein Beitragender des MoneroSwapper-Backends betreibt eine Flotte von sieben Pruned Nodes in drei Ländern, um diversifizierte Daemon-Endpunkte für unseren anonymen Swap-Service bereitzustellen. Jeder Node ist identisch ausgestattet — Debian 12, die oben gezeigte systemd-Unit, NVMe-Speicher und Tor-Hidden-Service-Exposition des P2P-Ports. In 38 Monaten kumulativer Laufzeit über die gesamte Flotte beschränkten sich die manuellen Eingriffe auf drei Resyncs nach ungeplanten Rechenzentrums-Neustarts und den üblichen Binary-Wechsel am Fork-Tag. Das ist der Dauerzustand, den Sie von einem sauber gehärteten Setup erwarten dürfen.

FAQ

Kann ich einen bestehenden Full Node ohne Resync in einen Pruned Node umwandeln?

Ja. Stoppen Sie monerod, führen Sie monerod --prune-blockchain einmalig als Vordergrundbefehl aus (nicht als Dienst) und warten Sie ab. Der Pruning-Vorgang dauert je nach Plattengeschwindigkeit 30–90 Minuten und schreibt die Datenbank an Ort und Stelle neu. Wenn er abgeschlossen ist, starten Sie den Dienst mit der Pruned-Konfiguration neu. Kein Datenverlust, kein Resync — sichern Sie aber vorsichtshalber Ihre Wallet-Schlüssel, niemals die Blockchain selbst (die ist von jedem Peer reproduzierbar).

Funktioniert ein Pruned Node fürs Mining oder als Monero-Händler-Gateway?

Beim Solo- wie beim Pool-Mining ja — der Miner braucht nur die Chain-Spitze, keine historischen Ring-Signaturen. P2Pool funktioniert ebenfalls mit einem Pruned Node und ist seit 2023 sogar die empfohlene Kombination für selbstsouveränes Solo-Style-Mining. Für ein Händler-Gateway, das eingehende Zahlungen über monero-wallet-rpc verarbeitet, ist ein Pruned Node ebenso geeignet. Wirklich auf einen Archiv-Node angewiesen sind nur Block-Explorer und akademische Chain-Analyse-Werkzeuge.

Schadet ein Pruned Node der Privatsphäre meiner eigenen Wallet?

Nein. Wallet-Scans nutzen die Output-Index- und Key-Image-Datenbanken, die auf einem Pruned Node beide vollständig vorgehalten werden. Die verworfenen Daten — historische Ring-Signaturen — fließen weder in das Scannen mit dem View Key ein, noch in die Decoy-Auswahl, die Ihre Wallet beim Bau einer neuen Transaktion vornimmt. Aus Wallet-Sicht ist der lokale Daemon ununterscheidbar von einem Archiv-Node — und dramatisch privater als jeder Remote Node, gleich wie vertrauenswürdig sich dessen Betreiber gibt.

Wie verträgt sich Pruning mit FCMP++, seit Membership Proofs live sind?

Der Hardfork im November 2025 hat parallel zum bestehenden Ring-Signatur-Schema vollständige Chain-Membership-Beweise eingeführt, und Pruning behandelt beide konsistent: Jeder Proof und jedes Key Image, das für die Validierung gebraucht wird, bleibt erhalten — nur die redundanten Ring-Signatur-Bytes, die ältere Transaktionen noch tragen, werden verworfen. Post-FCMP++-Transaktionen sind etwas kleiner als ihre CLSAG-Vorgänger, daher fällt das Pruning-Verhältnis auf jüngeren Blöcken geringfügig günstiger aus als auf historischen.

Kann ich einen Pruned Node komplett über Tor betreiben?

Ja — das ist eine verbreitete Konfiguration für Nutzer, die sowohl Plattenplatz-Effizienz als auch Netzwerk-Privatsphäre wollen. Tragen Sie in die monerod.conf tx-proxy=tor,127.0.0.1:9050,32 und anonymous-inbound=IHREONIONADRESSE.onion,127.0.0.1:18083,16 ein und konfigurieren Sie den passenden Hidden Service in /etc/tor/torrc. Der Erst-Sync über Tor ist langsamer — 24–48 Stunden statt 6–12 — aber im Dauerbetrieb läuft alles stabil, und Sie gewinnen die Eigenschaft, dass weder Ihre Transaktionen noch Ihre Wallet-Scans jemals das Clearnet berühren.

Fazit

Ein Pruned Monero-Node liefert die vollständigen Privatsphäre- und Verifikationsgarantien eines Archiv-Nodes bei rund 40 % des Speicherbedarfs — das ist der Unterschied zwischen „passt nicht auf meinen Laptop" und „läuft bequem neben allem anderen". Das Setup ist ein Projekt für einen Abend auf jeder halbwegs aktuellen Maschine, der Wartungsaufwand beträgt grob eine Stunde alle sechs Monate, und das Ergebnis ist ein selbstsouveränes Fundament für jede Monero-Transaktion, die Sie künftig senden oder empfangen. Kombinieren Sie einen lokalen Pruned Node mit einem KYC-freien Swap-Dienst wie MoneroSwapper, und Sie haben den vollen Stack: Privatsphäre auf Protokollebene durch RingCT und FCMP++, Privatsphäre auf Netzwerkebene durch Ihren eigenen Daemon, und Privatsphäre auf der On-Ramp durch fixe Atomic Swaps, die Ihre Identität nicht zu sehen bekommen. Der eingesparte Plattenplatz ist Beifang — die operative Unabhängigkeit ist der eigentliche Gewinn.