-
Notifications
You must be signed in to change notification settings - Fork 997
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
modify fork choice to utilize epochs properly #1198
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Started reviewing. Suggest merging #1185 soon regardless of this PR :)
481e1b7
to
c2128bd
Compare
c2128bd
to
d9b9757
Compare
|
||
```python | ||
@dataclass | ||
class Target(object): | ||
@dataclass(eq=True, frozen=True) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is temporary to make Checkpoint
usable as a lookup key in a dictionary.
In #1210, we elevate Checkpoint
to an SSZ type in beacon chain spec and this is removed
ff7f537
to
846ca64
Compare
3a54e25
to
6c1181b
Compare
6c1181b
to
c642896
Compare
children = [root for root in store.blocks.keys() if store.blocks[root].parent_root == head] | ||
children = [ | ||
root for root in store.blocks.keys() | ||
if store.blocks[root].parent_root == head and store.blocks[root].slot > justified_slot |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just checking parent_root
should be enough. But if we are doing both, maybe swap the slot check to be first (much faster)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It isn't actually enough. There is a case where the block is in the block tree since latest justified block but is from an epoch prior to latest justified epoch.
Example:
- Block A at slot 60
- Block B (parent A) at slot 61
- Block A is justified at epoch 1 (slot 64)
- The block tree under consideration is now descendants of Block A but exclusively after the epoch boundary slot of epoch 1.
- Thus Block B should not be in consideration.
That said, we can flip the two bool checks for speed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approved, partly to get #1210 merged also :)
This is a full adaptation of the issue discussed in #768 and is a crucial component of how state must be utilized in a slot/epoch based fork choice. note that this is a PR to the current fork choice PR #1185
When justifying and finalizing a block, we are actually justifying/finalize a
(block, epoch)
tuple (Checkpoint
). This represents the block at the 0th slot of the epoch and we must use the associated state from here. In the normal case, this is at parity but in the case of skipped slots, the finalized block must be transitions up to the start of the epoch it was finalized in.