Drand rounds are not computed as drand computes them

[nikkolasg]

Describe the bug

Lotus doesn't use the same "timestamp-to-round" mapping than drand:
Drand does the following (code):

math.Floor((now - genesis) / drandPeriod) + 1 

because round 1 happens at genesis time.
Lotus however does the following (code) :

math.Floor((now - genesis) / drandPeriod) 

It's a breaking change to move to drand, but it would be the preferred way.

Consequences: the lotus chain uses a round before the one it should use, having an offset of 2 instead of 1 (i.e. normally it looks at a drand round for one epoch before, but it's in fact using the randomness of one more previous drand round).

[nicola]

We can either leave as it is and update the spec (at the cost of having randomness with offset 2), or we can update lotus (but it will be a breaking change).

[nicola]

When making a block for a given round that block timestamp is when the block must be broadcasted by.

This means that you are likely generating that block at timestamp-1, so you must have it already by timestamp-1.

In order to make this work, it must come from a drand round at that time.

---

https://github.com/filecoin-project/lotus/blob/master/chain/beacon/drand/drand.go#L185

---

Final outcome: update the spec to reflect lotus code, since lotus is mitigating the issue described above.

[nikkolasg]

• There is one line that compute the filecoin timestamp given a filecoin epoch. This method already is shifting the result by one

latestTs := ((uint64(filEpoch) * db.filRoundTime) + db.filGenTime) - db.filRoundTime

The - db.filRoundTime at the end is saying "i take it one round before" (in Lotus, round 0 is at genesis, round 1 at genesis+roundTime, etc).

• Then once more, we compute the drand round shifted by one by doing:

dround := (latestTs - db.drandGenTime) / uint64(db.interval.Seconds()) 

Remember in drand we are supposed to do a +1 when computing the round.

I understand and well aware about the concern raised above but I think we are doing the fix "twice" instead of just one, resulting in a shift by two rounds.
@Kubuxu @nicola @whyrusleeping

[nicola]

Ping @Kubuxu did we fix this? Can we close this?

[nikkolasg]

PR subbmitted #3519

[arajasek]

Definitely descoping this from Chocolate in light of the blowup in complexity in #7376

[nicola]

hey @arajasek was this ever fixed?

[arajasek]

@nicola No, this is still an outstanding issue.

[jennijuju]

fixed in nv16

[nicola]

Congrats!