RFC: Engine API response status when merge transition block is INVALID

[mkalinin]

Problem

Merge transition block (the first PoS block in the chain) is a direct child of a terminal PoW block. Currently, Engine API spec prescribes EL to respond with {status: INVALID, latestValidHash: validAncestorHash, validationError: null | message} if transition block appears to be INVALID.

The problem is that validAncestorHash in this case should reference a terminal PoW block which isn't in CL's block tree. This makes CL client's behaviour underspecified.

Options

1. Leave the spec as it is. If transition block appears to be INVALID CL gets a response with validAncestorHash: terminalBlockHash, then it invalidates transition block and stops further traversing because the parent of transition beacon block doesn't have a payload at all (it's filled with zeroes)
2. Return INVALID_TERMINAL_BLOCK which explicitly tells CL to invalidate a subchain starting from a transition block
3. Remove INVALID_TERMINAL_BLOCK, and make EL respond with {status INVALID, latestValidHash: 0x00...00} when either terminal PoW block or transition block is INVALID. Then CL will naturally stop block tree traversing at a pre-transition block

[ajsutton]

For the merge transition block itself, I don't think this matters to Teku - as long as we get some form of INVALID response, we'll mark the transition block as INVALID and it has no ancestors with payloads so they're already all VALID and everything works out.

If the EL was syncing and we optimistically imported the transition block, we might get the INVALID response on a much later block. In that case the only thing that would get Teku to invalidate the ancestors currently would be to return latestValidHash: 0x00..00 - we don't really care if that's INVALID or INVALID_TERMINAL_BLOCK, any kind of invalid response is fine.

In option 1, Teku wouldn't be able to find the referenced validAncestorHash so would only invalidate the head block and would have to gradually walk it's way back up the chain until we reach the transition block or we invalidate enough attestations that we'd wind up re-orging to a different fork.

In option 2 we'd have to add special case handling to fork choice to find and invalidate the transition block. We currently simplify all the EL responses down to one of VALID, INVALID or SYNCING and this would then require us to pass through INVALID_TERMINAL_BLOCK as well which increases complexity.

Option 3 works well because specifying latestValidHash: 0x00...00 is quite a neat way of indicating that the last valid block is prior to the transition block. Seems to me it could be either INVALID_TERMINAL_BLOCK or INVALID in terms of semantics but not sure if that fits with the way the spec works.

[mkalinin]

Option 3 has been merged into the spec #217