Skip to content

Add optimistic import for blocks for VALID ancestors - #2841

Closed
paulhauner wants to merge 6 commits into
ethereum:devfrom
sigp:opt-parent
Closed

Add optimistic import for blocks for VALID ancestors#2841
paulhauner wants to merge 6 commits into
ethereum:devfrom
sigp:opt-parent

Conversation

@paulhauner

Copy link
Copy Markdown
Contributor

Allow a node to optimistically import a block if it has an ancestor which:

  1. Has execution enabled.
  2. Has a VALID payload.

The VALID ancestor infers that the transition block was available, therefore this chain is not performing a malicious fork choice "poisoning" attack.

Implementations are permitted to stop searching at the finalized block, if they wish. This means implementations can use fork choice to store the execution status, they don't need to maintain it in the database for ancient blocks.

@paulhauner

Copy link
Copy Markdown
Contributor Author

I've fixed a flipped-bool in 60b34dc, as pointed out by @potuz 🙏

Comment thread sync/optimistic.md
# back in the chain.
elif hash_tree_root(block) == finalized_root:
return False
elif block.parent_root == Hash32() or block.parent_root not in opt_store.blocks:

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Won't just block.parent_root not in opt_store.blocks be sufficient in this case?

Comment thread sync/optimistic.md
1. The current slot (as per the system clock) is at least
`SAFE_SLOTS_TO_IMPORT_OPTIMISTICALLY` ahead of the slot of the block being
imported.
1. The block has a ancestor with an execution payload that has been deemed to

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Suggested change
1. The block has a ancestor with an execution payload that has been deemed to
1. The block has an ancestor with an execution payload that has been deemed to

@paulhauner

paulhauner commented Mar 1, 2022

Copy link
Copy Markdown
Contributor Author

I'm closing this in favor of the more general solution in #2844.

Thanks to those that reviewed.

@paulhauner paulhauner closed this Mar 1, 2022
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.

3 participants