Ich synchronisiere meinen gethClient mit ropstenTestnet und habe gerade festgestellt, wie langsam der Synchronisierungsprozess nach einem bestimmten Block (der versucht, Informationen von Blöcken abzurufen, die gestern in die Blockchain gelangt sind) für ein paar Stunden ist.
Im Grunde habe ich mehrere Nachrichten wie diese erhalten, die einen möglichen Rewrite-Angriff besagen:
I0111 08:28:09.783928 eth/downloader/downloader.go:723] Peer 7335842dc6658f60 [hs 0.00/s, bs 0.00/s, rs 0.00/s, ss 0.00/s, miss 0, rtt 13.155759485s]: potential rewrite attack: #224778 [00000000�] <= #224778 limit
Meine Frage unterscheidet sich von dieser Frage, da ich beim Auschecken noch nicht synchronisiert bin. Eine der Antworten dort trifft hier nicht zu, da ich sichergestellt habe, dass ich auf den ropstenGenesis-Block verwiesen und den Hash dieses Genesis-Blocks in meiner lokalen Datenbank überprüft habe, um zu bestätigen, dass ich laufe, um mit dem richtigen Netzwerk synchronisiert zu werden. Ich glaube also nicht, dass die Ursache für diese hohe Verzögerung in meinem Knotensynchronisierungsprozess nicht wirklich das Hinzufügen von alt mordenzu meiner lokalen Datenbank ist.
Wird dieses Verhalten beim Synchronisieren erwartet? Gibt es eine Möglichkeit, die Peer-Abdeckung zu maximieren, um den gesamten Prozess zu beschleunigen, wenn es dazu kommt?
Sie können --fastFlag verwenden. Das Fast-Flag ermöglicht eine schnelle Synchronisierung durch Zustandsdownloads, anstatt die vollständigen Blockdaten herunterzuladen.
Ein weiteres Flag, das zusammen mit verwendet werden kann, um --fastIhren Client schneller zu synchronisieren, ist --cache. Das Cache-Flag kann verwendet werden, um den standardmäßig zugewiesenen Speicher für eine schnelle Synchronisierung zu ändern.
geth --datadir /path/to/testnet/data --networkid=3 –-syncmode=fast –-cache=1024
Siehe dazu: - https://medium.com/@crissimrobert/a-guide-to-ropsten-testnet-setup-f8952d615417
Versuchen Sie, zum Zeitpunkt der Synchronisierung das Flag „--fast“ in Ihrem Geth-Befehl hinzuzufügen. --fast ist die Standardeinstellung, wenn Sie geth das erste Mal ohne heruntergeladene Blöcke starten. Wenn Sie geth nach dem ersten Start neu starten, funktioniert --fast nicht mehr (es funktioniert nur noch von vorne). Deshalb müssen Sie es ausdrücklich erwähnen.
Wie Sie überall im Internet sehen können, gibt es viele Probleme bei der Synchronisierung von Geth mit Ropsten. Ich empfehle dringend, Parität für die Synchronisierung mit dem Ropsten-Netzwerk zu verwenden. Dafür empfehle ich, einem dieser Links zu folgen:
Parity ist nicht nur einfach zu konfigurieren und schnell zu synchronisieren, sondern verfügt auch über sehr umfangreiche Befehlszeilenparameter. Sie können sie überprüfen unter: https://github.com/paritytech/parity/wiki/Configuring-Parity
Saulo Ricci
q9f
Ziege teleportieren
eth.syncing?q9f