Was ist die „Warp“-Synchronisation von Parity und warum ist sie schneller als Geth „fast“?

Eine Fortsetzung einer der klassischen Fragen auf dieser Seite:

Eine der Antworten auf diese Frage schlug vor, das Geth- --fastFlag zu verwenden, um die Blockdaten schnell zu synchronisieren.

Kommt jetzt paritymit einem --warpFlag, um die Synchronisierung in 10 Minuten zu aktivieren.

--warp        Enable syncing from the snapshot over the network. (default: false)

Wie funktioniert das --warpFlag und wie beschleunigt seine Verwendung die Synchronisation? Synchronisieren wir weniger Daten oder führen wir in gewisser Weise weniger Überprüfungen ihrer Integrität oder Quelle durch?

Warum jetzt Paritätswarp beim Synchronisieren von Snapshot 3306/3306 und Synchronisieren von Block Nr. 8030000, seine sehr langsame Synchronisierung mit dem letzten Block – höchster Block: 8719236 mit meiner Geschwindigkeit von 0,20 blk/s, braucht 40 Tage :( Wie zum letzten Block warpen? Ich lösche die Datenbank und starte die Parität neu, aber es warp immer auf 8030000 :(

Antworten (1)

Es ist schwierig, eine Antwort zu geben, ohne die Erklärung im Parity-Wiki erneut zu wiederholen ...

Der relevante Teil lautet wie folgt:

Diese Momentaufnahmen können verwendet werden, um schnell eine vollständige Kopie des Zustands eines bestimmten Blocks zu erhalten. Alle 30.000 Blöcke machen Knoten einen konsenskritischen Schnappschuss des Zustands dieses Blocks. Jeder Knoten kann diese Snapshots über das Netzwerk abrufen, was eine schnelle Synchronisierung ermöglicht.

Der Schnappschuss selbst besteht aus 3 Teilen:

  1. Ein Manifest , bei dem es sich im Grunde um Metadaten zum Snapshot handelt;
  2. Block Chunks , die rohe Blockdaten über Blöcke und ihre Transaktionsbelege enthalten;
  3. State Chunks , die Daten über den Zustand eines bestimmten Blocks enthalten.

Chunks sind derzeit auf eine Größe von 4 MB eingestellt.

Wie beschleunigt dies also tatsächlich die Synchronisierung? Was diese Wiki-Seite nicht sagt, ist, dass wir zunächst nur die Schnappschüsse synchronisieren. Für jeden Block in Intervallen von 30.000 erhalten wir also einen Satz von 4-MB-Blöcken. Dann synchronisieren wir im Hintergrund weiterhin die verbleibenden Blockdaten.

Dies entspricht der --fastSynchronisierung von Geth, die zuerst die Blockheader synchronisiert und dann im Hintergrund den Rest der Daten synchronisiert. Es ist nur so, dass --warpbeim ersten Durchgang noch weniger Daten synchronisiert werden und später die größeren Lücken gefüllt werden.

Bearbeiten:

Siehe auch den entsprechenden offiziellen Ethcore- Blogbeitrag , insbesondere den Abschnitt mit dem Titel Core Strength.