eth2.0-specs/tests/formats/operations/README.md

61 lines
4.1 KiB
Markdown
Raw Normal View History

2019-04-12 12:19:10 +00:00
# Operations tests
The different kinds of operations ("transactions") are tested individually with test handlers.
2019-05-23 09:22:10 +00:00
## Test case format
2019-04-12 12:19:10 +00:00
### `meta.yaml`
2019-05-23 09:22:10 +00:00
```yaml
description: string -- Optional description of test case, purely for debugging purposes.
Tests should use the directory name of the test case as identifier, not the description.
bls_setting: int -- see general test-format spec.
2019-05-23 09:22:10 +00:00
```
2020-10-08 19:02:18 +00:00
### `pre.ssz_snappy`
2021-03-13 04:42:51 +00:00
An SSZ-snappy encoded `BeaconState`, the state before applying the operation.
2020-10-08 19:02:18 +00:00
### `<input-name>.ssz_snappy`
2021-03-13 04:42:51 +00:00
An SSZ-snappy encoded operation object, e.g. a `ProposerSlashing`, or `Deposit`.
2020-10-08 19:02:18 +00:00
### `post.ssz_snappy`
2021-03-13 04:42:51 +00:00
An SSZ-snappy encoded `BeaconState`, the state after applying the operation. No value if operation processing is aborted.
2019-05-23 09:22:10 +00:00
## Condition
2019-06-10 20:16:51 +00:00
A handler of the `operations` test-runner should process these cases,
2019-05-23 09:22:10 +00:00
calling the corresponding processing implementation.
This excludes the other parts of the block-transition.
2019-05-23 09:22:10 +00:00
Operations:
| *`operation-name`* | *`operation-object`* | *`input name`* | *`processing call`* |
|---------------------------|------------------------------|---------------------|----------------------------------------------------------------------------------|
| `attestation` | `Attestation` | `attestation` | `process_attestation(state, attestation)` |
| `attester_slashing` | `AttesterSlashing` | `attester_slashing` | `process_attester_slashing(state, attester_slashing)` |
| `block_header` | `BeaconBlock` | **`block`** | `process_block_header(state, block)` |
| `deposit` | `Deposit` | `deposit` | `process_deposit(state, deposit)` |
| `proposer_slashing` | `ProposerSlashing` | `proposer_slashing` | `process_proposer_slashing(state, proposer_slashing)` |
| `voluntary_exit` | `SignedVoluntaryExit` | `voluntary_exit` | `process_voluntary_exit(state, voluntary_exit)` |
| `sync_aggregate` | `SyncAggregate` | `sync_aggregate` | `process_sync_aggregate(state, sync_aggregate)` (new in Altair) |
2023-05-16 15:58:01 +00:00
| `execution_payload` | `BeaconBlockBody` | **`body`** | `process_execution_payload(state, body)` (new in Bellatrix) |
| `withdrawals` | `ExecutionPayload` | `execution_payload` | `process_withdrawals(state, execution_payload)` (new in Capella) |
| `bls_to_execution_change` | `SignedBLSToExecutionChange` | `address_change` | `process_bls_to_execution_change(state, address_change)` (new in Capella) |
| `deposit_request` | `DepositRequest` | `deposit_request` | `process_deposit_request(state, deposit_request)` (new in Electra) |
| `withdrawal_request` | `WithdrawalRequest` | `withdrawal_request` | `process_withdrawal_request(state, withdrawal_request)` (new in Electra) |
2024-05-31 11:50:59 +00:00
| `execution_layer_consolidation_request` | `ExecutionLayerConsolidationRequest` | `execution_layer_consolidation_request` | `process_execution_layer_consolidation_request(state, execution_layer_consolidation_request)` (new in Electra) |
2019-05-23 09:22:10 +00:00
2019-06-10 20:20:45 +00:00
Note that `block_header` is not strictly an operation (and is a full `Block`), but processed in the same manner, and hence included here.
2019-05-23 09:22:10 +00:00
2021-05-04 22:37:00 +00:00
The `execution_payload` processing normally requires a `verify_execution_state_transition(execution_payload)`,
a responsibility of an (external) execution engine.
During testing this execution is mocked, an `execution.yml` is provided instead:
a dict containing an `execution_valid` boolean field with the verification result.
2019-05-23 09:22:10 +00:00
The resulting state should match the expected `post` state, or if the `post` state is left blank,
the handler should reject the input operation as invalid.