Use the correct lookback for the worker key when creating blocks #4539
Conversation
We need to compute the ticket based on our worker key from the lookback epoch, not the current epoch.
Stebalien
requested review from
Kubuxu,
magik6k and
whyrusleeping
as code owners
| return nil, xerrors.Errorf("getting lookback miner actor state: %w", err) | ||
| } | ||
|
|
||
| lbst, _, err := sm.TipSetState(ctx, lbts) |
There was a problem hiding this comment.
This computes the state, we could just load it (we may also be doing this in GetMiningBase)
There was a problem hiding this comment.
Ah, I see. I should be walking back one fewer blocks and looking at the parent state?
There was a problem hiding this comment.
I'm not sure if I can do this reliably given null blocks. Currently, given:
- TS_A
- TS_B (parent: state at height 1)
- NULL <-- lookback height
- NULL
- TS_C (parent: state at height 4)
Currently, given a lookback height of 3, we'll use the state computed at height 2 (from TS_B). However, we don't actually record this state CID anywhere on chain. The next recorded state CID is for the state computed at height 4 (after processing two null rounds).
So, I could try to do my best to try to use parent tipset states from the chain, but that's going to be complicated.
Instead, what if we just improved our caching? We already maintain a tipset state cache, we could populate this cache with all tipsets between now and finality. (in a different PR)
There was a problem hiding this comment.
just do GetTipsetByHeight for the lookback height, and ensure prev is false, then take that tipsets epoch, add one, and call GetTipsetByHeight again on that with prev also equal to false.
There was a problem hiding this comment.
Given the null blocks, I'm pretty sure you'd end up with the exact same result.
There was a problem hiding this comment.
Yes but I need the state computed by executing TS_B. If I lookup lookback+1 and take the parent state, I'll get the parent state of TS_B, not the state resulting from the evaluation of TS_B. The fundamental issue here is that the state root produced by executing TS_B isn't recorded anywhere on chain.
There was a problem hiding this comment.
(alternatively, we could have looked at the parent state of the lookback tipset, but that needs a network upgrade)
There was a problem hiding this comment.
What? if a.Parents() == b then TipSetState(b) == a.ParentStateRoot.
There was a problem hiding this comment.
The fundamental issue here is that the state root produced by executing TS_B isn't recorded anywhere on chain.
Yes, its TS_C.ParentStateRoot
There was a problem hiding this comment.
Apparently I need to pay more attention when reading code. @whyrusleeping is correct.
Previously, we'd use the current worker key when signing blocks and computing the VRF. Now, we use the worker key from the correct lookback epoch. This now matches the behavior on the validation side.
Required for (and tested by) #4513.