You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
According to the Consensus section of the document, voter nodes will vote when they receive a newly generated block via the standard Ethereum P2P protocol (ChainHeadEvent). However they also appear to vote on the block generation event (CreateBlock).
E0120 21:44:49.886387 core/quorum/block_voting.go:288] Unable to create block: Node not configured for block creation
I0120 21:44:49.886915 core/quorum/block_voting.go:388] vote for 0xbb889fee70776551d79d7d65f6b5c3b1c932e15f63e3dba40b95b071e
495cab5 on height 8
As all nodes run the BlockMakerStrategy, looking in core/quorum/block_voting.go, in the run function for the CreateBlock event case it would seem that any voter node that is not enabled for block creation (i.e. createBlock will fail) will then always attempt to vote for the hash of the parent block of its current pending state.
The text was updated successfully, but these errors were encountered:
Thanks for reporting this. You are correct and this is something that needs to be addressed. It is not something that can lead to consensus problems but it leads to spurious transactions.
According to the Consensus section of the document, voter nodes will vote when they receive a newly generated block via the standard Ethereum P2P protocol (ChainHeadEvent). However they also appear to vote on the block generation event (CreateBlock).
E0120 21:44:49.886387 core/quorum/block_voting.go:288] Unable to create block: Node not configured for block creation
I0120 21:44:49.886915 core/quorum/block_voting.go:388] vote for 0xbb889fee70776551d79d7d65f6b5c3b1c932e15f63e3dba40b95b071e
495cab5 on height 8
As all nodes run the BlockMakerStrategy, looking in core/quorum/block_voting.go, in the run function for the CreateBlock event case it would seem that any voter node that is not enabled for block creation (i.e. createBlock will fail) will then always attempt to vote for the hash of the parent block of its current pending state.
The text was updated successfully, but these errors were encountered: