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

modify fork choice to utilize epochs properly #1198

Merged
merged 11 commits into from
Jun 27, 2019
Merged

modify fork choice to utilize epochs properly #1198

merged 11 commits into from
Jun 27, 2019

Conversation

djrtwo
Copy link
Contributor

@djrtwo djrtwo commented Jun 20, 2019

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.

@djrtwo djrtwo requested review from CarlBeek, JustinDrake and vbuterin and removed request for CarlBeek June 20, 2019 20:53
JustinDrake added a commit that referenced this pull request Jun 21, 2019
Copy link
Collaborator

@JustinDrake JustinDrake left a 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 :)

specs/core/0_fork-choice.md Outdated Show resolved Hide resolved
specs/core/0_fork-choice.md Outdated Show resolved Hide resolved
specs/core/0_fork-choice.md Outdated Show resolved Hide resolved
specs/core/0_fork-choice.md Outdated Show resolved Hide resolved
specs/core/0_fork-choice.md Outdated Show resolved Hide resolved
specs/core/0_fork-choice.md Outdated Show resolved Hide resolved
@djrtwo djrtwo changed the base branch from executable_fork_choice to dev June 21, 2019 17:28
@JustinDrake JustinDrake added the milestone:June 30 freeze 🥶 Phase 0 spec freeze for long-lived cross-client testnet label Jun 21, 2019
specs/core/0_fork-choice.md Outdated Show resolved Hide resolved
specs/core/0_fork-choice.md Outdated Show resolved Hide resolved
specs/core/0_fork-choice.md Show resolved Hide resolved
specs/core/0_fork-choice.md Outdated Show resolved Hide resolved
@djrtwo djrtwo force-pushed the fork-choice-epoch branch from 481e1b7 to c2128bd Compare June 25, 2019 03:13
@djrtwo djrtwo force-pushed the fork-choice-epoch branch from c2128bd to d9b9757 Compare June 25, 2019 03:23

```python
@dataclass
class Target(object):
@dataclass(eq=True, frozen=True)
Copy link
Contributor Author

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

@djrtwo djrtwo force-pushed the fork-choice-epoch branch from ff7f537 to 846ca64 Compare June 25, 2019 16:36
@djrtwo djrtwo force-pushed the fork-choice-epoch branch from 3a54e25 to 6c1181b Compare June 25, 2019 20:46
@djrtwo djrtwo force-pushed the fork-choice-epoch branch from 6c1181b to c642896 Compare June 25, 2019 20:48
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
Copy link
Collaborator

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)?

Copy link
Contributor Author

@djrtwo djrtwo Jun 26, 2019

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

Copy link
Contributor

@CarlBeek CarlBeek left a 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!

Copy link
Collaborator

@JustinDrake JustinDrake left a 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 :)

@CarlBeek CarlBeek merged commit 543729c into dev Jun 27, 2019
@djrtwo djrtwo deleted the fork-choice-epoch branch May 20, 2020 23:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
milestone:June 30 freeze 🥶 Phase 0 spec freeze for long-lived cross-client testnet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants