changed 3 years ago
Linked with GitHub

Optimistic Sync Homepage

In lighthouse#2691 we discuss the need for "optimstic sync" for post-merge consensus clients (a.k.a. eth2 clients). That issue establishes the need for optimistic sync and presents some of the unanswered questions that surround it.

This document follows from lighthouse#2691 to provide a "homepage" for research into optimistic sync in Ethereum consensus clients.

The status-quo

Optimistic Sync: How many heads? defines four different types of heads we can track in optimistic sync:

  1. The optimistic head
  2. The verified ancestor head
  3. The strict verified head
  4. The naive verified head

That document establishes that (1, 2) are simple-enough to implement, but (3, 4) are complex enough to strike fear in the hearts of client developers.

Optimistic Sync: Which is the right head for the job? then goes to enumerate all the components in a consensus client and aims to specify their behavior when the head of the beacon chain does not yet have a verified ExecutionPayload.

Implementation requirements

If the assumptions in this document are correct, consensus clients need to make the changes along the lines of:

  1. Support importing blocks if an execution client returns SYNCING.
  2. Add a field to each node/block in ProtoArray to indicate if that block is: verified, yet-to-be-verified, invalid or irrelevent (pre-merge).
  3. Add the ability to retrospectively update blocks as verified/invalid when the execution client finally catches up.
  4. Filter out blocks with an "invalid" status from fork choice.
  5. Add the ability to loudly explode if a finalized block has an invalid ExecutionPayload.
  6. Update the API to present the verified ancestor head when the optimistic head has an unverified payload.
  7. Modify the status RPC method to present the verified ancestor head when the optimistic head has an unverified payload.
  8. Filter out unverified payloads from responses to P2P peers.

Known Issues

Resources

Select a repo