Skip to content
Original file line number Diff line number Diff line change
@@ -0,0 +1,20 @@
# EIP-7805 FOCIL Test Cases

| Function Name | Goal | Setup | Expectation | Status |
|---------------|------|-------|-------------|--------|
| **Inclusion list Building** |

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should these pairs be speced out in this document or do you think a separate md could be useful?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mean the test inputs?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, the payloads. We could define them more indepth in checklist, a separate md, or just in the python test.

Copy link

@jihoonsong jihoonsong Oct 22, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could use pytest to parameterize it. For example, this test has 8 inputs (or variants in the context of their website.)

For pytest, you could refer to this one.

Thanks @raxhvl for sharing knowledge πŸ‘

| `test_focil_inclusion_list_committee_member_respects_size_limit` | Ensure the inclusion list committee member does not create a list that exceeds the `MAX_BYTES_PER_INCLUSION_LIST` limit. | Provide the committee member with more transactions than can fit within the size limit. | The builder MUST create an inclusion list that is less than or equal to the size limit. It MUST NOT produce an oversized list. | 🟑 Planned |
| **Block Inclusion List Validation** |
| `test_focil_block_validation_accepts_empty_inclusion_list` | Verify the EL correctly validates a payload with zero `inclusionListTransactions`. | The EL receives a payload and zero `inclusionListTransactions`. | The payload MUST be considered valid. | 🟑 Planned |
| `test_focil_block_validation_accepts_full_inclusion_list` | Verify the EL validates a payload correctly includes the maximum number of `inclusionListTransactions`. | The EL receives a payload and `inclusionListTransactions` whose size is equals `MAX_BYTES_PER_INCLUSION_LIST` * inclusion list committee size limit. | The payload MUST include all transactions. | 🟑 Planned |
| `test_focil_block_validation_ignores_invalid_transactions_in_inclusion_list` | Ensure the EL validates a block that correctly omits invalid transactions found in the `inclusionListTransactions`. | The EL receives a payload and `inclusionListTransactions` which contains invalid transactions (intrinsically invalid, bad nonce, sender cannot afford the gas, bad encoding, eip-4844 transactions, etc.). | These invalid transactions MUST *not* be included in the block body. | 🟑 Planned |
| `test_focil_block_validation_returns_error_when_inclusion_list_tx_is_omitted` | Verify block validation returns `INCLUSION_LIST_UNSATISFIED` if it omits a transaction that is valid against the current state and referenced by corresponding `inclusionListTransactions` for that slot. | The `inclusionListTransactions` references a transaction valid against the current state, but the block body omits it. | The EL MUST return an `INCLUSION_LIST_UNSATISFIED` error. | 🟑 Planned |
| `test_focil_block_validation_succeeds_with_interdependent_inclusion_list_transactions` | Verify that the EL correctly processes `inclusionListTransactions` that contain transactions where later ones depend on earlier ones. | Inclusion list is `[tx_A, tx_B]`. `tx_A` funds a new account. `tx_B` is a transaction sent from that new account. | Both transactions MUST be included. | 🟑 Planned |
| `test_focil_block_validation_accepts_two_independent_inclusion_list_transactions` | Verify the EL validates a payload correctly including transactions from `inclusionListTransactions` with two transactions. | The EL receives a payload and `inclusionListTransactions` containing two independent valid transactions. | The payload MUST include both transactions, order is irrelevant. | 🟑 Planned |
| **Block Building** |
| `test_focil_builder_includes_valid_inclusion_list_transactions` | Ensure the produced block includes all valid transactions from the provided `inclusionListTransactions`. | The EL is asked to build a block with `inclusionListTransactions` containing several valid transactions. | The produced block MUST contain all the valid transactions from the `inclusionListTransactions`. | 🟑 Planned |
| `test_focil_builder_ignores_invalid_inclusion_list_transactions` | Ensure `produce_execution_payload` does not include `inclusionListTransactions` 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 `inclusionListTransactions` and MUST NOT include the invalid ones. | 🟑 Planned |
| `test_focil_block_builder_handles_empty_inclusion_list` | Ensure a valid block is built with zero `inclusionListTransactions`. | The EL is asked to build a block with zero `inclusionListTransactions`. | 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 `inclusionListTransactions` are `[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` or `tx_B` (with nonce `N`). The transaction that is not included becomes invalid and MUST be omitted from the block. | 🟑 Planned |
| `test_focil_builder_handles_same_sender_insufficient_funds_after_first_tx` | Ensure builder correctly omits a transaction that becomes unaffordable after a preceding transaction from the same sender executes. | The `inclusionListTransactions` are `[tx_A, tx_B]`. Both are from the same EOA with sequential nonces (0, 1). Both valid against parent state. `tx_A` transfers most funds away, leaving insufficient balance for `tx_B`'s gas. | The builder MUST include `tx_A`. `tx_B` becomes unaffordable after `tx_A` and MUST be omitted from the block. | 🟑 Planned |
| `test_focil_builder_handles_full_block_with_partial_inclusion_list` | Ensure builder correctly handles when block gas limit is reached and not all `inclusionListTransactions` can fit. | The `inclusionListTransactions` contain valid independent transactions whose total gas exceeds the block gas limit. | The builder MUST include as many transactions from `inclusionListTransactions` as fit within the block gas limit. Remaining transactions are omitted (block full). | 🟑 Planned |