Add initial FOCIL spec

[jihoonsong]

This PR adds the engine APIs FOCIL spec on Bogota fork. It mainly adds or modifies three new methods.

i) engine_newPayloadV6
engine_newPayloadV6 takes an inclusion list (IL) as an additional parameter and verifies if the payload satisfies the IL constraints. (For the IL constraints, please refer to Execution Layer section in EIP-7805.)

ii) engine_getInclusionListV1
EL must provide an IL (a list of transactions) when engine_getInclusionListV1 is called. FOCIL as in EIP-7805 does not dictate IL building algorithm and expects the diversity would foster censorship resistance.

iii) engine_forkchoiceUpdatedV5

A proposer should listen to all ILs submitted by IL committee members and apply the aggregated IL to its payload before proposing a block. We 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.

[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

[jihoonsong]

I've revamped and rebased this PR to Bogotá fork. I'd like to get feedback on getInclusionList. getInclusionList doesn't have a timestamp to tell whether it's called after Bogotá fork transition, unlike newPayload, getPayload and forkchoiceUpdated. I can think of three options:

1. Add timestamp as a second parameter.
2. Similar to getBlobsV1 deprecation specification in Osaka, specify to return -38005: Unsupported fork if the Bogotá fork is not activated.
3. Do nothing and just trust CL.