Das Mining mit Geth im privaten Netzwerk hängt auf unbestimmte Zeit

Ich habe ein privates Testnetzwerk, das gemäß diesem Artikel läuft . Insbesondere difficultyist my auf 0x400; Die gesamte Genesis-Datei, die ich verwende, kann hier eingesehen werden .

Mining mit gethscheint überhaupt nicht zu funktionieren.

Hier ist, was ich versucht habe. Zuerst eine frische Blockchain und ein neues Konto:

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

Nachdem Sie sich damit befasst haben, starten Sie die Konsole:

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

Und dann verstehe ich das Standard-Mining-Setup:

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

Die Protokolle berichten, dass das Generieren des DAG für Epoche 0 in ~1 Sekunde abgeschlossen ist und der Miner dann zu hängen scheint. Die längste Zeit, die ich laufen ließ, waren etwa 15 Minuten, aber bei der angegebenen Schwierigkeit verstehe ich, dass ich viel in viel kürzerer Zeit abbauen sollte. Wenn ich miner.hashratean irgendeinem Punkt überprüfe, erhalte ich nur einen bizarren new BigNumber() not a number: [object Object]Fehler.

Ich habe auch versucht, das .ethashVerzeichnis zu löschen und einen neuen DAG von Grund auf neu zu erstellen. Gleiches Ergebnis.

Nach dem Stoppen mit bestätigt miner.stop(2)ein getBalanceAufruf, dass keine Ether geschürft wurden:

> eth.getBalance(foo);
0

Wenn ich anrufeeth.getBlock('pending', true) , erhalte ich die folgenden Informationen (Sie können die gesamte Protokoll-/Konsolensitzungsausgabe in diesem Kern sehen ):

{
  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: []
}

Beachten Sie, dass der gemeldete difficultyWert viel höher ist als das, was ich in meiner Genesis-Datei angegeben habe. 131072, wobei ich davon ausgehe, dass es 1024 wäre. Vielleicht stellt dies aber nicht die gleiche Schwierigkeit dar. Später totalDifficultywird verblüffenderweise als 0 gemeldet.

Hat jemand eine Ahnung, was hier schief laufen könnte?

Es scheint, als ob dies das gleiche Problem ist, das in dieser Frage auftritt .

Das hört sich ziemlich nach einem Fehler an und Sie könnten versuchen, offizielle Unterstützung im Github-Repository zu erhalten, indem Sie ein Ticket erstellen .
Ja, das scheint der Fall zu sein. Dort ist bereits ein Problem vorhanden.

Antworten (3)

Wie in den Kommentaren erwähnt, scheint dies auf einen Fehler zurückzuführen zu sein .

Ein Neustart meiner VM scheint das Problem in der Zwischenzeit umgangen zu haben.

der Fehler wurde geschlossen, weil er veraltet war, und ab geth v1.7.3-stable-4bb3c89d musste ich 28 Minuten warten, bevor der erste Block abgebaut wurde, und weitere 5 Minuten vor dem zweiten Block warten, und danach war es schnell, so hab einfach Geduld. Es kann daran liegen, dass ich das private Netzwerk mehrere Tage lang nicht hatte, da der Neustart nur zu einer anfänglichen Verzögerung von 1 Minute führte.

Ich hatte ein ähnliches Problem. Wenn Sie in einer virtuellen Maschine arbeiten. Stellen Sie sicher, dass Sie genügend RAM-Speicher zuweisen. Ich habe anfangs 800 MB verwendet und das Mining hat nicht funktioniert (die Hash-Rate war sehr niedrig). 2 GB Speicher zugewiesen und es funktionierte gut.

Wir hatten ein sehr ähnliches Problem. Das Aktualisieren von Geth auf die neueste Version und das Löschen und erneute Erstellen des DAG scheint das Problem behoben zu haben

Das Mining mit Geth im privaten Netzwerk hängt auf unbestimmte Zeit
AntwortenHierDatenschutz-Bestimmungen1y, 0v