La minería con geth en una red privada se cuelga indefinidamente

Tengo una red de prueba privada funcionando según este artículo . En particular, my difficultyse establece en 0x400; el archivo completo de génesis que estoy usando se puede ver aquí .

La minería con gethno parece funcionar en absoluto.

Esto es lo que he intentado hacer. Primero una cadena de bloques nueva y una cuenta:

vagrant@debian-jessie:~$ mkdir stackexchange-example-chain
vagrant@debian-jessie:~$ geth --genesis local_genesis.json \
  --datadir stackexchange-example-chain \
  --networkid 9991 --nodiscover --maxpeers 0 account new

Luego, después de lidiar con eso, iniciando la consola:

vagrant@debian-jessie:~$ geth --genesis local_genesis.json \
  --datadir stackexchange-example-chain \
  --networkid 9991 --nodiscover --maxpeers 0 console

Y luego lo que entiendo que es la configuración de minería estándar:

> eth.accounts
["0x699ec6d49641e59f65ba4bf72c52628059301e64"]
> var foo = eth.accounts[0];
undefined
> miner.setEtherbase(foo);
true
> miner.start(2);
true

Los registros informan que la generación del DAG para la época 0 finaliza en ~1 segundo, y luego el minero parece colgarse. El tiempo más largo que lo he dejado correr es de unos 15 minutos, pero con la dificultad que he especificado, entiendo que debería estar minando mucho en mucho menos tiempo que eso. Si compruebo miner.hashrateen cualquier momento, obtengo un new BigNumber() not a number: [object Object]error extraño.

También intenté borrar el .ethashdirectorio y generar un nuevo DAG desde cero. Mismo resultado.

Después de detenerse con miner.stop(2), una getBalancellamada verifica que no se haya extraído éter:

> eth.getBalance(foo);
0

Si llamo eth.getBlock('pending', true), recibo la siguiente información (puede ver el resultado completo de la sesión de registro/consola en este resumen ):

{
  difficulty: 131072,
  extraData: "0xd783010400844765746887676f312e352e31856c696e7578",
  gasLimit: 268173313,
  gasUsed: 0,
  hash: null,
  logsBloom: null,
  miner: null,
  nonce: null,
  number: 1,
  parentHash: "0x522fe03765d5834422cd7cfc88c435f33bcd13d7a4c71cd8eaf321a8b3dd8ea3",
  receiptRoot: "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
  sha3Uncles: "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
  size: 536,
  stateRoot: "0x2fa7b359e63faf5af52846537e67053ffd96d2fd33877704192c9c3e6e6266b9",
  timestamp: 1455530923,
  totalDifficulty: 0,
  transactions: [],
  transactionsRoot: "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
  uncles: []
}

Tenga en cuenta que el informe difficultyes mucho más alto que lo que especifiqué en mi archivo de génesis; 131072, mientras que supongo que sería 1024. Sin embargo, tal vez esto no represente la misma dificultad. Más tarde totalDifficultyse informa como 0, desconcertantemente.

¿Alguien tiene alguna idea de lo que podría estar yendo mal aquí?

Parece que este es el mismo problema encontrado en esta pregunta .

Esto suena bastante parecido a un error y podría intentar obtener soporte oficial en el repositorio de github creando un ticket .
Sí, ese parece ser el caso. Ya hay un problema existente allí.

Respuestas (3)

Como se menciona en los comentarios, esto parece deberse a un error .

Mientras tanto, reiniciar mi VM parece haber solucionado el problema.

el error se cerró por estar desactualizado y, a partir de geth v1.7.3-stable-4bb3c89d, tuve que esperar 28 minutos antes de que se extrajera el primer bloque y tuve que esperar 5 minutos adicionales antes del segundo bloque y después de eso fue rápido, así que sea ​​paciente. Puede deberse a que tuve la red privada inactiva durante varios días, ya que reiniciar solo provocó un retraso inicial de 1 minuto.

Tuve un problema similar. Si está ejecutando en una máquina virtual. Asegúrese de asignar suficiente memoria ram. Usé 800 MB inicialmente y la minería no funcionó (la tasa de hash era muy baja). Asignó 2 GB de memoria y funcionó bien.

Tuvimos un problema muy similar. Actualizar Geth a la última versión y eliminar y reconstruir el DAG parece haber solucionado el problema