Closed Scitz0 closed 1 year ago
The correlation with the epoch cutover suggests there may be an issue with e.g. the amount of time that is taken for rewards calculation.
hi @nc6 is this still an issue?
Has this issue been solved?
Closing this. If this is still relevant please re-open.
Exernal
Summary It has been observed running a node on private Guild Operators network that blocks minted right after epoch cutover(under 10s after cutover, exact time not confirmed but at least up to 6s) get rejected, trace:
TraceForgedInvalidBlock
, kind:VRFKeyBadNonceOVERLAY
.Steps to reproduce Have a block producing node with enough stake to regularly make blocks right after epoch cutover.
Expected behavior Blocks successfully made and adopted.
System info (please complete the following information):
Screenshots and attachments Full JSON trace of VRFKeyBadNonceOVERLAY
Image from my block collector implemented in guild operators cntools script tool to get a feeling for timestamps. Epoch cutover for guild network is exactly on the hour with 30min epochs. Shows 5 consecutive epochs for the first blocks made by my block producing node. The Hash field contains a base64 encoded representation of JSON trace like the one above.![image](https://user-images.githubusercontent.com/15903629/85151365-fcb56f00-b253-11ea-8687-5a6f2995267b.png)
Additional context Genesis for Guild network: https://github.com/cardano-community/guild-operators/blob/master/files/ptn0/files/genesis.json
We have checked if it's attempting to make a block when there is an overlay schedule with higher priority (due to d= 0.5) but this was not the case, was not on BFT schedule.
I have only ever seen the issue right after epoch cutover.