feat(FOCIL): EIP-7805 Checklist #2299
Conversation
|
Hey, just an FYI. We are about to finalize "The Weld" - moving EEST to EELS. It's best to keep this PR up here in EEST for now. We will then ask you to reopen the PR but in EELS somepoint next week. Hope that okay! More context: https://steel.ethereum.foundation/blog/blog_posts/2025-09-11_weld-announcement/ |
tests/amsterdam/eip7805_forkchoice_enforced_inclusion_lists/test_cases.md
Outdated
Show resolved
Hide resolved
tests/amsterdam/eip7805_forkchoice_enforced_inclusion_lists/test_cases.md
Show resolved
Hide resolved
tests/amsterdam/eip7805_forkchoice_enforced_inclusion_lists/test_cases.md
Outdated
Show resolved
Hide resolved
tests/amsterdam/eip7805_forkchoice_enforced_inclusion_lists/test_cases.md
Outdated
Show resolved
Hide resolved
tests/amsterdam/eip7805_forkchoice_enforced_inclusion_lists/test_cases.md
Outdated
Show resolved
Hide resolved
tests/amsterdam/eip7805_forkchoice_enforced_inclusion_lists/test_cases.md
Outdated
Show resolved
Hide resolved
tests/amsterdam/eip7805_forkchoice_enforced_inclusion_lists/test_cases.md
Outdated
Show resolved
Hide resolved
| | **Inclusion List Building** | | ||
| | `test_il_builder_creates_valid_list_from_txs` | Ensure the IL builder can build a valid `InclusionList` from the mempool. | Alice and Bob submit valid transactions to the mempool | The builder MUST produce a structurally valid `InclusionList`. The list must be properly encoded. | 🟡 Planned | | ||
| | `test_il_builder_respects_size_limit` | Ensure the IL builder does not create a list that exceeds the `MAX_BYTES_PER_INCLUSION_LIST` limit. | Provide the builder with more transactions than can fit within the size limit. | The builder MUST create an `InclusionList` that is less than or equal to the size limit. It MUST NOT produce an oversized list. | 🟡 Planned | | ||
| | **Block Validation** | |
There was a problem hiding this comment.
We could add more tests such as:
- When the gas left is insufficient to add omitted IL transactions.
- When omitted IL transactions are invalidated by other transactions in a payload. There will be multiple scenarios and we'd want to include as many as we can, especially regarding AA transactions.
There was a problem hiding this comment.
AA transactions would be interesting and make our tests very robust, if we could have exhaustive tests for AA.
…ist_txs and fixed grammar mistakes
| | `test_focil_builder_includes_valid_inclusion_list_txs` | Ensure the produced block includes all valid transactions from the provided inclusion list. | The EL is asked to build a block with an inclusion list containing several valid transactions. | The produced block MUST contain all the valid transactions from the inclusion list. | 🟡 Planned | | ||
| | `test_focil_builder_ignores_invalid_inclusion_list_transactions` | Ensure `produce_execution_payload` does not include inclusion list transactions that are invalid against the parent state. | The EL is asked to build a block with an inclusion list containing a mix of valid and invalid (e.g., bad nonce) transactions. | The produced block MUST include the valid inclusion list transactions and MUST NOT include the invalid ones. | 🟡 Planned | | ||
| | `test_focil_block_builder_handles_empty_inclusion_list` | Ensure a valid block is built when the inclusion list is empty. | The EL is asked to build a block with an empty inclusion list. | The builder MUST produce a valid block. | 🟡 Planned | | ||
| | `test_focil_builder_handles_inclusion_list_tx_becoming_invalid` | Ensure builder correctly omits an inclusion list transaction that becomes invalid due to a preceding inclusion list transaction. | The inclusion list is `[tx_A, tx_B]`. Both are from the same EOA with nonce `N`. Both are valid against the parent state. | The builder MUST include `tx_A`. `tx_B` (with nonce `N`) becomes invalid and MUST be omitted from the block. | 🟡 Planned | No newline at end of file |
There was a problem hiding this comment.
This is good. Could you add more tests that cover other cases such as both tx_A and tx_B are from the same EOA and have the right nonce (whatever their order is) but including the prior transaction makes the EOA cannot afford the latter. Also when a block is full and not all IL transactions are included. Any cases that can make this list exhaustive are good.
There was a problem hiding this comment.
I added 3 more, still trying to come up with more. Lemme know if anymore come to mind.
tests/amsterdam/eip7805_forkchoice_enforced_inclusion_lists/test_cases.md
Outdated
Show resolved
Hide resolved
tests/amsterdam/eip7805_forkchoice_enforced_inclusion_lists/test_cases.md
Outdated
Show resolved
Hide resolved
|
|
||
| | Function Name | Goal | Setup | Expectation | Status | | ||
| |---------------|------|-------|-------------|--------| | ||
| | **Inclusion list Building** | |
There was a problem hiding this comment.
When we test this, we would pass a payload and IL transactions, right? We could set up various payloads, which falls into three folds: contains all IL transactions and contains some of IL transactions and is valid/ invalid. I think some test cases in this section can be divided into subcategories of those three cases.
There was a problem hiding this comment.
For Inclusion List Building we are just testing the engine_getInclusionList functionality, but I agree we splitting the up payload IL pairs for the other test.
3 participants
🗒️ Description
Initial checklist for EIP-7805 (FOCIL) execution tests.
✅ Checklist
toxchecks to avoid unnecessary CI fails, see also Code Standards and Enabling Pre-commit Checks:uvx --with=tox-uv tox -e lint,typecheck,spellcheck,markdownlinttype(scope):.mkdocs servelocally and verified the auto-generated docs for new tests in the Test Case Reference are correctly formatted.@ported_frommarker.