Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix randomness fetching around null blocks #6240

Merged
merged 2 commits into from
May 28, 2021
Merged

Conversation

arajasek
Copy link
Contributor

@arajasek arajasek commented May 12, 2021

This is the larger but "better" fix to the critical portion of #3613.

  • Needs tests
  • Can we come up with a creative way to avoid the height check in the Chain API impl? That's the only bit I'm unhappy about.
  • Confirm we should actually be changing ChainRandomness fetching too.

@@ -95,7 +97,12 @@ func (a *ChainAPI) ChainGetRandomnessFromTickets(ctx context.Context, tsk types.
return nil, xerrors.Errorf("loading tipset key: %w", err)
}

return a.Chain.GetChainRandomness(ctx, pts.Cids(), personalization, randEpoch, entropy)
// Doing this here is slightly nicer than doing it in the chainstore directly, but it's still bad for ChainAPI to reason about network upgrades
if randEpoch > build.UpgradeHyperdriveHeight {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would love a creative suggestion that allows us to not do this

@Kubuxu
Copy link
Contributor

Kubuxu commented May 13, 2021

This version seems better to me. The Chain API having to check network version is annoying, especially if we consider that in future upgrades might depend on state and not a pure chain.

@arajasek
Copy link
Contributor Author

Added a test which will pass once we make a minor tweak to the tipset skipcache index (waiting on some input from Why)

@@ -833,3 +891,55 @@ func TestSyncCheckpointEarlierThanHead(t *testing.T) {
require.Equal(tu.t, p1Head, a.TipSet())
tu.assertBad(p1, b.TipSet())
}

func TestDrandNull(t *testing.T) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, because of the tipset cache thing i mentioned above^

Copy link
Contributor

@Kubuxu Kubuxu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SGWM, regarding the ugliness: the randomness just does not belong in Chain API,
as choosing randomness turns out to be a consensus rule built on top of the content of the chain.


require.Equal(t, []byte(rand), expectedRand)
build.UpgradeHyperdriveHeight = ov5h

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be easy enough to test that a second node can sync to this chain?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Lotus fetches drand from chain backwards with null blocks while specs fetches forward
3 participants