Ich habe 5 Clients eingerichtet (1 Boot, 1 Geth, 3 Unterzeichner, die Clique verwenden) - Die meiste Zeit funktionieren sie ohne Probleme und das Mining beginnt, manchmal stoppt das Mining einfach ohne Warnung oder Problem- / Fehlermeldung.
Ein anderes Mal bemerkte ich, dass, nachdem ich mich über einen zusätzlichen externen Unterzeichner geeinigt hatte, auch das Mining eingestellt wurde. Ich habe versucht, Informationen über die Reihenfolge zu finden, in der sich die Unterzeichner abwechseln und was das Mining verhindern kann, wenn man sich den Code ansieht, scheint es so Unterzeichner werden eher durch das Timing als zufällig ausgewählt, aber kann ein Unterzeichner, der aus irgendeinem Grund seinen "Turn" verpasst, die anderen Knoten lähmen oder daran hindern, Blöcke zu signieren/validieren? Ich würde vermuten, dass dies nicht der Fall ist, aber ich kann das Problem anscheinend nicht lösen und es macht mein Entwicklungsnetzwerk unbrauchbar. Ich weiß, dass ich nicht viel gebe, um weiterzumachen, aber es gibt keine Fehler wie üblich wie "als schlecht propagierter Block".
für was es wert ist, dass ich meine Unterzeichner damit betreibe
```
geth --datadir ~/test-net/data --mine --cache=1024 --syncmode 'full' --bootnodes="enode://enodeurlgoeshere@ipgoeshere:port" --networkid 47592 --rpc --rpcapi admin,db,eth,debug,miner,net,txpool,personal,web3 --rpcport "8545" --rpcaddr "0.0.0.0" --rpccorsdomain "*" --unlock 914be90b2a0dd6a5b0789c2cee5836dd1f1c030 --password <(echo "password") console --nat "extip:pubIPgoeshere"
```
und dies ist die Ausgabe des Signierens, wenn es aufhört
```
INFO [03-28|18:15:34] Commit new mining work number=21271 txs=0 uncles=2 elapsed=315.821µs
INFO [03-28|18:15:34] Successfully sealed new block number=21271 hash=0e4d19…b0854b
INFO [03-28|18:15:34] 🔨 mined potential block number=21271 hash=0e4d19…b0854b
INFO [03-28|18:15:34] Commit new mining work number=21272 txs=0 uncles=2 elapsed=434.638µs
INFO [03-28|18:15:34] Signed recently, must wait for others
INFO [03-28|18:23:07] Regenerated local transaction journal transactions=0 accounts=0
INFO [03-28|19:23:07] Regenerated local transaction journal transactions=0 accounts=0
INFO [03-28|20:23:07] Regenerated local transaction journal transactions=0 accounts=0
INFO [03-28|21:23:07] Regenerated local transaction journal transactions=0 accounts=0
```
Wenn Sie 3 Unterzeichner haben, müssen mindestens 2 online sein und das eth.coinbaseKonto entsperrt haben, um mit dem Versiegeln neuer Blöcke fortfahren zu können. Andernfalls bricht der Versiegelungsvorgang mit „Kürzlich unterschrieben, muss auf andere warten“ ab.
Wenn Sie sicher sind, dass Ihre Versiegeler online sind, dann ist die einzig logische Erklärung, dass Ihre Kontoentsperrung in eine Zeitüberschreitung gelaufen ist (Standard in Geth ist 5 Minuten) und das Versiegelungskonto wieder gesperrt ist. Bitte überprüfen Sie das. Sie können für unbegrenzte Zeit mit freischaltenpersonal.unlockAccount(eth.coinbase, "pwd", 0)
Siehe auch „ Wie kann ich Konten programmgesteuert entsperren, nachdem der Knoten gestartet wurde? “