-
Notifications
You must be signed in to change notification settings - Fork 187
feat(FOCIL): EIP-7805 Test Cases #2299
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. Weβll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
1fe99ca
fbe6195
e33ef18
f685a61
3592dde
60db8d2
9980486
82531a2
ac5dee1
5f440c1
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| 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** | | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For There was a problem hiding this comment. Choose a reason for hiding this commentThe 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? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do you mean the test inputs? There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. |
||
| | `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 | | ||
PelleKrab marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| | `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 | | ||
Uh oh!
There was an error while loading. Please reload this page.