Private Chain Ethereum Handshake fehlgeschlagen Genesis Block Mismatch

Ich richte eine private Kette zwischen zwei VMs ein.

Der erste Knoten hat erfolgreich mit dem Mining begonnen, und die Verbindung zwischen den beiden VMs ist problemlos.

Aber wenn ich versuche, den zweiten Knoten mit dem ersten zu verbinden, bekomme ich diesen Fehler:

DEBUG[05-08|09:21:11] Ethereum-Handshake fehlgeschlagen
id=e8d86dae37655a1b conn=dyndial err="Genesis block mismatch - dfc3e94e54007bba (!= 573969da5d11c81a)"

Ich habe die genesis.json-Datei vom ersten Knoten zum zweiten kopiert, wie können sie nicht übereinstimmen?

Der Befehl, mit dem ich den ersten Knoten gestartet habe, lautet:

geth --identity nodeBcDev1 --nodiscover --networkid 9191 --port 60830 --maxpeers 5 --lightkdf --cache 512 --rpc --rpccorsdomain "*" --datadir "C:\BlockChain\Data" --minerthreads 2 --mine

Der Befehl zum Verbinden vom zweiten Knoten:

geth --networkid 9191 --port 60830 --rpc --rpcport 8545 --rpccorsdomain "*" --datadir "C:\BlockChain\Data" --minerthreads 2 --bootnodes "enode://41cc17dydeefide8018c39054653d638430c3abfe3f77g009dc9294h0e8a9d62a5b819fb5810391fddab560d4c1bf9d1c9b110c6fbe603731388a993751bd95e@10.0.0.1:60830" --verbosity 4

Schließlich die genesis.json-Datei:

{
    "nonce"         : "0x0000000000000055",
    "mixHash"       : "0x0000000000000000000000000000000000000000000000000000000000000000",
    "parentHash"    : "0x0000000000000000000000000000000000000000000000000000000000000000",
    "difficulty"    : "0x1",
    "gasLimit"  : "0x800000",
    "timestamp" : "0x0",
    "extraData" : "",
    "coinbase"  : "0x0000000000000000000000000000000000000000",
    "alloc"         : {},
    "config"    : {
        "chainId": 9191,
        "homesteadBlock": 0,
        "eip155Block": 0,
        "eip158Block": 0
    }
}

Meine Client-ID stimmt mit der Netzwerk-ID überein, und ich weiß, dass die Verbindung erfolgreich war, weil die Zeilen über dem Handshake-Fehler lauteten:

DEBUG[05-08|09:21:11] Ethereum peer connected                  id=df887467936a7c9b conn=dyndial name=Geth/v1.8.0-unstable/linux-amd64/go1.9.4

Wirklich verwirrt.....

Die Werte von port und rpcport sind auf beiden Knoten unterschiedlich, die Netzwerk-ID ist dieselbe
@AK, meine beiden Knoten befinden sich auf zwei verschiedenen VMs, müssen Port und RPCPort unterschiedlich sein?
nicht in diesem Fall, einfach prüfen, ob node1 extern erreichbar ist, versuchen zu setzen--rpcaddr "0.0.0.0"
@AK, ich kann den ersten Knoten vom zweiten Knoten aus pingen, nachdem ich das Ping auf dem ersten Knoten aktiviert habe
Melden Sie sich einfach an der Konsole beider Knoten an und tun Sie, ob das eth.getBlock(0) if the Hash-Feld anders ist, dann schrauben Sie es irgendwo beim Initialisieren des Genesis-Blocks. Verwenden Sie zuerst initden Befehl, um beide Knoten mit dem richtigen Genesis-Block zu initialisieren, und starten Sie dann die Knoten

Antworten (2)

Dies ist ein häufiges Problem beim Einrichten eines lokalen Netzwerks. Es gibt vier Hauptprobleme, die die Synchronisierung von Blöcken stoppen können.

  1. Nicht übereinstimmender Genesis-Block.
  2. Boot-Knoten wurde nicht hinzugefügt.
  3. Die Netzwerk-ID stimmt nicht überein.

  4. Zugriff auf Knotensystem nicht möglich

    Wie können Sie überprüfen, ob Ihr Genesis-Block für zwei oder mehr Knoten gleich ist?

    Geben Sie den folgenden Befehl in Ihre Geth-Konsole ein.

    > admin.nodeInfo.protocols.eth.genesis

    0x981XXXXXXXXXXxxxxxxxxxXXXXXXXxxxxxXXXXxxxxxxXXXXXXXXXXXx Verbinden Sie zwei Knoten, zwei Genesis-Dateien sollten übereinstimmen. Wenn sein nicht übereinstimmender Geth-Knoten die Verbindung aufgrund eines Replay-Angriffs ablehnt. dh Sie müssen Ihre Knoten mit derselben genesis.json initialisieren. Bitte bearbeiten Sie genesis.json nicht

    --nodiscover:

    Wenn Sie diese Option verwenden, wird Ihr Knoten keinem externen System zum Scannen ausgesetzt. Um diesen Knoten dann einem anderen Knoten hinzuzufügen, verwenden Sie --bootnodes oder admin.addPeer('');

    Die Netzwerk-ID stimmt nicht überein

    Während Sie Ihren Geth-Knoten ausführen, stimmt Ihre Netzwerk-ID möglicherweise nicht überein, oder Sie haben möglicherweise vergessen, sie hinzuzufügen. Verwenden Sie --networkid zum Zeitpunkt des geth-Befehls.

    Zugriff auf Knotensystem nicht möglich

    Aufgrund einiger Netzwerk-Firewall-Einstellungen ist Ihr Port nicht zugänglich. Wie bei AWS müssen Sie den TCP-Port hinzufügen, der für die EC2-Instanz aktiviert werden soll.

Weitere Einzelheiten finden Sie unter folgendem Link: https://medium.com/mercuryprotocol/how-to-create-your-own-private-ethereum-blockchain-dad6af82fc9f

1, definitiv der gleiche Genesis-Block; 2, dies ist eingestellt; 3, gleiche Netzwerk-ID; 4 habe ich den Port auf Azure-VMs geöffnet. Müssen Port und RPCPort unterschiedlich sein? Die beiden Knoten befinden sich auf verschiedenen VMs (aber demselben privaten Netzwerk)
Verwenden Sie verschiedene Ports über den Befehl --port und stellen Sie sicher, dass dieser Port genau wiedergegeben wird, wenn Sie als enode referenzieren.

Das gleiche Problem, mit dem ich es gelöst habe

$ geth init genesis.json

vor dem Startknoten.

Private Chain Ethereum Handshake fehlgeschlagen Genesis Block Mismatch
AntwortenHierDatenschutz-Bestimmungen1y, 0v