Was ist die „schnelle“ Synchronisierung von Geth und warum ist sie schneller?

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

Wie funktioniert das Flag 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?

Bearbeiten:

Ab der Geth-Version 1.6.0 ist das --fastFlag geworden --syncmode=fast(aber --fastauch vorerst noch verwendbar).

Antworten (4)

Es gibt viele Details zu diesem PR auf github . Hier ist ein Zitat:

Anstatt die gesamte Blockchain Link für Link zu verarbeiten und alle Transaktionen wiederzugeben, die jemals in der Geschichte stattgefunden haben, lädt die schnelle Synchronisierung die Transaktionsbelege entlang der Blöcke herunter und ruft eine vollständige aktuelle Statusdatenbank ab.

Warum nicht --fast zum Standard machen?
Denn dann verliert man damit den Staat. Die Quittungen sagen nur, dass diese Aktionen stattgefunden haben, sie zeigen nicht wirklich die Ergebnisse der Hinrichtungen.
@ VoR0220 Der Zustandsverlust ist nicht das eigentliche Problem. Das Problem ist, dass wir uns, wenn wir es --fastfür einen beliebigen Zeitpunkt aktivieren würden, für Angriffe öffnen würden, bei denen ein Angreifer ein unendliches Zeitfenster hat, in dem er das Opfer angreifen kann, indem er einen gültigen Header akzeptiert, aber mit einem ungültigen Zustand. Dieses Problem besteht auch beim Aufholen von Grund auf, aber aufgrund einer gewissen Randomisierung können wir dies leicht bekämpfen.
Also @JeffreyW. Wollen Sie damit sagen, dass wir geth --fast aus Sicherheitsgründen nicht verwenden sollten? Ich synchronisiere Geth gerade damit und müsste wissen, ob ich dadurch anfällig für Hacking werde.
Das Synchronisieren von Grund auf ist in Ordnung, Sie sind nicht anfällig

Vergessen Sie nicht, eine SSD zu verwenden

Wenn Sie dazu in der Lage sind, ist die Verwendung einer NVMe-SSD noch besser.

Wenn Sie nur begrenzten Speicherplatz auf der SSD haben, siehe Können Kettendaten auf zwei (oder mehr) Standorte aufgeteilt werden?

Allerdings ist der Ethereum-Staat groß und wird immer größer. Seien Sie geduldig und es wird sich lohnen.

Wie kann ich einen Geth-Knoten dazu bringen, die Blockchain schnell herunterzuladen? Wiki wurde aktualisiert. Diese Antwort wurde für diejenigen aktualisiert, die dies finden und Probleme bei der Synchronisierung haben.


Vorherige Antwort

Vergessen Sie dies nicht , da dies --fastoft das Einzige ist, was mit einer schnellen Synchronisierung verbunden ist .--cache

Aus dem Homestead-Guide:

Nachfolgend finden Sie einige Flags, die Sie verwenden können, wenn Sie Ihren Client schneller synchronisieren möchten.

--schnell

Dieses Flag ermöglicht eine schnelle Synchronisierung durch Zustandsdownloads, anstatt die vollständigen Blockdaten herunterzuladen. Dadurch wird auch die Größe Ihrer Blockchain drastisch reduziert. HINWEIS: --fast kann aus Sicherheitsgründen nur ausgeführt werden, wenn Sie Ihre Blockchain von Grund auf neu synchronisieren und nur beim ersten Herunterladen der Blockchain. Weitere Informationen finden Sie in diesem Reddit-Beitrag .

--cache=1024

Megabyte Speicher, der dem internen Caching zugewiesen ist (mindestens 16 MB / Datenbank erzwungen). Der Standardwert ist 16 MB, also sollte die Erhöhung auf 256, 512, 1024 (1 GB) oder 2048 (2 GB) je nachdem, wie viel RAM Ihr Computer hat, einen Unterschied machen.

" fast" ist der Standardwert für den --syncmodeSchlüssel

Es bedeutet, dass es keinen Unterschied gibt, es zu verwenden --syncmode fastoder nicht zu verwenden.

Die Informationen von https://github.com/ethereum/go-ethereum/wiki/command-line-options

--syncmode value      Blockchain sync mode ("fast", "full", or "light") (default: fast)
Das stimmt nicht mehr:Blockchain sync mode ("fast", "full", "snap" or "light") (default: snap)

Aus der Geth-FAQ https://geth.ethereum.org/docs/faq

