Skip to content
Original file line number Diff line number Diff line change
@@ -0,0 +1,18 @@
# 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 an empty inclusion list. | The EL receives a payload and an empty inclusion list. | The payload MUST be considered valid. | 🟑 Planned |
| `test_focil_block_validation_accepts_full_inclusion_list` | Verify the EL validates a payload correctly including transactions from a maximally sized inclusion list. | The EL receives a payload and an inclusion list filled of size `MAX_BYTES_PER_INCLUSION_LIST` * inclusion list committee size limit. | The payload MUST include all transactions. | 🟑 Planned |
| `test_focil_block_validation_ignores_invalid_txs_in_inclusion_list` | Ensure the EL validates a block that correctly omits invalid transactions found in the inclusion list. | The EL receives a payload and an inclusion list which contains entries with 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_reorgs_if_valid_inclusion_list_tx_is_omitted` | Verify a block is reorged if it omits a transaction that is valid against the current state and referenced by corresponding inclusion list for that slot. | The inclusion list references a transaction valid against the current state, but the block body omits it. | The block MUST be reorged. | 🟑 Planned |
| `test_focil_block_validation_succeeds_with_interdependent_inclusion_list_txs` | Verify that the EL correctly processes an inclusion list that contains 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_txs` | Verify the EL validates a payload correctly including transactions from an inclusion list with two transactions. | The EL receives a payload and an inclusion list containing two independent valid transactions. | The payload MUST include both transactions, order is irrelevant. | 🟑 Planned |
| **Block Building** |
| `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 |

Choose a reason for hiding this comment

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

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.

Copy link
Author

Choose a reason for hiding this comment

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

I added 3 more, still trying to come up with more. Lemme know if anymore come to mind.