PoA private network clique: 😱 block lost

[marcosmartinez7]

System information

My current version is:

Geth
Version: 1.8.17-stable
Git Commit: 8bbe72075e4e16442c4e28d999edee12e294329e
Architecture: amd64
Protocol Versions: [63 62]
Network Id: 1
Go Version: go1.10.1
Operating System: linux
GOPATH=
GOROOT=/usr/lib/go-1.10

Expected behaviour

No blocks lost

Actual behaviour

I was running a go-ethereum private network with 6 sealers.

Each sealer is run by:

directory=/home/poa
command=/bin/bash -c 'geth --datadir sealer1/  --syncmode 'full' --port 30393 --rpc --rpcaddr 'localhost' --rpcport 8600 --rpcapi='net,web3,eth' --networkid 30 --gasprice '1' -unlock 'someaddress' --password sealer4/password.txt --mine '

Then, the nodes are added as peers with admin.addPeer() so each node is paired with the other 5 sealers

I have found this in my logs:

Any ideas of why is this happening? it happens a lot..

I can retrieve that block from the node anyway, but seems like an error..

[marcosmartinez7]

I see into other signer console that the block reached canonical chain

Sealer 1

INFO [01-08|04:03:57.001] 😱 block lost number=488889 hash=ff9da7…09303d

Sealer 2

INFO [01-08|04:05:37.260] 🔗 block reached canonical chain number=488899 hash=f0ee43…d9490d

So, whats the deal with this?

Thanks in advance!

[karalabe]

That's generally fine. The way clique works is that the in-turn sealer who should ideally sign next tries to sign and propagate the block immediately when the timer ticks. If no in-turn block appears within 500ms, the other signers start potentially creating alternative blocks (with random delays), this ensures that even if a signer is missing, the chain progresses more or less properly.

Now, if the original in-turn signer does come around and publish its block with some delay, that might reorg out alternative blocks signer by out-of-turn signers. At that point those will complain that their block was lost. The scary smiley is mostly meant for ethash :) Clique blocks have no subsidy anyway :)