Add initial FOCIL spec

[jihoonsong]

This PR adds initial FOCIL spec. It mainly adds three new methods.

i) engine_newPayloadV5
engine_newPayloadV5 is introduced as engine_newPayloadV4 will be shipped in Prague. engine_newPayloadV5 takes an inclusion list (IL) as a parameter and verifies if the payload satisfies the IL constraints. (For the IL constraints, please refer to Execution Layer section in EIP-7805.)

As IL isn't recorded onchain, it cannot be enforced during syncing. Currently, this spec adopts a naive approach: CL passes IL only when not syncing and EL enforces the IL constraints only if the given IL is not null. We're looking for feedback on whether there is a better approach such as using a sync complete flag.

ii) engine_getInclusionListV1
EL must provide an IL when engine_getInclusionListV1 is called. FOCIL as in EIP-7805 does not dictate IL construction algorithm and expects that having diverse approaches would help foster censorship resistance.

iii) engine_updatePayloadWithInclusionListV1
A proposer should listen to all ILs submitted by IL committee members and apply the aggregated IL to its payload before proposing a block. There are two ways to achieve this.

a) use engine_forkchoiceUpdated
We can add the IL field to payloadAttributes and call forkchoiceUpdated initially with a null IL field at the start of a slot, then call it again with the actual IL once it’s ready.

This will require modifying FCU to allow updates to an ongoing payload building process. If I’m not mistaken, geth and reth currently early return a valid response without updating the existing payload building process.

b) add a new Engine API
The second option is adding a new Engine API. We welcome feedback on better ways of applying IL.

We’re in the early stages of FOCIL implementation and would appreciate your feedback. Thank you.

[ensi321]

I think there once was an experimental folder for your purpose but was later removed because the folder is empty.

You can refer to #340 to see how eip6110.md is placed.

[jihoonsong]

Moved EIP-7805 spec under the experimental folder. Thank you for your review and providing the reference! @ensi321

[jihoonsong]

I think engine_updatePayloadWithInclusionListV1 should check if current timestamp is equal or later than eip7805 timestamp. As this is a draft, I'll leave this as a comment and would encourage people to revisit this after more core devs onboard.

[GrapeBaBa]

Will engine_newPayloadV5 change to engine_newPayloadV4 since engine_newPayloadV4 was not shipped in Prague?

[mkalinin]

We can introduce a response object like it is done in the forkchoiceUpdated case. Should we extend inclusion list with some meta information in the future, it will be smoother with an object in response

[jihoonsong]

We had object for that purpose but removed it as it makes the caller's job easier. I want to ask @terencechain's opinion on this. Relevant discussion here.

[jihoonsong]

There are some potential changes in queue and I'd like to share them here. They're queued because we want to make big changes altogether as we already have +5 clients implemented. Being SFI'd could be a good signal to make such changes.

1. Add the error code to engine_getInclusionListV1.
   We need to add the error code indicating when a block with parent_hash is not found.

2. Add PayloadStatusV2 with INVALID_INCLUSION_LIST status enum appended to engine_newPayload.
   Currently the client prototypes just piggy-backsPayloadStatusV1 and uses INVALID_INCLUSION_LIST, but technically this is not part of the spec.

3. Replace engine_updatePayloadWithInclusionListV1 with engine_forkchoiceUpdatedV4.
   I've gathered feedback on this from quite many people. The bottom line was that it's semantically better to use forkchoiceUpdated because ILs are part of payload building process and it seems there is no rough consensus on objection to overloading forkchoice attribute.

[mkalinin]

I’d suggest we use a different name than INVALID_INCLUSION_LIST. This is because INVALID_ prefix usually means that the payload or its part is invalid (e.g. an already deprecated INVALID_BLOCK_HASH status)

[jihoonsong]

Reflected the changes in the queue. Here is a change log:

• Add the error code to engine_getInclusionListV1.
  • -38006: Unknown parent error is added and will be returned when a block with the given parentHash does not exist.
  • Note that this would be removed if we decide to not pass parentHash in the future.
• Add INCLUSION_LIST_UNSATISFIED enum value to status field of PayloadStatusV1.
  • Since the return value has the same structure of PayloadStatusV1, it seems adding new enum value is better approach similar to that of engine_newPayloadV2.
  • The value is renamed to INCLUSION_LIST_UNSATISFIED following @mkalinin's feedback.
• Replace engine_updatePayloadWithInclusionListV1 with engine_forkchoiceUpdatedV4.
• Rename inclusionList to inclusionListTransactions.
  • This is just stylistic reason to make it in line with other specs, i.e., the CL and the EL specs.

Note: the fork check using timestamp is not specified. It should be specified once this merges into some canonical fork.

[ensi321]

Why don't we define PayloadStatusV2?

[jihoonsong]

We add one enum value without changing its structure and it seems the spec doesn't add another version in such cases. It's not a strong opinion though. Should we define PayloadStatusV2?

[mkalinin]

Currently, the spec doesn’t require to bump a version in this case, see here for all cases where the version change is required — we can definitely extend this list if we find it reasonable. But I am personally leaning towards not adding a new version in this particular case as the change doesn’t affect the layout of the PayloadStatus