F. Wie funktioniert die Ethereum-Synchronisierung?

A. Der aktuelle Standard-Synchronisierungsmodus für Geth heißt schnelle Synchronisierung. Anstatt mit dem Genesis-Block zu beginnen und alle jemals aufgetretenen Transaktionen erneut zu verarbeiten (was Wochen dauern kann), lädt Fast Sync die Blöcke herunter und verifiziert nur die zugehörigen Proof-of-Works. Das Herunterladen aller Blöcke ist ein einfaches und schnelles Verfahren und wird die gesamte Kette relativ schnell wieder zusammensetzen.

Viele Leute nehmen fälschlicherweise an, dass sie synchron sind, weil sie die Blöcke haben. Leider ist dies nicht der Fall, da keine Transaktion ausgeführt wurde, sodass uns kein Kontostand zur Verfügung steht (z. B. Salden, Nonces, Smart Contract Code und Daten). Diese müssen separat heruntergeladen und mit den neuesten Blöcken abgeglichen werden. Diese Phase wird als Status-Trie-Download bezeichnet und läuft tatsächlich gleichzeitig mit den Block-Downloads. Leider dauert es heutzutage viel länger als das Herunterladen der Blöcke.

Also, was ist der Zustand? Im Ethereum-Mainnet gibt es bereits eine Menge Konten, die den Kontostand, Nonce usw. jedes Benutzers/Vertrags verfolgen. Die Konten selbst reichen jedoch nicht aus, um einen Knoten zu betreiben, sie müssen kryptografisch mit jedem Block verknüpft werden, damit die Knoten tatsächlich überprüfen können, ob die Konten nicht manipuliert wurden. Diese kryptografische Verknüpfung erfolgt durch Erstellen einer Baumdatenstruktur über den Konten, wobei jede Ebene die darunter liegende Schicht zu einer immer kleineren Schicht aggregiert, bis Sie die einzelne Wurzel erreichen. Diese gigantische Datenstruktur, die alle Konten und die kryptografischen Zwischenbeweise enthält, wird als Staatstrie bezeichnet.

Ok, also warum stellt das ein Problem dar? Diese Trie-Datenstruktur ist eine komplizierte Verknüpfung von Hunderten Millionen winziger kryptografischer Beweise (Trie-Knoten). Um wirklich einen synchronisierten Knoten zu haben, müssen Sie alle Kontodaten sowie alle winzigen kryptografischen Beweise herunterladen, um zu überprüfen, dass niemand im Netzwerk versucht, Sie zu betrügen. Das ist an sich schon eine verrückte Anzahl von Datenelementen. Der Teil, an dem es noch chaotischer wird, ist, dass sich diese Daten ständig verändern: Bei jedem Block (15 Sekunden) werden etwa 1000 Knoten aus diesem Trie gelöscht und etwa 2000 neue hinzugefügt. Das bedeutet, dass Ihr Knoten einen Datensatz synchronisieren muss, der sich 200 Mal pro Sekunde ändert. Das Schlimmste ist, dass sich das Netzwerk während der Synchronisierung vorwärts bewegt und der Status, dass Sie mit dem Herunterladen begonnen haben, möglicherweise während des Herunterladens verschwindet. Ihr Knoten muss also ständig dem Netzwerk folgen, während er versucht, alle aktuellen Daten zu sammeln. Aber bis Sie tatsächlich alle Daten gesammelt haben, ist Ihr lokaler Knoten nicht verwendbar, da er nichts über Konten kryptografisch beweisen kann.

Wenn Sie sehen, dass Sie 64 Blöcke hinter dem Mainnet sind, sind Sie noch nicht synchronisiert, nicht einmal annähernd. Sie sind gerade mit der Block-Download-Phase fertig und führen immer noch die Status-Downloads aus. Sie können dies selbst anhand des scheinbar endlosen Stroms von Protokollen mit importierten Statuseinträgen [...] sehen. Sie müssen auch das abwarten, bevor Ihr Knoten wirklich online geht.


Lesen Sie den Rest der FAQ für weitere Antworten wie:

F: Der Knoten hängt nur beim Importieren von Zustandsentitäten?!

F: Ich stecke 64 Blöcke hinter dem Mainnet fest?!

F: Warum dauert das Herunterladen des Status so lange, ich habe eine gute Bandbreite?

F: Warten Sie, also kann ich keinen vollständigen Knoten auf einer Festplatte ausführen?