Retrospective transition block checking

[paulhauner]

Description

The "transition block" is the first block in a chain that includes a non-empty ExecutionPayload. This is effectively the first merging of the proof-of-work chain into the proof-of-stake chain.

This block requires some additional verification when compared to pre- and post-transition blocks; the consensus client must check that the PoW chain has reached the terminal total difficulty and/or some other criteria.

These additional verifications are challenging during optimistic sync. We can't perform them during sync, since the execution client might not be synced enough to respond to the requests. So, we optimistically accept the transition block and promise to come back later and check it once the execution client is synced.

Presently, Lighthouse happily optimistically accepts the transition block, but it fulfills the promise to verify it. Therefore, Lighthouse needs:

• A way to cache optimistic transition blocks as we come across them during sync.
  • This cache must persist across reboots, so it needs to be saved to the DB.
• A way to know that the EL is synced and it's therefore time to check all the blocks in the cache.
• Interaction with [Merged by Bors] - Retrospective invalidation of exec. payloads for opt. sync #2837 to invalidate any blocks where the tranisition fails the retrospective check (talk to @paulhauner)

[ethDreamer]

I ran into some related stuff when working on the engine-api upgrade so I'm going to put all the block conditions here:

• eth2 spec transition block validation conditions
• EIP-3675 transition block validation conditions (EE side)
• Invalid transition block response from EE (see #2)

You'll notice there's a new status INVALID_TERMINAL_BLOCK in the response to newPayloadV1 (formally executePayloadV1) from the execution engine.. not sure how that changes what you've discussed here @paulhauner

[paulhauner]

You'll notice there's a new status INVALID_TERMINAL_BLOCK in the response to newPayloadV1 (formally executePayloadV1) from the execution engine.. not sure how that changes what you've discussed here @paulhauner

I don't think that changes anything here, thanks for pointing it out though.

[paulhauner]

I'm thinking that perhaps we want logic along the lines of this:

1. Whenever a transition block is optimistically imported, insert it into an "optimistic transition blocks" (OTB) column in the database.
2. Periodically run a routine that:
   1. Loads all blocks roots from the OTB column.
   2. Removes any blocks from the OTB column that conflict with the finalized checkpoint.
   3. For remaining OTB block roots that are finalized, check them against the EL and kill the client if they're invalid.
   4. For remaining OTB blocks that are not-yet-finalized, run BeaconChain::process_invalid_execution_payload for any invalid blocks.
   5. For any blocks that are found to be valid, remove them from the OTB table.

[paulhauner]

Resolved via #3372 🎉