El apretón de manos de Ethereum de la cadena privada falló en el desajuste del bloque de Génesis

Estoy configurando una cadena privada entre dos máquinas virtuales.

El primer nodo comenzó a minar con éxito y la conexión entre las dos máquinas virtuales no tiene ningún problema.

Pero cuando intento conectar el segundo nodo al primero, aparece este error:

DEBUG[05-08|09:21:11] Ethereum handshake falló
id=e8d86dae37655a1b conn=dyndial err="No coincide el bloque de Génesis - dfc3e94e54007bba (!= 573969da5d11c81a)"

Copié el archivo genesis.json del primer nodo al segundo, ¿cómo es posible que no coincidan?

El comando que usé para iniciar el primer nodo es:

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

El comando para conectarse desde el segundo nodo:

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

Finalmente, el archivo genesis.json:

{
    "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
    }
}

La identificación de mi cliente coincide con la identificación de la red, y sé que la conexión fue exitosa porque las líneas sobre la falla del protocolo de enlace fueron:

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

Realmente confundido.....

los valores de port y rpcport serán diferentes en ambos nodos, la identificación de red será la misma
@AK, mis dos nodos están en dos máquinas virtuales diferentes, ¿el puerto y el puerto rpc tienen que ser diferentes?
no en ese caso, solo verifique si el nodo1 es accesible externamente, intente poner--rpcaddr "0.0.0.0"
@AK, puedo hacer ping al primer nodo desde el segundo nodo después de habilitar el ping en el primer nodo
simplemente inicie sesión en la consola de ambos nodos y haga que eth.getBlock(0) if the el campo Hash` sea diferente, luego lo atornilla en algún lugar al inicializar el bloque de génesis. Primero use initel comando para inicializar ambos nodos con el bloque de génesis correcto y luego inicie los nodos

Respuestas (2)

Este es un problema común para configurar una red local. Hay cuatro problemas principales que pueden detener la sincronización de bloques.

  1. Bloque de génesis no coincidente.
  2. No se agregó el nodo de arranque.
  3. La identificación de la red no coincide.

  4. No se puede acceder al sistema de nodos

    ¿Cómo verificar que su bloque de génesis sea el mismo para dos o más nodos?

    Escriba el siguiente comando en su consola geth.

    > admin.nodeInfo.protocols.eth.genesis

    0x981XXXXXXXXXXXXxxxxxxxxxXXXXXXXXXXXXXXXXXxxxxXXXXXXxxxXXx Unir dos nodos, dos archivos de génesis deben coincidir. Si su nodo geth no coincide, rechazará la conexión debido al ataque de repetición. es decir, debe iniciar sus nodos con el mismo genesis.json. No edite genesis.json

    --nodescubrir:

    Cuando use esta opción, su nodo no estará expuesto al sistema externo para escanear. Luego, cómo agregar este nodo a otro nodo, use --bootnodes o admin.addPeer('');

    La identificación de la red no coincide

    Mientras ejecuta su nodo geth, su identificación de red puede no coincidir, o puede olvidarse de agregar. use --networkid en el momento del comando geth.

    No se puede acceder al sistema de nodos

    Debido a la configuración de algunos cortafuegos de red, no se puede acceder a su puerto. Al igual que AWS, debe agregar el puerto tcp para que esté habilitado para la instancia EC2.

Para obtener más detalles, consulte el siguiente enlace: https://medium.com/mercuryprotocol/how-to-create-your-own-private-ethereum-blockchain-dad6af82fc9f

1, definitivamente el mismo bloque de génesis; 2, esto está configurado; 3, misma identificación de red; 4, abrí el puerto en máquinas virtuales de Azure. ¿El puerto y el rpcport tienen que ser diferentes? Los dos nodos están en máquinas virtuales diferentes (pero en la misma red privada)
Use diferentes puertos a través del comando --port y asegúrese de que dicho puerto se refleje con precisión al hacer referencia como enodo.

El mismo problema que resolví con

$ geth init genesis.json

antes de iniciar el nodo.

El apretón de manos de Ethereum de la cadena privada falló en el desajuste del bloque de Génesis
RespuestasAquíPolítica de privacidad1y, 0v