Parität: Vermeiden Sie experimentelles `--light`, aber speichern Sie minimale Blockchain

Die besten Optimierungen, die ich anbieten kann, sind:

[parity]
light = false

[network]
warp = true

[footprint]
tracing = "off"
fat_db = "off"
pruning = "fast"
pruning_history = 8
pruning_memory = 32
db_compaction = "ssd"

[snapshots]
disable_periodic = true

Dies deaktiviert den Lichtmodus und aktiviert Warp-Sync. Warp-Sync verifiziert nur PoW von alten Blöcken und berechnet nicht alle historischen Zustände vollständig, während sie sie abrufen. Es speichert jedoch alle Blöcke auf der Festplatte.

Transaktionsverfolgung und Fat DB sollten deaktiviert werden, da dies die Datenbank aufbläht. Die DB-Komprimierung sollte auf ssd eingestellt sein , Sie laufen auf SSD, nicht wahr? Versuchen Sie andernfalls hdd .

Das Pruning sollte auf schnell eingestellt werden, um historische Zustände zu verwerfen, dies reduziert die Datenbankgröße erheblich um etwa -90 %. Die minimal mögliche Beschneidungshistorie ist 8. Eine niedrigere Einstellung würde keinen Sinn machen, da dies die Gefahr erhöht, in Kettenreorganisationen gefangen zu werden. Bei Blockzeiten von 15 Sekunden sind Reorgs von 8 und weniger Blöcken keine Seltenheit. Der Pruning-Speicher kann weiter reduziert werden, wenn Sie möchten, aber er behält immer mindestens 8 Zustände bei.

Es gibt eine weitere Option, die den Speicherbedarf erheblich reduziert, da nicht der gesamte Blockverlauf gespeichert wird. Ich verstecke diese Option hinter einem Spoiler-Zitat, um sicherzustellen, dass jeder, der unten darüber schwebt, sich bewusst ist, dass dies gefährlich ist und auf keinen Fall in der Produktion verwendet werden sollte .

--no-ancient-blocks

Das Ausführen von Clients in diesem Modus reduziert Ihren Platzbedarf erheblich um mehrere GB, ermöglicht jedoch böswilligen Akteuren im Netzwerk, Ihren Client dazu zu bringen, eine manipulierte Kette zu synchronisieren. Verwenden Sie es nicht, es sei denn, Sie verstehen die Auswirkungen . Der Laufmodus --lightist sicherer als dieser. :)