Skip to content

Conversation

michaelsproul
Copy link
Member

Issue Addressed

#570

Proposed Changes

Update to version 0.9.1 of the beacon chain phase 0 spec.

Additional Info

A lot of stuff gets deleted or renamed. The concept of a "shard" is temporarily no more, in its place we have some number of "beacon committees" attesting per slot. Attestations are rejigged accordingly.

@michaelsproul
Copy link
Member Author

michaelsproul commented Nov 11, 2019

TODO:

  • Update the fork choice rule for v0.9.1's protections against the flip-flop attack
  • Resolve what to do about the rest_api. I'm unsure how to update the api_spec.yaml, or whether that would be worth doing given the API changes happening on other branches?

@michaelsproul michaelsproul marked this pull request as ready for review November 19, 2019 00:05
Copy link
Member

@paulhauner paulhauner left a comment

Choose a reason for hiding this comment

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

I'll cover the REST API in a subsequent PR (likely to land today or tomorrow).

Looks great, as always!

};
// Check if we should update our view of the justified checkpoint.
// Doing this check here should be quasi-equivalent to the update in the `on_tick`
// function of the spec, so long as `find_head` is called at least once during the first
Copy link
Member

Choose a reason for hiding this comment

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

Hmm, it seems a little scary to have a function that needs to be run at a particular time interval. I can't think of a better way to do this, though. We could implement a timer service to ping this, but that's likely to result in waste. A good fallback if we find it's an issue, though.

On the plus side, I can't see a scenario where if you can cause lasting impact from missing a single update. Can you?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, I think battle-testing fork choice will be a very worthwhile undertaking. I agree with you that missing a single update here (if you happen to miss the SAFE_SLOTS_TO_UPDATE_JUSTIFIED period, which would require the node to be pretty screwed anyway I think) should self-correct at the next epoch.

@michaelsproul michaelsproul merged commit 24e941d into master Nov 21, 2019
@michaelsproul michaelsproul deleted the v0.9 branch November 21, 2019 00:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ready-for-review The code is ready for review
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants