-
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 4 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,17 @@ | ||
| # EIP-7805 FOCIL Test Cases | ||
|
|
||
| | Function Name | Goal | Setup | Expectation | Status | | ||
| |---------------|------|-------|-------------|--------| | ||
| | **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 | | ||
PelleKrab marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
| | `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** | | ||
|
||
| | `test_block_validation_accepts_empty_il` | Verify the EL correctly validates a payload with an empty Inclusion List. | The EL receives a payload with an empty `inclusion_list`. | The payload MUST be considered valid. | π‘ Planned | | ||
PelleKrab marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
PelleKrab marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
| | `test_block_validation_accepts_full_il` | Verify the EL validates a payload correctly including transactions from a maximally sized IL. | The EL receives a payload with an `inclusion_list` filled to the `MAX_BYTES_PER_INCLUSION_LIST` * Inclusion List Committee Size limit. All valid IL txs are included. | The payload MUST be considered valid. | π‘ Planned | | ||
| | `test_block_validation_ignores_invalid_txs_in_il` | Ensure the EL validates a block that correctly omits invalid transactions found in the IL. | The EL receives a payload where the IL contains entries with invalid transactions (bad nonce, etc.). These are correctly *not* included in the block body. | The payload MUST be considered valid. | π‘ Planned | | ||
PelleKrab marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
| | `test_block_validation_fails_if_valid_il_tx_is_omitted` | Verify a block is invalid if it fails to include a valid transaction from the IL. | A payload's IL contains a transaction that is valid against the parent block's state. The block body, however, omits this transaction. | The block MUST be rejected as invalid. | π‘ Planned | | ||
PelleKrab marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
| | `test_block_validation_succeeds_with_interdependent_il_txs` | Verify a block is valid when it includes a sequence of IL txs where later ones depend on earlier ones. | IL is `[tx_A, tx_B]`. `tx_A` funds a new account. `tx_B` is a transaction sent from that new account. Both are included in the correct order. | The block MUST be considered valid. | π‘ Planned | | ||
PelleKrab marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
| | **Block Building** | | ||
| | `test_builder_includes_valid_il_txs` | Ensure the produced block includes all valid transactions from the provided Inclusion List. | The EL is asked to build a block with an IL containing several valid transactions. The mempool also has transactions. | The produced block's transaction list MUST contain all the valid transactions from the IL. | π‘ Planned || `test_builder_ignores_invalid_il_txs` | Ensure `produce_execution_payload` does not include IL transactions that are invalid against the parent state. | The EL is asked to build a block with an IL containing a mix of valid and invalid (e.g., bad nonce) transactions. | The produced block MUST include the valid IL transactions in the prefix and MUST NOT include the invalid ones. | π‘ Planned | | ||
| | `test_builder_handles_empty_il` | Ensure a correct block is built when the IL is empty. | The EL is asked to build a block with an empty IL. | The builder MUST produce a valid block. | π‘ Planned | | ||
| | `test_builder_handles_il_tx_becoming_invalid` | Ensure builder correctly omits an IL transaction that becomes invalid due to a preceding IL transaction. | The IL 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.