-
Couldn't load subscription status.
- Fork 185
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 7 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,18 @@ | ||
| # 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 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 | | ||
PelleKrab marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
| | `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 | | ||
PelleKrab marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
| | `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 | | ||
|
||
Uh oh!
There was an error while loading. Please reload this page.