Conversation
|
TODO:
|
paulhauner
left a comment
paulhauner
left a comment
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
2 participants
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.