Anhaltende "Deep Transaction Reorg" während der Synchronisierung des vollständigen Geth-Knotens

Beim Synchronisieren eines neuen vollständigen Knotens mit dem Geth-Befehl "geth --syncmode full" sehe ich in jeder zweiten Zeile nach einigen hundert Blöcken Folgendes:

WARN [12-02|02:30:46] Skipping deep transaction reorg          depth=2048

Dies hat sich bis zu ~1,6 Millionen synchronisierten Blöcken fortgesetzt.

Terminal-Screenshot:Screenshot des Terminals mit Warnmeldungen

Ist das ein Problem? Ist es ein Sicherheitsproblem? Stellt es einen "bösen" Kollegen, einen Sybil-Angriff oder etwas weitaus Gutartigeres dar?

Zu Ihrer Information, ich verwende die neueste Geth-Version (Geth/v1.7.2-stable-1db4ecdc/linux-amd64/go1.9) auf Ubuntu 17.10.

Vielleicht synchronisieren Sie näher an einem Fork in der Blockchain und einige der Peers befinden sich in der falschen Kette, das sollte sich nach einiger Zeit selbst beheben. Sie können versuchen, geth neu zu starten, damit es versucht, sich mit einer neuen Gruppe von Peers zu verbinden.

Antworten (2)

Fügen Sie einige renommierte Peers/Bootnodes manuell hinzu. Die folgende Anleitung zeigt, wie Sie dies mit Geth tun, entweder über IPC oder eine Konfigurationsdatei: https://github.com/ethereum/go-ethereum/wiki/Connecting-to-the-network

Ein Reorg wird nur durchgeführt, wenn ein Block, der auf einem Side Fork importiert wird, zu einer höheren Gesamtschwierigkeit auf diesem bestimmten Fork führt als der kanonische Fork. Die Blöcke müssen trotzdem noch gültig sein.

Wie im Ethereum -Blog geschrieben, finden Kettenreorganisationen statt, wenn ein Knoten im Ethereum-Netzwerk feststellt, dass das, was er für die kanonische Kette hielt, sich als falsch herausstellte. Wenn dies geschieht, werden die Transaktionen im letzten Teil der Kette (dh die jüngsten Transaktionen) rückgängig gemacht und stattdessen die Transaktionen im neueren Ersatz ausgeführt.

Da Ethereum eine kurze Target Block Time von 15s hat, kommt das natürlich ziemlich oft vor. Da es einige Zeit dauert, bis die Blöcke durch das Netzwerk sickern, ist es für verschiedene Teile des Netzwerks im Normalbetrieb leicht, einen anderen letzten Block (oder zwei oder vielleicht sogar drei) zu haben, da die Miner sie oft ungefähr um die Uhr finden gleiche Zeit. Das ist, was wir kurzlebiges Forking nennen könnten.

Wenn eine Reorganisation stattfindet, oder anders ausgedrückt, wenn das Netzwerk einen globaleren Konsens erreicht, den es früher hatte, und ein Fork aufgelöst wird, „reorganisieren“ die Knoten, die die jetzt veraltete Kette hatten, ihre Kette und werfen die aktuelle weg und nicht mehr kanonische Blöcke. Transaktionen werden rückgängig gemacht und andere ausgeführt, um mit dem anderen Pfad des Forks in Einklang zu kommen.

Wenn eine Kettenreorganisation in Ethereum auftritt, ist der übliche Weg, zuerst einen gemeinsamen Block zu finden, den Block mit der größeren Schwierigkeit einzufügen und die Transaktion innerhalb der alten Kette zu halten, aber nicht innerhalb der neuen Kette zurück zu txpool. Sie können auch hier mehr über Probleme mit der Kettenreorganisation lesen .