Optimistic Sync: HTTP API

Overview

The optimistic sync specification declares:

Consensus engines which provide an implementation of the Ethereum Beacon
APIs must take care to avoid presenting optimistic blocks as fully-verified blocks.

It achieves this by returning "503 syncing" for practically all endpoints that might ever return optimistic data, including the eth/*/validator/* endpoints. This prevents a VC from following the duties of an optimistic head. This document investigates that side-effect.

Validator Client Considerations

The "503 syncing" errors mean that a validator client (VC) cannot follow the duties for an optimistic head. Whilst it should never sign messages about an optimistic chain, there are arguments that a VC should able to (silently) follow the duties of an optimistic head, beacuse:

1. It ensures that VCs are ready to attest/produce immediately after an optimistic head becomes verified. This reduces downtime for individual validators and helps promote stability in the network during heavy forking.
2. It might be less impactful on VC implementations, since it still allows duties polling, head updates and subscriptions to work regardless of opt sync.

Full-Verification or Optimistic-Verification

Presently, the status quo for opt sync is "don't serve optimisitic info on the HTTP API". However, that conflicts with the ability to serve duties about an optimistic head to a VC.

So, it appears there are two ways to handle the API in an optimistic node:

• Full-Verification: don't return information about optimistic chains
  • Pro: Ensures the API always returns fully valid info.
  • Con: Strictly full verification will not allow validators to follow optimistic duties.
• Optimistic-Verification: return information about optimistic chains
  • Pro: VCs can follow duties of an optimistic head
  • Con: May sometimes return information about chains with invalid payloads (but won't allow building on them or attesting to them).

Which one? I'm looking for feedback

Image Not Showing Possible Reasons

• The image file may be corrupted
• The server hosting the image is unavailable
• The image path is incorrect
• The image format is not supported

Learn More →

In a Lighthouse issue, I enumerated all the endpoints and defined how they might be modified to achieve a sort-of hybrid between full/optimistic.

I'm interested to hear thoughts from API consumers and other "stakeholders" via the #merge-general channel on the Eth R&D Discord.