Jormungandr: 0.8.2 ITN - 2 Separate Nodes Mined the Same Block Number 2 Epochs in a Row

[rickymac68]

Versions:
jcli 0.8.2 (HEAD-fe327f9a, release, macos [x86_64]) - [rustc 1.39.0 (4560ea788 2019-11-04)]
jormungandr 0.8.2 (HEAD-fe327f9a, release, macos [x86_64]) - [rustc 1.39.0 (4560ea788 2019-11-04)]

On 0.8.2 ITN at least 2 separate nodes operated by 2 different people mined the same block 2 epochs in a row, Epochs 1 and 2. My node mined block number 1.22518 and 2.22518. Each different node also happened to have ~1 Million Ada staked to it.

My Node Epoch 1 and 2. Screenshot is Epoch 2. Pool ID: df2bcbf8d850fee9d82204f4acba2899de2e2870685c41d98e1442c106aa4e54

Another user's node Epoch 1 and 2

[rickymac68]

This looks like a duplicate of #1370

[disassembler]

I was actually surprised to see anyone get blocks in epoch two because the stake should come from the beginning of the previous epoch (which would have been IOHK only). I think there may be some special case that it calculates the stake for epoch two using end of the 1st to prevent genesis block producers from getting all of the rewards in epoch 2, but developers would need to confirm.

[gufmar]

Afaik this is intended (implemented) behaviour. I noted this in a private testnet some weeks ago. The graphic shows exactly identical slot leader assignements for ep 1 and 2.

[rinor]

Just to confirm what @gufmar and @disassembler explained, this is the intended and implemented behavior in the sense that epoch 1 and epoch 2 leadership events are derived from the available stake distribution on epoch 0. This is explained also here https://github.com/input-output-hk/jormungandr/blob/master/doc/internal_design.md#from-the-block-0. This is a special case related only to epoch 1 and epoch 2

• epoch 1 <- epoch 0
• epoch 2 <- epoch 0

and after that it continues normally deriving epoch leadership one at a time.

• epoch 3 <- epoch 1
• epoch 4 <- epoch 2
• epoch 5 <- epoch 3
  ....