Was ist der Parity-Light-Pruning-Modus?

Parity bietet vier verschiedene Pruning-Methoden: Archive, Basic, Fast und Light:

  --pruning METHOD         Configure pruning of the state/storage trie. METHOD
                           may be one of auto, archive, basic, fast, light:
                           archive - keep all state trie data. No pruning.
                           basic - reference count in disk DB. Slow but light.
                           fast - maintain journal overlay. Fast but 50MB used.
                           light - early merges with partial tracking. Fast
                           and light. Experimental!
                           auto - use the method most recently synced or
                           default to archive if none synced [default: auto].

Ich habe es gerade ausprobiert, archiveweil ich genug Platz und Zeit habe, um eine vollständige Synchronisierung durchzuführen. Es ist vergleichbar mit einer Geth-Kettengröße wie der folgenden:

 ~ $ du -hs .parity/
17G .parity/
 ~ $ du -hs .ethereum/
15G .ethereum/

Nun, ich sehe archive, es wird so ziemlich wie die Standardsynchronisierung in eth oder geth sein. Aber was ist basic, was ist light? Und ist fastdas gleiche Niveau wie geth --fast?

Was ist der Parity-Light-Pruning-Modus? Ist dies bereits als Light-Client zu betrachten?

Antworten (2)

Geth und Parity haben unterschiedliche Methoden, um die Ethereum-Blockchain in ihrem internen Format zu speichern. Ich habe viele Bänke gemacht, weil ich es so lange finde, nur eine Brieftasche zu benutzen.

Im Pruning-Modus werden die Blockdaten gespeichert. Beim Archivmodus werden alle Zustände gespeichert. So kennen Sie den Status in jedem Moment, ohne die gesamte Blockchain neu laden zu müssen. Bei Fast and Light gehen wir davon aus, dass wir nicht alle diese Informationen benötigen, sondern nur den aktuellen Zustand und wenige davor, also entfernen wir viele Zwischenzustände.

Auf geth speichert die Methode --fast einen Zustand der Blockchain bei Block B[-1500] und alle Zustände nach diesem Block (B[-1] ist der letzte Block, B[-2] ist der vorletzte Block . ..). So ist es möglich, beim Stand von 1500 letzten Blöcken zurückzuspulen. Mit einer vollständigen Blockchain können Sie dies für alle Blöcke tun.

In der Parität gibt es 4 Pruning-Modi oder JournalDB-Algorithmen :

  • Archiv (Archiv): Als Geth-Archiv bewahren wir alle Zustände auf
  • Fast (OverlayRecent): Als Get-Fast behalten wir alle vollständigen Zustände der B[-i] -Blöcke
  • Light (EarlyMerge): Wir behalten alle Zustände der B[-i] -Blöcke bei, aber differentiell (also kleiner als schneller, aber langsamerer Zugriff)
  • Basic (RefCounted): Wir behalten alle Zustände der B[-i] -Blöcke wie bei OverlayRecent, aber wir entfernen Zustände nach x Änderungen ... also haben wir nur die x-ten letzten Änderungen

Benchmarks durchgeführt auf i7 3720QM 16 GB RAM mit Geth 1.4.4 (Homestead mit 1,6 Mi-Blöcken)

_____________________________________________
| Option | Disk Used | Time | Disk Written  |
|--------|-----------|------|---------------|
| none   | 19.GB     | 5h00 | 1TB           |
| fast   | 3.7GB     | 1h00 | 100GB         |
---------------------------------------------

Benchmarks durchgeführt auf i7 3720QM 16GB RAM mit Geth 1.5.0 instabil (Homestead mit 1.6Mi Blöcken gefunden unter https://gitter.im/ethereum/go-ethereum?at=574d26c010f0fed86f49b32f )

__________________________________________________
| command     | Disk Used | Time | Disk Written  |
|-------------|-----------|------|---------------|
| geth        | 21GB      | 5h00 | 150GB         |
| geth --fast | 4.2GB     | 21m  | 35GB          |
| geth export | 1.5GB     | 10m  |               |
| geth import | 21GB      | 3h30 |               |
--------------------------------------------------

Benchmarks durchgeführt auf i7 3720QM 16 GB RAM mit Parität 1.2 (Homestead mit 1,6 Mi-Blöcken)

_____________________________________________
| Option | Disk Used | Time | Disk Written  |
|--------|-----------|------|---------------|
| archive| 19.GB     | 2h00 | 300GB         |
| fast   | 3.7GB     | 1h30 | 20GB          |
| light  | 2.5GB     | 2h00 | 130GB         |
---------------------------------------------

Hinweis: Wenn Sie einen Knoten mit einer Blockchain haben, können Sie die Kettendaten des Geth- Verzeichnisses ausgeben, um sie mit Ihren anderen Computern zu verwenden. Ich überprüfe es mit Linux, Windows und OS X.

Hinweis: Wenn Sie --cache mit 1024 verwenden, könnte es schneller sein. Aber es ist nicht signifikant auf meinem System. Dasselbe gilt für --jitvm

Hinweis: Die Ethereum-Blockchain hat den Endzustand nach Transaktionen gespeichert, aber es ist sicherer, die Transaktionen erneut abzuspielen, um sie zu überprüfen.

Was ist diese Abkürzung für „Go“? Ich nehme an, es ist "Gb"?
Tut mir leid, französischer Touch. Los ist GB
Ich bin neugierig, wie haben Sie die "Disk Written" gemessen?
Bitte aktualisieren Sie den Link zu github.com/paritytech/parity/blob/…
Update beendet. Danke

Mit jedem Block ändert sich der Status (Verträge, Speicher und Guthaben). Standardmäßig ( archive) behalten wir den vollen Zustand der Datenbank für jeden Block bei.

Mit verschiedenen Pruning-Algorithmen verwerfen wir Zustandsdaten für alte Blöcke und behalten nur die Teile bei, die benötigt werden. basic/fast/lightsind nur verschiedene Ansätze für dieses Problem mit unterschiedlichen Kompromissen.

geth --fastist die Implementierung von PV63 ( https://github.com/ethereum/wiki/wiki/Ethereum-Wire-Protocol ) – anstatt jeden vergangenen Block zu verarbeiten, laden wir ihn einfach von anderen Peers herunter, was zu einer viel schnelleren anfänglichen Synchronisierungszeit führt. Es hat nichts mit dem Beschneiden zu tun.

Light Client ( https://github.com/ethereum/wiki/wiki/Light-client-protocol ) ist auch eine andere Sache. Anstatt Daten über ganze Blockchain-Light-Clients zu verarbeiten (und aufzubewahren), verarbeiten sie nur Teile des Zustands, die für sie von Bedeutung sind.

Was ist der Parity-Light-Pruning-Modus?
AntwortenHierDatenschutz-Bestimmungen1y, 0v