Geth miner tiene 0 hashrate en la cadena privada incluso con el conjunto de direcciones de coinbase y miner.start() llamado

Tengo una cadena privada de varios nodos y recientemente tuve que cambiar el networkId y el ChainID en el bloque de Génesis para que coincidieran con el fin de obedecer los requisitos de Metamask.

Ahora que realicé esos cambios y volví a implementar, funcionó bien para mí localmente, pero mis nodos Geth dockerizados no pueden "Sellar con éxito un nuevo bloque", pero pueden "Confirmar un nuevo trabajo de minería". A continuación se muestra el siguiente Dockerfile:

FROM ethereum/client-go:v1.7.2

RUN mkdir -p /root/myChain/
WORKDIR /root/myChain

COPY Genesis.json /root/myChain/

RUN geth \
    --identity "myChainNode" \
    init \
    --datadir "/root/.ethereum/myChain/" \
    "/root/myChain/Genesis.json" \
    --ipcdisable \
    --mine --autodag --networkid 777 --nat "any" --gasprice "3000000"

EXPOSE 30303
EXPOSE 8545


ENTRYPOINT geth \
    --identity "myChainNode" \
    --datadir "/root/.ethereum/myChain/" \
    --ipcdisable \
    --networkid 777 \
    --rpcapi eth,web3,net,personal \
    --rpc --rpcaddr "0.0.0.0" --rpcport "8545" \
    --rpccorsdomain "*" \
    --nat "any" \
    --port "30303" \
    --etherbase "<myPublicAddress>" \
    --ws --wsport "8546" --wsaddr="0.0.0.0" --wsorigins "*" \
    --mine \
    console

Cuando yo miner.start()o miner.start(8)la respuesta es nullque estoy conectado a pares en mi cadena privada y mi tasa de hash sigue siendo 0.

AWS tiene los puertos 30303 y 8545 apropiados abiertos para mi EC2 ejecutándolo.

Mi nodo local está minando a la perfección y su script de ejecución se ve así:

sudo geth \
    --identity "myChainNode" \
    --datadir "~/Library/Ethereum/myChain" \
    --ipcdisable \
    --etherbase "<myPublicAddress>" \
    --networkid 777 \
    --rpcapi eth,web3,net,personal \
    --rpc --rpccorsdomain "*" \
    -rpcport "8545" \
    --verbosity 3 \
    --ws --wsport "8547" --wsorigins "*" \
    --mine \
    console

¿Alguna idea?

Respuestas (2)

Descubrí que la razón por la que sucedió esto es la siguiente:

Cuando creé por primera vez la cadena privada, ejecuté la inicialización con un ID de red diferente. Como mencioné en los comentarios, terminé cambiándolo debido a los requisitos de metamáscara para que CustomRPC tenga el ID de red y el ID de cadena coincidentes.

Si decidió cambiar su ID de red después de comenzar su cadena, debe asegurarse de que Geth Init use su ID de red original y luego, cuando ejecute/abra su nodo Geth, coloque su nuevo ID de red. La cadena se inicializó en todos sus otros nodos y no se extraerá correctamente ya que no se puede sellar sin tener la misma configuración de inicio.

Un minero requiere una cuenta desbloqueada para sellar. Parece que olvidaste desbloquear la cuenta.

No necesita la cuenta desbloqueada para que los selle. Lo he comprobado en otros nodos. De hecho, ni siquiera necesita tener ninguna cuenta cargada en web3.personal, solo necesita configurar Etherbase/Coinbase en la dirección que elija...
Pero esta respuesta y mi propia configuración me hacen pensar lo contrario:/ Pero aún así, volvería después de confirmarme.
Interesante, creo que no es el caso de que necesites desbloquear ninguna cuenta para poder minar. Lo compararía con trabajar en una empresa, le das a la empresa tu número de cuenta bancaria para que envíen dinero desde el aire, pero no necesitas iniciar sesión para hacer el trabajo. En cualquier caso, he probado a través de pruebas de mi parte que es cierto. Ojalá pudiera darte un hash de prueba de trabajo, jaja.
He confirmado por el siguiente msjWARN [03-27|06:49:17] Block sealing failed err="authentication needed: password or unlock"
Eso es tan raro. A mí no me pasó en absoluto. Implementé nodos nuevos en nuevas instancias de AWS y nunca desbloqueé nada y funciona perfectamente. Lo siento.
Probablemente sea el consenso. Podría ser necesario para POA. ¿Usaste POA?
Geth miner tiene 0 hashrate en la cadena privada incluso con el conjunto de direcciones de coinbase y miner.start() llamado
RespuestasAquíPolítica de privacidad1y, 0v