diff --git a/docs/.hugo_build.lock b/docs/.hugo_build.lock new file mode 100644 index 00000000000..e69de29bb2d diff --git a/docs/archetypes/default.md b/docs/archetypes/default.md new file mode 100644 index 00000000000..c6f3fcef6e3 --- /dev/null +++ b/docs/archetypes/default.md @@ -0,0 +1,5 @@ ++++ +title = '{{ replace .File.ContentBaseName "-" " " | title }}' +date = {{ .Date }} +draft = true ++++ diff --git a/docs/CHANGELOG.md b/docs/content/main/CHANGELOG.md similarity index 98% rename from docs/CHANGELOG.md rename to docs/content/main/CHANGELOG.md index b7b298173ee..41d87fe4b34 100644 --- a/docs/CHANGELOG.md +++ b/docs/content/main/CHANGELOG.md @@ -1,4 +1,13 @@ -# Changelog ++++ +title = 'Changelog' +date = 2025-07-09T12:42:33Z +draft = false +[menu] + [menu.main] + name = 'Changelog' + weight = 30 + ++++ Test fixtures for use by clients are available for each release on the [Github releases page](https://github.com/ethereum/execution-spec-tests/releases). @@ -22,8 +31,6 @@ The output behavior of `fill` has changed ([#1608](https://github.com/ethereum/e - Before: `fill` wrote fixtures into the directory specified by the `--output` flag (default: `fixtures`). This could have many unintended consequences, including unexpected errors if old or invalid fixtures existed in the directory (for details see [#1030](https://github.com/ethereum/execution-spec-tests/issues/1030)). - Now: `fill` will exit without filling any tests if the specified directory exists and is not-empty. This may be overridden by adding the `--clean` flag, which will first remove the specified directory. -Additionally, writing debugging information to the EVM "dump directory" by default has been disabled. To obtain debug output, the `--evm-dump-dir` flag must now be explicitly set. As a consequence, the now redundant `--skip-evm-dump` option was removed ([#1874](https://github.com/ethereum/execution-spec-tests/pull/1874)). This undoes functionality originally introduced in [#999](https://github.com/ethereum/execution-spec-tests/pull/999) and [#1150](https://github.com/ethereum/execution-spec-tests/pull/1150). - #### Feature `zkevm` updated to `benchmark` Due to the crossover between `zkevm` and `benchmark` tests, all instances of the former have been replaced with the latter nomenclature. Repository PR labels and titles are additionally updated to reflect this change. @@ -51,7 +58,6 @@ Users can select any of the artifacts depending on their testing needs for their - 🐞 `zkevm` marked tests have been removed from `tests-deployed` tox environment into its own separate workflow `tests-deployed-zkevm` and are filled by `evmone-t8n` ([#1617](https://github.com/ethereum/execution-spec-tests/pull/1617)). - ✨ Field `postStateHash` is now added to all `blockchain_test` and `blockchain_test_engine` tests that use `exclude_full_post_state_in_output` in place of `postState`. Fixes `evmone-blockchaintest` test consumption and indirectly fixes coverage runs for these tests ([#1667](https://github.com/ethereum/execution-spec-tests/pull/1667)). - πŸ”€ Changed INVALID_DEPOSIT_EVENT_LAYOUT to a BlockException instead of a TransactionException ([#1773](https://github.com/ethereum/execution-spec-tests/pull/1773)). -- πŸ”€ Disabled writing debugging information to the EVM "dump directory" to improve performance. To obtain debug output, the `--evm-dump-dir` flag must now be explicitly set. As a consequence, the now redundant `--skip-evm-dump` option was removed ([#1874](https://github.com/ethereum/execution-spec-tests/pull/1874)). #### `consume` @@ -64,7 +70,6 @@ Users can select any of the artifacts depending on their testing needs for their - ✨ Added new `Blob` class which can use the ckzg library to generate valid blobs at runtime ([#1614](https://github.com/ethereum/execution-spec-tests/pull/1614)). - ✨ Added `blob_transaction_test` execute test spec, which allows tests that send blob transactions to a running client and verifying its `engine_getBlobsVX` endpoint behavior ([#1644](https://github.com/ethereum/execution-spec-tests/pull/1644)). -- ✨ Added `execute eth-config` command to test the `eth_config` RPC endpoint of a client, and includes configurations by default for Mainnet, Sepolia, Holesky, and Hoodi ([#1863](https://github.com/ethereum/execution-spec-tests/pull/1863)). ### πŸ“‹ Misc @@ -92,7 +97,6 @@ Users can select any of the artifacts depending on their testing needs for their - πŸ”€ Add fixture comparison check to optimize coverage workflow in CI ([#1833](https://github.com/ethereum/execution-spec-tests/pull/1833)). - πŸ”€ Move `TransactionType` enum from test file to proper module location in `ethereum_test_types.transaction_types` for better code organization and reusability ([#1763](https://github.com/ethereum/execution-spec-tests/pull/1673)). - ✨ Opcode classes now validate keyword arguments and raise `ValueError` with clear error messages ([#1739](https://github.com/ethereum/execution-spec-tests/pull/1739), [#1856](https://github.com/ethereum/execution-spec-tests/pull/1856)). -- ✨ All commands (`fill`, `consume`, `execute`) now work without having to clone the repository, e.g. `uv run --with git+https://github.com/ethereum/execution-spec-tests.git consume` now works from any folder ([#1863](https://github.com/ethereum/execution-spec-tests/pull/1863)). ### πŸ§ͺ Test Cases @@ -101,13 +105,17 @@ Users can select any of the artifacts depending on their testing needs for their - ✨ EIP-7594: Sanity test cases to send blob transactions and verify `engine_getBlobsVX` using the `execute` command ([#1644](https://github.com/ethereum/execution-spec-tests/pull/1644)). - πŸ”€ Refactored EIP-145 static tests into python ([#1683](https://github.com/ethereum/execution-spec-tests/pull/1683)). - ✨ EIP-7823, EIP-7883: Add test cases for ModExp precompile gas-cost updates and input limits on Osaka ([#1579](https://github.com/ethereum/execution-spec-tests/pull/1579), [#1729](https://github.com/ethereum/execution-spec-tests/pull/1729)). -- ✨ [EIP-7825](https://eips.ethereum.org/EIPS/eip-7825): Add test cases for the transaction gas limit of 2^24 gas ([#1711](https://github.com/ethereum/execution-spec-tests/pull/1711), [#1882](https://github.com/ethereum/execution-spec-tests/pull/1882)). +- ✨ [EIP-7825](https://eips.ethereum.org/EIPS/eip-7825): Add test cases for the transaction gas limit of 30M gas ([#1711](https://github.com/ethereum/execution-spec-tests/pull/1711)). - ✨ [EIP-7951](https://eips.ethereum.org/EIPS/eip-7951): add test cases for `P256VERIFY` precompile to support secp256r1 curve [#1670](https://github.com/ethereum/execution-spec-tests/pull/1670). - ✨ Introduce blockchain tests for benchmark to cover the scenario of pure ether transfers [#1742](https://github.com/ethereum/execution-spec-tests/pull/1742). - ✨ [EIP-7934](https://eips.ethereum.org/EIPS/eip-7934): Add test cases for the block RLP max limit of 10MiB ([#1730](https://github.com/ethereum/execution-spec-tests/pull/1730)). - ✨ [EIP-7939](https://eips.ethereum.org/EIPS/eip-7939) Add count leading zeros (CLZ) opcode tests for Osaka ([#1733](https://github.com/ethereum/execution-spec-tests/pull/1733)). - ✨ [EIP-7918](https://eips.ethereum.org/EIPS/eip-7918): Blob base fee bounded by execution cost test cases (initial), includes some adjustments to [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) tests ([#1685](https://github.com/ethereum/execution-spec-tests/pull/1685)). +
+ +--- + ## [v4.5.0](https://github.com/ethereum/execution-spec-tests/releases/tag/v4.5.0) - 2025-05-14 ### πŸ’₯ Breaking Change @@ -138,6 +146,10 @@ A new fork `EOFv1` has additionally been created to fill and consume EOF related - πŸ”€ Automatically apply the `benchmark` marker to all tests under `./tests/benchmark/` and `./tests/prague/eip2537_bls_12_381_precompiles/` via conftest configuration ([#1534](https://github.com/ethereum/execution-spec-tests/pull/1534)). - ✨ Port [calldataload](https://github.com/ethereum/tests/blob/ae4791077e8fcf716136e70fe8392f1a1f1495fb/src/GeneralStateTestsFiller/VMTests/vmTests/calldatacopyFiller.yml) and [calldatasize](https://github.com/ethereum/tests/blob/81862e4848585a438d64f911a19b3825f0f4cd95/src/GeneralStateTestsFiller/VMTests/vmTests/calldatasizeFiller.yml) tests ([#1236](https://github.com/ethereum/execution-spec-tests/pull/1236)). +
+ +--- + ## [v4.4.0](https://github.com/ethereum/execution-spec-tests/releases/tag/v4.4.0) - 2025-04-29 ### πŸ’₯ Breaking Change @@ -178,6 +190,10 @@ Includes tests that are tailored specifically to test the execution layer proof - ✨ Add all [`GeneralStateTests` from `ethereum/tests`](https://github.com/ethereum/tests/tree/7dc757ec132e372b6178a016b91f4c639f366c02/src/GeneralStateTestsFiller) to `execution-spec-tests` located now at [tests/static/state_tests](https://github.com/ethereum/execution-spec-tests/tree/main/tests/static/state_tests) ([#1442](https://github.com/ethereum/execution-spec-tests/pull/1442)). - ✨ [EIP-2929](https://eips.ethereum.org/EIPS/eip-2929): Test that precompile addresses are cold/warm depending on the fork they are activated ([#1495](https://github.com/ethereum/execution-spec-tests/pull/1495)). +
+ +--- + ## [v4.3.0](https://github.com/ethereum/execution-spec-tests/releases/tag/v4.3.0) - 2025-04-18 ### πŸ’₯ Breaking Change @@ -235,6 +251,10 @@ This feature can be disabled by using `--disable-strict-exception-matching` for - 🐞 Configure `markdownlint` to expect an indent of 4 with unordered lists (otherwise HTML documentation is rendered incorrectly, [#1460](https://github.com/ethereum/execution-spec-tests/pull/1460)). - πŸ”€ Update `eels_resolutions.json` to point to temporary commit `bb0eb750d643ced0ebf5dec732cdd23558d0b7f2`, which is based on `forks/prague` branch, commit `d9a7ee24db359aacecd636349b4f3ac95a4a6e71`, with PRs , and merged ([#1394](https://github.com/ethereum/execution-spec-tests/pull/1394)). +
+ +--- + ## [v4.2.0](https://github.com/ethereum/execution-spec-tests/releases/tag/v4.2.0) - 2025-04-08 **Note**: Although not a breaking change, `consume` users should delete the cache directory (typically located at `~/.cache/ethereum-execution-spec-tests`) used to store downloaded fixture release tarballs. This release adds support for [ethereum/tests](https://github.com/ethereum/tests) and [ethereum/legacytests](https://github.com/ethereum/legacytests) fixture release downloads and the structure of the cache directory has been updated to accommodate this change. @@ -301,6 +321,10 @@ consume cache --help - ✨ Add more tests for EIP-7702: max-fee-per-gas verification, delegation-designation as initcode tests ([#1372](https://github.com/ethereum/execution-spec-tests/pull/1372)). - ✨ Add converted Identity precompile tests ([#1344](https://github.com/ethereum/execution-spec-tests/pull/1344)). +
+ +--- + ## [v4.1.0](https://github.com/ethereum/execution-spec-tests/releases/tag/v4.1.0) - 2025-03-11 ### πŸ’₯ Breaking Changes @@ -341,6 +365,10 @@ The following changes may be potentially breaking (all clients were tested with - ✨ Add EIP-7685 and EIP-7002 test cases for additional request type combinations and modified withdrawal contract that allows more withdrawals ([#1340](https://github.com/ethereum/execution-spec-tests/pull/1340)). - ✨ Add test cases for EIP-152 Blake2 and Identity precompiles ([#1244](https://github.com/ethereum/execution-spec-tests/pull/1244)). +
+ +--- + ## [v4.0.0](https://github.com/ethereum/execution-spec-tests/releases/tag/v4.0.0) - 2025-02-14 - πŸ’• ### πŸ“ Fixture Releases @@ -553,6 +581,10 @@ The following changes may be potentially breaking (all clients were tested with - ✨ Add tests for multiple EOF type sections ([#1195](https://github.com/ethereum/execution-spec-tests/pull/1195)). - ✨ Add EIP-7698 legacy EOF creation prevention tests ([#1206](https://github.com/ethereum/execution-spec-tests/pull/1206)). +
+ +--- + ## [v3.0.0](https://github.com/ethereum/execution-spec-tests/releases/tag/v3.0.0) - 2024-07-22 ### πŸ§ͺ Test Cases @@ -627,6 +659,10 @@ The following changes may be potentially breaking (all clients were tested with - The "Blockchain Test Hive" fixture format has been renamed to "Blockchain Test Engine" and updated to more closely resemble the `engine_newPayload` format in the `execution-apis` specification () and now contains a single `"params"` field instead of multiple fields for each parameter ([#687](https://github.com/ethereum/execution-spec-tests/pull/687)). - Output folder for fixtures has been renamed from "blockchain_tests_hive" to "blockchain_tests_engine" ([#687](https://github.com/ethereum/execution-spec-tests/pull/687)). +
+ +--- + ## [v2.1.1](https://github.com/ethereum/execution-spec-tests/releases/tag/v2.1.1) - 2024-03-09 ### πŸ§ͺ Test Cases @@ -658,6 +694,10 @@ The following changes may be potentially breaking (all clients were tested with - 🐞 Fix deprecation warnings due to outdated config in recommended VS Code project settings ([#420](https://github.com/ethereum/execution-spec-tests/pull/420)). - 🐞 Fix typo in the selfdestruct revert tests module ([#421](https://github.com/ethereum/execution-spec-tests/pull/421)). +
+ +--- + ## [v2.1.0](https://github.com/ethereum/execution-spec-tests/releases/tag/v2.1.0) - 2024-01-29: πŸπŸ–οΈ Cancun Release [v2.1.0](https://github.com/ethereum/execution-spec-tests/releases/tag/v2.1.0) primarily fixes a small bug introduced within the previous release where transition forks are used within the new `StateTest` format. This was highlighted by @chfast within #405 (), where the fork name `ShanghaiToCancunAtTime15k` was found within state tests. @@ -674,6 +714,10 @@ Release [v2.1.0](https://github.com/ethereum/execution-spec-tests/releases/tag/v - ✨ Use `run-parallel` and shared wheel packages for `tox` ([#408](https://github.com/ethereum/execution-spec-tests/pull/408)). +
+ +--- + ## [v2.0.0](https://github.com/ethereum/execution-spec-tests/releases/tag/v2.0.0) - 2024-01-25: πŸπŸ–οΈ Cancun Release [v2.0.0](https://github.com/ethereum/execution-spec-tests/releases/tag/v2.0.0) contains many important framework changes, including introduction of the `StateTest` format, and some additional Cancun and other test coverage. @@ -785,6 +829,10 @@ The fixture renaming provides a more consistent naming scheme between the pytest - `fixtures/blockchain_tests/frontier/opcodes/dup/dup.json` (`BlockChainTest` format). - `fixtures/blockchain_tests_hive/frontier/opcodes/dup/dup.json` (a blockchain test in `HiveFixture` format). +
+ +--- + ## [v1.0.6](https://github.com/ethereum/execution-spec-tests/releases/tag/v1.0.6) - 2023-10-19: πŸπŸ–οΈ Cancun Devnet 10 ### πŸ§ͺ Test Cases @@ -813,6 +861,10 @@ The fixture renaming provides a more consistent naming scheme between the pytest - Fixtures now use the Mainnet Trusted Setup merged on [consensus-specs#3521](https://github.com/ethereum/consensus-specs/pull/3521) ([#336](https://github.com/ethereum/execution-spec-tests/pull/336)). +
+ +--- + ## [v1.0.5](https://github.com/ethereum/execution-spec-tests/releases/tag/v1.0.5) - 2023-09-26: πŸπŸ–οΈ Cancun Devnet 9 Release 3 This release mainly serves to update the EIP-4788 beacon roots address to `0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02`, as updated in [ethereum/EIPs/pull/7672](https://github.com/ethereum/EIPs/pull/7672). @@ -837,6 +889,10 @@ Please use development fixtures from now on when testing Cancun. These refer to - fixtures_hive: All tests until the last stable fork (Shanghai) in hive format (Engine API directives instead of the usual BlockchainTest format). - fixtures_develop_hive: All tests until the last development fork (Cancun) in hive format. +
+ +--- + ## [v1.0.4](https://github.com/ethereum/execution-spec-tests/releases/tag/v1.0.4) - 2023-09-21: 🐍 Cancun Devnet 9 Release 2 This release adds additional coverage to the current set of Cancun tests, up to the [Devnet-9 Cancun specification](https://notes.ethereum.org/@ethpandaops/dencun-devnet-9). @@ -857,6 +913,10 @@ This release adds additional coverage to the current set of Cancun tests, up to - πŸ’₯ `fill`: `--disable-hive` flag removed; replaced by `--enable-hive` (@spencer-tb in [#301](https://github.com/ethereum/execution-spec-tests/pull/301)). - ✨ Add engine API forkchoice updated information in fixtures (@spencer-tb in [#256](https://github.com/ethereum/execution-spec-tests/pull/256)). +
+ +--- + ## [v1.0.3](https://github.com/ethereum/execution-spec-tests/releases/tag/v1.0.3) - 2023-09-14: 🐍 Cancun Devnet 9 Release See [v1.0.3](https://github.com/ethereum/execution-spec-tests/releases/tag/v1.0.3). @@ -873,4 +933,10 @@ See [v1.0.1](https://github.com/ethereum/execution-spec-tests/releases/tag/v1.0. See [v1.0.0](https://github.com/ethereum/execution-spec-tests/releases/tag/v1.0.0). +
+ +--- + +
+ Older releases can be found on [the releases page](https://github.com/ethereum/execution-spec-tests/releases). diff --git a/docs/changelog_section_template.md b/docs/content/main/changelog_section_template.txt similarity index 100% rename from docs/changelog_section_template.md rename to docs/content/main/changelog_section_template.txt diff --git a/docs/content/main/dev_docs/coding_style.md b/docs/content/main/dev_docs/coding_style.md new file mode 100644 index 00000000000..f15a5a78c3f --- /dev/null +++ b/docs/content/main/dev_docs/coding_style.md @@ -0,0 +1,8 @@ ++++ +title = 'Coding Style' +weight = 25 ++++ + +{{< callout warning "Documentation Moved" >}} +This documentation has been relocated to [Getting Started -> Code Standards](../getting_started/code_standards.md). Please use the new location for the most up-to-date information. +{{< /callout >}} \ No newline at end of file diff --git a/docs/dev/configurations.md b/docs/content/main/dev_docs/configurations.md similarity index 96% rename from docs/dev/configurations.md rename to docs/content/main/dev_docs/configurations.md index 90ab6b879a2..e595fa2cb51 100644 --- a/docs/dev/configurations.md +++ b/docs/content/main/dev_docs/configurations.md @@ -1,4 +1,7 @@ -# Managing Configurations ++++ +title = 'Managing Configurations' +weight = 5 ++++ Configurations are managed by the `config` package. It provides both environment and application configurations. diff --git a/docs/dev/deps_and_packaging.md b/docs/content/main/dev_docs/deps_and_packaging.md similarity index 54% rename from docs/dev/deps_and_packaging.md rename to docs/content/main/dev_docs/deps_and_packaging.md index 70d28adecce..c59b5a005f2 100644 --- a/docs/dev/deps_and_packaging.md +++ b/docs/content/main/dev_docs/deps_and_packaging.md @@ -1,27 +1,30 @@ -# EEST Dependency Management and Packaging ++++ +title = 'Dependency Management and Packaging' +weight = 45 ++++ EEST uses [`uv`](https://docs.astral.sh/uv/) to manage and pin its dependencies. -Please use `uv>=0.7.0` to ensure `uv` writes `uv.lock` files with consistent fields and formatting (see [ethereum/execution-spec-tests#1597]https://github.com/ethereum/execution-spec-tests/pull/1597). +Please use `uv>=0.7.0` to ensure `uv` writes `uv.lock` files with consistent fields and formatting (see [ethereum/execution-spec-tests#1597](https://github.com/ethereum/execution-spec-tests/pull/1597)). ## Managing Dependencies We aim to provide specific [version specifiers](https://peps.python.org/pep-0440/#version-specifiers) for each of our direct and extra dependencies. -!!! note "Packages should be managed via `uv`" +{{< callout info "Packages should be managed via `uv`" >}} +Dependencies should be managed using `uv` on the command-line to ensure that version compatibility is ensured across all dependencies and that `uv.lock` is updated as required. - Dependencies should be managed using `uv` on the command-line to ensure that version compatibility is ensured across all dependencies and that `uv.lock` is updated as required. +The docs below cover common operations, see the `uv` [documentation on managing dependencies](https://docs.astral.sh/uv/concepts/projects/dependencies/#multiple-sources) for more information. +{{< /callout >}} - The docs below cover common operations, see the `uv` [documentation on managing dependencies](https://docs.astral.sh/uv/concepts/projects/dependencies/#multiple-sources) for more information. +{{< callout info "Separate PRs are preferred when managing dependencies" >}} +An upgrade of all pinned dependencies in `uv.lock` must be performed in a dedicated PR! -!!! info "Separate PRs are preferred when managing dependencies" +For other dependency changes, they can be included in the PR that removed use of the library, for example. But if a version bump is made, without related source code changes, it should be done in a dedicated PR. This makes the change: - An upgrade of all pinned dependencies in `uv.lock` must be performed in a dedicated PR! - - For other dependency changes, they can be included in the PR that removed use of the library, for example. But if a version bump is made, without related source code changes, it should be done in a dedicated PR. This makes the change: - - - Easier to track. - - Trivial to revert. +- Easier to track. +- Trivial to revert. +{{< /callout >}} ### Adding/modifying direct dependencies @@ -45,17 +48,17 @@ ethereum-spec-evm-resolver = { git = "https://github.com/petertdavies/ethereum-s ... ``` -!!! example "Example: Updating direct dependencies" - - Example of a package dependency update: - ```console - uv add "requests>=2.31,<2.33" - ``` +{{< callout info "Example: Updating direct dependencies" >}} +Example of a package dependency update: +```console +uv add "requests>=2.31,<2.33" +``` - Example of a source dependency update: - ```console - uv add "ethereum-spec-evm-resolver @ git+https://github.com/petertdavies/ethereum-spec-evm-resolver@623ac4565025e72b65f45b926da2a3552041b469" - ``` +Example of a source dependency update: +```console +uv add "ethereum-spec-evm-resolver @ git+https://github.com/petertdavies/ethereum-spec-evm-resolver@623ac4565025e72b65f45b926da2a3552041b469" +``` +{{< /callout >}} ### Adding/modifying optional dependencies @@ -74,11 +77,11 @@ docs = [ ] ``` -!!! example "Example: Updating an optional dependency" - - ``` - uv add --optional lint "types-requests>=2.31,<2.33" - ``` +{{< callout info "Example: Updating an optional dependency" >}} +``` +uv add --optional lint "types-requests>=2.31,<2.33" +``` +{{< /callout >}} ## Upgrading Pinned Dependencies in `uv.lock` diff --git a/docs/content/main/dev_docs/docs.md b/docs/content/main/dev_docs/docs.md new file mode 100644 index 00000000000..d7c2e3e35e4 --- /dev/null +++ b/docs/content/main/dev_docs/docs.md @@ -0,0 +1,36 @@ ++++ +title = 'Documentation' +weight = 15 ++++ + +The `execution-spec-tests` documentation is generated via [`hugo`](https://github.com/gohugoio/hugo) and hosted remotely on Github Pages at [eest.ethereum.org](https://eest.ethereum.org/). + +## Prerequisites + +Grab the latest `hugo` binary from the official release page or build it yourself. Then make the binary executable and add it to the PATH (or to a directory that has already been added to the PATH like e.g. `/usr/local/bin/`). We do not require any additional plugins or dependencies. + +## Build and Locally Host the Documentation + +Build the docs: + +```console +hugo +``` + +If you want to build + locally host the docs: + +```console +hugo server +``` + +## Remote Deployment and Versioning + +The execution-specs-test docs are hosted using Github pages at [eest.ethereum.org](https://eest.ethereum.org/). Versions are updated/deployed automatically as part of Github Actions. + +### CI/CD: Doc Deployment via Github Actions + +This is our workflow that automatically deploys updated/new versions of the docs: + +| Workflow `yaml` File | What | When | +|----------------------|------|------| +| `docs.yaml` | Deploy new version of docs diff --git a/docs/dev/documenting_clis.md b/docs/content/main/dev_docs/documenting_clis.md similarity index 95% rename from docs/dev/documenting_clis.md rename to docs/content/main/dev_docs/documenting_clis.md index f7d3e382d71..9c8484d5847 100644 --- a/docs/dev/documenting_clis.md +++ b/docs/content/main/dev_docs/documenting_clis.md @@ -1,4 +1,7 @@ -# Documenting CLIs ++++ +title = 'Documenting CLI Commands' +weight = 20 ++++ EEST command line interfaces (CLIs) are documented using the [`click`](https://click.palletsprojects.com) library's built-in help system and the [`mkdocs-click`](https://github.com/mkdocs/mkdocs-click) extension for mkdocs. This allows generation of CLI documentation directly from the (click) source code, ensuring that the documentation is always up-to-date with the code. diff --git a/docs/dev/interactive_usage.md b/docs/content/main/dev_docs/interactive_usage.md similarity index 71% rename from docs/dev/interactive_usage.md rename to docs/content/main/dev_docs/interactive_usage.md index fab788ed0f6..f07aee7efbd 100644 --- a/docs/dev/interactive_usage.md +++ b/docs/content/main/dev_docs/interactive_usage.md @@ -1,4 +1,7 @@ -# Working with EEST Libraries Interactively ++++ +title = 'Interactive Library Usage' +weight = 10 ++++ You can work with EEST Python packages interactively with `ipython` using: @@ -8,16 +11,16 @@ uvx --with-editable . ipython This command will create a virtual environment, install EEST's packages in "[editable mode](https://setuptools.pypa.io/en/latest/userguide/development_mode.html)" (source changes get reflected in the interactive shell), and start an `ipython` shell. You can then import any of the packages and experiment with them interactively. -!!! example "Example: Working with `ethereum_test_forks`" +{{< callout info "Example: Working with `ethereum_test_forks`" >}} +See which defined forks are "ignored" by default: - See which defined forks are "ignored" by default: - - ```python - from ethereum_test_forks import forks, get_forks - forks = set([fork for fork in get_forks() if fork.ignore()]) - print(forks) - # -> {MuirGlacier, ArrowGlacier, GrayGlacier} - ``` +```python +from ethereum_test_forks import forks, get_forks +forks = set([fork for fork in get_forks() if fork.ignore()]) +print(forks) +# -> {MuirGlacier, ArrowGlacier, GrayGlacier} +``` +{{< /callout >}} ## Required `ipython` Configuration diff --git a/docs/dev/logging.md b/docs/content/main/dev_docs/logging.md similarity index 99% rename from docs/dev/logging.md rename to docs/content/main/dev_docs/logging.md index 346dfcf2431..8b36befb24a 100644 --- a/docs/dev/logging.md +++ b/docs/content/main/dev_docs/logging.md @@ -1,4 +1,7 @@ -# Logging ++++ +title = 'Logging' +weight = 30 ++++ This document describes the logging system used in the Ethereum Execution Spec Tests project. Currently, logging is only supported for `consume` commands. diff --git a/docs/dev/index.md b/docs/content/main/dev_docs/main.md similarity index 89% rename from docs/dev/index.md rename to docs/content/main/dev_docs/main.md index d7fe93286d6..c636df5b322 100644 --- a/docs/dev/index.md +++ b/docs/content/main/dev_docs/main.md @@ -1,4 +1,13 @@ -# Developer Documentation ++++ +title = 'Developer Documentation' +date = 2025-07-09T12:42:33Z +draft = false +[menu] + [menu.main] + name = 'Developer Doc' + weight = 25 + ++++ This documentation is aimed at `execution-spec-tests` developers: diff --git a/docs/dev/precommit.md b/docs/content/main/dev_docs/precommit.md similarity index 53% rename from docs/dev/precommit.md rename to docs/content/main/dev_docs/precommit.md index 3b8af55539d..c4afd3c1cd8 100644 --- a/docs/dev/precommit.md +++ b/docs/content/main/dev_docs/precommit.md @@ -1,4 +1,7 @@ -# Enabling Pre-Commit Checks ++++ +title = 'Enabling Pre-Commit Checks' +weight = 35 ++++ There's a [pre-commit](https://pre-commit.com/) config file available in the repository root (`.pre-commit-config.yaml`) that can be used to enable automatic checks upon commit - the commit will not go through if the checks don't pass. @@ -8,9 +11,10 @@ To enable pre-commit, the following must be run once: uvx pre-commit install ``` -!!! note "Bypassing pre-commit checks" - Enabling of pre-commit checks is not mandatory (it cannot be enforced) and even if it is enabled, it can always be bypassed with: +{{< callout info "Bypassing pre-commit checks" >}} +Enabling of pre-commit checks is not mandatory (it cannot be enforced) and even if it is enabled, it can always be bypassed with: - ```console - git commit --no-verify - ``` +```console +git commit --no-verify +``` +{{< /callout >}} \ No newline at end of file diff --git a/docs/dev/test_actions_locally.md b/docs/content/main/dev_docs/test_actions_locally.md similarity index 96% rename from docs/dev/test_actions_locally.md rename to docs/content/main/dev_docs/test_actions_locally.md index 4653c9b9392..2c849c5eb6c 100644 --- a/docs/dev/test_actions_locally.md +++ b/docs/content/main/dev_docs/test_actions_locally.md @@ -1,4 +1,7 @@ -# Running Github Actions Locally ++++ +title = 'Running Github Actions Locally' +weight = 40 ++++ The Github Actions workflows can be tested locally using [nektos/act](https://github.com/nektos/act) without pushing changes to the remote. The local repository state will be used in the executed workflow. @@ -27,12 +30,13 @@ The Github Actions workflows can be tested locally using [nektos/act](https://gi or use one of the [other available methods](https://nektosact.com/installation/index.html). -!!! note "Updating nektos/act to the latest version via the Github CLI" - The `act` tool can be updated via the Github CLI: +{{< callout info "Updating nektos/act to the latest version via the Github CLI" >}} +The `act` tool can be updated via the Github CLI: - ```bash - gh extension upgrade nektos/act - ``` +```bash +gh extension upgrade nektos/act +``` +{{< /callout >}} ## Listing the Available Workflows diff --git a/docs/filling_tests/debugging_t8n_tools.md b/docs/content/main/filling_tests/debugging_t8n_tools.md similarity index 83% rename from docs/filling_tests/debugging_t8n_tools.md rename to docs/content/main/filling_tests/debugging_t8n_tools.md index 21b57d3735f..4be4552bd96 100644 --- a/docs/filling_tests/debugging_t8n_tools.md +++ b/docs/content/main/filling_tests/debugging_t8n_tools.md @@ -1,14 +1,16 @@ -# Debugging Transition Tools ++++ +title = 'Debugging Transition Tools' ++++ There are two flags that can help debugging `t8n` tools or the execution-spec-tests framework: -1. `--evm-dump-dir`: Write debug information from `t8n` tool calls to the specified directory. +1. `--evm-dump-dir` (Default: /logs/evm): Write debug information from `t8n` tool calls to the specified directory. 2. `--traces`: Collect traces of the execution from the transition tool. 3. `--verify-fixtures`: Run go-ethereum's `evm blocktest` command to verify the generated test fixtures. ## EVM Dump Directory -The `--evm-dump-dir` flag tells the framework to write the inputs and outputs of every call made to the `t8n` command to the specified output directory. The aim is to help debugging or simply understand how a test is interacting with the EVM. Debug output is only generated when this flag is explicitly specified. +The `--evm-dump-dir` flag tells the framework to write the inputs and outputs of every call made to the `t8n` command to the specified output directory. The aim is to help debugging or simply understand how a test is interacting with the EVM. The default location is `logs/evm` in the project root. Each test case receives its own sub-directory under the `--evm-dump-dir` that contains these files which can be easily accessed from the HTML test report generated by `fill` (located by default in the root of the `--output` directory). @@ -169,13 +171,10 @@ where the `verify_fixtures.sh` script can be used to reproduce the `evm blocktes --single-fixture-per-file ``` -!!! note "Execution scope of `evm blocktest`" +{{< callout info "Execution scope of `evm blocktest`" >}} +Note, by default, that `evm blocktest` is not executed per parametrized test case, but rather per test function. This is because each fixture JSON file contains fixtures for all the parametrized test cases for one test function. This means only one error will be reported, even if multiple fixtures fail within one fixture file. - Note, by default, that `evm blocktest` is not executed per parametrized test case, but rather per test function. This is because each fixture JSON file contains fixtures for all the parametrized test cases for one test function. This means only one error will be reported, even if multiple fixtures fail within one fixture file. - - Additionally, it is only executed after all the test cases in the module have been executed[^1] and will only report the first failing test fixture in all files, even if there are multiple failing fixture files. - - This means, by default, that the feedback is not as granular as for test case execution. To improve granularity, and get feedback per parametrized test case use `--single-fixture-per-file`. +Additionally, it is only executed after all the test cases in the module have been executed and will only report the first failing test fixture in all files, even if there are multiple failing fixture files. This limitation is required to enable support of the [`pytest-xdist` plugin](https://github.com/pytest-dev/pytest-xdist) for concurrent test execution across multiple CPUs. To achieve this we use the we apply the `--dist loadscope` xdist flag in our `pytest.ini`. -[^1]: - This limitation is required to enable support of the [`pytest-xdist` plugin](https://github.com/pytest-dev/pytest-xdist) for concurrent test execution across multiple CPUs. To achieve this we use the we apply the `--dist loadscope` xdist flag in our `pytest-fill.ini`. +This means, by default, that the feedback is not as granular as for test case execution. To improve granularity, and get feedback per parametrized test case use `--single-fixture-per-file`. +{{< /callout >}} \ No newline at end of file diff --git a/docs/filling_tests/filling_tests_command_line.md b/docs/content/main/filling_tests/filling_tests_command_line.md similarity index 73% rename from docs/filling_tests/filling_tests_command_line.md rename to docs/content/main/filling_tests/filling_tests_command_line.md index f875dfc7924..6f92a699ff0 100644 --- a/docs/filling_tests/filling_tests_command_line.md +++ b/docs/content/main/filling_tests/filling_tests_command_line.md @@ -1,15 +1,18 @@ -# Filling Tests at a Prompt ++++ +title = 'Filling Tests at a Prompt' ++++ -The execution-spec-tests test framework uses the [pytest framework](https://docs.pytest.org/en/latest/) for test case collection and execution. The `fill` command is essentially an alias for `pytest`, which uses several [custom pytest plugins](../library/pytest_plugins/index.md) to run transition tools against test cases and generate JSON fixtures. +The execution-spec-tests test framework uses the [pytest framework](https://docs.pytest.org/en/latest/) for test case collection and execution. The `fill` command is essentially an alias for `pytest`, which uses several [custom pytest plugins](../library/pytest_plugins/main.md) to run transition tools against test cases and generate JSON fixtures. -!!! note "Options specific to execution-spec-tests" - The command-line options specific to filling tests can be listed via: +{{< callout info "Options specific to execution-spec-tests" >}} +The command-line options specific to filling tests can be listed via: - ```console - uv run fill --help - ``` +```console +uv run fill --help +``` - See [Custom `fill` Command-Line Options](#custom-fill-command-line-options) for all options. +See [Custom `fill` Command-Line Options](#custom-fill-command-line-options) for all options. +{{< /callout >}} ## Collection - Test Exploration @@ -47,8 +50,9 @@ To generate all the test fixtures defined in the `./tests/shanghai` sub-director uv run fill ./tests/shanghai --output="fixtures-shanghai" ``` -!!! note "Test case verification" - Note, that the (limited set of) test `post` conditions are tested against the output of the `evm t8n` command during test generation. +{{< callout info "Test case verification" >}} +Note, that the (limited set of) test `post` conditions are tested against the output of the `evm t8n` command during test generation. +{{< /callout >}} To generate all the test fixtures in the `tests/shanghai/eip3651_warm_coinbase/test_warm_coinbase.py` module, for example, run: @@ -76,17 +80,18 @@ uv run fill tests/shanghai/eip3651_warm_coinbase/test_warm_coinbase.py::test_war ## Execution for Development Forks -!!! note "" - By default, test cases are not filled for upcoming Ethereum forks so that they can be readily filled using the `evm` tool from the latest `geth` release. +{{< callout info "Note" >}} +By default, test cases are not filled for upcoming Ethereum forks so that they can be readily filled using the `evm` tool from the latest `geth` release. - In order to fill test cases for an upcoming fork, ensure that the `evm` tool used supports that fork and features under test and use the `--until` or `--fork` flag. +In order to fill test cases for an upcoming fork, ensure that the `evm` tool used supports that fork and features under test and use the `--until` or `--fork` flag. - For example, as of Q2 2023, the current fork under active development is `Cancun`: - ```console - uv run fill --until Cancun - ``` +For example, as of Q2 2023, the current fork under active development is `Cancun`: +```console +uv run fill --until Cancun +``` +{{< /callout >}} - See: [Filling Tests for Features under Development](./filling_tests_dev_fork.md). +See: [Filling Tests for Features under Development](./filling_tests_dev_fork.md). ## Debugging the `t8n` Command diff --git a/docs/filling_tests/filling_tests_dev_fork.md b/docs/content/main/filling_tests/filling_tests_dev_fork.md similarity index 54% rename from docs/filling_tests/filling_tests_dev_fork.md rename to docs/content/main/filling_tests/filling_tests_dev_fork.md index 6217ed032a2..d158bcdb343 100644 --- a/docs/filling_tests/filling_tests_dev_fork.md +++ b/docs/content/main/filling_tests/filling_tests_dev_fork.md @@ -1,4 +1,6 @@ -# Filling Tests for Features under Development ++++ +title = 'Filling Tests for Features under Development' ++++ ## Requirements @@ -7,41 +9,46 @@ By default, execution-spec-tests only generates fixtures for forks that have bee 1. A version of the `evm` and `solc` tools that implement the feature must be available (although, typically only a developer version of the `evm` tool is required, usually the latest stable release of `solc` is adequate), and, 2. The development fork to test must be explicitly specified on the command-line: - === "via the `--fork` flag" +{{< tabs >}} - ```console - uv run fill -k 4844 --fork=Cancun -v - ``` +{{< tab "via the `--fork` flag" >}} +```console +uv run fill -k 4844 --fork=Cancun -v +``` +{{< /tab >}} - === "via the `--from` flag" +{{< tab "via the `--from` flag" >}} +```console +uv run fill -k 4844 --from=Cancun -v +``` +{{< /tab >}} - ```console - uv run fill -k 4844 --from=Cancun -v - ``` +{{< tab "via the `--until` flag" >}} +```console +uv run fill -k 4844 --until=Cancun -v +``` +{{< /tab >}} - === "via the `--until` flag" +{{< /tabs >}} - ```console - uv run fill -k 4844 --until=Cancun -v - ``` -!!! note "Specifying the `evm` binary via `evm-bin`" - It is possible to explicitly specify the `evm` binary used to generate fixtures via the `--evm-bin` flag, for example, +{{< callout info "Specifying the `evm` binary via `evm-bin`" >}} +It is possible to explicitly specify the `evm` binary used to generate fixtures via the `--evm-bin` flag, for example, - ```console - uv run fill --fork=Cancun --evm-bin=/opt/bin/evm -v - ``` +```console +uv run fill --fork=Cancun --evm-bin=/opt/bin/evm -v +``` +{{< /callout >}} ## Further Help 1. [`geth`/`evm` build documentation](https://geth.ethereum.org/docs/getting-started/installing-geth#build-from-source). 2. [`solc` build documentation](https://docs.soliditylang.org/en/v0.8.20/installing-solidity.html#building-from-source). -!!! note "Verifying `evm` and `solc` versions used" - The versions used to generate fixtures are displayed in the console output: -
- ![Screenshot of pytest test collection console output](./img/pytest_run_example.png){align=center} -
+{{< callout info "Verifying `evm` and `solc` versions used" >}} +The versions used to generate fixtures are displayed in the console output: +![Screenshot of pytest test collection console output](/images/filling_tests/pytest_run_example.png) +{{< /callout >}} ## VS Code Setup diff --git a/docs/content/main/filling_tests/filling_tests_vs_code.md b/docs/content/main/filling_tests/filling_tests_vs_code.md new file mode 100644 index 00000000000..02fbefe4012 --- /dev/null +++ b/docs/content/main/filling_tests/filling_tests_vs_code.md @@ -0,0 +1,19 @@ ++++ +title = 'Filling Tests in VS Code' ++++ + +Prerequisite: [VS Code Setup](../getting_started/setup_vs_code.md). + +## Exploring Test Cases + +Implemented test cases can be explored in VS Code's "Testing" View; click on the conical flask highlighted in the screenshot below. + +![VS Code Testing Tab](/images/filling_tests/vs_code_exploring_tests.png) + +{{< callout info "Testing EVM Features Under Active Development" >}} +See [the VS Code section](./filling_tests_dev_fork.md#vs-code-setup) in [Filling Tests for Features under Development](./filling_tests_dev_fork.md) to explore tests targeting EVM features under development. +{{< /callout >}} + +## Filling and Debugging Test Cases + +![VS Code Testing Tab](/images/filling_tests/vs_code_executing_tests.png) \ No newline at end of file diff --git a/docs/filling_tests/getting_started.md b/docs/content/main/filling_tests/getting_started.md similarity index 97% rename from docs/filling_tests/getting_started.md rename to docs/content/main/filling_tests/getting_started.md index a9e39715b15..45628f2730a 100644 --- a/docs/filling_tests/getting_started.md +++ b/docs/content/main/filling_tests/getting_started.md @@ -1,3 +1,8 @@ ++++ +title = 'Getting Started' +weight = 5 ++++ + # Getting Started: Filling Tests This guide describes how to get started with `fill` and commonly-used command-line options. @@ -54,4 +59,4 @@ This guide describes how to get started with `fill` and commonly-used command-li 1. Learn [useful command-line flags](./filling_tests_command_line.md). 2. [Execute tests for features under development](./filling_tests_dev_fork.md) via the `--fork` flag. 3. _Optional:_ [Configure VS Code](../getting_started/setup_vs_code.md) to auto-format Python code and [execute tests within VS Code](./filling_tests_vs_code.md#filling-and-debugging-test-cases). -4. Implement a new test case, see [Writing Tests](../writing_tests/index.md). +4. Implement a new test case, see [Writing Tests](../writing_tests/main.md). diff --git a/docs/filling_tests/index.md b/docs/content/main/filling_tests/main.md similarity index 67% rename from docs/filling_tests/index.md rename to docs/content/main/filling_tests/main.md index 213b3049d75..9783dda477e 100644 --- a/docs/filling_tests/index.md +++ b/docs/content/main/filling_tests/main.md @@ -1,4 +1,13 @@ -# Filling Tests ++++ +title = 'Filling Tests' +date = 2025-07-09T12:42:33Z +draft = false +[menu] + [menu.main] + name = 'Filling Tests' + weight = 15 + ++++ Execution of test cases against clients is a two-step process: @@ -7,9 +16,9 @@ Execution of test cases against clients is a two-step process: The process of generating fixtures is often referred to as "filling" the tests. -!!! note "The `execute` command" - - The `execute` command directly executes Python test cases against a client via its RPC without using generated JSON fixtures. For all other methods of testing clients, the JSON fixtures are required. For more information, see [Executing Tests](../running_tests/execute/index.md). +{{< callout info "The `execute` command" >}} +The `execute` command directly executes Python test cases against a client via its RPC without using generated JSON fixtures. For all other methods of testing clients, the JSON fixtures are required. For more information, see [Executing Tests](../running_tests/execute/main.md). +{{< /callout >}} ## Transition Tools (`t8n`) @@ -23,11 +32,11 @@ By default, the [Ethereum Execution Layer Specification](https://github.com/ethe The "fill-consume" method follows a differential testing approach: A reference implementation is used to generate JSON test fixtures, which can then be executed against other EVM clients. However: -!!! warning "Successfully filling does not guarantee correctness" +{{< callout warning "Successfully filling does not guarantee correctness" >}} +Some tests cases, particularly those without straightforward post-checks, such as certain gas calculations, may allow subtle inconsistencies to slip through during filling. - Some tests cases, particularly those without straightforward post-checks, such as certain gas calculations, may allow subtle inconsistencies to slip through during filling. - - **Consequently, filling the tests does not ensure the client’s correctness. Clients must consume the tests to be considered correctly tested, even if that client was used to fill the tests.** +**Consequently, filling the tests does not ensure the client's correctness. Clients must consume the tests to be considered correctly tested, even if that client was used to fill the tests.** +{{< /callout >}} ## Filling Static Tests from [ethereum/tests](https://github.com/ethereum/tests) diff --git a/docs/filling_tests/test_ids.md b/docs/content/main/filling_tests/test_ids.md similarity index 98% rename from docs/filling_tests/test_ids.md rename to docs/content/main/filling_tests/test_ids.md index 7005ab639be..2d83220b0e4 100644 --- a/docs/filling_tests/test_ids.md +++ b/docs/content/main/filling_tests/test_ids.md @@ -1,4 +1,6 @@ -# An explanation of test IDs generated by `fill` ++++ +title = 'An Explanation of Test IDs' ++++ ## Test Case Organization diff --git a/docs/filling_tests/transition_tool_support.md b/docs/content/main/filling_tests/transition_tool_support.md similarity index 96% rename from docs/filling_tests/transition_tool_support.md rename to docs/content/main/filling_tests/transition_tool_support.md index 48e26291adf..274225a9fbd 100644 --- a/docs/filling_tests/transition_tool_support.md +++ b/docs/content/main/filling_tests/transition_tool_support.md @@ -1,4 +1,6 @@ -# Transition Tool Support ++++ +title = 'Transition Tool Support' ++++ The following transition tools are supported by the framework: diff --git a/docs/content/main/getting_started/code_standards.md b/docs/content/main/getting_started/code_standards.md new file mode 100644 index 00000000000..f7dd34cbd25 --- /dev/null +++ b/docs/content/main/getting_started/code_standards.md @@ -0,0 +1,106 @@ ++++ +title = 'Code Standards' +weight = 25 ++++ + +This document outlines the coding standards and practices used in the [ethereum/execution-spec-tests](https://github.com/ethereum/execution-spec-tests/) repository. + +## Code and CI Requirements + +Code pushed to execution-spec-tests must fulfill the following checks in [CI](https://github.com/ethereum/execution-spec-tests/actions/workflows/tox_verify.yaml): + +{{< table headers="Type|Explanation|Tox Command" >}} +Lint & code formatting | `uvx --with=tox-uv tox -e lint` | Python lint, format and module import check via `ruff` || +Typecheck | `uvx --with=tox-uv tox -e typecheck` | Objects that provide typehints pass type-checking via `mypy` || +Framework unit tests | `uvx --with=tox-uv tox -e pytest` | All framework unit tests must execute correctly || +EL Client test cases | `uvx --with=tox-uv tox -e tests-deployed` | All client test cases for deployed forks can be generated || +Benchmark EL Test cases | `uvx --with=tox-uv tox -e tests-deployed-benchmark`| All client test cases specific to benchmarks for deployed forks can be generated || +HTML doc build | `uvx --with=tox-uv tox -e hugo` | Documentation generated without warnings || +Spellcheck | `uvx --with=tox-uv tox -e spellcheck` | Code and documentation spell-check using codespell || +Markdown lint | `uvx --with=tox-uv tox -e markdownlint` | Markdown lint (requires [additional dependency]({{< ref "code_standards_details.md#additional-dependencies" >}})) || +Changelog validation | `uvx --with=tox-uv tox -e changelog` | Validates changelog entries format and structure in `docs/CHANGELOG.md` || +{{< /table >}} + +{{< callout warning "Avoid CI surprises - Use pre-commit hooks!" >}} +**We strongly encourage all contributors to install and use pre-commit hooks!** This will run fast checks (lint, typecheck, spellcheck) automatically before each commit, helping you catch issues early and avoid frustrating CI failures after pushing your changes. + +Install with one simple command: +```console +uvx pre-commit install +``` + +This saves you time by catching formatting issues, type errors, and spelling mistakes before they reach CI. +{{< /callout >}} + +{{< callout info "Running checks easily" >}} +Add an alias: + +```console +alias tox="uvx --with=tox-uv tox" +``` + +Run all checks in parallel: + +```console +uvx --with=tox-uv tox run-parallel +``` + +Run sequentially: + +```console +uvx --with=tox-uv tox +``` + +Run specific, faster checks: + +```console +uvx --with=tox-uv tox -e lint,typecheck +``` +{{< /callout >}} + +{{< callout info "Lint & code formatting: Using `ruff` and VS Code to help autoformat and fix module imports" >}} +On the command-line, solve fixable issues with: + +```console +uv run ruff check --fix +``` + +Use VS Code, see [VS Code Setup]({{< ref "../getting_started/setup_vs_code.md" >}}), to autoformat code, automatically organize Python module imports and highlight typechecking and spelling issues. +{{< /callout >}} + +{{< callout info "Typechecking" >}} +Adding the correct typehints can sometimes be tricky and there are exceptions that require manually disabling typechecking on a per-line basis. Please reach out to the maintainers if you need help, either [directly]({{< ref "../getting_started/getting_help.md" >}}) or in a PR. +{{< /callout >}} + +## Python Coding Preferences + +- **Line Length**: 100 characters maximum. +- **Formatting**: Enforced by `ruff` (similar to `black`). +- **Documentation**: + - All public functions and classes should have docstrings + - Docstrings should have a good one-line summary which uses the imperative ("Return" not "Returns"). + - Add a blank line after the summary for multi-line docstrings. + - Single-line docstrings should have triple quotes on the same line. +- **Imports**: Use explicit imports (no `from module import *`). +- **Relative Imports**: Use relative imports within the same package +- **Error Handling**: Use explicit exception types and meaningful error messages. +- **Type Hints**: All functions should include type annotations. +- **Variable Naming**: + - Use `snake_case` for variables, functions, and modules. + - Use `PascalCase` for classes. + - Use `UPPER_CASE` for constants. +- **File Paths**: Strongly prefer `pathlib` over `os.path` for file system operations. + +## Editor Setup + +A correctly configured editor will automatically handle most formatting requirements. See [VS Code Setup]({{< ref "./setup_vs_code.md" >}}) for recommended settings. + +## Detailed Information + +See the [Detailed Code Standards]({{< ref "code_standards_details.md" >}}) page for more information on: + +- [Running tox environments]({{< ref "code_standards_details.md#running-tox-environments" >}}). + - Additional required [dependencies for markdownlint and spellchecking]({{< ref "code_standards_details.md#additional-dependencies" >}}). +- [Pre-commit hooks setup]({{< ref "code_standards_details.md#pre-commit-hooks" >}}). +- [Verifying test fixture changes]({{< ref "code_standards_details.md#verifying-fixture-changes" >}}). +- [Ignoring bulk change commits]({{< ref "code_standards_details.md#ignoring-bulk-change-commits" >}}) in `git blame`. diff --git a/docs/getting_started/code_standards_details.md b/docs/content/main/getting_started/code_standards_details.md similarity index 71% rename from docs/getting_started/code_standards_details.md rename to docs/content/main/getting_started/code_standards_details.md index aac00b138a3..7ad24fdc079 100644 --- a/docs/getting_started/code_standards_details.md +++ b/docs/content/main/getting_started/code_standards_details.md @@ -1,6 +1,9 @@ -# Detailed Code Standards ++++ +title = 'Detailed Code Standards' +weight = 30 ++++ -This page provides in-depth information about the code standards and verification processes in @ethereum/execution-spec-tests. +This page provides in-depth information about the code standards and verification processes in [ethereum/execution-spec-tests](https://github.com/ethereum/execution-spec-tests/). ## Running Tox Environments @@ -50,8 +53,9 @@ uvx --with=tox-uv tox -e lint,typecheck,spellcheck,pytest uvx --with=tox-uv tox -e spellcheck,markdownlint,mkdocs,changelog ``` -!!! note "Tox Virtual Environment" +{{< callout info "Tox Virtual Environment" >}} Checks performed by `tox` are sandboxed in their own virtual environments (created automatically in the `.tox/` subdirectory). These can be used to debug errors encountered during `tox` execution. +{{< /callout >}} ### Additional Dependencies @@ -67,8 +71,9 @@ To fix spelling errors found by codespell: uv run codespell *.md *.ini .github/ src/ tests/ docs/ --write-changes ``` -!!! note "VS Code Integration" - The `whitelist.txt` file is still maintained for the VS Code cSpell extension, which provides real-time spell checking in the editor. +{{< callout info "VS Code Integration" >}} +The `whitelist.txt` file is still maintained for the VS Code cSpell extension, which provides real-time spell checking in the editor. +{{< /callout >}} #### For `markdownlint` @@ -89,11 +94,11 @@ Certain `tox` environments can be run automatically as git pre-commit hooks to e uvx pre-commit install ``` -For more information, see [Pre-commit Hooks Documentation](../dev/precommit.md). +For more information, see [Pre-commit Hooks Documentation]({{< ref "../dev_docs/precommit.md" >}}). ## Formatting and Line Length -The Python code in @ethereum/execution-spec-tests is formatted with `ruff` with a line length of 100 characters. +The Python code in execution-spec-tests is formatted with `ruff` with a line length of 100 characters. ### Ignoring Bulk Change Commits @@ -111,23 +116,12 @@ git config blame.ignoreRevsFile .git-blame-ignore-revs ## Building and Verifying Docs Locally -To quickly build and browse the HTML documentation locally run: +To quickly build and browse the HTML documentation get latest hugo binary, navigate into the `docs` folder and run: -=== "bash" - - ```console - export FAST_DOCS=True - uv run mkdocs serve - ``` - -=== "fish" - - ```console - set -x FAST_DOCS True - uv run mkdocs serve - ``` +```console +hugo server +``` -Setting `FAST_DOCS` to `False` additionally builds the "[Test Case Reference](https://eest.ethereum.org/main/tests/)" Section. ## Verifying Fixture Changes @@ -139,11 +133,11 @@ All filled fixtures contain a `hash` field in the `_info` object, which is used The `hasher` command can be used to bulk-verify the hashes of fixtures in a directory. -| Flag | Description | -| ---------------- | ----------------------------------------------------------------- | -| `--files` / `-f` | Prints a combined hash per JSON fixture file. | -| `--tests` / `-t` | Prints the hash of every test vector in JSON fixture files. | -| `--root` / `-r` | Prints a combined hash for all JSON fixture files in a directory. | +{{< table headers="Flag|Description" >}} +`--files` / `-f` | Prints a combined hash per JSON fixture file|| +`--tests` / `-t` | Prints the hash of every test vector in JSON fixture files|| +`--root` / `-r` | Prints a combined hash for all JSON fixture files in a directory|| +{{< /table >}} For a quick comparison between two fixture directories: diff --git a/docs/getting_started/getting_help.md b/docs/content/main/getting_started/getting_help.md similarity index 60% rename from docs/getting_started/getting_help.md rename to docs/content/main/getting_started/getting_help.md index 8e370fb6b49..2dcc48ad242 100644 --- a/docs/getting_started/getting_help.md +++ b/docs/content/main/getting_started/getting_help.md @@ -1,4 +1,7 @@ -# Getting Help ++++ +title = 'Getting Help' +weight = 45 ++++ The tests in this repository are a community effort to help improve the development cycle of all Ethereum execution clients. @@ -8,10 +11,10 @@ We encourage contributions and recognize that Python is not everyone's primary Write to: -- Dan on [Discord](https://discordapp.com/users/danceratopz) or [Telegram](https://t.me/danceratopz) (`danceratopz`). -- Spencer on [Discord](https://discordapp.com/users/spencertaylorbrown) or [Telegram](https://t.me/spencertb) (`spencertaylorbrown`/`@techbro_ccoli`). -- Mario on [Discord](https://discordapp.com/users/marioevz) or [Telegram](https://t.me/marioevz) (`marioevz`/`@marioevz`). +- Dan on [Discord](https://discordapp.com/users/danceratopz) or [Telegram](https://t.me/danceratopz). +- Spencer on [Discord](https://discordapp.com/users/spencertaylorbrown) or [Telegram](https://t.me/spencertb). +- Mario on [Discord](https://discordapp.com/users/marioevz) or [Telegram](https://t.me/marioevz). +- Felix on [Discord](https://discordapp.com/users/felix314159_) or [Telegram](https://t.me/felix_eest). -
- ![ukiyo-e style design of 3 furry happy pandas playfully doing experiments on ethereum in a laboratory](img/testing_pandas.png){width="400"} -
+ +![ukiyo-e style design of 3 furry happy pandas playfully doing experiments on ethereum in a laboratory](/images/getting_started/testing_pandas.png) diff --git a/docs/content/main/getting_started/installation_troubleshooting.md b/docs/content/main/getting_started/installation_troubleshooting.md new file mode 100644 index 00000000000..25107683442 --- /dev/null +++ b/docs/content/main/getting_started/installation_troubleshooting.md @@ -0,0 +1,150 @@ ++++ +title = 'Installation Troubleshooting' +weight = 10 ++++ + +This page provides guidance on how to troubleshoot common issues that may arise when installing [ethereum/execution-spec-tests](https://github.com/ethereum/execution-spec-tests). + +## Problem: `Failed building wheel for coincurve` + +{{< callout danger "Problem: `Failed building wheel for coincurve`" >}} +Installing EEST and its dependencies via `uv sync --all-extras` fails with: + +```bash +Stored in directory: /tmp/... + Building wheel for coincurve (pyproject.toml) ... error + error: subprocess-exited-with-error + + Γ— Building wheel for coincurve (pyproject.toml) did not run successfully. + β”‚ exit code: 1 + ╰─> [27 lines of output] + ... + 571 | #include + | ^~~~~~~~~~~~~~~~~~~~~~~ + compilation terminated. + error: command '/usr/bin/gcc' failed with exit code 1 + [end of output] + + note: This error originates from a subprocess, and is likely not a problem with pip. + ERROR: Failed building wheel for coincurve +``` +{{< /callout >}} + +{{< callout success "Solution: Install the `libsecp256k1` library" >}} +On Ubuntu, you can install this library with: + +```bash +sudo apt update +sudo apt-get install libsecp256k1-dev +``` +{{< /callout >}} + +## Problem: `solc` Installation issues + +### Problem: `CERTIFICATE_VERIFY_FAILED` + +{{< callout danger "Problem: `Failed to ... CERTIFICATE_VERIFY_FAILED`" >}} +When running `fill` you might encounter the following error: + +```bash +Exit: Failed to ...: +``` +{{< /callout >}} + + + +{{< tabs >}} + +{{< tab "Ubuntu" >}} +{{< callout success "Solution: Update your system’s CA certificates" >}} +On Ubuntu, run the following commands: + +```bash +sudo apt-get update +sudo apt-get install ca-certificates +``` +{{< /callout >}} +{{< /tab >}} + +{{< tab "macOS" >}} +{{< callout success "Solution: Update your system’s CA certificates" >}} +On macOS, Python provides a built-in script to install the required certificates: + +```bash +/Applications/Python\ 3.11/Install\ Certificates.command +``` +{{< /callout >}} +{{< /tab >}} + +{{< /tabs >}} + + + +### Problem: `Exception: failed to compile yul source` + +{{< callout danger "Problem: `Running fill on static_tests fails with tests that contain yul source code` on ARM platforms" >}} +To resolve the issue you must acquire the `solc` binary e.g. by building solidity from source. The guide below installs v0.8.28 but you might prefer to choose a different version. +{{< /callout >}} + +{{< callout success "Solution: Build solc from source" >}} +The following steps have been tested on Ubuntu 24.04.2 LTS ARM64: +```bash +git clone --branch v0.8.28 --depth 1 https://github.com/ethereum/solidity.git +cd solidity && mkdir build && cd build +sudo apt install build-essential libboost-all-dev z3 +cmake .. +make +mv $HOME/Documents/execution-spec-tests/.venv/bin/solc $HOME/Documents/execution-spec-tests/.venv/bin/solc-x86-64 +cp ./solc/solc $HOME/Documents/execution-spec-tests/.venv/bin/ +chmod +x $HOME/Documents/execution-spec-tests/.venv/bin/solc +``` +Running `uv run solc --version` should now return the expected version. +{{< /callout >}} + +## Problem: `ValueError: unsupported hash type ripemd160` + +{{< callout danger "Problem: `Running fill fails with tests that use the RIPEMD160 precompile (0x03)`" >}} +When running `fill`, you encounter the following error: + +```python +ValueError: unsupported hash type ripemd160 +# or +ValueError: [digital envelope routines] unsupported +``` + +This is due to the removal of certain cryptographic primitives in OpenSSL 3. These were re-introduced in [OpenSSL v3.0.7](https://github.com/openssl/openssl/blob/master/CHANGES.md#changes-between-306-and-307-1-nov-2022). +{{< /callout >}} + +{{< callout success "Solution: Modify OpenSSL configuration" >}} +On platforms where OpenSSL v3.0.7 is unavailable (e.g., Ubuntu 22.04), modify your OpenSSL configuration to enable RIPEMD160. Make the following changes in the OpenSSL config file: + +```ini +[openssl_init] +providers = provider_sect + +# List of providers to load +[provider_sect] +default = default_sect +legacy = legacy_sect + +[default_sect] +activate = 1 + +[legacy_sect] +activate = 1 +``` + +This will enable the legacy cryptographic algorithms, including RIPEMD160. See [ethereum/execution-specs#506](https://github.com/ethereum/execution-specs/issues/506) for more information. +{{< /callout >}} + +## Other Issues Not Listed? + +If you're facing an issue that's not listed here, you can easily report it on GitHub for resolution. + +[Click here to report a documentation issue related to installation](https://github.com/ethereum/execution-spec-tests/issues/new?title=docs(bug):%20unable%20to%20install%20eest%20with%20error%20...&labels=scope:docs,type:bug&body=%3Ccopy-paste%20command%20that%20triggered%20the%20issue%20here%3E%0A%3Ccopy-paste%20output%20or%20attach%20screenshot%20here%3E) + +Please include the following details in your report: + +1. The command that triggered the issue. +2. Any relevant error messages or screenshots. +3. Relevant version information from the output of `uv run eest info` (if running consume from within `eest`). diff --git a/docs/getting_started/installation.md b/docs/content/main/getting_started/main.md similarity index 56% rename from docs/getting_started/installation.md rename to docs/content/main/getting_started/main.md index dbe3bf11e7b..fa8fd290cf5 100644 --- a/docs/getting_started/installation.md +++ b/docs/content/main/getting_started/main.md @@ -1,24 +1,40 @@ ++++ +title = 'Installation' +date = 2025-07-09T12:42:33Z +draft = false +[menu] + [menu.main] + name = 'Getting Started' + weight = 5 + pageRef = "/main/getting_started/main" + ++++ + # Installation ## Prerequisites -The tools provided by [execution-spec-tests](https://github.com/ethereum/execution-spec-tests) use `uv` ([docs.astral.sh/uv](https://docs.astral.sh/uv/)) to manage their dependencies and virtual environment. +The tools provided by [execution-spec-tests](https://github.com/ethereum/execution-spec-tests) use [`uv`](https://docs.astral.sh/uv/) to manage their dependencies and virtual environment.

-It's typically recommended to use the latest version of `uv`, currently `uv>=0.5.22` is required. +It's typically recommended to use the latest version of `uv`, currently `uv>=0.5.22` is required.

The latest version of `uv` can be installed via `curl` (recommended; can self-update via `uv self update`) or pip (requires Python, can't self-update): -=== "curl" +{{< tabs >}} - ```console - curl -LsSf https://astral.sh/uv/install.sh | sh - ``` +{{< tab "curl" >}} +```console +curl -LsSf https://astral.sh/uv/install.sh | sh +``` +{{< /tab >}} -=== "pip" +{{< tab "pip" >}} +```console +pip install uv +``` +{{< /tab >}} - ```console - pip install uv - ``` +{{< /tabs >}} If installed via `curl`, `uv` will download Python for your target platform if one of the required versions (Python 3.11 or 3.12) is not available natively. @@ -26,18 +42,23 @@ If installed via `curl`, `uv` will download Python for your target platform if o Clone [execution-spec-tests](https://github.com/ethereum/execution-spec-tests) and install its dependencies. We recommend using Python 3.12, the following uses `uv` to download and configures 3.12 to be the Python version used in execution-spec-tests: -=== "All platforms" +{{< tabs >}} - ```console +{{< tab "All platforms" >}} +```console git clone https://github.com/ethereum/execution-spec-tests cd execution-spec-tests uv python install 3.12 uv python pin 3.12 uv sync --all-extras - ``` +``` +{{< /tab >}} + +{{< /tabs >}} + -Static tests/maintainers only: To learn how to build the `solc` binary from source (optional) follow [this guide](./installation_troubleshooting.md#problem-exception-failed-to-compile-yul-source). +Static tests/maintainers only: To learn how to build the `solc` binary from source (optional) follow [this guide]({{< ref "./installation_troubleshooting.md#problem-exception-failed-to-compile-yul-source" >}}). ## Installation Troubleshooting -If you encounter issues during installation, see the [Installation Troubleshooting](./installation_troubleshooting.md) guide. +If you encounter issues during installation, see the [Installation Troubleshooting]({{< ref "./installation_troubleshooting.md" >}}) guide. diff --git a/docs/getting_started/repository_overview.md b/docs/content/main/getting_started/repository_overview.md similarity index 90% rename from docs/getting_started/repository_overview.md rename to docs/content/main/getting_started/repository_overview.md index 669a4647074..662009ecb9a 100644 --- a/docs/getting_started/repository_overview.md +++ b/docs/content/main/getting_started/repository_overview.md @@ -1,5 +1,7 @@ - -# Repository Overview ++++ +title = 'Repository Overview' +weight = 40 ++++ The most relevant folders and files in the repo are: @@ -43,4 +45,4 @@ Contains documentation configuration and source files. #### `.vscode/` -See [VS Code Setup](./setup_vs_code.md). +See [VS Code Setup]({{< ref "./setup_vs_code.md" >}}). diff --git a/docs/getting_started/setup_vs_code.md b/docs/content/main/getting_started/setup_vs_code.md similarity index 88% rename from docs/getting_started/setup_vs_code.md rename to docs/content/main/getting_started/setup_vs_code.md index 3b122fc9e6b..92322686731 100644 --- a/docs/getting_started/setup_vs_code.md +++ b/docs/content/main/getting_started/setup_vs_code.md @@ -1,8 +1,11 @@ -# VS Code Setup ++++ +title = 'VS Code Setup' +weight = 35 ++++ VS Code setup is optional, but does offer the following advantages: -- Auto-format your Python code to conform to the repository's [code standards](../writing_tests/code_standards.md) ([ruff](https://docs.astral.sh/ruff/)). +- Auto-format your Python code to conform to the repository's [code standards]({{< ref "code_standards.md" >}}) (we use [ruff](https://docs.astral.sh/ruff/)). - Inline linting and auto-completion (thanks to Python type hints). - Spell-check your code and docs. - Graphical exploration of test cases and easy test execution/debug. @@ -43,10 +46,8 @@ The extensions listed in `.vscode/extensions.json` are required for a smooth dev - [`ms-python.flake8`](https://marketplace.visualstudio.com/items?itemName=ms-python.flake8) - [`ms-python.black-formatter`](https://marketplace.visualstudio.com/items?itemName=ms-python.black-formatter) -
- ![Disabling extensions for the current workspace](./img/vscode_extension_disable_for_workspace.png){width=auto align=center} -
+ ![Disabling extensions for the current workspace](/images/getting_started/vscode_extension_disable_for_workspace.png) ## Configuration for Testing EVM Features Under Active Development -An additional step is required to enable fixture generations for features from forks that are under active development and have not been deployed to mainnet, see [Filling Tests for Features under Development](../filling_tests/filling_tests_dev_fork.md#vs-code-setup). +An additional step is required to enable fixture generations for features from forks that are under active development and have not been deployed to mainnet, see [Filling Tests for Features under Development]({{< ref "../filling_tests/filling_tests_dev_fork.md#vs-code-setup" >}}). diff --git a/docs/content/main/main.md b/docs/content/main/main.md new file mode 100644 index 00000000000..2e078cc917d --- /dev/null +++ b/docs/content/main/main.md @@ -0,0 +1,48 @@ ++++ +title = 'Execution Spec Tests' +date = 2025-07-09T12:42:33Z +draft = false +[menu] + [menu.main] + name = 'Execution Spec Tests' + weight = 1 + ++++ + +![Execution Spec Tests Logo](/images/main/execution_spec_tests.jpg) + +[ethereum/execution-spec-tests](https://github.com/ethereum/execution-spec-tests/) is both a collection of test cases and a framework in Python to generate tests for Ethereum execution clients. + +The framework collects and executes the test cases in order to generate _test fixtures_ (JSON) which can be consumed by any execution client to verify their implementation of [ethereum/execution-specs](https://github.com/ethereum/execution-specs). The fixtures, which define state transition and block tests, are generated by the framework using one of the `t8n` command-line tools that are provided by most execution clients, see below for an overview of the supported `t8n` tools. + +![Test Fixture Generation with execution-spec-tests](/images/main/fixture-gen-flowchart.png) + +The generated test fixtures can be used: + +1. Directly by client teams' test frameworks, and, +2. In the integration tests executed in the [ethereum/hive](https://github.com/ethereum/hive) framework. + +More information on how to use and download the [released test fixtures](https://github.com/ethereum/execution-spec-tests/releases) can be found [here]({{< ref "/main/running_tests/releases.md" >}}). + +## Relationship to ethereum/tests + +This collection of tests is relatively new (test case development started Q4, 2022) and mainly targets recent and upcoming Ethereum specification changes. It does not replace, but rather complements the existing tests in [ethereum/tests](https://github.com/ethereum/tests). + +## Motivation + +The motivation to implement test cases in [ethereum/execution-spec-tests](https://github.com/ethereum/execution-spec-tests) is: + +1. To implement test cases as code and ensure that changes, due to spec changes, for example, can be easily made. Moreover, changes are easily understandable and available in version control. +2. To avoid the 2-step approach often used in [ethereum/tests](https://github.com/ethereum/tests): + * Code (often unavailable) -> Test case (YAML). + * Test case (YAML) -> Fixtures (JSON). + +{{< callout success "Contributing" >}} +Contributions via [PR](https://github.com/ethereum/execution-spec-tests/pulls) are welcome! +{{< /callout >}} + +{{< callout danger "Reporting a Vulnerability" >}} +Care is required when adding PRs or issues for functionality that is live on Ethereum mainnet. Please report vulnerabilities and verify bounty eligibility via the [bug bounty program](https://ethereum.org/en/bug-bounty/). +- **Please do not create a PR with a vulnerability visible.** +- **Please do not file a public ticket mentioning the vulnerability.** +{{< /callout >}} diff --git a/docs/running_tests/consume/cache.md b/docs/content/main/running_tests/consume/cache.md similarity index 92% rename from docs/running_tests/consume/cache.md rename to docs/content/main/running_tests/consume/cache.md index 110fd9df406..3b97fbf053c 100644 --- a/docs/running_tests/consume/cache.md +++ b/docs/content/main/running_tests/consume/cache.md @@ -144,7 +144,7 @@ uv run consume cache --input stable@latest --cache-folder /path/to/custom/cache ## The Fixture Index File -The [`fill` command](../../filling_tests/index.md) generates a JSON file `/.meta/index.json` that indexes the fixtures its generated. This index file is used by `consume` commands to allow fast collection of test subsets specified on the command-line, for example, via the `--sim.limit` flag. For help with `--sim.limit` when running `./hive`, see [Hive Common Options](../hive/common_options.md), for an overview of other available test selection flags when running `consume` directly, see [Useful Pytest Options](../useful_pytest_options.md). +The [`fill` command](../../filling_tests/main.md) generates a JSON file `/.meta/index.json` that indexes the fixtures its generated. This index file is used by `consume` commands to allow fast collection of test subsets specified on the command-line, for example, via the `--sim.limit` flag. For help with `--sim.limit` when running `./hive`, see [Hive Common Options](../hive/common_options.md), for an overview of other available test selection flags when running `consume` directly, see [Useful Pytest Options](../useful_pytest_options.md). ## CI-Friendly Behavior for Direct URLs diff --git a/docs/running_tests/consume/direct.md b/docs/content/main/running_tests/consume/direct.md similarity index 90% rename from docs/running_tests/consume/direct.md rename to docs/content/main/running_tests/consume/direct.md index 350df0ead01..921d182a8ae 100644 --- a/docs/running_tests/consume/direct.md +++ b/docs/content/main/running_tests/consume/direct.md @@ -9,12 +9,12 @@ uv run consume direct --bin= [OPTIONS] - `--bin EVM_BIN`: Path to an evm executable that can process `StateTestFixture` and/or `BlockTestFixture` formats. - `--traces`: Collect execution traces from the evm executable. -!!! warning "Limited Client Support" +{{< callout warning "Limited Client Support" >}} +Currently, only the following clients can be used with `consume direct`: - Currently, only the following clients can be used with `consume direct`: - - - go-ethereum `statetest` and `blocktest`. - - Nethermind `nethtest`. +- go-ethereum `statetest` and `blocktest`. +- Nethermind `nethtest`. +{{< /callout >}} ## Advantages diff --git a/docs/running_tests/consume/exceptions.md b/docs/content/main/running_tests/consume/exceptions.md similarity index 95% rename from docs/running_tests/consume/exceptions.md rename to docs/content/main/running_tests/consume/exceptions.md index d68f3f720a0..65eaf77b400 100644 --- a/docs/running_tests/consume/exceptions.md +++ b/docs/content/main/running_tests/consume/exceptions.md @@ -92,8 +92,9 @@ uv run consume engine --disable-strict-exception-matching=nimbus,besu --sim.disable-strict-exception-matching=nimbus ``` -!!! warning "Production Testing" - Always enable strict exception matching for production test runs to ensure clients properly validate consensus rules. +{{< callout warning "Production Testing" >}} +Always enable strict exception matching for production test runs to ensure clients properly validate consensus rules. +{{< /callout >}} ## Debugging Exception Test Failures diff --git a/docs/running_tests/consume/index.md b/docs/content/main/running_tests/consume/main.md similarity index 77% rename from docs/running_tests/consume/index.md rename to docs/content/main/running_tests/consume/main.md index 040ba6b0e91..f1a6bdba066 100644 --- a/docs/running_tests/consume/index.md +++ b/docs/content/main/running_tests/consume/main.md @@ -1,3 +1,14 @@ ++++ +title = 'Consume' +date = 2025-07-09T12:42:33Z +draft = false +[menu] + [menu.main] + parent = 'Running Tests' + weight = 10 + ++++ + # The `consume` Command The EEST `consume` command implements different methods to run EEST-generated test fixtures against clients: @@ -6,9 +17,9 @@ The EEST `consume` command implements different methods to run EEST-generated te uv run consume [OPTIONS] SUBCOMMAND [ARGS]... ``` -For help with installation, see [Installation](../../getting_started/installation.md). +For help with installation, see [Installation](../../getting_started/main.md). -This section provides help for running the EEST commands directly (as opposed to running as a `./hive` [standalone command](../hive/index.md), where applicable) see: +This section provides help for running the EEST commands directly (as opposed to running as a `./hive` [standalone command](../hive/main.md), where applicable) see: 1. [Consume Cache & Fixture Inputs](./cache.md) for how to specify `consume` fixture input. diff --git a/docs/running_tests/consume/simulators.md b/docs/content/main/running_tests/consume/simulators.md similarity index 85% rename from docs/running_tests/consume/simulators.md rename to docs/content/main/running_tests/consume/simulators.md index f8b88306785..bb0e5e31b19 100644 --- a/docs/running_tests/consume/simulators.md +++ b/docs/content/main/running_tests/consume/simulators.md @@ -10,7 +10,7 @@ uv run consume [OPTIONS] ## Relevant Information -- To install the `consume` command, see [Installation](../../getting_started/installation.md). -- Help [setting up](../hive/index.md) and [starting Hive in dev mode](../hive/dev_mode.md). +- To install the `consume` command, see [Installation](../../getting_started/main.md). +- Help [setting up](../hive/main.md) and [starting Hive in dev mode](../hive/dev_mode.md). - For an explanation of how the `consume` simulators work, see the [Engine](../running.md#engine) and [RLP](../running.md#rlp) sections in [Running Tests](../running.md). - Help for relevant options can be found in [Consume Cache and Fixture Inputs](./cache.md) and [Useful Pytest Options](../useful_pytest_options.md). diff --git a/docs/running_tests/execute/hive.md b/docs/content/main/running_tests/execute/hive.md similarity index 96% rename from docs/running_tests/execute/hive.md rename to docs/content/main/running_tests/execute/hive.md index 3c8879ab168..dfe064c7451 100644 --- a/docs/running_tests/execute/hive.md +++ b/docs/content/main/running_tests/execute/hive.md @@ -10,7 +10,7 @@ The `blob_transaction_test` execute test spec sends blob transactions to a runni ./hive --client besu --client-file ./configs/osaka.yaml --sim ethereum/eest/execute-blobs ``` -See [Hive](../hive/index.md) for help installing and configuring Hive. +See [Hive](../hive/main.md) for help installing and configuring Hive. ## Running `execute` tests with Hive in Dev Mode diff --git a/docs/running_tests/execute/index.md b/docs/content/main/running_tests/execute/main.md similarity index 96% rename from docs/running_tests/execute/index.md rename to docs/content/main/running_tests/execute/main.md index 51d8e27e2f2..a1595cc1696 100644 --- a/docs/running_tests/execute/index.md +++ b/docs/content/main/running_tests/execute/main.md @@ -1,3 +1,14 @@ ++++ +title = 'Execute' +date = 2025-07-09T12:42:33Z +draft = false +[menu] + [menu.main] + parent = 'Running Tests' + weight = 10 + ++++ + # Executing Tests on Local Networks or Hive @ethereum/execution-spec-tests is capable of running tests on local networks or on Hive with a few considerations. The `execute` command runs test cases directly from the Python source (without the use of JSON fixtures). @@ -6,7 +17,6 @@ See: - [Execute Hive](./hive.md) for help with the `execute` simulator in order to run tests on a single-client local network. - [Execute Remote](./remote.md) for help with executing tests on a remote network such as a devnet, or even mainnet. -- [Execute Eth Config](./eth_config.md) for help verifying client configurations on a remote network such as a devnet, or even mainnet. The rest of this page describes how `execute` works and explains its architecture. diff --git a/docs/running_tests/execute/remote.md b/docs/content/main/running_tests/execute/remote.md similarity index 100% rename from docs/running_tests/execute/remote.md rename to docs/content/main/running_tests/execute/remote.md diff --git a/docs/running_tests/hive/ci_integration.md b/docs/content/main/running_tests/hive/ci_integration.md similarity index 100% rename from docs/running_tests/hive/ci_integration.md rename to docs/content/main/running_tests/hive/ci_integration.md diff --git a/docs/running_tests/hive/client_config.md b/docs/content/main/running_tests/hive/client_config.md similarity index 100% rename from docs/running_tests/hive/client_config.md rename to docs/content/main/running_tests/hive/client_config.md diff --git a/docs/running_tests/hive/common_options.md b/docs/content/main/running_tests/hive/common_options.md similarity index 100% rename from docs/running_tests/hive/common_options.md rename to docs/content/main/running_tests/hive/common_options.md diff --git a/docs/running_tests/hive/dev_mode.md b/docs/content/main/running_tests/hive/dev_mode.md similarity index 97% rename from docs/running_tests/hive/dev_mode.md rename to docs/content/main/running_tests/hive/dev_mode.md index 61b382ff440..6db9ac92126 100644 --- a/docs/running_tests/hive/dev_mode.md +++ b/docs/content/main/running_tests/hive/dev_mode.md @@ -18,8 +18,8 @@ This avoids running the simulator in a dockerized environment and has several ad ### Prerequisites -- EEST is installed, see [Installation](../../getting_started/installation.md) -- Hive is built, see [Hive](../hive/index.md#quick-start). +- EEST is installed, see [Installation](../../getting_started/main.md) +- Hive is built, see [Hive](../hive/main.md#quick-start). ## Hive Dev Setup on Linux diff --git a/docs/running_tests/hive/hiveview.md b/docs/content/main/running_tests/hive/hiveview.md similarity index 100% rename from docs/running_tests/hive/hiveview.md rename to docs/content/main/running_tests/hive/hiveview.md diff --git a/docs/running_tests/hive/index.md b/docs/content/main/running_tests/hive/main.md similarity index 83% rename from docs/running_tests/hive/index.md rename to docs/content/main/running_tests/hive/main.md index 81f75be5eec..bc91a7c88c1 100644 --- a/docs/running_tests/hive/index.md +++ b/docs/content/main/running_tests/hive/main.md @@ -1,3 +1,14 @@ ++++ +title = 'Hive' +date = 2025-07-09T12:42:33Z +draft = false +[menu] + [menu.main] + parent = 'Running Tests' + weight = 10 + ++++ + # Hive @ethereum/hive is a containerized testing framework that helps orchestrate test execution against Ethereum clients. Hive is incredibly extensible; new test suites can be implemented in a module manner as "simulators" that interact with clients to test certain aspects of their behavior. EEST implements several simulators, see [Running Tests](../running.md) for an overview. diff --git a/docs/content/main/running_tests/main.md b/docs/content/main/running_tests/main.md new file mode 100644 index 00000000000..d14f4f6f204 --- /dev/null +++ b/docs/content/main/running_tests/main.md @@ -0,0 +1,24 @@ ++++ +title = 'Running Tests' +date = 2025-07-09T12:42:33Z +draft = false +[menu] + [menu.main] + name = 'Running Tests' + weight = 20 + ++++ + +This section documents how EL clients can run EEST tests to verify their implementations. The information is organized as follows: + +1. **[Methods of Running Tests]({{< ref "running.md" >}}):** A detailed overview and comparison. + +2. **[EEST Fixture Releases]({{< ref "releases.md" >}}):** The available release types; release versioning. + +3. **[Test Fixture Specifications]({{< ref "test_formats/main.md" >}})** and guides to implement direct consumer interfaces. + +4. **[Hive]({{< ref "./hive/main.md" >}}):** Help running EEST Hive simulators. + +5. **[Consume]({{< ref "./consume/main.md" >}}):** Commands that help clients run tests by consuming test fixtures. + +6. **[Execute]({{< ref "./execute/main.md" >}}):** Commands that help clients run tests by executing test source. diff --git a/docs/running_tests/releases.md b/docs/content/main/running_tests/releases.md similarity index 98% rename from docs/running_tests/releases.md rename to docs/content/main/running_tests/releases.md index f4126366e4f..f89047730c3 100644 --- a/docs/running_tests/releases.md +++ b/docs/content/main/running_tests/releases.md @@ -1,8 +1,11 @@ -# EEST Fixture Releases ++++ +title = 'EEST Fixture Releases' +weight = 10 ++++ ## Formats and Release Layout -@ethereum/execution-spec-tests releases contain JSON test fixtures in various formats. Note that transaction type tests are executed directly from Python source using the [`execute`](./execute/index.md) command. +@ethereum/execution-spec-tests releases contain JSON test fixtures in various formats. Note that transaction type tests are executed directly from Python source using the [`execute`](./execute/main.md) command. | Format | Consumed by the client | Location in `.tar.gz` release | | -------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------- | diff --git a/docs/running_tests/running.md b/docs/content/main/running_tests/running.md similarity index 83% rename from docs/running_tests/running.md rename to docs/content/main/running_tests/running.md index 7c5535d0fcc..3d39e323f94 100644 --- a/docs/running_tests/running.md +++ b/docs/content/main/running_tests/running.md @@ -1,4 +1,7 @@ -# Methods of Running Tests ++++ +title = 'Methods of Running Tests' +weight = 5 ++++ EEST has two commands, `consume` and `execute`, that run test cases against EL clients: @@ -22,9 +25,9 @@ Both `consume` and `execute` provide sub-commands which correspond to different The following sections describe the different methods in more detail. -!!! note "`./hive --sim=eest/consume-engine` vs `consume engine`" - - EEST simulators can be ran either standalone using the `./hive` command or via an EEST command against a `./hive --dev` backend, more details are [provided below](#two-methods-to-run-eest-simulators). +{{< callout info "`./hive --sim=eest/consume-engine` vs `consume engine`" >}} +EEST simulators can be ran either standalone using the `./hive` command or via an EEST command against a `./hive --dev` backend, more details are [provided below](#two-methods-to-run-eest-simulators). +{{< /callout >}} ## Direct @@ -38,9 +41,9 @@ The direct method provides the fastest way to test EVM functionality by executin The EEST `consume direct` command is a small wrapper around client direct interfaces that allows fast and easy selection of test subsets to execute via [test ID](../filling_tests/test_ids.md) regex match (thanks to [an index file](./consume/cache.md#the-fixture-index-file)). See [Consume Direct](./consume/direct.md) and the [Cache and Fixture Inputs](./consume/cache.md) and [Useful Pytest Options](./useful_pytest_options.md) pages for help with options. -!!! tip "Rapid EVM development" - - The [`direct` method](./consume/direct.md) with the [`StateTest` format](./test_formats/state_test.md) should be used for the fastest EVM development feedback loop. Additionally, EVM traces can be readily generated and compared to other implementations. +{{< callout info "Rapid EVM development" >}} +The [`direct` method](./consume/direct.md) with the [`StateTest` format](./test_formats/state_test.md) should be used for the fastest EVM development feedback loop. Additionally, EVM traces can be readily generated and compared to other implementations. +{{< /callout >}} ## Engine @@ -83,7 +86,7 @@ This method simulates how clients import blocks during historical sync, testing ## Engine vs RLP Simulator -The RLP Simulator (`eest/consume-rlp`) and the Engine Simulator (`eest/consume-engine`) should be seen as complimentary to one another. Although they execute the same underlying EVM test cases, the block validation logic is executed via different client code paths (using different [fixture formats](./test_formats/index.md)). Therefore, ideally, **both simulators should be executed for full coverage**. +The RLP Simulator (`eest/consume-rlp`) and the Engine Simulator (`eest/consume-engine`) should be seen as complimentary to one another. Although they execute the same underlying EVM test cases, the block validation logic is executed via different client code paths (using different [fixture formats](./test_formats/main.md)). Therefore, ideally, **both simulators should be executed for full coverage**. ### Code Path Choices @@ -100,17 +103,17 @@ Clients consume fixtures in the `eest/consume-engine` simulator via the Engine A | **Interface** | Block import upon start-up via RLP files | Engine API calls (`newPayload`, `forkchoiceUpdated`) | | **Exception testing** | Basic exception handling | Advanced exception verification with client-specific mappers | -!!! hint "Running both simulators adds some redundancy that can assist test debugging" - - If Engine tests fail but RLP tests pass, the issue is likely in your Engine API implementation rather than core EVM logic. +{{< callout info "Running both simulators adds some redundancy that can assist test debugging" >}} +If Engine tests fail but RLP tests pass, the issue is likely in your Engine API implementation rather than core EVM logic. +{{< /callout >}} ## Execute -See [Execute Command](./execute/index.md). +See [Execute Command](./execute/main.md). ## Two Methods to Run EEST Simulators Many of the methods use the Hive Testing Environment to interact with clients and run tests against them. These methods are also called Hive simulators. While Hive is always necessary to run simulators, they can be called in two different ways. Both of these commands execute the same simulator code, but in different environments, we take the example of the `eest/consume-engine` simulator: -1. `./hive --sim=eest/consume-engine` is a standalone command that installs EEST and the `consume` command in a dockerized container managed by Hive. This is the standard method to execute EEST [fixture releases](./releases.md) against clients in CI environments and is the method to generate the results at [hive.ethpandaops.io](https://hive.ethpandaops.io). See [Hive](./hive/index.md) and its [Common Options](./hive/common_options.md) for help with this method. -2. `uv run consume engine` requires the user to clone and [install EEST](../getting_started/installation.md) and start a Hive server in [development mode](./hive/dev_mode.md). In this case, the simulator runs on the native system and communicate to the client via the Hive API. This is particularly useful during test development as fixtures on the local disk can be specified via `--input=fixtures/`. As the simulator runs natively, it is easy to drop into a debugger and inspect the simulator or client container state. See [Hive Developer Mode](./hive/dev_mode.md) for help with this method. +1. `./hive --sim=eest/consume-engine` is a standalone command that installs EEST and the `consume` command in a dockerized container managed by Hive. This is the standard method to execute EEST [fixture releases](./releases.md) against clients in CI environments and is the method to generate the results at [hive.ethpandaops.io](https://hive.ethpandaops.io). See [Hive](./hive/main.md) and its [Common Options](./hive/common_options.md) for help with this method. +2. `uv run consume engine` requires the user to clone and [install EEST](../getting_started/main.md) and start a Hive server in [development mode](./hive/dev_mode.md). In this case, the simulator runs on the native system and communicate to the client via the Hive API. This is particularly useful during test development as fixtures on the local disk can be specified via `--input=fixtures/`. As the simulator runs natively, it is easy to drop into a debugger and inspect the simulator or client container state. See [Hive Developer Mode](./hive/dev_mode.md) for help with this method. diff --git a/docs/running_tests/test_formats/blockchain_test.md b/docs/content/main/running_tests/test_formats/blockchain_test.md similarity index 100% rename from docs/running_tests/test_formats/blockchain_test.md rename to docs/content/main/running_tests/test_formats/blockchain_test.md diff --git a/docs/running_tests/test_formats/blockchain_test_engine.md b/docs/content/main/running_tests/test_formats/blockchain_test_engine.md similarity index 100% rename from docs/running_tests/test_formats/blockchain_test_engine.md rename to docs/content/main/running_tests/test_formats/blockchain_test_engine.md diff --git a/docs/running_tests/test_formats/blockchain_test_engine_x.md b/docs/content/main/running_tests/test_formats/blockchain_test_engine_x.md similarity index 100% rename from docs/running_tests/test_formats/blockchain_test_engine_x.md rename to docs/content/main/running_tests/test_formats/blockchain_test_engine_x.md diff --git a/docs/running_tests/test_formats/common_types.md b/docs/content/main/running_tests/test_formats/common_types.md similarity index 100% rename from docs/running_tests/test_formats/common_types.md rename to docs/content/main/running_tests/test_formats/common_types.md diff --git a/docs/running_tests/test_formats/exceptions.md b/docs/content/main/running_tests/test_formats/exceptions.md similarity index 100% rename from docs/running_tests/test_formats/exceptions.md rename to docs/content/main/running_tests/test_formats/exceptions.md diff --git a/docs/running_tests/test_formats/index.md b/docs/content/main/running_tests/test_formats/main.md similarity index 58% rename from docs/running_tests/test_formats/index.md rename to docs/content/main/running_tests/test_formats/main.md index c6901807bee..dc849018a9c 100644 --- a/docs/running_tests/test_formats/index.md +++ b/docs/content/main/running_tests/test_formats/main.md @@ -1,3 +1,14 @@ ++++ +title = 'Test Formats' +date = 2025-07-09T12:42:33Z +draft = false +[menu] + [menu.main] + parent = 'Running Tests' + weight = 10 + ++++ + # Test Fixture Specifications The following sub-sections provide: diff --git a/docs/running_tests/test_formats/state_test.md b/docs/content/main/running_tests/test_formats/state_test.md similarity index 100% rename from docs/running_tests/test_formats/state_test.md rename to docs/content/main/running_tests/test_formats/state_test.md diff --git a/docs/running_tests/test_formats/transaction_test.md b/docs/content/main/running_tests/test_formats/transaction_test.md similarity index 100% rename from docs/running_tests/test_formats/transaction_test.md rename to docs/content/main/running_tests/test_formats/transaction_test.md diff --git a/docs/running_tests/useful_pytest_options.md b/docs/content/main/running_tests/useful_pytest_options.md similarity index 90% rename from docs/running_tests/useful_pytest_options.md rename to docs/content/main/running_tests/useful_pytest_options.md index 6a5c7f6d7d9..5cd3ade80d5 100644 --- a/docs/running_tests/useful_pytest_options.md +++ b/docs/content/main/running_tests/useful_pytest_options.md @@ -1,4 +1,7 @@ -# Useful Pytest Options ++++ +title = 'Useful Pytest Options' +weight = 15 ++++ The EEST commands to run tests are customizations to the pytest framework, which provides many helpful options for test selection, parallel execution, report output and debugging. This section provides the most relevant options, a full overview is available in the [pytest docs](https://docs.pytest.org/en/8.3.x/). @@ -14,7 +17,7 @@ List collected tests, `-q` restricts output to [test IDs](../filling_tests/test_ uv run consume engine --input= --collect-only -q ``` -In `./hive` [standalone mode](./hive/index.md), this can be achieved via EEST's [`--sim.limit` "collectonly" prefix](./hive/common_options.md#collect-onlydry-run). +In `./hive` [standalone mode](./hive/main.md), this can be achieved via EEST's [`--sim.limit` "collectonly" prefix](./hive/common_options.md#collect-onlydry-run). ## Output Control @@ -71,8 +74,9 @@ Combine marks with keyword filtering: uv run consume engine --input= -m "blockchain_test" -k "eip4844 or blob" ``` -!!! note "Mark Availability" - Not all test marks are available with consume commands. Fork and test type marks work reliably. +{{< callout info "Mark Availability" >}} +Not all test marks are available with consume commands. Fork and test type marks work reliably. +{{< /callout >}} ## Parallel Execution diff --git a/docs/writing_tests/adding_a_new_test.md b/docs/content/main/writing_tests/adding_a_new_test.md similarity index 96% rename from docs/writing_tests/adding_a_new_test.md rename to docs/content/main/writing_tests/adding_a_new_test.md index a9c8befa9cd..d46b7f05408 100644 --- a/docs/writing_tests/adding_a_new_test.md +++ b/docs/content/main/writing_tests/adding_a_new_test.md @@ -1,4 +1,7 @@ -# Adding a New Test ++++ +title = 'Adding a New Test' +weight = 5 ++++ All test cases are located underneath the `tests` directory, which are then organized by fork. Each fork contains sub-directories containing test sub-categories. diff --git a/docs/writing_tests/checklist_templates/eip_testing_checklist_template.md b/docs/content/main/writing_tests/checklist_templates/eip_testing_checklist_template.md similarity index 100% rename from docs/writing_tests/checklist_templates/eip_testing_checklist_template.md rename to docs/content/main/writing_tests/checklist_templates/eip_testing_checklist_template.md diff --git a/docs/writing_tests/checklist_templates/index.md b/docs/content/main/writing_tests/checklist_templates/main.md similarity index 51% rename from docs/writing_tests/checklist_templates/index.md rename to docs/content/main/writing_tests/checklist_templates/main.md index ec798641680..41ce6932a23 100644 --- a/docs/writing_tests/checklist_templates/index.md +++ b/docs/content/main/writing_tests/checklist_templates/main.md @@ -1,3 +1,14 @@ ++++ +title = 'Checklist Templates' +date = 2025-07-09T12:42:33Z +draft = false +[menus] + [menus.main] + parent = 'Writing Tests' + weight = 10 + ++++ + # Testing Checklist Templates This page includes checklist templates that must be followed to guarantee a minimum base testing coverage of new EIP feature. diff --git a/docs/content/main/writing_tests/eest_make_test.gif b/docs/content/main/writing_tests/eest_make_test.gif new file mode 100644 index 00000000000..e2842a9f6ba Binary files /dev/null and b/docs/content/main/writing_tests/eest_make_test.gif differ diff --git a/docs/writing_tests/eip_checklist.md b/docs/content/main/writing_tests/eip_checklist.md similarity index 99% rename from docs/writing_tests/eip_checklist.md rename to docs/content/main/writing_tests/eip_checklist.md index 26b722490e1..ed232f2677e 100644 --- a/docs/writing_tests/eip_checklist.md +++ b/docs/content/main/writing_tests/eip_checklist.md @@ -1,4 +1,7 @@ -# EIP Checklist Generation ++++ +title = 'EIP Checklist Generation' +weight = 50 ++++ The EIP checklist feature helps track test coverage for EIP implementations by automatically generating filled checklists based on test markers. diff --git a/docs/writing_tests/exception_tests.md b/docs/content/main/writing_tests/exception_tests.md similarity index 98% rename from docs/writing_tests/exception_tests.md rename to docs/content/main/writing_tests/exception_tests.md index af5d65aabe6..eee05a660de 100644 --- a/docs/writing_tests/exception_tests.md +++ b/docs/content/main/writing_tests/exception_tests.md @@ -1,4 +1,7 @@ -# Exception Tests ++++ +title = 'Exception Tests' +weight = 35 ++++ Exception tests are a special type of test which verify that an invalid transaction or an invalid block are correctly rejected with the expected error. diff --git a/docs/writing_tests/fork_methods.md b/docs/content/main/writing_tests/fork_methods.md similarity index 99% rename from docs/writing_tests/fork_methods.md rename to docs/content/main/writing_tests/fork_methods.md index 44e75693712..2519b5b4dfe 100644 --- a/docs/writing_tests/fork_methods.md +++ b/docs/content/main/writing_tests/fork_methods.md @@ -1,4 +1,7 @@ -# Using and Extending Fork Methods ++++ +title = 'Using and Extending Fork Methods' +weight = 40 ++++ This document describes the Fork class in the Ethereum execution spec tests framework, which provides a standardized way to define properties of Ethereum forks. Understanding how to use and extend these fork methods is essential for writing flexible tests that can automatically adapt to different forks. diff --git a/docs/content/main/writing_tests/main.md b/docs/content/main/writing_tests/main.md new file mode 100644 index 00000000000..23be002ef58 --- /dev/null +++ b/docs/content/main/writing_tests/main.md @@ -0,0 +1,32 @@ ++++ +title = 'Writing Tests' +date = 2025-07-09T12:42:33Z +draft = false +[menu] + [menu.main] + name = 'Writing Tests' + weight = 12 + ++++ + +The easiest way to get started is to use the interactive CLI: + +```console +uv run eest make test +``` + +and modify the generated test module to suit your needs. + +![Gif that shows how to create a test in EEST](/images/writing_tests/eest_make_test.gif) + +For help deciding which test format to select, see [Types of Tests]({{< ref "types_of_tests.md" >}}), in particular [Deciding on a Test Type]({{< ref "types_of_tests.md#deciding-on-a-test-type" >}}). + +## Key Resources + +- [Coding Standards]({{< ref "code_standards.md#code-standards" >}}) - Code style and standards for this repository +- [Adding a New Test]({{< ref "adding_a_new_test.md" >}}) - Step-by-step guide to adding new tests +- [Writing a New Test]({{< ref "writing_a_new_test.md" >}}) - Detailed guide on writing different test types +- [Using and Extending Fork Methods]({{< ref "fork_methods.md" >}}) - How to use fork methods to write fork-adaptive tests +- [Porting tests]({{< ref "porting_legacy_tests.md" >}}): A guide to porting [ethereum/tests](https://github.com/ethereum/tests) to EEST. + +Please check that your code adheres to the repo's coding standards and read the other pages in this section for more background and an explanation of how to implement state transition and blockchain tests. diff --git a/docs/writing_tests/porting_legacy_tests.md b/docs/content/main/writing_tests/porting_legacy_tests.md similarity index 82% rename from docs/writing_tests/porting_legacy_tests.md rename to docs/content/main/writing_tests/porting_legacy_tests.md index 813cd0ce3ea..91aae753794 100644 --- a/docs/writing_tests/porting_legacy_tests.md +++ b/docs/content/main/writing_tests/porting_legacy_tests.md @@ -1,4 +1,7 @@ -# A Guide to Porting Original Ethereum Tests to EEST ++++ +title = 'Porting Legacy Tests' +weight = 65 ++++ ## Background @@ -17,7 +20,7 @@ While automating the conversion of the remaining YAML (or JSON) test cases to Py 1. Select one or more test cases from `./tests/static/state_tests/` to port and create an issue in this repository AND comment on [this tracker issue.](https://github.com/ethereum/execution-spec-tests/issues/972) -2. [Add a new test](../writing_tests/index.md) in the appropriate fork folder, following the guidelines for [choosing a test type.](../writing_tests/types_of_tests.md#deciding-on-a-test-type) +2. [Add a new test](../writing_tests/main.md) in the appropriate fork folder, following the guidelines for [choosing a test type.](../writing_tests/types_of_tests.md#deciding-on-a-test-type) 3. Submit a PR with the ported tests: @@ -100,13 +103,13 @@ Follow the hyperlinks for lost base coverage (`LBC`) to address coverage gaps. H > Lost line coverage from a coverage report. In this case, caused by a missing invocation of `CALLDATALOAD`. -!!! note "Expected coverage loss" +{{< callout info "Expected coverage loss" >}} +EEST uses [pytest](https://docs.pytest.org/en/stable/), a popular Python testing framework, to help orchestrate testing Ethereum specifications, while _original tests_ relied on large, static contracts and the EVM to handle much of the execution. This difference can lead to coverage gaps. EEST favors dynamic contract creation for each test vector, while _original tests_ preferred a single static contract with multiple test vectors determined by transaction input data. - EEST uses [pytest](https://docs.pytest.org/en/stable/), a popular Python testing framework, to help orchestrate testing Ethereum specifications, while _original tests_ relied on large, static contracts and the EVM to handle much of the execution. This difference can lead to coverage gaps. EEST favors dynamic contract creation for each test vector, while _original tests_ preferred a single static contract with multiple test vectors determined by transaction input data. +It's important to note that coverage helps identify missing test paths. If you believe the coverage loss is due to differences in "setup" code between frameworks and doesn't impact the feature you're testing, explain this in your PR. A team member can help with the review. - It's important to note that coverage helps identify missing test paths. If you believe the coverage loss is due to differences in "setup" code between frameworks and doesn't impact the feature you're testing, explain this in your PR. A team member can help with the review. - - For example, review the [discussion in this PR] to see an example of why and how coverage loss can occur.(https://github.com/ethereum/execution-spec-tests/pull/975#issuecomment-2528792289) +For example, review the [discussion in this PR](https://github.com/ethereum/execution-spec-tests/pull/975#issuecomment-2528792289) to see an example of why and how coverage loss can occur. +{{< /callout >}} ## Resolving Coverage Gaps from Yul Compilation @@ -124,5 +127,6 @@ If coverage analysis shows missing opcodes that were only present due to Yul com ) ``` -!!! note "Add coverage_missed_reason only after PR review" - Only add `coverage_missed_reason` after PR review determines the coverage gap is acceptable, never preemptively. This helps maintain test coverage integrity while accounting for legitimate differences between Yul-based and EEST opcode-based implementations. +{{< callout info "Add coverage_missed_reason only after PR review" >}} +Only add `coverage_missed_reason` after PR review determines the coverage gap is acceptable, never preemptively. This helps maintain test coverage integrity while accounting for legitimate differences between Yul-based and EEST opcode-based implementations. +{{< /callout >}} \ No newline at end of file diff --git a/docs/writing_tests/post_mortems.md b/docs/content/main/writing_tests/post_mortems.md similarity index 98% rename from docs/writing_tests/post_mortems.md rename to docs/content/main/writing_tests/post_mortems.md index 6e2db8e0cef..762f57472de 100644 --- a/docs/writing_tests/post_mortems.md +++ b/docs/content/main/writing_tests/post_mortems.md @@ -1,4 +1,7 @@ -# Post-Mortems of Missed Test Scenarios ++++ +title = 'Post-Mortems' +weight = 55 ++++ This page contains a collection of post-mortem analyses for test cases that were not initially identified by the testing process. diff --git a/docs/writing_tests/reference_specification.md b/docs/content/main/writing_tests/reference_specification.md similarity index 53% rename from docs/writing_tests/reference_specification.md rename to docs/content/main/writing_tests/reference_specification.md index 347a79075bb..efd135e6388 100644 --- a/docs/writing_tests/reference_specification.md +++ b/docs/content/main/writing_tests/reference_specification.md @@ -1,47 +1,46 @@ -# Referencing an EIP Spec Version ++++ +title = 'Referencing an EIP Spec Version' +weight = 45 ++++ Tests that implement features from an Ethereum Improvement Proposal ([ethereum/EIPs](https://github.com/ethereum/EIPs/tree/master/EIPS)) must define the EIP's markdown SHA digest within the test's Python module. This ensures our tests stay up-to-date with any changes to the EIP specifications. The `check_eip_versions` command-line utility automatically verifies that all EIP references in the codebase are current. It works by comparing the SHA specified in the test against the latest version in the ethereum/EIPs repository. This utility uses pytest to generate test cases for every module that includes "eip" in its path. -
- ![Test framework summary for a failing EIP spec version test](./img/eip_reference_spec_console_output.png){ width=auto align=center} -
+![Test framework summary for a failing EIP spec version test](/imgages/writing_tests/eip_reference_spec_console_output.png) -!!! note "The SHA digest value is provided in the failure message of the corresponding test" +{{< callout info "The SHA digest value is provided in the failure message of the corresponding test" >}} +![EIP spec version test fail](/images/writing_tests/eip_reference_spec_console_output_fail.png) +{{< /callout >}} -
- ![EIP spec version test fail](./img/eip_reference_spec_console_output_fail.png){ width=auto align=center} -
+{{< callout info "Understanding and Retrieving the EIP Markdown's SHA Digest" >}} +The SHA value is the output from git's `hash-object` command, for example: -!!! info "Understanding and Retrieving the EIP Markdown's SHA Digest" - - The SHA value is the output from git's `hash-object` command, for example: - - ```console - git clone git@github.com:ethereum/EIPs - git hash-object EIPS/EIPS/eip-3651.md - # output: d94c694c6f12291bb6626669c3e8587eef3adff1 - ``` +```console +git clone git@github.com:ethereum/EIPs +git hash-object EIPS/EIPS/eip-3651.md +# output: d94c694c6f12291bb6626669c3e8587eef3adff1 +``` - and can be retrieved from the remote repo via the Github API on the command-line as following: +and can be retrieved from the remote repo via the Github API on the command-line as following: - ```console - sudo apt install jq - curl -s -H "Accept: application/vnd.github.v3+json" \ - https://api.github.com/repos/ethereum/EIPs/contents/EIPS/eip-3651.md |\ - jq -r '.sha' - # output: d94c694c6f12291bb6626669c3e8587eef3adff1 - ``` +```console +sudo apt install jq +curl -s -H "Accept: application/vnd.github.v3+json" \ +https://api.github.com/repos/ethereum/EIPs/contents/EIPS/eip-3651.md |\ +jq -r '.sha' +# output: d94c694c6f12291bb6626669c3e8587eef3adff1 +``` +{{< /callout >}} ## How to Add a Spec Version Check This check accomplished by adding the following two global variables anywhere in the Python source file: -| Variable Name | Explanation | -| ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `REFERENCE_SPEC_GIT_PATH` | The relative path of the EIP markdown file in the [ethereum/EIPs](https://github.com/ethereum/EIPs/) repository, e.g. "`EIPS/eip-1234.md`" | -| `REFERENCE_SPEC_VERSION` | The SHA hash of the latest version of the file retrieved from the Github API:
`https://api.github.com/repos/ethereum/EIPs/contents/EIPS/eip-.md` | +{{< table headers="Variable Name|Explanation" >}} +`REFERENCE_SPEC_GIT_PATH`|The relative path of the EIP markdown file in the [ethereum/EIPs](https://github.com/ethereum/EIPs/) repository, e.g. "`EIPS/eip-1234.md`"|| +`REFERENCE_SPEC_VERSION`|The SHA hash of the latest version of the file retrieved from the Github API: `https://api.github.com/repos/ethereum/EIPs/contents/EIPS/eip-.md` +{{< /table >}} ## Running the `check_eip_versions` Command Locally @@ -69,11 +68,11 @@ This workflow uses GitHub's built-in token for authentication, so there's no nee ## Example -Here is an example from [./tests/shanghai/eip3651_warm_coinbase/test_warm_coinbase.py](../tests/shanghai/eip3651_warm_coinbase/test_warm_coinbase/index.md): +Here is an example from [./tests/shanghai/eip3651_warm_coinbase/test_warm_coinbase.py](https://github.com/ethereum/execution-spec-tests/blob/0f7c73a7e177abf58cdba116a3b4275e9be9a61b/tests/shanghai/eip3651_warm_coinbase/test_warm_coinbase.py#L26-L27): ```python REFERENCE_SPEC_GIT_PATH = "EIPS/eip-3651.md" REFERENCE_SPEC_VERSION = "d94c694c6f12291bb6626669c3e8587eef3adff1" ``` -The SHA digest was retrieved [from here](https://api.github.com/repos/ethereum/EIPs/contents/EIPS/eip-3651.md). +While the code uses variable names the shown constants can be found in `spec.py`. The SHA digest was retrieved [from here](https://api.github.com/repos/ethereum/EIPs/contents/EIPS/eip-3651.md). diff --git a/docs/writing_tests/test_markers.md b/docs/content/main/writing_tests/test_markers.md similarity index 74% rename from docs/writing_tests/test_markers.md rename to docs/content/main/writing_tests/test_markers.md index 97a04948adb..500316db5a8 100644 --- a/docs/writing_tests/test_markers.md +++ b/docs/content/main/writing_tests/test_markers.md @@ -1,4 +1,7 @@ -# Test Markers ++++ +title = 'Test Markers' +weight = 20 ++++ Test markers are used to categorize tests and to run specific subsets of tests. They are defined in the test files using the `pytest.mark` decorator. @@ -10,19 +13,120 @@ These markers are used to specify the forks for which a test is valid. ### `@pytest.mark.valid_from("FORK_NAME")` -:::pytest_plugins.forks.forks.ValidFrom +Bases: `ValidityMarker` +Marker used to specify the fork from which the test is valid. The test will not be filled for forks before the specified fork. + +```python +import pytest + +from ethereum_test_tools import Alloc, StateTestFiller + +@pytest.mark.valid_from("London") +def test_something_only_valid_after_london( + state_test: StateTestFiller, + pre: Alloc +): + pass +``` + +In this example, the test will only be filled for the London fork and after, e.g. London, Paris, Shanghai, Cancun, etc. + +
+ +--- + ### `@pytest.mark.valid_until("FORK_NAME")` +Bases: `ValidityMarker` + +Marker to specify the fork until which the test is valid. The test will not be filled for forks after the specified fork. -:::pytest_plugins.forks.forks.ValidUntil +```python +import pytest +from ethereum_test_tools import Alloc, StateTestFiller + +@pytest.mark.valid_until("London") +def test_something_only_valid_until_london( + state_test: StateTestFiller, + pre: Alloc +): + pass +``` + +In this example, the test will only be filled for the London fork and before, e.g. London, Berlin, Istanbul, etc. + +
+ +--- + ### `@pytest.mark.valid_at("FORK_NAME_1", "FORK_NAME_2", ...)` +Bases: `ValidityMarker` + +Marker to specify each fork individually for which the test is valid. + +```python +import pytest -:::pytest_plugins.forks.forks.ValidAt +from ethereum_test_tools import Alloc, StateTestFiller +@pytest.mark.valid_at("London", "Cancun") +def test_something_only_valid_at_london_and_cancun( + state_test: StateTestFiller, + pre: Alloc +): + pass +``` + +In this example, the test will only be filled for the London and Cancun forks. + +
+ +--- + ### `@pytest.mark.valid_at_transition_to("FORK_NAME")` +Bases: `ValidityMarker` + +Marker to specify that a test is only meant to be filled at the transition to the specified fork. + +The test usually starts at the fork prior to the specified fork at genesis and at block 5 (for pre-merge forks) or at timestamp 15,000 (for post-merge forks) the fork transition occurs. + +```python +import pytest + +from ethereum_test_tools import Alloc, BlockchainTestFiller + +@pytest.mark.valid_at_transition_to("London") +def test_something_that_happens_during_the_fork_transition_to_london( + blockchain_test: BlockchainTestFiller, + pre: Alloc +): + pass +``` -:::pytest_plugins.forks.forks.ValidAtTransitionTo +In this example, the test will only be filled for the fork that transitions to London at block number 5, BerlinToLondonAt5, and no other forks. + +To see or add a new transition fork, see the ethereum_test_forks.forks.transition module. + +Note that the test uses a BlockchainTestFiller fixture instead of a StateTestFiller, as the transition forks are used to test changes throughout the blockchain progression, and not just the state change of a single transaction. + +This marker also accepts the following keyword arguments: + +- subsequent_transitions: Force the test to also fill for subsequent fork transitions. +- until: Implies subsequent_transitions and puts a limit on which transition fork will the test filling will be limited to. + +For example: +```python +@pytest.mark.valid_at_transition_to("Cancun", subsequent_transitions=True) +``` +produces tests on `ShanghaiToCancunAtTime15k` and `CancunToPragueAtTime15k`, and any transition fork after that. +And: +```python +@pytest.mark.valid_at_transition_to("Cancun", subsequent_transitions=True, until="Prague") +``` +produces tests on ShanghaiToCancunAtTime15k and CancunToPragueAtTime15k, but no forks after Prague. + + ## Fork Covariant Markers @@ -49,12 +153,20 @@ def test_something_with_all_tx_types( In this example, the test will be parameterized for parameter `tx_type` with values `[0, 1]` for fork Berlin, but with values `[0, 1, 2]` for fork London (because of EIP-1559). +
+ +--- + ### `@pytest.mark.with_all_contract_creating_tx_types` This marker is used to automatically parameterize a test with all contract creating transaction types that are valid for the fork being tested. This marker only differs from `pytest.mark.with_all_tx_types` in that it does not include transaction type 3 (Blob Transaction type) on fork Cancun and after. +
+ +--- + ### `@pytest.mark.with_all_precompiles` This marker is used to automatically parameterize a test with all precompiles that are valid for the fork being tested. @@ -76,6 +188,10 @@ def test_something_with_all_precompiles( In this example, the test will be parameterized for parameter `precompile` with values `[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]` for fork Shanghai, but with values `[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]` for fork Cancun which introduced the [point evaluation precompile](https://eips.ethereum.org/EIPS/eip-4844#point-evaluation-precompile) defined in EIP-4844. +
+ +--- + ### `@pytest.mark.with_all_evm_code_types` This marker is used to automatically parameterize a test with all EVM code types that are valid for the fork being tested. @@ -129,6 +245,10 @@ def test_something_with_all_evm_code_types( ... ``` +
+ +--- + ### `@pytest.mark.with_all_call_opcodes` This marker is used to automatically parameterize a test with all EVM call opcodes that are valid for the fork being tested. @@ -153,6 +273,10 @@ In this example, the test will be parametrized for parameter `call_opcode` with Parameter `evm_code_type` will also be parametrized with the correct EVM code type for the opcode under test. +
+ +--- + ### `@pytest.mark.with_all_create_opcodes` This marker is used to automatically parameterize a test with all EVM create opcodes that are valid for the fork being tested. @@ -177,6 +301,10 @@ In this example, the test will be parametrized for parameter `create_opcode` wit Parameter `evm_code_type` will also be parametrized with the correct EVM code type for the opcode under test. +
+ +--- + ### `@pytest.mark.with_all_system_contracts` This marker is used to automatically parameterize a test with all system contracts that are valid for the fork being tested. @@ -200,6 +328,10 @@ def test_something_with_all_system_contracts( In this example, the test will be parameterized for parameter `system_contract` with value `[0x000F3DF6D732807EF1319FB7B8BB8522D0BEAC02]` for fork Cancun. +
+ +--- + ### Covariant Marker Keyword Arguments All fork covariant markers accept the following keyword arguments: @@ -329,7 +461,7 @@ In this example, the test will be marked as expected to fail when it is being ex ### `@pytest.mark.slow` -This marker is used to mark tests that are slow to run. These tests are not run during [`tox` checks](./verifying_changes.md), and are only run when a release is being prepared. +This marker is used to mark tests that are slow to run. These tests are not run during [`tox` checks]({{< ref "../getting_started/code_standards_details.md" >}}), and are only run when a release is being prepared. ### `@pytest.mark.pre_alloc_modify` diff --git a/docs/writing_tests/tutorials/blockchain.md b/docs/content/main/writing_tests/tutorials/blockchain.md similarity index 97% rename from docs/writing_tests/tutorials/blockchain.md rename to docs/content/main/writing_tests/tutorials/blockchain.md index d6082529d5c..2e87f7557b5 100644 --- a/docs/writing_tests/tutorials/blockchain.md +++ b/docs/content/main/writing_tests/tutorials/blockchain.md @@ -6,7 +6,7 @@ This tutorial teaches you to create a blockchain execution specification test. T Before proceeding with this tutorial, it is assumed that you have prior knowledge and experience with the following: -- Repository set-up, see [installation](../../getting_started/installation.md).and run an execution specification test as outlined in the . +- Repository set-up, see [installation](../../getting_started/main.md).and run an execution specification test as outlined in the . - Able to run `fill`, see [Getting Started: Filling Tests](../../filling_tests/getting_started.md). - Understand how to read a [blockchain test](https://ethereum-tests.readthedocs.io/en/latest/test_filler/blockchain_filler.html). - Familiarity with [Python](https://docs.python.org/3/tutorial/). diff --git a/docs/content/main/writing_tests/tutorials/main.md b/docs/content/main/writing_tests/tutorials/main.md new file mode 100644 index 00000000000..b5893d81d3f --- /dev/null +++ b/docs/content/main/writing_tests/tutorials/main.md @@ -0,0 +1,13 @@ ++++ +title = 'Tutorials' +date = 2025-07-09T12:42:33Z +draft = false +[menus] + [menus.main] + parent = 'Writing Tests' + weight = 10 + ++++ + +# Tutorials +Show overview of existing tutorials \ No newline at end of file diff --git a/docs/writing_tests/tutorials/state_transition.md b/docs/content/main/writing_tests/tutorials/state_transition.md similarity index 94% rename from docs/writing_tests/tutorials/state_transition.md rename to docs/content/main/writing_tests/tutorials/state_transition.md index 3377a9e0983..a3cbf033358 100644 --- a/docs/writing_tests/tutorials/state_transition.md +++ b/docs/content/main/writing_tests/tutorials/state_transition.md @@ -8,7 +8,7 @@ For an overview of different test types available, see [Types of Tests](../../wr This tutorial will require some prior knowledge and experience with the following: -- Repository set-up, see [installation](../../getting_started/installation.md). +- Repository set-up, see [installation](../../getting_started/main.md). - Ability to run `fill`, see [Getting Started: Filling Tests](../../filling_tests/getting_started.md). - Basic familiarity with [Python](https://docs.python.org/3/tutorial/). @@ -47,18 +47,19 @@ In this case, the decorator is a custom [pytest mark](https://docs.pytest.org/en For more information about test markers and fork validity, see [Test Markers](../../writing_tests/test_markers.md). -!!! info "Filling the test" - To fill this test for all the specified forks, we can specify pytest's `-k` flag that [filters test cases by keyword expression](https://docs.pytest.org/en/latest/how-to/usage.html#specifying-tests-selecting-tests): +{{< callout info "Filling the test" >}} +To fill this test for all the specified forks, we can specify pytest's `-k` flag that [filters test cases by keyword expression](https://docs.pytest.org/en/latest/how-to/usage.html#specifying-tests-selecting-tests): - ```console - fill -k test_state_test_example - ``` +```console +fill -k test_state_test_example +``` - and to fill it for a specific fork range, we can provide the `--from` and `--until` command-line arguments: +and to fill it for a specific fork range, we can provide the `--from` and `--until` command-line arguments: - ```console - fill -k test_state_test_example --from London --until Paris - ``` +```console +fill -k test_state_test_example --from London --until Paris +``` +{{< /callout >}} ```python def test_state_test_example(state_test: StateTestFiller, pre: Alloc): diff --git a/docs/writing_tests/types_of_tests.md b/docs/content/main/writing_tests/types_of_tests.md similarity index 86% rename from docs/writing_tests/types_of_tests.md rename to docs/content/main/writing_tests/types_of_tests.md index 97c3914f53f..6d934078619 100644 --- a/docs/writing_tests/types_of_tests.md +++ b/docs/content/main/writing_tests/types_of_tests.md @@ -1,4 +1,7 @@ -# Types of tests ++++ +title = 'Types of Test' +weight = 10 ++++ There are currently three types of tests that can be produced by a test spec: @@ -19,9 +22,9 @@ Tests the effects of individual transactions (ideally a single one) that span a - Test interactions between multiple smart contracts. - Test creation of smart contracts. -!!! info - - The fill function will automatically generate a `blockchain_test` fixture from `state_tests`, consisting of one block and one transaction. +{{< callout info "Info" >}} +The fill function will automatically generate a `blockchain_test` fixture from `state_tests`, consisting of one block and one transaction. +{{< /callout >}} ## Blockchain Tests @@ -63,9 +66,9 @@ Test correct transaction rejection/acceptance of a serialized transaction (curre - Verify that a badly formatted transaction is correctly rejected by the client. - Verify that a transaction with an invalid value in one of its fields is correctly rejected by the client. -!!! info - - Using the `execute` command, transaction tests can be sent to clients in a live network using the `eth_sendRawTransaction` endpoint. +{{< callout info "Note" >}} +Using the `execute` command, transaction tests can be sent to clients in a live network using the `eth_sendRawTransaction` endpoint. +{{< /callout >}} ## Deciding on a test type diff --git a/docs/writing_tests/writing_a_new_test.md b/docs/content/main/writing_tests/writing_a_new_test.md similarity index 79% rename from docs/writing_tests/writing_a_new_test.md rename to docs/content/main/writing_tests/writing_a_new_test.md index 89e4197b902..3cbcb8b0589 100644 --- a/docs/writing_tests/writing_a_new_test.md +++ b/docs/content/main/writing_tests/writing_a_new_test.md @@ -1,15 +1,18 @@ -# Writing a New Test ++++ +title = 'Writing a New Test' +weight = 15 ++++ ## Test Functions -Every test case is defined as a Python function that implements a single `StateTest` or `BlockchainTest` using the `state_test` or `blockchain_test` objects made available by the framework ([learn how to decide on a test type](./types_of_tests.md#deciding-on-a-test-type)). Test cases, and the respective test modules, must fulfill the following requirements: +Every test case is defined as a Python function that implements a single `StateTest` or `BlockchainTest` using the `state_test` or `blockchain_test` objects made available by the framework ([learn how to decide on a test type]({{< ref "./types_of_tests.md#deciding-on-a-test-type" >}})). Test cases, and the respective test modules, must fulfill the following requirements: -| Requirement | When | -| -----------------------------------------------------------------------|---------------------------------------------| -| Be [decorated with validity markers](#specifying-which-forks-tests-are-valid-for) | If the test case is not valid for all forks | -| Use one of `state_test` or `blockchain_test` [in its function arguments](#the-state_test-and-blockchain_test-test-function-arguments) | Always | -| Call the `state_test` or `blockchain_test` in its test body | Always | -| Add a [reference version of the EIP spec](./reference_specification.md) under test | Test path contains `eip` | +{{< table headers="Requirement|When" >}} +Be [decorated with validity markers](#specifying-which-forks-tests-are-valid-for) | If the test case is not valid for all forks || +Use one of `state_test` or `blockchain_test` [in its function arguments](#the-state_test-and-blockchain_test-test-function-arguments) | Always || +Call the `state_test` or `blockchain_test` in its test body | Always || +Add a [reference version of the EIP spec]({{< ref "./reference_specification.md" >}}) under test | Test path contains `eip` || +{{< /table >}} ### Specifying which Forks Tests are Valid For @@ -23,38 +26,42 @@ or markers on either the test function, test class or test module level: -=== "Function" +{{< tabs >}} - ```python - import pytest - - @pytest.mark.valid_from("Berlin") - @pytest.mark.valid_until("London") - def test_access_list(state_test: StateTestFiller, fork: Fork): - ``` - -=== "Class" +{{< tab "Function" >}} +```python +import pytest - ```python - import pytest +@pytest.mark.valid_from("Berlin") +@pytest.mark.valid_until("London") +def test_access_list(state_test: StateTestFiller, fork: Fork): +``` +{{< /tab >}} +{{< tab "Class" >}} +```python +import pytest - @pytest.mark.valid_from("Shanghai") - class TestMultipleWithdrawalsSameAddress: - ``` -=== "Module" +@pytest.mark.valid_from("Shanghai") +class TestMultipleWithdrawalsSameAddress: +``` +{{< /tab >}} - ```python - import pytest +{{< tab "Module" >}} +```python +import pytest - pytestmark = pytest.mark.valid_from("Shanghai") - ``` +pytestmark = pytest.mark.valid_from("Shanghai") +``` +{{< /tab >}} -The [`ethereum_test_forks`](../library/ethereum_test_forks.md) package defines the available forks and provides the following helpers that return all forks within the specified range: +{{< /tabs >}} + +The ethereum_test_forks package defines the available forks and provides the following helpers that return all forks within the specified range: -- [forks_from](../library/ethereum_test_forks.md#ethereum_test_forks.forks_from) -- [forks_from_until](../library/ethereum_test_forks.md#ethereum_test_forks.forks_from_until) +- forks_from +- forks_from_until ### The `state_test` and `blockchain_test` Test Function Arguments @@ -146,11 +153,11 @@ which allows checking for an exact `gas_used` value. ## Writing code for the accounts in the test -Account bytecode can be "deployed" in a test's pre-state using the `pre` pytest fixture. The @ethereum/execution-spec-tests Python [`Opcodes`][ethereum_test_vm.Opcodes] minilang can be used to help write the bytecode in a readable form. +Account bytecode can be "deployed" in a test's pre-state using the `pre` pytest fixture. The execution-spec-tests Python [`Opcodes`](https://github.com/ethereum/execution-spec-tests/blob/28d2299f4260d38d98215ab3f28aee8aa6340bae/src/ethereum_test_vm/opcode.py) minilang can be used to help write the bytecode in a readable form. ### Using the Python Opcode Minilang -EVM bytecode for tests should be written using the Python-based minilang provided by the [`Opcodes`][ethereum_test_vm.Opcodes] class. This allows you to construct bytecode using symbolic opcodes as Python objects. +EVM bytecode for tests should be written using the Python-based minilang provided by the `Opcodes` class. This allows you to construct bytecode using symbolic opcodes as Python objects. #### Example: Simple Addition Contract @@ -170,13 +177,13 @@ code = ( contract_address = pre.deploy_contract(code=code) ``` -You add this contract to the test's pre-state using the `pre` fixture or assign this `code` to the `code` field of an account in your test's `post` state. See the [state test tutorial](./tutorials/state_transition.md) for more help. +You add this contract to the test's pre-state using the `pre` fixture or assign this `code` to the `code` field of an account in your test's `post` state. See the [state test tutorial]({{< ref "./tutorials/state_transition.md" >}}) for more help. -For a full list of available opcodes and their usage, see [`Opcodes`][ethereum_test_vm.Opcodes]. +For a full list of available opcodes and their usage, see [`Opcodes`](https://github.com/ethereum/execution-spec-tests/blob/28d2299f4260d38d98215ab3f28aee8aa6340bae/src/ethereum_test_vm/opcode.py). #### Higher-Level Constructs -For more complex control flow, you can use constructs like [`Switch`][ethereum_test_tools.code.generators.Switch] and [`Case`][ethereum_test_tools.code.generators.Case] from the `ethereum_test_tools.code.generators` module: +For more complex control flow, you can use constructs like `Switch` and `Case` from the `ethereum_test_tools.code.generators` module: ```python from ethereum_test_tools.code.generators import Switch, Case @@ -191,11 +198,11 @@ code = Switch( ) ``` -The `ethereum_test_tools.code.generators` module also defines other high-level constructs like [`While`][ethereum_test_tools.code.generators.While] and [`Conditional`][ethereum_test_tools.code.generators.Conditional]. +The `ethereum_test_tools.code.generators` module also defines other high-level constructs like `While` and `Conditional`. #### Converting Bytecode to Minilang -If you have EVM bytecode (as hex or binary), you can use the [`evm_bytes` CLI tool](../library/cli/evm_bytes.md) to convert it to the EEST Python opcode minilang automatically, for example: +If you have EVM bytecode (as hex or binary), you can use the [`evm_bytes` CLI tool](https://github.com/ethereum/execution-spec-tests/blob/28d2299f4260d38d98215ab3f28aee8aa6340bae/src/cli/evm_bytes.py) to convert it to the EEST Python opcode minilang automatically, for example: ```console uv run evm_bytes hex-string 0x604260005260206000F3 @@ -323,8 +330,6 @@ current fork under test, and does not need to be parametrized. Tests can also be automatically parametrized with appropriate fork covariant values using the `with_all_*` markers listed in the -[Test Markers](./test_markers.md#fork-covariant-markers) page. - -### The `extend_with_defaults` Utility +[Test Markers]({{< ref "./test_markers.md#fork-covariant-markers" >}}) page. -::: ethereum_test_tools.utility.pytest.extend_with_defaults + \ No newline at end of file diff --git a/docs/dev/coding_style.md b/docs/dev/coding_style.md deleted file mode 100644 index 6772746ca0b..00000000000 --- a/docs/dev/coding_style.md +++ /dev/null @@ -1,4 +0,0 @@ -# Coding Style - -!!! warning "Documentation Moved" - This documentation has been relocated to [Getting Started -> Code Standards](../getting_started/code_standards.md). Please use the new location for the most up-to-date information. diff --git a/docs/dev/docs.md b/docs/dev/docs.md deleted file mode 100644 index 4a4f389cce1..00000000000 --- a/docs/dev/docs.md +++ /dev/null @@ -1,177 +0,0 @@ -# Documentation - -The `execution-spec-tests` documentation is generated via [`mkdocs`](https://www.mkdocs.org/) and hosted remotely on Github Pages at [eest.ethereum.org](https://eest.ethereum.org/). - -## Prerequisites - -```console -uv sync --all-extras -``` - -## Build and Verify the Documentation - -One time build in strict mode: - -```console -uv run mkdocs build --strict -``` - -Perform all docs related checks via `tox` in parallel: - -```console -uvx --with=tox-uv tox -e spellcheck,markdownlint,mkdocs --parallel -``` - -### Local Deployment and Test - -This runs continually: Deploys the site locally and re-generates the site upon modifications to `docs/**/*.md` or `tests/**/*.py`: - -```console -uv run mkdocs serve -``` - -For more help (including ensuring a clean build), see the `gen_test_doc` pytest plugin's documentation: - -::: src.pytest_plugins.filler.gen_test_doc.gen_test_doc - options: - members: no - -## Remote Deployment and Versioning - -The execution-specs-test docs are hosted using Github pages at [eest.ethereum.org](https://eest.ethereum.org/). Versions are updated/deployed automatically as part of Github Actions, but this can also be performed on the command-line. - -Our mkdocs configuration uses [mike](https://github.com/jimporter/mike) as a version provider. All deployments should be made via `mike` (whether as part of CI/CD or executed locally). - -The deployed versions of the docs managed via `mike` are kept in the [gh-pages](https://github.com/ethereum/execution-spec-tests/tree/gh-pages) branch. When you run `mike` it commits to this branch and optionally pushes the changes directly to remote. - -### Aliases - -We currently have two aliases (which both point to `main` as of [#998](https://github.com/ethereum/execution-spec-tests/pull/998)): - -- [`latest`](https://eest.ethereum.org/latest): the current state of the main branch. -- [`development`](https://eest.ethereum.org/development): the current state of the main branch. - -These aliases point to specific versions, as configured below. It's possible to share links containing either of these aliases or to specific versions, i.e, the following are all valid links: - -- https://eest.ethereum.org/ (redirects to latest/main) -- https://eest.ethereum.org/latest (redirects to main) -- https://eest.ethereum.org/development (redirects main) -- https://eest.ethereum.org/main -- https://eest.ethereum.org/v1.0.0 - -### CI/CD: Doc Deployment via Github Actions - -There are two workflows that automatically deploy updated/new versions of the docs: - -| Workflow `yaml` File | What | When | -|----------------------|------|------| -| `docs_main.yaml` | Update "main" version of docs | Push to 'main' branch, (e.g., on PR merge) | -| `docs_tags.yaml` | Deploy new version of docs; tag is used as version name | Upon creating a tag matching `v*` | - -### Build and Deployment (without alias update) - -Build a new version and deploy it to remote (this version will then show up in the version selector list): - -```console -uv run mike deploy -rebase --push v1.2.3 -``` - -!!! note "Local deployment" - If you deploy locally, the documentation will be built with any changes made in your local repository. Check out the tag to deploy tagged versions. - -### Build, Deploy and Update the Alias - -Build, deploy and update the version an alias points to with: - -```console -uv run mike deploy --rebase --push --update-aliases v1.2.3 latest -``` - -where `v1.2.3` indicates the version's name and `development` is the alias. This will overwrite the version if it already exists. - -!!! note "Updating the 'main' version locally" - "main" is just a version name (intended to reflect that it is build from the main branch). However, `mike` will build the docs site from the current local repository state (including local modifications). Therefore, make sure you're on the HEAD of the main branch before executing (unless you know what you're doing :wink:)! - - ```console - uv run mike deploy --rebase --push main - ``` - - If the alias accidentally go change: - - ```console - uv run mike deploy --rebase --push --update-aliases main development - ``` - -### Viewing and Deleting Versions - -List versions: - -```console -uv run mike list -``` - -Delete a version: - -```console -uv run mike delete v1.2.3a1-eof -``` - -### Set Default Version - -Set the default version of the docs to open upon loading the page: - -```console -uv run mike set-default --push latest -``` - -Typically, this must only be executed once for a repo. - -## Implementation - -### Plugins - -The documentation flow uses `mkdocs` and the following additional plugins: - -- [mkdocs](https://www.mkdocs.org/): The main doc generation tool. -- [mkdocs-material](https://squidfunk.github.io/mkdocs-material): Provides many additional features and styling for mkdocs. -- [mkdocstrings](https://mkdocstrings.github.io/) and [mkdocstrings-python](https://mkdocstrings.github.io/python/): To generate documentation from Python docstrings. -- [mkdocs-gen-files](https://oprypin.github.io/mkdocs-gen-files): To generate markdown files automatically for each test case Python module. See [this page](https://mkdocstrings.github.io/crystal/quickstart/migrate.html) for example usage. This plugin is used to [programmatically generate the nav section](https://oprypin.github.io/mkdocs-gen-files/extras.html) for the generated test case reference documentation. -- [mkdocs-literate-nav](https://oprypin.github.io/mkdocs-literate-nav/index.html): Is used to define the navigation layout for non-generated content and was created to work well with `mkdocs-gen-files` to add nav content for generated content. -- @blueswen/mkdocs-glightbox - for improved image and inline content display. - -### The "Test Case Reference" Section - -This section is auto-generated via a combination of: - -1. [mkdocstrings](https://mkdocstrings.github.io/) and [mkdocstrings-python](https://mkdocstrings.github.io/python/), -2. [mkdocs-gen-files](https://oprypin.github.io/mkdocs-gen-files), -3. [mkdocs-literate-nav](https://oprypin.github.io/mkdocs-literate-nav/index.html). - -It auto-generates a sequence of nested pages (with nav entries) of all python modules detected under `./tests`. Each page contains a stub to the doc generated by mkdocstrings from the module's docstrings and source code. The mkdocs-gen-files and mkdocs-literate-nav plugins were created exactly for [this purpose](https://mkdocstrings.github.io/crystal/quickstart/migrate.html). - -No action is necessary if a new test directory or module is added to `./tests`, it will be picked up automatically. - -!!! info "Working with generated content" - The files in the `./tests` directory are watched by `mkdocs serve`. Run `mkdocs serve` and edit the source docstrings: The browser will reload with the new content automatically. - -### Navigation - -All pages that are to be included in the documentation and the navigation bar must be included in `navigation.md`, except "Test Case Reference" entries. This is enabled by [mkdocs-literate-nav](https://oprypin.github.io/mkdocs-literate-nav/index.html). The nav entries for the automatically generated "Test Case Reference" section are generated in [mkdocs-gen-files](https://oprypin.github.io/mkdocs-gen-files) and appended to `navigation.md`. - -!!! info "Current nav ordering limitations" - The "Test Case Reference" section must currently be the last section in the nav. This is because our mkdocs flow: - - 1. Reads `navigation.md`. - 2. Generates the Test Case Reference documentation and appends the Test Case Reference entries to `navigation.md` - 3. Generates the nav. - - If necessary, we could probably split `navigation.md` into two files - - - `navigation-pre-test-case-reference.md`, - - `navigation-post-test-case-reference.md`, - - and create an arbitrary ordering in the Test Case Reference doc gen script. But this is untested. - -## Read the Docs - -Originally, before June 2023, documentation was hosted at readthedocs.io. Currently, this page no longer exists (execution-spec-tests.readthedocs.io). diff --git a/docs/filling_tests/filling_tests_vs_code.md b/docs/filling_tests/filling_tests_vs_code.md deleted file mode 100644 index bf04ef90d95..00000000000 --- a/docs/filling_tests/filling_tests_vs_code.md +++ /dev/null @@ -1,20 +0,0 @@ -# Filling Tests in VS Code - -Prerequisite: [VS Code Setup](../getting_started/setup_vs_code.md). - -## Exploring Test Cases - -Implemented test cases can be explored in VS Code's "Testing" View; click on the conical flask highlighted in the screenshot below. - -
- ![VS Code Testing Tab](./img/vs_code_exploring_tests.png){ width=auto align=center} -
- -!!! note "Testing EVM Features Under Active Development" - See [the VS Code section](./filling_tests_dev_fork.md#vs-code-setup) in [Filling Tests for Features under Development](./filling_tests_dev_fork.md) to explore tests targeting EVM features under development. - -## Filling and Debugging Test Cases - -
- ![VS Code Testing Tab](./img/vs_code_executing_tests.png){ width=auto align=center} -
diff --git a/docs/filling_tests/img/vs_code_executing_tests.kra b/docs/filling_tests/img/vs_code_executing_tests.kra deleted file mode 100644 index 31e3f463660..00000000000 Binary files a/docs/filling_tests/img/vs_code_executing_tests.kra and /dev/null differ diff --git a/docs/getting_started/code_standards.md b/docs/getting_started/code_standards.md deleted file mode 100644 index 63148bf9e21..00000000000 --- a/docs/getting_started/code_standards.md +++ /dev/null @@ -1,101 +0,0 @@ -# Code Standards - -This document outlines the coding standards and practices used in the @ethereum/execution-spec-tests repository. - -## Code and CI Requirements - -Code pushed to @ethereum/execution-spec-tests must fulfill the following checks in [CI](https://github.com/ethereum/execution-spec-tests/actions/workflows/tox_verify.yaml): - -| Type | Tox Command | Explanation | -| ---------------------- | ----------------------------------------------- | ----------------------------------------------------------------------------------------------------------- | -| Lint & code formatting | `uvx --with=tox-uv tox -e lint` | Python lint, format and module import check via `ruff` | -| Typecheck | `uvx --with=tox-uv tox -e typecheck` | Objects that provide typehints pass type-checking via `mypy`. | -| Framework unit tests | `uvx --with=tox-uv tox -e pytest` | All framework unit tests must execute correctly. | -| EL Client test cases | `uvx --with=tox-uv tox -e tests-deployed` | All client test cases for deployed forks can be generated. | -| Benchmark EL Test cases | `uvx --with=tox-uv tox -e tests-deployed-benchmark` | All client test cases specific to benchmarks for deployed forks can be generated. | -| HTML doc build | `uvx --with=tox-uv tox -e mkdocs` | Documentation generated without warnings. | -| Spellcheck | `uvx --with=tox-uv tox -e spellcheck` | Code and documentation spell-check using codespell. | -| Markdown lint | `uvx --with=tox-uv tox -e markdownlint` | Markdown lint (requires [additional dependency](code_standards_details.md#additional-dependencies)). | -| Changelog validation | `uvx --with=tox-uv tox -e changelog` | Validates changelog entries format and structure in `docs/CHANGELOG.md`. | - -!!! important "Avoid CI surprises - Use pre-commit hooks!" - **We strongly encourage all contributors to install and use pre-commit hooks!** This will run fast checks (lint, typecheck, spellcheck) automatically before each commit, helping you catch issues early and avoid frustrating CI failures after pushing your changes. - - Install with one simple command: - ```console - uvx pre-commit install - ``` - - This saves you time by catching formatting issues, type errors, and spelling mistakes before they reach CI. - -!!! tip "Running checks easily" - - Add an alias: - - ```console - alias tox="uvx --with=tox-uv tox" - ``` - - Run all checks in parallel: - - ```console - uvx --with=tox-uv tox run-parallel - ``` - - Run sequentially: - - ```console - uvx --with=tox-uv tox - ``` - - Run specific, faster checks: - - ```console - uvx --with=tox-uv tox -e lint,typecheck - ``` - -!!! tip "Lint & code formatting: Using `ruff` and VS Code to help autoformat and fix module imports" - - On the command-line, solve fixable issues with: - - ```console - uv run ruff check --fix - ``` - - Use VS Code, see [VS Code Setup](../getting_started/setup_vs_code.md), to autoformat code, automatically organize Python module imports and highlight typechecking and spelling issues. - -!!! hint "Typechecking" - - Adding the correct typehints can sometimes be tricky and there are exceptions that require manually disabling typechecking on a per-line basis. Please reach out to the maintainers if you need help, either [directly](../getting_started/getting_help.md) or in a PR. - -## Python Coding Preferences - -- **Line Length**: 100 characters maximum. -- **Formatting**: Enforced by `ruff` (similar to `black`). -- **Documentation**: All public functions and classes should have docstrings - - Docstrings should have a good one-line summary which uses the imperative ("Return" not "Returns"). - - Add a blank line after the summary for multi-line docstrings. - - Single-line docstrings should have triple quotes on the same line. -- **Imports**: Use explicit imports (no `from module import *`). -- **Relative Imports**: Use relative imports within the same package -- **Error Handling**: Use explicit exception types and meaningful error messages. -- **Type Hints**: All functions should include type annotations. -- **Variable Naming**: - - Use `snake_case` for variables, functions, and modules. - - Use `PascalCase` for classes. - - Use `UPPER_CASE` for constants. -- **File Paths**: Strongly prefer `pathlib` over `os.path` for file system operations. - -## Editor Setup - -A correctly configured editor will automatically handle most formatting requirements. See [VS Code Setup](./setup_vs_code.md) for recommended settings. - -## Detailed Information - -See the [Detailed Code Standards](code_standards_details.md) page for more information on: - -- [Running tox environments](code_standards_details.md#running-tox-environments). - - Additional required [dependencies for markdownlint and spellchecking](code_standards_details.md#additional-dependencies). -- [Pre-commit hooks setup](code_standards_details.md#pre-commit-hooks). -- [Verifying test fixture changes](code_standards_details.md#verifying-fixture-changes). -- [Ignoring bulk change commits](code_standards_details.md#ignoring-bulk-change-commits) in `git blame`. diff --git a/docs/getting_started/installation_troubleshooting.md b/docs/getting_started/installation_troubleshooting.md deleted file mode 100644 index 12cdb775ded..00000000000 --- a/docs/getting_started/installation_troubleshooting.md +++ /dev/null @@ -1,130 +0,0 @@ -# Installation Troubleshooting - -This page provides guidance on how to troubleshoot common issues that may arise when installing [ethereum/execution-spec-tests](https://github.com/ethereum/execution-spec-tests). - -## Problem: `Failed building wheel for coincurve` - -!!! danger "Problem: `Failed building wheel for coincurve`" - Installing EEST and its dependencies via `uv sync --all-extras` fails with: - - ```bash - Stored in directory: /tmp/... - Building wheel for coincurve (pyproject.toml) ... error - error: subprocess-exited-with-error - - Γ— Building wheel for coincurve (pyproject.toml) did not run successfully. - β”‚ exit code: 1 - ╰─> [27 lines of output] - ... - 571 | #include - | ^~~~~~~~~~~~~~~~~~~~~~~ - compilation terminated. - error: command '/usr/bin/gcc' failed with exit code 1 - [end of output] - - note: This error originates from a subprocess, and is likely not a problem with pip. - ERROR: Failed building wheel for coincurve - ``` - -!!! success "Solution: Install the `libsecp256k1` library" - On Ubuntu, you can install this library with: - - ```bash - sudo apt update - sudo apt-get install libsecp256k1-dev - ``` - -## Problem: `solc` Installation issues - -### Problem: `CERTIFICATE_VERIFY_FAILED` - -!!! danger "Problem: `Failed to ... CERTIFICATE_VERIFY_FAILED`" - When running `fill` you might encounter the following error: - - ```bash - Exit: Failed to ...: - ``` - -=== "Ubuntu" - - !!! success "Solution: Update your system’s CA certificates" - On Ubuntu, run the following commands: - - ```bash - sudo apt-get update - sudo apt-get install ca-certificates - ``` - -=== "macOS" - - !!! success "Solution: Update your system’s CA certificates" - On macOS, Python provides a built-in script to install the required certificates: - - ```bash - /Applications/Python\ 3.11/Install\ Certificates.command - ``` - -### Problem: `Exception: failed to compile yul source` - -!!! danger "Problem: `Running fill on static_tests fails with tests that contain yul source code` on ARM platforms" - To resolve the issue you must acquire the `solc` binary e.g. by building solidity from source. The guide below installs v0.8.28 but you might prefer to choose a different version. - -!!! success "Solution: Build solc from source" - The following steps have been tested on Ubuntu 24.04.2 LTS ARM64: - ```bash - git clone --branch v0.8.28 --depth 1 https://github.com/ethereum/solidity.git - cd solidity && mkdir build && cd build - sudo apt install build-essential libboost-all-dev z3 - cmake .. - make - mv $HOME/Documents/execution-spec-tests/.venv/bin/solc $HOME/Documents/execution-spec-tests/.venv/bin/solc-x86-64 - cp ./solc/solc $HOME/Documents/execution-spec-tests/.venv/bin/ - chmod +x $HOME/Documents/execution-spec-tests/.venv/bin/solc - ``` - Running `uv run solc --version` should now return the expected version. - -## Problem: `ValueError: unsupported hash type ripemd160` - -!!! danger "Problem: `Running fill fails with tests that use the RIPEMD160 precompile (0x03)`" - When running `fill`, you encounter the following error: - - ```python - ValueError: unsupported hash type ripemd160 - # or - ValueError: [digital envelope routines] unsupported - ``` - - This is due to the removal of certain cryptographic primitives in OpenSSL 3. These were re-introduced in [OpenSSL v3.0.7](https://github.com/openssl/openssl/blob/master/CHANGES.md#changes-between-306-and-307-1-nov-2022). - -!!! success "Solution: Modify OpenSSL configuration" - On platforms where OpenSSL v3.0.7 is unavailable (e.g., Ubuntu 22.04), modify your OpenSSL configuration to enable RIPEMD160. Make the following changes in the OpenSSL config file: - - ```ini - [openssl_init] - providers = provider_sect - - # List of providers to load - [provider_sect] - default = default_sect - legacy = legacy_sect - - [default_sect] - activate = 1 - - [legacy_sect] - activate = 1 - ``` - - This will enable the legacy cryptographic algorithms, including RIPEMD160. See [ethereum/execution-specs#506](https://github.com/ethereum/execution-specs/issues/506) for more information. - -## Other Issues Not Listed? - -If you're facing an issue that's not listed here, you can easily report it on GitHub for resolution. - -[Click here to report a documentation issue related to installation](https://github.com/ethereum/execution-spec-tests/issues/new?title=docs(bug):%20unable%20to%20install%20eest%20with%20error%20...&labels=scope:docs,type:bug&body=%3Ccopy-paste%20command%20that%20triggered%20the%20issue%20here%3E%0A%3Ccopy-paste%20output%20or%20attach%20screenshot%20here%3E) - -Please include the following details in your report: - -1. The command that triggered the issue. -2. Any relevant error messages or screenshots. -3. Relevant version information from the output of `uv run eest info` (if running consume from within `eest`). diff --git a/docs/hugo.toml b/docs/hugo.toml new file mode 100644 index 00000000000..1a26557e708 --- /dev/null +++ b/docs/hugo.toml @@ -0,0 +1,11 @@ +baseURL = 'https://example.org/' +languageCode = 'en-us' +title = 'EEST Docs' +theme = "minimal" +sectionPagesMenu = "" +[markup] +[markup.goldmark.renderer] + unsafe = true + +[params] + sectionPagesMenu = "" # Disable auto menu generation \ No newline at end of file diff --git a/docs/index.md b/docs/index.md deleted file mode 100644 index 5c18851bb2c..00000000000 --- a/docs/index.md +++ /dev/null @@ -1,82 +0,0 @@ -# Execution Spec Tests - -
- ![Execution Spec Tests Logo](img/execution_spec_tests.jpg) -
- -@ethereum/execution-spec-tests is both a collection of test cases and a framework in Python to generate tests for Ethereum execution clients. - -The framework collects and executes the test cases in order to generate _test fixtures_ (JSON) which can be consumed by any execution client to verify their implementation of [ethereum/execution-specs](https://github.com/ethereum/execution-specs). The fixtures, which define state transition and block tests, are generated by the framework using one of the `t8n` command-line tools that are provided by most execution clients, see below for an overview of the supported `t8n` tools. - -```mermaid ---- -title: Test Fixture Generation with execution-spec-tests ---- -flowchart LR - style C stroke:#333,stroke-width:2px - style D stroke:#333,stroke-width:2px - style G stroke:#F9A825,stroke-width:2px - style H stroke:#F9A825,stroke-width:2px - - subgraph ethereum/go-ethereum - C[evm t8n
external executable] - end - - subgraph ethereum/solidity - D[solc
external executable] - end - - subgraph ethereum/EIPs - E(EIPS/EIP-*.md
SHA digest via Github API) - end - - subgraph "ethereum/execution-spec-tests" - A(./tests/**/*.py
Python Test Cases) - B([$ fill ./tests/
Python Framework]) - end - - subgraph Test Fixture Consumers - subgraph ethereum/hive - G([$ hive ...
Go Test Framework]) - end - H([Client executables]) - end - - C <-.-> B - D <-.-> B - A --> B - E <-.-> |retrieve latest spec version\ncheck tested spec version| B - B -->|output| F(./fixtures/**/*.json\nJSON Test Fixtures) - F -->|input| G - F -->|input| H -``` - -The generated test fixtures can be used: - -1. Directly by client teams' test frameworks, and, -2. In the integration tests executed in the @ethereum/hive framework. - -More information on how to use and download the [released test fixtures](https://github.com/ethereum/execution-spec-tests/releases) can be found [here](running_tests/index.md). - -## Relationship to ethereum/tests - -This collection of tests is relatively new (test case development started Q4, 2022) and mainly targets recent and upcoming Ethereum specification changes. It does not replace, but rather complements the existing tests in [ethereum/tests](https://github.com/ethereum/tests). - -## Motivation - -The motivation to implement test cases in [ethereum/execution-spec-tests](https://github.com/ethereum/execution-spec-tests) is: - -1. To implement test cases as code and ensure that changes, due to spec changes, for example, can be easily made. Moreover, changes are easily understandable and available in version control. -2. To avoid the 2-step approach often used in [ethereum/tests](https://github.com/ethereum/tests): - 1. Code (often unavailable) -> Test case (YAML). - 2. Test case (YAML) -> Fixtures (JSON). - -!!! success "Contributing" - Contributions via [PR](https://github.com/ethereum/execution-spec-tests/pulls) are welcome! - -!!! bug "Reporting a Vulnerability" - - Care is required when adding PRs or issues for functionality that is live on Ethereum mainnet. Please report vulnerabilities and verify bounty eligibility via the [bug bounty program](https://bounty.ethereum.org). - - - **Please do not create a PR with a vulnerability visible.** - - **Please do not file a public ticket mentioning the vulnerability.** diff --git a/docs/javascripts/site.js b/docs/javascripts/site.js deleted file mode 100644 index c39a3307ea7..00000000000 --- a/docs/javascripts/site.js +++ /dev/null @@ -1,128 +0,0 @@ -// Config -const FILTER_INPUT_SELECTOR = ".custom_dt_filter"; -const FILTER_SEARCH_SELECTOR = "#custom_dt_search"; -let table; -const ICON_COLUMN_FILTER = - ''; - -// This script is used both within mkdocs and in standalone html files. -// As such, a uniform listener to page load event is required. -// The snippet below uses mkdocs subscription if present otherwise jquery is used -// as a fallback. -// see: https://github.com/squidfunk/mkdocs-material/issues/5816#issuecomment-1667654560 - -if (typeof document$ == "undefined") { - document$ = {}; - document$.subscribe = $(document).ready; -} - -document$.subscribe(() => { - initDataTable(); - - if (table) { - // Listen for changes to filters - $(FILTER_INPUT_SELECTOR).on("change", filterRows); - - $(FILTER_SEARCH_SELECTOR).on("input", filterRows); - - // Apply preselected filters (if present) on page load - filterRows(); - - // Listen for copy event - listenForClipboardCopy(); - - // Style native dataTable buttons - $(".dt-buttons").detach().appendTo(".panel_row.filters"); - $(".buttons-collection").prepend(ICON_COLUMN_FILTER); - } - - // Setup up select 2 - $(`select${FILTER_INPUT_SELECTOR}`).select2(); -}); - -const initDataTable = () => { - // Only pages where a table is present. - if (!$("#test_table").length) return false; - - // Setup DataTable plugin - // https://datatables.net/reference/api/ - table = new DataTable("#test_table", { - pageLength: -1, - scrollX: true, - autoWidth: false, - layout: { - topStart: { - buttons: ["colvis"], - }, - }, - }); -}; - -// A custom DataTable filter is implemented using a -// -// The value of the `data-criteria' attribute must match the corresponding data attribute in the elements. -// For instance, rows containing will be filtered based on this selection. -const filterRows = () => { - table - .rows() - .search(function (rowContent, b, index) { - const row = $(table.row(index).node()); - let match = true; - - const searchKeyword = $(FILTER_SEARCH_SELECTOR).val(); - const searchHit = rowContent.includes(searchKeyword); - - for (let filter of $(FILTER_INPUT_SELECTOR)) { - // Filter is ignored if set to all - if ($(filter).val() == "all") continue; - - // Otherwise, the result of this filter applied to the previous match. - match = - match && row.data($(filter).data("criteria")) === $(filter).val(); - } - - return searchKeyword.length ? match && searchHit : match; - }) - .draw(); -}; - -const listenForClipboardCopy = () => { - // Event delegation for copy-to-clipboard functionality - document.addEventListener("click", function (event) { - if (event.target && event.target.classList.contains("copy-id")) { - const fullId = event.target.getAttribute("data-full-id"); - - // Copy to clipboard - navigator.clipboard - .writeText(fullId) - .then(() => { - const originalContent = event.target.innerHTML; - - // Set the sliding message with animation - event.target.innerHTML = - '...full test id copied!'; - - // Delay the hiding of the slide-out message - setTimeout(() => { - const slideElement = event.target.querySelector(".slide"); - if (slideElement) { - slideElement.classList.add("hide"); - } - }, 1000); - - // Restore the original content after the animation - setTimeout(() => { - event.target.innerHTML = originalContent; - }, 1500); // Total duration before restoring original content - }) - .catch((err) => { - console.error("Failed to copy text: ", err); - }); - } - }); -}; diff --git a/docs/layouts/_default/_markup/render-link.html b/docs/layouts/_default/_markup/render-link.html new file mode 100644 index 00000000000..355c2881bc6 --- /dev/null +++ b/docs/layouts/_default/_markup/render-link.html @@ -0,0 +1,10 @@ +{{/* layouts/_default/_markup/render-link.html */}} +{{- $link := .Destination -}} +{{- $isInternal := not (or (hasPrefix $link "http://") (hasPrefix $link "https://")) -}} + +{{- if and $isInternal (hasSuffix $link "/") -}} + {{- /* This is a directory link, append main to it */ -}} + {{- $link = printf "%smain/" $link -}} +{{- end -}} + +{{ .Text | safeHTML }} \ No newline at end of file diff --git a/docs/layouts/_default/baseof.html b/docs/layouts/_default/baseof.html new file mode 100644 index 00000000000..97d3136e690 --- /dev/null +++ b/docs/layouts/_default/baseof.html @@ -0,0 +1,257 @@ +{{/* layouts/_default/baseof.html */}} + + + + + + {{ if .IsHome }}{{ .Site.Title }}{{ else }}{{ .Title }} - {{ .Site.Title }}{{ end }} + + + + + {{ partial "head-close.html" . }} + + + + + + {{/* Top Navigation */}} + + + {{/* Main Content Area */}} +
+ + +
+ {{ block "main" . }}{{ end }} +
+
+ + \ No newline at end of file diff --git a/docs/layouts/_default/list.html b/docs/layouts/_default/list.html new file mode 100644 index 00000000000..6bdf636693e --- /dev/null +++ b/docs/layouts/_default/list.html @@ -0,0 +1,13 @@ +{{/* layouts/_default/list.html */}} +{{ define "main" }} +

{{ .Title }}

+ +{{ end }} + +{{ define "sidebar" }} + {{ partial "sidebar.html" . }} +{{ end }} \ No newline at end of file diff --git a/docs/layouts/_default/section.html b/docs/layouts/_default/section.html new file mode 100644 index 00000000000..802be0210d1 --- /dev/null +++ b/docs/layouts/_default/section.html @@ -0,0 +1,29 @@ +{{/* layouts/_default/section.html */}} +{{ define "main" }} + {{/* Look for main.md in this section */}} + {{ $mainPage := .GetPage "main" }} + + {{ if $mainPage }} + {{/* If main.md exists, render its content */}} +
+ {{ $mainPage.Content }} +
+ {{ else }} + {{/* Fallback: list all pages in this section */}} +
+

{{ .Title | default (humanize (path.Base .Section)) }}

+

No main.md found in this section.

+ +

Available Pages:

+ +
+ {{ end }} +{{ end }} + +{{ define "sidebar" }} + {{ partial "sidebar.html" . }} +{{ end }} \ No newline at end of file diff --git a/docs/layouts/_default/single.html b/docs/layouts/_default/single.html new file mode 100644 index 00000000000..d4e5eea3f47 --- /dev/null +++ b/docs/layouts/_default/single.html @@ -0,0 +1,19 @@ +{{/* layouts/_default/single.html */}} +{{ define "main" }} +
+

{{ .Title }}

+
{{ .Description }}
+ {{ if .Params.tags }} +
+ {{ range .Params.tags }} + {{ . }} + {{ end }} +
+ {{ end }} +
+
{{ .Content }}
+{{ end }} + +{{ define "sidebar" }} + {{ partial "sidebar.html" . }} +{{ end }} \ No newline at end of file diff --git a/docs/layouts/index.html b/docs/layouts/index.html new file mode 100644 index 00000000000..4a00ea32ff2 --- /dev/null +++ b/docs/layouts/index.html @@ -0,0 +1,11 @@ + + + + + + Redirecting... + + +

Redirecting to main page...

+ + \ No newline at end of file diff --git a/docs/layouts/partials/head-close.html b/docs/layouts/partials/head-close.html new file mode 100644 index 00000000000..ef034c03128 --- /dev/null +++ b/docs/layouts/partials/head-close.html @@ -0,0 +1,2 @@ + + \ No newline at end of file diff --git a/docs/layouts/partials/sidebar-enhanced.html b/docs/layouts/partials/sidebar-enhanced.html new file mode 100644 index 00000000000..9470cccabbc --- /dev/null +++ b/docs/layouts/partials/sidebar-enhanced.html @@ -0,0 +1,59 @@ + \ No newline at end of file diff --git a/docs/layouts/partials/sidebar.html b/docs/layouts/partials/sidebar.html new file mode 100644 index 00000000000..b1cb1334c95 --- /dev/null +++ b/docs/layouts/partials/sidebar.html @@ -0,0 +1,124 @@ +{{/* layouts/partials/sidebar.html */}} + diff --git a/docs/layouts/shortcodes/callout.html b/docs/layouts/shortcodes/callout.html new file mode 100644 index 00000000000..2b427e007b4 --- /dev/null +++ b/docs/layouts/shortcodes/callout.html @@ -0,0 +1,8 @@ +{{ $type := .Get 0 | default "info" }} +{{ $title := .Get 1 | default (title $type) }} +
+
{{ $title | markdownify }}
+
+ {{ .Inner | markdownify }} +
+
\ No newline at end of file diff --git a/docs/layouts/shortcodes/tab.html b/docs/layouts/shortcodes/tab.html new file mode 100644 index 00000000000..5db93d0d677 --- /dev/null +++ b/docs/layouts/shortcodes/tab.html @@ -0,0 +1,5 @@ +{{ with .Parent }} + {{ $tabs := .Scratch.Get "tabs" | default slice }} + {{ $tabs = $tabs | append (dict "title" ($.Get 0) "content" $.Inner) }} + {{ .Scratch.Set "tabs" $tabs }} +{{ end }} \ No newline at end of file diff --git a/docs/layouts/shortcodes/table.html b/docs/layouts/shortcodes/table.html new file mode 100644 index 00000000000..967b4a8f0bd --- /dev/null +++ b/docs/layouts/shortcodes/table.html @@ -0,0 +1,58 @@ +{{ $headers := split (.Get "headers") "|" }} +{{ $content := .Inner }} +{{ $rows := split $content "||" }} + + + + + {{ range $headers }} + + {{ end }} + + + + {{ range $rows }} + {{ $row := trim . "\n" }} + {{ if $row }} + + {{ $cells := split $row "|" }} + {{ range $cells }} + + {{ end }} + + {{ end }} + {{ end }} + +
{{ . | markdownify }}
{{ trim . " " | $.Page.RenderString }}
+ + \ No newline at end of file diff --git a/docs/layouts/shortcodes/tabs.html b/docs/layouts/shortcodes/tabs.html new file mode 100644 index 00000000000..9734d80d17e --- /dev/null +++ b/docs/layouts/shortcodes/tabs.html @@ -0,0 +1,140 @@ +{{ $tabs := slice }} +{{ $id := .Ordinal }} + +{{/* Process inner content to collect tabs */}} +{{ .Inner }} + +{{/* Get tabs from scratch */}} +{{ $tabs = .Scratch.Get "tabs" }} + +
+
+ {{ range $index, $tab := $tabs }} + + {{ end }} +
+ +
+ {{ range $index, $tab := $tabs }} +
+ {{ .content | $.Page.RenderString }} +
+ {{ end }} +
+
+ +{{/* Clear the scratch for next use */}} +{{ .Scratch.Delete "tabs" }} + + + + \ No newline at end of file diff --git a/docs/library/cli/eest.md b/docs/library/cli/eest.md deleted file mode 100644 index 1b6a73591a1..00000000000 --- a/docs/library/cli/eest.md +++ /dev/null @@ -1,7 +0,0 @@ -# The `eest` CLI - -::: mkdocs-click - :module: cli.eest.cli - :command: eest - :depth: 1 - :list_subcommands: true diff --git a/docs/library/cli/evm_bytes.md b/docs/library/cli/evm_bytes.md deleted file mode 100644 index 21e8d4014a9..00000000000 --- a/docs/library/cli/evm_bytes.md +++ /dev/null @@ -1,7 +0,0 @@ -# The `evm_bytes` CLI - -::: mkdocs-click - :module: cli.evm_bytes - :command: evm_bytes - :depth: 1 - :list_subcommands: true diff --git a/docs/library/cli/extract_config.md b/docs/library/cli/extract_config.md deleted file mode 100644 index 3a4afae6599..00000000000 --- a/docs/library/cli/extract_config.md +++ /dev/null @@ -1,132 +0,0 @@ -# `extract_config` - Extract Client Configuration Files - -The `extract_config` command extracts configuration files from Ethereum clients by spawning them via Hive and retrieving the generated files from the Docker container. - -## Purpose - -When Ethereum clients start up with a genesis configuration, they generate various configuration files such as: - -- `/chainspec/test.json` - Chain specification file -- `/configs/test.cfg` - Configuration file -- `/genesis.json` - Genesis block configuration - -This tool automates the process of extracting these files from the client containers for analysis or debugging purposes. - -## Usage - -```bash -uv run extract_config --fixture [OPTIONS] -``` - -### Options - -- `--fixture, -f` (required): Path to a fixture JSON file or directory containing fixture files -- `--client, -c`: Specific client name to extract from (e.g., go-ethereum, besu, nethermind). If not specified, extracts from all available clients -- `--output, -o`: Output directory for extracted files (default: ./extracted_configs) -- `--hive-url`: Hive server URL (default: http://127.0.0.1:3000) -- `--list-files, -l`: List files in the container root before extraction -- `--help`: Show help message - -### Examples - -Extract configuration from all clients using a specific fixture: - -```bash -uv run extract_config --fixture fixtures/blockchain_tests/paris/security/test_selfdestruct_balance_bug.json -``` - -Extract configuration from a specific client: - -```bash -uv run extract_config --fixture fixtures/blockchain_tests/paris/security/test_selfdestruct_balance_bug.json --client besu -``` - -Extract configurations from all fixtures in a directory: - -```bash -uv run extract_config --fixture fixtures/blockchain_tests/paris/security/ -``` - -Extract to a specific directory and list container files: - -```bash -uv run extract_config --fixture my_fixture.json --output ./my_configs --list-files -``` - -## Prerequisites - -1. Hive must be running in the background: - - ```bash - ./hive --dev - ``` - -2. Docker must be installed and accessible - -## Output - -The tool creates a hierarchical directory structure: - -```console -/ - / - / - chainspec.json - config.cfg - genesis.json -``` - -For example: - -```console -extracted_configs/ - test_selfdestruct_balance_bug/ - go-ethereum/ - genesis.json - besu/ - genesis.json - chainspec.json - nethermind/ - chainspec.json - config.cfg -``` - -Only files that exist in the client container will be extracted. - -## How It Works - -1. Loads the fixture file(s) to extract genesis configuration -2. Starts a Hive simulation -3. For each fixture and each client: - - Captures the list of Docker containers before starting the client - - Spawns the client with the genesis configuration - - Compares Docker containers to identify the newly created container - - Uses Docker exec commands to check for and extract configuration files - - Saves the extracted files to the organized output directory - - Stops the client container -4. Ends the Hive simulation - -## Container ID Detection - -Since Hive doesn't directly expose container IDs, the tool uses a detection mechanism: - -1. Lists all Docker container IDs before starting the client -2. Starts the client through Hive -3. Lists all Docker container IDs after starting the client -4. The difference should be exactly one container - the client's container - -## Supported Fixture Formats - -The tool supports: - -- Individual fixture JSON files (BlockchainFixture format) -- PreAllocGroup JSON files -- Directories containing multiple fixture files - -## Troubleshooting - -- If no files are extracted, use the `--list-files` flag to see what files are available in the container root -- Ensure Hive is running before executing the command -- Check that Docker is installed and the current user has permissions to run Docker commands -- If the tool fails to detect the container ID, ensure no other containers are being created simultaneously -- Some clients may not generate all configuration file types - this is normal diff --git a/docs/library/cli/index.md b/docs/library/cli/index.md deleted file mode 100644 index 4231719a442..00000000000 --- a/docs/library/cli/index.md +++ /dev/null @@ -1,6 +0,0 @@ -# EEST CLI Tools - -- [`check_eip_versions`](../../writing_tests/reference_specification.md) - A CLI tool to check the SHA values specified in EIP tests match the latest version from ethereum/EIPs. -- [`eest`](eest.md) - A CLI tool that helps with routine tasks in ethereum/execution-spec-tests. -- [`evm_bytes`](evm_bytes.md) - Convert the given EVM bytes from a binary file or a hex string to EEST's python opcodes. -- [`extract_config`](extract_config.md) - Extract client configuration files (chainspec/genesis.json) from Ethereum clients via Hive. diff --git a/docs/library/ethereum_clis.md b/docs/library/ethereum_clis.md deleted file mode 100644 index c4595a50afc..00000000000 --- a/docs/library/ethereum_clis.md +++ /dev/null @@ -1,3 +0,0 @@ -# Ethereum CLIs Package - -::: ethereum_clis diff --git a/docs/library/ethereum_test_base_types.md b/docs/library/ethereum_test_base_types.md deleted file mode 100644 index e1bca5d4898..00000000000 --- a/docs/library/ethereum_test_base_types.md +++ /dev/null @@ -1,3 +0,0 @@ -# Ethereum Test Base Types package - -::: ethereum_test_base_types diff --git a/docs/library/ethereum_test_exceptions.md b/docs/library/ethereum_test_exceptions.md deleted file mode 100644 index e0cfd17a32e..00000000000 --- a/docs/library/ethereum_test_exceptions.md +++ /dev/null @@ -1,3 +0,0 @@ -# Ethereum Test Exceptions package - -::: ethereum_test_exceptions diff --git a/docs/library/ethereum_test_fixtures.md b/docs/library/ethereum_test_fixtures.md deleted file mode 100644 index 89ed5ff7036..00000000000 --- a/docs/library/ethereum_test_fixtures.md +++ /dev/null @@ -1,3 +0,0 @@ -# Ethereum Test Fixtures package - -::: ethereum_test_fixtures diff --git a/docs/library/ethereum_test_forks.md b/docs/library/ethereum_test_forks.md deleted file mode 100644 index 23ef6fab46a..00000000000 --- a/docs/library/ethereum_test_forks.md +++ /dev/null @@ -1,3 +0,0 @@ -# Ethereum Test Forks package - -::: ethereum_test_forks diff --git a/docs/library/ethereum_test_specs.md b/docs/library/ethereum_test_specs.md deleted file mode 100644 index 525ff84e0a4..00000000000 --- a/docs/library/ethereum_test_specs.md +++ /dev/null @@ -1,3 +0,0 @@ -# Ethereum Test Specs package - -::: ethereum_test_specs diff --git a/docs/library/ethereum_test_tools.md b/docs/library/ethereum_test_tools.md deleted file mode 100644 index b2a7a9d4355..00000000000 --- a/docs/library/ethereum_test_tools.md +++ /dev/null @@ -1,3 +0,0 @@ -# Ethereum Test Tools Package - -::: ethereum_test_tools diff --git a/docs/library/ethereum_test_types.md b/docs/library/ethereum_test_types.md deleted file mode 100644 index ef83eac6aef..00000000000 --- a/docs/library/ethereum_test_types.md +++ /dev/null @@ -1,3 +0,0 @@ -# Ethereum Test Types package - -::: ethereum_test_types diff --git a/docs/library/ethereum_test_vm.md b/docs/library/ethereum_test_vm.md deleted file mode 100644 index 20712b314b4..00000000000 --- a/docs/library/ethereum_test_vm.md +++ /dev/null @@ -1,3 +0,0 @@ -# Ethereum Test VM package - -::: ethereum_test_vm diff --git a/docs/library/index.md b/docs/library/index.md deleted file mode 100644 index de5b5183f1e..00000000000 --- a/docs/library/index.md +++ /dev/null @@ -1,14 +0,0 @@ -# Library (Tools) Reference Documentation - -Execution spec tests consists of several packages that implement helper classes and tools that enable and simplify test case implementation. This section contains their reference documentation: - -- [`ethereum_test_base_types`](./ethereum_test_base_types.md) - provides the basic types on top of which other testing libraries are built. -- [`ethereum_test_exceptions`](./ethereum_test_exceptions.md) - provides definitions for exceptions used in all tests. -- [`ethereum_test_fixtures`](./ethereum_test_fixtures.md) - provides definitions of all test fixture types that are produced in this repository and can be consumed by clients. -- [`ethereum_test_forks`](./ethereum_test_forks.md) - provides definitions for supported forks used in tests. -- [`ethereum_test_specs`](./ethereum_test_specs.md) - provides definitions for all spec types used to define test cases, and generate different kinds of test fixtures. -- [`ethereum_test_tools`](./ethereum_test_tools.md) - provides primitives and helpers to test Ethereum execution clients. -- [`ethereum_test_types`](./ethereum_test_types.md) - provides Ethereum types built on top of the base types which are used to define test cases and interact with other libraries. -- [`ethereum_test_vm`](./ethereum_test_vm.md) - provides definitions for the Ethereum Virtual Machine (EVM) as used to define bytecode in test cases. -- [`ethereum_clis`](./ethereum_clis.md) - a wrapper for the transition (`t8n`) tool. -- [`pytest_plugins`](./pytest_plugins/index.md) - contains pytest customizations that provide additional functionality for generating test fixtures. diff --git a/docs/library/pytest_plugins/filler.md b/docs/library/pytest_plugins/filler.md deleted file mode 100644 index 632b3f16af1..00000000000 --- a/docs/library/pytest_plugins/filler.md +++ /dev/null @@ -1,7 +0,0 @@ -# Filler Plugin - -::: pytest_plugins.filler - -::: pytest_plugins.filler.filler - -::: pytest_plugins.filler.pre_alloc diff --git a/docs/library/pytest_plugins/forks.md b/docs/library/pytest_plugins/forks.md deleted file mode 100644 index 68d035bb5de..00000000000 --- a/docs/library/pytest_plugins/forks.md +++ /dev/null @@ -1,5 +0,0 @@ -# Forks Plugin - -::: pytest_plugins.forks - -::: pytest_plugins.forks.forks diff --git a/docs/library/pytest_plugins/index.md b/docs/library/pytest_plugins/index.md deleted file mode 100644 index e083fad56d4..00000000000 --- a/docs/library/pytest_plugins/index.md +++ /dev/null @@ -1,7 +0,0 @@ -# Pytest Framework and Customizations - -::: pytest_plugins - -- [Filler Plugin](./filler.md). -- [Forks Plugin](./forks.md). -- [Spec Version Checker Plugin](./spec_version_checker.md). diff --git a/docs/library/pytest_plugins/spec_version_checker.md b/docs/library/pytest_plugins/spec_version_checker.md deleted file mode 100644 index 6e4158b5c32..00000000000 --- a/docs/library/pytest_plugins/spec_version_checker.md +++ /dev/null @@ -1,5 +0,0 @@ -# Spec Version Checker Plugin - -::: pytest_plugins.spec_version_checker - -::: pytest_plugins.spec_version_checker.spec_version_checker diff --git a/docs/navigation.md b/docs/navigation.md deleted file mode 100644 index 9fc4c9d49cc..00000000000 --- a/docs/navigation.md +++ /dev/null @@ -1,87 +0,0 @@ - - - * [Home](index.md) - * Getting Started - * [Installation](getting_started/installation.md) - * [Installation Troubleshooting](getting_started/installation_troubleshooting.md) - * [Contributing](getting_started/contributing.md) - * [Security Policy](getting_started/security.md) - * [Code Standards](getting_started/code_standards.md) - * [Detailed Code Standards](getting_started/code_standards_details.md) - * [VS Code Setup](getting_started/setup_vs_code.md) - * [Repository Overview](getting_started/repository_overview.md) - * [Getting Help](getting_started/getting_help.md) - * [Writing Tests](writing_tests/index.md) - * [Adding a New Test](writing_tests/adding_a_new_test.md) - * [Types of Test](writing_tests/types_of_tests.md) - * [Writing a New Test](writing_tests/writing_a_new_test.md) - * [Test Markers](writing_tests/test_markers.md) - * [Verifying Changes Locally](writing_tests/verifying_changes.md) - * [Code Standards](writing_tests/code_standards.md) - * [Exception Tests](writing_tests/exception_tests.md) - * [Using and Extending Fork Methods](writing_tests/fork_methods.md) - * [Referencing an EIP Spec Version](writing_tests/reference_specification.md) - * [EIP Checklist Generation](writing_tests/eip_checklist.md) - * [Testing Checklist Templates](writing_tests/checklist_templates/index.md) - * [EIP Execution Layer Testing Checklist Template](writing_tests/checklist_templates/eip_testing_checklist_template.md) - * [Post-mortems](writing_tests/post_mortems.md) - * [Tutorial: Adding a State Test](writing_tests/tutorials/state_transition.md) - * [Porting Legacy Tests](writing_tests/porting_legacy_tests.md) - * [Filling Tests](filling_tests/index.md) - * [Getting Started](filling_tests/getting_started.md) - * [Filling Tests at a Prompt](filling_tests/filling_tests_command_line.md) - * [Fill Command-Line Options](filling_tests/filling_tests_command_line_options.md) - * [Filling Tests in VS Code](filling_tests/filling_tests_vs_code.md) - * [Filling Tests for Features Under Development](filling_tests/filling_tests_dev_fork.md) - * [An Explanation of Test IDs](filling_tests/test_ids.md) - * [Transition Tool Support](filling_tests/transition_tool_support.md) - * [Debugging Transition Tools](filling_tests/debugging_t8n_tools.md) - * [Running Tests](running_tests/index.md) - * [Methods of Running Tests](running_tests/running.md) - * [EEST Fixture Releases](running_tests/releases.md) - * [Test Fixture Specifications](running_tests/test_formats/index.md) - * [State Tests](running_tests/test_formats/state_test.md) - * [Blockchain Tests](running_tests/test_formats/blockchain_test.md) - * [Blockchain Engine Tests](running_tests/test_formats/blockchain_test_engine.md) - * [Blockchain Engine X Tests](running_tests/test_formats/blockchain_test_engine_x.md) - * [Transaction Tests](running_tests/test_formats/transaction_test.md) - * [Common Types](running_tests/test_formats/common_types.md) - * [Exceptions](running_tests/test_formats/exceptions.md) - * [Hive](running_tests/hive/index.md) - * [Client Configuration](running_tests/hive/client_config.md) - * [Common Options](running_tests/hive/common_options.md) - * [Development Mode](running_tests/hive/dev_mode.md) - * [Viewing Results](running_tests/hive/hiveview.md) - * [CI Integration](running_tests/hive/ci_integration.md) - * [Consume Commands](running_tests/consume/index.md) - * [Consume Cache & Fixture Inputs](running_tests/consume/cache.md) - * [Consume Direct](running_tests/consume/direct.md) - * [Consume Simulators](running_tests/consume/simulators.md) - * [Exception Tests](running_tests/consume/exceptions.md) - * [Execute Commands](./running_tests/execute/index.md) - * [Execute Hive](./running_tests/execute/hive.md) - * [Execute Remote](./running_tests/execute/remote.md) - * [Execute Eth Config](./running_tests/execute/eth_config.md) - * [Useful Pytest Options](running_tests/useful_pytest_options.md) - * [Developer Doc](dev/index.md) - * [Managing Configurations](dev/configurations.md) - * [Interactive Library Usage](dev/interactive_usage.md) - * [Generating Documentation](dev/docs.md) - * [Documenting CLI Commands](dev/documenting_clis.md) - * [Coding Style](dev/coding_style.md) - * [Logging](dev/logging.md) - * [Enabling Precommit Checks](dev/precommit.md) - * [Running Github Actions Locally](dev/test_actions_locally.md) - * [Changelog](CHANGELOG.md) - * [Library Reference](library/index.md) - * [EEST CLI Tools](library/cli/index.md) - * [Ethereum Test Base Types Package](library/ethereum_test_base_types.md) - * [Ethereum Test Exceptions Package](library/ethereum_test_exceptions.md) - * [Ethereum Test Fixtures Package](library/ethereum_test_fixtures.md) - * [Ethereum Test Forks Package](library/ethereum_test_forks.md) - * [Ethereum Test Specs Package](library/ethereum_test_specs.md) - * [Ethereum Test Tools Package](library/ethereum_test_tools.md) - * [Ethereum Test Types Package](library/ethereum_test_types.md) - * [Ethereum Test VM Package](library/ethereum_test_vm.md) - * [Ethereum CLIs Package](library/ethereum_clis.md) - * [Pytest Plugins](library/pytest_plugins/index.md) diff --git a/docs/public/404.html b/docs/public/404.html new file mode 100644 index 00000000000..13b1c966c18 --- /dev/null +++ b/docs/public/404.html @@ -0,0 +1,123 @@ + + + + + + + + 404 Page not found + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
+

Β―\_(ツ)_/Β―

+

Nothing here

+
+
+ +
+ +
+ + + + + + + + diff --git a/docs/public/categories/index.html b/docs/public/categories/index.html new file mode 100644 index 00000000000..ce9fa34ba1f --- /dev/null +++ b/docs/public/categories/index.html @@ -0,0 +1,129 @@ + + + + + + + + Categories + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +

Categories

+ + + +
+ + + +
+ +
+ + + + + + + + diff --git a/docs/public/categories/index.xml b/docs/public/categories/index.xml new file mode 100644 index 00000000000..ea73f33b0d0 --- /dev/null +++ b/docs/public/categories/index.xml @@ -0,0 +1,11 @@ + + + + Categories on EEST Docs + http://localhost:1313/categories/ + Recent content in Categories on EEST Docs + Hugo + en-us + + + diff --git a/docs/public/categories/page/1/index.html b/docs/public/categories/page/1/index.html new file mode 100644 index 00000000000..83884ac9386 --- /dev/null +++ b/docs/public/categories/page/1/index.html @@ -0,0 +1,10 @@ + + + + http://localhost:1313/categories/ + + + + + + diff --git a/docs/public/css/boxes.css b/docs/public/css/boxes.css new file mode 100644 index 00000000000..afd8b5fcb4d --- /dev/null +++ b/docs/public/css/boxes.css @@ -0,0 +1,84 @@ +/* +@font-face { + font-family: "icons-boxes"; + src: url("../fonts/icons-boxes.eot?bzmaom"); + src: url("../fonts/icons-boxes.eot?bzmaom#iefix") format("embedded-opentype"), + url("../fonts/icons-boxes.ttf?bzmaom") format("truetype"), + url("../fonts/icons-boxes.woff?bzmaom") format("woff"), + url("../fonts/icons-boxes.svg?bzmaom#icomoon-notices") format("svg"); + font-weight: normal; + font-style: normal; + font-display: block; + font-variant: normal; + text-transform: none; + line-height: 1; + } +*/ + [class^="box"], + [class*=" box"] { + /* use !important to prevent issues with browser extensions that change fonts */ + font-family: "icons-boxes" !important; + background-color: #fffeb4a3; + + padding: 0.5em; + margin-top: 1em; + + /* Better Font Rendering =========== */ + -webkit-font-smoothing: antialiased; + -moz-osx-font-smoothing: grayscale; + } + + [class^="box"]::before { + padding-left: 0.4em; + padding-right: 0.8em; + } + + /* Add icons */ + + .boxBell:before { + content: "\f0f3"; + color: #9f6000; + } + .boxCheck:before { + content: "\f058"; + color: #4f8a10; + } + .boxComment:before { + content: "\f075"; + } + .boxHeart:before { + content: "\f004"; + } + .boxInfo:before { + content: "\f05a"; + color: #00529b; + } + .boxPlus:before { + content: "\f067"; + } + .boxStar:before { + content: "\f005"; + } + .boxWarning:before { + content: "\f06a"; + } + + /* Set colors */ + + .boxBell { + background-color: #f1f500a4; + } + + .boxWarning { + color: #fff; + background-color: rgba(217, 83, 79, 0.9); + } + + .boxCheck { + background-color: #dff2bf; + } + + .boxInfo { + background-color: #bde5f8; + } + \ No newline at end of file diff --git a/docs/public/css/callouts.css b/docs/public/css/callouts.css new file mode 100644 index 00000000000..3ba3aec9f06 --- /dev/null +++ b/docs/public/css/callouts.css @@ -0,0 +1,87 @@ +.callout { + margin: 1.5em 0; + padding: 0; + border-left: 4px solid; + border-radius: 4px; + background-color: #f7f7f7; + } + + .callout-title { + padding: 0.75em 1em; + font-weight: bold; + background-color: rgba(0,0,0,0.05); + } + + .callout-content { + padding: 1em; + } + + .callout-warning { + border-color: #ff9800; + background-color: #fff3e0; + } + + .callout-warning .callout-title { + color: #e65100; + background-color: #ffe0b2; + } + + .callout-info { + border-color: #2196f3; + background-color: #e3f2fd; + } + + .callout-info .callout-title { + color: #0d47a1; + background-color: #bbdefb; + } + + .callout-danger { + border-color: #f44336; + background-color: #ffebee; + } + + .callout-danger .callout-title { + color: #b71c1c; + background-color: #ffcdd2; + } + + .callout-success { + border-color: #4caf50; + background-color: #e8f5e9; + } + + .callout-success .callout-title { + color: #1b5e20; + background-color: #c8e6c9; + } + + +/* Dark mode support (optional) */ +@media (prefers-color-scheme: dark) { + .callout-info { + background-color: rgba(33, 150, 243, 0.1); + color: #90caf9; + } + + .callout-warning { + background-color: rgba(255, 152, 0, 0.1); + color: #ffb74d; + } + + .callout-danger, + .callout-error { + background-color: rgba(244, 67, 54, 0.1); + color: #ef5350; + } + + .callout-success { + background-color: rgba(76, 175, 80, 0.1); + color: #81c784; + } + + .callout-note { + background-color: rgba(158, 158, 158, 0.1); + color: #e0e0e0; + } +} diff --git a/docs/public/css/custom.css b/docs/public/css/custom.css new file mode 100644 index 00000000000..9ccc4d42d64 --- /dev/null +++ b/docs/public/css/custom.css @@ -0,0 +1,43 @@ +/* Better table styling */ +table { + border-collapse: collapse; + width: 100%; + margin: 1.5rem 0; + font-size: 0.95em; + } + + table th { + background-color: #f5f5f5; + border: 1px solid #ddd; + padding: 0.75rem; + text-align: left; + font-weight: 600; + } + + table td { + border: 1px solid #ddd; + padding: 0.75rem; + vertical-align: top; + } + + table tr:nth-child(even) { + background-color: #f9f9f9; + } + + table code { + background-color: #f4f4f4; + padding: 0.2rem 0.4rem; + border-radius: 3px; + font-size: 0.9em; + } + + /* Responsive tables */ + @media (max-width: 768px) { + table { + font-size: 0.85em; + } + + table td, table th { + padding: 0.5rem; + } + } \ No newline at end of file diff --git a/docs/public/css/main.css b/docs/public/css/main.css new file mode 100644 index 00000000000..09452b318e9 --- /dev/null +++ b/docs/public/css/main.css @@ -0,0 +1,106 @@ +html, body { + height: 100%; +} + +body { + padding-top: 55px; + display: flex; + text-align: left; + flex-direction: column; +} + +main { + margin: auto; + padding: 25px; + flex: 1 0 auto; + max-width: 750px; +} + +img { + max-width: 100%; +} + +/* Homepage */ + +.intro { + transform: translateY(22vh); +} + +.intro > h1 { + color: #212121; + font-size: 12vh; +} + +.intro > h2 { + color: #757575; + font-size: 3vmin; +} + +/* Page content */ + +.content { + padding-top: 20px; +} + +/* Profile picture */ + +.profile { + width: 10vh; + height: 10vh; + border-radius: 50%; +} + +/* Colored links */ + +a:link, a:visited { + color: var(--accent); +} + +a.icon:hover { + text-decoration: none; +} + +a:hover { + color: var(--accent) !important; +} + +.copyright { + display: none !important; +} + +/* Paginator */ + +.pages { + padding: 15px 0; +} + +.pages-icon { + padding: 0 15px; +} + +/* List item for posts/projects */ + +.item { + padding: 10px 0; +} + +.item-tag { + background-color: var(--accent); +} + +/* Navigation icons */ + +.navbar-icon { + font-size: 125%; + display: inline-block !important; +} + +/* Colored borders at top/bottom of page */ + +.navbar.navbar-default { + border-top: var(--border-width) solid var(--accent); +} + +footer { + display: none !important; +} diff --git a/docs/public/css/sidebar.css b/docs/public/css/sidebar.css new file mode 100644 index 00000000000..6ce3f53b101 --- /dev/null +++ b/docs/public/css/sidebar.css @@ -0,0 +1,116 @@ +/* Sidebar layout */ +.content-with-sidebar { + display: flex; + gap: 2rem; + max-width: 1200px; + margin: 0 auto; + padding: 2rem; + } + + .sidebar { + flex: 0 0 250px; + min-height: 300px; + } + + .main-content { + flex: 1; + min-width: 0; /* Prevent overflow */ + } + + /* Sidebar styling */ + .sidebar-nav { + position: sticky; + top: 2rem; + background: #f5f5f5; + border-radius: 8px; + padding: 1.5rem; + border: 1px solid #e0e0e0; + } + + .sidebar-title { + margin: 0 0 1rem 0; + font-size: 1.1rem; + color: #333; + border-bottom: 2px solid #ddd; + padding-bottom: 0.5rem; + } + + .sidebar-subtitle { + margin: 1.5rem 0 0.5rem 0; + font-size: 0.9rem; + color: #666; + } + + .sidebar-menu { + list-style: none; + margin: 0; + padding: 0; + } + + .sidebar-item { + margin: 0.25rem 0; + } + + .sidebar-link { + display: block; + padding: 0.5rem 0.75rem; + color: #333; + text-decoration: none; + border-radius: 4px; + transition: all 0.2s ease; + } + + .sidebar-link:hover { + background-color: #e8e8e8; + color: #000; + } + + .sidebar-item.active .sidebar-link { + background-color: #007bff; + color: white; + font-weight: 500; + } + + /* Mobile responsive */ + @media (max-width: 768px) { + .content-with-sidebar { + flex-direction: column; + } + + .sidebar { + flex: 1; + margin-bottom: 2rem; + } + + .sidebar-nav { + position: static; + } + } + + /* enhanced */ + .breadcrumbs { + font-size: 0.85rem; + margin-bottom: 1rem; + color: #666; + } + + .breadcrumbs a { + color: #007bff; + text-decoration: none; + } + + .breadcrumbs a:hover { + text-decoration: underline; + } + + .sidebar-divider { + margin: 1rem 0; + border: none; + border-top: 1px solid #ddd; + } + + .sidebar-submenu { + list-style: none; + margin: 0; + padding: 0; + } \ No newline at end of file diff --git a/docs/public/filling_tests/debugging_t8n_tools/index.html b/docs/public/filling_tests/debugging_t8n_tools/index.html new file mode 100644 index 00000000000..e90110f1b0a --- /dev/null +++ b/docs/public/filling_tests/debugging_t8n_tools/index.html @@ -0,0 +1,241 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

+
+ + +
+ +

Debugging Transition Tools

+

There are two flags that can help debugging t8n tools or the execution-spec-tests framework:

+
    +
  1. --evm-dump-dir (Default: /logs/evm): Write debug information from t8n tool calls to the specified directory.
  2. +
  3. --traces: Collect traces of the execution from the transition tool.
  4. +
  5. --verify-fixtures: Run go-ethereum’s evm blocktest command to verify the generated test fixtures.
  6. +
+

EVM Dump Directory

+

The --evm-dump-dir flag tells the framework to write the inputs and outputs of every call made to the t8n command to the specified output directory. The aim is to help debugging or simply understand how a test is interacting with the EVM. The default location is logs/evm in the project root.

+

Each test case receives its own sub-directory under the --evm-dump-dir that contains these files which can be easily accessed from the HTML test report generated by fill (located by default in the root of the --output directory).

+
+ ![HTML Report Summary](./img/evm_dump_dir_in_html_report.png){width=auto align=center} +
+

In particular, a script t8n.sh is generated for each call to the t8n command which can be used to reproduce the call to trigger errors or attach a debugger without the need to execute Python.

+

For example, running:

+
fill tests/berlin/eip2930_access_list/ --fork Berlin -m blockchain_test \
+    --evm-dump-dir=/tmp/evm-dump --traces
+

will produce the directory structure:

+
πŸ“‚ /tmp/evm-dump
+└── πŸ“‚ berlin__eip2930_access_list__test_acl__test_access_list
+    └── πŸ“‚ fork_Berlin_blockchain_test
+        └── πŸ“‚ 0
+         Β Β  β”œβ”€β”€ πŸ“„ args.py
+         Β Β  β”œβ”€β”€ πŸ“‚ input
+         Β Β  β”‚Β Β  β”œβ”€β”€ πŸ“„ alloc.json
+         Β Β  β”‚Β Β  β”œβ”€β”€ πŸ“„ env.json
+         Β Β  β”‚Β Β  └── πŸ“„ txs.json
+         Β Β  β”œβ”€β”€ πŸ“‚ output
+         Β Β  β”‚Β Β  β”œβ”€β”€ πŸ“„ alloc.json
+         Β Β  β”‚Β Β  β”œβ”€β”€ πŸ“„ result.json
+         Β Β  β”‚Β Β  └── πŸ“„ txs.rlp
+         Β Β  β”œβ”€β”€ πŸ“„ returncode.txt
+         Β Β  β”œβ”€β”€ πŸ“„ stderr.txt
+         Β Β  β”œβ”€β”€ πŸ“„ stdin.txt
+         Β Β  β”œβ”€β”€ πŸ“„ stdout.txt
+         Β Β  β”œβ”€β”€ πŸ“„ t8n.sh
+            └── πŸ“„ trace-0-0x5c4f07ce52f0a276a06aabdfff16cc693b5e007c018f9a42431e68200e2da515.jsonl
+

where the directory 0 is the starting index of the different calls made to the t8n tool executed during the test, and since the test only contains one block, there is only one directory present.

+

Note, there may be more directories present 1, 2, 3,… if the test executes more blocks.

+

Each directory contains files containing information corresponding to the call, for example, the args.py file contains the arguments passed to the t8n command and the output/alloc.json file contains the output of the t8n command’s --output-alloc flag.

+

The t8n.sh Script

+

The t8n.sh script written to the debug directory can be used to reproduce a specific call made to the t8n command during the test session. For example, if a Besu t8n-server has been started on port 3001, the request made by the test for first block can be reproduced as:

+
/tmp/besu/test_access_list_fork_Berlin/0/t8n.sh 3001
+

which writes the response the from the t8n-server to the console output:

+
{
+  "alloc" : {
+    "0x000000000000000000000000000000000000aaaa" : {
+      "code" : "0x5854505854",
+      "balance" : "0x4",
+      "nonce" : "0x1"
+    },
+    "0x2adc25665018aa1fe0e6bc666dac8fc2697ff9ba" : {
+      "balance" : "0x1bc16d674ecb26ce"
+    },
+    "0xa94f5374fce5edbc8e2a8697c15331677e6ebf0b" : {
+      "balance" : "0x2cd931",
+      "nonce" : "0x1"
+    }
+  },
+  "body" : "0xf8a0b89e01f89b0180078304ef0094000000000000000000000000000000000000aaaa0180f838f7940000000000000000000000000000000000000000e1a0000000000000000000000000000000000000000000000000000000000000000001a02e16eb72206c93c471b5894800495ee9c64ae2d9823bcc4d6adeb5d9d9af0dd4a03be6691e933a0816c59d059a556c27c6753e6ce76d1e357b9201865c80b28df3",
+  "result" : {
+    "stateRoot" : "0x51799508f764047aee6606bc6a00863856f83ee5b91555f00c8a3cbdfbec5acb",
+    ...
+    ...
+  }
+}
+

The t8n.sh is written to the debug directory for all supported t8n tools.

+

Verifying Test Fixtures via evm blocktest

+

The --verify-fixtures flag can be used to run go-ethereum’s evm blocktest command in order to verify the generated JSON test fixtures.

+

For example, running:

+
fill tests/berlin/eip2930_access_list/ --fork Berlin -m blockchain_test \
+    --evm-dump-dir==/tmp/evm-dump \
+    --evm-bin=../evmone/build/bin/evmone-t8n \
+    --verify-fixtures-bin=../go-ethereum/build/bin/evm \
+    --verify-fixtures
+

will additionally run the evm blocktest command on every JSON fixture file and write its output to the EVM dump directory:

+
πŸ“‚ /tmp/evm-dump
+└── πŸ“‚ berlin__eip2930_access_list__test_acl__test_access_list
+    β”œβ”€β”€ πŸ“„ fixtures.json
+    β”œβ”€β”€ πŸ“‚ fork_Berlin_blockchain_test
+    β”‚Β Β  β”œβ”€β”€ πŸ“‚ 0
+    β”‚Β Β  β”‚Β Β  β”œβ”€β”€ πŸ“„ args.py
+    β”‚Β Β  β”‚Β Β  β”œβ”€β”€ πŸ“‚ input
+    β”‚Β Β  β”‚Β Β  β”‚Β Β  β”œβ”€β”€ πŸ“„ alloc.json
+    β”‚Β Β  β”‚Β Β  β”‚Β Β  β”œβ”€β”€ πŸ“„ env.json
+    β”‚Β Β  β”‚Β Β  β”‚Β Β  └── πŸ“„ txs.json
+    β”‚Β Β  β”‚Β Β  β”œβ”€β”€ πŸ“‚ output
+    β”‚Β Β  β”‚Β Β  β”‚Β Β  β”œβ”€β”€ πŸ“„ alloc.json
+    β”‚   ... ... ...
+    β”‚
+    β”œβ”€β”€ πŸ“„ verify_fixtures_args.py
+    β”œβ”€β”€ πŸ“„ verify_fixtures_returncode.txt
+    β”œβ”€β”€ πŸ“„ verify_fixtures.sh
+    β”œβ”€β”€ πŸ“„ verify_fixtures_stderr.txt
+    └── πŸ“„ verify_fixtures_stdout.txt
+

where the verify_fixtures.sh script can be used to reproduce the evm blocktest command.

+

Further --verify-fixtures Examples

+
    +
  1. +

    No fixture verification performed:

    +
    fill
    +
  2. +
  3. +

    Verify fixtures: Use the first evm binary in the PATH to execute both the t8n and blocktest commands (i.e., same binary used; this must be a geth binary):

    +
    fill --verify-fixtures
    +
  4. +
  5. +

    Explicitly specify the evm binary to execute the blocktest command (the first evm binary in the PATH is used for t8n commands; --verify-fixtures is not necessary):

    +
    fill --verify-fixtures-bin=../go-ethereum/build/bin/evm
    +
  6. +
  7. +

    Explicitly set two different evm binaries to execute the t8n and blocktest commands; write debug data to the specified --evm-dump-dir:

    +
    fill --evm-bin=../evmone/build/bin/evmone-t8n \
    +  --verify-fixtures-bin=../go-ethereum/build/bin/evm \
    +  --evm-dump-dir=/tmp/evm-dump
    +
  8. +
  9. +

    Additionally use --single-fixture-per-file to improve the granularity of the reporting of the evm blocktest command by writing the fixture generated by each parametrized test case to its own file.

    +
    fill --evm-bin=../evmone/build/bin/evmone-t8n \
    +  --verify-fixtures-bin=../go-ethereum/build/bin/evm \
    +  --evm-dump-dir=/tmp/evm-dump \
    +  --single-fixture-per-file
    +
  10. +
+

!!! note “Execution scope of evm blocktest

+
Note, by default, that `evm blocktest` is not executed per parametrized test case, but rather per test function. This is because each fixture JSON file contains fixtures for all the parametrized test cases for one test function. This means only one error will be reported, even if multiple fixtures fail within one fixture file.
+
+Additionally, it is only executed after all the test cases in the module have been executed[^1] and will only report the first failing test fixture in all files, even if there are multiple failing fixture files.
+
+This means, by default, that the feedback is not as granular as for test case execution. To improve granularity, and get feedback per parametrized test case use `--single-fixture-per-file`.
+
+
+ +
+ +
+ +
+ + + + + + + + diff --git a/docs/public/filling_tests/filling_tests_command_line/index.html b/docs/public/filling_tests/filling_tests_command_line/index.html new file mode 100644 index 00000000000..dbfe1a6dde6 --- /dev/null +++ b/docs/public/filling_tests/filling_tests_command_line/index.html @@ -0,0 +1,167 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

+
+ + +
+ +

Filling Tests at a Prompt

+

The execution-spec-tests test framework uses the pytest framework for test case collection and execution. The fill command is essentially an alias for pytest, which uses several custom pytest plugins to run transition tools against test cases and generate JSON fixtures.

+

!!! note “Options specific to execution-spec-tests” +The command-line options specific to filling tests can be listed via:

+
```console
+uv run fill --help
+```
+
+See [Custom `fill` Command-Line Options](#custom-fill-command-line-options) for all options.
+
+

Collection - Test Exploration

+

The test cases implemented in the ./tests sub-directory can be listed in the console using:

+
uv run fill --collect-only
+

and can be filtered (by test path, function and parameter substring):

+
uv run fill --collect-only -k warm_coinbase
+

Docstrings are additionally displayed when ran verbosely:

+
uv run fill --collect-only -k warm_coinbase -vv
+

Execution

+

By default, test cases are filled for all forks already deployed to mainnet, but not for forks still under active development, i.e., as of time of writing, Q2 2023:

+
uv run fill
+

will generate fixtures for test cases from Frontier to Shanghai.

+

To generate all the test fixtures defined in the ./tests/shanghai sub-directory and write them to the ./fixtures-shanghai directory, run fill in the top-level directory as:

+
uv run fill ./tests/shanghai --output="fixtures-shanghai"
+

!!! note “Test case verification” +Note, that the (limited set of) test post conditions are tested against the output of the evm t8n command during test generation.

+

To generate all the test fixtures in the tests/shanghai/eip3651_warm_coinbase/test_warm_coinbase.py module, for example, run:

+
uv run fill tests/shanghai/eip3651_warm_coinbase/test_warm_coinbase.py
+

To generate specific test fixtures from a specific test function or even test function and parameter set, obtain the corresponding test ID using:

+
uv run fill --collect-only -q -k test_warm_coinbase
+

This filters the tests by test_warm_coinbase. Then find the relevant test ID in the console output and provide it to fill, for example, for a test function:

+
uv run fill tests/shanghai/eip3651_warm_coinbase/test_warm_coinbase.py::test_warm_coinbase_gas_usage
+

or, for a test function and specific parameter combination:

+
uv run fill tests/shanghai/eip3651_warm_coinbase/test_warm_coinbase.py::test_warm_coinbase_gas_usage[fork_Paris-DELEGATECALL]
+

Execution for Development Forks

+

!!! note "" +By default, test cases are not filled for upcoming Ethereum forks so that they can be readily filled using the evm tool from the latest geth release.

+
In order to fill test cases for an upcoming fork, ensure that the `evm` tool used supports that fork and features under test and use the `--until` or `--fork` flag.
+
+For example, as of Q2 2023, the current fork under active development is `Cancun`:
+```console
+uv run fill --until Cancun
+```
+
+See: [Filling Tests for Features under Development](./filling_tests_dev_fork.md).
+
+

Debugging the t8n Command

+

The --evm-dump-dir flag can be used to dump the inputs and outputs of every call made to the t8n command for debugging purposes, see Debugging Transition Tools.

+

Other Useful Pytest Command-Line Options

+
uv run fill -vv            # More verbose output
+uv run fill -x             # Exit instantly on first error or failed test case
+uv run fill --pdb -nauto   # Drop into the debugger upon error in a test case
+uv run fill -s             # Print stdout from tests to the console during execution
+

Custom fill Command-Line Options

+

To see all the options available to fill, including pytest and pytest plugin options, use --pytest-help.

+

To list the options that only specific to fill, use:

+
uv run fill --help
+

For a complete, up-to-date list of all command-line options, see the Fill Command-Line Options page, which is automatically generated from the current uv run fill --help output.

+
+ +
+ +
+ +
+ + + + + + + + diff --git a/docs/public/filling_tests/filling_tests_dev_fork/index.html b/docs/public/filling_tests/filling_tests_dev_fork/index.html new file mode 100644 index 00000000000..e5db2ada665 --- /dev/null +++ b/docs/public/filling_tests/filling_tests_dev_fork/index.html @@ -0,0 +1,154 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

+
+ + +
+ +

Filling Tests for Features under Development

+

Requirements

+

By default, execution-spec-tests only generates fixtures for forks that have been deployed to mainnet. In order to generate fixtures for evm features that are actively under development:

+
    +
  1. +

    A version of the evm and solc tools that implement the feature must be available (although, typically only a developer version of the evm tool is required, usually the latest stable release of solc is adequate), and,

    +
  2. +
  3. +

    The development fork to test must be explicitly specified on the command-line:

    +

    === “via the --fork flag”

    +
       ```console
    +   uv run fill -k 4844 --fork=Cancun -v
    +   ```
    +
    +

    === “via the --from flag”

    +
       ```console
    +   uv run fill -k 4844 --from=Cancun -v
    +   ```
    +
    +

    === “via the --until flag”

    +
       ```console
    +   uv run fill -k 4844 --until=Cancun -v
    +   ```
    +
    +
  4. +
+

!!! note “Specifying the evm binary via evm-bin” +It is possible to explicitly specify the evm binary used to generate fixtures via the --evm-bin flag, for example,

+
 ```console
+ uv run fill --fork=Cancun --evm-bin=/opt/bin/evm -v
+ ```
+
+

Further Help

+
    +
  1. geth/evm build documentation.
  2. +
  3. solc build documentation.
  4. +
+

!!! note “Verifying evm and solc versions used” +The versions used to generate fixtures are displayed in the console output: +

+Screenshot of pytest test collection console output{align=center} +

+

VS Code Setup

+

By default, VS Code’s Testing View will only show tests for stable forks. To show tests for development forks, uncomment the relevant line in the python.testing.pytestArgs configuration section of included settings file (.vscode/settings.json) to enable the --until=FORK flag. See VS Code Setup for help finding the settings files.

+
+ +
+ +
+ +
+ + + + + + + + diff --git a/docs/public/filling_tests/filling_tests_vs_code/index.html b/docs/public/filling_tests/filling_tests_vs_code/index.html new file mode 100644 index 00000000000..45e84a970b0 --- /dev/null +++ b/docs/public/filling_tests/filling_tests_vs_code/index.html @@ -0,0 +1,123 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

+
+ + +
+ +

Filling Tests in VS Code

+

Prerequisite: VS Code Setup.

+

Exploring Test Cases

+

Implemented test cases can be explored in VS Code’s “Testing” View; click on the conical flask highlighted in the screenshot below.

+
+ ![VS Code Testing Tab](./img/vs_code_exploring_tests.png){ width=auto align=center} +
+

!!! note “Testing EVM Features Under Active Development” +See the VS Code section in Filling Tests for Features under Development to explore tests targeting EVM features under development.

+

Filling and Debugging Test Cases

+
+ ![VS Code Testing Tab](./img/vs_code_executing_tests.png){ width=auto align=center} +
+
+ +
+ +
+ +
+ + + + + + + + diff --git a/docs/public/filling_tests/getting_started/index.html b/docs/public/filling_tests/getting_started/index.html new file mode 100644 index 00000000000..c26daadc5d9 --- /dev/null +++ b/docs/public/filling_tests/getting_started/index.html @@ -0,0 +1,155 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

+
+ + +
+ +

Getting Started: Filling Tests

+

This guide describes how to get started with fill and commonly-used command-line options.

+
    +
  1. +

    Explore test cases via --collect-only and search for test cases that combine PUSH0 and DELEGATECALL in the EVM functionality introduced in the Shanghai hard fork:

    +
    uv run fill --collect-only -k "push0 and delegatecall" tests/shanghai/
    +

    The fill command is based on pytest. The above command uses the optional pytest arguments:

    +
      +
    • --collect-only only collect test cases; don’t execute them.
    • +
    • -k <expression> filter test cases by their test case ID based on the given expression.
    • +
    • tests/shanghai the directory containing the test cases (tells fill to only discover test cases in this directory; default: tests/).
    • +
    +

    Expected console output:

    +
    + ![Screenshot of pytest test collection console output](./img/pytest_collect_only.png){align=center} +
    +
  2. +
  3. +

    Fill state_test fixtures for these test cases:

    +
    uv run fill -k "push0 and delegatecall" tests/shanghai/ -m state_test -v
    +

    where:

    +
      +
    • -m state_test only fills test cases marked as a state_test (see all available markers via uv run fill --markers).
    • +
    • -v enables verbose output.
    • +
    +

    Expected console output:

    +
    + ![Screenshot of fill test collection console output](./img/pytest_run_example.png){align=center} +
    +
  4. +
  5. +

    Verify the generated fixtures:

    +

    a. Check the corresponding fixture file has been generated:

    +
    head fixtures/state_tests/shanghai/eip3855_push0/push0/push0_contract_during_call_contexts.json
    +

    b. Open the generated HTML test using the link provided at the bottom of the console output. This is written to the output directory at:

    +
    ./fixtures/.meta/report_fill.html
    +
  6. +
+

Next Steps

+
    +
  1. Learn useful command-line flags.
  2. +
  3. Execute tests for features under development via the --fork flag.
  4. +
  5. Optional: Configure VS Code to auto-format Python code and execute tests within VS Code.
  6. +
  7. Implement a new test case, see Writing Tests.
  8. +
+
+ +
+ +
+ +
+ + + + + + + + diff --git a/docs/filling_tests/img/evm_dump_dir_in_html_report.png b/docs/public/filling_tests/img/evm_dump_dir_in_html_report.png similarity index 100% rename from docs/filling_tests/img/evm_dump_dir_in_html_report.png rename to docs/public/filling_tests/img/evm_dump_dir_in_html_report.png diff --git a/docs/filling_tests/img/pytest_collect_only.png b/docs/public/filling_tests/img/pytest_collect_only.png similarity index 100% rename from docs/filling_tests/img/pytest_collect_only.png rename to docs/public/filling_tests/img/pytest_collect_only.png diff --git a/docs/filling_tests/img/pytest_run_example.png b/docs/public/filling_tests/img/pytest_run_example.png similarity index 100% rename from docs/filling_tests/img/pytest_run_example.png rename to docs/public/filling_tests/img/pytest_run_example.png diff --git a/docs/filling_tests/img/vs_code_executing_tests.png b/docs/public/filling_tests/img/vs_code_executing_tests.png similarity index 100% rename from docs/filling_tests/img/vs_code_executing_tests.png rename to docs/public/filling_tests/img/vs_code_executing_tests.png diff --git a/docs/filling_tests/img/vs_code_exploring_tests.kra b/docs/public/filling_tests/img/vs_code_exploring_tests.kra similarity index 100% rename from docs/filling_tests/img/vs_code_exploring_tests.kra rename to docs/public/filling_tests/img/vs_code_exploring_tests.kra diff --git a/docs/filling_tests/img/vs_code_exploring_tests.png b/docs/public/filling_tests/img/vs_code_exploring_tests.png similarity index 100% rename from docs/filling_tests/img/vs_code_exploring_tests.png rename to docs/public/filling_tests/img/vs_code_exploring_tests.png diff --git a/docs/public/filling_tests/index.html b/docs/public/filling_tests/index.html new file mode 100644 index 00000000000..87bd1753e59 --- /dev/null +++ b/docs/public/filling_tests/index.html @@ -0,0 +1,199 @@ + + + + + + + + Filling_tests + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +

Filling_tests

+ +
+ + + + + + + + +

Filling Tests

+
July 9, 2025
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+ + +
+ + + +
+ + + + + + + +
+ + + +
+ +
+ + + + + + + + diff --git a/docs/public/filling_tests/index.xml b/docs/public/filling_tests/index.xml new file mode 100644 index 00000000000..5f0a4f09c07 --- /dev/null +++ b/docs/public/filling_tests/index.xml @@ -0,0 +1,68 @@ + + + + Filling_tests on EEST Docs + http://localhost:1313/filling_tests/ + Recent content in Filling_tests on EEST Docs + Hugo + en-us + Wed, 09 Jul 2025 12:42:33 +0000 + + + Filling Tests + http://localhost:1313/filling_tests/main/ + Wed, 09 Jul 2025 12:42:33 +0000 + http://localhost:1313/filling_tests/main/ + <p>Execution of test cases against clients is a two-step process:</p> <ol> <li>JSON test fixtures are generated from the Python test cases found in <code>./tests</code> using <code>fill</code> and an EVM transition tool (<code>t8n</code>) implementation.</li> <li>Clients &ldquo;consume&rdquo; the JSON fixtures via either a dedicated, client-specific interface or a testing environment such as Hive.</li> </ol> <p>The process of generating fixtures is often referred to as &ldquo;filling&rdquo; the tests.</p> <div class="callout callout-info"> <div class="callout-title">The <code>execute</code> command</div> <div class="callout-content"> The <code>execute</code> command directly executes Python test cases against a client via its RPC without using generated JSON fixtures. For all other methods of testing clients, the JSON fixtures are required. For more information, see <a href="../running_tests/execute/main.md">Executing Tests</a>. </div> </div> <h2 id="transition-tools-t8n">Transition Tools (<code>t8n</code>)</h2> <p>The <code>fill</code> command requires an EVM <code>t8n</code> tool provided by most clients in order to generate the JSON fixtures. The <code>t8n</code> tool is mainly responsible for calculating the post-state of the EVM after executing a transaction, most relevantly, it calculates the updated state root.</p> + + + + http://localhost:1313/filling_tests/debugging_t8n_tools/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/filling_tests/debugging_t8n_tools/ + <h1 id="debugging-transition-tools">Debugging Transition Tools</h1> <p>There are two flags that can help debugging <code>t8n</code> tools or the execution-spec-tests framework:</p> <ol> <li><code>--evm-dump-dir</code> (Default: <repo>/logs/evm): Write debug information from <code>t8n</code> tool calls to the specified directory.</li> <li><code>--traces</code>: Collect traces of the execution from the transition tool.</li> <li><code>--verify-fixtures</code>: Run go-ethereum&rsquo;s <code>evm blocktest</code> command to verify the generated test fixtures.</li> </ol> <h2 id="evm-dump-directory">EVM Dump Directory</h2> <p>The <code>--evm-dump-dir</code> flag tells the framework to write the inputs and outputs of every call made to the <code>t8n</code> command to the specified output directory. The aim is to help debugging or simply understand how a test is interacting with the EVM. The default location is <code>logs/evm</code> in the project root.</p> + + + + http://localhost:1313/filling_tests/filling_tests_command_line/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/filling_tests/filling_tests_command_line/ + <h1 id="filling-tests-at-a-prompt">Filling Tests at a Prompt</h1> <p>The execution-spec-tests test framework uses the <a href="https://docs.pytest.org/en/latest/">pytest framework</a> for test case collection and execution. The <code>fill</code> command is essentially an alias for <code>pytest</code>, which uses several <a href="../library/pytest_plugins/main.md">custom pytest plugins</a> to run transition tools against test cases and generate JSON fixtures.</p> <p>!!! note &ldquo;Options specific to execution-spec-tests&rdquo; The command-line options specific to filling tests can be listed via:</p> <pre><code>```console uv run fill --help ``` See [Custom `fill` Command-Line Options](#custom-fill-command-line-options) for all options. </code></pre> <h2 id="collection---test-exploration">Collection - Test Exploration</h2> <p>The test cases implemented in the <code>./tests</code> sub-directory can be listed in the console using:</p> + + + + http://localhost:1313/filling_tests/filling_tests_dev_fork/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/filling_tests/filling_tests_dev_fork/ + <h1 id="filling-tests-for-features-under-development">Filling Tests for Features under Development</h1> <h2 id="requirements">Requirements</h2> <p>By default, execution-spec-tests only generates fixtures for forks that have been deployed to mainnet. In order to generate fixtures for evm features that are actively under development:</p> <ol> <li> <p>A version of the <code>evm</code> and <code>solc</code> tools that implement the feature must be available (although, typically only a developer version of the <code>evm</code> tool is required, usually the latest stable release of <code>solc</code> is adequate), and,</p> + + + + http://localhost:1313/filling_tests/filling_tests_vs_code/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/filling_tests/filling_tests_vs_code/ + <h1 id="filling-tests-in-vs-code">Filling Tests in VS Code</h1> <p>Prerequisite: <a href="../getting_started/setup_vs_code.md">VS Code Setup</a>.</p> <h2 id="exploring-test-cases">Exploring Test Cases</h2> <p>Implemented test cases can be explored in VS Code&rsquo;s &ldquo;Testing&rdquo; View; click on the conical flask highlighted in the screenshot below.</p> <figure markdown> <!-- markdownlint-disable MD033 (MD033=no-inline-html) --> ![VS Code Testing Tab](./img/vs_code_exploring_tests.png){ width=auto align=center} </figure> <p>!!! note &ldquo;Testing EVM Features Under Active Development&rdquo; See <a href="./filling_tests_dev_fork.md#vs-code-setup">the VS Code section</a> in <a href="./filling_tests_dev_fork.md">Filling Tests for Features under Development</a> to explore tests targeting EVM features under development.</p> + + + + http://localhost:1313/filling_tests/getting_started/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/filling_tests/getting_started/ + <h1 id="getting-started-filling-tests">Getting Started: Filling Tests</h1> <p>This guide describes how to get started with <code>fill</code> and commonly-used command-line options.</p> <ol> <li> <p>Explore test cases via <code>--collect-only</code> and search for test cases that combine <code>PUSH0</code> and <code>DELEGATECALL</code> in the EVM functionality introduced in the Shanghai hard fork:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-console" data-lang="console"><span style="display:flex;"><span>uv run fill --collect-only -k &#34;push0 and delegatecall&#34; tests/shanghai/ </span></span></code></pre></div><p>The <code>fill</code> command is based on <a href="https://docs.pytest.org/en/stable/"><code>pytest</code></a>. The above command uses the <a href="https://docs.pytest.org/en/stable/how-to/usage.html">optional pytest arguments</a>:</p> <ul> <li><code>--collect-only</code> only collect test cases; don&rsquo;t execute them.</li> <li><code>-k &lt;expression&gt;</code> filter test cases by their test case ID based on the given expression.</li> <li><code>tests/shanghai</code> the directory containing the test cases (tells <code>fill</code> to only discover test cases in this directory; default: <code>tests/</code>).</li> </ul> <p>Expected console output:</p> + + + + http://localhost:1313/filling_tests/test_ids/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/filling_tests/test_ids/ + <h1 id="an-explanation-of-test-ids-generated-by-fill">An explanation of test IDs generated by <code>fill</code></h1> <h2 id="test-case-organization">Test Case Organization</h2> <p>Test cases are implemented in Python &ldquo;modules&rdquo;, which are organized by folder, named after the fork where the feature-under-test was introduced, for example:</p> <ul> <li><code>tests/cancun/</code> contains tests for features added in the Cancun hardfork.</li> <li><code>tests/prague/</code> contains tests for features added in the Prague hardfork.</li> </ul> <h2 id="test-id-generation">Test ID generation</h2> <p>A test ID is a string, generated by the test framework, that uniquely identifies a test case. It&rsquo;s format is:</p> + + + + http://localhost:1313/filling_tests/transition_tool_support/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/filling_tests/transition_tool_support/ + <h1 id="transition-tool-support">Transition Tool Support</h1> <p>The following transition tools are supported by the framework:</p> <table> <thead> <tr> <th>Client</th> <th><code>t8n</code> Tool</th> <th>Tracing Support</th> </tr> </thead> <tbody> <tr> <td><a href="https://github.com/ethereum/evmone">ethereum/evmone</a></td> <td><code>evmone-t8n</code></td> <td>Yes</td> </tr> <tr> <td><a href="https://github.com/ethereum/execution-specs">ethereum/execution-specs</a></td> <td><a href="https://github.com/petertdavies/ethereum-spec-evm-resolver"><code>ethereum-spec-evm-resolver</code></a></td> <td>Yes</td> </tr> <tr> <td><a href="https://github.com/ethereumjs/ethereumjs-monorepo">ethereumjs</a></td> <td><a href="https://github.com/ethereumjs/ethereumjs-monorepo/tree/master/packages/vm/test/t8n"><code>ethereumjs-t8ntool.sh</code></a></td> <td>No</td> </tr> <tr> <td><a href="https://github.com/ethereum/go-ethereum">ethereum/go-ethereum</a></td> <td><a href="https://github.com/ethereum/go-ethereum/tree/master/cmd/evm"><code>evm t8n</code></a></td> <td>Yes</td> </tr> <tr> <td><a href="https://github.com/hyperledger/besu/tree/main/ethereum/evmtool">hyperledger/besu</a></td> <td><a href="https://github.com/hyperledger/besu/tree/main/ethereum/evmtool"><code>evmtool t8n-server</code></a></td> <td>Yes</td> </tr> <tr> <td><a href="https://github.com/status-im/nimbus-eth1">status-im/nimbus-eth1</a></td> <td><a href="https://github.com/status-im/nimbus-eth1/blob/master/tools/t8n/readme.md"><code>t8n</code></a></td> <td>Yes</td> </tr> </tbody> </table> + + + diff --git a/docs/public/filling_tests/main/index.html b/docs/public/filling_tests/main/index.html new file mode 100644 index 00000000000..23d177a514a --- /dev/null +++ b/docs/public/filling_tests/main/index.html @@ -0,0 +1,144 @@ + + + + + + + + Filling Tests + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

Filling Tests

+
+ + +
+ +

Execution of test cases against clients is a two-step process:

+
    +
  1. JSON test fixtures are generated from the Python test cases found in ./tests using fill and an EVM transition tool (t8n) implementation.
  2. +
  3. Clients “consume” the JSON fixtures via either a dedicated, client-specific interface or a testing environment such as Hive.
  4. +
+

The process of generating fixtures is often referred to as “filling” the tests.

+ + +
+
The execute command
+
+ The execute command directly executes Python test cases against a client via its RPC without using generated JSON fixtures. For all other methods of testing clients, the JSON fixtures are required. For more information, see Executing Tests. +
+
+

Transition Tools (t8n)

+

The fill command requires an EVM t8n tool provided by most clients in order to generate the JSON fixtures. The t8n tool is mainly responsible for calculating the post-state of the EVM after executing a transaction, most relevantly, it calculates the updated state root.

+

Ethereum Execution Layer Specification (EELS)

+

By default, the Ethereum Execution Layer Specification (EELS) reference implementation of the t8n tool is used to generate test fixtures for all forks that have been deployed to Ethereum mainnet. We strong encourage EIP authors to provide a reference implementation of their EIP in EELS, so that it can be used to generate test fixtures for features under active development.

+

Limitations of Filling

+

The “fill-consume” method follows a differential testing approach: A reference implementation is used to generate JSON test fixtures, which can then be executed against other EVM clients. However:

+ + +
+
Successfully filling does not guarantee correctness
+
+

Some tests cases, particularly those without straightforward post-checks, such as certain gas calculations, may allow subtle inconsistencies to slip through during filling.

+

Consequently, filling the tests does not ensure the client’s correctness. Clients must consume the tests to be considered correctly tested, even if that client was used to fill the tests.

+ +
+
+

Filling Static Tests from ethereum/tests

+

Filling static test fillers in YAML or JSON formats from ethereum/tests is possible by adding the --fill-static-tests to the fill command.

+

This functionality is only available for backwards compatibility and copying legacy tests from the ethereum/tests repository into this one.

+

Adding new static test fillers is otherwise not allowed.

+
+ +
+ +
+ +
+ + + + + + + + diff --git a/docs/public/filling_tests/page/1/index.html b/docs/public/filling_tests/page/1/index.html new file mode 100644 index 00000000000..3192b4181c6 --- /dev/null +++ b/docs/public/filling_tests/page/1/index.html @@ -0,0 +1,10 @@ + + + + http://localhost:1313/filling_tests/ + + + + + + diff --git a/docs/public/filling_tests/page/2/index.html b/docs/public/filling_tests/page/2/index.html new file mode 100644 index 00000000000..c3624357d6b --- /dev/null +++ b/docs/public/filling_tests/page/2/index.html @@ -0,0 +1,169 @@ + + + + + + + + Filling_tests + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +

Filling_tests

+ +
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+ + +
+ + + +
+ + + + + + + +
+ + + +
+ +
+ + + + + + + + diff --git a/docs/public/filling_tests/test_ids/index.html b/docs/public/filling_tests/test_ids/index.html new file mode 100644 index 00000000000..4c6caac06e7 --- /dev/null +++ b/docs/public/filling_tests/test_ids/index.html @@ -0,0 +1,170 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

+
+ + +
+ +

An explanation of test IDs generated by fill

+

Test Case Organization

+

Test cases are implemented in Python “modules”, which are organized by folder, named after the fork where the feature-under-test was introduced, for example:

+
    +
  • tests/cancun/ contains tests for features added in the Cancun hardfork.
  • +
  • tests/prague/ contains tests for features added in the Prague hardfork.
  • +
+

Test ID generation

+

A test ID is a string, generated by the test framework, that uniquely identifies a test case. It’s format is:

+
<python_test_module_path>::<python_test_function_name>[<parameter_1_id>-...-<parameter_N_id]
+

Let’s use the following simple test case example to understand this format:

+
tests/istanbul/eip1344_chainid/test_chainid.py::test_chainid[fork_Cancun-blockchain_test]
+

The components map as following:

+
    +
  • <python_test_module_path> - the Python “module” (file) where the test is implemented tests/istanbul/eip1344_chainid/test_chainid.py,
  • +
  • <python_test_function_name> - the Python test function: test_chainid,
  • +
  • [<parameter_1_id>-...-<parameter_N_id] - the test parameters, this test case has the following parameters: +
      +
    • fork_Cancun, to read “fork = Cancun”, the fork the test case is filled for,
    • +
    • blockchain_test, the test type.
    • +
    +
  • +
+

Although test_chainid is not directly parametrized on the test function level, the framework always parametrizes tests by fork and, if possible, by test type. If we inspect its function signature, we see that it’s native test format is of type StateTestFiller:

+
@pytest.mark.valid_from("Istanbul")
+def test_chainid(state_test: StateTestFiller, pre: Alloc):
+    """Test CHAINID opcode."""
+    ...
+

Parametrization by Fork

+

Every test case is parametrized by the fork where the feature-under-test remains valid, for example:

+
    +
  • Test cases in tests/cancun/ get filled for Cancun and Prague.
  • +
  • Test cases in tests/prague/, only get filled for Prague, at the time of writing, as Prague is the current fork in development.
  • +
+

All test IDs contain the fork_<name> parameter used to generate the test case in the test ID, e.g., test_Cancun.

+

Transition Forks

+

The test framework can also generate blockchain tests containing blocks that span a fork boundary, these test cases receive a special fork parameter name which contain both fork names and the timestamp at which the transition was made, e.g., fork_CancunToPragueAtTime15k.

+

Parametrization by Test Type

+

Each Python test case is also typically parametrized by test type, respectively fixture format. For example, if the test is implemented as a state_test, the test framework will additionally generate the following blockchain test fixtures (consisting of a single block with a single transaction):

+
    +
  • a blockchain_test which can be tested via the Hive eest/consume-rlp simulator (or directly via a dedicated client interface).
  • +
  • a blockchain_engine_test (for post-merge forks) which can be tested via the Hive eest/consume-engine simulator.
  • +
+

Example: The Test IDs generated for test_chainid

+

To see all the test cases and their IDs that get generated from London until Shanghai for test_chainid, we can execute fill with the --collect-only -q flags:

+
fill tests/istanbul/eip1344_chainid/test_chainid.py --from London --until Shanghai --collect-only -q 
+

which lists the following test IDs:

+
tests/istanbul/eip1344_chainid/test_chainid.py::test_chainid[fork_London-blockchain_test]
+tests/istanbul/eip1344_chainid/test_chainid.py::test_chainid[fork_London-state_test]
+tests/istanbul/eip1344_chainid/test_chainid.py::test_chainid[fork_Paris-blockchain_test]
+tests/istanbul/eip1344_chainid/test_chainid.py::test_chainid[fork_Paris-blockchain_test_engine]
+tests/istanbul/eip1344_chainid/test_chainid.py::test_chainid[fork_Paris-state_test]
+tests/istanbul/eip1344_chainid/test_chainid.py::test_chainid[fork_Shanghai-blockchain_test]
+tests/istanbul/eip1344_chainid/test_chainid.py::test_chainid[fork_Shanghai-blockchain_test_engine]
+tests/istanbul/eip1344_chainid/test_chainid.py::test_chainid[fork_Shanghai-state_test]
+

Additional Parametrization

+

The test function tests/cancun/eip4844_blobs/test_blob_txs.py::test_blob_type_tx_pre_fork is additionally parametrized:

+
tests/cancun/eip4844_blobs/test_blob_txs.py::test_blob_type_tx_pre_fork[fork_ShanghaiToCancunAtTime15k-blockchain_test-no_blob_tx]
+tests/cancun/eip4844_blobs/test_blob_txs.py::test_blob_type_tx_pre_fork[fork_ShanghaiToCancunAtTime15k-blockchain_test-one_blob_tx]
+

The strings no_blob_tx and one_blob_tx are additional descriptive parameter IDs that indicate the focus of the test.

+
+ +
+ +
+ +
+ + + + + + + + diff --git a/docs/public/filling_tests/transition_tool_support/index.html b/docs/public/filling_tests/transition_tool_support/index.html new file mode 100644 index 00000000000..94957147b90 --- /dev/null +++ b/docs/public/filling_tests/transition_tool_support/index.html @@ -0,0 +1,153 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

+
+ + +
+ +

Transition Tool Support

+

The following transition tools are supported by the framework:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Clientt8n ToolTracing Support
ethereum/evmoneevmone-t8nYes
ethereum/execution-specsethereum-spec-evm-resolverYes
ethereumjsethereumjs-t8ntool.shNo
ethereum/go-ethereumevm t8nYes
hyperledger/besuevmtool t8n-serverYes
status-im/nimbus-eth1t8nYes
+
+ +
+ +
+ +
+ + + + + + + + diff --git a/docs/public/images/filling_tests/evm_dump_dir_in_html_report.png b/docs/public/images/filling_tests/evm_dump_dir_in_html_report.png new file mode 100644 index 00000000000..1979b5dd40f Binary files /dev/null and b/docs/public/images/filling_tests/evm_dump_dir_in_html_report.png differ diff --git a/docs/public/images/filling_tests/pytest_collect_only.png b/docs/public/images/filling_tests/pytest_collect_only.png new file mode 100644 index 00000000000..a20e58c2c8c Binary files /dev/null and b/docs/public/images/filling_tests/pytest_collect_only.png differ diff --git a/docs/public/images/filling_tests/pytest_run_example.png b/docs/public/images/filling_tests/pytest_run_example.png new file mode 100644 index 00000000000..96df337a21f Binary files /dev/null and b/docs/public/images/filling_tests/pytest_run_example.png differ diff --git a/docs/public/images/filling_tests/vs_code_executing_tests.png b/docs/public/images/filling_tests/vs_code_executing_tests.png new file mode 100644 index 00000000000..7c46ae2849b Binary files /dev/null and b/docs/public/images/filling_tests/vs_code_executing_tests.png differ diff --git a/docs/public/images/filling_tests/vs_code_exploring_tests.png b/docs/public/images/filling_tests/vs_code_exploring_tests.png new file mode 100644 index 00000000000..3618a2249d6 Binary files /dev/null and b/docs/public/images/filling_tests/vs_code_exploring_tests.png differ diff --git a/docs/getting_started/img/testing_pandas.png b/docs/public/images/getting_started/testing_pandas.png similarity index 100% rename from docs/getting_started/img/testing_pandas.png rename to docs/public/images/getting_started/testing_pandas.png diff --git a/docs/getting_started/img/vscode_extension_disable_for_workspace.png b/docs/public/images/getting_started/vscode_extension_disable_for_workspace.png similarity index 100% rename from docs/getting_started/img/vscode_extension_disable_for_workspace.png rename to docs/public/images/getting_started/vscode_extension_disable_for_workspace.png diff --git a/docs/public/images/gohugo-default-sample-hero-image.jpg b/docs/public/images/gohugo-default-sample-hero-image.jpg new file mode 100644 index 00000000000..06815836a5f Binary files /dev/null and b/docs/public/images/gohugo-default-sample-hero-image.jpg differ diff --git a/docs/writing_tests/img/eest_make_test.mp4 b/docs/public/images/img/eest_make_test.mp4 similarity index 100% rename from docs/writing_tests/img/eest_make_test.mp4 rename to docs/public/images/img/eest_make_test.mp4 diff --git a/docs/writing_tests/img/eip_reference_spec_console_output.png b/docs/public/images/img/eip_reference_spec_console_output.png similarity index 100% rename from docs/writing_tests/img/eip_reference_spec_console_output.png rename to docs/public/images/img/eip_reference_spec_console_output.png diff --git a/docs/writing_tests/img/eip_reference_spec_console_output_fail.png b/docs/public/images/img/eip_reference_spec_console_output_fail.png similarity index 100% rename from docs/writing_tests/img/eip_reference_spec_console_output_fail.png rename to docs/public/images/img/eip_reference_spec_console_output_fail.png diff --git a/docs/public/images/img/testing_pandas.png b/docs/public/images/img/testing_pandas.png new file mode 100644 index 00000000000..34d6d91ea13 Binary files /dev/null and b/docs/public/images/img/testing_pandas.png differ diff --git a/docs/public/images/img/vscode_extension_disable_for_workspace.png b/docs/public/images/img/vscode_extension_disable_for_workspace.png new file mode 100644 index 00000000000..5ffb5a6c959 Binary files /dev/null and b/docs/public/images/img/vscode_extension_disable_for_workspace.png differ diff --git a/docs/img/ETH-logo-icon.svg b/docs/public/images/main/ETH-logo-icon.svg similarity index 100% rename from docs/img/ETH-logo-icon.svg rename to docs/public/images/main/ETH-logo-icon.svg diff --git a/docs/img/Ethereum-logo-600px.png b/docs/public/images/main/Ethereum-logo-600px.png similarity index 100% rename from docs/img/Ethereum-logo-600px.png rename to docs/public/images/main/Ethereum-logo-600px.png diff --git a/docs/img/annotated-coverage.jpg b/docs/public/images/main/annotated-coverage.jpg similarity index 100% rename from docs/img/annotated-coverage.jpg rename to docs/public/images/main/annotated-coverage.jpg diff --git a/docs/img/execution_spec_tests.jpg b/docs/public/images/main/execution_spec_tests.jpg similarity index 100% rename from docs/img/execution_spec_tests.jpg rename to docs/public/images/main/execution_spec_tests.jpg diff --git a/docs/img/favicon.ico b/docs/public/images/main/favicon.ico similarity index 100% rename from docs/img/favicon.ico rename to docs/public/images/main/favicon.ico diff --git a/docs/public/images/main/fixture-gen-flowchart.png b/docs/public/images/main/fixture-gen-flowchart.png new file mode 100644 index 00000000000..3f5d820797f Binary files /dev/null and b/docs/public/images/main/fixture-gen-flowchart.png differ diff --git a/docs/img/original-coverage-loss.png b/docs/public/images/main/original-coverage-loss.png similarity index 100% rename from docs/img/original-coverage-loss.png rename to docs/public/images/main/original-coverage-loss.png diff --git a/docs/public/images/writing_tests/eest_make_test.gif b/docs/public/images/writing_tests/eest_make_test.gif new file mode 100644 index 00000000000..e2842a9f6ba Binary files /dev/null and b/docs/public/images/writing_tests/eest_make_test.gif differ diff --git a/docs/public/images/writing_tests/eest_make_test.mp4 b/docs/public/images/writing_tests/eest_make_test.mp4 new file mode 100644 index 00000000000..5694dc8de07 Binary files /dev/null and b/docs/public/images/writing_tests/eest_make_test.mp4 differ diff --git a/docs/public/images/writing_tests/eip_reference_spec_console_output.png b/docs/public/images/writing_tests/eip_reference_spec_console_output.png new file mode 100644 index 00000000000..f043ed2fef4 Binary files /dev/null and b/docs/public/images/writing_tests/eip_reference_spec_console_output.png differ diff --git a/docs/public/images/writing_tests/eip_reference_spec_console_output_fail.png b/docs/public/images/writing_tests/eip_reference_spec_console_output_fail.png new file mode 100644 index 00000000000..2c36f0dfbaf Binary files /dev/null and b/docs/public/images/writing_tests/eip_reference_spec_console_output_fail.png differ diff --git a/docs/public/img/ETH-logo-icon.svg b/docs/public/img/ETH-logo-icon.svg new file mode 100644 index 00000000000..feffde6a690 --- /dev/null +++ b/docs/public/img/ETH-logo-icon.svg @@ -0,0 +1,19 @@ + + + + + + + + + + + diff --git a/docs/public/img/Ethereum-logo-600px.png b/docs/public/img/Ethereum-logo-600px.png new file mode 100644 index 00000000000..7f65db744b9 Binary files /dev/null and b/docs/public/img/Ethereum-logo-600px.png differ diff --git a/docs/public/img/annotated-coverage.jpg b/docs/public/img/annotated-coverage.jpg new file mode 100644 index 00000000000..ef4a403ec34 Binary files /dev/null and b/docs/public/img/annotated-coverage.jpg differ diff --git a/docs/public/img/execution_spec_tests.jpg b/docs/public/img/execution_spec_tests.jpg new file mode 100644 index 00000000000..51796da1036 Binary files /dev/null and b/docs/public/img/execution_spec_tests.jpg differ diff --git a/docs/public/img/favicon.ico b/docs/public/img/favicon.ico new file mode 100644 index 00000000000..feffde6a690 --- /dev/null +++ b/docs/public/img/favicon.ico @@ -0,0 +1,19 @@ + + + + + + + + + + + diff --git a/docs/public/img/main/ETH-logo-icon.svg b/docs/public/img/main/ETH-logo-icon.svg new file mode 100644 index 00000000000..feffde6a690 --- /dev/null +++ b/docs/public/img/main/ETH-logo-icon.svg @@ -0,0 +1,19 @@ + + + + + + + + + + + diff --git a/docs/public/img/main/Ethereum-logo-600px.png b/docs/public/img/main/Ethereum-logo-600px.png new file mode 100644 index 00000000000..7f65db744b9 Binary files /dev/null and b/docs/public/img/main/Ethereum-logo-600px.png differ diff --git a/docs/public/img/main/annotated-coverage.jpg b/docs/public/img/main/annotated-coverage.jpg new file mode 100644 index 00000000000..ef4a403ec34 Binary files /dev/null and b/docs/public/img/main/annotated-coverage.jpg differ diff --git a/docs/public/img/main/execution_spec_tests.jpg b/docs/public/img/main/execution_spec_tests.jpg new file mode 100644 index 00000000000..51796da1036 Binary files /dev/null and b/docs/public/img/main/execution_spec_tests.jpg differ diff --git a/docs/public/img/main/favicon.ico b/docs/public/img/main/favicon.ico new file mode 100644 index 00000000000..feffde6a690 --- /dev/null +++ b/docs/public/img/main/favicon.ico @@ -0,0 +1,19 @@ + + + + + + + + + + + diff --git a/docs/public/img/main/original-coverage-loss.png b/docs/public/img/main/original-coverage-loss.png new file mode 100644 index 00000000000..5fead1bc1e2 Binary files /dev/null and b/docs/public/img/main/original-coverage-loss.png differ diff --git a/docs/public/img/original-coverage-loss.png b/docs/public/img/original-coverage-loss.png new file mode 100644 index 00000000000..5fead1bc1e2 Binary files /dev/null and b/docs/public/img/original-coverage-loss.png differ diff --git a/docs/public/index.html b/docs/public/index.html new file mode 100644 index 00000000000..782247ed029 --- /dev/null +++ b/docs/public/index.html @@ -0,0 +1,12 @@ + + + + + + + Redirecting... + + +

Redirecting to main page...

+ + \ No newline at end of file diff --git a/docs/public/index.xml b/docs/public/index.xml new file mode 100644 index 00000000000..2b27afc6027 --- /dev/null +++ b/docs/public/index.xml @@ -0,0 +1,509 @@ + + + + EEST Docs + http://localhost:1313/ + Recent content on EEST Docs + Hugo + en-us + Wed, 09 Jul 2025 12:42:33 +0000 + + + Adding a New Test + http://localhost:1313/main/writing_tests/adding_a_new_test/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/writing_tests/adding_a_new_test/ + <p>All test cases are located underneath the <code>tests</code> directory, which are then organized by fork. Each fork contains sub-directories containing test sub-categories.</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-text" data-lang="text"><span style="display:flex;"><span>πŸ“ execution-test-specs/ </span></span><span style="display:flex;"><span>β”œβ”€β•΄πŸ“ tests/ </span></span><span style="display:flex;"><span>| β”œβ”€β”€ πŸ“„ __init__.py </span></span><span style="display:flex;"><span>β”‚ β”œβ”€β”€ πŸ“ cancun/ </span></span><span style="display:flex;"><span>| | β”œβ”€β”€ πŸ“„ __init__.py </span></span><span style="display:flex;"><span>β”‚ | └── πŸ“ eip4844_blobs/ </span></span><span style="display:flex;"><span>| | β”œβ”€β”€ πŸ“„ __init__.py </span></span><span style="display:flex;"><span>| | β”œβ”€β”€ πŸ“„ test_blobhash_opcode.py </span></span><span style="display:flex;"><span>| | β”œβ”€β”€ πŸ“„ test_excess_blob_gas.py </span></span><span style="display:flex;"><span>| | └── πŸ“„ ... </span></span><span style="display:flex;"><span>| β”œβ”€β”€ πŸ“ shanghai </span></span><span style="display:flex;"><span>| | β”œβ”€β”€ πŸ“ eip3651_warm_coinbase </span></span><span style="display:flex;"><span>| | | β”œβ”€β”€ πŸ“„ __init__.py </span></span><span style="display:flex;"><span>| | | └── πŸ“„ test_warm_coinbase.py </span></span><span style="display:flex;"><span>| | β”œβ”€β”€ πŸ“ eip3855_push0 </span></span><span style="display:flex;"><span>| | | β”œβ”€β”€ πŸ“„ __init__.py </span></span><span style="display:flex;"><span>| | | └── πŸ“„ test_push0.py </span></span><span style="display:flex;"><span>| | β”œβ”€β”€ πŸ“... </span></span><span style="display:flex;"><span>| | ... </span></span><span style="display:flex;"><span>β”‚ └── πŸ“ ... </span></span></code></pre></div><p>Each category/sub-directory may have multiple Python test modules (<code>*.py</code>) which in turn may contain many test functions. The test functions themselves are always parametrized by fork (by the framework).</p> + + + Getting Started + http://localhost:1313/main/filling_tests/getting_started/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/filling_tests/getting_started/ + <h1 id="getting-started-filling-tests">Getting Started: Filling Tests</h1> <p>This guide describes how to get started with <code>fill</code> and commonly-used command-line options.</p> <ol> <li> <p>Explore test cases via <code>--collect-only</code> and search for test cases that combine <code>PUSH0</code> and <code>DELEGATECALL</code> in the EVM functionality introduced in the Shanghai hard fork:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-console" data-lang="console"><span style="display:flex;"><span>uv run fill --collect-only -k &#34;push0 and delegatecall&#34; tests/shanghai/ </span></span></code></pre></div><p>The <code>fill</code> command is based on <a href="https://docs.pytest.org/en/stable/" target="_blank" rel="noopener"><code>pytest</code></a>. The above command uses the <a href="https://docs.pytest.org/en/stable/how-to/usage.html" target="_blank" rel="noopener">optional pytest arguments</a>:</p> <ul> <li><code>--collect-only</code> only collect test cases; don&rsquo;t execute them.</li> <li><code>-k &lt;expression&gt;</code> filter test cases by their test case ID based on the given expression.</li> <li><code>tests/shanghai</code> the directory containing the test cases (tells <code>fill</code> to only discover test cases in this directory; default: <code>tests/</code>).</li> </ul> <p>Expected console output:</p> + + + Managing Configurations + http://localhost:1313/main/dev_docs/configurations/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/dev_docs/configurations/ + <p>Configurations are managed by the <code>config</code> package. It provides both environment and application configurations.</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-console" data-lang="console"><span style="display:flex;"><span>. </span></span><span style="display:flex;"><span>β”œβ”€β”€ src </span></span><span style="display:flex;"><span>β”‚ └── πŸ“ config [Application wide environment and configurations] </span></span><span style="display:flex;"><span>β”‚ β”œβ”€β”€ πŸ“„ __init__.py </span></span><span style="display:flex;"><span>β”‚ β”œβ”€β”€ πŸ“„ app.py [Configurations for application framework] </span></span><span style="display:flex;"><span>β”‚ β”œβ”€β”€ πŸ“„ docs.py [Configurations for documentation] </span></span><span style="display:flex;"><span>β”‚ └── πŸ“„ env.py [Exposes `env.yaml` to the application] </span></span><span style="display:flex;"><span>└── πŸ“„ env.yaml [Environment file (git ignored)] </span></span></code></pre></div><h2 id="environment-configurations">Environment Configurations</h2> <p>Application-wide <a href="https://www.12factor.net/config" target="_blank" rel="noopener">environment configuration</a>, which varies across staging, production, and development environments are read from <code>env.yaml</code> in the project root.</p> + + + Methods of Running Tests + http://localhost:1313/main/running_tests/running/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/running_tests/running/ + <p>EEST has two commands, <code>consume</code> and <code>execute</code>, that run test cases against EL clients:</p> <ol> <li><code>consume</code> runs JSON test fixtures against a client - the client is said to &ldquo;consume&rdquo; the test case fixture.</li> <li><code>execute</code> runs test cases from Python source against a client - the test case is &ldquo;executed&rdquo; against the client.</li> </ol> <h2 id="top-level-comparison">Top-Level Comparison</h2> <p>Both <code>consume</code> and <code>execute</code> provide sub-commands which correspond to different methods of testing EL clients using EEST test cases:</p> + + + EEST Fixture Releases + http://localhost:1313/main/running_tests/releases/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/running_tests/releases/ + <h2 id="formats-and-release-layout">Formats and Release Layout</h2> <p>@ethereum/execution-spec-tests releases contain JSON test fixtures in various formats. Note that transaction type tests are executed directly from Python source using the <a href="./execute/main.md"><code>execute</code></a> command.</p> <table> <thead> <tr> <th>Format</th> <th>Consumed by the client</th> <th>Location in <code>.tar.gz</code> release</th> </tr> </thead> <tbody> <tr> <td><a href="./test_formats/state_test.md">State Tests</a></td> <td>- directly via a <code>statetest</code>-like command<br/> (e.g., <a href="https://github.com/ethereum/go-ethereum/blob/4bb097b7ffc32256791e55ff16ca50ef83c4609b/cmd/evm/staterunner.go" target="_blank" rel="noopener">go-ethereum/cmd/evm/staterunner.go</a>)</td> <td><code>./fixtures/state_tests/</code></td> </tr> <tr> <td><a href="./test_formats/blockchain_test.md">Blockchain Tests</a></td> <td>- directly via a <code>blocktest</code>-like command<br/> (e.g., <a href="https://github.com/ethereum/go-ethereum/blob/4bb097b7ffc32256791e55ff16ca50ef83c4609b/cmd/evm/blockrunner.go" target="_blank" rel="noopener">go-ethereum/cmd/evm/blockrunner.go</a>)</br>- using the <a href="./running.md#rlp">RLPeest/consume-rlp Simulator</a> via block import</td> <td><code>./fixtures/blockchain_tests/</code></td> </tr> <tr> <td><a href="./test_formats/blockchain_test_engine.md">Blockchain Engine Tests</a></td> <td>- using the <a href="./running.md#engine">eest/consume-engine Simulator</a> and the Engine API</td> <td><code>./fixtures/blockchain_tests_engine/</code></td> </tr> <tr> <td><a href="./test_formats/transaction_test.md">Transaction Tests</a></td> <td>- using a new simulator coming soon</td> <td>None; executed directly from Python source,</br>using a release tag</td> </tr> <tr> <td>Blob Transaction Tests</td> <td>- using the <a href="./execute/hive.md#the-eestexecute-blobs-simulator">eest/execute-blobs Simulator</a> and</td> <td>None; executed directly from Python source,</br>using a release tag</td> </tr> </tbody> </table> <h2 id="release-urls-and-tarballs">Release URLs and Tarballs</h2> <h3 id="versioning-scheme">Versioning Scheme</h3> <p>EEST framework and test sources and fixture releases are tagged use a semantic versioning scheme, <code>&lt;optional:&lt;pre_release_name@&gt;&gt;v&lt;MAJOR&gt;.&lt;MINOR&gt;.&lt;PATCH&gt;</code> as following:</p> + + + Installation Troubleshooting + http://localhost:1313/main/getting_started/installation_troubleshooting/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/getting_started/installation_troubleshooting/ + <p>This page provides guidance on how to troubleshoot common issues that may arise when installing <a href="https://github.com/ethereum/execution-spec-tests" target="_blank" rel="noopener">ethereum/execution-spec-tests</a>.</p> <h2 id="problem-failed-building-wheel-for-coincurve">Problem: <code>Failed building wheel for coincurve</code></h2> <div class="callout callout-danger"> <div class="callout-title">Problem: <code>Failed building wheel for coincurve</code></div> <div class="callout-content"> <p>Installing EEST and its dependencies via <code>uv sync --all-extras</code> fails with:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-bash" data-lang="bash"><span style="display:flex;"><span>Stored in directory: /tmp/... </span></span><span style="display:flex;"><span> Building wheel <span style="color:#66d9ef">for</span> coincurve <span style="color:#f92672">(</span>pyproject.toml<span style="color:#f92672">)</span> ... error </span></span><span style="display:flex;"><span> error: subprocess-exited-with-error </span></span><span style="display:flex;"><span> </span></span><span style="display:flex;"><span> Γ— Building wheel <span style="color:#66d9ef">for</span> coincurve <span style="color:#f92672">(</span>pyproject.toml<span style="color:#f92672">)</span> did not run successfully. </span></span><span style="display:flex;"><span> β”‚ exit code: <span style="color:#ae81ff">1</span> </span></span><span style="display:flex;"><span> ╰─&gt; <span style="color:#f92672">[</span><span style="color:#ae81ff">27</span> lines of output<span style="color:#f92672">]</span> </span></span><span style="display:flex;"><span> ... </span></span><span style="display:flex;"><span> <span style="color:#ae81ff">571</span> | <span style="color:#75715e">#include &lt;secp256k1_extrakeys.h&gt;</span> </span></span><span style="display:flex;"><span> | ^~~~~~~~~~~~~~~~~~~~~~~ </span></span><span style="display:flex;"><span> compilation terminated. </span></span><span style="display:flex;"><span> error: command <span style="color:#e6db74">&#39;/usr/bin/gcc&#39;</span> failed with exit code <span style="color:#ae81ff">1</span> </span></span><span style="display:flex;"><span> <span style="color:#f92672">[</span>end of output<span style="color:#f92672">]</span> </span></span><span style="display:flex;"><span> </span></span><span style="display:flex;"><span> note: This error originates from a subprocess, and is likely not a problem with pip. </span></span><span style="display:flex;"><span> ERROR: Failed building wheel <span style="color:#66d9ef">for</span> coincurve </span></span></code></pre></div> </div> </div> <div class="callout callout-success"> <div class="callout-title">Solution: Install the <code>libsecp256k1</code> library</div> <div class="callout-content"> <p>On Ubuntu, you can install this library with:</p> + + + Interactive Library Usage + http://localhost:1313/main/dev_docs/interactive_usage/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/dev_docs/interactive_usage/ + <p>You can work with EEST Python packages interactively with <code>ipython</code> using:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-console" data-lang="console"><span style="display:flex;"><span>uvx --with-editable . ipython </span></span></code></pre></div><p>This command will create a virtual environment, install EEST&rsquo;s packages in &ldquo;<a href="https://setuptools.pypa.io/en/latest/userguide/development_mode.html" target="_blank" rel="noopener">editable mode</a>&rdquo; (source changes get reflected in the interactive shell), and start an <code>ipython</code> shell. You can then import any of the packages and experiment with them interactively.</p> <div class="callout callout-info"> <div class="callout-title">Example: Working with <code>ethereum_test_forks</code></div> <div class="callout-content"> <p>See which defined forks are &ldquo;ignored&rdquo; by default:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-python" data-lang="python"><span style="display:flex;"><span><span style="color:#f92672">from</span> ethereum_test_forks <span style="color:#f92672">import</span> forks, get_forks </span></span><span style="display:flex;"><span>forks <span style="color:#f92672">=</span> set([fork <span style="color:#66d9ef">for</span> fork <span style="color:#f92672">in</span> get_forks() <span style="color:#66d9ef">if</span> fork<span style="color:#f92672">.</span>ignore()]) </span></span><span style="display:flex;"><span>print(forks) </span></span><span style="display:flex;"><span><span style="color:#75715e"># -&gt; {MuirGlacier, ArrowGlacier, GrayGlacier}</span> </span></span></code></pre></div> </div> </div> <h2 id="required-ipython-configuration">Required <code>ipython</code> Configuration</h2> <p>To enable <a href="https://ipython.readthedocs.io/en/stable/config/extensions/autoreload.html" target="_blank" rel="noopener">autoreload</a> of changed modules in the current <code>ipython</code> session, type:</p> + + + Types of Test + http://localhost:1313/main/writing_tests/types_of_tests/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/writing_tests/types_of_tests/ + <p>There are currently three types of tests that can be produced by a test spec:</p> <ol> <li>State Tests</li> <li>Blockchain Tests</li> <li>Transaction Tests</li> </ol> <h2 id="state-tests">State Tests</h2> <h3 id="purpose">Purpose</h3> <p>Tests the effects of individual transactions (ideally a single one) that span a single block in a controlled environment.</p> <h3 id="use-cases">Use cases</h3> <ul> <li>Test a single opcode behavior.</li> <li>Verify opcode gas costs.</li> <li>Test interactions between multiple smart contracts.</li> <li>Test creation of smart contracts.</li> </ul> <div class="callout callout-info"> <div class="callout-title">Info</div> <div class="callout-content"> The fill function will automatically generate a <code>blockchain_test</code> fixture from <code>state_tests</code>, consisting of one block and one transaction. </div> </div> <h2 id="blockchain-tests">Blockchain Tests</h2> <h3 id="purpose-1">Purpose</h3> <p>Blockchain tests span multiple blocks which may or may not contain transactions and mainly focus on the block to block effects to the Ethereum state.</p> + + + Documentation + http://localhost:1313/main/dev_docs/docs/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/dev_docs/docs/ + <p>The <code>execution-spec-tests</code> documentation is generated via <a href="https://github.com/gohugoio/hugo" target="_blank" rel="noopener"><code>hugo</code></a> and hosted remotely on Github Pages at <a href="https://eest.ethereum.org/" target="_blank" rel="noopener">eest.ethereum.org</a>.</p> <h2 id="prerequisites">Prerequisites</h2> <p>Grab the latest <code>hugo</code> binary from the official release page or build it yourself. Then make the binary executable and add it to the PATH (or to a directory that has already been added to the PATH like e.g. <code>/usr/local/bin/</code>). We do not require any additional plugins or dependencies.</p> <h2 id="build-and-locally-host-the-documentation">Build and Locally Host the Documentation</h2> <p>Build the docs:</p> + + + Useful Pytest Options + http://localhost:1313/main/running_tests/useful_pytest_options/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/running_tests/useful_pytest_options/ + <p>The EEST commands to run tests are customizations to the pytest framework, which provides many helpful options for test selection, parallel execution, report output and debugging. This section provides the most relevant options, a full overview is available in the <a href="https://docs.pytest.org/en/8.3.x/" target="_blank" rel="noopener">pytest docs</a>.</p> <h2 id="fixture-inputs-consume-commands">Fixture Inputs (Consume Commands)</h2> <p>See <a href="./consume/cache.md">Consume Cache and Fixture Inputs</a>.</p> <h2 id="dry-run">Dry-Run</h2> <p>List collected tests, <code>-q</code> restricts output to <a href="../filling_tests/test_ids.md">test IDs</a> only:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-bash" data-lang="bash"><span style="display:flex;"><span>uv run consume engine --input<span style="color:#f92672">=</span>&lt;fixture_input&gt; --collect-only -q </span></span></code></pre></div><p>In <code>./hive</code> <a href="./hive/main.md">standalone mode</a>, this can be achieved via EEST&rsquo;s <a href="./hive/common_options.md#collect-onlydry-run"><code>--sim.limit</code> &ldquo;collectonly&rdquo; prefix</a>.</p> + + + Writing a New Test + http://localhost:1313/main/writing_tests/writing_a_new_test/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/writing_tests/writing_a_new_test/ + <h2 id="test-functions">Test Functions</h2> <p>Every test case is defined as a Python function that implements a single <code>StateTest</code> or <code>BlockchainTest</code> using the <code>state_test</code> or <code>blockchain_test</code> objects made available by the framework (<a href="http://localhost:1313/main/writing_tests/types_of_tests/#deciding-on-a-test-type">learn how to decide on a test type</a>). Test cases, and the respective test modules, must fulfill the following requirements:</p> <table class="styled-table"> <thead> <tr> <th>Requirement</th> <th>When</th> </tr> </thead> <tbody> <tr> <td>Be <a href="#specifying-which-forks-tests-are-valid-for">decorated with validity markers</a></td> <td>If the test case is not valid for all forks</td> </tr> <tr> <td>Use one of <code>state_test</code> or <code>blockchain_test</code> <a href="#the-state_test-and-blockchain_test-test-function-arguments">in its function arguments</a></td> <td>Always</td> </tr> <tr> <td>Call the <code>state_test</code> or <code>blockchain_test</code> in its test body</td> <td>Always</td> </tr> <tr> <td>Add a <a href="http://localhost:1313/main/writing_tests/reference_specification/" target="_blank" rel="noopener">reference version of the EIP spec</a> under test</td> <td>Test path contains <code>eip</code></td> </tr> </tbody> </table> <style> .styled-table { border-collapse: collapse; width: 100%; margin: 1.5rem 0; border: 1px solid #ddd; } .styled-table th, .styled-table td { border: 1px solid #ddd; padding: 0.75rem; text-align: left; } .styled-table th { background-color: #f5f5f5; font-weight: 600; } .styled-table tr:nth-child(even) { background-color: #f9f9f9; } .styled-table code { background-color: #f4f4f4; padding: 0.2rem 0.4rem; border-radius: 3px; font-size: 0.9em; } </style> <h3 id="specifying-which-forks-tests-are-valid-for">Specifying which Forks Tests are Valid For</h3> <p>Test cases can (and it most cases should) be decorated with one or more &ldquo;validity markers&rdquo; that define which the forks the test is valid for. This is achieved by applying:</p> + + + Documenting CLI Commands + http://localhost:1313/main/dev_docs/documenting_clis/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/dev_docs/documenting_clis/ + <p>EEST command line interfaces (CLIs) are documented using the <a href="https://click.palletsprojects.com" target="_blank" rel="noopener"><code>click</code></a> library&rsquo;s built-in help system and the <a href="https://github.com/mkdocs/mkdocs-click" target="_blank" rel="noopener"><code>mkdocs-click</code></a> extension for mkdocs. This allows generation of CLI documentation directly from the (click) source code, ensuring that the documentation is always up-to-date with the code.</p> <p>Current limitations:</p> <ol> <li><code>mkdocs serve</code> does not automatically update the CLI documentation when the source code changes. You must restart the server to see the changes.</li> <li><code>mkdocs-click</code> does not automatically generate a short help string from sub-command docstrings. You must provide a short help string for each sub-command in the source code with <code>@click.command(short_help=&quot;...&quot;)</code>.</li> </ol> <p>See the <a href="https://github.com/ethereum/execution-spec-tests/blob/main/docs/library/cli/evm_bytes.md" target="_blank" rel="noopener">markdown</a> and corresponding <a href="https://github.com/ethereum/execution-spec-tests/blob/main/src/cli/evm_bytes.py" target="_blank" rel="noopener">Python docstrings</a> for the <a href="../library/cli/evm_bytes.md"><code>evm_bytes</code> CLI documentation</a> as an example of how to document a CLI using <code>mkdocs-click</code>.</p> + + + Test Markers + http://localhost:1313/main/writing_tests/test_markers/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/writing_tests/test_markers/ + <p>Test markers are used to categorize tests and to run specific subsets of tests. They are defined in the test files using the <code>pytest.mark</code> decorator.</p> <p>The examples below use <code>StateTestFiller</code> tests, but the same markers can also be applied to <code>BlockchainTestFiller</code> tests.</p> <h2 id="fork-markers">Fork Markers</h2> <p>These markers are used to specify the forks for which a test is valid.</p> <h3 id="pytestmarkvalid_fromfork_name"><code>@pytest.mark.valid_from(&quot;FORK_NAME&quot;)</code></h3> <p>Bases: <code>ValidityMarker</code></p> <p>Marker used to specify the fork from which the test is valid. The test will not be filled for forks before the specified fork.</p> + + + Code Standards + http://localhost:1313/main/getting_started/code_standards/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/getting_started/code_standards/ + <p>This document outlines the coding standards and practices used in the <a href="https://github.com/ethereum/execution-spec-tests/" target="_blank" rel="noopener">ethereum/execution-spec-tests</a> repository.</p> <h2 id="code-and-ci-requirements">Code and CI Requirements</h2> <p>Code pushed to execution-spec-tests must fulfill the following checks in <a href="https://github.com/ethereum/execution-spec-tests/actions/workflows/tox_verify.yaml" target="_blank" rel="noopener">CI</a>:</p> <table class="styled-table"> <thead> <tr> <th>Type</th> <th>Explanation</th> <th>Tox Command</th> </tr> </thead> <tbody> <tr> <td>Lint &amp; code formatting</td> <td><code>uvx --with=tox-uv tox -e lint</code></td> <td>Python lint, format and module import check via <code>ruff</code></td> </tr> <tr> <td>Typecheck</td> <td><code>uvx --with=tox-uv tox -e typecheck</code></td> <td>Objects that provide typehints pass type-checking via <code>mypy</code></td> </tr> <tr> <td>Framework unit tests</td> <td><code>uvx --with=tox-uv tox -e pytest</code></td> <td>All framework unit tests must execute correctly</td> </tr> <tr> <td>EL Client test cases</td> <td><code>uvx --with=tox-uv tox -e tests-deployed</code></td> <td>All client test cases for deployed forks can be generated</td> </tr> <tr> <td>Benchmark EL Test cases</td> <td><code>uvx --with=tox-uv tox -e tests-deployed-benchmark</code></td> <td>All client test cases specific to benchmarks for deployed forks can be generated</td> </tr> <tr> <td>HTML doc build</td> <td><code>uvx --with=tox-uv tox -e hugo</code></td> <td>Documentation generated without warnings</td> </tr> <tr> <td>Spellcheck</td> <td><code>uvx --with=tox-uv tox -e spellcheck</code></td> <td>Code and documentation spell-check using codespell</td> </tr> <tr> <td>Markdown lint</td> <td><code>uvx --with=tox-uv tox -e markdownlint</code></td> <td>Markdown lint (requires <a href="http://localhost:1313/main/getting_started/code_standards_details/#additional-dependencies" target="_blank" rel="noopener">additional dependency</a>)</td> </tr> <tr> <td>Changelog validation</td> <td><code>uvx --with=tox-uv tox -e changelog</code></td> <td>Validates changelog entries format and structure in <code>docs/CHANGELOG.md</code></td> </tr> </tbody> </table> <style> .styled-table { border-collapse: collapse; width: 100%; margin: 1.5rem 0; border: 1px solid #ddd; } .styled-table th, .styled-table td { border: 1px solid #ddd; padding: 0.75rem; text-align: left; } .styled-table th { background-color: #f5f5f5; font-weight: 600; } .styled-table tr:nth-child(even) { background-color: #f9f9f9; } .styled-table code { background-color: #f4f4f4; padding: 0.2rem 0.4rem; border-radius: 3px; font-size: 0.9em; } </style> <div class="callout callout-warning"> <div class="callout-title">Avoid CI surprises - Use pre-commit hooks!</div> <div class="callout-content"> <p><strong>We strongly encourage all contributors to install and use pre-commit hooks!</strong> This will run fast checks (lint, typecheck, spellcheck) automatically before each commit, helping you catch issues early and avoid frustrating CI failures after pushing your changes.</p> + + + Coding Style + http://localhost:1313/main/dev_docs/coding_style/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/dev_docs/coding_style/ + <div class="callout callout-warning"> <div class="callout-title">Documentation Moved</div> <div class="callout-content"> This documentation has been relocated to <a href="../getting_started/code_standards.md">Getting Started -&gt; Code Standards</a>. Please use the new location for the most up-to-date information. </div> </div> + + + Verifying Changes + http://localhost:1313/main/writing_tests/verifying_changes/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/writing_tests/verifying_changes/ + <div class="callout callout-warning"> <div class="callout-title">Documentation Moved</div> <div class="callout-content"> This documentation has been relocated to <a href="../getting_started/code_standards_details.md">Detailed Code Standards</a>. Please use the new location for the most up-to-date information. </div> </div> + + + Code Standards + http://localhost:1313/main/writing_tests/code_standards/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/writing_tests/code_standards/ + <h1 id="code-standards"><a href="#code-standards">Code Standards</a></h1> <p>This documentation has been relocated.</p> + + + Detailed Code Standards + http://localhost:1313/main/getting_started/code_standards_details/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/getting_started/code_standards_details/ + <p>This page provides in-depth information about the code standards and verification processes in <a href="https://github.com/ethereum/execution-spec-tests/" target="_blank" rel="noopener">ethereum/execution-spec-tests</a>.</p> <h2 id="running-tox-environments">Running Tox Environments</h2> <h3 id="execution-options">Execution Options</h3> <p>Run all <code>tox</code> environments in parallel:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-console" data-lang="console"><span style="display:flex;"><span>uvx --with=tox-uv tox run-parallel </span></span></code></pre></div><p>Run environments sequentially with verbose output:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-console" data-lang="console"><span style="display:flex;"><span>uvx --with=tox-uv tox -v </span></span></code></pre></div><p>List all available environments:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-console" data-lang="console"><span style="display:flex;"><span>uvx --with=tox-uv tox -av </span></span></code></pre></div><h3 id="specific-environment-commands">Specific Environment Commands</h3> <p>Run specific environments using the <code>-e</code> flag:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-console" data-lang="console"><span style="display:flex;"><span>uvx --with=tox-uv tox -e lint,typecheck,spellcheck </span></span></code></pre></div><h4 id="for-test-case-changes-tests">For Test Case Changes (<code>./tests/</code>)</h4> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-console" data-lang="console"><span style="display:flex;"><span>uvx --with=tox-uv tox -e lint,typecheck,spellcheck,tests-deployed </span></span></code></pre></div><h4 id="for-framework-and-library-changes-src">For Framework and Library Changes (<code>./src/</code>)</h4> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-console" data-lang="console"><span style="display:flex;"><span>uvx --with=tox-uv tox -e lint,typecheck,spellcheck,pytest </span></span></code></pre></div><h4 id="for-documentation-changes-docs">For Documentation Changes (<code>./docs/</code>)</h4> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-console" data-lang="console"><span style="display:flex;"><span>uvx --with=tox-uv tox -e spellcheck,markdownlint,mkdocs,changelog </span></span></code></pre></div> <div class="callout callout-info"> <div class="callout-title">Tox Virtual Environment</div> <div class="callout-content"> Checks performed by <code>tox</code> are sandboxed in their own virtual environments (created automatically in the <code>.tox/</code> subdirectory). These can be used to debug errors encountered during <code>tox</code> execution. </div> </div> <h3 id="additional-dependencies">Additional Dependencies</h3> <p>Some checks require external (non-Python) packages:</p> + + + Logging + http://localhost:1313/main/dev_docs/logging/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/dev_docs/logging/ + <p>This document describes the logging system used in the Ethereum Execution Spec Tests project. Currently, logging is only supported for <code>consume</code> commands.</p> <h2 id="overview">Overview</h2> <p>The project uses Python&rsquo;s standard logging module with custom extensions to provide enhanced logging capabilities. Our logging system is implemented in the <code>src/pytest_plugins/logging.py</code> module and provides the following features:</p> <ul> <li>Custom log levels between the standard Python log levels</li> <li>Timestamps with millisecond precision in UTC</li> <li>Color-coded log output (when not running in Docker)</li> <li>File logging with a consistent naming pattern</li> <li>Integration with pytest&rsquo;s output capture</li> <li>Support for distributed test execution with pytest-xdist</li> </ul> <h2 id="custom-log-levels">Custom Log Levels</h2> <p>In addition to the standard Python log levels (DEBUG, INFO, WARNING, ERROR, CRITICAL), we&rsquo;ve added the following custom levels:</p> + + + Enabling Pre-Commit Checks + http://localhost:1313/main/dev_docs/precommit/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/dev_docs/precommit/ + <p>There&rsquo;s a <a href="https://pre-commit.com/" target="_blank" rel="noopener">pre-commit</a> config file available in the repository root (<code>.pre-commit-config.yaml</code>) that can be used to enable automatic checks upon commit - the commit will not go through if the checks don&rsquo;t pass.</p> <p>To enable pre-commit, the following must be run once:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-console" data-lang="console"><span style="display:flex;"><span>uvx pre-commit install </span></span></code></pre></div> <div class="callout callout-info"> <div class="callout-title">Bypassing pre-commit checks</div> <div class="callout-content"> <p>Enabling of pre-commit checks is not mandatory (it cannot be enforced) and even if it is enabled, it can always be bypassed with:</p> + + + Exception Tests + http://localhost:1313/main/writing_tests/exception_tests/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/writing_tests/exception_tests/ + <p>Exception tests are a special type of test which verify that an invalid transaction or an invalid block are correctly rejected with the expected error.</p> <h2 id="creating-an-exception-test">Creating an Exception Test</h2> <p>To test for an exception, the test can use either of the following types from <code>ethereum_test_exceptions</code> library:</p> <ol> <li> <p><a href="../library/ethereum_test_exceptions.md#ethereum_test_exceptions.TransactionException"><code>TransactionException</code></a>: To be added to the <code>error</code> field of the <code>Transaction</code> object, and to the <code>exception</code> field of the <code>Block</code> object that includes the transaction; this exception type is used when a transaction is invalid, and therefore when included in a block, the block is expected to be invalid too. This is different from valid transactions where an exception during EVM execution is expected (e.g. a revert, or out-of-gas), which can be included in valid blocks.</p> + + + VS Code Setup + http://localhost:1313/main/getting_started/setup_vs_code/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/getting_started/setup_vs_code/ + <p>VS Code setup is optional, but does offer the following advantages:</p> <ul> <li>Auto-format your Python code to conform to the repository&rsquo;s <a href="http://localhost:1313/main/writing_tests/code_standards/">code standards</a> (we use <a href="https://docs.astral.sh/ruff/" target="_blank" rel="noopener">ruff</a>).</li> <li>Inline linting and auto-completion (thanks to Python type hints).</li> <li>Spell-check your code and docs.</li> <li>Graphical exploration of test cases and easy test execution/debug.</li> </ul> <h2 id="installation">Installation</h2> <p>Please refer to the <a href="https://code.visualstudio.com/docs/setup/setup-overview" target="_blank" rel="noopener">Visual Studio Code docs</a> for help with installation.</p> <h2 id="vs-code-settings-file">VS Code Settings file</h2> <p>The <a href="https://github.com/ethereum/execution-spec-tests" target="_blank" rel="noopener">ethereum/execution-spec-tests</a> repo includes configuration files for VS Code in the <code>.vscode/</code> sub-directory:</p> + + + Repository Overview + http://localhost:1313/main/getting_started/repository_overview/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/getting_started/repository_overview/ + <p>The most relevant folders and files in the repo are:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-text" data-lang="text"><span style="display:flex;"><span>πŸ“ execution-test-specs/ </span></span><span style="display:flex;"><span>β”œβ”€β•΄πŸ“ tests/ # test cases </span></span><span style="display:flex;"><span>β”‚ β”œβ”€β”€ πŸ“ eips/ </span></span><span style="display:flex;"><span>β”‚ β”œβ”€β”€ πŸ“ vm/ </span></span><span style="display:flex;"><span>β”‚ └── πŸ“ ... </span></span><span style="display:flex;"><span>β”œβ”€β•΄πŸ“ fixtures/ # default fixture output dir </span></span><span style="display:flex;"><span>β”‚ β”œβ”€β”€ πŸ“ blockchain_tests/ </span></span><span style="display:flex;"><span>β”‚ β”œβ”€β”€ πŸ“ blockchain_tests_engine/ </span></span><span style="display:flex;"><span>β”‚ β”œβ”€β”€ πŸ“ state_tests/ </span></span><span style="display:flex;"><span>β”‚ └── πŸ“ ... </span></span><span style="display:flex;"><span>β”œβ”€β•΄πŸ“ src/ # library &amp; framework packages </span></span><span style="display:flex;"><span>β”‚ β”œβ”€β”€ πŸ“ ethereum_test_fork/ </span></span><span style="display:flex;"><span>β”‚ β”œβ”€β”€ πŸ“ ethereum_test_tools/ </span></span><span style="display:flex;"><span>β”‚ └── πŸ“ ... </span></span><span style="display:flex;"><span>β”œβ”€β•΄πŸ“ docs/ # markdown documentation </span></span><span style="display:flex;"><span>β”‚ β”œβ”€β”€ πŸ“ getting_started </span></span><span style="display:flex;"><span>β”‚ β”œβ”€β”€ πŸ“ dev </span></span><span style="display:flex;"><span>β”‚ └── πŸ“ ... </span></span><span style="display:flex;"><span>β”œβ”€β•΄πŸ“ .vscode/ # visual studio code config </span></span><span style="display:flex;"><span>β”‚ β”œβ”€β”€ πŸ“„ settings.recommended.json # copy to settings.json </span></span><span style="display:flex;"><span>β”‚ β”œβ”€β”€ πŸ“„ launch.recommended.json </span></span><span style="display:flex;"><span>β”‚ └── πŸ“„ extensions.json </span></span><span style="display:flex;"><span>└── πŸ“„ whitelist.txt # spellcheck dictionary </span></span></code></pre></div><h4 id="tests"><code>tests/</code></h4> <p>Contains the implementation of the Ethereum consensus tests available in this repository.</p> + + + Running Github Actions Locally + http://localhost:1313/main/dev_docs/test_actions_locally/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/dev_docs/test_actions_locally/ + <p>The Github Actions workflows can be tested locally using <a href="https://github.com/nektos/act" target="_blank" rel="noopener">nektos/act</a> without pushing changes to the remote. The local repository state will be used in the executed workflow.</p> <h2 id="prerequisites">Prerequisites</h2> <ol> <li> <p>A docker installation without <code>sudo</code> prefix requirement (<a href="https://docs.docker.com/engine/install/linux-postinstall/#manage-docker-as-a-non-root-user" target="_blank" rel="noopener">see also dockerdocs</a>):</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-bash" data-lang="bash"><span style="display:flex;"><span>sudo usermod -aG docker $USER </span></span></code></pre></div></li> <li> <p>Install the Github CLI (<code>gh</code>): <a href="https://github.com/cli/cli/blob/trunk/docs/install_linux.md" target="_blank" rel="noopener">linux</a>, <a href="https://github.com/cli/cli/tree/trunk?tab=readme-ov-file#macos" target="_blank" rel="noopener">macos</a>.</p> </li> <li> <p>Authenticate your Github account with the Github CLI:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-bash" data-lang="bash"><span style="display:flex;"><span>gh auth login </span></span></code></pre></div><p>This is required to set <code>GITHUB_TOKEN</code> to the output of <code>gh auth token</code> when running the workflows.</p> + + + Using and Extending Fork Methods + http://localhost:1313/main/writing_tests/fork_methods/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/writing_tests/fork_methods/ + <p>This document describes the Fork class in the Ethereum execution spec tests framework, which provides a standardized way to define properties of Ethereum forks. Understanding how to use and extend these fork methods is essential for writing flexible tests that can automatically adapt to different forks.</p> <h2 id="overview">Overview</h2> <p>The <code>BaseFork</code> class is an abstract base class that defines the interface for all Ethereum forks. Each implemented fork (like Frontier, Homestead, etc.) extends this class and implements its abstract methods to provide fork-specific behavior.</p> + + + Dependency Management and Packaging + http://localhost:1313/main/dev_docs/deps_and_packaging/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/dev_docs/deps_and_packaging/ + <p>EEST uses <a href="https://docs.astral.sh/uv/" target="_blank" rel="noopener"><code>uv</code></a> to manage and pin its dependencies.</p> <p>Please use <code>uv&gt;=0.7.0</code> to ensure <code>uv</code> writes <code>uv.lock</code> files with consistent fields and formatting (see <a href="https://github.com/ethereum/execution-spec-tests/pull/1597" target="_blank" rel="noopener">ethereum/execution-spec-tests#1597</a>).</p> <h2 id="managing-dependencies">Managing Dependencies</h2> <p>We aim to provide specific <a href="https://peps.python.org/pep-0440/#version-specifiers" target="_blank" rel="noopener">version specifiers</a> for each of our direct and extra dependencies.</p> <div class="callout callout-info"> <div class="callout-title">Packages should be managed via <code>uv</code></div> <div class="callout-content"> <p>Dependencies should be managed using <code>uv</code> on the command-line to ensure that version compatibility is ensured across all dependencies and that <code>uv.lock</code> is updated as required.</p> + + + Getting Help + http://localhost:1313/main/getting_started/getting_help/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/getting_started/getting_help/ + <p>The tests in this repository are a community effort to help improve the development cycle of all Ethereum execution clients.</p> <p>We encourage contributions and recognize that Python is not everyone&rsquo;s primary language - if you stumble over issues or need help, please reach out to one of the execution-spec-tests maintainers either directly or in the <code>#el-testing</code> channel in the <a href="https://discord.com/invite/qGpsxSA" target="_blank" rel="noopener">Ethereum R&amp;D Discord Server</a>.</p> <h2 id="contact-the-maintainers">Contact the Maintainers</h2> <p>Write to:</p> <ul> <li>Dan on <a href="https://discordapp.com/users/danceratopz" target="_blank" rel="noopener">Discord</a> or <a href="https://t.me/danceratopz" target="_blank" rel="noopener">Telegram</a>.</li> <li>Spencer on <a href="https://discordapp.com/users/spencertaylorbrown" target="_blank" rel="noopener">Discord</a> or <a href="https://t.me/spencertb" target="_blank" rel="noopener">Telegram</a>.</li> <li>Mario on <a href="https://discordapp.com/users/marioevz" target="_blank" rel="noopener">Discord</a> or <a href="https://t.me/marioevz" target="_blank" rel="noopener">Telegram</a>.</li> <li>Felix on <a href="https://discordapp.com/users/felix314159_" target="_blank" rel="noopener">Discord</a> or <a href="https://t.me/felix_eest" target="_blank" rel="noopener">Telegram</a>.</li> </ul> <p><img src="http://localhost:1313/images/getting_started/testing_pandas.png" alt="ukiyo-e style design of 3 furry happy pandas playfully doing experiments on ethereum in a laboratory"></p> + + + Referencing an EIP Spec Version + http://localhost:1313/main/writing_tests/reference_specification/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/writing_tests/reference_specification/ + <p>Tests that implement features from an Ethereum Improvement Proposal (<a href="https://github.com/ethereum/EIPs/tree/master/EIPS" target="_blank" rel="noopener">ethereum/EIPs</a>) must define the EIP&rsquo;s markdown SHA digest within the test&rsquo;s Python module. This ensures our tests stay up-to-date with any changes to the EIP specifications.</p> <p>The <code>check_eip_versions</code> command-line utility automatically verifies that all EIP references in the codebase are current. It works by comparing the SHA specified in the test against the latest version in the ethereum/EIPs repository. This utility uses pytest to generate test cases for every module that includes &ldquo;eip&rdquo; in its path.</p> + + + EIP Checklist Generation + http://localhost:1313/main/writing_tests/eip_checklist/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/writing_tests/eip_checklist/ + <p>The EIP checklist feature helps track test coverage for EIP implementations by automatically generating filled checklists based on test markers.</p> <h2 id="overview">Overview</h2> <p>When implementing tests for an EIP, you can mark specific tests as covering checklist items from the <a href="../writing_tests/checklist_templates/eip_testing_checklist_template.md">EIP testing checklist template</a>. The framework will then generate a filled checklist showing which items have been implemented.</p> <h2 id="marking-tests-as-implementing-eip-checklist-items">Marking Tests as implementing EIP Checklist Items</h2> <p>To mark a test as implementing a specific checklist item, use the structured <code>EIPChecklist</code> class:</p> + + + Post-Mortems + http://localhost:1313/main/writing_tests/post_mortems/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/writing_tests/post_mortems/ + <p>This page contains a collection of post-mortem analyses for test cases that were not initially identified by the testing process.</p> <p>The objective is to document and learn from missed scenarios β€” including those that were caught on the client side due to consensus issue, client developer raised issues, external reviewers, or external bug bounties β€” in order to improve test coverage and reduce the likelihood of similar omissions in the future.</p> + + + Porting Legacy Tests + http://localhost:1313/main/writing_tests/porting_legacy_tests/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/writing_tests/porting_legacy_tests/ + <h2 id="background">Background</h2> <p>EEST is the successor to <a href="https://github.com/ethereum/tests" target="_blank" rel="noopener">ethereum/tests</a> (aka &ldquo;original tests&rdquo;), a repository that defined EVM test cases from the <a href="https://ethereum.org/en/history/#frontier" target="_blank" rel="noopener">Frontier</a> phase up to and including <a href="https://ethereum.org/en/history/#paris" target="_blank" rel="noopener">The Merge</a>. These test cases are specified as YAML (and occasionally JSON) files in the <a href="https://github.com/ethereum/tests/tree/develop/src" target="_blank" rel="noopener"><code>./src/</code></a> sub-directory. JSON test fixtures, which are fully-populated tests that can be executed against clients, are generated using <a href="https://github.com/ethereum/retesteth" target="_blank" rel="noopener">ethereum/retesteth</a>. These JSON artifacts are regenerated when needed and added to the repository, typically in the <a href="https://github.com/ethereum/execution-spec-tests/tree/main/tests/static/state_tests" target="_blank" rel="noopener"><code>tests/static/state_tests</code></a> sub-directory.</p> + + + Changelog + http://localhost:1313/main/changelog/ + Wed, 09 Jul 2025 12:42:33 +0000 + http://localhost:1313/main/changelog/ + <p>Test fixtures for use by clients are available for each release on the <a href="https://github.com/ethereum/execution-spec-tests/releases" target="_blank" rel="noopener">Github releases page</a>.</p> <p><strong>Key:</strong> ✨ = New, 🐞 = Fixed, πŸ”€ = Changed. πŸ’₯ = Breaking</p> <h2 id="-unreleased">πŸ”œ [Unreleased]</h2> <h3 id="-breaking-changes">πŸ’₯ Breaking Changes</h3> <ul> <li>Python 3.10 support was removed in this release (<a href="https://github.com/ethereum/execution-spec-tests/pull/1808" target="_blank" rel="noopener">#1808</a>).</li> </ul> <h4 id="-important-change-for-test-contributors">πŸ’₯ Important Change for test contributors</h4> <ul> <li>EEST no longer allows usage of Yul code in Python tests. From now on, please make use of our opcode wrapper. Yul code is now only allowed in the &ldquo;static tests&rdquo; located in <code>./tests/static/</code> (these are test cases defined by JSON and YAML files instead of Python test functions that were originally maintained in <a href="https://github.com/ethereum/tests" target="_blank" rel="noopener">ethereum/tests</a>).</li> <li>In order to fill the static tests (which is not the case by default), please ensure that <code>solc</code> is located in your <code>PATH</code>.</li> </ul> <h4 id="-important-change-for-fill-users">πŸ’₯ Important Change for <code>fill</code> Users</h4> <p>The output behavior of <code>fill</code> has changed (<a href="https://github.com/ethereum/execution-spec-tests/pull/1608" target="_blank" rel="noopener">#1608</a>):</p> + + + Checklist Templates + http://localhost:1313/main/writing_tests/checklist_templates/main/ + Wed, 09 Jul 2025 12:42:33 +0000 + http://localhost:1313/main/writing_tests/checklist_templates/main/ + <h1 id="testing-checklist-templates">Testing Checklist Templates</h1> <p>This page includes checklist templates that must be followed to guarantee a minimum base testing coverage of new EIP feature.</p> + + + Consume + http://localhost:1313/main/running_tests/consume/main/ + Wed, 09 Jul 2025 12:42:33 +0000 + http://localhost:1313/main/running_tests/consume/main/ + <h1 id="the-consume-command">The <code>consume</code> Command</h1> <p>The EEST <code>consume</code> command implements different methods to run EEST-generated test fixtures against clients:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-bash" data-lang="bash"><span style="display:flex;"><span>uv run consume <span style="color:#f92672">[</span>OPTIONS<span style="color:#f92672">]</span> SUBCOMMAND <span style="color:#f92672">[</span>ARGS<span style="color:#f92672">]</span>... </span></span></code></pre></div><p>For help with installation, see <a href="../../getting_started/main.md">Installation</a>.</p> <p>This section provides help for running the EEST commands directly (as opposed to running as a <code>./hive</code> <a href="../hive/main.md">standalone command</a>, where applicable) see:</p> <ol> <li> <p><a href="./cache.md">Consume Cache &amp; Fixture Inputs</a> for how to specify <code>consume</code> fixture input.</p> </li> <li> <p><a href="./direct.md">Consume Direct</a> to run test fixtures against direct client interfaces.</p> </li> <li> <p><a href="./simulators.md">Consume Simulators</a> for help with Hive Simulators.</p> + + + Developer Documentation + http://localhost:1313/main/dev_docs/main/ + Wed, 09 Jul 2025 12:42:33 +0000 + http://localhost:1313/main/dev_docs/main/ + <p>This documentation is aimed at <code>execution-spec-tests</code> developers:</p> <ul> <li><a href="./configurations.md">Managing configurations</a>: Instructions for setting up and modifying test configurations.</li> <li><a href="./interactive_usage.md">Interactive usage</a>: Guide on interactive use of EEST packages using <code>ipython</code>.</li> <li><a href="./documenting_clis.md">Documenting CLI commands</a>: Instructions for documenting command line interfaces (CLIs).</li> <li><a href="./coding_style.md">Coding style</a>: Standards and best practices for code formatting and to maintain consistency across the repository.</li> <li><a href="./logging.md">Logging</a>: Documentation on using the custom logging system with enhanced features.</li> <li><a href="./precommit.md">Enabling pre-commit checks</a>: A guide for setting up pre-commit hooks to enforce code quality before commits.</li> <li><a href="./test_actions_locally.md">Running github actions locally</a>: Instructions for testing GitHub Actions workflows on your local machine to streamline development and debugging.</li> </ul> <p>These sections are primarily aimed at <code>execution-spec-tests</code> maintainers:</p> + + + Execute + http://localhost:1313/main/running_tests/execute/main/ + Wed, 09 Jul 2025 12:42:33 +0000 + http://localhost:1313/main/running_tests/execute/main/ + <h1 id="executing-tests-on-local-networks-or-hive">Executing Tests on Local Networks or Hive</h1> <p>@ethereum/execution-spec-tests is capable of running tests on local networks or on Hive with a few considerations. The <code>execute</code> command runs test cases directly from the Python source (without the use of JSON fixtures).</p> <p>See:</p> <ul> <li><a href="./hive.md">Execute Hive</a> for help with the <code>execute</code> simulator in order to run tests on a single-client local network.</li> <li><a href="./remote.md">Execute Remote</a> for help with executing tests on a remote network such as a devnet, or even mainnet.</li> </ul> <p>The rest of this page describes how <code>execute</code> works and explains its architecture.</p> + + + Execution Spec Tests + http://localhost:1313/main/main/ + Wed, 09 Jul 2025 12:42:33 +0000 + http://localhost:1313/main/main/ + <p><img src="http://localhost:1313/images/main/execution_spec_tests.jpg" alt="Execution Spec Tests Logo"></p> <p><a href="https://github.com/ethereum/execution-spec-tests/" target="_blank" rel="noopener">ethereum/execution-spec-tests</a> is both a collection of test cases and a framework in Python to generate tests for Ethereum execution clients.</p> <p>The framework collects and executes the test cases in order to generate <em>test fixtures</em> (JSON) which can be consumed by any execution client to verify their implementation of <a href="https://github.com/ethereum/execution-specs" target="_blank" rel="noopener">ethereum/execution-specs</a>. The fixtures, which define state transition and block tests, are generated by the framework using one of the <code>t8n</code> command-line tools that are provided by most execution clients, see below for an overview of the supported <code>t8n</code> tools.</p> + + + Filling Tests + http://localhost:1313/main/filling_tests/main/ + Wed, 09 Jul 2025 12:42:33 +0000 + http://localhost:1313/main/filling_tests/main/ + <p>Execution of test cases against clients is a two-step process:</p> <ol> <li>JSON test fixtures are generated from the Python test cases found in <code>./tests</code> using <code>fill</code> and an EVM transition tool (<code>t8n</code>) implementation.</li> <li>Clients &ldquo;consume&rdquo; the JSON fixtures via either a dedicated, client-specific interface or a testing environment such as Hive.</li> </ol> <p>The process of generating fixtures is often referred to as &ldquo;filling&rdquo; the tests.</p> <div class="callout callout-info"> <div class="callout-title">The <code>execute</code> command</div> <div class="callout-content"> The <code>execute</code> command directly executes Python test cases against a client via its RPC without using generated JSON fixtures. For all other methods of testing clients, the JSON fixtures are required. For more information, see <a href="../running_tests/execute/main.md">Executing Tests</a>. </div> </div> <h2 id="transition-tools-t8n">Transition Tools (<code>t8n</code>)</h2> <p>The <code>fill</code> command requires an EVM <code>t8n</code> tool provided by most clients in order to generate the JSON fixtures. The <code>t8n</code> tool is mainly responsible for calculating the post-state of the EVM after executing a transaction, most relevantly, it calculates the updated state root.</p> + + + Hive + http://localhost:1313/main/running_tests/hive/main/ + Wed, 09 Jul 2025 12:42:33 +0000 + http://localhost:1313/main/running_tests/hive/main/ + <h1 id="hive">Hive</h1> <p>@ethereum/hive is a containerized testing framework that helps orchestrate test execution against Ethereum clients. Hive is incredibly extensible; new test suites can be implemented in a module manner as &ldquo;simulators&rdquo; that interact with clients to test certain aspects of their behavior. EEST implements several simulators, see <a href="../running.md">Running Tests</a> for an overview.</p> <h2 id="quick-start">Quick Start</h2> <h3 id="prerequisites">Prerequisites</h3> <ol> <li>Docker: <a href="https://docs.docker.com/get-docker/" target="_blank" rel="noopener">https://docs.docker.com/get-docker/</a>.</li> <li>Golang 1.22+: <a href="https://go.dev/doc/install" target="_blank" rel="noopener">https://go.dev/doc/install</a>.</li> </ol> <h3 id="installation">Installation</h3> <p>Clone @ethereum/hive and build the <code>./hive</code> command:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-bash" data-lang="bash"><span style="display:flex;"><span>git clone https://github.com/ethereum/hive </span></span><span style="display:flex;"><span>cd hive </span></span><span style="display:flex;"><span>go build . </span></span></code></pre></div> + + + Installation + http://localhost:1313/main/getting_started/main/ + Wed, 09 Jul 2025 12:42:33 +0000 + http://localhost:1313/main/getting_started/main/ + <h1 id="installation">Installation</h1> <h2 id="prerequisites">Prerequisites</h2> <p>The tools provided by <a href="https://github.com/ethereum/execution-spec-tests" target="_blank" rel="noopener">execution-spec-tests</a> use <a href="https://docs.astral.sh/uv/" target="_blank" rel="noopener"><code>uv</code></a> to manage their dependencies and virtual environment.<br><br></p> <p>It&rsquo;s typically recommended to use the latest version of <code>uv</code>, currently <code>uv&gt;=0.5.22</code> is required.<br><br></p> <p>The latest version of <code>uv</code> can be installed via <code>curl</code> (recommended; can self-update via <code>uv self update</code>) or pip (requires Python, can&rsquo;t self-update):</p> <div class="tab-container" data-tab-group="tabs-0"> <div class="tab-header"> <button class="tab-button active" onclick="switchTab('tabs-0', 0 )"> curl </button> <button class="tab-button " onclick="switchTab('tabs-0', 1 )"> pip </button> </div> <div class="tab-panels"> <div class="tab-panel active"> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-console" data-lang="console"><span style="display:flex;"><span>curl -LsSf https://astral.sh/uv/install.sh | sh </span></span></code></pre></div> </div> <div class="tab-panel "> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-console" data-lang="console"><span style="display:flex;"><span>pip install uv </span></span></code></pre></div> </div> </div> </div> <style> .tab-container { margin: 1.5rem 0; background: #f8f9fa; border-radius: 8px; overflow: hidden; box-shadow: 0 1px 3px rgba(0,0,0,0.1); } .tab-header { display: flex; background: #e9ecef; } .tab-button { flex: 1; padding: 0.75rem 1rem; border: none; background: transparent; cursor: pointer; font-size: 14px; white-space: nowrap; transition: all 0.2s; position: relative; text-align: center; overflow: hidden; text-overflow: ellipsis; } .tab-button:hover { background: rgba(0,0,0,0.05); } .tab-button.active { background: #f8f9fa; font-weight: 600; color: #007bff; } .tab-button.active::after { content: ''; position: absolute; bottom: 0; left: 0; right: 0; height: 3px; background: #007bff; } .tab-button code { background: rgba(0,0,0,0.1); padding: 2px 4px; border-radius: 3px; font-size: 12px; } .tab-panel { display: none; padding: 1.5rem; background: white; } .tab-panel.active { display: block; } .tab-panel pre { margin: 0; background: #f6f8fa; border: 1px solid #e1e4e8; } @media (max-width: 768px) { .tab-header { flex-wrap: wrap; } .tab-button { flex: 1 1 50%; padding: 0.5rem 0.75rem; font-size: 13px; } @media (max-width: 480px) { .tab-button { flex: 1 1 100%; } } } </style> <script> function switchTab(groupId, tabIndex) { const container = document.querySelector(`[data-tab-group="${groupId}"]`); container.querySelectorAll('.tab-button').forEach((btn, idx) => { btn.classList.toggle('active', idx === tabIndex); }); container.querySelectorAll('.tab-panel').forEach((panel, idx) => { panel.classList.toggle('active', idx === tabIndex); }); } </script> <p>If installed via <code>curl</code>, <code>uv</code> will download Python for your target platform if one of the required versions (Python 3.11 or 3.12) is not available natively.</p> + + + Running Tests + http://localhost:1313/main/running_tests/main/ + Wed, 09 Jul 2025 12:42:33 +0000 + http://localhost:1313/main/running_tests/main/ + <p>This section documents how EL clients can run EEST tests to verify their implementations. The information is organized as follows:</p> <ol> <li> <p><strong><a href="http://localhost:1313/main/running_tests/running/">Methods of Running Tests</a>:</strong> A detailed overview and comparison.</p> </li> <li> <p><strong><a href="http://localhost:1313/main/running_tests/releases/">EEST Fixture Releases</a>:</strong> The available release types; release versioning.</p> </li> <li> <p><strong><a href="http://localhost:1313/main/running_tests/test_formats/main/">Test Fixture Specifications</a></strong> and guides to implement direct consumer interfaces.</p> </li> <li> <p><strong><a href="http://localhost:1313/main/running_tests/hive/main/">Hive</a>:</strong> Help running EEST Hive simulators.</p> </li> <li> <p><strong><a href="http://localhost:1313/main/running_tests/consume/main/">Consume</a>:</strong> Commands that help clients run tests by consuming test fixtures.</p> </li> <li> <p><strong><a href="http://localhost:1313/main/running_tests/execute/main/">Execute</a>:</strong> Commands that help clients run tests by executing test source.</p> + + + Test Formats + http://localhost:1313/main/running_tests/test_formats/main/ + Wed, 09 Jul 2025 12:42:33 +0000 + http://localhost:1313/main/running_tests/test_formats/main/ + <h1 id="test-fixture-specifications">Test Fixture Specifications</h1> <p>The following sub-sections provide:</p> <ul> <li>Specifications for each test fixture format with an explanation of each field and its type.</li> <li>Guides on how to consume each format.</li> </ul> + + + Tutorials + http://localhost:1313/main/writing_tests/tutorials/main/ + Wed, 09 Jul 2025 12:42:33 +0000 + http://localhost:1313/main/writing_tests/tutorials/main/ + <h1 id="tutorials">Tutorials</h1> <p>Show overview of existing tutorials</p> + + + Writing Tests + http://localhost:1313/main/writing_tests/main/ + Wed, 09 Jul 2025 12:42:33 +0000 + http://localhost:1313/main/writing_tests/main/ + <p>The easiest way to get started is to use the interactive CLI:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-console" data-lang="console"><span style="display:flex;"><span>uv run eest make test </span></span></code></pre></div><p>and modify the generated test module to suit your needs.</p> <p><img src="http://localhost:1313/images/writing_tests/eest_make_test.gif" alt="Gif that shows how to create a test in EEST"></p> <p>For help deciding which test format to select, see <a href="http://localhost:1313/main/writing_tests/types_of_tests/">Types of Tests</a>, in particular <a href="http://localhost:1313/main/writing_tests/types_of_tests/#deciding-on-a-test-type">Deciding on a Test Type</a>.</p> <h2 id="key-resources">Key Resources</h2> <ul> <li><a href="http://localhost:1313/main/writing_tests/code_standards/#code-standards">Coding Standards</a> - Code style and standards for this repository</li> <li><a href="http://localhost:1313/main/writing_tests/adding_a_new_test/">Adding a New Test</a> - Step-by-step guide to adding new tests</li> <li><a href="http://localhost:1313/main/writing_tests/writing_a_new_test/">Writing a New Test</a> - Detailed guide on writing different test types</li> <li><a href="http://localhost:1313/main/writing_tests/fork_methods/">Using and Extending Fork Methods</a> - How to use fork methods to write fork-adaptive tests</li> <li><a href="http://localhost:1313/main/writing_tests/porting_legacy_tests/">Porting tests</a>: A guide to porting <a href="https://github.com/ethereum/tests" target="_blank" rel="noopener">ethereum/tests</a> to EEST.</li> </ul> <p>Please check that your code adheres to the repo&rsquo;s coding standards and read the other pages in this section for more background and an explanation of how to implement state transition and blockchain tests.</p> + + + + http://localhost:1313/main/running_tests/consume/cache/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/running_tests/consume/cache/ + <h1 id="consume-cache-and-fixture-inputs">Consume Cache and Fixture Inputs</h1> <p>The <code>consume cache</code> command can be used to resolve, download and cache fixture releases:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-console" data-lang="console"><span style="display:flex;"><span>consume cache --input=stable@v4.5.0 </span></span></code></pre></div><p>All <code>consume</code> subcommands have an <code>--input</code> argument, which implements the same functionality as <code>consume cache</code> to download and cache fixtures, respectively obtain downloaded fixtures from the cache.</p> <h2 id="example-two-liner-to-download-the-latest-fixture-release">Example: Two-liner to Download the Latest Fixture Release</h2> <p>Releases can be downloaded using EEST tooling without (manually) cloning and installing the @ethereum/execution-spec-tests tools as following:</p> + + + + http://localhost:1313/main/running_tests/consume/direct/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/running_tests/consume/direct/ + <h1 id="the-consume-direct-command">The <code>consume direct</code> Command</h1> <p>The <code>direct</code> method provides the fastest way to test EVM functionality by executing tests directly through a client&rsquo;s dedicated test interface (e.g. <a href="https://github.com/ethereum/go-ethereum/blob/4bb097b7ffc32256791e55ff16ca50ef83c4609b/cmd/evm/staterunner.go" target="_blank" rel="noopener"><code>statetest</code></a> or <a href="https://github.com/ethereum/go-ethereum/blob/35dd84ce2999ecf5ca8ace50a4d1a6abc231c370/cmd/evm/blockrunner.go" target="_blank" rel="noopener"><code>blocktest</code></a>).</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-bash" data-lang="bash"><span style="display:flex;"><span>uv run consume direct --bin<span style="color:#f92672">=</span>&lt;evm-binary&gt; <span style="color:#f92672">[</span>OPTIONS<span style="color:#f92672">]</span> </span></span></code></pre></div><ul> <li><code>--bin EVM_BIN</code>: Path to an evm executable that can process <code>StateTestFixture</code> and/or <code>BlockTestFixture</code> formats.</li> <li><code>--traces</code>: Collect execution traces from the evm executable.</li> </ul> <div class="callout callout-warning"> <div class="callout-title">Limited Client Support</div> <div class="callout-content"> <p>Currently, only the following clients can be used with <code>consume direct</code>:</p> <ul> <li>go-ethereum <code>statetest</code> and <code>blocktest</code>.</li> <li>Nethermind <code>nethtest</code>.</li> </ul> </div> </div> <h2 id="advantages">Advantages</h2> <ul> <li><strong>Speed</strong>: Fastest test execution method.</li> <li><strong>Simplicity</strong>: No container or network overhead.</li> <li><strong>Debugging</strong>: Easy access to traces and logs.</li> </ul> <h2 id="limitations">Limitations</h2> <ul> <li><strong>Limited client support</strong>: Only go-ethereum and Nethermind.</li> <li><strong>Module scope</strong>: Tests EVM, respectively block import, in isolation, not full client behavior.</li> <li><strong>Interface dependency</strong>: Requires client-specific test interfaces.</li> </ul> <h2 id="example-usage">Example Usage</h2> <p>Only run state tests (by using a mark filter, <code>-m</code>) from a local <code>fixtures</code> folder with go-ethereum:</p> + + + + http://localhost:1313/main/running_tests/consume/exceptions/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/running_tests/consume/exceptions/ + <h1 id="exception-tests">Exception Tests</h1> <h2 id="overview">Overview</h2> <p>Exception tests validate that clients correctly reject invalid blocks and transactions with appropriate error messages. The Engine simulator provides advanced exception verification using client-specific mappers to handle varying error message formats across different clients.</p> <h2 id="how-exception-testing-works">How Exception Testing Works</h2> <ol> <li><strong>Test fixtures specify expected exceptions</strong> - Each test defines what error should occur</li> <li><strong>Clients reject invalid payloads</strong> - Via Engine API or block import</li> <li><strong>Exception mappers translate errors</strong> - Client-specific error messages are normalized</li> <li><strong>Test framework validates</strong> - Ensures the correct exception type was raised</li> </ol> <h2 id="client-exception-mappers">Client Exception Mappers</h2> <p>Each client has unique error message formats. EEST maintains exception mappers that translate client-specific errors to standardized exception types.</p> + + + + http://localhost:1313/main/running_tests/consume/simulators/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/running_tests/consume/simulators/ + <h1 id="consume-simulators">Consume Simulators</h1> <p>The <code>engine</code> and <code>rlp</code> simulators test clients by importing blocks through different interfaces. These simulators run within the Hive testing framework to provide containerized, isolated testing environments.</p> <h2 id="command-syntax">Command Syntax</h2> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-bash" data-lang="bash"><span style="display:flex;"><span>uv run consume &lt;engine|rlp&gt; <span style="color:#f92672">[</span>OPTIONS<span style="color:#f92672">]</span> </span></span></code></pre></div><h2 id="relevant-information">Relevant Information</h2> <ul> <li>To install the <code>consume</code> command, see <a href="../../getting_started/main.md">Installation</a>.</li> <li>Help <a href="../hive/main.md">setting up</a> and <a href="../hive/dev_mode.md">starting Hive in dev mode</a>.</li> <li>For an explanation of how the <code>consume</code> simulators work, see the <a href="../running.md#engine">Engine</a> and <a href="../running.md#rlp">RLP</a> sections in <a href="../running.md">Running Tests</a>.</li> <li>Help for relevant options can be found in <a href="./cache.md">Consume Cache and Fixture Inputs</a> and <a href="../useful_pytest_options.md">Useful Pytest Options</a>.</li> </ul> + + + + http://localhost:1313/main/running_tests/execute/hive/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/running_tests/execute/hive/ + <h1 id="executing-tests-on-a-hive-local-network">Executing Tests on a Hive Local Network</h1> <p>Tests can be executed on a local hive-controlled single-client network by running the <code>execute hive</code> command.</p> <h2 id="the-eestexecute-blobs-simulator">The <code>eest/execute-blobs</code> Simulator</h2> <p>The <code>blob_transaction_test</code> execute test spec sends blob transactions to a running client in order to verify its <code>engine_getBlobsVX</code> endpoint behavior. These tests can be run using:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-bash" data-lang="bash"><span style="display:flex;"><span>./hive --client besu --client-file ./configs/osaka.yaml --sim ethereum/eest/execute-blobs </span></span></code></pre></div><p>See <a href="../hive/main.md">Hive</a> for help installing and configuring Hive.</p> <h2 id="running-execute-tests-with-hive-in-dev-mode">Running <code>execute</code> tests with Hive in Dev Mode</h2> <p>This command requires hive to be running in <code>--dev</code> mode:</p> + + + + http://localhost:1313/main/running_tests/execute/remote/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/running_tests/execute/remote/ + <h1 id="running-test-on-a-live-remote-network">Running Test on a Live Remote Network</h1> <p>Tests can be executed on a live remote network by running the <code>execute remote</code> command.</p> <p>The command requires the <code>--fork</code> flag which must match the fork that is currently active in the network (fork transition tests are not supported yet).</p> <p>The <code>execute remote</code> command requires to be pointed to an RPC endpoint of a client that is connected to the network, which can be specified by using the <code>--rpc-endpoint</code> flag:</p> + + + + http://localhost:1313/main/running_tests/hive/ci_integration/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/running_tests/hive/ci_integration/ + <h1 id="continuous-integration-and-automated-testing">Continuous Integration and Automated Testing</h1> <p>The Ethereum Foundation maintains continuous testing infrastructure:</p> <ul> <li><strong>Production results</strong>: <a href="https://hive.ethpandaops.io" target="_blank" rel="noopener">hive.ethpandaops.io</a></li> <li><strong>GitHub Actions</strong>: <a href="https://github.com/ethpandaops/hive-github-action" target="_blank" rel="noopener">ethpandaops/hive-github-action</a></li> </ul> + + + + http://localhost:1313/main/running_tests/hive/client_config/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/running_tests/hive/client_config/ + <h1 id="client-configuration-guide">Client Configuration Guide</h1> <p>Clients ran in Hive are configured via the following <code>./hive</code> options:</p> <ol> <li><code>--client-file=client_config.yaml</code>: Specifies a YAML file defining which and how clients are built.</li> <li><code>--client=client1,client2</code>: Selects a subset of clients to run from the YAML via <code>nametag</code>.</li> </ol> <h2 id="client-yaml-file-format">Client YAML File Format</h2> <p>Multiple client configurations can be defined as a list in a client YAML file with the following structure:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-yaml" data-lang="yaml"><span style="display:flex;"><span>- <span style="color:#f92672">client</span>: <span style="color:#ae81ff">&lt;client-name-1&gt;</span> </span></span><span style="display:flex;"><span> <span style="color:#f92672">nametag</span>: <span style="color:#ae81ff">&lt;unique-identifier&gt;</span> </span></span><span style="display:flex;"><span> <span style="color:#f92672">dockerfile</span>: <span style="color:#ae81ff">&lt;dockerfile-variant&gt;</span> </span></span><span style="display:flex;"><span> <span style="color:#f92672">build_args</span>: </span></span><span style="display:flex;"><span> <span style="color:#f92672">&lt;key&gt;</span>: <span style="color:#ae81ff">&lt;value&gt;</span> </span></span><span style="display:flex;"><span> <span style="color:#ae81ff">...</span> </span></span><span style="display:flex;"><span>- <span style="color:#f92672">client</span>: <span style="color:#ae81ff">&lt;client-name-2&gt;</span> </span></span><span style="display:flex;"><span> <span style="color:#ae81ff">...</span> </span></span></code></pre></div><h2 id="client-build-variants">Client Build Variants</h2> <p>Hive runs client images in Docker containers. There are three different ways to specify how a client image should be built:</p> + + + + http://localhost:1313/main/running_tests/hive/common_options/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/running_tests/hive/common_options/ + <h1 id="common-simulator-options">Common Simulator Options</h1> <p>All EEST Hive simulators share common command-line options and patterns.</p> <h2 id="basic-usage">Basic Usage</h2> <p>While they may be omitted, it&rsquo;s recommended to specify the <code>fixtures</code> and <code>branch</code> simulator build arguments when running EEST simulators.</p> <p>For example, this runs &ldquo;stable&rdquo; fixtures from the v4.3.0 <a href="../releases.md#standard-releases">latest stable release</a> and builds the simulator at the v4.3.0 tag:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-bash" data-lang="bash"><span style="display:flex;"><span>./hive --sim ethereum/eest/consume-engine <span style="color:#ae81ff">\ </span></span></span><span style="display:flex;"><span><span style="color:#ae81ff"></span> --sim.buildarg fixtures<span style="color:#f92672">=</span>stable@v4.3.0 <span style="color:#ae81ff">\ </span></span></span><span style="display:flex;"><span><span style="color:#ae81ff"></span> --sim.buildarg branch<span style="color:#f92672">=</span>v4.3.0 <span style="color:#ae81ff">\ </span></span></span><span style="display:flex;"><span><span style="color:#ae81ff"></span> --client go-ethereum </span></span></code></pre></div><h2 id="test-selection">Test Selection</h2> <p>Run a subset of tests by filtering tests using <code>--sim.limit=&lt;regex&gt;</code> to perform a regular expression match against test IDs:</p> + + + + http://localhost:1313/main/running_tests/hive/dev_mode/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/running_tests/hive/dev_mode/ + <h1 id="hive-development-mode">Hive Development Mode</h1> <p>This section explains how to run EEST simulators using their EEST commands, e.g., <code>uv run consume engine</code>, against a Hive &ldquo;development&rdquo; server as apposed to using the standalone <code>./hive</code> command.</p> <p>This avoids running the simulator in a dockerized environment and has several advantages:</p> <ol> <li>A local directory containing fixtures can be specified (<code>--input=./fixtures/</code>).</li> <li>Allows dropping into a Python debugger (via <code>--pdb</code>) upon test failure to inspect the response or ssh to the client container.</li> <li>Provides access to a larger set of the simulator&rsquo;s command-line options,</li> <li>Runs are faster; there are no docker image rebuilds in between runs. In particular, modifications to the simulator do not require a an image rebuild.</li> </ol> <h2 id="platform-support">Platform Support</h2> <ul> <li>Linux: Direct development mode supported.</li> <li>macOS: Must be ran from a Linux environment or use a Docker-based workaround (see macOS Setup).</li> </ul> <h2 id="quick-start">Quick Start</h2> <h3 id="prerequisites">Prerequisites</h3> <ul> <li>EEST is installed, see <a href="../../getting_started/main.md">Installation</a></li> <li>Hive is built, see <a href="../hive/main.md#quick-start">Hive</a>.</li> </ul> <h2 id="hive-dev-setup-on-linux">Hive Dev Setup on Linux</h2> <ol> <li> <p>Start Hive in development mode, e.g.:</p> + + + + http://localhost:1313/main/running_tests/hive/hiveview/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/running_tests/hive/hiveview/ + <h1 id="viewing-results">Viewing Results</h1> <p>Build the result viewer <code>hiveview</code>:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-bash" data-lang="bash"><span style="display:flex;"><span>go build ./cmd/hiveview </span></span></code></pre></div><p>Start the server:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-bash" data-lang="bash"><span style="display:flex;"><span>./hiveview --serve </span></span></code></pre></div> + + + + http://localhost:1313/main/running_tests/test_formats/blockchain_test/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/running_tests/test_formats/blockchain_test/ + <h1 id="blockchain-tests">Blockchain Tests <!-- markdownlint-disable MD051 (MD051=link-fragments "Link fragments should be valid") --></h1> <p>The Blockchain Test fixture format tests are included in the fixtures subdirectory <code>blockchain_tests</code>.</p> <p>These are produced by the <code>StateTest</code> and <code>BlockchainTest</code> test specs.</p> <h2 id="description">Description</h2> <p>The blockchain test fixture format is used to test block validation and the consensus rules of the Ethereum blockchain.</p> <p>It does so by defining a pre-execution state, a series of blocks, and a post-execution state, verifying that, after all the blocks have been processed, appended if valid or rejected if invalid, the result is the expected post-execution state.</p> + + + + http://localhost:1313/main/running_tests/test_formats/blockchain_test_engine/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/running_tests/test_formats/blockchain_test_engine/ + <h1 id="blockchain-engine-tests">Blockchain Engine Tests <!-- markdownlint-disable MD051 (MD051=link-fragments "Link fragments should be valid") --></h1> <p>The Blockchain Engine Test fixture format tests are included in the fixtures subdirectory <code>blockchain_tests_engine</code>, and use Engine API directives instead of the usual BlockchainTest format.</p> <p>These are produced by the <code>StateTest</code> and <code>BlockchainTest</code> test specs.</p> <h2 id="description">Description</h2> <p>The Blockchain Engine Test fixture format is used to test block validation and the consensus rules of the Ethereum blockchain, when a block is delivered through the Engine API as a <code>engine_newPayloadVX</code> directive.</p> + + + + http://localhost:1313/main/running_tests/test_formats/blockchain_test_engine_x/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/running_tests/test_formats/blockchain_test_engine_x/ + <h1 id="blockchain-engine-x-tests">Blockchain Engine X Tests <!-- markdownlint-disable MD051 (MD051=link-fragments "Link fragments should be valid") --></h1> <p>The Blockchain Engine X Test fixture format tests are included in the fixtures subdirectory <code>blockchain_tests_engine_x</code>, and use Engine API directives with optimized pre-allocation groups for improved execution performance.</p> <p>These are produced by the <code>StateTest</code> and <code>BlockchainTest</code> test specs when using the <code>--generate-pre-alloc-groups</code> and <code>--use-pre-alloc-groups</code> flags.</p> <h2 id="description">Description</h2> <p>The Blockchain Engine X Test fixture format is an optimized variant of the <a href="./blockchain_test_engine.md">Blockchain Engine Test</a> format designed for large-scale test execution with performance optimizations.</p> + + + + http://localhost:1313/main/running_tests/test_formats/common_types/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/running_tests/test_formats/common_types/ + <h1 id="common-types">Common Types</h1> <h2 id="basic-types">Basic Types</h2> <h3 id="address"><code>Address</code></h3> <p><a href="#bytes">Bytes</a> of a 20-byte fixed length.</p> <h3 id="bloom"><code>Bloom</code></h3> <p><a href="#bytes">Bytes</a> of a 256-byte fixed length.</p> <h3 id="bytes"><code>Bytes</code></h3> <p>Hexadecimal representation of binary data of any length encoded as a JSON string, with a &ldquo;0x&rdquo; prefix.</p> <h3 id="emptyaddress"><code>EmptyAddress</code></h3> <p>An empty JSON string <code>&quot;&quot;</code>, used to represent an empty address. E.g. in the <code>to</code> field of a transaction when it is a contract creation.</p> <h3 id="hash"><code>Hash</code></h3> <p><a href="#bytes">Bytes</a> of a 32-byte fixed length.</p> <h3 id="headernonce"><code>HeaderNonce</code></h3> <p><a href="#bytes">Bytes</a> of a 8-byte fixed length.</p> + + + + http://localhost:1313/main/running_tests/test_formats/exceptions/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/running_tests/test_formats/exceptions/ + <h1 id="exceptions">Exceptions</h1> <p>Exception types are represented as a JSON string in the test fixtures.</p> <p>The exception converted into a string is composed of the exception type name, followed by a period, followed by the specific exception name.</p> <p>For example, the exception <code>INSUFFICIENT_ACCOUNT_FUNDS</code> of type <code>TransactionException</code> is represented as <code>&quot;TransactionException.INSUFFICIENT_ACCOUNT_FUNDS&quot;</code>.</p> <p>The JSON string can contain multiple exception types, separated by the <code>|</code> character, denoting that the transaction or block can throw either one of the exceptions.</p> + + + + http://localhost:1313/main/running_tests/test_formats/state_test/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/running_tests/test_formats/state_test/ + <h1 id="state-tests">State Tests <!-- markdownlint-disable MD051 (MD051=link-fragments "Link fragments should be valid") --></h1> <p>The State Test fixture format tests are included in the fixtures subdirectory <code>state_tests</code>.</p> <p>These are produced by the <code>StateTest</code> and <code>StateTestOnly</code> test specs.</p> <h2 id="description">Description</h2> <p>The state test fixture format is used to test the state transition function of the Ethereum Virtual Machine (EVM).</p> <p>It does so by defining a transaction, a pre-execution state, and a post-execution state, and verifying that the transaction execution results in the expected post-execution state.</p> + + + + http://localhost:1313/main/running_tests/test_formats/transaction_test/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/running_tests/test_formats/transaction_test/ + <h1 id="transaction-tests">Transaction Tests <!-- markdownlint-disable MD051 (MD051=link-fragments "Link fragments should be valid") --></h1> <p>The Transaction Test fixture format tests are included in the fixtures subdirectory <code>transaction_tests</code>.</p> <p>These are produced by the <code>TransactionTest</code> test spec.</p> <h2 id="description">Description</h2> <p>The transaction test fixture format is used to test client&rsquo;s transaction RLP parsing without executing the transaction on the EVM.</p> <p>It does so by defining a transaction binary RLP representation, and whether the transaction should be accepted or rejected by the client in each fork.</p> + + + + http://localhost:1313/main/writing_tests/checklist_templates/eip_testing_checklist_template/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/writing_tests/checklist_templates/eip_testing_checklist_template/ + <!-- markdownlint-disable MD001 (MD001=heading-increment) --> <h1 id="eip-execution-layer-testing-checklist-template">EIP Execution Layer Testing Checklist Template</h1> <p>Depending on the changes introduced by an EIP, the following template is the minimum baseline to guarantee test coverage of the Execution Layer features.</p> <h2 id="checklist-progress-tracker">Checklist Progress Tracker</h2> <table> <thead> <tr> <th>Total Checklist Items</th> <th>Covered Checklist Items</th> <th>Percentage</th> </tr> </thead> <tbody> <tr> <td>TOTAL_CHECKLIST_ITEMS</td> <td>COVERED_CHECKLIST_ITEMS</td> <td>PERCENTAGE</td> </tr> </tbody> </table> <h2 id="general">General</h2> <h4 id="code-coverage">Code coverage</h4> <table> <thead> <tr> <th>ID</th> <th>Description</th> <th>Status</th> <th>Tests</th> </tr> </thead> <tbody> <tr> <td><code>general/code_coverage/eels</code></td> <td>Run produced tests against <a href="https://github.com/ethereum/execution-specs" target="_blank" rel="noopener">EELS</a> and verify that line code coverage of new added lines for the EIP is 100%, with only exceptions being unreachable code lines.</td> <td></td> <td></td> </tr> <tr> <td><code>general/code_coverage/test_coverage</code></td> <td>Run coverage on the test code itself (as a basic logic sanity check), i.e., <code>uv run fill --cov tests</code>.</td> <td></td> <td></td> </tr> <tr> <td><code>general/code_coverage/second_client</code></td> <td>Optional - Run against a second client and verify sufficient code coverage over new code added for the EIP.</td> <td></td> <td></td> </tr> </tbody> </table> <h4 id="fuzzing">Fuzzing</h4> <p>Fuzzing is recommended to be performed on EIPs that introduce new cryptography primitives.</p> + + + + http://localhost:1313/main/writing_tests/tutorials/blockchain/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/writing_tests/tutorials/blockchain/ + <h1 id="blockchain-tests">Blockchain Tests</h1> <p>This tutorial teaches you to create a blockchain execution specification test. These tests verify that a blockchain, starting from a defined pre-state, will process given blocks and arrive at a defined post-state.</p> <h2 id="pre-requisites">Pre-requisites</h2> <p>Before proceeding with this tutorial, it is assumed that you have prior knowledge and experience with the following:</p> <ul> <li>Repository set-up, see <a href="../../getting_started/main.md">installation</a>.and run an execution specification test as outlined in the .</li> <li>Able to run <code>fill</code>, see <a href="../../filling_tests/getting_started.md">Getting Started: Filling Tests</a>.</li> <li>Understand how to read a <a href="https://ethereum-tests.readthedocs.io/en/latest/test_filler/blockchain_filler.html" target="_blank" rel="noopener">blockchain test</a>.</li> <li>Familiarity with <a href="https://docs.python.org/3/tutorial/" target="_blank" rel="noopener">Python</a>.</li> <li>Understand how to write an execution spec <a href="./state_transition.md">state transition test</a>.</li> </ul> <h2 id="example-tests">Example Tests</h2> <p>In this tutorial we will go over [test_block_number] in <code>test_block_example.py</code>.</p> + + + + http://localhost:1313/main/writing_tests/tutorials/state_transition/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/writing_tests/tutorials/state_transition/ + <h1 id="state-transition-tests">State Transition Tests</h1> <p>This tutorial teaches you to create a state transition execution specification test using the Python Opcodes minilang for writing EVM bytecode. These tests verify that a starting pre-state will reach a specified post-state after executing a single transaction. In this example, we&rsquo;ll create a simple contract using bytecode and then interact with it through a transaction to verify the expected state changes.</p> <p>For an overview of different test types available, see <a href="../../writing_tests/types_of_tests.md">Types of Tests</a>.</p> + + + An Explanation of Test IDs + http://localhost:1313/main/filling_tests/test_ids/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/filling_tests/test_ids/ + <h2 id="test-case-organization">Test Case Organization</h2> <p>Test cases are implemented in Python &ldquo;modules&rdquo;, which are organized by folder, named after the fork where the feature-under-test was introduced, for example:</p> <ul> <li><code>tests/cancun/</code> contains tests for features added in the Cancun hardfork.</li> <li><code>tests/prague/</code> contains tests for features added in the Prague hardfork.</li> </ul> <h2 id="test-id-generation">Test ID generation</h2> <p>A test ID is a string, generated by the test framework, that uniquely identifies a test case. It&rsquo;s format is:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-text" data-lang="text"><span style="display:flex;"><span>&lt;python_test_module_path&gt;::&lt;python_test_function_name&gt;[&lt;parameter_1_id&gt;-...-&lt;parameter_N_id] </span></span></code></pre></div><p>Let&rsquo;s use the following simple test case example to understand this format:</p> + + + Debugging Transition Tools + http://localhost:1313/main/filling_tests/debugging_t8n_tools/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/filling_tests/debugging_t8n_tools/ + <p>There are two flags that can help debugging <code>t8n</code> tools or the execution-spec-tests framework:</p> <ol> <li><code>--evm-dump-dir</code> (Default: <repo>/logs/evm): Write debug information from <code>t8n</code> tool calls to the specified directory.</li> <li><code>--traces</code>: Collect traces of the execution from the transition tool.</li> <li><code>--verify-fixtures</code>: Run go-ethereum&rsquo;s <code>evm blocktest</code> command to verify the generated test fixtures.</li> </ol> <h2 id="evm-dump-directory">EVM Dump Directory</h2> <p>The <code>--evm-dump-dir</code> flag tells the framework to write the inputs and outputs of every call made to the <code>t8n</code> command to the specified output directory. The aim is to help debugging or simply understand how a test is interacting with the EVM. The default location is <code>logs/evm</code> in the project root.</p> + + + Filling Tests at a Prompt + http://localhost:1313/main/filling_tests/filling_tests_command_line/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/filling_tests/filling_tests_command_line/ + <p>The execution-spec-tests test framework uses the <a href="https://docs.pytest.org/en/latest/" target="_blank" rel="noopener">pytest framework</a> for test case collection and execution. The <code>fill</code> command is essentially an alias for <code>pytest</code>, which uses several <a href="../library/pytest_plugins/main.md">custom pytest plugins</a> to run transition tools against test cases and generate JSON fixtures.</p> <div class="callout callout-info"> <div class="callout-title">Options specific to execution-spec-tests</div> <div class="callout-content"> <p>The command-line options specific to filling tests can be listed via:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-console" data-lang="console"><span style="display:flex;"><span>uv run fill --help </span></span></code></pre></div><p>See <a href="#custom-fill-command-line-options">Custom <code>fill</code> Command-Line Options</a> for all options.</p> </div> </div> <h2 id="collection---test-exploration">Collection - Test Exploration</h2> <p>The test cases implemented in the <code>./tests</code> sub-directory can be listed in the console using:</p> + + + Filling Tests for Features under Development + http://localhost:1313/main/filling_tests/filling_tests_dev_fork/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/filling_tests/filling_tests_dev_fork/ + <h2 id="requirements">Requirements</h2> <p>By default, execution-spec-tests only generates fixtures for forks that have been deployed to mainnet. In order to generate fixtures for evm features that are actively under development:</p> <ol> <li>A version of the <code>evm</code> and <code>solc</code> tools that implement the feature must be available (although, typically only a developer version of the <code>evm</code> tool is required, usually the latest stable release of <code>solc</code> is adequate), and,</li> <li>The development fork to test must be explicitly specified on the command-line:</li> </ol> <div class="tab-container" data-tab-group="tabs-0"> <div class="tab-header"> <button class="tab-button active" onclick="switchTab('tabs-0', 0 )"> via the <code>--fork</code> flag </button> <button class="tab-button " onclick="switchTab('tabs-0', 1 )"> via the <code>--from</code> flag </button> <button class="tab-button " onclick="switchTab('tabs-0', 2 )"> via the <code>--until</code> flag </button> </div> <div class="tab-panels"> <div class="tab-panel active"> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-console" data-lang="console"><span style="display:flex;"><span>uv run fill -k 4844 --fork=Cancun -v </span></span></code></pre></div> </div> <div class="tab-panel "> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-console" data-lang="console"><span style="display:flex;"><span>uv run fill -k 4844 --from=Cancun -v </span></span></code></pre></div> </div> <div class="tab-panel "> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-console" data-lang="console"><span style="display:flex;"><span>uv run fill -k 4844 --until=Cancun -v </span></span></code></pre></div> </div> </div> </div> <style> .tab-container { margin: 1.5rem 0; background: #f8f9fa; border-radius: 8px; overflow: hidden; box-shadow: 0 1px 3px rgba(0,0,0,0.1); } .tab-header { display: flex; background: #e9ecef; } .tab-button { flex: 1; padding: 0.75rem 1rem; border: none; background: transparent; cursor: pointer; font-size: 14px; white-space: nowrap; transition: all 0.2s; position: relative; text-align: center; overflow: hidden; text-overflow: ellipsis; } .tab-button:hover { background: rgba(0,0,0,0.05); } .tab-button.active { background: #f8f9fa; font-weight: 600; color: #007bff; } .tab-button.active::after { content: ''; position: absolute; bottom: 0; left: 0; right: 0; height: 3px; background: #007bff; } .tab-button code { background: rgba(0,0,0,0.1); padding: 2px 4px; border-radius: 3px; font-size: 12px; } .tab-panel { display: none; padding: 1.5rem; background: white; } .tab-panel.active { display: block; } .tab-panel pre { margin: 0; background: #f6f8fa; border: 1px solid #e1e4e8; } @media (max-width: 768px) { .tab-header { flex-wrap: wrap; } .tab-button { flex: 1 1 50%; padding: 0.5rem 0.75rem; font-size: 13px; } @media (max-width: 480px) { .tab-button { flex: 1 1 100%; } } } </style> <script> function switchTab(groupId, tabIndex) { const container = document.querySelector(`[data-tab-group="${groupId}"]`); container.querySelectorAll('.tab-button').forEach((btn, idx) => { btn.classList.toggle('active', idx === tabIndex); }); container.querySelectorAll('.tab-panel').forEach((panel, idx) => { panel.classList.toggle('active', idx === tabIndex); }); } </script> <div class="callout callout-info"> <div class="callout-title">Specifying the <code>evm</code> binary via <code>evm-bin</code></div> <div class="callout-content"> <p>It is possible to explicitly specify the <code>evm</code> binary used to generate fixtures via the <code>--evm-bin</code> flag, for example,</p> + + + Filling Tests in VS Code + http://localhost:1313/main/filling_tests/filling_tests_vs_code/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/filling_tests/filling_tests_vs_code/ + <p>Prerequisite: <a href="../getting_started/setup_vs_code.md">VS Code Setup</a>.</p> <h2 id="exploring-test-cases">Exploring Test Cases</h2> <p>Implemented test cases can be explored in VS Code&rsquo;s &ldquo;Testing&rdquo; View; click on the conical flask highlighted in the screenshot below.</p> <p><img src="http://localhost:1313/images/filling_tests/vs_code_exploring_tests.png" alt="VS Code Testing Tab"></p> <div class="callout callout-info"> <div class="callout-title">Testing EVM Features Under Active Development</div> <div class="callout-content"> See <a href="./filling_tests_dev_fork.md#vs-code-setup">the VS Code section</a> in <a href="./filling_tests_dev_fork.md">Filling Tests for Features under Development</a> to explore tests targeting EVM features under development. </div> </div> <h2 id="filling-and-debugging-test-cases">Filling and Debugging Test Cases</h2> <p><img src="http://localhost:1313/images/filling_tests/vs_code_executing_tests.png" alt="VS Code Testing Tab"></p> + + + Transition Tool Support + http://localhost:1313/main/filling_tests/transition_tool_support/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/filling_tests/transition_tool_support/ + <p>The following transition tools are supported by the framework:</p> <table> <thead> <tr> <th>Client</th> <th><code>t8n</code> Tool</th> <th>Tracing Support</th> </tr> </thead> <tbody> <tr> <td><a href="https://github.com/ethereum/evmone" target="_blank" rel="noopener">ethereum/evmone</a></td> <td><code>evmone-t8n</code></td> <td>Yes</td> </tr> <tr> <td><a href="https://github.com/ethereum/execution-specs" target="_blank" rel="noopener">ethereum/execution-specs</a></td> <td><a href="https://github.com/petertdavies/ethereum-spec-evm-resolver" target="_blank" rel="noopener"><code>ethereum-spec-evm-resolver</code></a></td> <td>Yes</td> </tr> <tr> <td><a href="https://github.com/ethereumjs/ethereumjs-monorepo" target="_blank" rel="noopener">ethereumjs</a></td> <td><a href="https://github.com/ethereumjs/ethereumjs-monorepo/tree/master/packages/vm/test/t8n" target="_blank" rel="noopener"><code>ethereumjs-t8ntool.sh</code></a></td> <td>No</td> </tr> <tr> <td><a href="https://github.com/ethereum/go-ethereum" target="_blank" rel="noopener">ethereum/go-ethereum</a></td> <td><a href="https://github.com/ethereum/go-ethereum/tree/master/cmd/evm" target="_blank" rel="noopener"><code>evm t8n</code></a></td> <td>Yes</td> </tr> <tr> <td><a href="https://github.com/hyperledger/besu/tree/main/ethereum/evmtool" target="_blank" rel="noopener">hyperledger/besu</a></td> <td><a href="https://github.com/hyperledger/besu/tree/main/ethereum/evmtool" target="_blank" rel="noopener"><code>evmtool t8n-server</code></a></td> <td>Yes</td> </tr> <tr> <td><a href="https://github.com/status-im/nimbus-eth1" target="_blank" rel="noopener">status-im/nimbus-eth1</a></td> <td><a href="https://github.com/status-im/nimbus-eth1/blob/master/tools/t8n/readme.md" target="_blank" rel="noopener"><code>t8n</code></a></td> <td>Yes</td> </tr> </tbody> </table> + + + diff --git a/docs/public/main/adding_a_new_test/index.html b/docs/public/main/adding_a_new_test/index.html new file mode 100644 index 00000000000..20695a384b2 --- /dev/null +++ b/docs/public/main/adding_a_new_test/index.html @@ -0,0 +1,1458 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

Adding a New Test

+

All test cases are located underneath the tests directory, which are then organized by fork. Each fork contains sub-directories containing test sub-categories.

+
πŸ“ execution-test-specs/
+β”œβ”€β•΄πŸ“ tests/
+|   β”œβ”€β”€ πŸ“„ __init__.py
+β”‚   β”œβ”€β”€ πŸ“ cancun/
+|   |    β”œβ”€β”€ πŸ“„ __init__.py
+β”‚   |    └── πŸ“ eip4844_blobs/
+|   |        β”œβ”€β”€ πŸ“„ __init__.py
+|   |        β”œβ”€β”€ πŸ“„ test_blobhash_opcode.py
+|   |        β”œβ”€β”€ πŸ“„ test_excess_blob_gas.py
+|   |        └── πŸ“„ ...
+|   β”œβ”€β”€ πŸ“ shanghai
+|   |    β”œβ”€β”€ πŸ“ eip3651_warm_coinbase
+|   |    |   β”œβ”€β”€ πŸ“„ __init__.py
+|   |    |   └── πŸ“„ test_warm_coinbase.py
+|   |    β”œβ”€β”€ πŸ“ eip3855_push0
+|   |    |   β”œβ”€β”€ πŸ“„ __init__.py
+|   |    |   └── πŸ“„ test_push0.py
+|   |    β”œβ”€β”€ πŸ“...
+|   |    ...
+β”‚   └── πŸ“ ...
+

Each category/sub-directory may have multiple Python test modules (*.py) which in turn may contain many test functions. The test functions themselves are always parametrized by fork (by the framework).

+

A new test can be added by either:

+
    +
  • Adding a new test_ python function to an existing file in any of the existing category subdirectories within tests.
  • +
  • Creating a new source file in an existing category, and populating it with the new test function(s).
  • +
  • Creating an entirely new category by adding a subdirectory in tests with the appropriate source files and test functions.
  • +
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/blockchain/index.html b/docs/public/main/blockchain/index.html new file mode 100644 index 00000000000..5d00d71d366 --- /dev/null +++ b/docs/public/main/blockchain/index.html @@ -0,0 +1,1315 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

Blockchain Tests

+

This tutorial teaches you to create a blockchain execution specification test. These tests verify that a blockchain, starting from a defined pre-state, will process given blocks and arrive at a defined post-state.

+

Pre-requisites

+

Before proceeding with this tutorial, it is assumed that you have prior knowledge and experience with the following:

+ +

Example Tests

+

In this tutorial we will go over [test_block_number] in test_block_example.py.

+

It is assumed you have already gone through the state transition test tutorial. Only new concepts will be discussed.

+

Smart Contract

+

A smart contract is defined that is called by each transaction in the test. It stores a pointer to storage at storage[0]. When it is called storage cell 0 gets the current block number, and the pointer is incremented to the next value.

+
contract_addr: Account(
+    balance=1000000000000000000000,
+    code=code,
+    storage={
+        0x00: 0x01,
+    },
+),
+

Transaction Generator

+

The transactions used in this test are nearly identical. Their only difference is the nonce value which needs to be incremented.

+
def tx_generator():
+    nonce = 0  # Initial value
+    while True:
+        tx = Transaction(
+            ty=0x0,
+            chain_id=0x0,
+            nonce=nonce,
+            to=contractAddr,
+            gas_limit=500000,
+            gas_price=10,
+        )
+        nonce = nonce + 1
+        yield tx
+
+tx_generator = tx_generator()
+

This looks like an infinite loop but it isn’t because this is a generator function. When generator encounters the yield keyword it returns the value and stops execution, keeping a copy of all the local variables, until it is called again. Hence infinite loops inside a generator are not a problem as long as they include yield. This code section is responsible for creating the Transaction object and incrementing the nonce.

+

Every time the function tx_generator() is called, it returns a new generator with a nonce of zero. To increment the nonce we need to use the same generator. We assign this generator to tx_generator.

+

Blocks

+

Each integer in the tx_per_block array is the number of transactions in a block. The genesis block is block 0 (no transactions). It follows that we have 2 transactions in block 1, 0 in block two, 4 in block 3, …, and 50 in block 9.

+
tx_per_block = [2, 0, 4, 8, 0, 0, 20, 1, 50]
+

The code section that creates the blocks is a bit complex in this test. For some simpler definitions of Block creation you can browse tests within test_withdrawals.py.

+
blocks = map(
+    lambda len: Block(
+        txs=list(map(lambda x: next(tx_generator), range(len)))
+    ),
+    tx_per_block,
+)
+

We use lambda notation to specify short functions. In this case, the function doesn’t actually care about its input, it just returns the next transaction from the generator.

+
lambda x: next(tx_generator)
+

Python uses range(n) to create a list of numbers from 0 to n-1. Among other things, it’s a simple way to create a list of n values.

+
range(len)
+

The map function runs the function (the first parameter) on every element of the list (the second parameter). Putting together what we know, it means that it runs next(tx_generator) len times, giving us len transactions. We then use list to turn the transactions into a list that we can provide as the txs parameter to the Block constructor.

+
list(map(lambda x: next(tx_generator), range(len)))
+

The outer lambda function takes an integer, len, and creates a Block object with len transactions. This function is then run on every value of tx_per_block to generate the blocks.

+
blocks = map(
+    lambda len: Block(
+        txs=list of len transactions
+    ),
+    tx_per_block,
+)
+

For example, if we had tx_per_block = [0,2,4], we’d get this result:

+
blocks = [
+    Blocks(txs=[]),
+    Blocks(txs=[next(tx_generator), next(tx_generator)]),
+    Blocks(txs=[next(tx_generator), next(tx_generator), next(tx_generator), next(tx_generator)])        
+]
+

Post State

+

Recall that storage slot 0 retains the value of the next slot that the block number is written into. It starts at one and is incremented after each transaction. Hence it’s the total number of transactions plus 1.

+
storage = {0: sum(tx_per_block) + 1}
+

For every block and transaction within the block, we write the block number and increment the next slot number in storage slot 0. As Python lists are 0 indexed, we must increment the block number by 1.

+
next_slot = 1
+for blocknum in range(len(tx_per_block)):
+    for _ in range(tx_per_block[blocknum]):
+        storage[next_slot] = blocknum + 1
+        next_slot = next_slot + 1
+

Now that the expected storage values are calculated, the post state can be defined and yielded within the BlockchainTest, synonymous to the state test example.

+
post = {contract_addr: Account(storage=storage)}
+
+yield BlockchainTest(
+    genesis_environment=env,
+    pre=pre,
+    blocks=blocks,
+    post=post,
+)
+

Note that because of the yield we could have multiple tests under the same name.

+

Conclusion

+

At this point you should be able to write blockchain tests.

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/blockchain_test/index.html b/docs/public/main/blockchain_test/index.html new file mode 100644 index 00000000000..c493a764383 --- /dev/null +++ b/docs/public/main/blockchain_test/index.html @@ -0,0 +1,1511 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

Blockchain Tests

+

The Blockchain Test fixture format tests are included in the fixtures subdirectory blockchain_tests.

+

These are produced by the StateTest and BlockchainTest test specs.

+

Description

+

The blockchain test fixture format is used to test block validation and the consensus rules of the Ethereum blockchain.

+

It does so by defining a pre-execution state, a series of blocks, and a post-execution state, verifying that, after all the blocks have been processed, appended if valid or rejected if invalid, the result is the expected post-execution state.

+

A single JSON fixture file is composed of a JSON object where each key-value pair is a different Fixture test object, with the key string representing the test name.

+

The JSON file path plus the test name are used as the unique test identifier.

+

Consumption

+

For each Fixture test object in the JSON fixture file, perform the following steps:

+
    +
  1. +

    Use network to configure the execution fork schedule according to the Fork type definition.

    +
  2. +
  3. +

    Use pre as the starting state allocation of the execution environment for the test and calculate the genesis state root.

    +
  4. +
  5. +

    Decode genesisRLP to obtain the genesis block header, if the block cannot be decoded, fail the test.

    +
  6. +
  7. +

    Compare the genesis block header with genesisBlockHeader, if any field does not match, fail the test.

    +
  8. +
  9. +

    Compare the state root calculated on step 2 with the state root in the genesis block header, if they do not match, fail the test.

    +
  10. +
  11. +

    Set the genesis block as the current head of the chain.

    +
  12. +
  13. +

    If blocks contains at least one block, perform the following steps for each FixtureBlock or InvalidFixtureBlock:

    +
      +
    1. +

      Determine whether the current block is valid or invalid:

      +
        +
      1. If the expectException field is not present, it is valid, and object must be decoded as a FixtureBlock.
      2. +
      3. If the expectException field is present, it is invalid, and object must be decoded as a InvalidFixtureBlock.
      4. +
      +
    2. +
    3. +

      Attempt to decode field rlp as the current block

      +
        +
      1. If the block cannot be decoded: +
          +
        • If an rlp decoding exception is not expected for the current block, fail the test.
        • +
        • If an rlp decoding error is expected, pass the test (Note: A block with an expected exception will be the last block in the fixture).
        • +
        +
      2. +
      3. If the block can be decoded, proceed to the next step.
      4. +
      +
    4. +
    5. +

      Attempt to apply the current decoded block on top of the current head of the chain

      +
        +
      1. If the block cannot be applied: +
          +
        • If an exception is expected on the current block and it matches the exception obtained upon execution, pass the test. (Note: A block with an expected exception will be the last block in the fixture)
        • +
        • If an exception is not expected on the current block, fail the test
        • +
        +
      2. +
      3. If the block can be applied: +
          +
        • If an exception is expected on the current block, fail the test
        • +
        • If an exception is not expected on the current block, set the decoded block as the current head of the chain and proceed to the next block until you reach the last block in the fixture.
        • +
        +
      4. +
      +
    6. +
    +
  14. +
  15. +

    Compare the hash of the current head of the chain against lastblockhash, if they do not match, fail the test.

    +
  16. +
  17. +

    Compare all accounts and the fields described in post against the current state, if any do not match, fail the test.

    +
  18. +
+

Structures

+

Fixture

+

- network: Fork

+
TO BE DEPRECATED
+

Fork configuration for the test.

+

This field is going to be replaced by the value contained in config.network.

+

- pre: Alloc

+

Starting account allocation for the test. State root calculated from this allocation must match the one in the genesis block.

+

- genesisRLP: Bytes

+

RLP serialized version of the genesis block.

+

- genesisBlockHeader: FixtureHeader

+

Genesis block header.

+

- blocks: List[FixtureBlock|InvalidFixtureBlock]

+

List of blocks to be processed after the genesis block.

+

- lastblockhash: Hash

+

Hash of the last valid block, or the genesis block hash if the list of blocks is empty, or contains a single invalid block.

+

- post: Alloc

+

Account allocation for verification after all the blocks have been processed.

+

- sealEngine: str

+

Deprecated: Seal engine used to mine the blocks.

+

- config: FixtureConfig

+

Chain configuration object to be applied to the client running the blockchain test.

+

FixtureConfig

+

- network: Fork

+

Fork configuration for the test. It is guaranteed that this field contains the same value as the root field network.

+

- blobSchedule: BlobSchedule

+

Optional; present from Cancun on. Maps forks to their blob schedule configurations as defined by EIP-7840.

+

FixtureHeader

+

- parentHash: Hash

+

Hash of the parent block.

+

- uncleHash: Hash

+

Hash of the uncle block list.

+

- coinbase: Address

+

Address of the account that will receive the rewards for building the block.

+

- stateRoot: Hash

+

Root hash of the state trie.

+

- transactionsTrie: Hash

+

Root hash of the transactions trie.

+

- receiptTrie: Hash

+

Root hash of the receipts trie.

+

- bloom: Bloom

+

Bloom filter composed of the logs of all the transactions in the block.

+

- difficulty: ZeroPaddedHexNumber

+

Difficulty of the block.

+

- number: ZeroPaddedHexNumber

+

Number of the block.

+

- gasLimit: ZeroPaddedHexNumber

+

Total gas limit of the block.

+

- gasUsed: ZeroPaddedHexNumber

+

Total gas used by all the transactions in the block.

+

- timestamp: ZeroPaddedHexNumber

+

Timestamp of the block.

+

- extraData: Bytes

+

Extra data of the block.

+

- mixHash: Hash

+

Mix hash or PrevRandao of the block.

+

- nonce: HeaderNonce

+

Nonce of the block.

+

- hash: Hash

+

Hash of the block.

+

- baseFeePerGas: ZeroPaddedHexNumber (fork: London)

+

Base fee per gas of the block.

+

- withdrawalsRoot: Hash (fork: Shanghai)

+

Root hash of the withdrawals trie.

+

- blobGasUsed: ZeroPaddedHexNumber (fork: Cancun)

+

Total blob gas used by all the transactions in the block.

+

- excessBlobGas: ZeroPaddedHexNumber (fork: Cancun)

+

Excess blob gas of the block used to calculate the blob fee per gas for this block.

+

- parentBeaconBlockRoot: Hash (fork: Cancun)

+

Root hash of the parent beacon block.

+

FixtureBlock

+

- rlp: Bytes

+

RLP serialized version of the block. Field is only optional when embedded in a InvalidFixtureBlock as the rlp_decoded field.

+

- blockHeader: FixtureHeader

+

Decoded block header fields included in the block RLP.

+

- blocknumber: Number

+

Block number.

+

- transactions: List[FixtureTransaction]

+

List of decoded transactions included in the block RLP.

+

- uncleHeaders: List[FixtureHeader]

+

List of uncle headers included in the block RLP. An empty list post merge.

+

- withdrawals: Optional[List[FixtureWithdrawal]] (fork: Shanghai)

+

Optional list of withdrawals included in the block RLP.

+

InvalidFixtureBlock

+

- expectException: TransactionException|BlockException

+

Expected exception that invalidates the block.

+

- rlp: Bytes

+

RLP serialized version of the block.

+

- rlp_decoded: Optional[FixtureBlock]

+

Decoded block attributes included in the block RLP.

+

FixtureTransaction

+

- type: ZeroPaddedHexNumber

+

Transaction type.

+

- chainId: ZeroPaddedHexNumber

+

Chain ID of the transaction.

+

- nonce: ZeroPaddedHexNumber

+

Nonce of the account that sends the transaction

+

- gasPrice: ZeroPaddedHexNumber

+

Gas price for the transaction (Transaction types 0 & 1)

+

- maxPriorityFeePerGas: HexNumber (fork: London)

+

Max priority fee per gas to pay (Transaction types 2 & 3)

+

- maxFeePerGas: HexNumber (fork: London)

+

Max base fee per gas to pay (Transaction types 2 & 3)

+

- gasLimit: ZeroPaddedHexNumber

+

Gas limit of the transaction

+

- to: Address| null

+

Destination address of the transaction, or null to create a contract

+

- value: ZeroPaddedHexNumber

+

Value of the transaction

+

- data: Bytes

+

Data bytes of the transaction

+

- accessList: List[Mapping[Address,List[Hash]]] (fork: Berlin)

+

Account access lists (Transaction types 1, 2 & 3)

+

- maxFeePerBlobGas: ZeroPaddedHexNumber (fork: Cancun)

+

Max fee per blob gas to pay (Transaction type 3)

+

- blobVersionedHashes: List[Hash] (fork: Cancun)

+

Max fee per blob gas to pay (Transaction type 3)

+

- v: ZeroPaddedHexNumber

+

V value of the transaction signature

+

- r: ZeroPaddedHexNumber

+

R value of the transaction signature

+

- s: ZeroPaddedHexNumber

+

S value of the transaction signature

+

- sender: Address

+

Sender address of the transaction

+

- secretKey: Hash

+

Private key that must be used to sign the transaction

+

FixtureWithdrawal

+

- index: ZeroPaddedHexNumber

+

Index of the withdrawal

+

- validatorIndex: ZeroPaddedHexNumber

+

Withdrawing validator index

+

- address: Address

+

Address to withdraw to

+

- amount: ZeroPaddedHexNumber

+

Amount of the withdrawal

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/blockchain_test_engine/index.html b/docs/public/main/blockchain_test_engine/index.html new file mode 100644 index 00000000000..15841369cd9 --- /dev/null +++ b/docs/public/main/blockchain_test_engine/index.html @@ -0,0 +1,1431 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

Blockchain Engine Tests

+

The Blockchain Engine Test fixture format tests are included in the fixtures subdirectory blockchain_tests_engine, and use Engine API directives instead of the usual BlockchainTest format.

+

These are produced by the StateTest and BlockchainTest test specs.

+

Description

+

The Blockchain Engine Test fixture format is used to test block validation and the consensus rules of the Ethereum blockchain, when a block is delivered through the Engine API as a engine_newPayloadVX directive.

+

It does so by defining a pre-execution state, a series of blocks as engine_newPayloadVX directives, and a post-execution state, verifying that, after all the blocks have been processed, appended if valid or rejected if invalid, the result is the expected post-execution state.

+

A single JSON fixture file is composed of a JSON object where each key-value pair is a different HiveFixture test object, with the key string representing the test name.

+

The JSON file path plus the test name are used as the unique test identifier.

+

Consumption

+

For each HiveFixture test object in the JSON fixture file, perform the following steps:

+
    +
  1. +

    Start a full node using:

    +
      +
    • network to configure the execution fork schedule according to the Fork type definition.
    • +
    • pre as the starting state allocation of the execution environment for the test and calculate the genesis state root.
    • +
    • genesisBlockHeader as the genesis block header.
    • +
    +
  2. +
  3. +

    Verify the head of the chain is the genesis block, and the state root matches the one calculated on step 1, otherwise fail the test.

    +
  4. +
  5. +

    For each FixtureEngineNewPayload in engineNewPayloads:

    +
      +
    1. Deliver the payload using the engine_newPayloadVX directive, using: + +
    2. +
    3. If errorCode is present: +
        +
      • Verify the directive returns an error, and the error code matches the one in errorCode, otherwise fail the test.
      • +
      • Proceed to the next payload.
      • +
      +
    4. +
    5. If valid is false, verify that the directive returns status field of PayloadStatusV1 as INVALID, otherwise fail the test.
    6. +
    7. If valid is true, verify that the directive returns status field of PayloadStatusV1 as VALID, otherwise fail the test.
    8. +
    +
  6. +
+

Structures

+

HiveFixture

+

- network: Fork

+
TO BE DEPRECATED
+

Fork configuration for the test.

+

This field is going to be replaced by the value contained in config.network.

+

- genesisBlockHeader: FixtureHeader

+

Genesis block header.

+

- engineNewPayloads: List[FixtureEngineNewPayload]

+

List of engine_newPayloadVX directives to be processed after the genesis block.

+

- engineFcuVersion: Number

+

Version of the engine_forkchoiceUpdatedVX directive to use to set the head of the chain.

+

- pre: Alloc

+

Starting account allocation for the test. State root calculated from this allocation must match the one in the genesis block.

+

- lastblockhash: Hash

+

Hash of the last valid block, or the genesis block hash if the list of blocks is empty, or contains a single invalid block.

+

- post: Alloc

+

Account allocation for verification after all the blocks have been processed.

+

- config: FixtureConfig

+

Chain configuration object to be applied to the client running the blockchain engine test.

+

FixtureConfig

+

- network: Fork

+

Fork configuration for the test. It is guaranteed that this field contains the same value as the root field network.

+

- blobSchedule: BlobSchedule

+

Optional; present from Cancun on. Maps forks to their blob schedule configurations as defined by EIP-7840.

+

FixtureEngineNewPayload

+

- executionPayload: FixtureExecutionPayload

+

Execution payload.

+

- blob_versioned_hashes: Optional[List[Hash]] (fork: Cancun)

+

List of hashes of the versioned blobs that are part of the execution payload. +They can mismatch the hashes of the versioned blobs in the execution payload, for negative-testing reasons.

+

- parentBeaconBlockRoot: Optional[Hash] (fork: Cancun)

+

Hash of the parent beacon block root.

+

- validationError: TransactionException|BlockException

+

Validation error expected when executing the payload.

+

When the payload is valid, this field is not present, and a VALID status is +expected in the status field of +PayloadStatusV1.

+

If this field is present, the status field of +PayloadStatusV1 +is expected to be INVALID.

+

- version: Number

+

Version of the engine_newPayloadVX directive to use to deliver the payload.

+

- errorCode: Optional[Number]

+

Error code to be returned by the engine_newPayloadVX directive.

+

FixtureExecutionPayload

+

- parentHash: Hash

+

Hash of the parent block.

+

- feeRecipient: Address

+

Address of the account that will receive the rewards for building the block.

+

- stateRoot: Hash

+

Root hash of the state trie.

+

- receiptsRoot: Hash

+

Root hash of the receipts trie.

+

- logsBloom: Bloom

+

Bloom filter composed of the logs of all the transactions in the block.

+

- blockNumber: HexNumber

+

Number of the block.

+

- gasLimit: HexNumber

+

Total gas limit of the block.

+

- gasUsed: HexNumber

+

Total gas used by all the transactions in the block.

+

- timestamp: HexNumber

+

Timestamp of the block.

+

- extraData: Bytes

+

Extra data of the block.

+

- prevRandao: Hash

+

PrevRandao of the block.

+

- blockHash: Hash

+

Hash of the block.

+

- transactions: List[Bytes]

+

List of transactions in the block, in serialized format.

+

- withdrawals: List[FixtureWithdrawal]

+

List of withdrawals in the block.

+

- baseFeePerGas: HexNumber (fork: London)

+

Base fee per gas of the block.

+

- blobGasUsed: HexNumber (fork: Cancun)

+

Total blob gas used by all the transactions in the block.

+

- excessBlobGas: HexNumber (fork: Cancun)

+

Excess blob gas of the block used to calculate the blob fee per gas for this block.

+

FixtureWithdrawal

+

- index: HexNumber

+

Index of the withdrawal

+

- validatorIndex: HexNumber

+

Withdrawing validator index

+

- address: Address

+

Address to withdraw to

+

- amount: HexNumber

+

Amount of the withdrawal

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/blockchain_test_engine_x/index.html b/docs/public/main/blockchain_test_engine_x/index.html new file mode 100644 index 00000000000..aa4b2ee2359 --- /dev/null +++ b/docs/public/main/blockchain_test_engine_x/index.html @@ -0,0 +1,1420 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

Blockchain Engine X Tests

+

The Blockchain Engine X Test fixture format tests are included in the fixtures subdirectory blockchain_tests_engine_x, and use Engine API directives with optimized pre-allocation groups for improved execution performance.

+

These are produced by the StateTest and BlockchainTest test specs when using the --generate-pre-alloc-groups and --use-pre-alloc-groups flags.

+

Description

+

The Blockchain Engine X Test fixture format is an optimized variant of the Blockchain Engine Test format designed for large-scale test execution with performance optimizations.

+

It uses the Engine API to test block validation and consensus rules while leveraging pre-allocation groups to significantly reduce test execution time and resource usage. Tests are grouped by their initial state (fork + environment + pre-allocation). Each group is executed against the same client instance using a common genesis state.

+

The key optimization is that clients need only be started once per group instead of once per test (as in the original engine fixture format), dramatically improving execution performance for large test suites.

+

Instead of including large pre-allocation state in each test fixture, this format references a pre-allocation groups folder (pre_alloc) which contains all different pre-allocation combinations organized by group.

+

A single JSON fixture file is composed of a JSON object where each key-value pair is a different BlockchainTestEngineXFixture test object, with the key string representing the test name.

+

The JSON file path plus the test name are used as the unique test identifier.

+

Pre-Allocation Groups Folder

+

The blockchain_tests_engine_x directory contains a special directory pre_alloc that stores pre-allocation group files used by all tests in this format, one per pre-allocation group with the name of the pre-alloc hash. This folder is essential for test execution and must be present alongside the test fixtures.

+

Pre-Allocation Group File Structure

+

Each file in the pre_alloc folder corresponds to a pre-allocation group identified by a hash:

+
{
+   "test_count": 88,
+   "pre_account_count": 174,
+   "testIds": ["test1", "test2", ...],
+   "network": "Prague",
+   "environment": { ... },
+   "pre": { ... }
+}
+

Pre-Allocation Group Fields

+
    +
  • test_count: Number of tests in this pre-allocation group
  • +
  • pre_account_count: Number of accounts in the pre-allocation group
  • +
  • testIds: Array of test identifiers that belong to this group
  • +
  • network: Fork name (e.g., “Prague”, “Cancun”)
  • +
  • environment: Complete Environment object with execution context
  • +
  • pre: Pre-allocation group Alloc object containing initial account states
  • +
+

Consumption

+

For each BlockchainTestEngineXFixture test object in the JSON fixture file, perform the following steps:

+
    +
  1. +

    Load Pre-Allocation Group:

    +
      +
    • Read the appropriate file from the pre_alloc folder in the same directory
    • +
    • Locate the pre-allocation group using preHash
    • +
    • Extract the pre allocation and environment from the group
    • +
    +
  2. +
  3. +

    Initialize Client:

    +
      +
    • Use network to configure the execution fork schedule
    • +
    • Use the pre-allocation group’s pre allocation as the starting state
    • +
    • Use the pre-allocation group’s environment as the execution context
    • +
    • Use genesisBlockHeader as the genesis block header
    • +
    +
  4. +
  5. +

    Execute Engine API Sequence:

    + +
  6. +
  7. +

    Verify Final State:

    +
      +
    • Compare the final chain head against lastblockhash
    • +
    • If postStateDiff is present: +
        +
      • Apply the state differences to the pre-allocation group
      • +
      • Verify the resulting state matches the client’s final state
      • +
      +
    • +
    • If post field were present (not typical), verify it directly
    • +
    +
  8. +
+

Structures

+

BlockchainTestEngineXFixture

+

- network: Fork

+
TO BE DEPRECATED
+

Fork configuration for the test.

+

This field is going to be replaced by the value contained in config.network.

+

- preHash: string

+

Hash identifier referencing a pre-allocation group in the pre_alloc folder. This hash uniquely identifies the combination of fork, environment, and pre-allocation state that defines the group.

+

- genesisBlockHeader: FixtureHeader

+

Genesis block header. The state root in this header must match the state root calculated from the pre-allocation group referenced by preHash.

+

- engineNewPayloads: List[FixtureEngineNewPayload]

+

List of engine_newPayloadVX directives to be processed after the genesis block. These define the sequence of blocks to be executed via the Engine API.

+

- syncPayload: Optional[FixtureEngineNewPayload]

+

Optional synchronization payload. When present, this payload is typically used to sync the chain to a specific state before or after the main payload sequence.

+

- lastblockhash: Hash

+

Hash of the last valid block after all payloads have been processed, or the genesis block hash if all payloads are invalid.

+

- postStateDiff: Optional[Alloc]

+

State differences from the pre-allocation group after test execution. This optimization stores only the accounts that changed, were created, or were deleted during test execution, rather than the complete final state.

+

To reconstruct the final state:

+
    +
  1. Start with the pre-allocation group from the pre_alloc folder
  2. +
  3. Apply the changes in postStateDiff: +
      +
    • Modified accounts: Replace existing accounts with new values
    • +
    • New accounts: Add accounts not present in pre-allocation
    • +
    • Deleted accounts: Remove accounts (represented as null values)
    • +
    +
  4. +
+

- config: FixtureConfig

+

Chain configuration object to be applied to the client running the blockchain engine x test.

+

FixtureConfig

+

- network: Fork

+

Fork configuration for the test. It is guaranteed that this field contains the same value as the root field network.

+

- blobSchedule: BlobSchedule

+

Optional; present from Cancun on. Maps forks to their blob schedule configurations as defined by EIP-7840.

+

FixtureEngineNewPayload

+

Engine API payload structure identical to the one defined in Blockchain Engine Tests. Includes execution payload, versioned hashes, parent beacon block root, validation errors, version, and error codes.

+

Usage Notes

+
    +
  • This format is only generated when using --generate-pre-alloc-groups and --use-pre-alloc-groups flags
  • +
  • The pre_alloc folder is essential and must be distributed with the test fixtures
  • +
  • Tests are grouped by identical (fork + environment + pre-allocation) combinations
  • +
  • The format is optimized for Engine API testing (post-Paris forks)
  • +
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/cache/index.html b/docs/public/main/cache/index.html new file mode 100644 index 00000000000..49cdeb7a4c3 --- /dev/null +++ b/docs/public/main/cache/index.html @@ -0,0 +1,1370 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

Consume Cache and Fixture Inputs

+

The consume cache command can be used to resolve, download and cache fixture releases:

+
consume cache --input=stable@v4.5.0
+

All consume subcommands have an --input argument, which implements the same functionality as consume cache to download and cache fixtures, respectively obtain downloaded fixtures from the cache.

+

Example: Two-liner to Download the Latest Fixture Release

+

Releases can be downloaded using EEST tooling without (manually) cloning and installing the @ethereum/execution-spec-tests tools as following:

+
    +
  1. +

    Install uv (a fast, rust-based Python package manager):

    +
    curl -LsSf https://astral.sh/uv/install.sh | sh
    +
  2. +
  3. +

    Run EEST’s consume cache command via uv and request the latest “stable” fixture release:

    +
    uvx --from git+https://github.com/ethereum/execution-spec-tests \
    +    consume cache --input=stable@latest
    +

    Expected output, as of v4.5.0:

    +
    Updated https://github.com/ethereum/execution-spec-tests (8c3cbd7a4eef3967abd78db32ee45ef8f7cf8271)
    +Updated https://github.com/petertdavies/ethereum-spec-evm-resolver (623ac4565025e72b65f45b926da2a3552041b469)
    +Built ethereum-execution-spec-tests @ git+https://github.com/ethereum/execution-spec-tests@8c3cbd7a4eef3967abd78db32ee45ef8f7cf8271
    +
    +Installed 69 packages in 10ms
    +Exit: Fixtures downloaded and cached.
    +Path: /home/dtopz/.cache/ethereum-execution-spec-tests/cached_downloads/ethereum/execution-spec-tests/v4.5.0/fixtures_stable/fixtures
    +Input: https://github.com/ethereum/execution-spec-tests/releases/download/v4.5.0/fixtures_stable.tar.gz
    +Release page: https://github.com/ethereum/execution-spec-tests/releases/tag/v4.5.0
    +

    Note: Use direct URLs to avoid GitHub API calls (better for CI environments). Version specifiers like stable@latest will always use the GitHub API to resolve versions. More details on the arguments to --input are provided below.

    +

    Explanation: uv creates a local Python virtual environment in ~/.cache/uv/, installs EEST and executes the consume cache command to resolve and download the release, which gets cached at ~/.cache/ethereum-execution-spec-tests. Subsequent commands will use the cached version of the fixtures.

    +
  4. +
+

The --input Flag to Specify Fixtures

+

All consume sub-commands take an --input=<fixture_path>|<release_spec>|<url> flag to specify which fixtures should be used for the command, <fixtures> may be:

+
    +
  1. A local directory: Fixtures from your local file system.
  2. +
  3. A release specification: An EEST release tag or “release specification” stable@latest, fusaka-devnet-1@v1.0.0, etc.
  4. +
  5. A URLs: A full URL to a custom hosted release or a Github release.
  6. +
+

Release Specifications

+

A release specification has the format <release_name>@<version>.

+

Supported release names:

+
    +
  • stable: Latest stable fork release.
  • +
  • develop: Latest development fork release.
  • +
  • Custom release names: e.g., pectra-devnet-4, eip7692.
  • +
+

Supported version formats:

+
    +
  • latest: Most recent release for the specified name.
  • +
  • v1.2.3: Specific semantic version.
  • +
+

Examples

+

Examples using a release specification:

+
# Latest standard, full stable release (all forks up to and including the latest deployed mainnet fork)
+uv run consume engine --input stable@latest
+
+# Latest standard, full development release (all forks up to and including the latest development fork)
+uv run consume rlp --input develop@latest
+
+# Standard, full releases by tag
+uv run consume engine --input stable@v4.1.0
+uv run consume rlp --input develop@v4.2.1
+
+# Pre-release tags
+uv run consume cache --input pectra-devnet-6@v1.0.0
+uv run consume direct --input eip7692@latest --bin ../go-ethereum/build/bin/evm
+

Examples using a URL, the target must be a .tar.gz:

+
# GitHub release URL
+uv run consume engine --input https://github.com/ethereum/execution-spec-tests/releases/download/v4.1.0/fixtures_develop.tar.gz
+
+# Direct archive URL
+uv run consume rlp --input https://example.com/custom-fixtures.tar.gz
+

Caching System

+

Automatic Caching

+

All remote fixture sources are automatically cached to avoid repeated downloads:

+

Default cache location:

+
~/.cache/ethereum-execution-spec-tests/cached_downloads/
+

You can override this location with the --cache-folder flag:

+
uv run consume cache --input stable@latest --cache-folder /path/to/custom/cache
+

Cache structure:

+
❯ tree ~/.cache/ethereum-execution-spec-tests/ -L 5
+/home/dtopz/.cache/ethereum-execution-spec-tests/
+β”œβ”€β”€ cached_downloads
+β”‚Β Β  β”œβ”€β”€ ethereum
+β”‚Β Β  β”‚Β Β  └── execution-spec-tests
+β”‚Β Β  β”‚Β Β      β”œβ”€β”€ pectra-devnet-5%40v1.0.0
+β”‚Β Β  β”‚Β Β      β”‚Β Β  └── fixtures_pectra-devnet-5
+β”‚Β Β  β”‚Β Β      β”œβ”€β”€ pectra-devnet-6%40v1.0.0
+β”‚Β Β  β”‚Β Β      β”‚Β Β  └── fixtures_pectra-devnet-6
+β”‚Β Β  β”‚Β Β      β”œβ”€β”€ v4.0.0
+β”‚Β Β  β”‚Β Β      β”‚Β Β  └── fixtures_develop
+β”‚Β Β  β”‚Β Β      β”œβ”€β”€ v4.1.0
+β”‚Β Β  β”‚Β Β      β”‚Β Β  └── fixtures_develop
+β”‚Β Β  β”‚Β Β      β”œβ”€β”€ v4.2.0
+β”‚Β Β  β”‚Β Β      β”‚Β Β  β”œβ”€β”€ fixtures_develop
+β”‚Β Β  β”‚Β Β      β”‚Β Β  β”œβ”€β”€ fixtures_eip7692
+β”‚Β Β  β”‚Β Β      β”‚Β Β  └── fixtures_stable
+β”‚Β Β  β”‚Β Β      β”œβ”€β”€ v4.3.0
+β”‚Β Β  β”‚Β Β      β”‚Β Β  └── fixtures_develop
+β”‚Β Β  β”‚Β Β      └── v4.5.0
+β”‚Β Β  β”‚Β Β          └── fixtures_stable
+β”‚Β Β  └── other
+└── release_information.json
+

The Fixture Index File

+

The fill command generates a JSON file <fixture_path>/.meta/index.json that indexes the fixtures its generated. This index file is used by consume commands to allow fast collection of test subsets specified on the command-line, for example, via the --sim.limit flag. For help with --sim.limit when running ./hive, see Hive Common Options, for an overview of other available test selection flags when running consume directly, see Useful Pytest Options.

+

CI-Friendly Behavior for Direct URLs

+

When using direct GitHub release URLs (instead of version specifiers), the consume command automatically avoids unnecessary GitHub API calls to prevent rate limiting in CI environments:

+
consume cache --input=https://github.com/ethereum/execution-spec-tests/releases/download/v4.5.0/fixtures_stable.tar.gz
+

API Call Behavior:

+
    +
  • βœ… Direct URLs: No API calls made, cleaner output (no “Release page:” line).
  • +
  • ℹ️ Version specifiers: API calls required to resolve versions, includes release page info.
  • +
+

Examples:

+
# No API calls - direct download
+consume cache --input=https://github.com/ethereum/execution-spec-tests/releases/download/v4.5.0/fixtures_stable.tar.gz
+
+# API calls required - version resolution  
+consume cache --input=stable@latest
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/changelog/index.html b/docs/public/main/changelog/index.html new file mode 100644 index 00000000000..2bfcfce672b --- /dev/null +++ b/docs/public/main/changelog/index.html @@ -0,0 +1,2484 @@ + + + + + + + Changelog - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

Changelog

+
+ +
+

Test fixtures for use by clients are available for each release on the Github releases page.

+

Key: ✨ = New, 🐞 = Fixed, πŸ”€ = Changed. πŸ’₯ = Breaking

+

πŸ”œ [Unreleased]

+

πŸ’₯ Breaking Changes

+
    +
  • Python 3.10 support was removed in this release (#1808).
  • +
+

πŸ’₯ Important Change for test contributors

+
    +
  • EEST no longer allows usage of Yul code in Python tests. From now on, please make use of our opcode wrapper. Yul code is now only allowed in the “static tests” located in ./tests/static/ (these are test cases defined by JSON and YAML files instead of Python test functions that were originally maintained in ethereum/tests).
  • +
  • In order to fill the static tests (which is not the case by default), please ensure that solc is located in your PATH.
  • +
+

πŸ’₯ Important Change for fill Users

+

The output behavior of fill has changed (#1608):

+
    +
  • Before: fill wrote fixtures into the directory specified by the --output flag (default: fixtures). This could have many unintended consequences, including unexpected errors if old or invalid fixtures existed in the directory (for details see #1030).
  • +
  • Now: fill will exit without filling any tests if the specified directory exists and is not-empty. This may be overridden by adding the --clean flag, which will first remove the specified directory.
  • +
+

Feature zkevm updated to benchmark

+

Due to the crossover between zkevm and benchmark tests, all instances of the former have been replaced with the latter nomenclature. Repository PR labels and titles are additionally updated to reflect this change.

+

This update renames the zkevm feature release to benchmark_30M and further expands the latter for 1M, 10M, 60M, 90M, and 120M block gas limits in fixtures_benchmark_1M.tar.gz, fixtures_benchmark_10M.tar.gz, fixtures_benchmark_30M.tar.gz, fixtures_benchmark_60M.tar.gz, fixtures_benchmark_90M.tar.gz, and fixtures_benchmark_120M.tar.gz respectively.

+

Users can select any of the artifacts depending on their testing needs for their provers.

+

πŸ› οΈ Framework

+

πŸ”€ Refactoring

+
    +
  • πŸ”€ Move TransactionType enum from test file to proper module location in ethereum_test_types.transaction_types for better code organization and reusability.
  • +
  • ✨ Opcode classes now validate keyword arguments and raise ValueError with clear error messages.
  • +
  • πŸ”€ This PR removes the solc requirement to fill Python test cases. Regular test contributors no longer need to concern themselves with solc and, as such, the solc-select dependency has been removed. The remaining tests that used Yul have been ported to the EEST opcode wrapper mini-lang and the use of Yul in Python tests is no longer supported. Maintainers only: To fill the “static” JSON and YAML tests (./tests/static/) locally, solc (ideally v0.8.24) must be available in your PATH.
  • +
+

fill

+
    +
  • ✨ Add the ported_from test marker to track Python test cases that were converted from static fillers in ethereum/tests repository (#1590).
  • +
  • ✨ Add a new pytest plugin, ported_tests, that lists the static fillers and PRs from ported_from markers for use in the coverage Github Workflow (#1634).
  • +
  • ✨ Enable two-phase filling of fixtures with pre-allocation groups and add a BlockchainEngineXFixture format (#1706, #1760).
  • +
  • πŸ”€ Refactor: Encapsulate fill’s fixture output options (--output, --flat-output, --single-fixture-per-file) into a FixtureOutput class (#1471,#1612).
  • +
  • ✨ Don’t warn about a “high Transaction gas_limit” for zkevm tests (#1598).
  • +
  • 🐞 fill no longer writes generated fixtures into an existing, non-empty output directory; it must now be empty or --clean must be used to delete it first (#1608).
  • +
  • 🐞 zkevm marked tests have been removed from tests-deployed tox environment into its own separate workflow tests-deployed-zkevm and are filled by evmone-t8n (#1617).
  • +
  • ✨ Field postStateHash is now added to all blockchain_test and blockchain_test_engine tests that use exclude_full_post_state_in_output in place of postState. Fixes evmone-blockchaintest test consumption and indirectly fixes coverage runs for these tests (#1667).
  • +
  • πŸ”€ Changed INVALID_DEPOSIT_EVENT_LAYOUT to a BlockException instead of a TransactionException (#1773).
  • +
+

consume

+
    +
  • 🐞 Fix consume cache --cache-folder parameter being ignored, now properly caches fixtures in the specified directory instead of always using the default system cache location.
  • +
  • πŸ”€ consume now automatically avoids GitHub API calls when using direct release URLs (better for CI environments), while release specifiers like stable@latest continue to use the API for version resolution (#1788).
  • +
  • πŸ”€ Refactor consume simulator architecture to use explicit pytest plugin structure with forward-looking architecture (#1801).
  • +
  • πŸ”€ Add exponential retry logic to initial fcu within consume engine (#1815).
  • +
+

execute

+
    +
  • ✨ Added new Blob class which can use the ckzg library to generate valid blobs at runtime (#1614).
  • +
  • ✨ Added blob_transaction_test execute test spec, which allows tests that send blob transactions to a running client and verifying its engine_getBlobsVX endpoint behavior (#1644).
  • +
+

πŸ“‹ Misc

+
    +
  • πŸ”€ Use only relative imports in tests/ directory (#1848).
  • +
  • πŸ”€ Misc. doc updates, including a navigation footer (#1846).
  • +
  • πŸ”€ Remove Python 3.10 support (#1808).
  • +
  • πŸ”€ Modernize codebase with Python 3.11 language features (#1812).
  • +
  • ✨ Add changelog formatting validation to CI to ensure consistent punctuation in bullet points #1691.
  • +
  • ✨ Added the EIP checklist template that serves as a reference to achieve better coverage when implementing tests for new EIPs (#1327).
  • +
  • ✨ Added Post-Mortems of Missed Test Scenarios to the documentation that serves as a reference list of all cases that were missed during the test implementation phase of a new EIP, and includes the steps taken in order to prevent similar test cases to be missed in the future (#1327).
  • +
  • ✨ Add documentation “Running Tests” that explains the different methods available to run EEST tests and reference guides for running consume and hive: (#1172).
  • +
  • ✨ Added a new eest sub-command, eest info, to easily print a cloned EEST repository’s version and the versions of relevant tools, e.g., python, uv (#1621).
  • +
  • ✨ Add CONTRIBUTING.md for execution-spec-tests and improve coding standards documentation (#1604).
  • +
  • ✨ Add CLAUDE.md to help working in @ethereum/execution-spec-tests with Claude Code (#1749).
  • +
  • ✨ Use codespell instead of pyspelling to spell-check python and markdown sources (#1715).
  • +
  • πŸ”€ Updated from pytest 7 to pytest 8, benefits include improved type hinting and hook typing, stricter mark handling, and clearer error messages for plugin and metadata development (#1433).
  • +
  • 🐞 Fix bug in ported-from plugin and coverage script that made PRs fail with modified tests that contained no ported tests (#1661).
  • +
  • πŸ”€ Refactor the click-based CLI interface used for pytest-based commands (fill, execute, consume) to make them more extensible (#1654).
  • +
  • πŸ”€ Split src/ethereum_test_types/types.py into several files to improve code organization (#1665).
  • +
  • ✨ Added extract_config command to extract genesis files used to launch clients in hive (#1740).
  • +
  • ✨ Added automatic checklist generation for every EIP inside of the tests folder. The checklist is appended to each EIP in the documentation in the “Test Case Reference” section (#1679, #1718).
  • +
  • πŸ”€ Add macOS hive development mode workaround to the docs #1786.
  • +
  • πŸ”€ Refactor and clean up of exceptions including EOF exceptions within client specific mappers #1803.
  • +
  • πŸ”€ Rename tests/zkevm/ to tests/benchmark/ and replace the zkevm pytest mark with benchmark #1804.
  • +
  • πŸ”€ Add fixture comparison check to optimize coverage workflow in CI (#1833).
  • +
  • πŸ”€ Move TransactionType enum from test file to proper module location in ethereum_test_types.transaction_types for better code organization and reusability (#1763).
  • +
  • ✨ Opcode classes now validate keyword arguments and raise ValueError with clear error messages (#1739, #1856).
  • +
+

πŸ§ͺ Test Cases

+
    +
  • πŸ”€ Refactored BLOBHASH opcode context tests to use the pre_alloc plugin in order to avoid contract and EOA address collisions (#1637).
  • +
  • πŸ”€ Refactored SELFDESTRUCT opcode collision tests to use the pre_alloc plugin in order to avoid contract and EOA address collisions (#1643).
  • +
  • ✨ EIP-7594: Sanity test cases to send blob transactions and verify engine_getBlobsVX using the execute command (#1644).
  • +
  • πŸ”€ Refactored EIP-145 static tests into python (#1683).
  • +
  • ✨ EIP-7823, EIP-7883: Add test cases for ModExp precompile gas-cost updates and input limits on Osaka (#1579, #1729).
  • +
  • ✨ EIP-7825: Add test cases for the transaction gas limit of 30M gas (#1711).
  • +
  • ✨ EIP-7951: add test cases for P256VERIFY precompile to support secp256r1 curve #1670.
  • +
  • ✨ Introduce blockchain tests for benchmark to cover the scenario of pure ether transfers #1742.
  • +
  • ✨ EIP-7934: Add test cases for the block RLP max limit of 10MiB (#1730).
  • +
  • ✨ EIP-7939 Add count leading zeros (CLZ) opcode tests for Osaka (#1733).
  • +
  • ✨ EIP-7918: Blob base fee bounded by execution cost test cases (initial), includes some adjustments to EIP-4844 tests (#1685).
  • +
+
+
+

v4.5.0 - 2025-05-14

+

πŸ’₯ Breaking Change

+

EOF removed from Osaka

+

Following “Interop Testing Call 34” and the procedural EIPs PR the decision to remove EOF from Osaka was made.

+

To accommodate EOF testing for the interim within EEST, its tests have migrated to a new tests/unscheduled folder. This folder will now contain tests for features that are not yet CFI’d in any fork. When EOF is CFI’d for a fork in the future, all tests will be moved from unscheduled to the respective future fork folder.

+

A new fork EOFv1 has additionally been created to fill and consume EOF related fixtures. Client tests fillers such as evmone (and client consumers) will now need to use this fork name.

+

πŸ› οΈ Framework

+
    +
  • ✨ Add an empty account function for usage within fill and execute (#1482).
  • +
  • ✨ Added TransactionException.INTRINSIC_GAS_BELOW_FLOOR_GAS_COST exception to specifically catch the case where the intrinsic gas cost is insufficient due to the data floor gas cost (#1582).
  • +
+

πŸ“‹ Misc

+
    +
  • ✨ Engine API updates for Osaka, add get_blobs rpc method (#1510).
  • +
  • ✨ The EIP Version checker has been moved from fill and execute to it’s own command-line tool check_eip_versions that gets ran daily as a Github Action (#1537).
  • +
  • πŸ”€ Add new tests/unscheduled folder, move EOF from Osaka to unscheduled, add EOFv1 fork name for EOF tests (#1507).
  • +
  • ✨ CI features now contain an optional field to skip them from EEST full releases, benchmark and EOF features are now feature only (#1596).
  • +
  • 🐞 Don’t attempt to install solc via solc-select on ARM (official Linux ARM builds of solc are not available at the time of writing, cf ethereum/solidity#11351) and add a version sanity check (#1556).
  • +
+

πŸ§ͺ Test Cases

+
    +
  • πŸ”€ Automatically apply the benchmark marker to all tests under ./tests/benchmark/ and ./tests/prague/eip2537_bls_12_381_precompiles/ via conftest configuration (#1534).
  • +
  • ✨ Port calldataload and calldatasize tests (#1236).
  • +
+
+
+

v4.4.0 - 2025-04-29

+

πŸ’₯ Breaking Change

+

fixtures_static

+

A new fixture tarball has been included in this release: fixtures_static.tar.gz.

+

This tarball contains all tests inside of ./tests/static, which at this point only contains all tests copied from GeneralStateTests in ethereum/tests@7dc757ec132e372b6178a016b91f4c639f366c02.

+

The tests have been filled using the new static test filler introduced in #1336, and enhanced in #1362 and #1439.

+

Users can expect that all tests currently living in ethereum/tests should eventually make its way into ./tests/static and can rely that these tests, filled for new forks even, will be included in fixtures_static.tar.gz.

+

fixtures_benchmark

+

Another new fixture tarball has been included in this release: fixtures_benchmark.tar.gz.

+

Includes tests that are tailored specifically to test the execution layer proof generators.

+

πŸ› οΈ Framework

+

fill

+
    +
  • 🐞 Fix the reported fixture source URLs for the case of auto-generated tests (#1488).
  • +
+

consume

+
    +
  • 🐞 Fix the Hive commands used to reproduce test executions that are displayed in test descriptions in the Hive UI (#1494).
  • +
  • 🐞 Fix consume direct fails for geth blockchain tests (#1502).
  • +
+

πŸ“‹ Misc

+

πŸ§ͺ Test Cases

+ +
+
+

v4.3.0 - 2025-04-18

+

πŸ’₯ Breaking Change

+

Consume engine strict exception checking

+

consume engine now checks exceptions returned by the execution clients in their Engine API responses, specifically in the validationErrorfield of the engine_newPayloadVX method.

+

While not strictly a breaking change since tests will continue to run normally, failures are expected if a client modifies their exception messages.

+

This feature can be disabled by using --disable-strict-exception-matching for specific clients or forks.

+

πŸ› οΈ Framework

+

fill

+
    +
  • ✨ The static_filler plug-in now has support for static state tests (from GeneralStateTests) (#1362).
  • +
  • ✨ Introduce pytest.mark.exception_test to mark tests that contain an invalid transaction or block (#1436).
  • +
  • 🐞 Fix DeprecationWarning: Pickle, copy, and deepcopy support will be removed from itertools in Python 3.14. by avoiding use itertools object in the spec BaseTest pydantic model (#1414).
  • +
  • ✨ An optional configuration flag to override the maximum gas limit in the environment for filling or executing tests is now available. The --block-gas-limit flag overrides the default block gas limit during filling. The --transaction-gas-limit flag overrides the maximum for transactions during execution. (#1470).
  • +
+

consume

+
    +
  • 🐞 Fix fixture tarball downloading with regular, non-Github release URLS and with numerical versions in regular release specs, e.g., stable@v4.2.0 (#1437).
  • +
  • ✨ consume engine now has strict exception mapping enabled by default (#1416).
  • +
+

Tools

+
    +
  • πŸ”€ generate_system_contract_deploy_test test generator has been updated to handle system contracts that are not allowed to be absent when the fork happens (#1394).
  • +
  • ✨ Add generate_system_contract_error_test to generate tests on system contracts that invalidate a block in case of error (#1394).
  • +
+

Exceptions

+
    +
  • ✨ BlockException.SYSTEM_CONTRACT_EMPTY: Raised when a required system contract was not found in the state by the time it was due to execution with a system transaction call (#1394).
  • +
  • ✨ BlockException.SYSTEM_CONTRACT_CALL_FAILED: Raised when a system contract call made by a system transaction fails (#1394).
  • +
  • ✨ BlockException.INVALID_BLOCK_HASH: Raised when the calculated block hash does not match the expectation (Currently only during Engine API calls) (#1416).
  • +
  • ✨ BlockException.INVALID_VERSIONED_HASHES: Raised when a discrepancy is found between versioned hashes in the payload and the ones found in the transactions (#1416).
  • +
+

πŸ§ͺ Test Cases

+
    +
  • ✨ EIP-7702: Test precompile case in same transaction as delegation without extra gas in case of precompile code execution; parametrize all call opcodes in existing precompile test (#1431).
  • +
  • ✨ EIP-7702: Add invalid nonce authorizations tests for the case of multiple signers when the sender’s nonce gets increased (#1441).
  • +
  • ✨ EIP-7702: Add a test that verifies that set code transactions are correctly rejected before Prague activation (#1463).
  • +
  • ✨ EIP-7623: Additionally parametrize transaction validity tests with the to set to an EOA account (previously only contracts) (#1422).
  • +
  • ✨ EIP-7251: Add EIP-7251 test cases for modified consolidations contract that allows more consolidations (#1465).
  • +
  • ✨ EIP-6110: Add extra deposit request edge cases, sending eth to the deposit contract while sending a deposit request (#1467).
  • +
  • ✨ EIP-6110: Add cases for deposit log layout and other topics (ERC-20) transfer (#1371).
  • +
  • ✨ EIP-7251: Remove pytest skips for consolidation request cases (#1449).
  • +
  • ✨ EIP-7002, EIP-7251: Add cases to verify behavior of contracts missing at fork (#1394).
  • +
  • ✨ EIP-7002, EIP-7251: Add cases to verify behavior of system contract errors invalidating a block (#1394).
  • +
  • πŸ”€ Remove EIP-7698: EIP has been removed and the tests related to it have also been removed, while preserving a subset of the tests to verify that functionality is removed in clients (#1451).
  • +
+

πŸ“‹ Misc

+ +
+
+

v4.2.0 - 2025-04-08

+

Note: Although not a breaking change, consume users should delete the cache directory (typically located at ~/.cache/ethereum-execution-spec-tests) used to store downloaded fixture release tarballs. This release adds support for ethereum/tests and ethereum/legacytests fixture release downloads and the structure of the cache directory has been updated to accommodate this change.

+

To try this feature:

+
consume direct --input=https://github.com/ethereum/tests/releases/download/v17.0/fixtures_blockchain_tests.tgz
+

To determine the cache directory location, see the --cache-folder entry from the command:

+
consume cache --help
+

πŸ’₯ Breaking Change

+

πŸ› οΈ Framework

+

consume

+
    +
  • ✨ Add support for ethereum/tests and ethereum/legacytests release tarball download via URL to the --input flag of consume commands (#1306).
  • +
  • ✨ Add support for Nethermind’s nethtest command to consume direct (#1250).
  • +
  • ✨ Allow filtering of test cases by fork via pytest marks (e.g., -m "Cancun or Prague") (#1304, #1318).
  • +
  • ✨ Allow filtering of test cases by fixture format via pytest marks (e.g., -m blockchain_test) (#1314).
  • +
  • ✨ Add top-level entries forks and fixture_formats to the index file that list all the forks and fixture formats used in the indexed fixtures (#1318).
  • +
  • ✨ Enable logging from consume commands (#1361).
  • +
  • ✨ Propagate stdout and stderr (including logs) captured during test execution to the Hive test result (#1361).
  • +
  • 🐞 Don’t parametrize tests for unsupported fixture formats; improve consume test collection (#1315).
  • +
  • 🐞 Fix the the hive command printed in test reports to reproduce tests in isolation by prefixing the --sim.limit flag value with id: (#1333).
  • +
  • 🐞 Improve index generation of ethereum/tests fixtures: Allow generation at any directory level and include generatedTestHash in the index file for the fixture_hash (#1303).
  • +
  • 🐞 Fix loading of ethereum/tests and ethereum/legacytests fixtures for the case of mixed 0x0 and 0x1 transaction types in multi-index (data, gas, value) state test fixtures (#1330).
  • +
  • ✨ Add Osaka to the hive ruleset, includes a small ruleset refactor (#1355).
  • +
+

fill

+
    +
  • 🐞 Fix --fork/from/until for transition forks when using fill #1311.
  • +
  • 🐞 Fix the node id for state tests marked by transition forks (#1313).
  • +
  • ✨ Add static_filler plug-in which allows to fill static YAML and JSON tests (from ethereum/tests) by adding flag --fill-static-tests to uv run fill (#1336).
  • +
+

execute

+
    +
  • πŸ”€ Test IDs have changed to include the name of the test spec where the test came from (e.g. state_test, blockchain_test, etc) (#1367).
  • +
  • ✨ Markers can now be used to execute only tests from a specific test spec type (e.g. -m state_test, -m blockchain_test, etc) (#1367).
  • +
+

πŸ“‹ Misc

+
    +
  • πŸ”€ Bump the version of execution-specs used by the framework to the package ethereum-execution==1.17.0rc6.dev1; bump the version used for test fixture generation for forks < Prague to current execution-specs master, fa847a0 (#1310).
  • +
  • 🐞 Init TransitionTool in GethTransitionTool (#1276).
  • +
  • πŸ”€ Refactored RLP encoding of test objects to allow automatic generation of tests (#1359).
  • +
  • ✨ Document how to manage execution-spec-tests package dependencies (#1388).
  • +
+

Packaging

+
    +
  • 🐞 Fix eest make test when ethereum-execution-spec-tests is installed as a package (#1342).
  • +
  • πŸ”€ Pin setuptools and wheel in [build-system], bump trie>=3.1 and remove setuptools from package dependencies (#1345, #1351).
  • +
+

πŸ§ͺ Test Cases

+
    +
  • ✨ Add additional test coverage for EIP-152 Blake2 precompiles (#1244). Refactor to add variables for spec constants and common fixture code. (#1395), (#1405).
  • +
  • ✨ Add EIP-7702 incorrect-rlp-encoding tests (#1347).
  • +
  • ✨ Add EIP-2935 tests for all call opcodes (#1379).
  • +
  • ✨ Add more tests for EIP-7702: max-fee-per-gas verification, delegation-designation as initcode tests (#1372).
  • +
  • ✨ Add converted Identity precompile tests (#1344).
  • +
+
+
+

v4.1.0 - 2025-03-11

+

πŸ’₯ Breaking Changes

+

The following changes may be potentially breaking (all clients were tested with these changes with the state test format, but not the blockchain test format):

+
    +
  • πŸ’₯ Add a yParity field (that duplicates v) to transaction authorization tuples in fixture formats to have fields that conform to EIP-7702 spec, resolves erigontech/erigon#14073 (#1286).
  • +
  • πŸ’₯ Rename the recently introduced _info field fixture_format to fixture-format for consistency #1295.
  • +
+

πŸ› οΈ Framework

+
    +
  • πŸ”€ Make BaseFixture able to parse any fixture format such as BlockchainFixture (#1210).
  • +
  • ✨ Blockchain and Blockchain-Engine tests now have a marker to specify that they were generated from a state test, which can be used with -m blockchain_test_from_state_test and -m blockchain_test_engine_from_state_test respectively (#1220).
  • +
  • ✨ Blockchain and Blockchain-Engine tests that were generated from a state test now have blockchain_test_from_state_test or blockchain_test_engine_from_state_test as part of their test IDs (#1220).
  • +
  • πŸ”€ Refactor ethereum_test_fixtures and ethereum_clis to create FixtureConsumer and FixtureConsumerTool classes which abstract away the consumption process used by consume direct (#935).
  • +
  • ✨ Allow consume direct --collect-only without specifying a fixture consumer binary on the command-line (#1237).
  • +
  • ✨ Allow fill --collect-only without the need for existence of the folder ./fixtures.
  • +
  • ✨ Report the (resolved) fixture tarball URL and local fixture cache directory when consume’s --input flag is a release spec or URL (#1239).
  • +
  • ✨ EOF Container validation tests (eof_test) now generate container deployment state tests, by wrapping the EOF container in an init-container and sending a deploy transaction (#783, #1233).
  • +
  • ✨ Use regexes for Hive’s --sim.limit argument and don’t use xdist if --sim.parallelism==1 in the eest/consume-rlp and eest/consume-rlp simulators (#1220).
  • +
  • 🐞 Register generated test markers, e.g., blockchain_test_from_state_test, to prevent test session warnings (#1238, #1245).
  • +
  • 🐞 Zero-pad Environment fields passed to t8n tools as required by evmone-t8n (#1268).
  • +
+

πŸ“‹ Misc

+
    +
  • ✨ Add a guide to the docs for porting tests from ethereum/tests to EEST (#1165).
  • +
  • ✨ Improve the uv run eest make test interactive CLI to enable creation of new test modules within existing test sub-folders (#1241).
  • +
  • ✨ Update mypy to latest release >=1.15.0,<1.16 (#1209).
  • +
  • 🐞 Bug fix for filling with EELS for certain Python versions due to an issue with CPython (#1231).
  • +
  • 🐞 Fix HTML site deployment due to the site’s index file exceeding Github’s max file size limit (#1292).
  • +
  • ✨ Update the build fixtures workflow to use multiple self-hosted runners, remove pectra-devnet-6 feature build (#1296).
  • +
+

πŸ§ͺ Test Cases

+
    +
  • ✨ Add gas cost of delegation access in CALL opcode (#1208).
  • +
  • ✨ Add EIP-7698 failed nonce and short data tests (#1211).
  • +
  • ✨ Add EIP-2537 additional pairing precompile tests cases, and then update all BLS12 test vectors (#1275, #1289).
  • +
  • ✨ Add EIP-7685 and EIP-7002 test cases for additional request type combinations and modified withdrawal contract that allows more withdrawals (#1340).
  • +
  • ✨ Add test cases for EIP-152 Blake2 and Identity precompiles (#1244).
  • +
+
+
+

v4.0.0 - 2025-02-14 - πŸ’•

+

πŸ“ Fixture Releases

+
    +
  • πŸ”€ Initially we moved old fork configured tests within stable and develop fixture releases to a separate legacy release (#788).
  • +
  • πŸ”€ This was later reverted after some client teams preferred to keep them in all in the same releases (#1053).
  • +
+

πŸ’₯ Breaking Change

+
    +
  • ✨ Use uv for package management replacing pip (#777).
  • +
  • ✨ Ruff now replaces Flake8, Isort and Black resulting in significant changes to the entire code base including its usage (#922).
  • +
  • πŸ”€ Fill test fixtures using EELS by default. EEST now uses the ethereum-specs-evm-resolver with the EELS daemon (#792).
  • +
  • πŸ”€ The EOF fixture format contained in eof_tests may now contain multiple exceptions in the "exception" field in the form of a pipe (|) separated string (#759).
  • +
  • πŸ”€ state_test, blockchain_test and blockchain_test_engine fixtures now contain a config field, which contains an object that contains a blobSchedule field. On the blockchain_test and blockchain_test_engine fixtures, the object also contains a duplicate of the network root field. The root’s network field will be eventually deprecated (#1040).
  • +
  • πŸ”€ latest-stable-release and latest-develop-release keywords for the --input flag in consume commands have been replaced with stable@latest and develop@latest respectively (#1044).
  • +
+

πŸ› οΈ Framework

+
    +
  • ✨ Execute command added to run existing tests in live networks (#).
  • +
  • 🐞 Fixed consume hive commands from spawning different hive test suites during the same test execution when using xdist (#712).
  • +
  • ✨ consume hive command is now available to run all types of hive tests (#712).
  • +
  • ✨ Generated fixtures now contain the test index index.json by default (#716).
  • +
  • ✨ A metadata folder .meta/ now stores all fixture metadata files by default (#721).
  • +
  • 🐞 Fixed fill command index generation issue due to concurrency (#725).
  • +
  • ✨ Added with_all_evm_code_types, with_all_call_opcodes and with_all_create_opcodes markers, which allow automatic parametrization of tests to EOF (#610, #739).
  • +
  • ✨ Added with_all_system_contracts marker, which helps parametrize tests with all contracts that affect the chain on a system level (#739).
  • +
  • ✨ Code generators Conditional and Switch now support EOF by adding parameter evm_code_type (#610).
  • +
  • ✨ fill command now supports parameter --evm-code-type that can be (currently) set to legacy or eof_v1 to force all test smart contracts to deployed in normal or in EOF containers (#610).
  • +
  • 🐞 Fixed fixture index generation on EOF tests (#728).
  • +
  • 🐞 Fixes consume genesis mismatch exception for hive based simulators (#734).
  • +
  • ✨ Adds reproducible consume commands to hiveview (#717).
  • +
  • πŸ’₯ Added multiple exceptions to the EOF fixture format (#759).
  • +
  • ✨ Added optional parameter to all with_all_* markers to specify a lambda function that filters the parametrized values (#739).
  • +
  • ✨ Added extend_with_defaults utility function, which helps extend test case parameter sets with default values. @pytest.mark.parametrize (#739).
  • +
  • ✨ Added Container.Init to ethereum_test_types.EOF.V1 package, which allows generation of an EOF init container more easily (#739).
  • +
  • ✨ Introduce method valid_opcodes() to the fork class (#748).
  • +
  • 🐞 Fixed consume exit code return values, ensuring that pytest’s return value is correctly propagated to the shell. This allows the shell to accurately reflect the test results (e.g., failures) based on the pytest exit code (#765).
  • +
  • ✨ Added a new flag --solc-version to the fill command, which allows the user to specify the version of the Solidity compiler to use when compiling Yul source code; this version will now be automatically downloaded by fill via solc-select (#772).
  • +
  • 🐞 Fix usage of multiple @pytest.mark.with_all* markers which shared parameters, such as with_all_call_opcodes and with_all_create_opcodes which shared evm_code_type, and now only parametrize compatible values (#762).
  • +
  • ✨ Added selector and marks fields to all @pytest.mark.with_all* markers, which allows passing lambda functions to select or mark specific parametrized values (see documentation for more information) (#762).
  • +
  • ✨ Improves consume input flags for develop and stable fixture releases, fixes --help flag for consume (#745).
  • +
  • πŸ”€ Return exit-code from consume commands (#766).
  • +
  • πŸ”€ Remove duplicate EOF container tests, automatically check for duplicates (#800).
  • +
  • πŸ”€ Fix DATALOAD pushed_stack_items calculation (#784).
  • +
  • ✨ Add evm_bytes rename and print asm (#844).
  • +
  • πŸ”€ Use the session_temp_folder introduced in #824 (#845).
  • +
  • 🐞 Don’t treat eels resolutions as a fixture (#878).
  • +
  • ✨ Emphasize that no tests were executed during a fill pytest session (#887).
  • +
  • πŸ”€ Move generic code from TransitionTool to a new generic base class EthereumCLI (#894).
  • +
  • 🐞 Fix erroneous fork mes- πŸ”€ Fix max stack height calculation (#810).
  • +
  • ✨ Add storage key hint in Storage class (#917).
  • +
  • ✨ Add system to verify exception strings (#795).
  • +
  • πŸ”€ Fix FixedBytes assignment rules (#1010).
  • +
  • πŸ”€ Fix Address padding options (#1113).
  • +
  • πŸ”€ Add Container.expected_bytecode optional parameter (#737).
  • +
  • ✨ Add support for initcode_prefix on EOF Container.Init (#819).sage in pytest session header with development forks (#806).
  • +
  • 🐞 Fix Conditional code generator in EOF mode (#821).
  • +
  • πŸ”€ Ensure that Block objects keep track of their fork, for example, when the block’s rlp_modifier is not None (#854).
  • +
  • πŸ”€ ethereum_test_rpc library has been created with what was previously ethereum_test_tools.rpc (#822).
  • +
  • ✨ Add Wei type to ethereum_test_base_types which allows parsing wei amounts from strings like “1 ether”, “1000 wei”, “10**2 gwei”, etc (#825).
  • +
  • ✨ Pin EELS versions in eels_resolutions.json and include this file in fixture releases (#872).
  • +
  • πŸ”€ Replace ethereum.base_types with ethereum-types (#850).
  • +
  • πŸ’₯ Rename the PragueEIP7692 fork to Osaka (#869).
  • +
  • ✨ Improve fill terminal output to emphasize that filling tests is not actually testing a client (#807).
  • +
  • ✨ Add the BlockchainTestEngine test spec type that only generates a fixture in the EngineFixture (blockchain_test_engine) format (#888).
  • +
  • πŸ”€ Move the evm_transition_tool package to ethereum_clis and derive the transition tool CL interfaces from a shared EthereumCLI class that can be reused for other sub-commands (#894).
  • +
  • ✨ Pass state_test property to T8N tools that support it (Only EELS at the time of merge) (#943).
  • +
  • ✨ Add the eofwrap cli used to wrap tests from ethereum/tests in an EOF container (#896).
  • +
  • πŸ”€ Improve gentest architecture with EthereumTestBaseModel and EthereumTestRootModel (#901).
  • +
  • πŸ”€ Migrate transaction test to state_test for gentest (#903).
  • +
  • πŸ”€ ethereum_test_forks forks now contain gas-calculating functions, which return the appropriate function to calculate the gas used by a transaction or memory function for the given fork (#779).
  • +
  • 🐞 Fix Bytecode class __eq__ method (#939).
  • +
  • πŸ”€ Update pydantic from 2.8.2 to 2.9.2 (#960).
  • +
  • ✨ Add the eest make test command, an interactive CLI that helps users create a new test module and function (#950).
  • +
  • ✨ Add the eest clean command that helps delete generated files and directories from the repository (#980).
  • +
  • ✨ Add framework changes for EIP-7742, required for Prague devnet-5 (#931).
  • +
  • ✨ Add the eest make env command that generates a default env file (env.yaml)(#996).
  • +
  • ✨ Generate Transaction Test type (#933).
  • +
  • ✨ Add a default location for evm logs (--evm-dump-dir) when filling tests (#999).
  • +
  • ✨ Slow tests now have greater timeout when making a request to the T8N server (#1037).
  • +
  • ✨ Introduce pytest.mark.parametrize_by_fork helper marker (#1019, #1057).
  • +
  • 🐞 fix(consume): allow absolute paths with --evm-bin (#1052).
  • +
  • ✨ Disable EIP-7742 framework changes for Prague (#1023).
  • +
  • ✨ Allow verification of the transaction receipt on executed test transactions (#1068).
  • +
  • ✨ Modify valid_at_transition_to marker to add keyword arguments subsequent_transitions and until to fill a test using multiple transition forks (#1081).
  • +
  • 🐞 fix(consume): use "HIVE_CHECK_LIVE_PORT" to signal hive to wait for port 8551 (Engine API port) instead of the 8545 port when running consume engine (#1095).
  • +
  • ✨ state_test, blockchain_test and blockchain_test_engine fixtures now contain the blobSchedule from EIP-7840, only for tests filled for Cancun and Prague forks (#1040).
  • +
  • πŸ”€ Change --dist flag to the default value, load, for better parallelism handling during test filling (#1118).
  • +
  • πŸ”€ Refactor framework code to use the ethereum-rlp package instead of ethereum.rlp, previously available in ethereum/execution-specs (#1180).
  • +
  • πŸ”€ Update EELS / execution-specs EEST dependency to 99238233 for EEST framework libraries and test case generation (#1181).
  • +
  • ✨ Add the consume cache command to cache fixtures before running consume commands (#1044).
  • +
  • ✨ The --input flag of the consume commands now supports parsing of tagged release names in the format <RELEASE_NAME>@<RELEASE_VERSION> (#1044).
  • +
  • 🐞 Fix stdout output when using the fill command (#1188).
  • +
  • ✨ Add tests for blockchain intermediate state verification (#1075).
  • +
  • ✨ Add Interactive CLI input functionality (#947).
  • +
  • πŸ”€ Rename EOFTest.data to EOFTest.container with rebase of EOFStateTest (#1145).
  • +
  • ✨ Turn on --traces for EELS + ethereum-specs-evm-resolver (#1174).
  • +
+

πŸ“‹ Misc

+
    +
  • ✨ Feature releases can now include multiple types of fixture tarball files from different releases that start with the same prefix (#736).
  • +
  • ✨ Releases for feature eip7692 now include both Cancun and Prague based tests in the same release, in files fixtures_eip7692.tar.gz and fixtures_eip7692-prague.tar.gz respectively (#743). +✨ Re-write the test case reference doc flow as a pytest plugin and add pages for test functions with a table providing an overview of their parametrized test cases (#801, #842).
  • +
  • πŸ”€ Simplify Python project configuration and consolidate it into pyproject.toml (#764).
  • +
  • ✨ Add dev docs to help using nectos/act (#776).
  • +
  • πŸ”€ Update uv.lock for updated solc deps (#782).
  • +
  • ✨ Enable coverage on any test change (#790).
  • +
  • πŸ”€ Created pytest_plugins.concurrency plugin to sync multiple xdist processes without using a command flag to specify the temporary working folder (#824).
  • +
  • πŸ”€ Move pytest plugin pytest_plugins.filler.solc to pytest_plugins.solc.solc (#823).
  • +
  • πŸ”€ Remove formats.py, embed properties as class vars (#826).
  • +
  • ✨ Add build-evm-base to docs deploy workflows (#829).
  • +
  • πŸ”€ Add links to the online test case docs in the EOF tracker (#838).
  • +
  • πŸ”€ Fix miscellaneous improvements to troubleshooting, navigation, styling (#840).
  • +
  • ✨ Include all parameters in test parameter datatables (#842).
  • +
  • ✨ Add info about ripemd160 & update running actions locally (#847).
  • +
  • ✨ Add SECURITY.md describing how to report vulnerabilities (#848).
  • +
  • πŸ”€ Change image from ubuntu-24.04 to ubuntu-latest in CI (#855).
  • +
  • 🐞 Asserts that the deploy docs tags workflow is only triggered for full releases (#857).
  • +
  • 🐞 Fix deploy docs tags workflow trigger (#858).
  • +
  • ✨ A new application-wide configuration manager provides access to environment and application configurations. (#892).
  • +
  • πŸ”€ Update the developer docs navigation (#898).
  • +
  • πŸ”€ Use jinja2 templating in gentest (#900).
  • +
  • ✨ Fix/add test github actions locally page (#909).
  • +
  • 🐞 Fix print fill output in coverage workflow on errors (#919).
  • +
  • 🐞 Use a local version of ethereum/execution-specs (EELS) when running the framework tests in CI (#997).
  • +
  • ✨ Use self-hosted runners for fixture building in CI (#1051).
  • +
  • ✨ Release tarballs now contain fixtures filled for all forks, not only the fork under active development and the fork currently deployed on mainnet (#1053).
  • +
  • ✨ StateTest fixture format now contains state field in each network post result, containing the decoded post allocation that results from the transaction execution (#1064).
  • +
  • ✨ Include EELS fork resolution information in filled json test fixtures (#1123).
  • +
  • πŸ”€ Updates ruff from version 0.8.2 to 0.9.4 (#1168).
  • +
  • πŸ”€ Update uv.lock to be compatible with uv>=0.5.22 (#1178).
  • +
  • πŸ”€ Update mypy from version 0.991 to 1.15 (#1209).
  • +
+

πŸ§ͺ Test Cases

+
    +
  • ✨ Migrate validation tests EIP3540/validInvalidFiller.yml (#598).
  • +
  • ✨ EIP-4844 test tests/cancun/eip4844_blobs/test_point_evaluation_precompile.py includes an EOF test case (#610).
  • +
  • ✨ Example test tests/frontier/opcodes/test_dup.py now includes EOF parametrization (#610).
  • +
  • ✨ Add EOFv1 function test - Call simple contract test (#695).
  • +
  • ✨ Add section size validation tests (#705).
  • +
  • ✨ Add deep and wide EOF subcontainers tests (#718).
  • +
  • ✨ Update EIP-7702 tests for Devnet-3 (#733).
  • +
  • ✨ Migrate “valid” EOFCREATE validation (#738).
  • +
  • ✨ Migrate tests for truncated sections (#740).
  • +
  • ✨ Add out of order container section test (#741).
  • +
  • ✨ Convert all opcodes validation test tests/frontier/opcodes/test_all_opcodes.py (#748).
  • +
  • πŸ”€ Add Test types with 128 inputs (#749).
  • +
  • πŸ”€ Use new marker to EOF-ize MCOPY test (#754).
  • +
  • ✨ Add EOF Tests from Fuzzing (#756).
  • +
  • ✨ Add embedded container tests (#763).
  • +
  • ✨ Validate EOF only opcodes are invalid in legacy (#768).
  • +
  • ✨ Update EOF tracker, add unimplemented tests (#773).
  • +
  • ✨ Add EIP-7620 EOFCREATE gas tests (#785).
  • +
  • ✨ Add more fuzzing discovered EOF tests (#789).
  • +
  • ✨ Add EOF tests for invalid non-returning sections (#794).
  • +
  • ✨ Test to ensure transient storage is cleared after transactions (#798).
  • +
  • ✨ Test that transient storage stays at correct address (#799).
  • +
  • ✨ Add EOFCREATE referencing the same subcontainer twice test (#809).
  • +
  • ✨ Add dangling data in subcontainer test (#812).
  • +
  • 🐞 Fix EIP-7702+EOF tests due to incorrect test expectations and faulty Conditional test generator in EOF mode (#821).
  • +
  • 🐞 Fix TSTORE EOF variant test (#831).
  • +
  • πŸ”€ Unify EOF return code constants (#834).
  • +
  • ✨ Add RJUMP* vs CALLF tests (#833).
  • +
  • ✨ Add tests to clarify “non-returning instruction” (#837).
  • +
  • ✨ Add double RJUMPI stack validation tests (#851).
  • +
  • ✨ Add unreachable code sections tests (#856).
  • +
  • πŸ’₯ PragueEIP7692 fork in tests has been updated to Osaka (#869).
  • +
  • ✨ Update EIP-6110, EIP-7002, EIP-7251, EIP-7685, and EIP-7702 tests for Devnet-4 (#832).
  • +
  • ✨ Add EIP-7069 and EIP-7620 failures and context vars tests (#836).
  • +
  • ✨ Add EOF EIP-4750 Stack validation in CALLF test (#889).
  • +
  • ✨ Add stack overflow by rule check to JUMPF tests (#902).
  • +
  • 🐞 Fix erroneous test withCALLF rule bug (#907).
  • +
  • ✨ Add test for EXTDELEGATECALL value cost (#911).
  • +
  • ✨ Add basic EOF execution tests (#912).
  • +
  • ✨ Add parametrized CALLF execution tests (#913).
  • +
  • ✨ Add CALLF execution tests (#914).
  • +
  • ✨ Add fibonacci and factorial CALLF tests (#915).
  • +
  • ✨ Add RJUMP* execution tests (#916).
  • +
  • ✨ EIP-7702 many delegations test (#923).
  • +
  • ✨ Add opcode validation tests (#932).
  • +
  • ✨ Add RJUMPI with JUMPF tests (#928).
  • +
  • ✨ EIP-7702 set code of non-empty-storage account test (#948).
  • +
  • ✨ Add PUSH* opcode tests (#975).
  • +
  • ✨ EIP-7702 implement 7702 test ideas (#981).
  • +
  • ✨ EIP-7702 Remove delegation behavior of EXTCODE* (#984).
  • +
  • ✨ Add EIP-7620 RETURNCONTRACT behavior verification test (#1109).
  • +
  • ✨ Add EIP-7069 p256verify EOF calls tests (#1021).
  • +
  • ✨ Add EIP-7480 DATACOPY edge cases tests (#1020).
  • +
  • ✨ Add EIP-7069 EXTCALL creation gas charge tests (#1025).
  • +
  • ✨ Add generic precompile-absence test (#1036).
  • +
  • ✨ Add test for EIP-2537 which uses the full discount table of G2 MSM (#1038).
  • +
  • ✨ EIP-7691 Blob throughput increase tests by parametrization of existing EIP-4844 tests (#1023, #1082).
  • +
  • ✨ Port calldatacopy test (#1056).
  • +
  • ✨ EIP-7623 Increase calldata cost (#1004, #1071).
  • +
  • ✨ Add CALLF invalid section index tests (#1111).
  • +
  • ✨ Add JUMPF invalid section index tests (#1112).
  • +
  • ✨ Add CALLF truncated immediate bytes tests (#1114).
  • +
  • ✨ EIP-152 Add tests for Blake2 compression function F precompile (#1067).
  • +
  • ✨ Add CALLF non-returning section tests (#1126).
  • +
  • ✨ Add DATALOADN truncated immediate bytes tests (#1127).
  • +
  • πŸ”€ Update EIP-7702 test expectations according to spec updates (#1129).
  • +
  • ✨ Add tests for CALLF and non-returning (#1140).
  • +
  • πŸ”€ Update EIP-7251 according to spec updates #9127, #9289 (#1024, #1155).
  • +
  • πŸ”€ Update EIP-7002 according to spec updates #9119, #9288 (#1024, #1155).
  • +
  • πŸ”€ Update EIP-2935 according to spec updates #9144, #9287 (#1046, #1155).
  • +
  • ✨ Add DATALOADN validation and execution tests (#1162).
  • +
  • ✨ Add EOF prefix tests (#1187).
  • +
  • ✨ Add tests for EOF code header missing (#1193).
  • +
  • ✨ Add tests for empty EOF type section (#1194).
  • +
  • ✨ Add tests for multiple EOF type sections (#1195).
  • +
  • ✨ Add EIP-7698 legacy EOF creation prevention tests (#1206).
  • +
+
+
+

v3.0.0 - 2024-07-22

+

πŸ§ͺ Test Cases

+ +

πŸ› οΈ Framework

+
    +
  • 🐞 Fix incorrect != operator for FixedSizeBytes (#477).
  • +
  • ✨ Add Macro enum that represents byte sequence of Op instructions (#457).
  • +
  • ✨ Number of parameters used to call opcodes (to generate bytecode) is now checked (#492).
  • +
  • ✨ Libraries have been refactored to use pydantic for type checking in most test types (#486, #501, #508).
  • +
  • ✨ Opcodes are now subscriptable and it’s used to define the data portion of the opcode: Op.PUSH1(1) == Op.PUSH1[1] == b"\x60\x01" (#513).
  • +
  • ✨ Added EOF fixture format (#512).
  • +
  • ✨ Verify filled EOF fixtures using evmone-eofparse during fill execution (#519).
  • +
  • ✨ Added --traces support when running with Hyperledger Besu (#511).
  • +
  • ✨ Use pytest’s “short” traceback style (--tb=short) for failure summaries in the test report for more compact terminal output (#542).
  • +
  • ✨ The fill command now generates HTML test reports with links to the JSON fixtures and debug information (#537).
  • +
  • ✨ Add an Ethereum RPC client class for use with consume commands (#556).
  • +
  • ✨ Add a “slow” pytest marker, in order to be able to limit the filled tests until release (#562).
  • +
  • ✨ Add a CLI tool that generates blockchain tests as Python from a transaction hash (#470, #576).
  • +
  • ✨ Add more Transaction and Block exceptions from existing ethereum/tests repo (#572).
  • +
  • ✨ Add “description” and “url” fields containing test case documentation and a source code permalink to fixtures during fill and use them in consume-generated Hive test reports (#579).
  • +
  • ✨ Add git workflow evmone coverage script for any new lines mentioned in converted_ethereum_tests.txt (#503).
  • +
  • ✨ Add a new covariant marker with_all_contract_creating_tx_types that allows automatic parametrization of a test with all contract-creating transaction types at the current executing fork (#602).
  • +
  • ✨ Tests are now encouraged to declare a pre: Alloc parameter to get the pre-allocation object for the test, and use pre.deploy_contract and pre.fund_eoa to deploy contracts and fund accounts respectively, instead of declaring the pre as a dictionary or modifying its contents directly (see the state test tutorial for an updated example) (#584).
  • +
  • ✨ Enable loading of ethereum/tests/BlockchainTests (#596).
  • +
  • πŸ”€ Refactor gentest to use ethereum_test_tools.rpc.rpc by adding to get_transaction_by_hash, debug_trace_call to EthRPC (#568).
  • +
  • ✨ Write a properties file to the output directory and enable direct generation of a fixture tarball from fill via --output=fixtures.tgz(#627).
  • +
  • πŸ”€ ethereum_test_tools library has been split into multiple libraries (#645).
  • +
  • ✨ Add the consume engine simulator and refactor the consume simulator suite (#691).
  • +
  • 🐞 Prevents forcing consume to use stdin as an input when running from hive (#701).
  • +
+

πŸ“‹ Misc

+
    +
  • 🐞 Fix CI by using Golang 1.21 in Github Actions to build geth (#484).
  • +
  • πŸ’₯ “Merge” has been renamed to “Paris” in the “network” field of the Blockchain tests, and in the “post” field of the State tests (#480).
  • +
  • ✨ Port entry point scripts to use click and add tests (#483).
  • +
  • πŸ’₯ As part of the pydantic conversion, the fixtures have the following (possibly breaking) changes (#486): +
      +
    • State test field transaction now uses the proper zero-padded hex number format for fields maxPriorityFeePerGas, maxFeePerGas, and maxFeePerBlobGas.
    • +
    • Fixtures’ hashes (in the _info field) are now calculated by removing the “_info” field entirely instead of it being set to an empty dict.
    • +
    +
  • +
  • 🐞 Relax minor and patch dependency requirements to avoid conflicting package dependencies (#510).
  • +
  • πŸ”€ Update all CI actions to use their respective Node.js 20 versions, ahead of their Node.js 16 version deprecations (#527).
  • +
  • ✨ Releases now contain a fixtures_eip7692.tar.gz which contains all EOF fixtures (#573).
  • +
  • ✨ Use solc-select for tox when running locally and within CI (#604).
  • +
+

πŸ’₯ Breaking Change

+
    +
  • Cancun is now the latest deployed fork, and the development fork is now Prague (#489).
  • +
  • Stable fixtures artifact fixtures.tar.gz has been renamed to fixtures_stable.tar.gz (#573).
  • +
  • The “Blockchain Test Hive” fixture format has been renamed to “Blockchain Test Engine” and updated to more closely resemble the engine_newPayload format in the execution-apis specification (https://github.com/ethereum/execution-apis/blob/main/src/engine/prague.md#request) and now contains a single "params" field instead of multiple fields for each parameter (#687).
  • +
  • Output folder for fixtures has been renamed from “blockchain_tests_hive” to “blockchain_tests_engine” (#687).
  • +
+
+
+

v2.1.1 - 2024-03-09

+

πŸ§ͺ Test Cases

+
    +
  • 🐞 Dynamic create2 collision from different transactions same block (#430).
  • +
  • 🐞 Fix beacon root contract deployment tests so the account in the pre-alloc is not empty (#425).
  • +
  • πŸ”€ All beacon root contract tests are now contained in tests/cancun/eip4788_beacon_root/test_beacon_root_contract.py, and all state tests have been converted back to blockchain tests format (#449).
  • +
+

πŸ› οΈ Framework

+
    +
  • +

    ✨ Adds two consume commands #339:

    +
      +
    1. consume direct - Execute a test fixture directly against a client using a blocktest-like command (currently only geth supported).
    2. +
    3. consume rlp - Execute a test fixture in a hive simulator against a client that imports the test’s genesis config and blocks as RLP upon startup. This is a re-write of the ethereum/consensus Golang simulator.
    4. +
    +
  • +
  • +

    ✨ Add Prague to forks (#419).

    +
  • +
  • +

    ✨ Improve handling of the argument passed to solc --evm-version when compiling Yul code (#418).

    +
  • +
  • +

    🐞 Fix fill -m yul_test which failed to filter tests that are (dynamically) marked as a yul test (#418).

    +
  • +
  • +

    πŸ”€ Helper methods to_address, to_hash and to_hash_bytes have been deprecated in favor of Address and Hash, which are automatically detected as opcode parameters and pushed to the stack in the resulting bytecode (#422).

    +
  • +
  • +

    ✨ Opcodes enum now contains docstrings with each opcode description, including parameters and return values, which show up in many development environments (#424) @ThreeHrSleep.

    +
  • +
  • +

    πŸ”€ Locally calculate state root for the genesis blocks in the blockchain tests instead of calling t8n (#450).

    +
  • +
  • +

    🐞 Fix bug that causes an exception during test collection because the fork parameter contains None (#452).

    +
  • +
  • +

    ✨ The _info field in the test fixtures now contains a hash field, which is the hash of the test fixture, and a hasher script has been added which prints and performs calculations on top of the hashes of all fixtures (see hasher -h) (#454).

    +
  • +
  • +

    ✨ Adds an optional verify_sync field to hive blockchain tests (EngineAPI). When set to true a second client attempts to sync to the first client that executed the tests (#431).

    +
  • +
  • +

    🐞 Fix manually setting the gas limit in the genesis test env for post genesis blocks in blockchain tests (#472).

    +
  • +
+

πŸ“‹ Misc

+
    +
  • 🐞 Fix deprecation warnings due to outdated config in recommended VS Code project settings (#420).
  • +
  • 🐞 Fix typo in the selfdestruct revert tests module (#421).
  • +
+
+
+

v2.1.0 - 2024-01-29: πŸπŸ–οΈ Cancun

+

Release v2.1.0 primarily fixes a small bug introduced within the previous release where transition forks are used within the new StateTest format. This was highlighted by @chfast within #405 (https://github.com/ethereum/execution-spec-tests/issues/405), where the fork name ShanghaiToCancunAtTime15k was found within state tests.

+

πŸ§ͺ Test Cases

+
    +
  • ✨ EIP-4844: Adds test_blob_gas_subtraction_tx() verifying the blob gas fee is subtracted from the sender before executing the blob tx (#407).
  • +
+

πŸ› οΈ Framework

+
    +
  • 🐞 State tests generated with transition forks no longer use the transition fork name in the fixture output, instead they use the actual enabled fork according to the state test’s block number and timestamp (#406).
  • +
+

πŸ“‹ Misc

+
    +
  • ✨ Use run-parallel and shared wheel packages for tox (#408).
  • +
+
+
+

v2.0.0 - 2024-01-25: πŸπŸ–οΈ Cancun

+

Release v2.0.0 contains many important framework changes, including introduction of the StateTest format, and some additional Cancun and other test coverage.

+

Due to changes in the framework, there is a breaking change in the directory structure in the release tarball, please see the dedicated “πŸ’₯ Breaking Changes” section below for more information.

+

πŸ§ͺ Test Cases

+
    +
  • ✨ EIP-4844: Add test_sufficient_balance_blob_tx() and test_sufficient_balance_blob_tx_pre_fund_tx() (#379).
  • +
  • ✨ EIP-6780: Add a reentrancy suicide revert test (#372).
  • +
  • ✨ EIP-1153: Add test_run_until_out_of_gas() for transient storage opcodes (#401).
  • +
  • ✨ EIP-198: Add tests for the MODEXP precompile (#364).
  • +
  • ✨ Tests for nested CALL and CALLCODE gas consumption with a positive value transfer (previously lacking coverage) (#371).
  • +
  • 🐞 EIP-4844: Fixed test_invalid_tx_max_fee_per_blob_gas() to account for extra gas required in the case where the account is incorrectly deduced the balance as if it had the correct block blob gas fee (#370).
  • +
  • 🐞 EIP-4844: Fixed test_insufficient_balance_blob_tx() to correctly calculate the minimum balance required for the accounts (#379).
  • +
  • 🐞 EIP-4844: Fix and enable test_invalid_blob_tx_contract_creation (#379).
  • +
  • πŸ”€ Convert all eligible BlockchainTests to StateTests (and additionally generate corresponding BlockchainTests) (#368, #370).
  • +
+

πŸ› οΈ Framework

+
    +
  • ✨ Add StateTest fixture format generation; StateTests now generate a StateTest and a corresponding BlockchainTest test fixture, previously only BlockchainTest fixtures were generated (#368).
  • +
  • ✨ Add StateTestOnly fixture format is now available and its only difference with StateTest is that it does not produce a BlockchainTest (#368).
  • +
  • ✨ Add evm_bytes_to_python command-line utility which converts EVM bytecode to Python Opcodes (#357).
  • +
  • ✨ Fork objects used to write tests can now be compared using the >, >=, <, <= operators, to check for a fork being newer than, newer than or equal, older than, older than or equal, respectively when compared against other fork (#367).
  • +
  • ✨ Add solc 0.8.23 support (#373).
  • +
  • ✨ Add framework unit tests for post state exception verification (#350).
  • +
  • ✨ Add a helper class ethereum_test_tools.TestParameterGroup to define test parameters as dataclasses and auto-generate test IDs (#364).
  • +
  • ✨ Add a --single-fixture-per-file flag to generate one fixture JSON file per test case (#331).
  • +
  • 🐞 Storage type iterator is now fixed (#369).
  • +
  • 🐞 Fix type coercion in FixtureHeader.join() (#398).
  • +
  • πŸ”€ Locally calculate the transactions list’s root instead of using the one returned by t8n when producing BlockchainTests (#353).
  • +
  • πŸ”€ Change custom exception classes to dataclasses to improve testability (#386).
  • +
  • πŸ”€ Update fork name from “Merge” to “Paris” used within the framework and tests (#363).
  • +
  • πŸ’₯ Replace = with _ in pytest node ids and test fixture names (#342).
  • +
  • πŸ’₯ The StateTest, spec format used to write tests, is now limited to a single transaction per test (#361).
  • +
  • πŸ’₯ Tests must now use BlockException and TransactionException to define the expected exception of a given test, which can be used to test whether the client is hitting the proper exception when processing the block or transaction (#384).
  • +
  • πŸ’₯ fill: Remove the --enable-hive flag; now all test types are generated by default (#358).
  • +
  • πŸ’₯ Rename test fixtures names to match the corresponding pytest node ID as generated using fill (#342).
  • +
+

πŸ“‹ Misc

+
    +
  • ✨ Docs: Add a “Consuming Tests” section to the docs, where each test fixture format is described, along with the steps to consume them, and the description of the structures used in each format (#375).
  • +
  • πŸ”€ Docs: Update t8n tool branch to fill tests for development features in the readme (#338).
  • +
  • πŸ”€ Filling tool: Updated the default filling tool (t8n) to go-ethereum@master (#368).
  • +
  • 🐞 Docs: Fix error banner in online docs due to mermaid syntax error (#398).
  • +
  • 🐞 Docs: Fix incorrectly formatted nested lists in online doc (#403).
  • +
  • πŸ”€ CLI: evm_bytes_to_python is renamed to evm_bytes and now accepts flag --assembly to output the code in assembly format (#844).
  • +
+

πŸ’₯ Breaking Changes

+

A concrete example of the test name renaming and change in directory structure is provided below.

+
    +
  1. +

    Fixture output, including release tarballs, now contain subdirectories for different test types:

    +
      +
    1. blockchain_tests: Contains BlockchainTest formatted tests
    2. +
    3. blockchain_tests_hive: Contains BlockchainTest with Engine API call directives for use in hive
    4. +
    5. state_tests: Contains StateTest formatted tests
    6. +
    +
  2. +
  3. +

    StateTest, spec format used to write tests, is now limited to a single transaction per test.

    +
  4. +
  5. +

    In this release the pytest node ID is now used for fixture names (previously only the test parameters were used), this should not be breaking. However, = in both node IDs (and therefore fixture names) have been replaced with _, which may break tooling that depends on the = character.

    +
  6. +
  7. +

    Produced blockchain_tests fixtures and their corresponding blockchain_tests_hive fixtures now contain the named exceptions BlockException and TransactionException as strings in the expectException and validationError fields, respectively. These exceptions can be used to test whether the client is hitting the proper exception when processing an invalid block.

    +

    Blockchain test:

    +
    "blocks": [
    +      {
    +         ...
    +         "expectException": "TransactionException.INSUFFICIENT_ACCOUNT_FUNDS",
    +         ...
    +      }
    +      ...
    +]
    +

    Blockchain hive test:

    +
    "engineNewPayloads": [
    +      {
    +         ...
    +         "validationError": "TransactionException.INSUFFICIENT_ACCOUNT_FUNDS",
    +         ...
    +      }
    +      ...
    +]
    +
  8. +
+

Renaming and Release Tarball Directory Structure Change Example

+

The fixture renaming provides a more consistent naming scheme between the pytest node ID and fixture name and allows the fixture name to be provided directly to pytest 5on the command line to execute individual tests in isolation, e.g. pytest tests/frontier/opcodes/test_dup.py::test_dup[fork_Frontier].

+
    +
  1. +

    Pytest node ID example:

    +
      +
    1. Previous node ID: tests/frontier/opcodes/test_dup.py::test_dup[fork=Frontier].
    2. +
    3. New node ID: tests/frontier/opcodes/test_dup.py::test_dup[fork_Frontier].
    4. +
    +
  2. +
  3. +

    Fixture name example:

    +
      +
    1. Previous fixture name: 000-fork=Frontier
    2. +
    3. New fixture name: tests/frontier/opcodes/test_dup.py::test_dup[fork_Frontier] (now the same as the pytest node ID).
    4. +
    +
  4. +
  5. +

    Fixture JSON file name example (within the release tarball):

    +
      +
    1. Previous fixture file name: fixtures/frontier/opcodes/dup/dup.json (BlockChainTest format).
    2. +
    3. New fixture file names (all present within the release tarball):
    4. +
    +
      +
    • fixtures/state_tests/frontier/opcodes/dup/dup.json (StateTest format).
    • +
    • fixtures/blockchain_tests/frontier/opcodes/dup/dup.json (BlockChainTest format).
    • +
    • fixtures/blockchain_tests_hive/frontier/opcodes/dup/dup.json (a blockchain test in HiveFixture format).
    • +
    +
  6. +
+
+
+

v1.0.6 - 2023-10-19: πŸπŸ–οΈ Cancun Devnet 10

+

πŸ§ͺ Test Cases

+
    +
  • πŸ”€ EIP-4844: Update KZG point evaluation test vectors to use data from the official KZG setup and Mainnet Trusted Setup (#336).
  • +
+

πŸ› οΈ Framework

+
    +
  • πŸ”€ Fixtures: Add a non-RLP format field (rlp_decoded) to invalid blocks (#322).
  • +
  • πŸ”€ Spec: Refactor state and blockchain spec (#307).
  • +
+

πŸ”§ EVM Tools

+
    +
  • ✨ Run geth’s evm blocktest command to verify JSON fixtures after test case execution (--verify-fixtures) (#325).
  • +
  • ✨ Enable tracing support for ethereum-spec-evm (#289).
  • +
+

πŸ“‹ Misc

+ +

πŸ’₯ Breaking Change

+ +
+
+

v1.0.5 - 2023-09-26: πŸπŸ–οΈ Cancun Devnet 9 Release 3

+

This release mainly serves to update the EIP-4788 beacon roots address to 0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02, as updated in ethereum/EIPs/pull/7672.

+

πŸ§ͺ Test Cases

+
    +
  • 🐞 EIP-4844: Fix invalid blob txs pre-Cancun engine response (#306).
  • +
  • ✨ EIP-4788: Final update to the beacon root address (#312).
  • +
+

πŸ“‹ Misc

+
    +
  • ✨ Docs: Changelog added (#305).
  • +
  • ✨ CI/CD: Run development fork tests in Github Actions (#302).
  • +
  • ✨ CI/CD: Generate test JSON fixtures on push (#303).
  • +
+

πŸ’₯ Breaking Change

+

Please use development fixtures from now on when testing Cancun. These refer to changes that are currently under development within clients:

+
    +
  • fixtures: All tests until the last stable fork (Shanghai).
  • +
  • fixtures_develop: All tests until the last development fork (Cancun).
  • +
  • fixtures_hive: All tests until the last stable fork (Shanghai) in hive format (Engine API directives instead of the usual BlockchainTest format).
  • +
  • fixtures_develop_hive: All tests until the last development fork (Cancun) in hive format.
  • +
+
+
+

v1.0.4 - 2023-09-21: 🐍 Cancun Devnet 9 Release 2

+

This release adds additional coverage to the current set of Cancun tests, up to the Devnet-9 Cancun specification.

+

Note: Additional EIP-4788 updates from ethereum/EIPs/pull/7672 will be included in the next release.

+

πŸ§ͺ Test Cases

+ +

πŸ› οΈ Framework

+
    +
  • πŸ”€ EIP-4788: Beacon root contract is pre-deployed at 0xbEAC020008aFF7331c0A389CB2AAb67597567d7a (@spencer-tb in #297).
  • +
  • ✨ Deprecate empty accounts within framework (@spencer-tb in #300).
  • +
  • ✨ Fixture generation split based on hive specificity (@spencer-tb in #301).
  • +
  • πŸ’₯ fill: --disable-hive flag removed; replaced by --enable-hive (@spencer-tb in #301).
  • +
  • ✨ Add engine API forkchoice updated information in fixtures (@spencer-tb in #256).
  • +
+
+
+

v1.0.3 - 2023-09-14: 🐍 Cancun Devnet 9 Release

+

See v1.0.3.

+

v1.0.2 - 2023-08-11: 🐍 Cancun Devnet 8 + 4788 v2 Pre-Release

+

See v1.0.2.

+

v1.0.1 - 2023-08-03: 🐍 Cancun Devnet-8 Pre-Release

+

See v1.0.1.

+

v1.0.0 - 2023-06-27: πŸ§ͺ Welcome to the Pytest Era

+

See v1.0.0.

+
+
+
+

Older releases can be found on the releases page.

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/changelog_section_template.txt b/docs/public/main/changelog_section_template.txt new file mode 100644 index 00000000000..dd11bca8f4a --- /dev/null +++ b/docs/public/main/changelog_section_template.txt @@ -0,0 +1,17 @@ +# Changelog Section Template + +The following can be copy-pasted into the `CHANGELOG.md` file for a new release. + +## πŸ”œ [Unreleased] + +### πŸ’₯ Breaking Change + +### πŸ› οΈ Framework + +#### `fill` + +#### `consume` + +### πŸ“‹ Misc + +### πŸ§ͺ Test Cases diff --git a/docs/public/main/changelog_section_template/index.html b/docs/public/main/changelog_section_template/index.html new file mode 100644 index 00000000000..c68bd37f3e2 --- /dev/null +++ b/docs/public/main/changelog_section_template/index.html @@ -0,0 +1,1631 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ + +
+ +
+

+
+ +
+

Changelog Section Template

+

The following can be copy-pasted into the CHANGELOG.md file for a new release.

+

πŸ”œ [Unreleased]

+

πŸ’₯ Breaking Change

+

πŸ› οΈ Framework

+

fill

+

consume

+

πŸ“‹ Misc

+

πŸ§ͺ Test Cases

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/ci_integration/index.html b/docs/public/main/ci_integration/index.html new file mode 100644 index 00000000000..26a41e783a4 --- /dev/null +++ b/docs/public/main/ci_integration/index.html @@ -0,0 +1,1274 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

Continuous Integration and Automated Testing

+

The Ethereum Foundation maintains continuous testing infrastructure:

+ +
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/client_config/index.html b/docs/public/main/client_config/index.html new file mode 100644 index 00000000000..8e2d0b05ae4 --- /dev/null +++ b/docs/public/main/client_config/index.html @@ -0,0 +1,1383 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

Client Configuration Guide

+

Clients ran in Hive are configured via the following ./hive options:

+
    +
  1. --client-file=client_config.yaml: Specifies a YAML file defining which and how clients are built.
  2. +
  3. --client=client1,client2: Selects a subset of clients to run from the YAML via nametag.
  4. +
+

Client YAML File Format

+

Multiple client configurations can be defined as a list in a client YAML file with the following structure:

+
- client: <client-name-1>
+  nametag: <unique-identifier>
+  dockerfile: <dockerfile-variant>
+  build_args:
+    <key>: <value>
+    ...
+- client: <client-name-2>
+  ...
+

Client Build Variants

+

Hive runs client images in Docker containers. There are three different ways to specify how a client image should be built:

+ + + + + + + + + + + + + + + + + + + + + + + + + +
DockerfilePurposeExample Usage
DockerfileDefault production builddockerfile: "" (default)
Dockerfile.gitClone from Github and build from sourcedockerfile: git
Dockerfile.localBuild from local sourcedockerfile: local
+

These Dockerfiles are maintained for each supported client in @ethereum/hive in the ./clients/ subfolder.

+

Production Image

+

A pre-built image can be specified, for example, for Besu with:

+
- client: besu
+  nametag: pectra
+  build_args:
+    baseimage: hyperledger/besu
+    tag: 25.4.1
+

Git Dockerfile

+

“Git Dockerfiles” clone a branch of the client from Github and build it from source, for example:

+
- client: go-ethereum
+  nametag: experimental
+  dockerfile: git
+  build_args:
+    github: your-username/go-ethereum
+    tag: experimental-branch
+

Using A “Local Dockerfile”

+

“Local Dockerfiles” can be used to build a client from local source for testing local modifications:

+
- client: go-ethereum
+  nametag: local-dev
+  dockerfile: local
+  build_args:
+    local_path: ./clients/go-ethereum/go-ethereum-local
+

This requires copying the local client source code to the Hive directory:

+
cp -r /path/to/your/go-ethereum ./clients/go-ethereum/go-ethereum-local
+

Required Fields

+
    +
  • client: Must match a directory name in clients/ within the Hive repository
  • +
  • nametag: Unique identifier for this client configuration
  • +
+

Optional Fields

+
    +
  • dockerfile: Alternative Dockerfile to use (default: Dockerfile)
  • +
  • build_args: Docker build arguments passed to the Dockerfile
  • +
+

Build Arguments

+

Common Build Arguments

+ + + + + + + + + + + + + + + + + + + + + + + + + +
ArgumentDescriptionExample
tagGit commit/tag/branch or Docker tagmaster, v1.13.8, latest
githubGitHub repository for source buildsethereum/go-ethereum
baseimageDocker Hub image for binary buildsethereum/client-go
+

Troubleshooting

+

Build Issues

+

Force rebuild base images:

+
./hive --docker.pull --sim ethereum/eest/consume-engine
+

Force rebuild specific client:

+
./hive --docker.nocache "clients/go-ethereum" --sim ethereum/eest/consume-engine
+

Show the docker container build output:

+
./hive --docker.buildoutput --sim ethereum/eest/consume-engine
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/code_standards/index.html b/docs/public/main/code_standards/index.html new file mode 100644 index 00000000000..daef88972b3 --- /dev/null +++ b/docs/public/main/code_standards/index.html @@ -0,0 +1,1433 @@ + + + + + + + Coding Standards - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

Coding Standards

+
+ +
+

Code Standards

+

This documentation has been relocated.

+

yyyyyyyyyy

+

yeet

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/code_standards_details/index.html b/docs/public/main/code_standards_details/index.html new file mode 100644 index 00000000000..d6b204d16da --- /dev/null +++ b/docs/public/main/code_standards_details/index.html @@ -0,0 +1,1389 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

Detailed Code Standards

+

This page provides in-depth information about the code standards and verification processes in @ethereum/execution-spec-tests.

+

Running Tox Environments

+

Execution Options

+

Run all tox environments in parallel:

+
uvx --with=tox-uv tox run-parallel
+

Run environments sequentially with verbose output:

+
uvx --with=tox-uv tox -v
+

List all available environments:

+
uvx --with=tox-uv tox -av
+

Specific Environment Commands

+

Run specific environments using the -e flag:

+
uvx --with=tox-uv tox -e lint,typecheck,spellcheck
+

For Test Case Changes (./tests/)

+
uvx --with=tox-uv tox -e lint,typecheck,spellcheck,tests-deployed
+

For Framework and Library Changes (./src/)

+
uvx --with=tox-uv tox -e lint,typecheck,spellcheck,pytest
+

For Documentation Changes (./docs/)

+
uvx --with=tox-uv tox -e spellcheck,markdownlint,mkdocs,changelog
+
+ +
+
Tox Virtual Environment
+
+ Checks performed by tox are sandboxed in their own virtual environments (created automatically in the .tox/ subdirectory). These can be used to debug errors encountered during tox execution. +
+
+

Additional Dependencies

+

Some checks require external (non-Python) packages:

+

For spellcheck

+

The spellcheck environment uses codespell, which is automatically installed via Python dependencies and checks for common spelling mistakes in code and documentation.

+

To fix spelling errors found by codespell:

+
uv run codespell *.md *.ini .github/ src/ tests/ docs/ --write-changes
+
+ +
+
VS Code Integration
+
+ The whitelist.txt file is still maintained for the VS Code cSpell extension, which provides real-time spell checking in the editor. +
+
+

For markdownlint

+
sudo apt install nodejs
+sudo npm install -g markdownlint-cli2@0.17.2  # the version used in ci
+

Or use a specific node version using nvm.

+

Pre-commit Hooks

+

Certain tox environments can be run automatically as git pre-commit hooks to ensure that your changes meet the project’s standards before committing.

+

Installation

+
uvx pre-commit install
+

For more information, see Pre-commit Hooks Documentation.

+

Formatting and Line Length

+

The Python code in @ethereum/execution-spec-tests is formatted with ruff with a line length of 100 characters.

+

Ignoring Bulk Change Commits

+

The maximum line length was changed from 80 to 100 in Q2 2023. To ignore this bulk change commit in git blame output, use the .git-blame-ignore-revs file:

+
git blame --ignore-revs-file .git-blame-ignore-revs docs/gen_test_case_reference.py
+

To use the revs file persistently with git blame:

+
git config blame.ignoreRevsFile .git-blame-ignore-revs
+

Building and Verifying Docs Locally

+

To quickly build and browse the HTML documentation locally run:

+

=== “bash”

+
```console
+export FAST_DOCS=True
+uv run mkdocs serve
+```
+
+

=== “fish”

+
```console
+set -x FAST_DOCS True
+uv run mkdocs serve
+```
+
+

Setting FAST_DOCS to False additionally builds the “Test Case Reference” Section.

+

Verifying Fixture Changes

+

When writing a PR that modifies either the framework or test cases, verify that changes don’t cause issues with existing test cases.

+

All filled fixtures contain a hash field in the _info object, which is used to verify that the fixture hasn’t changed.

+

Using the Hasher Tool

+

The hasher command can be used to bulk-verify the hashes of fixtures in a directory.

+ + + + + + + + + + + + + + + + + + + + + +
FlagDescription
--files / -fPrints a combined hash per JSON fixture file.
--tests / -tPrints the hash of every test vector in JSON fixture files.
--root / -rPrints a combined hash for all JSON fixture files in a directory.
+

For a quick comparison between two fixture directories:

+
hasher --root fixtures/
+hasher --root fixtures_new/
+

To identify which files are different:

+
diff <(hasher --files fixtures/) <(hasher --files fixtures_new/)
+

For a granular comparison:

+
diff <(hasher --tests fixtures/) <(hasher --tests fixtures_new/)
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/coding_style/index.html b/docs/public/main/coding_style/index.html new file mode 100644 index 00000000000..9d151b33dae --- /dev/null +++ b/docs/public/main/coding_style/index.html @@ -0,0 +1,1337 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

Coding Style

+ + +
+
Documentation Moved
+
+ This documentation has been relocated to Getting Started -> Code Standards. Please use the new location for the most up-to-date information. +
+
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/common_options/index.html b/docs/public/main/common_options/index.html new file mode 100644 index 00000000000..fa6c6b1b723 --- /dev/null +++ b/docs/public/main/common_options/index.html @@ -0,0 +1,1303 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

Common Simulator Options

+

All EEST Hive simulators share common command-line options and patterns.

+

Basic Usage

+

While they may be omitted, it’s recommended to specify the fixtures and branch simulator build arguments when running EEST simulators.

+

For example, this runs “stable” fixtures from the v4.3.0 latest stable release and builds the simulator at the v4.3.0 tag:

+
./hive --sim ethereum/eest/consume-engine \
+  --sim.buildarg fixtures=stable@v4.3.0 \
+  --sim.buildarg branch=v4.3.0 \
+  --client go-ethereum
+

Test Selection

+

Run a subset of tests by filtering tests using --sim.limit=<regex> to perform a regular expression match against test IDs:

+
./hive --sim ethereum/eest/consume-engine --sim.limit ".*eip4844.*"
+

Collect Only/Dry-Run

+

The collectonly: prefix can be used to inspect which tests would match an expression (dry-run), --docker.output must be specified to see the simulator’s collection result:

+
./hive --sim ethereum/eest/consume-engine \
+     --sim.buildarg fixtures=stable@v4.3.0 \
+     --sim.buildarg branch=v4.3.0 \
+     --docker.output \
+     --sim.limit="collectonly:.*eip4844.*"
+

Exact test ID Match

+

The id: prefix can be used to select a single test via its ID (this will automatically escape any special characters in the test case ID):

+
./hive --sim ethereum/eest/consume-engine \
+     --sim.buildarg fixtures=stable@v4.3.0 \
+     --sim.buildarg branch=v4.3.0 \
+     --docker.output \
+     --sim.limit "id:tests/cancun/eip4844_blobs/test_blob_txs.py::test_sufficient_balance_blob_tx"
+

Parallelism

+

To run multiple tests in parallel, use --sim.parallelism:

+
./hive --sim ethereum/eest/consume-rlp --sim.parallelism 4
+

Output Options

+

See hive log output in the console:

+
./hive --sim ethereum/eest/consume-engine --sim.loglevel 5
+

Container Issues

+

Increase client timeout:

+
./hive --client.checktimelimit=180s --sim ethereum/eest/consume-engine
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/common_types/index.html b/docs/public/main/common_types/index.html new file mode 100644 index 00000000000..c282c04c76a --- /dev/null +++ b/docs/public/main/common_types/index.html @@ -0,0 +1,1607 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

Common Types

+

Basic Types

+

Address

+

Bytes of a 20-byte fixed length.

+

Bloom

+

Bytes of a 256-byte fixed length.

+

Bytes

+

Hexadecimal representation of binary data of any length encoded as a JSON string, with a “0x” prefix.

+

EmptyAddress

+

An empty JSON string "", used to represent an empty address. E.g. in the to field of a transaction when it is a contract creation.

+

Hash

+

Bytes of a 32-byte fixed length.

+

HeaderNonce

+

Bytes of a 8-byte fixed length.

+

HexNumber

+

Hexadecimal number with “0x” prefix encoded as a JSON string.

+

List

+

A JSON array where each element is a specific type, also defined in this document. +E.g. List[Address] is a JSON array where each element is an Ethereum address.

+

Mapping

+

A JSON object where the keys and values are specific types, also defined in this document. +E.g. Mapping[Address, Account] is a JSON object where the keys are Ethereum addresses, and the values are Ethereum accounts.

+

Number

+

Decimal number encoded as a JSON string.

+

Optional

+

Marks a field as optional, meaning that the field can be missing from the JSON object.

+

ZeroPaddedHexNumber

+

Hexadecimal number with “0x” prefix encoded as a JSON string, with a single zero used to pad odd number of digits, and zero represented as “0x00”.

+

Composite Types

+

Storage: Mapping[Hash,Hash]

+

Storage represented as a JSON object, where the keys and values are represented with the Hash type.

+

Account

+

An Ethereum account represented as a JSON object with the following fields:

+

- balance: ZeroPaddedHexNumber

+

Balance of the account.

+

- nonce: ZeroPaddedHexNumber

+

Nonce of the account.

+

- code: Bytes

+

Code of the account.

+

- storage: Storage

+

Storage of the account.

+

Alloc: Mapping[Address,Account]

+

State allocation represented as a JSON object, where the keys are the addresses of the accounts, and the values are the accounts.

+

BlobSchedule: Mapping[Fork,ForkBlobSchedule]

+

Maps forks to blob schedule configurations as defined by EIP-7840.

+

Environment

+

Contains blockchain-related configuration that provides the context in which a test is run.

+

ForkBlobSchedule

+

A fork blob schedule as defined by EIP-7840 as a JSON dictionary with the following entries:

+

- target: ZeroPaddedHexNumber

+

The target blob count for a block.

+

- max: ZeroPaddedHexNumber

+

The maximum possible blob count for a block.

+

- base_fee_update_fraction: ZeroPaddedHexNumber

+

The blob base fee update fraction (adjusts the responsiveness of blob gas pricing per fork).

+

Fork

+

Fork type is represented as a JSON string that can be set to one of the following values:

+

"Frontier"

+
    +
  • Chain ID: 0x00
  • +
+

"Homestead"

+
    +
  • Chain ID: 0x01
  • +
  • Homestead Block: 0x00
  • +
+

"Byzantium"

+
    +
  • Chain ID: 0x01
  • +
  • Homestead Block: 0x00
  • +
  • EIP150 Block: 0x00
  • +
  • EIP155 Block: 0x00
  • +
  • EIP158 Block: 0x00
  • +
  • DAO Fork Block: 0x00
  • +
  • Byzantium Block: 0x00
  • +
+

"Constantinople"

+
    +
  • Chain ID: 0x01
  • +
  • Homestead Block: 0x00
  • +
  • EIP150 Block: 0x00
  • +
  • EIP155 Block: 0x00
  • +
  • EIP158 Block: 0x00
  • +
  • DAO Fork Block: 0x00
  • +
  • Byzantium Block: 0x00
  • +
  • Constantinople Block: 0x00
  • +
+

"ConstantinopleFix"

+
    +
  • Chain ID: 0x01
  • +
  • Homestead Block: 0x00
  • +
  • EIP150 Block: 0x00
  • +
  • EIP155 Block: 0x00
  • +
  • EIP158 Block: 0x00
  • +
  • DAO Fork Block: 0x00
  • +
  • Byzantium Block: 0x00
  • +
  • Constantinople Block: 0x00
  • +
  • Constantinople Fix Block: 0x00
  • +
+

"Istanbul"

+
    +
  • Chain ID: 0x01
  • +
  • Homestead Block: 0x00
  • +
  • EIP150 Block: 0x00
  • +
  • EIP155 Block: 0x00
  • +
  • EIP158 Block: 0x00
  • +
  • DAO Fork Block: 0x00
  • +
  • Byzantium Block: 0x00
  • +
  • Constantinople Block: 0x00
  • +
  • Constantinople Fix Block: 0x00
  • +
  • Istanbul Block: 0x00
  • +
+

"MuirGlacier"

+
    +
  • Chain ID: 0x01
  • +
  • Homestead Block: 0x00
  • +
  • EIP150 Block: 0x00
  • +
  • EIP155 Block: 0x00
  • +
  • EIP158 Block: 0x00
  • +
  • DAO Fork Block: 0x00
  • +
  • Byzantium Block: 0x00
  • +
  • Constantinople Block: 0x00
  • +
  • Constantinople Fix Block: 0x00
  • +
  • Istanbul Block: 0x00
  • +
  • Muir Glacier Block: 0x00
  • +
+

"Berlin"

+
    +
  • Chain ID: 0x01
  • +
  • Homestead Block: 0x00
  • +
  • EIP150 Block: 0x00
  • +
  • EIP155 Block: 0x00
  • +
  • EIP158 Block: 0x00
  • +
  • DAO Fork Block: 0x00
  • +
  • Byzantium Block: 0x00
  • +
  • Constantinople Block: 0x00
  • +
  • Constantinople Fix Block: 0x00
  • +
  • Istanbul Block: 0x00
  • +
  • Muir Glacier Block: 0x00
  • +
  • Berlin Block: 0x00
  • +
+

"BerlinToLondonAt5"

+
    +
  • Chain ID: 0x01
  • +
  • Homestead Block: 0x00
  • +
  • EIP150 Block: 0x00
  • +
  • EIP155 Block: 0x00
  • +
  • EIP158 Block: 0x00
  • +
  • DAO Fork Block: 0x00
  • +
  • Byzantium Block: 0x00
  • +
  • Constantinople Block: 0x00
  • +
  • Constantinople Fix Block: 0x00
  • +
  • Istanbul Block: 0x00
  • +
  • Muir Glacier Block: 0x00
  • +
  • Berlin Block: 0x00
  • +
  • London Block: 0x05
  • +
+

"London"

+
    +
  • Chain ID: 0x01
  • +
  • Homestead Block: 0x00
  • +
  • EIP150 Block: 0x00
  • +
  • EIP155 Block: 0x00
  • +
  • EIP158 Block: 0x00
  • +
  • DAO Fork Block: 0x00
  • +
  • Byzantium Block: 0x00
  • +
  • Constantinople Block: 0x00
  • +
  • Constantinople Fix Block: 0x00
  • +
  • Istanbul Block: 0x00
  • +
  • Muir Glacier Block: 0x00
  • +
  • Berlin Block: 0x00
  • +
  • London Block: 0x00
  • +
+

"ArrowGlacier"

+
    +
  • Chain ID: 0x01
  • +
  • Homestead Block: 0x00
  • +
  • EIP150 Block: 0x00
  • +
  • EIP155 Block: 0x00
  • +
  • EIP158 Block: 0x00
  • +
  • DAO Fork Block: 0x00
  • +
  • Byzantium Block: 0x00
  • +
  • Constantinople Block: 0x00
  • +
  • Constantinople Fix Block: 0x00
  • +
  • Istanbul Block: 0x00
  • +
  • Muir Glacier Block: 0x00
  • +
  • Berlin Block: 0x00
  • +
  • London Block: 0x00
  • +
  • Arrow Glacier Block: 0x00
  • +
+

"GrayGlacier"

+
    +
  • Chain ID: 0x01
  • +
  • Homestead Block: 0x00
  • +
  • EIP150 Block: 0x00
  • +
  • EIP155 Block: 0x00
  • +
  • EIP158 Block: 0x00
  • +
  • DAO Fork Block: 0x00
  • +
  • Byzantium Block: 0x00
  • +
  • Constantinople Block: 0x00
  • +
  • Constantinople Fix Block: 0x00
  • +
  • Istanbul Block: 0x00
  • +
  • Muir Glacier Block: 0x00
  • +
  • Berlin Block: 0x00
  • +
  • London Block: 0x00
  • +
  • Arrow Glacier Block: 0x00
  • +
  • Gray Glacier Block: 0x00
  • +
+

"Merge"

+
    +
  • Chain ID: 0x01
  • +
  • Homestead Block: 0x00
  • +
  • EIP150 Block: 0x00
  • +
  • EIP155 Block: 0x00
  • +
  • EIP158 Block: 0x00
  • +
  • DAO Fork Block: 0x00
  • +
  • Byzantium Block: 0x00
  • +
  • Constantinople Block: 0x00
  • +
  • Constantinople Fix Block: 0x00
  • +
  • Istanbul Block: 0x00
  • +
  • Muir Glacier Block: 0x00
  • +
  • Berlin Block: 0x00
  • +
  • London Block: 0x00
  • +
  • Arrow Glacier Block: 0x00
  • +
  • Gray Glacier Block: 0x00
  • +
  • Terminal Total Difficulty: 0x00
  • +
+

"MergeToShanghaiAtTime15k"

+
    +
  • Chain ID: 0x01
  • +
  • Homestead Block: 0x00
  • +
  • EIP150 Block: 0x00
  • +
  • EIP155 Block: 0x00
  • +
  • EIP158 Block: 0x00
  • +
  • DAO Fork Block: 0x00
  • +
  • Byzantium Block: 0x00
  • +
  • Constantinople Block: 0x00
  • +
  • Constantinople Fix Block: 0x00
  • +
  • Istanbul Block: 0x00
  • +
  • Muir Glacier Block: 0x00
  • +
  • Berlin Block: 0x00
  • +
  • London Block: 0x00
  • +
  • Arrow Glacier Block: 0x00
  • +
  • Gray Glacier Block: 0x00
  • +
  • Terminal Total Difficulty: 0x00
  • +
  • Shanghai Time: 0x3a98
  • +
+

"Shanghai"

+
    +
  • Chain ID: 0x01
  • +
  • Homestead Block: 0x00
  • +
  • EIP150 Block: 0x00
  • +
  • EIP155 Block: 0x00
  • +
  • EIP158 Block: 0x00
  • +
  • DAO Fork Block: 0x00
  • +
  • Byzantium Block: 0x00
  • +
  • Constantinople Block: 0x00
  • +
  • Constantinople Fix Block: 0x00
  • +
  • Istanbul Block: 0x00
  • +
  • Muir Glacier Block: 0x00
  • +
  • Berlin Block: 0x00
  • +
  • London Block: 0x00
  • +
  • Arrow Glacier Block: 0x00
  • +
  • Gray Glacier Block: 0x00
  • +
  • Terminal Total Difficulty: 0x00
  • +
  • Shanghai Time: 0x00
  • +
+

"ShanghaiToCancunAtTime15k"

+
    +
  • Chain ID: 0x01
  • +
  • Homestead Block: 0x00
  • +
  • EIP150 Block: 0x00
  • +
  • EIP155 Block: 0x00
  • +
  • EIP158 Block: 0x00
  • +
  • DAO Fork Block: 0x00
  • +
  • Byzantium Block: 0x00
  • +
  • Constantinople Block: 0x00
  • +
  • Constantinople Fix Block: 0x00
  • +
  • Istanbul Block: 0x00
  • +
  • Muir Glacier Block: 0x00
  • +
  • Berlin Block: 0x00
  • +
  • London Block: 0x00
  • +
  • Arrow Glacier Block: 0x00
  • +
  • Gray Glacier Block: 0x00
  • +
  • Terminal Total Difficulty: 0x00
  • +
  • Shanghai Time: 0x0
  • +
  • Cancun Time: 0x3a98
  • +
+

"Cancun"

+
    +
  • Chain ID: 0x01
  • +
  • Homestead Block: 0x00
  • +
  • EIP150 Block: 0x00
  • +
  • EIP155 Block: 0x00
  • +
  • EIP158 Block: 0x00
  • +
  • DAO Fork Block: 0x00
  • +
  • Byzantium Block: 0x00
  • +
  • Constantinople Block: 0x00
  • +
  • Constantinople Fix Block: 0x00
  • +
  • Istanbul Block: 0x00
  • +
  • Muir Glacier Block: 0x00
  • +
  • Berlin Block: 0x00
  • +
  • London Block: 0x00
  • +
  • Arrow Glacier Block: 0x00
  • +
  • Gray Glacier Block: 0x00
  • +
  • Terminal Total Difficulty: 0x00
  • +
  • Shanghai Time: 0x00
  • +
  • Cancun Time: 0x00
  • +
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/configurations/index.html b/docs/public/main/configurations/index.html new file mode 100644 index 00000000000..d2ac6c09984 --- /dev/null +++ b/docs/public/main/configurations/index.html @@ -0,0 +1,1364 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

Managing Configurations

+

Configurations are managed by the config package. It provides both environment and application configurations.

+
.
+β”œβ”€β”€ src
+β”‚   └── πŸ“ config  [Application wide environment and configurations]
+β”‚       β”œβ”€β”€ πŸ“„ __init__.py
+β”‚       β”œβ”€β”€ πŸ“„ app.py [Configurations for application framework]
+β”‚       β”œβ”€β”€ πŸ“„ docs.py [Configurations for documentation]
+β”‚       └── πŸ“„ env.py  [Exposes `env.yaml` to the application]
+└── πŸ“„ env.yaml [Environment file (git ignored)]
+

Environment Configurations

+

Application-wide environment configuration, which varies across staging, production, and development environments are read from env.yaml in the project root.

+

This file will not be tracked by git, making it safe for storing local secrets.

+

To get started, run the command eest make env cli to initialize your environment configuration.

+

Usage

+

1. Generate env file

+

Run the eest make env cli tool.

+
uv run eest make env
+πŸŽ‰ Success! Config file created at: <path>/env.yaml
+

which should generate an env.yaml in the project root.

+
remote_nodes:
+  - name: mainnet_archive
+    # Replace with your Ethereum RPC node URL
+    node_url: http://example.com
+    # Optional: Headers for RPC requests
+    rpc_headers:
+      client-secret: <secret>
+

2. Import EnvConfig

+
from config import EnvConfig
+EnvConfig().remote_nodes[0].name
+'mainnet_archive'
+

Application configuration

+

Application configuration are pydantic classes.

+
from config import DocsConfig
+DocsConfig().TARGET_FORK
+'Prague'
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/debugging_t8n_tools/index.html b/docs/public/main/debugging_t8n_tools/index.html new file mode 100644 index 00000000000..f9a793aa283 --- /dev/null +++ b/docs/public/main/debugging_t8n_tools/index.html @@ -0,0 +1,1433 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

Debugging Transition Tools

+

There are two flags that can help debugging t8n tools or the execution-spec-tests framework:

+
    +
  1. --evm-dump-dir (Default: /logs/evm): Write debug information from t8n tool calls to the specified directory.
  2. +
  3. --traces: Collect traces of the execution from the transition tool.
  4. +
  5. --verify-fixtures: Run go-ethereum’s evm blocktest command to verify the generated test fixtures.
  6. +
+

EVM Dump Directory

+

The --evm-dump-dir flag tells the framework to write the inputs and outputs of every call made to the t8n command to the specified output directory. The aim is to help debugging or simply understand how a test is interacting with the EVM. The default location is logs/evm in the project root.

+

Each test case receives its own sub-directory under the --evm-dump-dir that contains these files which can be easily accessed from the HTML test report generated by fill (located by default in the root of the --output directory).

+
+ ![HTML Report Summary](./img/evm_dump_dir_in_html_report.png){width=auto align=center} +
+

In particular, a script t8n.sh is generated for each call to the t8n command which can be used to reproduce the call to trigger errors or attach a debugger without the need to execute Python.

+

For example, running:

+
fill tests/berlin/eip2930_access_list/ --fork Berlin -m blockchain_test \
+    --evm-dump-dir=/tmp/evm-dump --traces
+

will produce the directory structure:

+
πŸ“‚ /tmp/evm-dump
+└── πŸ“‚ berlin__eip2930_access_list__test_acl__test_access_list
+    └── πŸ“‚ fork_Berlin_blockchain_test
+        └── πŸ“‚ 0
+         Β Β  β”œβ”€β”€ πŸ“„ args.py
+         Β Β  β”œβ”€β”€ πŸ“‚ input
+         Β Β  β”‚Β Β  β”œβ”€β”€ πŸ“„ alloc.json
+         Β Β  β”‚Β Β  β”œβ”€β”€ πŸ“„ env.json
+         Β Β  β”‚Β Β  └── πŸ“„ txs.json
+         Β Β  β”œβ”€β”€ πŸ“‚ output
+         Β Β  β”‚Β Β  β”œβ”€β”€ πŸ“„ alloc.json
+         Β Β  β”‚Β Β  β”œβ”€β”€ πŸ“„ result.json
+         Β Β  β”‚Β Β  └── πŸ“„ txs.rlp
+         Β Β  β”œβ”€β”€ πŸ“„ returncode.txt
+         Β Β  β”œβ”€β”€ πŸ“„ stderr.txt
+         Β Β  β”œβ”€β”€ πŸ“„ stdin.txt
+         Β Β  β”œβ”€β”€ πŸ“„ stdout.txt
+         Β Β  β”œβ”€β”€ πŸ“„ t8n.sh
+            └── πŸ“„ trace-0-0x5c4f07ce52f0a276a06aabdfff16cc693b5e007c018f9a42431e68200e2da515.jsonl
+

where the directory 0 is the starting index of the different calls made to the t8n tool executed during the test, and since the test only contains one block, there is only one directory present.

+

Note, there may be more directories present 1, 2, 3,… if the test executes more blocks.

+

Each directory contains files containing information corresponding to the call, for example, the args.py file contains the arguments passed to the t8n command and the output/alloc.json file contains the output of the t8n command’s --output-alloc flag.

+

The t8n.sh Script

+

The t8n.sh script written to the debug directory can be used to reproduce a specific call made to the t8n command during the test session. For example, if a Besu t8n-server has been started on port 3001, the request made by the test for first block can be reproduced as:

+
/tmp/besu/test_access_list_fork_Berlin/0/t8n.sh 3001
+

which writes the response the from the t8n-server to the console output:

+
{
+  "alloc" : {
+    "0x000000000000000000000000000000000000aaaa" : {
+      "code" : "0x5854505854",
+      "balance" : "0x4",
+      "nonce" : "0x1"
+    },
+    "0x2adc25665018aa1fe0e6bc666dac8fc2697ff9ba" : {
+      "balance" : "0x1bc16d674ecb26ce"
+    },
+    "0xa94f5374fce5edbc8e2a8697c15331677e6ebf0b" : {
+      "balance" : "0x2cd931",
+      "nonce" : "0x1"
+    }
+  },
+  "body" : "0xf8a0b89e01f89b0180078304ef0094000000000000000000000000000000000000aaaa0180f838f7940000000000000000000000000000000000000000e1a0000000000000000000000000000000000000000000000000000000000000000001a02e16eb72206c93c471b5894800495ee9c64ae2d9823bcc4d6adeb5d9d9af0dd4a03be6691e933a0816c59d059a556c27c6753e6ce76d1e357b9201865c80b28df3",
+  "result" : {
+    "stateRoot" : "0x51799508f764047aee6606bc6a00863856f83ee5b91555f00c8a3cbdfbec5acb",
+    ...
+    ...
+  }
+}
+

The t8n.sh is written to the debug directory for all supported t8n tools.

+

Verifying Test Fixtures via evm blocktest

+

The --verify-fixtures flag can be used to run go-ethereum’s evm blocktest command in order to verify the generated JSON test fixtures.

+

For example, running:

+
fill tests/berlin/eip2930_access_list/ --fork Berlin -m blockchain_test \
+    --evm-dump-dir==/tmp/evm-dump \
+    --evm-bin=../evmone/build/bin/evmone-t8n \
+    --verify-fixtures-bin=../go-ethereum/build/bin/evm \
+    --verify-fixtures
+

will additionally run the evm blocktest command on every JSON fixture file and write its output to the EVM dump directory:

+
πŸ“‚ /tmp/evm-dump
+└── πŸ“‚ berlin__eip2930_access_list__test_acl__test_access_list
+    β”œβ”€β”€ πŸ“„ fixtures.json
+    β”œβ”€β”€ πŸ“‚ fork_Berlin_blockchain_test
+    β”‚Β Β  β”œβ”€β”€ πŸ“‚ 0
+    β”‚Β Β  β”‚Β Β  β”œβ”€β”€ πŸ“„ args.py
+    β”‚Β Β  β”‚Β Β  β”œβ”€β”€ πŸ“‚ input
+    β”‚Β Β  β”‚Β Β  β”‚Β Β  β”œβ”€β”€ πŸ“„ alloc.json
+    β”‚Β Β  β”‚Β Β  β”‚Β Β  β”œβ”€β”€ πŸ“„ env.json
+    β”‚Β Β  β”‚Β Β  β”‚Β Β  └── πŸ“„ txs.json
+    β”‚Β Β  β”‚Β Β  β”œβ”€β”€ πŸ“‚ output
+    β”‚Β Β  β”‚Β Β  β”‚Β Β  β”œβ”€β”€ πŸ“„ alloc.json
+    β”‚   ... ... ...
+    β”‚
+    β”œβ”€β”€ πŸ“„ verify_fixtures_args.py
+    β”œβ”€β”€ πŸ“„ verify_fixtures_returncode.txt
+    β”œβ”€β”€ πŸ“„ verify_fixtures.sh
+    β”œβ”€β”€ πŸ“„ verify_fixtures_stderr.txt
+    └── πŸ“„ verify_fixtures_stdout.txt
+

where the verify_fixtures.sh script can be used to reproduce the evm blocktest command.

+

Further --verify-fixtures Examples

+
    +
  1. +

    No fixture verification performed:

    +
    fill
    +
  2. +
  3. +

    Verify fixtures: Use the first evm binary in the PATH to execute both the t8n and blocktest commands (i.e., same binary used; this must be a geth binary):

    +
    fill --verify-fixtures
    +
  4. +
  5. +

    Explicitly specify the evm binary to execute the blocktest command (the first evm binary in the PATH is used for t8n commands; --verify-fixtures is not necessary):

    +
    fill --verify-fixtures-bin=../go-ethereum/build/bin/evm
    +
  6. +
  7. +

    Explicitly set two different evm binaries to execute the t8n and blocktest commands; write debug data to the specified --evm-dump-dir:

    +
    fill --evm-bin=../evmone/build/bin/evmone-t8n \
    +  --verify-fixtures-bin=../go-ethereum/build/bin/evm \
    +  --evm-dump-dir=/tmp/evm-dump
    +
  8. +
  9. +

    Additionally use --single-fixture-per-file to improve the granularity of the reporting of the evm blocktest command by writing the fixture generated by each parametrized test case to its own file.

    +
    fill --evm-bin=../evmone/build/bin/evmone-t8n \
    +  --verify-fixtures-bin=../go-ethereum/build/bin/evm \
    +  --evm-dump-dir=/tmp/evm-dump \
    +  --single-fixture-per-file
    +
  10. +
+ + +
+
Execution scope of evm blocktest
+
+

Note, by default, that evm blocktest is not executed per parametrized test case, but rather per test function. This is because each fixture JSON file contains fixtures for all the parametrized test cases for one test function. This means only one error will be reported, even if multiple fixtures fail within one fixture file.

+

Additionally, it is only executed after all the test cases in the module have been executed and will only report the first failing test fixture in all files, even if there are multiple failing fixture files. This limitation is required to enable support of the pytest-xdist plugin for concurrent test execution across multiple CPUs. To achieve this we use the we apply the --dist loadscope xdist flag in our pytest.ini.

+

This means, by default, that the feedback is not as granular as for test case execution. To improve granularity, and get feedback per parametrized test case use --single-fixture-per-file.

+ +
+
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/deps_and_packaging/index.html b/docs/public/main/deps_and_packaging/index.html new file mode 100644 index 00000000000..f734538d64f --- /dev/null +++ b/docs/public/main/deps_and_packaging/index.html @@ -0,0 +1,1410 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

EEST Dependency Management and Packaging

+

EEST uses uv to manage and pin its dependencies.

+

Please use uv>=0.7.0 to ensure uv writes uv.lock files with consistent fields and formatting (see [ethereum/execution-spec-tests#1597]https://github.com/ethereum/execution-spec-tests/pull/1597).

+

Managing Dependencies

+

We aim to provide specific version specifiers for each of our direct and extra dependencies.

+ + +
+
Packages should be managed via uv
+
+

Dependencies should be managed using uv on the command-line to ensure that version compatibility is ensured across all dependencies and that uv.lock is updated as required.

+

The docs below cover common operations, see the uv documentation on managing dependencies for more information.

+ +
+
+ + +
+
Separate PRs are preferred when managing dependencies
+
+

An upgrade of all pinned dependencies in uv.lock must be performed in a dedicated PR!

+

For other dependency changes, they can be included in the PR that removed use of the library, for example. But if a version bump is made, without related source code changes, it should be done in a dedicated PR. This makes the change:

+
    +
  • Easier to track.
  • +
  • Trivial to revert.
  • +
+ +
+
+

Adding/modifying direct dependencies

+

These are packages listed in the project’s direct dependencies, i.e., in pyproject.toml [project] section:

+
[project]
+...
+dependencies = [
+    "click>=8.1.0,<9",
+    ...
+    "pytest-regex>=0.2.0,<0.3",
+]
+

or, for source package dependencies (directly installed via a git+ specifier from Github), in the [tool.uv.sources] section:

+
[tool.uv.sources]
+ethereum-spec-evm-resolver = { git = "https://github.com/petertdavies/ethereum-spec-evm-resolver", rev = \
+...
+
+ +
+
Example: Updating direct dependencies
+
+

Example of a package dependency update:

+
uv add "requests>=2.31,<2.33"
+

Example of a source dependency update:

+
uv add "ethereum-spec-evm-resolver @ git+https://github.com/petertdavies/ethereum-spec-evm-resolver@623ac4565025e72b65f45b926da2a3552041b469"
+
+
+
+

Adding/modifying optional dependencies

+

The package versions in the optional “extra” groups should also be managed via uv on the command-line These are the: lint, docs, test optional groups defined in the pyproject.toml:

+
[project.optional-dependencies]
+test = ["pytest-cov>=4.1.0,<5"]
+lint = [
+    "ruff==0.9.4",
+    "mypy>=1.15.0,<1.16",
+    "types-requests>=2.31,<2.33",
+]
+docs = [
+    ...
+]
+
+ +
+
Example: Updating an optional dependency
+
+
uv add --optional lint "types-requests>=2.31,<2.33"
+
+
+
+

Upgrading Pinned Dependencies in uv.lock

+

To upgrade all pinned dependencies in uv.lock to the latest version permitted by EEST’s project.toml version specifiers run:

+
uv lock --upgrade
+

Project-wide dependency upgrades must be made via a dedicated PR!

+

To upgrade a single package run:

+
uv lock --upgrade-package <package>
+

See Locking and Syncing in the uv docs for more information.

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/dev/index.html b/docs/public/main/dev/index.html new file mode 100644 index 00000000000..d26ce0a2a70 --- /dev/null +++ b/docs/public/main/dev/index.html @@ -0,0 +1,505 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
+ + + + +
+
+

+
+ + +
+

Developer Documentation

+

This documentation is aimed at execution-spec-tests developers:

+
    +
  • Managing configurations: Instructions for setting up and modifying test configurations.
  • +
  • Interactive usage: Guide on interactive use of EEST packages using ipython.
  • +
  • Documenting CLI commands: Instructions for documenting command line interfaces (CLIs).
  • +
  • Coding style: Standards and best practices for code formatting and to maintain consistency across the repository.
  • +
  • Logging: Documentation on using the custom logging system with enhanced features.
  • +
  • Enabling pre-commit checks: A guide for setting up pre-commit hooks to enforce code quality before commits.
  • +
  • Running github actions locally: Instructions for testing GitHub Actions workflows on your local machine to streamline development and debugging.
  • +
+

These sections are primarily aimed at execution-spec-tests maintainers:

+ +
+
+
+
+
+ +
+ + + + + + + diff --git a/docs/public/main/dev_docs/coding_style/index.html b/docs/public/main/dev_docs/coding_style/index.html new file mode 100644 index 00000000000..5033ec29bfa --- /dev/null +++ b/docs/public/main/dev_docs/coding_style/index.html @@ -0,0 +1,1330 @@ + + + + + + + Coding Style - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

Coding Style

+
+ +
+
+ +
+
Documentation Moved
+
+ This documentation has been relocated to Getting Started -> Code Standards. Please use the new location for the most up-to-date information. +
+
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/dev_docs/configurations/index.html b/docs/public/main/dev_docs/configurations/index.html new file mode 100644 index 00000000000..176c86a2346 --- /dev/null +++ b/docs/public/main/dev_docs/configurations/index.html @@ -0,0 +1,1357 @@ + + + + + + + Managing Configurations - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

Managing Configurations

+
+ +
+

Configurations are managed by the config package. It provides both environment and application configurations.

+
.
+β”œβ”€β”€ src
+β”‚   └── πŸ“ config  [Application wide environment and configurations]
+β”‚       β”œβ”€β”€ πŸ“„ __init__.py
+β”‚       β”œβ”€β”€ πŸ“„ app.py [Configurations for application framework]
+β”‚       β”œβ”€β”€ πŸ“„ docs.py [Configurations for documentation]
+β”‚       └── πŸ“„ env.py  [Exposes `env.yaml` to the application]
+└── πŸ“„ env.yaml [Environment file (git ignored)]
+

Environment Configurations

+

Application-wide environment configuration, which varies across staging, production, and development environments are read from env.yaml in the project root.

+

This file will not be tracked by git, making it safe for storing local secrets.

+

To get started, run the command eest make env cli to initialize your environment configuration.

+

Usage

+

1. Generate env file

+

Run the eest make env cli tool.

+
uv run eest make env
+πŸŽ‰ Success! Config file created at: <path>/env.yaml
+

which should generate an env.yaml in the project root.

+
remote_nodes:
+  - name: mainnet_archive
+    # Replace with your Ethereum RPC node URL
+    node_url: http://example.com
+    # Optional: Headers for RPC requests
+    rpc_headers:
+      client-secret: <secret>
+

2. Import EnvConfig

+
from config import EnvConfig
+EnvConfig().remote_nodes[0].name
+'mainnet_archive'
+

Application configuration

+

Application configuration are pydantic classes.

+
from config import DocsConfig
+DocsConfig().TARGET_FORK
+'Prague'
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/dev_docs/deps_and_packaging/index.html b/docs/public/main/dev_docs/deps_and_packaging/index.html new file mode 100644 index 00000000000..383a123ca12 --- /dev/null +++ b/docs/public/main/dev_docs/deps_and_packaging/index.html @@ -0,0 +1,1403 @@ + + + + + + + Dependency Management and Packaging - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

Dependency Management and Packaging

+
+ +
+

EEST uses uv to manage and pin its dependencies.

+

Please use uv>=0.7.0 to ensure uv writes uv.lock files with consistent fields and formatting (see ethereum/execution-spec-tests#1597).

+

Managing Dependencies

+

We aim to provide specific version specifiers for each of our direct and extra dependencies.

+ + +
+
Packages should be managed via uv
+
+

Dependencies should be managed using uv on the command-line to ensure that version compatibility is ensured across all dependencies and that uv.lock is updated as required.

+

The docs below cover common operations, see the uv documentation on managing dependencies for more information.

+ +
+
+ + +
+
Separate PRs are preferred when managing dependencies
+
+

An upgrade of all pinned dependencies in uv.lock must be performed in a dedicated PR!

+

For other dependency changes, they can be included in the PR that removed use of the library, for example. But if a version bump is made, without related source code changes, it should be done in a dedicated PR. This makes the change:

+
    +
  • Easier to track.
  • +
  • Trivial to revert.
  • +
+ +
+
+

Adding/modifying direct dependencies

+

These are packages listed in the project’s direct dependencies, i.e., in pyproject.toml [project] section:

+
[project]
+...
+dependencies = [
+    "click>=8.1.0,<9",
+    ...
+    "pytest-regex>=0.2.0,<0.3",
+]
+

or, for source package dependencies (directly installed via a git+ specifier from Github), in the [tool.uv.sources] section:

+
[tool.uv.sources]
+ethereum-spec-evm-resolver = { git = "https://github.com/petertdavies/ethereum-spec-evm-resolver", rev = \
+...
+
+ +
+
Example: Updating direct dependencies
+
+

Example of a package dependency update:

+
uv add "requests>=2.31,<2.33"
+

Example of a source dependency update:

+
uv add "ethereum-spec-evm-resolver @ git+https://github.com/petertdavies/ethereum-spec-evm-resolver@623ac4565025e72b65f45b926da2a3552041b469"
+
+
+
+

Adding/modifying optional dependencies

+

The package versions in the optional “extra” groups should also be managed via uv on the command-line These are the: lint, docs, test optional groups defined in the pyproject.toml:

+
[project.optional-dependencies]
+test = ["pytest-cov>=4.1.0,<5"]
+lint = [
+    "ruff==0.9.4",
+    "mypy>=1.15.0,<1.16",
+    "types-requests>=2.31,<2.33",
+]
+docs = [
+    ...
+]
+
+ +
+
Example: Updating an optional dependency
+
+
uv add --optional lint "types-requests>=2.31,<2.33"
+
+
+
+

Upgrading Pinned Dependencies in uv.lock

+

To upgrade all pinned dependencies in uv.lock to the latest version permitted by EEST’s project.toml version specifiers run:

+
uv lock --upgrade
+

Project-wide dependency upgrades must be made via a dedicated PR!

+

To upgrade a single package run:

+
uv lock --upgrade-package <package>
+

See Locking and Syncing in the uv docs for more information.

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/dev_docs/docs/index.html b/docs/public/main/dev_docs/docs/index.html new file mode 100644 index 00000000000..11994a12f88 --- /dev/null +++ b/docs/public/main/dev_docs/docs/index.html @@ -0,0 +1,1350 @@ + + + + + + + Documentation - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

Documentation

+
+ +
+

The execution-spec-tests documentation is generated via hugo and hosted remotely on Github Pages at eest.ethereum.org.

+

Prerequisites

+

Grab the latest hugo binary from the official release page or build it yourself. Then make the binary executable and add it to the PATH (or to a directory that has already been added to the PATH like e.g. /usr/local/bin/). We do not require any additional plugins or dependencies.

+

Build and Locally Host the Documentation

+

Build the docs:

+
hugo
+

If you want to build + locally host the docs:

+
hugo server
+

Remote Deployment and Versioning

+

The execution-specs-test docs are hosted using Github pages at eest.ethereum.org. Versions are updated/deployed automatically as part of Github Actions.

+

CI/CD: Doc Deployment via Github Actions

+

This is our workflow that automatically deploys updated/new versions of the docs:

+ + + + + + + + + + + + + + + +
Workflow yaml FileWhatWhen
docs.yamlDeploy new version of docs
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/dev_docs/documenting_clis/index.html b/docs/public/main/dev_docs/documenting_clis/index.html new file mode 100644 index 00000000000..66fb7eacf4a --- /dev/null +++ b/docs/public/main/dev_docs/documenting_clis/index.html @@ -0,0 +1,1329 @@ + + + + + + + Documenting CLI Commands - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

Documenting CLI Commands

+
+ +
+

EEST command line interfaces (CLIs) are documented using the click library’s built-in help system and the mkdocs-click extension for mkdocs. This allows generation of CLI documentation directly from the (click) source code, ensuring that the documentation is always up-to-date with the code.

+

Current limitations:

+
    +
  1. mkdocs serve does not automatically update the CLI documentation when the source code changes. You must restart the server to see the changes.
  2. +
  3. mkdocs-click does not automatically generate a short help string from sub-command docstrings. You must provide a short help string for each sub-command in the source code with @click.command(short_help="...").
  4. +
+

See the markdown and corresponding Python docstrings for the evm_bytes CLI documentation as an example of how to document a CLI using mkdocs-click.

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/dev_docs/index.html b/docs/public/main/dev_docs/index.html new file mode 100644 index 00000000000..677b9e21537 --- /dev/null +++ b/docs/public/main/dev_docs/index.html @@ -0,0 +1,1382 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/ + | Page.Permalink: http://localhost:1313/main/ + + +
Name: Filling Tests + | URL: /main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/ + | Page.Permalink: http://localhost:1313/main/ + + +
Name: Getting Started + | URL: /main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/ + | Page.Permalink: http://localhost:1313/main/ + + +
Name: Running Tests + | URL: /main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/ + | Page.Permalink: http://localhost:1313/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

Running Github Actions Locally

+

The Github Actions workflows can be tested locally using nektos/act without pushing changes to the remote. The local repository state will be used in the executed workflow.

+

Prerequisites

+
    +
  1. +

    A docker installation without sudo prefix requirement (see also dockerdocs):

    +
    sudo usermod -aG docker $USER
    +
  2. +
  3. +

    Install the Github CLI (gh): linux, macos.

    +
  4. +
  5. +

    Authenticate your Github account with the Github CLI:

    +
    gh auth login
    +

    This is required to set GITHUB_TOKEN to the output of gh auth token when running the workflows.

    +
  6. +
  7. +

    Install the act tool as a Github extension (nektos/act docs):

    +
    gh extension install https://github.com/nektos/gh-act
    +

    or use one of the other available methods.

    +
  8. +
+ + +
+
Updating nektos/act to the latest version via the Github CLI
+
+

The act tool can be updated via the Github CLI:

+
gh extension upgrade nektos/act
+
+
+
+

Listing the Available Workflows

+
gh act --list
+

will output something similar to:

+
INFO[0000] Using docker host 'unix:///var/run/docker.sock', and daemon socket 'unix:///var/run/docker.sock'
+Stage  Job ID                Job name                                                      Workflow name                             Workflow file          Events                             
+0      evmone-coverage-diff  evmone-coverage-diff                                          Evmone Coverage Report                    coverage.yaml          pull_request                       
+0      deploy                deploy                                                        Deploy Docs Main                          docs_main.yaml         push                               
+0      deploy                deploy                                                        Deploy Docs Tags                          docs_tags.yaml         push                               
+0      features              features                                                      Build and Package Fixtures                fixtures.yaml          push,workflow_dispatch             
+0      feature-names         feature-names                                                 Build and Package Fixtures for a feature  fixtures_feature.yaml  push,workflow_dispatch             
+0      lint                  Lint python sources with ruff                                 Tox                                       tox_verify.yaml        push,pull_request,workflow_dispatch
+0      typecheck             Typecheck python sources with mypy                            Tox                                       tox_verify.yaml        push,pull_request,workflow_dispatch
+0      spellcheck            Spellcheck sources with pyspelling                            Tox                                       tox_verify.yaml        push,pull_request,workflow_dispatch
+0      markdownlint          Lint markdown files with markdownlint                         Tox                                       tox_verify.yaml        push,pull_request,workflow_dispatch
+0      mkdocs                Build html documentation with mkdocs                          Tox                                       tox_verify.yaml        push,pull_request,workflow_dispatch
+0      pytest_framework      Run unit tests, ${{ matrix.os }}, ${{ matrix.python }}        Tox                                       tox_verify.yaml        push,pull_request,workflow_dispatch
+0      tests_deployed        Fill tests, deployed, ${{ matrix.os }}, ${{ matrix.python }}  Tox                                       tox_verify.yaml        push,pull_request,workflow_dispatch
+1      build                 build                                                         Build and Package Fixtures                fixtures.yaml          push,workflow_dispatch             
+1      build                 build                                                         Build and Package Fixtures for a feature  fixtures_feature.yaml  push,workflow_dispatch             
+2      release               release                                                       Build and Package Fixtures                fixtures.yaml          push,workflow_dispatch             
+2      release               release                                                       Build and Package Fixtures for a feature  fixtures_feature.yaml  push,workflow_dispatch
+

The Job ID is required to run a specific workflow and is provided to the -j option of gh act.

+

Running Workflows that require Github Vars

+

Create a text file containing the required variables and variables, e.g., .act_github_vars (this is in .gitignore):

+
UV_VERSION=0.5.15
+DEFAULT_PYTHON_VERSION=3.12
+

and use the --var-file option to specify the file:

+
gh act --workflows .github/workflows/tox_verify.yaml -s GITHUB_TOKEN=$(gh auth token) --var-file=gh_vars.txt -j lint 
+

Running Workflows that use a Matrix Strategy

+

This is optional, recent versions will automatically detect the matrix strategy and run supported values. To run a specific matrix value, use the --matrix option:

+
gh act --workflows .github/workflows/tox_verify.yaml -s GITHUB_TOKEN=$(gh auth token) --matrix python:3.12 -j pytest_framework
+

Running Release Workflows

+

Release builds require the ref input to be specified. To test a release build locally:

+
    +
  1. +

    Create a JSON file specifying the input data required for a release build (the release tag), e.g, event.json:

    +
    {
    +    "ref": "refs/tags/stable@v4.2.0"
    +}
    +
  2. +
  3. +

    Run act and specify the workflow file, the Github token, and the event file:

    +
    gh act -j build --workflows .github/workflows/fixtures_feature.yaml -s GITHUB_TOKEN=$(gh auth token) -e event.json
    +
  4. +
+

Manually Specifying the Docker Image

+

It’s possible to specify the Docker image used by the act tool for a specific platform defined in a workflow using the -P (--platform) option. For example, use map ubuntu-latest in the workflow to use ubuntu-24.04:

+
-P ubuntu-latest=ubuntu:24.04
+

This can be added to any gh act command.

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/dev_docs/index.xml b/docs/public/main/dev_docs/index.xml new file mode 100644 index 00000000000..dc8c97fc6b4 --- /dev/null +++ b/docs/public/main/dev_docs/index.xml @@ -0,0 +1,75 @@ + + + + Developer Documentation on EEST Docs + http://localhost:1313/main/dev_docs/ + Recent content in Developer Documentation on EEST Docs + Hugo + en-us + Mon, 01 Jan 0001 00:00:00 +0000 + + + + http://localhost:1313/main/dev_docs/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/dev_docs/ + <h1 id="coding-style">Coding Style</h1> <div class="callout callout-warning"> <div class="callout-title">Documentation Moved</div> <div class="callout-content"> This documentation has been relocated to <a href="../getting_started/code_standards.md">Getting Started -&gt; Code Standards</a>. Please use the new location for the most up-to-date information. </div> </div> + + + + http://localhost:1313/main/dev_docs/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/dev_docs/ + <h1 id="managing-configurations">Managing Configurations</h1> <p>Configurations are managed by the <code>config</code> package. It provides both environment and application configurations.</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-console" data-lang="console"><span style="display:flex;"><span>. </span></span><span style="display:flex;"><span>β”œβ”€β”€ src </span></span><span style="display:flex;"><span>β”‚ └── πŸ“ config [Application wide environment and configurations] </span></span><span style="display:flex;"><span>β”‚ β”œβ”€β”€ πŸ“„ __init__.py </span></span><span style="display:flex;"><span>β”‚ β”œβ”€β”€ πŸ“„ app.py [Configurations for application framework] </span></span><span style="display:flex;"><span>β”‚ β”œβ”€β”€ πŸ“„ docs.py [Configurations for documentation] </span></span><span style="display:flex;"><span>β”‚ └── πŸ“„ env.py [Exposes `env.yaml` to the application] </span></span><span style="display:flex;"><span>└── πŸ“„ env.yaml [Environment file (git ignored)] </span></span></code></pre></div><h2 id="environment-configurations">Environment Configurations</h2> <p>Application-wide <a href="https://www.12factor.net/config" target="_blank" rel="noopener">environment configuration</a>, which varies across staging, production, and development environments are read from <code>env.yaml</code> in the project root.</p> + + + + http://localhost:1313/main/dev_docs/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/dev_docs/ + <h1 id="eest-dependency-management-and-packaging">EEST Dependency Management and Packaging</h1> <p>EEST uses <a href="https://docs.astral.sh/uv/" target="_blank" rel="noopener"><code>uv</code></a> to manage and pin its dependencies.</p> <p>Please use <code>uv&gt;=0.7.0</code> to ensure <code>uv</code> writes <code>uv.lock</code> files with consistent fields and formatting (see [ethereum/execution-spec-tests#1597]https://github.com/ethereum/execution-spec-tests/pull/1597).</p> <h2 id="managing-dependencies">Managing Dependencies</h2> <p>We aim to provide specific <a href="https://peps.python.org/pep-0440/#version-specifiers" target="_blank" rel="noopener">version specifiers</a> for each of our direct and extra dependencies.</p> <div class="callout callout-info"> <div class="callout-title">Packages should be managed via <code>uv</code></div> <div class="callout-content"> <p>Dependencies should be managed using <code>uv</code> on the command-line to ensure that version compatibility is ensured across all dependencies and that <code>uv.lock</code> is updated as required.</p> + + + + http://localhost:1313/main/dev_docs/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/dev_docs/ + <h1 id="documentation">Documentation</h1> <p>The <code>execution-spec-tests</code> documentation is generated via <a href="https://github.com/gohugoio/hugo" target="_blank" rel="noopener"><code>hugo</code></a> and hosted remotely on Github Pages at <a href="https://eest.ethereum.org/" target="_blank" rel="noopener">eest.ethereum.org</a>.</p> <h2 id="prerequisites">Prerequisites</h2> <p>Grab the latest <code>hugo</code> binary from the official release page or build it yourself. Then make the binary executable and add it to the PATH (or to a directory that has already been added to the PATH like e.g. <code>/usr/local/bin/</code>). We do not require any additional plugins or dependencies.</p> <h2 id="build-and-locally-host-the-documentation">Build and Locally Host the Documentation</h2> <p>Build the docs:</p> + + + + http://localhost:1313/main/dev_docs/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/dev_docs/ + <h1 id="documenting-clis">Documenting CLIs</h1> <p>EEST command line interfaces (CLIs) are documented using the <a href="https://click.palletsprojects.com" target="_blank" rel="noopener"><code>click</code></a> library&rsquo;s built-in help system and the <a href="https://github.com/mkdocs/mkdocs-click" target="_blank" rel="noopener"><code>mkdocs-click</code></a> extension for mkdocs. This allows generation of CLI documentation directly from the (click) source code, ensuring that the documentation is always up-to-date with the code.</p> <p>Current limitations:</p> <ol> <li><code>mkdocs serve</code> does not automatically update the CLI documentation when the source code changes. You must restart the server to see the changes.</li> <li><code>mkdocs-click</code> does not automatically generate a short help string from sub-command docstrings. You must provide a short help string for each sub-command in the source code with <code>@click.command(short_help=&quot;...&quot;)</code>.</li> </ol> <p>See the <a href="https://github.com/ethereum/execution-spec-tests/blob/main/docs/library/cli/evm_bytes.md" target="_blank" rel="noopener">markdown</a> and corresponding <a href="https://github.com/ethereum/execution-spec-tests/blob/main/src/cli/evm_bytes.py" target="_blank" rel="noopener">Python docstrings</a> for the <a href="../library/cli/evm_bytes.md"><code>evm_bytes</code> CLI documentation</a> as an example of how to document a CLI using <code>mkdocs-click</code>.</p> + + + + http://localhost:1313/main/dev_docs/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/dev_docs/ + <h1 id="working-with-eest-libraries-interactively">Working with EEST Libraries Interactively</h1> <p>You can work with EEST Python packages interactively with <code>ipython</code> using:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-console" data-lang="console"><span style="display:flex;"><span>uvx --with-editable . ipython </span></span></code></pre></div><p>This command will create a virtual environment, install EEST&rsquo;s packages in &ldquo;<a href="https://setuptools.pypa.io/en/latest/userguide/development_mode.html" target="_blank" rel="noopener">editable mode</a>&rdquo; (source changes get reflected in the interactive shell), and start an <code>ipython</code> shell. You can then import any of the packages and experiment with them interactively.</p> <div class="callout callout-info"> <div class="callout-title">Example: Working with <code>ethereum_test_forks</code></div> <div class="callout-content"> <p>See which defined forks are &ldquo;ignored&rdquo; by default:</p> + + + + http://localhost:1313/main/dev_docs/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/dev_docs/ + <h1 id="logging">Logging</h1> <p>This document describes the logging system used in the Ethereum Execution Spec Tests project. Currently, logging is only supported for <code>consume</code> commands.</p> <h2 id="overview">Overview</h2> <p>The project uses Python&rsquo;s standard logging module with custom extensions to provide enhanced logging capabilities. Our logging system is implemented in the <code>src/pytest_plugins/logging.py</code> module and provides the following features:</p> <ul> <li>Custom log levels between the standard Python log levels</li> <li>Timestamps with millisecond precision in UTC</li> <li>Color-coded log output (when not running in Docker)</li> <li>File logging with a consistent naming pattern</li> <li>Integration with pytest&rsquo;s output capture</li> <li>Support for distributed test execution with pytest-xdist</li> </ul> <h2 id="custom-log-levels">Custom Log Levels</h2> <p>In addition to the standard Python log levels (DEBUG, INFO, WARNING, ERROR, CRITICAL), we&rsquo;ve added the following custom levels:</p> + + + + http://localhost:1313/main/dev_docs/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/dev_docs/ + <h1 id="enabling-pre-commit-checks">Enabling Pre-Commit Checks</h1> <p>There&rsquo;s a <a href="https://pre-commit.com/" target="_blank" rel="noopener">pre-commit</a> config file available in the repository root (<code>.pre-commit-config.yaml</code>) that can be used to enable automatic checks upon commit - the commit will not go through if the checks don&rsquo;t pass.</p> <p>To enable pre-commit, the following must be run once:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-console" data-lang="console"><span style="display:flex;"><span>uvx pre-commit install </span></span></code></pre></div> <div class="callout callout-info"> <div class="callout-title">Bypassing pre-commit checks</div> <div class="callout-content"> <p>Enabling of pre-commit checks is not mandatory (it cannot be enforced) and even if it is enabled, it can always be bypassed with:</p> + + + + http://localhost:1313/main/dev_docs/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/dev_docs/ + <h1 id="running-github-actions-locally">Running Github Actions Locally</h1> <p>The Github Actions workflows can be tested locally using <a href="https://github.com/nektos/act" target="_blank" rel="noopener">nektos/act</a> without pushing changes to the remote. The local repository state will be used in the executed workflow.</p> <h2 id="prerequisites">Prerequisites</h2> <ol> <li> <p>A docker installation without <code>sudo</code> prefix requirement (<a href="https://docs.docker.com/engine/install/linux-postinstall/#manage-docker-as-a-non-root-user" target="_blank" rel="noopener">see also dockerdocs</a>):</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-bash" data-lang="bash"><span style="display:flex;"><span>sudo usermod -aG docker $USER </span></span></code></pre></div></li> <li> <p>Install the Github CLI (<code>gh</code>): <a href="https://github.com/cli/cli/blob/trunk/docs/install_linux.md" target="_blank" rel="noopener">linux</a>, <a href="https://github.com/cli/cli/tree/trunk?tab=readme-ov-file#macos" target="_blank" rel="noopener">macos</a>.</p> </li> <li> <p>Authenticate your Github account with the Github CLI:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-bash" data-lang="bash"><span style="display:flex;"><span>gh auth login </span></span></code></pre></div><p>This is required to set <code>GITHUB_TOKEN</code> to the output of <code>gh auth token</code> when running the workflows.</p> + + + diff --git a/docs/public/main/dev_docs/interactive_usage/index.html b/docs/public/main/dev_docs/interactive_usage/index.html new file mode 100644 index 00000000000..3494a17069f --- /dev/null +++ b/docs/public/main/dev_docs/interactive_usage/index.html @@ -0,0 +1,1345 @@ + + + + + + + Interactive Library Usage - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

Interactive Library Usage

+
+ +
+

You can work with EEST Python packages interactively with ipython using:

+
uvx  --with-editable . ipython
+

This command will create a virtual environment, install EEST’s packages in “editable mode” (source changes get reflected in the interactive shell), and start an ipython shell. You can then import any of the packages and experiment with them interactively.

+ + +
+
Example: Working with ethereum_test_forks
+
+

See which defined forks are “ignored” by default:

+
from ethereum_test_forks import forks, get_forks
+forks = set([fork for fork in get_forks() if fork.ignore()])
+print(forks)
+# -> {MuirGlacier, ArrowGlacier, GrayGlacier}
+
+
+
+

Required ipython Configuration

+

To enable autoreload of changed modules in the current ipython session, type:

+
%load_ext autoreload
+%autoreload 2
+

To make this configuration persistent, add/uncomment the following lines to ~/.ipython/profile_default/ipython_config.py:

+
c.InteractiveShellApp.exec_lines = ["%autoreload 2"]
+c.InteractiveShellApp.extensions = ["autoreload"]
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/dev_docs/logging/index.html b/docs/public/main/dev_docs/logging/index.html new file mode 100644 index 00000000000..26f4ddc6b8c --- /dev/null +++ b/docs/public/main/dev_docs/logging/index.html @@ -0,0 +1,1469 @@ + + + + + + + Logging - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

Logging

+
+ +
+

This document describes the logging system used in the Ethereum Execution Spec Tests project. Currently, logging is only supported for consume commands.

+

Overview

+

The project uses Python’s standard logging module with custom extensions to provide enhanced logging capabilities. Our logging system is implemented in the src/pytest_plugins/logging.py module and provides the following features:

+
    +
  • Custom log levels between the standard Python log levels
  • +
  • Timestamps with millisecond precision in UTC
  • +
  • Color-coded log output (when not running in Docker)
  • +
  • File logging with a consistent naming pattern
  • +
  • Integration with pytest’s output capture
  • +
  • Support for distributed test execution with pytest-xdist
  • +
+

Custom Log Levels

+

In addition to the standard Python log levels (DEBUG, INFO, WARNING, ERROR, CRITICAL), we’ve added the following custom levels:

+ + + + + + + + + + + + + + + + + + + + +
LevelNumeric ValuePurpose
VERBOSE15For messages more detailed than INFO but less verbose than DEBUG
FAIL35For test failures and related issues (between WARNING and ERROR)
+

Using the Logger

+

Getting a Logger

+

To use the custom logger in your code, import the get_logger function from the logging module:

+
from pytest_plugins.logging import get_logger
+
+# Create a logger with your module's name
+logger = get_logger(__name__)
+

Logging at Different Levels

+

You can use all standard Python log methods plus our custom methods:

+
# Standard log levels
+logger.debug("Detailed debug information")
+logger.info("General information")
+logger.warning("Warning message")
+logger.error("Error message")
+logger.critical("Critical failure")
+
+# Custom log levels
+logger.verbose("More detailed than INFO, less than DEBUG")
+logger.fail("Test failure or similar issue")
+

When to Use Each Level

+
    +
  • DEBUG (10): For very detailed diagnostic information useful for debugging
  • +
  • VERBOSE (15): For information that’s useful during development but more detailed than INFO
  • +
  • INFO (20): For general information about program operation
  • +
  • WARNING (30): For potential issues that don’t prevent program execution
  • +
  • FAIL (35): For test failures and related issues
  • +
  • ERROR (40): For errors that prevent an operation from completing
  • +
  • CRITICAL (50): For critical errors that may prevent the program from continuing
  • +
+

Configuration

+

Setting Log Level on the Command Line

+

You can adjust the log level when running pytest with the --eest-log-level option:

+
consume engine --input=latest@stable --eest-log-level=VERBOSE -s --sim.limit=".*chainid.*"
+

The argument accepts both log level names (e.g., “DEBUG”, “VERBOSE”, “INFO”) and numeric values.

+

Adding pytest’s -s flag writes the logging messages to the terminal; otherwise output will be written to the log file that is reported in the test session header at the end of the test session.

+

Log File Output

+

Log files are automatically created in the logs/ directory with a naming pattern that includes:

+
    +
  • The command name, e.g. consume,
  • +
  • An optional subcommand (e.g., engine),
  • +
  • A timestamp in UTC,
  • +
  • The worker ID (when using pytest-xdist).
  • +
+

Example: consume-engine-20240101-123456-main.log

+

The log file path is displayed in the pytest header and summary.

+

Using the Standalone Configuration in Non-Pytest Projects

+

The logging module can also be used in non-pytest projects by using the configure_logging function:

+
from pytest_plugins.logging import configure_logging, get_logger
+
+# Configure logging with custom settings
+configure_logging(
+    log_level="VERBOSE",
+    log_file="my_application.log",
+    log_to_stdout=True,
+    log_format="%(asctime)s [%(levelname)s] %(name)s: %(message)s",
+    use_color=True
+)
+
+# Get a logger and use it
+logger = get_logger(__name__)
+logger.verbose("Logging configured in standalone application!")
+

The configure_logging function accepts the following parameters:

+
    +
  • log_level: A string or numeric log level (default: “INFO”)
  • +
  • log_file: Path to a log file, or None to disable file logging (default: None)
  • +
  • log_to_stdout: Whether to log to stdout (default: True)
  • +
  • log_format: The format string for log messages (default: “%(asctime)s [%(levelname)s] %(name)s: %(message)s”)
  • +
  • use_color: Whether to use colors in stdout output, or None to auto-detect (default: None)
  • +
+

Implementation Details

+

The EESTLogger Class

+

The EESTLogger class extends Python’s Logger class to add the custom log methods. The main module logger is automatically configured to use this class.

+

Formatters

+

Two formatter classes are available:

+
    +
  • UTCFormatter: Formats timestamps with millisecond precision in UTC
  • +
  • ColorFormatter: Extends UTCFormatter to add ANSI colors to log level names in terminal output
  • +
+

Pytest and Hive Integration

+

The logging module includes several pytest hooks to:

+
    +
  • Configure logging at the start of a test session
  • +
  • Record logs during test execution
  • +
  • Display the log file path in the test report
  • +
  • Ensure logs are captured properly during fixture teardown
  • +
+

The hive_pytest plugin has been extended to propagate the logs to the hiveview UI via the test case’s details (“description” in hiveview).

+

Example Usage

+

A complete example of using the logging system in a consume test (or plugin):

+
from pytest_plugins.logging import get_logger
+
+# Get a properly typed logger for your module
+logger = get_logger(__name__)
+
+def test_something():
+    # Use standard log levels
+    logger.debug("Setting up test variables")
+    logger.info("Starting test")
+    
+    # Use custom log levels
+    logger.verbose("Additional details about test execution")
+    
+    # Log warnings or errors as needed
+    if something_concerning:
+        logger.warning("Something looks suspicious")
+    
+    if something_failed:
+        logger.fail("Test condition not met")
+        assert False, "Test failed"
+    
+    # Log successful completion
+    logger.info("Test completed successfully")
+

All log messages will be displayed according to the configured log level and captured in the log file.

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/dev_docs/main/index.html b/docs/public/main/dev_docs/main/index.html new file mode 100644 index 00000000000..ccac9cec7fb --- /dev/null +++ b/docs/public/main/dev_docs/main/index.html @@ -0,0 +1,1337 @@ + + + + + + + Developer Documentation - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

Developer Documentation

+
+ +
+

This documentation is aimed at execution-spec-tests developers:

+
    +
  • Managing configurations: Instructions for setting up and modifying test configurations.
  • +
  • Interactive usage: Guide on interactive use of EEST packages using ipython.
  • +
  • Documenting CLI commands: Instructions for documenting command line interfaces (CLIs).
  • +
  • Coding style: Standards and best practices for code formatting and to maintain consistency across the repository.
  • +
  • Logging: Documentation on using the custom logging system with enhanced features.
  • +
  • Enabling pre-commit checks: A guide for setting up pre-commit hooks to enforce code quality before commits.
  • +
  • Running github actions locally: Instructions for testing GitHub Actions workflows on your local machine to streamline development and debugging.
  • +
+

These sections are primarily aimed at execution-spec-tests maintainers:

+ +
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/dev_docs/precommit/index.html b/docs/public/main/dev_docs/precommit/index.html new file mode 100644 index 00000000000..1cf0f9607d7 --- /dev/null +++ b/docs/public/main/dev_docs/precommit/index.html @@ -0,0 +1,1335 @@ + + + + + + + Enabling Pre-Commit Checks - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

Enabling Pre-Commit Checks

+
+ +
+

There’s a pre-commit config file available in the repository root (.pre-commit-config.yaml) that can be used to enable automatic checks upon commit - the commit will not go through if the checks don’t pass.

+

To enable pre-commit, the following must be run once:

+
uvx pre-commit install
+
+ +
+
Bypassing pre-commit checks
+
+

Enabling of pre-commit checks is not mandatory (it cannot be enforced) and even if it is enabled, it can always be bypassed with:

+
git commit --no-verify
+
+
+
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/dev_docs/test_actions_locally/index.html b/docs/public/main/dev_docs/test_actions_locally/index.html new file mode 100644 index 00000000000..1ea27a57d68 --- /dev/null +++ b/docs/public/main/dev_docs/test_actions_locally/index.html @@ -0,0 +1,1402 @@ + + + + + + + Running Github Actions Locally - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

Running Github Actions Locally

+
+ +
+

The Github Actions workflows can be tested locally using nektos/act without pushing changes to the remote. The local repository state will be used in the executed workflow.

+

Prerequisites

+
    +
  1. +

    A docker installation without sudo prefix requirement (see also dockerdocs):

    +
    sudo usermod -aG docker $USER
    +
  2. +
  3. +

    Install the Github CLI (gh): linux, macos.

    +
  4. +
  5. +

    Authenticate your Github account with the Github CLI:

    +
    gh auth login
    +

    This is required to set GITHUB_TOKEN to the output of gh auth token when running the workflows.

    +
  6. +
  7. +

    Install the act tool as a Github extension (nektos/act docs):

    +
    gh extension install https://github.com/nektos/gh-act
    +

    or use one of the other available methods.

    +
  8. +
+ + +
+
Updating nektos/act to the latest version via the Github CLI
+
+

The act tool can be updated via the Github CLI:

+
gh extension upgrade nektos/act
+
+
+
+

Listing the Available Workflows

+
gh act --list
+

will output something similar to:

+
INFO[0000] Using docker host 'unix:///var/run/docker.sock', and daemon socket 'unix:///var/run/docker.sock'
+Stage  Job ID                Job name                                                      Workflow name                             Workflow file          Events                             
+0      evmone-coverage-diff  evmone-coverage-diff                                          Evmone Coverage Report                    coverage.yaml          pull_request                       
+0      deploy                deploy                                                        Deploy Docs Main                          docs_main.yaml         push                               
+0      deploy                deploy                                                        Deploy Docs Tags                          docs_tags.yaml         push                               
+0      features              features                                                      Build and Package Fixtures                fixtures.yaml          push,workflow_dispatch             
+0      feature-names         feature-names                                                 Build and Package Fixtures for a feature  fixtures_feature.yaml  push,workflow_dispatch             
+0      lint                  Lint python sources with ruff                                 Tox                                       tox_verify.yaml        push,pull_request,workflow_dispatch
+0      typecheck             Typecheck python sources with mypy                            Tox                                       tox_verify.yaml        push,pull_request,workflow_dispatch
+0      spellcheck            Spellcheck sources with pyspelling                            Tox                                       tox_verify.yaml        push,pull_request,workflow_dispatch
+0      markdownlint          Lint markdown files with markdownlint                         Tox                                       tox_verify.yaml        push,pull_request,workflow_dispatch
+0      mkdocs                Build html documentation with mkdocs                          Tox                                       tox_verify.yaml        push,pull_request,workflow_dispatch
+0      pytest_framework      Run unit tests, ${{ matrix.os }}, ${{ matrix.python }}        Tox                                       tox_verify.yaml        push,pull_request,workflow_dispatch
+0      tests_deployed        Fill tests, deployed, ${{ matrix.os }}, ${{ matrix.python }}  Tox                                       tox_verify.yaml        push,pull_request,workflow_dispatch
+1      build                 build                                                         Build and Package Fixtures                fixtures.yaml          push,workflow_dispatch             
+1      build                 build                                                         Build and Package Fixtures for a feature  fixtures_feature.yaml  push,workflow_dispatch             
+2      release               release                                                       Build and Package Fixtures                fixtures.yaml          push,workflow_dispatch             
+2      release               release                                                       Build and Package Fixtures for a feature  fixtures_feature.yaml  push,workflow_dispatch
+

The Job ID is required to run a specific workflow and is provided to the -j option of gh act.

+

Running Workflows that require Github Vars

+

Create a text file containing the required variables and variables, e.g., .act_github_vars (this is in .gitignore):

+
UV_VERSION=0.5.15
+DEFAULT_PYTHON_VERSION=3.12
+

and use the --var-file option to specify the file:

+
gh act --workflows .github/workflows/tox_verify.yaml -s GITHUB_TOKEN=$(gh auth token) --var-file=gh_vars.txt -j lint 
+

Running Workflows that use a Matrix Strategy

+

This is optional, recent versions will automatically detect the matrix strategy and run supported values. To run a specific matrix value, use the --matrix option:

+
gh act --workflows .github/workflows/tox_verify.yaml -s GITHUB_TOKEN=$(gh auth token) --matrix python:3.12 -j pytest_framework
+

Running Release Workflows

+

Release builds require the ref input to be specified. To test a release build locally:

+
    +
  1. +

    Create a JSON file specifying the input data required for a release build (the release tag), e.g, event.json:

    +
    {
    +    "ref": "refs/tags/stable@v4.2.0"
    +}
    +
  2. +
  3. +

    Run act and specify the workflow file, the Github token, and the event file:

    +
    gh act -j build --workflows .github/workflows/fixtures_feature.yaml -s GITHUB_TOKEN=$(gh auth token) -e event.json
    +
  4. +
+

Manually Specifying the Docker Image

+

It’s possible to specify the Docker image used by the act tool for a specific platform defined in a workflow using the -P (--platform) option. For example, use map ubuntu-latest in the workflow to use ubuntu-24.04:

+
-P ubuntu-latest=ubuntu:24.04
+

This can be added to any gh act command.

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/dev_mode/index.html b/docs/public/main/dev_mode/index.html new file mode 100644 index 00000000000..8a5e366845d --- /dev/null +++ b/docs/public/main/dev_mode/index.html @@ -0,0 +1,1388 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

Hive Development Mode

+

This section explains how to run EEST simulators using their EEST commands, e.g., uv run consume engine, against a Hive “development” server as apposed to using the standalone ./hive command.

+

This avoids running the simulator in a dockerized environment and has several advantages:

+
    +
  1. A local directory containing fixtures can be specified (--input=./fixtures/).
  2. +
  3. Allows dropping into a Python debugger (via --pdb) upon test failure to inspect the response or ssh to the client container.
  4. +
  5. Provides access to a larger set of the simulator’s command-line options,
  6. +
  7. Runs are faster; there are no docker image rebuilds in between runs. In particular, modifications to the simulator do not require a an image rebuild.
  8. +
+

Platform Support

+
    +
  • Linux: Direct development mode supported.
  • +
  • macOS: Must be ran from a Linux environment or use a Docker-based workaround (see macOS Setup).
  • +
+

Quick Start

+

Prerequisites

+ +

Hive Dev Setup on Linux

+
    +
  1. +

    Start Hive in development mode, e.g.:

    +
    ./hive --dev --client go-ethereum --client-file clients.yaml --docker.output
    +
  2. +
  3. +

    In a separate shell, configure environment for EEST:

    +

    === “bash/zsh”

    +
     ```bash
    + export HIVE_SIMULATOR=http://127.0.0.1:3000
    + ```
    +
    +

    === “fish”

    +
     ```console
    + set -x HIVE_SIMULATOR http://127.0.0.1:3000
    + ```
    +
    +
  4. +
  5. +

    Run EEST consume commands

    +
    uv run consume engine --input ./fixtures -k "test_chainid"
    +uv run consume rlp --input stable@latest
    +
  6. +
+

Hive Dev Setup on macOS

+

Due to Docker running within a VM on macOS, the host machine and Docker containers don’t share the same network namespace, preventing direct communication with Hive’s development server. To run development mode on macOS, you have the following options:

+
    +
  1. Linux VM: Run a Linux virtual machine on your macOS and execute the standard development workflow above from within the VM.
  2. +
  3. Remote Linux: SSH into a remote Linux environment (server or cloud instance) and run development mode there.
  4. +
  5. Docker Development Image: Create a containerized EEST environment that runs within Docker’s network namespace (recommended).
  6. +
+

The following section details the setup and usage of option 3.

+

EEST Docker Development Image

+

Within the eest/ directory of hive, a new dockerfile must be created: Dockerfile.dev, with the following contents:

+
FROM ghcr.io/astral-sh/uv:python3.12-bookworm-slim
+ARG branch=main
+ENV GIT_REF=${branch} 
+
+RUN apt-get update && apt-get install -y git
+RUN git init execution-spec-tests && \
+    cd execution-spec-tests && \
+    git remote add origin https://github.com/ethereum/execution-spec-tests.git && \
+    git fetch --depth 1 origin $GIT_REF && \
+    git checkout FETCH_HEAD;
+
+WORKDIR /execution-spec-tests
+RUN uv sync
+ENTRYPOINT ["/bin/bash"]
+

This dockerfile will be our entry point for running EEST commands.

+

eest/ Hive Directory Structure

+
β”œβ”€β”€ eest
+β”‚   β”œβ”€β”€ Dockerfile.dev
+β”‚   β”œβ”€β”€ consume-block-rlp
+β”‚   β”‚   └── Dockerfile
+β”‚   └── consume-engine
+β”‚       └── Dockerfile
+

Running Consume

+
    +
  1. +

    Get your local IP address:

    +
    ipconfig getifaddr en0
    +
  2. +
  3. +

    Start Hive in development mode with your local IP:

    +
    ./hive --dev --dev.addr <LOCAL_IP>:3000 --client go-ethereum --client-file clients.yaml 
    +
  4. +
  5. +

    In a separate terminal session, build the EEST development image:

    +
    cd simulators/ethereum/eest/
    +docker build -t macos-consume-dev -f Dockerfile.dev .
    +
  6. +
  7. +

    Run the container with the Hive simulator environment:

    +
    docker run -it -e HIVE_SIMULATOR=http://<LOCAL_IP>:3000 macos-consume-dev
    +
  8. +
  9. +

    Inside the Docker container, run consume commands:

    +
    uv run consume engine -v
    +
  10. +
+

How Development Mode Works

+

When Hive runs in dev mode:

+
    +
  1. Starts the Hive API server (default: http://127.0.0.1:3000).
  2. +
  3. Builds and maintains client containers.
  4. +
  5. Keeps the Hive Proxy container running between test executions.
  6. +
  7. Waits for external simulator connections via the API.
  8. +
+

This allows EEST’s consume commands to connect to the running Hive instance and execute tests interactively.

+

More Options Available

+

There are many useful native pytest options available in dev mode, see Useful Options.

+

Custom API Endpoint

+

Specify a custom address and port via --dev.addr:

+
./hive --dev \
+  --dev.addr 127.0.0.1:5000 \
+  --client reth \
+  --client-file clients.yaml
+

Then connect with:

+
export HIVE_SIMULATOR=http://127.0.0.1:5000
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/direct/index.html b/docs/public/main/direct/index.html new file mode 100644 index 00000000000..8f83ecaf213 --- /dev/null +++ b/docs/public/main/direct/index.html @@ -0,0 +1,1297 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

The consume direct Command

+

The direct method provides the fastest way to test EVM functionality by executing tests directly through a client’s dedicated test interface (e.g. statetest or blocktest).

+
uv run consume direct --bin=<evm-binary> [OPTIONS]
+
    +
  • --bin EVM_BIN: Path to an evm executable that can process StateTestFixture and/or BlockTestFixture formats.
  • +
  • --traces: Collect execution traces from the evm executable.
  • +
+ + +
+
Limited Client Support
+
+

Currently, only the following clients can be used with consume direct:

+
    +
  • go-ethereum statetest and blocktest.
  • +
  • Nethermind nethtest.
  • +
+
+
+

Advantages

+
    +
  • Speed: Fastest test execution method.
  • +
  • Simplicity: No container or network overhead.
  • +
  • Debugging: Easy access to traces and logs.
  • +
+

Limitations

+
    +
  • Limited client support: Only go-ethereum and Nethermind.
  • +
  • Module scope: Tests EVM, respectively block import, in isolation, not full client behavior.
  • +
  • Interface dependency: Requires client-specific test interfaces.
  • +
+

Example Usage

+

Only run state tests (by using a mark filter, -m) from a local fixtures folder with go-ethereum:

+
uv run consume direct --input ./fixtures -m state_test --bin=evm
+

or Nethermind:

+
uv run consume direct --input ./fixtures -m state_test --bin=nethtest
+

Run fixtures in the blockchain test format for the Prague fork:

+
uv run consume direct --input ./fixtures -m "blockchain_test and Prague" --bin=evm
+

Test selection via a regular expression match on collected fixture IDs:

+
uv run consume direct --input ./fixtures --sim.limit ".*push0.*"
+

Test selection via pytest keyword expression match:

+
uv run consume direct --input ./fixtures -k "eip3855 or Prague"
+

Use --collect-only -q to get a list of available test fixture IDs:

+
uv run consume direct --input ./fixtures -k "eip3855 or Prague" --collect-only -q
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/docs/index.html b/docs/public/main/docs/index.html new file mode 100644 index 00000000000..a4531223384 --- /dev/null +++ b/docs/public/main/docs/index.html @@ -0,0 +1,1357 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

Documentation

+

The execution-spec-tests documentation is generated via hugo and hosted remotely on Github Pages at eest.ethereum.org.

+

Prerequisites

+

Grab the latest hugo binary from the official release page or build it yourself. Then make the binary executable and add it to the PATH (or to a directory that has already been added to the PATH like e.g. /usr/local/bin/). We do not require any additional plugins or dependencies.

+

Build and Locally Host the Documentation

+

Build the docs:

+
hugo
+

If you want to build + locally host the docs:

+
hugo server
+

Remote Deployment and Versioning

+

The execution-specs-test docs are hosted using Github pages at eest.ethereum.org. Versions are updated/deployed automatically as part of Github Actions.

+

CI/CD: Doc Deployment via Github Actions

+

This is our workflow that automatically deploys updated/new versions of the docs:

+ + + + + + + + + + + + + + + +
Workflow yaml FileWhatWhen
docs.yamlDeploy new version of docs
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/documenting_clis/index.html b/docs/public/main/documenting_clis/index.html new file mode 100644 index 00000000000..a5eac533ad4 --- /dev/null +++ b/docs/public/main/documenting_clis/index.html @@ -0,0 +1,1336 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

Documenting CLIs

+

EEST command line interfaces (CLIs) are documented using the click library’s built-in help system and the mkdocs-click extension for mkdocs. This allows generation of CLI documentation directly from the (click) source code, ensuring that the documentation is always up-to-date with the code.

+

Current limitations:

+
    +
  1. mkdocs serve does not automatically update the CLI documentation when the source code changes. You must restart the server to see the changes.
  2. +
  3. mkdocs-click does not automatically generate a short help string from sub-command docstrings. You must provide a short help string for each sub-command in the source code with @click.command(short_help="...").
  4. +
+

See the markdown and corresponding Python docstrings for the evm_bytes CLI documentation as an example of how to document a CLI using mkdocs-click.

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/eip_checklist/index.html b/docs/public/main/eip_checklist/index.html new file mode 100644 index 00000000000..df6e17ff367 --- /dev/null +++ b/docs/public/main/eip_checklist/index.html @@ -0,0 +1,1614 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

EIP Checklist Generation

+

The EIP checklist feature helps track test coverage for EIP implementations by automatically generating filled checklists based on test markers.

+

Overview

+

When implementing tests for an EIP, you can mark specific tests as covering checklist items from the EIP testing checklist template. The framework will then generate a filled checklist showing which items have been implemented.

+

Marking Tests as implementing EIP Checklist Items

+

To mark a test as implementing a specific checklist item, use the structured EIPChecklist class:

+

The EIPChecklist Class

+
import pytest
+from ethereum_test_tools import StateTestFiller
+from ethereum_test_checklists import EIPChecklist
+
+@EIPChecklist.TransactionType.Test.IntrinsicValidity.GasLimit.Exact()
+def test_exact_intrinsic_gas(state_test: StateTestFiller):
+    """Test transaction with exact intrinsic gas limit."""
+    # Test implementation
+    pass
+
+# You can also use the marker without parentheses
+@EIPChecklist.TransactionType.Test.IntrinsicValidity.GasLimit.Insufficient
+def test_insufficient_intrinsic_gas(state_test: StateTestFiller):
+    """Test transaction with insufficient intrinsic gas limit."""
+    # Test implementation
+    pass
+

The EIPChecklist class provides type safety and IDE autocompletion, making it easier to find and reference checklist items correctly.

+

Marker Parameters

+
    +
  • First positional parameter (required): The checklist item ID (EIPChecklist reference)
  • +
  • eip keyword parameter (optional): List of additional EIPs covered by the test
  • +
+

Example with multiple EIPs covered by the same test:

+
@EIPChecklist.TransactionType.Test.Signature.Invalid.V.Two(
+    eip=[7702, 2930]
+)
+def test_invalid_signature(state_test: StateTestFiller):
+    """Test invalid signature that affects multiple EIPs."""
+    pass
+

Partial ID Matching

+

You can use partial IDs that will match all checklist items starting with that prefix:

+
@EIPChecklist.TransactionType.Test.Signature.Invalid()
+def test_all_invalid_signatures(state_test: StateTestFiller):
+    """Test covering all invalid signature scenarios."""
+    pass
+

Generating Checklists

+

Using the Dedicated checklist Command

+

To generate only checklists without filling fixtures:

+
# Generate checklists for all EIPs
+uv run checklist
+
+# Generate checklist for specific EIP
+uv run checklist --eip 7702
+
+# Specify output directory
+uv run checklist --output ./my-checklists
+
+# Multiple EIPs
+uv run checklist --eip 7702 --eip 2930
+

Automatic Generation in Documentation

+

When building the documentation with mkdocs, checklists are automatically generated for all EIPs that have tests with checklist markers. The checklists appear in the test documentation alongside the test modules.

+

External Coverage and Not Applicable Items

+

External Coverage

+

For checklist items that are covered by external tests, procedures, or tools (e.g., EELS coverage), create a file named eip_checklist_external_coverage.txt in the EIP test directory:

+
# tests/prague/eip7702_set_code_tx/eip_checklist_external_coverage.txt
+general/code_coverage/eels = Covered by EELS test suite
+general/code_coverage/second_client = Covered by Nethermind tests
+

Format: checklist_item_id = reason

+

Not Applicable Items

+

For checklist items that are not applicable to a specific EIP, create a file named eip_checklist_not_applicable.txt in the EIP test directory:

+
# tests/prague/eip7702_set_code_tx/eip_checklist_not_applicable.txt
+system_contract = EIP-7702 does not introduce a system contract
+precompile = EIP-7702 does not introduce a precompile
+

Format: checklist_item_id = reason

+

Both files support partial ID matching, so you can mark entire sections as not applicable:

+

MyPy Type Checking Support

+

The EIPChecklist classes are made callable through a companion .pyi stub file that provides proper type hints for mypy. This allows you to use both decorator patterns without type checking errors:

+
# Both of these work with proper mypy support
+@EIPChecklist.Opcode.Test.StackComplexOperations()  # With parentheses
+@EIPChecklist.Opcode.Test.StackComplexOperations   # Without parentheses
+

Regenerating Type Stubs

+

If you modify the EIPChecklist class structure in src/ethereum_test_checklists/eip_checklist.py, you need to regenerate the type stub file:

+
# Generate the stub file (for maintainers):
+uv run generate_checklist_stubs
+
+# Preview what would be generated without writing the file
+uv run generate_checklist_stubs --dry-run
+
+# Generate to a custom location
+uv run generate_checklist_stubs --output path/to/custom/stubs.pyi
+

The generated stub file (eip_checklist.pyi) should be committed to the repository to ensure proper type checking for all developers.

+
# Mark all system contract items as not applicable
+system_contract/ = EIP does not introduce system contracts
+

Output Format

+

The generated checklist will show:

+
    +
  • βœ… for completed items (either by tests or external coverage)
  • +
  • N/A for not applicable items
  • +
  • Test names that implement each item
  • +
  • External coverage reasons where applicable
  • +
  • A percentage of covered checklist items (excluding N/A items)
  • +
  • Color-coded completion status: 🟒 (100%), 🟑 (>50%), πŸ”΄ (≀50%)
  • +
+

Example output snippet:

+
# EIP-7702 Test Checklist
+
+## Checklist Progress Tracker
+
+| Total Checklist Items | Covered Checklist Items | Percentage |
+| --------------------- | ----------------------- | ---------- |
+| 45 | 32 | 🟑 71.11% |
+
+## General
+
+#### Code coverage
+
+| ID | Description | Status | Tests |
+| -- | ----------- | ------ | ----- |
+| `general/code_coverage/eels` | Run produced tests against EELS... | βœ… | Covered by EELS test suite |
+| `general/code_coverage/test_coverage` | Run coverage on the test code itself... | βœ… | `tests/prague/eip7702_set_code_tx/test_set_code_txs.py::test_set_code_txs` |
+
+## Transaction Type
+
+| ID | Description | Status | Tests |
+| -- | ----------- | ------ | ----- |
+| `transaction_type/test/intrinsic_validity/gas_limit/exact` | Provide the exact intrinsic gas... | βœ… | `tests/prague/eip7702_set_code_tx/test_checklist_example.py::test_exact_intrinsic_gas` |
+| `transaction_type/test/intrinsic_validity/gas_limit/insufficient` | Provide the exact intrinsic gas minus one... |  |  |
+
+## System Contract
+
+| ID | Description | Status | Tests |
+| -- | ----------- | ------ | ----- |
+| `system_contract/test/deployment/missing` | Verify block execution behavior... | N/A | EIP-7702 does not introduce a system contract |
+

Best Practices

+
    +
  1. Start with the checklist: Review the checklist template before writing tests to ensure comprehensive coverage
  2. +
  3. Use the EIPChecklist class: Use EIPChecklist.Opcode.Test.GasUsage.Normal for type safety and IDE autocompletion
  4. +
  5. Use descriptive test names: The test name will appear in the checklist, so make it clear what the test covers
  6. +
  7. Mark items as you go: Add eip_checklist markers while writing tests, not as an afterthought
  8. +
  9. Document external coverage: If items are covered by external tools/tests, document this in eip_checklist_external_coverage.txt
  10. +
  11. Be explicit about N/A items: Document why items are not applicable in eip_checklist_not_applicable.txt
  12. +
  13. Use partial IDs wisely: When a test covers multiple related items, use partial IDs to mark them all
  14. +
  15. Verify IDs before using: Use str(EIPChecklist.Section.Subsection) to verify the exact string ID when needed
  16. +
+

Workflow Example

+
    +
  1. +

    Create test directory structure:

    +
    tests/prague/eip9999_new_feature/
    +β”œβ”€β”€ __init__.py
    +β”œβ”€β”€ spec.py
    +β”œβ”€β”€ test_basic.py
    +β”œβ”€β”€ eip_checklist_external_coverage.txt
    +└── eip_checklist_not_applicable.txt
    +
  2. +
  3. +

    Mark tests as you implement them:

    +
    from ethereum_test_checklists import EIPChecklist
    +
    +@EIPChecklist.Opcode.Test.GasUsage.Normal()
    +def test_opcode_gas_consumption(state_test: StateTestFiller):
    +   """Test normal gas consumption of the new opcode."""
    +   pass
    +
  4. +
  5. +

    Document external coverage:

    +
    # eip_checklist_external_coverage.txt
    +general/code_coverage/eels = Covered by ethereum/execution-specs PR #1234
    +

    You can verify the correct ID using:

    +
    # str(EIPChecklist.General.CodeCoverage.Eels) = "general/code_coverage/eels"
    +
  6. +
  7. +

    Mark non-applicable items:

    +
    # eip_checklist_not_applicable.txt
    +precompile/ = EIP-9999 introduces an opcode, not a precompile
    +

    You can verify the correct ID using:

    +
    # str(EIPChecklist.Precompile) = "precompile"
    +
  8. +
  9. +

    Generate and review checklist:

    +
    checklist --eip 9999
    +# Review the generated checklist for completeness
    +
  10. +
+

See Also

+ +
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/eip_testing_checklist_template/index.html b/docs/public/main/eip_testing_checklist_template/index.html new file mode 100644 index 00000000000..e120ce989db --- /dev/null +++ b/docs/public/main/eip_testing_checklist_template/index.html @@ -0,0 +1,4340 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+
+

EIP Execution Layer Testing Checklist Template

+

Depending on the changes introduced by an EIP, the following template is the minimum baseline to guarantee test coverage of the Execution Layer features.

+

Checklist Progress Tracker

+ + + + + + + + + + + + + + + +
Total Checklist ItemsCovered Checklist ItemsPercentage
TOTAL_CHECKLIST_ITEMSCOVERED_CHECKLIST_ITEMSPERCENTAGE
+

General

+

Code coverage

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
general/code_coverage/eelsRun produced tests against EELS and verify that line code coverage of new added lines for the EIP is 100%, with only exceptions being unreachable code lines.
general/code_coverage/test_coverageRun coverage on the test code itself (as a basic logic sanity check), i.e., uv run fill --cov tests.
general/code_coverage/second_clientOptional - Run against a second client and verify sufficient code coverage over new code added for the EIP.
+

Fuzzing

+

Fuzzing is recommended to be performed on EIPs that introduce new cryptography primitives.

+

See holiman/goevmlab for an example of a fuzzing framework for the EVM.

+

New Opcode

+

The EIP introduces one or more new opcodes to the EVM.

+

Test Vectors

+

Memory expansion

+

If the opcode execution can expand the memory size, either by writing to memory or reading from an offset that exceeds current memory, or interaction of both parameters (size of zero should never result in memory expansion, regardless of offset value).

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/mem_exp/zero_bytes_zero_offsetZero bytes expansion with zero-offset.
opcode/test/mem_exp/zero_bytes_max_offsetZero bytes expansion with 2**256-1 offset.
opcode/test/mem_exp/single_byteSingle byte expansion.
opcode/test/mem_exp/31_bytes31 bytes expansion.
opcode/test/mem_exp/32_bytes32 bytes expansion.
opcode/test/mem_exp/33_bytes33 bytes expansion.
opcode/test/mem_exp/64_bytes64 bytes expansion.
opcode/test/mem_exp/2_32_minus_one_bytes2**32-1 bytes expansion.
opcode/test/mem_exp/2_32_bytes2**32 bytes expansion.
opcode/test/mem_exp/2_64_minus_one_bytes2**64-1 bytes expansion.
opcode/test/mem_exp/2_64_bytes2**64 bytes expansion.
opcode/test/mem_exp/2_256_minus_one_bytes2**256-1 bytes expansion (Should always result in Out-of-gas).
+

Stack

+
Stack Overflow
+

If the opcode pushes one or more items to the stack, and the opcode pushes more elements than it pops, verify that the opcode execution results in exceptional abort when pushing elements to the stack would result in the stack having more than 1024 elements.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/stack_overflowStack Overflow.
+
Stack Underflow
+

If the opcode pops one or more items to the stack, or it has a minimum stack height of one or more (e.g. DUPN requires a minimum amount of elements in the stack even when it does not pop any element from it), verify that the opcode execution results in exceptional abort then stack has 1 less item than the minimum stack height expected.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/stack_underflowStack Underflow.
+
Stack Complex Operations
+

If opcode performs stack operations more complex than simple pop/push (e.g. the opcode has a data portion that specifies a variable to access a specific stack element), perform the following test combinations.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/stack_complex_operations/stack_heights/zeroOperation on an empty stack (Potential stack-underflow).
opcode/test/stack_complex_operations/stack_heights/oddOperation on a stack with an odd height.
opcode/test/stack_complex_operations/stack_heights/evenOperation on a stack with an even height.
+
Stack Manipulation With Data Portion Variables
+

If the opcode contains variables in its data portion, for each variable n of the opcode that accesses the nth stack item, test n being.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/stack_complex_operations/data_portion_variables/topTop stack item.
opcode/test/stack_complex_operations/data_portion_variables/bottomBottom stack item.
opcode/test/stack_complex_operations/data_portion_variables/middleMiddle stack item.
+

Execution context

+

Evaluate opcode’s behavior in different execution contexts.

+
CALL
+

Verify opcode operation in a subcall frame originated from a CALL opcode.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/execution_context/callCALL.
+
STATICCALL
+

Verify opcode operation in a subcall frame originated from a STATICCALL opcode.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/execution_context/staticcall/ban_checkVerify exceptional abort if the opcode attempts to modify the code, storage or balance of an account.
opcode/test/execution_context/staticcall/ban_no_modificationIf the opcode is completely banned from static contexts, verify that even when its inputs would not cause any account modification, the opcode still results in exceptional abort of the execution (e.g. PAY with zero value, or SSTORE to the value it already has in the storage).
opcode/test/execution_context/staticcall/sub_callsVerify sub-calls using other opcodes (e.g. CALL, DELEGATECALL, etc) also results in the same exceptional abort behavior.
+
DELEGATECALL
+

Verify opcode operation in a subcall frame originated from a DELEGATECALL opcode.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/execution_context/delegatecallDELEGATECALL.
opcode/test/execution_context/delegatecall/storageIf the opcode modifies the storage of the account currently executing it, verify that only the account that is delegating execution is the one that has its storage modified.
opcode/test/execution_context/delegatecall/balanceIf the opcode modifies the balance of the account currently executing it, verify that only the account that is delegating execution is the one that has its balance modified.
opcode/test/execution_context/delegatecall/codeIf the opcode modifies the code of the account currently executing it, verify that only the account that is delegating execution is the one that has its code modified.
+
CALLCODE
+

Verify opcode operation in a subcall frame originated from a CALLCODE opcode.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/execution_context/callcodeCALLCODE.
+
Initcode
+

Verify opcode behaves as expected when running during the initcode phase of contract creation.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/execution_context/initcode/behaviorInitcode operation.
opcode/test/execution_context/initcode/behavior/txInitcode of a contract creating transaction.
opcode/test/execution_context/initcode/behavior/opcodeInitcode of a contract creating opcode (including itself if opcode creates a contract).
opcode/test/execution_context/initcode/reentryInitcode re-entry: using the same initcode and same address (e.g. CREATE2->REVERT->CREATE2).
+
Set-code Delegated Account
+

Verify opcode operations are applied to the set-code account and do not affect the address that is the target of the delegation.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/execution_context/set_codeSet-code delegated account.
+
Transaction Context
+

If opcode changes behavior depending on particular transaction properties, test using multiple values for each property.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/execution_context/tx_contextTransaction-context dependent opcode.
+
Block Context
+

If opcode changes behavior depending on particular block properties, test using multiple values for each property.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/execution_context/block_contextBlock-context dependent opcode.
+

Return data

+

Verify proper return data buffer overwriting if the opcode is meant to interact with it, otherwise verify that the return data buffer is unaffected.

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/return_data/buffer/currentReturn buffer at current call context.
opcode/test/return_data/buffer/parentReturn buffer at parent call context.
+

Gas Usage

+
Normal Operation
+

Verify gas usage affectation of each stack argument or memory input consumed by the opcode.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/gas_usage/normalNormal operation gas usage.
+
Memory Expansion
+

Verify that the memory expansion correctly follows the gas calculation.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/gas_usage/memory_expansionMemory expansion.
+
Out-Of-Gas
+

Verify that attempting to execute the opcode when gas available is 1 less than the required gas results in exceptional abort.

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/gas_usage/out_of_gas_executionOut-of-gas due to opcode inputs.
opcode/test/gas_usage/out_of_gas_memoryOut-of-gas due to memory expansion.
+
Order-of-operations
+

If the opcode requires different gas stipends for other operations (e.g. contract creation, cold/warm account access), create one case for each operation (ideally independent of each other) and the listed cases for each.

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/gas_usage/order_of_operations/exactSuccess using the exact amount of gas required for the stipend.
opcode/test/gas_usage/order_of_operations/oogOOG with a 1-gas-difference from the gas required for the stipend.
+

Terminating opcode

+

If an opcode is terminating, meaning it results in the current call context to end execution.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/terminating/scenarios/top_levelTop-level call termination.
opcode/test/terminating/scenarios/sub_levelSub-level call termination.
opcode/test/terminating/scenarios/initcodeInitcode termination.
+

Aborting/Reverting opcode

+

If the terminating opcode is meant to rollback the executing call frame, verify the listed events are properly rolled back.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/terminating/rollback/balanceBalance changes.
opcode/test/terminating/rollback/storageStorage changes.
opcode/test/terminating/rollback/contractsContract creations.
opcode/test/terminating/rollback/nonceNonce increments.
opcode/test/terminating/rollback/logsLog events.
+

Out-of-bounds checks

+

If the opcode has out-of-bounds conditions in its parameters/inputs.

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/out_of_bounds/verify/maxMax value for each parameter.
opcode/test/out_of_bounds/verify/max_plus_oneMax value + 1 for each parameter.
+

Exceptional Abort

+

If the opcode has conditions, either inputs or execution context states, that should cause exceptional abort and are different than out-of-gas or stack overflow or underflow.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/exceptional_abortExceptional abort conditions.
+

Data portion

+

If an opcode has a data portion, meaning the N bytes following the opcode in the contract bytecode are skipped from execution.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/data_portion/all_zerosAll zeros data portion.
opcode/test/data_portion/max_valueMax value data portion (2**N-1 where N is the bit size of the data portion).
opcode/test/data_portion/jumpJump into the data portion.
+

Contract creation

+

If the opcode execution results in the creation of a new contract in the state.

+
Correct Creation
+

Verify contract is created at the expected address given multiple inputs.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/contract_creation/addressAddress calculation.
+
Creation Failure
+

The contract creation fails given the listed conditions.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/contract_creation/failure/oogOut-of-gas when available gas is less than minimum contract creation stipend.
opcode/test/contract_creation/failure/insufficient_valueOpcode has a value parameter and the caller does not have enough funds.
opcode/test/contract_creation/failure/collisionCreation would result in an address collision with an existing contract or EOA-delegated address.
+
Recursive Contract Creation
+

Opcode is used to attempt to recreate a contract that is currently mid-creation by a previous call of the same opcode.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/contract_creation/recursiveRecursive contract creation using the opcode.
+

Fork transition

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/fork_transition/invalidExceptional abort if executed before its activation fork/after its deactivation fork.
opcode/test/fork_transition/atVerify correct opcode behavior at transition block, in the case of opcodes which behavior depends on current or parent block information.
+

Framework Changes

+ + + + + + + + + + + +
IDDescriptionStatusTests
+
    +
  • Add opcode to src/ethereum_test_vm/opcode.py
  • +
  • Add opcode to relevant methods in the fork where the EIP is introduced in src/ethereum_test_forks/forks/forks.py
  • +
+

New Precompile

+

The EIP introduces one or more new precompiles.

+

Test Vectors

+

Call contexts

+

Evaluate precompile behavior when called using different call opcodes or called from different execution contexts.

+
CALL
+

Verify precompile operation when called using the CALL opcode.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
precompile/test/call_contexts/normalCALL.
+
DELEGATECALL
+

Verify precompile operation when called using the DELEGATECALL opcode.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
precompile/test/call_contexts/delegateDELEGATECALL.
+
STATICCALL
+

Verify precompile operation when called using the STATICCALL opcode.

+

If the precompile is stateful, meaning calling it affects its storage, this call must result in exceptional abort.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
precompile/test/call_contexts/staticSTATICCALL.
+
CALLCODE
+

Verify precompile operation when called using the CALLCODE opcode.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
precompile/test/call_contexts/callcodeCALLCODE.
+
Transaction Entry-point
+

Verify precompile behavior when it’s used as tx.to.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
precompile/test/call_contexts/tx_entryPrecompile as transaction entry-point.
+
Initcode call
+

Verify calling the opcode during initcode execution of a new contract.

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
precompile/test/call_contexts/initcode/CREATECall from Initcode initiated from a CREATE/CREATE2 opcode.
precompile/test/call_contexts/initcode/txCall from Initcode initiated from a contract-creating transaction (tx.to==None).
+
Precompile as Set-code Delegated Address
+

Test setting the precompile as a set-code delegated address, and verify no precompile logic is executed.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
precompile/test/call_contexts/set_codeSet code delegated address.
+

Inputs

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
precompile/test/inputs/validVerify combinations of valid inputs to the precompile.
precompile/test/inputs/valid/boundaryVerify all boundary values given the precompile functionality.
precompile/test/inputs/valid/cryptoIf precompile performs cryptographic operations, verify behavior on all inputs that have special cryptographic properties (e.g. infinity points as inputs, or input values that result in infinity points returned).
precompile/test/inputs/all_zerosVerify all zeros input.
precompile/test/inputs/max_valuesVerify 2^N-1 where N is a single or multiple valid bit-lengths.
precompile/test/inputs/invalidVerify combinations of invalid inputs to the precompile.
precompile/test/inputs/invalid/cryptoInputs that fail specific mathematical or cryptographic validity checks.
precompile/test/inputs/invalid/corruptedInputs that are malformed/corrupted.
+

Value Transfer

+
Minimum Fee Precompile
+

If the precompile requires a minimum value (fee) to execute, either constant or depending on a formula.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
precompile/test/value_transfer/fee/underCalls with the required value amount minus one, expect failure.
precompile/test/value_transfer/fee/exactCalls with the exact required amount, expect success.
precompile/test/value_transfer/fee/overCalls with extra value than the required amount, expect success.
+
No-Fee Precompile
+

If the precompile does not require any minimum value (fee) to execute.

+

| precompile/test/value_transfer/no_fee | Sending non-zero value does not cause an exception (unless otherwise specified by the EIP). | | |

+

Out-of-bounds checks

+

If the precompile has out-of-bounds conditions in its inputs.

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
precompile/test/out_of_bounds/maxMax value for each input.
precompile/test/out_of_bounds/max_plus_oneMax value + 1 for each input.
+

Input Lengths

+

Verify different combinations of input lengths to the precompile, ensuring the correct minimum fee (if any) is provided.

+
Zero-length Input
+

Regardless of the input requirements for the precompile.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
precompile/test/input_lengths/zeroZero-length calldata.
+
Static Required Input Length
+

If the precompile has a static required input length.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
precompile/test/input_lengths/static/correctCorrect static-length calldata.
precompile/test/input_lengths/static/too_shortCalldata too short, where the value represents a correct but truncated input to the precompile.
precompile/test/input_lengths/static/too_longCalldata too long, where the value represents a correct input to the precompile with padded zeros.
+
Dynamic Required Input Length
+

If the precompile has a variable required input-length based on a formula, test all listed scenarios given different input lengths.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
precompile/test/input_lengths/dynamic/validVerify correct precompile execution for valid lengths.
precompile/test/input_lengths/dynamic/too_shortCalldata too short, where the value represents a correct but truncated input to the precompile.
precompile/test/input_lengths/dynamic/too_longCalldata too long, where the value represents a correct input to the precompile with padded zeros.
+

Gas usage

+
Constant Gas Cost
+

If the precompile always charges the same gas cost regardless of input conditions.

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
precompile/test/gas_usage/constant/exactVerify exact gas consumption.
precompile/test/gas_usage/constant/oogVerify exact gas consumption minus one results in out-of-gas error.
+
Variable Gas Cost
+

If the precompile charges variable gas cost given input conditions, test all listed scenarios using multiple different valid inputs.

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
precompile/test/gas_usage/dynamic/exactVerify exact gas consumption.
precompile/test/gas_usage/dynamic/oogVerify exact gas consumption minus one results in out-of-gas error.
+
Excessive Gas
+

Verify spending all block gas in calls to the precompile (Use Environment().gas_limit as reference max amount).

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
precompile/test/excessive_gas_usageExcessive gas usage.
+

Fork transition

+
Pre-fork Block Call
+

Verify that calling the precompile before its activation fork results in a valid call, even for inputs that are expected to be invalid for the precompile, or a zero-gas call.

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
precompile/test/fork_transition/before/invalid_inputInvalid input call.
precompile/test/fork_transition/before/zero_gasZero-gas call.
+
Cold/Warm Precompile Address State
+

Verify the cold/warm state of the precompile address depending on the fork activation.

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
precompile/test/fork_transition/before/coldPrecompile address is cold by default before the fork activation.
precompile/test/fork_transition/after/warmPrecompile address is warm by default after the fork activation.
+

Framework Changes

+
    +
  • Add precompile address to relevant methods in the fork where the EIP is introduced in src/ethereum_test_forks/forks/forks.py
  • +
+

Removed Precompile

+

The EIP removes one or more precompiles from the existing list of precompiles.

+

Test Vectors

+

Fork transition

+
Precompile Operation
+

Verify that the precompile remains operational up until the last block before the fork is active, and behaves as an account with empty code afterwards.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
removed_precompile/test/fork_transition/operationalPrecompile operation on fork activation.
+
Cold/Warm Precompile Address State
+

Verify the cold/warm state of the precompile address depending on the fork activation.

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
removed_precompile/test/fork_transition/before/warmPrecompile address is warm by default before the fork activation.
removed_precompile/test/fork_transition/after/coldPrecompile address is cold by default after the fork activation.
+

Framework Changes

+
    +
  • Remove the precompile address from relevant methods in the fork where the EIP is removed in src/ethereum_test_forks/forks/forks.py
  • +
+

New System Contract

+

Test Vectors

+

Call contexts

+

Evaluate precompile behavior when called using different call opcodes or called from different execution contexts.

+
CALL
+

Verify system contract operation when called using the CALL opcode.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
system_contract/test/call_contexts/normalCALL.
+
DELEGATECALL
+

Verify system contract operation when called using the DELEGATECALL opcode.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
system_contract/test/call_contexts/delegateDELEGATECALL.
+
STATICCALL
+

Verify system contract operation when called using the STATICCALL opcode.

+

If the system contract is stateful, meaning calling it affects its storage, this call must result in exceptional abort.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
system_contract/test/call_contexts/staticSTATICCALL.
+
CALLCODE
+

Verify system contract operation when called using the CALLCODE opcode.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
system_contract/test/call_contexts/callcodeCALLCODE.
+
Transaction Entry-point
+

Verify system contract behavior when it’s used as tx.to.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
system_contract/test/call_contexts/tx_entrySystem Contract as transaction entry-point.
+
Initcode call
+

Verify calling the opcode during initcode execution of a new contract.

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
system_contract/test/call_contexts/initcode/CREATECall from Initcode initiated from a CREATE/CREATE2 opcode.
system_contract/test/call_contexts/initcode/txCall from Initcode initiated from a contract-creating transaction (tx.to==None).
+
System Contract as Set-code Delegated Address
+

Test setting the system contract as a set-code delegated address, and verify no system contract side-effects are triggered, even if the actual system contract logic is executed.

+

If the system contract requires specific storage pre-conditions to be set for proper execution (e.g. if the contract contains a safety mechanism that prevents it from executing prior to the fork activation), ensure the delegated account has the proper values in the storage to guarantee the correct logic is executed.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
system_contract/test/call_contexts/set_codeSet code delegated address.
+

Inputs

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
system_contract/test/inputs/validVerify combinations of valid inputs to the system contract.
system_contract/test/inputs/boundaryVerify all boundary values given the system contract functionality.
system_contract/test/inputs/all_zerosVerify all zeros input.
system_contract/test/inputs/max_valuesVerify 2^N-1 where N is a single or multiple valid bit-lengths.
system_contract/test/inputs/invalidVerify combinations of invalid inputs to the precompile.
system_contract/test/inputs/invalid/checksInputs that fail validity checks.
system_contract/test/inputs/invalid/cryptoInputs that fail specific mathematical or cryptographic validity checks.
system_contract/test/inputs/invalid/corruptedInputs that are malformed/corrupted.
+

Value Transfer

+
Minimum Fee System Contract
+

If the system contract requires a minimum value (fee) to execute, either constant or depending on a formula.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
system_contract/test/value_transfer/fee/underCalls with the required value amount minus one, expect failure.
system_contract/test/value_transfer/fee/exactCalls with the exact required amount, expect success.
system_contract/test/value_transfer/fee/overCalls with extra value than the required amount, expect success.
+
No-Fee System Contract
+

If the system contract does not require any minimum value (fee) to execute.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
system_contract/test/value_transfer/no_feeSending non-zero value does not cause an exception (unless otherwise specified by the EIP).
+

Out-of-bounds checks

+

If the system contract has out-of-bounds conditions in its inputs.

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
system_contract/test/out_of_bounds/maxMax value for each input.
system_contract/test/out_of_bounds/max_plus_oneMax value + 1 for each input.
+

Input Lengths

+

Verify different combinations of input lengths to the system contract, ensuring the correct minimum fee (if any) is provided.

+
Zero-length Input
+

Regardless of the input requirements for the system contract.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
system_contract/test/input_lengths/zeroZero-length calldata.
+
Static Required Input Length
+

If the system contract has a static required input length.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
system_contract/test/input_lengths/static/correctCorrect static-length calldata.
system_contract/test/input_lengths/static/too_shortCalldata too short, where the value represents a correct but truncated input to the contract.
system_contract/test/input_lengths/static/too_longCalldata too long, where the value represents a correct input to the contract with padded zeros.
+
Dynamic Required Input Length
+

If the system contract has a variable required input-length based on a formula, test all listed scenarios given different input lengths.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
system_contract/test/input_lengths/dynamic/validVerify correct system contract execution for valid lengths.
system_contract/test/input_lengths/dynamic/too_shortCalldata too short, where the value represents a correct but truncated input to the contract.
system_contract/test/input_lengths/dynamic/too_longCalldata too long, where the value represents a correct input to the contract with padded zeros.
+

Gas usage

+
Constant Gas Cost
+

If the system contract always charges the same gas cost regardless of input conditions.

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
system_contract/test/gas_usage/constant/exactVerify exact gas consumption.
system_contract/test/gas_usage/constant/oogVerify exact gas consumption minus one results in out-of-gas error.
+
Variable Gas Cost
+

If the system contract charges variable gas cost given input conditions, test all listed scenarios using multiple different valid inputs.

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
system_contract/test/gas_usage/dynamic/exactVerify exact gas consumption.
system_contract/test/gas_usage/dynamic/oogVerify exact gas consumption minus one results in out-of-gas error.
+

Excessive Gas Cases

+
Excessive Gas Usage During Block Execution
+

Verify spending all block gas in calls to system contract (Use Environment().gas_limit as reference max amount).

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
system_contract/test/excessive_gas/block_gasExhaust block gas limit.
+
Excessive Gas Usage During System Call
+

If possible, produce a scenario where, given all transactions executed within the block result in the execution of the contract by the system address would result in excessive gas usage.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
system_contract/test/excessive_gas/system_callExcessive gas on system call.
+

System Contract Deployment

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
system_contract/test/deployment/missingVerify block execution behavior after fork activation if the system contract has not been deployed (Depending on the EIP, block could be invalid).
system_contract/test/deployment/addressVerify deployment transaction results in the system contract being deployed to the expected address.
+

Contract Variations

+

Verify execution of the different variations of the contract for different networks (if any) results in the expected behavior.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
system_contract/test/contract_variations/networksDifferent network contract variations.
+

Contract Substitution

+

Substitute the default system contract with a mock contract to modify its behavior when called by the system address (at the end of the block execution).

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
system_contract/test/contract_substitution/return_lengthsModified return value lengths.
system_contract/test/contract_substitution/logsModified to emit logs or modified logs.
system_contract/test/contract_substitution/exceptionModified to cause an exception (e.g. invalid opcode).
system_contract/test/contract_substitution/gas_limit_successModified to consume 30,000,000 million gas exactly, execution should be successful.
system_contract/test/contract_substitution/gas_limit_failureModified to consume 30,000,001 million gas exactly, execution should fail.
+

Fork transition

+

Verify calling the system contract before its activation fork results in correct behavior (depends on the system contract implementation).

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
system_contract/test/fork_transition/call_before_forkCall system contract before fork.
+

Framework Changes

+
    +
  • Add system contract address to relevant methods in the fork where the EIP is introduced in src/ethereum_test_forks/forks/forks.py
  • +
  • Add system contract bytecode to the returned value of pre_allocation_blockchain in the fork where the EIP is introduced in src/ethereum_test_forks/forks/forks.py
  • +
+

New Transaction Type

+

Test Vectors

+

Intrinsic Validity

+

Verify the transaction (and the block it is included in) is valid or invalid given the intrinsic validity of the new transaction type, depending on each test scenario.

+

For each new field that affects the intrinsic gas cost of the transaction verify all listed scenarios.

+
Gas Limit
+

Note: Data floor gas cost affects the intrinsic validity of all transaction types, so it must be taken into account when designing all test scenarios.

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/intrinsic_validity/gas_limit/exactProvide the exact intrinsic gas as gas_limit value to the transaction.
transaction_type/test/intrinsic_validity/gas_limit/insufficientProvide the exact intrinsic gas minus one as gas_limit value to the transaction.
+
Gas Fee
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/intrinsic_validity/max_fee/max_priority_lower_than_max_feeInvalid if tx.max_priority_fee_per_gas < tx.max_fee_per_gas.
transaction_type/test/intrinsic_validity/max_fee/max_priority_equal_to_max_feeValid if tx.max_priority_fee_per_gas == tx.max_fee_per_gas.
transaction_type/test/intrinsic_validity/max_fee/base_lowerInvalid if tx.max_fee_per_gas < block.base_fee_per_gas.
transaction_type/test/intrinsic_validity/max_fee/base_equalValid if tx.max_fee_per_gas < block.base_fee_per_gas.
+
Chain ID
+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/intrinsic_validity/chain_idInvalid if tx.chain_id != network.chain_id.
+
Nonce
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/intrinsic_validity/nonce_minus_oneInvalid if tx.nonce == sender.nonce - 1.
transaction_type/test/intrinsic_validity/nonce_plus_oneInvalid if tx.nonce == sender.nonce + 1.
transaction_type/test/intrinsic_validity/nonce_exactValid if tx.nonce == sender.nonce.
+
To
+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/intrinsic_validity/toValid/Invalid if tx.to == None, depending on the EIP.
+
Value
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/intrinsic_validity/value_non_zero_insufficient_balanceInvalid if tx.value == 1 and account.balance == (tx.max_fee_per_gas * tx.gas_price).
transaction_type/test/intrinsic_validity/value_non_zero_sufficient_balanceValid if tx.value == 1 and account.balance == (tx.max_fee_per_gas * tx.gas_price) + 1.
transaction_type/test/intrinsic_validity/value_zero_insufficient_balanceInvalid if tx.value == 0 and account.balance == (tx.max_fee_per_gas * tx.gas_price) - 1.
transaction_type/test/intrinsic_validity/value_zero_sufficient_balanceValid if tx.value == 0 and account.balance == (tx.max_fee_per_gas * tx.gas_price).
+
Data
+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/intrinsic_validity/data_floor_above_intrinsic_gas_costInvalid if data_floor_cost(len(tx.data)) > tx.intrinsic_gas_cost and tx.gas_limit == tx.intrinsic_gas_cost.
transaction_type/test/intrinsic_validity/data_floor_above_intrinsic_gas_costValid if data_floor_cost(len(tx.data)) > tx.intrinsic_gas_cost and tx.gas_limit == data_floor_cost(len(tx.data)).
+

Signature

+

Verify the transaction is correctly rejected if it contains an invalid signature.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/signature/invalid/field_outside_curveV, R, S represent a value that is inside of the field but outside of the curve.
+
V
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/signature/invalid/v/22.
transaction_type/test/signature/invalid/v/2727 (Type-0 transaction valid value).
transaction_type/test/signature/invalid/v/2828 (Type-0 transaction valid value).
transaction_type/test/signature/invalid/v/3535 (Type-0 replay-protected transaction valid value for chain id 1).
transaction_type/test/signature/invalid/v/3636 (Type-0 replay-protected transaction valid value for chain id 1).
transaction_type/test/signature/invalid/v/max2**8-1.
+
R
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/signature/invalid/r/00.
transaction_type/test/signature/invalid/r/secp256k1n_minus_oneSECP256K1N-1.
transaction_type/test/signature/invalid/r/secp256k1nSECP256K1N.
transaction_type/test/signature/invalid/r/secp256k1n_plus_oneSECP256K1N+1.
transaction_type/test/signature/invalid/r/max_minus_one2**256-1.
transaction_type/test/signature/invalid/r/max2**256.
+
S
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/signature/invalid/s/00.
transaction_type/test/signature/invalid/s/secp256k1n_half_minus_oneSECP256K1N//2-1.
transaction_type/test/signature/invalid/s/secp256k1n_halfSECP256K1N//2.
transaction_type/test/signature/invalid/s/secp256k1n_half_plus_oneSECP256K1N//2+1.
transaction_type/test/signature/invalid/s/secp256k1n_minus_oneSECP256K1N-1.
transaction_type/test/signature/invalid/s/secp256k1nSECP256K1N.
transaction_type/test/signature/invalid/s/secp256k1n_plus_oneSECP256K1N+1.
transaction_type/test/signature/invalid/s/max_minus_one2**256-1.
transaction_type/test/signature/invalid/s/max2**256.
transaction_type/test/signature/invalid/s/complementSECP256K1N - S of a valid signature.
+

Transaction Attributes Readable From EVM

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/tx_scoped_attributes/readVerify attributes that can be read in the EVM from transaction fields.
transaction_type/test/tx_scoped_attributes/older_tx_typesVerify attributes specific to the new transaction type that can be read in the EVM behave correctly on older transaction types.
+

Transaction-Scoped Persistent Values

+

Verify values or variables that are persistent through the execution of the transaction (e.g. transient storage, warm/cold accounts).

+

| transaction_type/test/tx_scoped_attributes/persistent/throughout | Persist throughout the entire transaction. | | | +| transaction_type/test/tx_scoped_attributes/persistent/reset | Reset on subsequent transactions in the same block. | | |

+

Encoding (RLP, SSZ)

+

Verify correct transaction rejection in all listed scenarios.

+
Field Sizes
+

Verify all listed scenarios for each transaction field.

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/encoding/field_sizes/leading_zeroAdd leading zero byte.
transaction_type/test/encoding/field_sizes/remove_byteRemove single byte from fixed-byte-length fields.
+
Fields of List Type
+

Verify for each transaction field that is of type list.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/encoding/list_field/zeroZero-element list (Failure depending on EIP).
transaction_type/test/encoding/list_field/maxMax count list.
transaction_type/test/encoding/list_field/max_plus_oneMax count plus one list.
+
Extra/Missing Fields
+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/encoding/missing_fieldsAny fields particular to the new transaction types are missing.
transaction_type/test/encoding/extra_fieldsTransaction contains extra fields.
+
Serialization Corruption
+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/encoding/truncatedSerialized bytes object is truncated by one byte.
transaction_type/test/encoding/extra_bytesSerialized bytes object has one extra byte.
+
Serializable Fields
+

Verify for each serializable field, all previous tests plus following listed scenario.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/encoding/new_types/incorrect_encodingSerializable field is encoded as bytes instead of using the correct encoding (e.g. list in the case of RLP).
+

Out-of-bounds checks

+

Verify if the transaction has out-of-bounds conditions in its fields and verify.

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/out_of_bounds/maxMax value for each field.
transaction_type/test/out_of_bounds/max_plus_oneMax value + 1 for each field.
+

Contract creation

+

Verify that the transaction can create new contracts if the transaction type supports it.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/contract_creationCreate contracts using new transaction type.
+

Sender account modifications

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/sender_account/nonceSender account has its nonce incremented at least by one after the transaction is included in a block (or more if the transaction type introduces a new mechanism that bumps the nonce by more than one).
transaction_type/test/sender_account/balanceSender account has its balance reduced by the correct amount (gas consumed and value) at the start of execution (e.g. using BALANCE).
+

Block Level Interactions

+
Single Transaction In Block
+

Verify a block where the new transaction type is the sole transaction contained in the block.

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/block_interactions/single_tx/invalidInvalid if tx.gas_limit == block.gas_limit + 1.
transaction_type/test/block_interactions/single_tx/validValid if tx.gas_limit == block.gas_limit.
+
Two Transactions In Block
+

Verify a block where the new transaction type is the last transaction contained in a block with two transactions.

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/block_interactions/last_tx/validValid if block.txs[0].gas_used + block.txs[1].gas_limit == block.gas_limit.
transaction_type/test/block_interactions/last_tx/invalidInvalid if (block.txs[0].gas_used + block.txs[1].gas_limit == block.gas_limit + 1) and (block.txs[0].gas_used < block.gas_limit).
+
EIP-7825
+

Verify a transaction of the new type is rejected if its gas limit exceeds the EIP-7825 gas limit for the current fork.

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/block_interactions/eip7825/invalidExceeds EIP-7825 gas limit by one.
transaction_type/test/block_interactions/eip7825/validGas limit is exactly the EIP-7825 gas limit.
+
Mixed transactions
+

Verify a block with all transactions types including the new type is executed correctly.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/block_interactions/mixed_txsMixed transactions.
+

Fork transition

+

Verify that a block prior to fork activation where the new transaction type is introduced and containing the new transaction type is invalid.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/fork_transition/beforeNew transaction type included before fork activation block.
+

RPC Tests

+
    +
  • *Verify eth_estimateGas behavior for different valid combinations of the new transaction type.
  • +
  • transaction_type/test/rpc/send_raw | Verify eth_sendRawTransaction using execute.
  • +
+

*Tests must be added to execution-apis repository.

+

Framework Changes

+
    +
  • Modify transaction_intrinsic_cost_calculator in the fork where the EIP is introduced in src/ethereum_test_forks/forks/forks.py, adding the appropriate new fields that the transaction introduced and the logic to the intrinsic gas cost calculation, if any.
  • +
  • Add the transaction type number to tx_types response in the fork where the EIP is introduced in src/ethereum_test_forks/forks/forks.py (If applicable add also to contract_creating_tx_types).
  • +
+

New Block Header Field

+

Test Vectors

+

Genesis value

+

Verify, if possible, that the value can be set at genesis if the network starting fork is the activation fork, and that clients can consume such genesis.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
block_header_field/test/genesisNew block header field at genesis.
+

Value behavior

+

Verify, given multiple initial values, that a block is accepted or rejected depending on the correct expected value for the current block.

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
block_header_field/test/value_behavior/acceptBlock is accepted if the value is the correct expected for the current block, depending on the circumstances that affect the value as defined in the EIP.
block_header_field/test/value_behavior/rejectBlock is rejected if the value is modified (using block.rlp_modifier) to an incorrect value for the current block, depending on the circumstances that affect the value as defined in the EIP.
+

Fork transition

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
block_header_field/test/fork_transition/initialVerify initial value of the field at the first block of the activation fork.
block_header_field/test/fork_transition/beforeVerify that a block containing the new header field before the activation of the fork is invalid.
block_header_field/test/fork_transition/afterVerify that a block lacking the new header field at the activation of the fork is invalid.
+

Framework Changes

+
    +
  • Add the new header field to the relevant objects: +
      +
    • ethereum_test_fixtures.FixtureHeader.
    • +
    • ethereum_test_fixtures.FixtureExecutionPayload.
    • +
    • ethereum_test_specs.Header.
    • +
    +
  • +
  • Add the appropriate header_*_required fork method to BaseFork in ethereum_test_forks.
  • +
+

New Block Body Field

+

Test Vectors

+

Value behavior

+

Verify, given multiple initial values, that a block is accepted or rejected depending on the correct expected value for the current block.

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
block_body_field/test/value_behavior/acceptBlock is accepted if the value is the correct expected for the current block, depending on the circumstances that affect the value as defined in the EIP.
block_body_field/test/value_behavior/rejectBlock is rejected if the value is modified (using appropriate block) to an incorrect value for the current block, depending on the circumstances that affect the value as defined in the EIP.
+

Fork transition

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
block_body_field/test/fork_transition/beforeVerify that a block containing the new block body field before the activation of the fork is invalid.
block_body_field/test/fork_transition/afterVerify that a block lacking the new block field at the activation of the fork is invalid.
+

Framework Changes

+
    +
  • Add the new body field to the relevant objects. +
      +
    • ethereum_test_fixtures.FixtureBlockBase.
    • +
    • ethereum_test_fixtures.FixtureEngineNewPayload.
    • +
    • ethereum_test_specs.Block.
    • +
    +
  • +
  • Modify ethereum_test_specs.BlockchainTest filling behavior to account for the new block field.
  • +
+

Gas Cost Changes

+

Test Vectors

+

Gas Usage

+

Measure and store the gas usage during the operations affected by the gas cost changes and verify the updated behavior.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
gas_cost_changes/test/gas_updates_measurementMeasure updated gas costs.
+

Out-of-gas

+

Verify the operations affected by the gas cost changes can run out-of-gas with the updated limits.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
gas_cost_changes/test/out_of_gasOut-Of-Gas with new gas prices.
+

Fork transition

+

Verify gas costs are updated at the fork transition boundary.

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
gas_cost_changes/test/fork_transition/beforeCosts unaffected before the fork activation block.
gas_cost_changes/test/fork_transition/afterCosts are updated on and after fork activation block.
+

Framework Changes

+
    +
  • Modify transaction_intrinsic_cost_calculator in the fork where the EIP is introduced in src/ethereum_test_forks/forks/forks.py if the EIP affects intrinsic gas cost calculation.
  • +
  • Modify transaction_data_floor_cost_calculator in the fork where the EIP is introduced in src/ethereum_test_forks/forks/forks.py if the EIP affects calldata floor cost.
  • +
  • Modify memory_expansion_gas_calculator in the fork where the EIP is introduced in src/ethereum_test_forks/forks/forks.py if the EIP affects memory expansion gas cost calculation.
  • +
  • Modify gas_costs in the fork where the EIP is introduced in src/ethereum_test_forks/forks/forks.py if the EIP affects specific opcode gas costs.
  • +
+

Gas Refunds Changes

+

Test Vectors

+

Refund calculation

+

Verify that the refund does not exceed gas_used // MAX_REFUND_QUOTIENT (MAX_REFUND_QUOTIENT==5 in EIP-3529) in the following scenarios.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
gas_refunds_changes/test/refund_calculation/overrefund == gas_used // MAX_REFUND_QUOTIENT + 1.
gas_refunds_changes/test/refund_calculation/exactrefund == gas_used // MAX_REFUND_QUOTIENT.
gas_refunds_changes/test/refund_calculation/underrefund == gas_used // MAX_REFUND_QUOTIENT - 1.
+

Exceptional Abort

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
gas_refunds_changes/test/exceptional_abort/revertableIf the operation causing the refund can be reverted, verify the refund is not applied if the following cases:.
gas_refunds_changes/test/exceptional_abort/revertable/revertREVERT.
gas_refunds_changes/test/exceptional_abort/revertable/out_of_gasOut-of-gas.
gas_refunds_changes/test/exceptional_abort/revertable/invalid_opcodeInvalid opcode.
gas_refunds_changes/test/exceptional_abort/revertable/upper_revertREVERT of an upper call frame.
gas_refunds_changes/test/exceptional_abort/non_revertableIf the operation causing the refund cannot be reverted (e.g. in the case of a transaction-scoped operation such as authorization refunds in EIP-7702), verify the refund is still applied even in the following cases:.
gas_refunds_changes/test/exceptional_abort/non_revertable/revertREVERT at the top call frame.
gas_refunds_changes/test/exceptional_abort/non_revertable/out_of_gasOut-of-gas at the top call frame.
gas_refunds_changes/test/exceptional_abort/non_revertable/invalid_opcodeInvalid opcode at the top call frame.
+

Cross-Functional Test

+

Verify the following tests are updated to support the new type of refunds.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
gas_refunds_changes/test/cross_functional/calldata_costtests/prague/eip7623_increase_calldata_cost/test_refunds.py.
+

Framework Changes

+

N/A

+

Blob Count Changes

+

Test Vectors

+

Existing Test Updates

+

Verify tests in tests/cancun/eip4844_blobs were correctly and automatically updated to take into account the new blob count values at the new fork activation block.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
blob_count_changes/test/eip4844_blobs_changesUpdates to tests/cancun/eip4844_blobs were applied correctly.
+

Framework Changes

+
    +
  • Modify blob_base_fee_update_fraction, target_blobs_per_block, max_blobs_per_block in the fork where the EIP is introduced in src/ethereum_test_forks/forks/forks.py if the EIP affects any of the values returned by each function.
  • +
+

New Execution Layer Request

+

Test Vectors

+

Cross-Request-Type Interaction

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
execution_layer_request/test/cross_request_type/updateUpdate tests/prague/eip7685_general_purpose_el_requests tests to include the new request type in the tests combinations.
+

Framework Changes

+
    +
  • Increment max_request_type in the fork where the EIP is introduced in src/ethereum_test_forks/forks/forks.py to the new maximum request type number after the EIP is activated.
  • +
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/exception_tests/index.html b/docs/public/main/exception_tests/index.html new file mode 100644 index 00000000000..02303b502d4 --- /dev/null +++ b/docs/public/main/exception_tests/index.html @@ -0,0 +1,1453 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

Exception Tests

+

Exception tests are a special type of test which verify that an invalid transaction or an invalid block are correctly rejected with the expected error.

+

Creating an Exception Test

+

To test for an exception, the test can use either of the following types from ethereum_test_exceptions library:

+
    +
  1. +

    TransactionException: To be added to the error field of the Transaction object, and to the exception field of the Block object that includes the transaction; this exception type is used when a transaction is invalid, and therefore when included in a block, the block is expected to be invalid too. This is different from valid transactions where an exception during EVM execution is expected (e.g. a revert, or out-of-gas), which can be included in valid blocks.

    +

    For an example, see eip3860_initcode.test_initcode.test_contract_creating_tx which raises TransactionException.INITCODE_SIZE_EXCEEDED in the case that the initcode size exceeds the maximum allowed size.

    +
  2. +
  3. +

    BlockException: To be added to the exception field of the Block object; this exception type is used when a block is expected to be invalid, but the exception is related to a block property, e.g. an invalid value of the block header.

    +

    For an example, see eip4844_blobs.test_excess_blob_gas.test_invalid_static_excess_blob_gas which raises BlockException.INCORRECT_EXCESS_BLOB_GAS in the case that the excessBlobGas remains unchanged +but the parent blobs included are not TARGET_BLOBS_PER_BLOCK.

    +
  4. +
+

Although exceptions can be combined with the | operator to indicate that a test vector can throw either one of multiple exceptions, ideally the tester should aim to use only one exception per test vector, and only use multiple exceptions on the rare instance when it is not possible to know which exception will be thrown because it depends on client implementation.

+

Adding a new exception

+

If a test requires a new exception, because none of the existing ones is suitable for the test, a new exception can be added to either TransactionException or BlockException classes.

+

The new exception should be added as a new enum value, and the docstring of the attribute should be a string that describes the exception.

+

The name of the exception should be unique, and should not be used by any other exception.

+

Test runner behavior on exception tests

+

When an exception is added to a test vector, the test runner must check that the transaction or block is rejected with the expected exception.

+

The test runner must map the exception key to the corresponding error string that is expected to be returned by the client.

+

Exception mapping are particularly important in blockchain tests because the block can be invalid for multiple reasons, and the client returning a different error can mean that a verification in the client is faulty.

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/exceptions/index.html b/docs/public/main/exceptions/index.html new file mode 100644 index 00000000000..ec173c81170 --- /dev/null +++ b/docs/public/main/exceptions/index.html @@ -0,0 +1,1309 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

Exceptions

+

Exception types are represented as a JSON string in the test fixtures.

+

The exception converted into a string is composed of the exception type name, +followed by a period, followed by the specific exception name.

+

For example, the exception INSUFFICIENT_ACCOUNT_FUNDS of type +TransactionException is represented as +"TransactionException.INSUFFICIENT_ACCOUNT_FUNDS".

+

The JSON string can contain multiple exception types, separated by the | +character, denoting that the transaction or block can throw either one of +the exceptions.

+

For a list of all defined exceptions look at Ethereum Test Exceptions Package.

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/filling_tests/debugging_t8n_tools/index.html b/docs/public/main/filling_tests/debugging_t8n_tools/index.html new file mode 100644 index 00000000000..9610a1cf329 --- /dev/null +++ b/docs/public/main/filling_tests/debugging_t8n_tools/index.html @@ -0,0 +1,1426 @@ + + + + + + + Debugging Transition Tools - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

Debugging Transition Tools

+
+ +
+

There are two flags that can help debugging t8n tools or the execution-spec-tests framework:

+
    +
  1. --evm-dump-dir (Default: /logs/evm): Write debug information from t8n tool calls to the specified directory.
  2. +
  3. --traces: Collect traces of the execution from the transition tool.
  4. +
  5. --verify-fixtures: Run go-ethereum’s evm blocktest command to verify the generated test fixtures.
  6. +
+

EVM Dump Directory

+

The --evm-dump-dir flag tells the framework to write the inputs and outputs of every call made to the t8n command to the specified output directory. The aim is to help debugging or simply understand how a test is interacting with the EVM. The default location is logs/evm in the project root.

+

Each test case receives its own sub-directory under the --evm-dump-dir that contains these files which can be easily accessed from the HTML test report generated by fill (located by default in the root of the --output directory).

+
+ ![HTML Report Summary](./img/evm_dump_dir_in_html_report.png){width=auto align=center} +
+

In particular, a script t8n.sh is generated for each call to the t8n command which can be used to reproduce the call to trigger errors or attach a debugger without the need to execute Python.

+

For example, running:

+
fill tests/berlin/eip2930_access_list/ --fork Berlin -m blockchain_test \
+    --evm-dump-dir=/tmp/evm-dump --traces
+

will produce the directory structure:

+
πŸ“‚ /tmp/evm-dump
+└── πŸ“‚ berlin__eip2930_access_list__test_acl__test_access_list
+    └── πŸ“‚ fork_Berlin_blockchain_test
+        └── πŸ“‚ 0
+         Β Β  β”œβ”€β”€ πŸ“„ args.py
+         Β Β  β”œβ”€β”€ πŸ“‚ input
+         Β Β  β”‚Β Β  β”œβ”€β”€ πŸ“„ alloc.json
+         Β Β  β”‚Β Β  β”œβ”€β”€ πŸ“„ env.json
+         Β Β  β”‚Β Β  └── πŸ“„ txs.json
+         Β Β  β”œβ”€β”€ πŸ“‚ output
+         Β Β  β”‚Β Β  β”œβ”€β”€ πŸ“„ alloc.json
+         Β Β  β”‚Β Β  β”œβ”€β”€ πŸ“„ result.json
+         Β Β  β”‚Β Β  └── πŸ“„ txs.rlp
+         Β Β  β”œβ”€β”€ πŸ“„ returncode.txt
+         Β Β  β”œβ”€β”€ πŸ“„ stderr.txt
+         Β Β  β”œβ”€β”€ πŸ“„ stdin.txt
+         Β Β  β”œβ”€β”€ πŸ“„ stdout.txt
+         Β Β  β”œβ”€β”€ πŸ“„ t8n.sh
+            └── πŸ“„ trace-0-0x5c4f07ce52f0a276a06aabdfff16cc693b5e007c018f9a42431e68200e2da515.jsonl
+

where the directory 0 is the starting index of the different calls made to the t8n tool executed during the test, and since the test only contains one block, there is only one directory present.

+

Note, there may be more directories present 1, 2, 3,… if the test executes more blocks.

+

Each directory contains files containing information corresponding to the call, for example, the args.py file contains the arguments passed to the t8n command and the output/alloc.json file contains the output of the t8n command’s --output-alloc flag.

+

The t8n.sh Script

+

The t8n.sh script written to the debug directory can be used to reproduce a specific call made to the t8n command during the test session. For example, if a Besu t8n-server has been started on port 3001, the request made by the test for first block can be reproduced as:

+
/tmp/besu/test_access_list_fork_Berlin/0/t8n.sh 3001
+

which writes the response the from the t8n-server to the console output:

+
{
+  "alloc" : {
+    "0x000000000000000000000000000000000000aaaa" : {
+      "code" : "0x5854505854",
+      "balance" : "0x4",
+      "nonce" : "0x1"
+    },
+    "0x2adc25665018aa1fe0e6bc666dac8fc2697ff9ba" : {
+      "balance" : "0x1bc16d674ecb26ce"
+    },
+    "0xa94f5374fce5edbc8e2a8697c15331677e6ebf0b" : {
+      "balance" : "0x2cd931",
+      "nonce" : "0x1"
+    }
+  },
+  "body" : "0xf8a0b89e01f89b0180078304ef0094000000000000000000000000000000000000aaaa0180f838f7940000000000000000000000000000000000000000e1a0000000000000000000000000000000000000000000000000000000000000000001a02e16eb72206c93c471b5894800495ee9c64ae2d9823bcc4d6adeb5d9d9af0dd4a03be6691e933a0816c59d059a556c27c6753e6ce76d1e357b9201865c80b28df3",
+  "result" : {
+    "stateRoot" : "0x51799508f764047aee6606bc6a00863856f83ee5b91555f00c8a3cbdfbec5acb",
+    ...
+    ...
+  }
+}
+

The t8n.sh is written to the debug directory for all supported t8n tools.

+

Verifying Test Fixtures via evm blocktest

+

The --verify-fixtures flag can be used to run go-ethereum’s evm blocktest command in order to verify the generated JSON test fixtures.

+

For example, running:

+
fill tests/berlin/eip2930_access_list/ --fork Berlin -m blockchain_test \
+    --evm-dump-dir==/tmp/evm-dump \
+    --evm-bin=../evmone/build/bin/evmone-t8n \
+    --verify-fixtures-bin=../go-ethereum/build/bin/evm \
+    --verify-fixtures
+

will additionally run the evm blocktest command on every JSON fixture file and write its output to the EVM dump directory:

+
πŸ“‚ /tmp/evm-dump
+└── πŸ“‚ berlin__eip2930_access_list__test_acl__test_access_list
+    β”œβ”€β”€ πŸ“„ fixtures.json
+    β”œβ”€β”€ πŸ“‚ fork_Berlin_blockchain_test
+    β”‚Β Β  β”œβ”€β”€ πŸ“‚ 0
+    β”‚Β Β  β”‚Β Β  β”œβ”€β”€ πŸ“„ args.py
+    β”‚Β Β  β”‚Β Β  β”œβ”€β”€ πŸ“‚ input
+    β”‚Β Β  β”‚Β Β  β”‚Β Β  β”œβ”€β”€ πŸ“„ alloc.json
+    β”‚Β Β  β”‚Β Β  β”‚Β Β  β”œβ”€β”€ πŸ“„ env.json
+    β”‚Β Β  β”‚Β Β  β”‚Β Β  └── πŸ“„ txs.json
+    β”‚Β Β  β”‚Β Β  β”œβ”€β”€ πŸ“‚ output
+    β”‚Β Β  β”‚Β Β  β”‚Β Β  β”œβ”€β”€ πŸ“„ alloc.json
+    β”‚   ... ... ...
+    β”‚
+    β”œβ”€β”€ πŸ“„ verify_fixtures_args.py
+    β”œβ”€β”€ πŸ“„ verify_fixtures_returncode.txt
+    β”œβ”€β”€ πŸ“„ verify_fixtures.sh
+    β”œβ”€β”€ πŸ“„ verify_fixtures_stderr.txt
+    └── πŸ“„ verify_fixtures_stdout.txt
+

where the verify_fixtures.sh script can be used to reproduce the evm blocktest command.

+

Further --verify-fixtures Examples

+
    +
  1. +

    No fixture verification performed:

    +
    fill
    +
  2. +
  3. +

    Verify fixtures: Use the first evm binary in the PATH to execute both the t8n and blocktest commands (i.e., same binary used; this must be a geth binary):

    +
    fill --verify-fixtures
    +
  4. +
  5. +

    Explicitly specify the evm binary to execute the blocktest command (the first evm binary in the PATH is used for t8n commands; --verify-fixtures is not necessary):

    +
    fill --verify-fixtures-bin=../go-ethereum/build/bin/evm
    +
  6. +
  7. +

    Explicitly set two different evm binaries to execute the t8n and blocktest commands; write debug data to the specified --evm-dump-dir:

    +
    fill --evm-bin=../evmone/build/bin/evmone-t8n \
    +  --verify-fixtures-bin=../go-ethereum/build/bin/evm \
    +  --evm-dump-dir=/tmp/evm-dump
    +
  8. +
  9. +

    Additionally use --single-fixture-per-file to improve the granularity of the reporting of the evm blocktest command by writing the fixture generated by each parametrized test case to its own file.

    +
    fill --evm-bin=../evmone/build/bin/evmone-t8n \
    +  --verify-fixtures-bin=../go-ethereum/build/bin/evm \
    +  --evm-dump-dir=/tmp/evm-dump \
    +  --single-fixture-per-file
    +
  10. +
+ + +
+
Execution scope of evm blocktest
+
+

Note, by default, that evm blocktest is not executed per parametrized test case, but rather per test function. This is because each fixture JSON file contains fixtures for all the parametrized test cases for one test function. This means only one error will be reported, even if multiple fixtures fail within one fixture file.

+

Additionally, it is only executed after all the test cases in the module have been executed and will only report the first failing test fixture in all files, even if there are multiple failing fixture files. This limitation is required to enable support of the pytest-xdist plugin for concurrent test execution across multiple CPUs. To achieve this we use the we apply the --dist loadscope xdist flag in our pytest.ini.

+

This means, by default, that the feedback is not as granular as for test case execution. To improve granularity, and get feedback per parametrized test case use --single-fixture-per-file.

+ +
+
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/filling_tests/filling_tests/evm_dump_dir_in_html_report.png b/docs/public/main/filling_tests/filling_tests/evm_dump_dir_in_html_report.png new file mode 100644 index 00000000000..1979b5dd40f Binary files /dev/null and b/docs/public/main/filling_tests/filling_tests/evm_dump_dir_in_html_report.png differ diff --git a/docs/public/main/filling_tests/filling_tests_command_line/index.html b/docs/public/main/filling_tests/filling_tests_command_line/index.html new file mode 100644 index 00000000000..bd17aa7f1f7 --- /dev/null +++ b/docs/public/main/filling_tests/filling_tests_command_line/index.html @@ -0,0 +1,1359 @@ + + + + + + + Filling Tests at a Prompt - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

Filling Tests at a Prompt

+
+ +
+

The execution-spec-tests test framework uses the pytest framework for test case collection and execution. The fill command is essentially an alias for pytest, which uses several custom pytest plugins to run transition tools against test cases and generate JSON fixtures.

+ + +
+
Options specific to execution-spec-tests
+
+

The command-line options specific to filling tests can be listed via:

+
uv run fill --help
+

See Custom fill Command-Line Options for all options.

+ +
+
+

Collection - Test Exploration

+

The test cases implemented in the ./tests sub-directory can be listed in the console using:

+
uv run fill --collect-only
+

and can be filtered (by test path, function and parameter substring):

+
uv run fill --collect-only -k warm_coinbase
+

Docstrings are additionally displayed when ran verbosely:

+
uv run fill --collect-only -k warm_coinbase -vv
+

Execution

+

By default, test cases are filled for all forks already deployed to mainnet, but not for forks still under active development, i.e., as of time of writing, Q2 2023:

+
uv run fill
+

will generate fixtures for test cases from Frontier to Shanghai.

+

To generate all the test fixtures defined in the ./tests/shanghai sub-directory and write them to the ./fixtures-shanghai directory, run fill in the top-level directory as:

+
uv run fill ./tests/shanghai --output="fixtures-shanghai"
+
+ +
+
Test case verification
+
+ Note, that the (limited set of) test post conditions are tested against the output of the evm t8n command during test generation. +
+
+

To generate all the test fixtures in the tests/shanghai/eip3651_warm_coinbase/test_warm_coinbase.py module, for example, run:

+
uv run fill tests/shanghai/eip3651_warm_coinbase/test_warm_coinbase.py
+

To generate specific test fixtures from a specific test function or even test function and parameter set, obtain the corresponding test ID using:

+
uv run fill --collect-only -q -k test_warm_coinbase
+

This filters the tests by test_warm_coinbase. Then find the relevant test ID in the console output and provide it to fill, for example, for a test function:

+
uv run fill tests/shanghai/eip3651_warm_coinbase/test_warm_coinbase.py::test_warm_coinbase_gas_usage
+

or, for a test function and specific parameter combination:

+
uv run fill tests/shanghai/eip3651_warm_coinbase/test_warm_coinbase.py::test_warm_coinbase_gas_usage[fork_Paris-DELEGATECALL]
+

Execution for Development Forks

+ + +
+
Note
+
+

By default, test cases are not filled for upcoming Ethereum forks so that they can be readily filled using the evm tool from the latest geth release.

+

In order to fill test cases for an upcoming fork, ensure that the evm tool used supports that fork and features under test and use the --until or --fork flag.

+

For example, as of Q2 2023, the current fork under active development is Cancun:

+
uv run fill --until Cancun
+
+
+
+

See: Filling Tests for Features under Development.

+

Debugging the t8n Command

+

The --evm-dump-dir flag can be used to dump the inputs and outputs of every call made to the t8n command for debugging purposes, see Debugging Transition Tools.

+

Other Useful Pytest Command-Line Options

+
uv run fill -vv            # More verbose output
+uv run fill -x             # Exit instantly on first error or failed test case
+uv run fill --pdb -nauto   # Drop into the debugger upon error in a test case
+uv run fill -s             # Print stdout from tests to the console during execution
+

Custom fill Command-Line Options

+

To see all the options available to fill, including pytest and pytest plugin options, use --pytest-help.

+

To list the options that only specific to fill, use:

+
uv run fill --help
+

For a complete, up-to-date list of all command-line options, see the Fill Command-Line Options page, which is automatically generated from the current uv run fill --help output.

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/filling_tests/filling_tests_dev_fork/index.html b/docs/public/main/filling_tests/filling_tests_dev_fork/index.html new file mode 100644 index 00000000000..870444bc412 --- /dev/null +++ b/docs/public/main/filling_tests/filling_tests_dev_fork/index.html @@ -0,0 +1,1505 @@ + + + + + + + Filling Tests for Features under Development - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

Filling Tests for Features under Development

+
+ +
+

Requirements

+

By default, execution-spec-tests only generates fixtures for forks that have been deployed to mainnet. In order to generate fixtures for evm features that are actively under development:

+
    +
  1. A version of the evm and solc tools that implement the feature must be available (although, typically only a developer version of the evm tool is required, usually the latest stable release of solc is adequate), and,
  2. +
  3. The development fork to test must be explicitly specified on the command-line:
  4. +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
+ + + + + + + +
+ +
+ +
+
uv run fill -k 4844 --fork=Cancun -v
+
+
+ +
+
uv run fill -k 4844 --from=Cancun -v
+
+
+ +
+
uv run fill -k 4844 --until=Cancun -v
+
+
+ +
+
+ + + + + + + + + +
+
Specifying the evm binary via evm-bin
+
+

It is possible to explicitly specify the evm binary used to generate fixtures via the --evm-bin flag, for example,

+
uv run fill --fork=Cancun --evm-bin=/opt/bin/evm -v
+
+
+
+

Further Help

+
    +
  1. geth/evm build documentation.
  2. +
  3. solc build documentation.
  4. +
+ + +
+
Verifying evm and solc versions used
+
+ The versions used to generate fixtures are displayed in the console output: +Screenshot of pytest test collection console output +
+
+

VS Code Setup

+

By default, VS Code’s Testing View will only show tests for stable forks. To show tests for development forks, uncomment the relevant line in the python.testing.pytestArgs configuration section of included settings file (.vscode/settings.json) to enable the --until=FORK flag. See VS Code Setup for help finding the settings files.

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/filling_tests/filling_tests_vs_code/index.html b/docs/public/main/filling_tests/filling_tests_vs_code/index.html new file mode 100644 index 00000000000..58c8943de8d --- /dev/null +++ b/docs/public/main/filling_tests/filling_tests_vs_code/index.html @@ -0,0 +1,1306 @@ + + + + + + + Filling Tests in VS Code - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

Filling Tests in VS Code

+
+ +
+

Prerequisite: VS Code Setup.

+

Exploring Test Cases

+

Implemented test cases can be explored in VS Code’s “Testing” View; click on the conical flask highlighted in the screenshot below.

+

VS Code Testing Tab

+ + +
+
Testing EVM Features Under Active Development
+
+ See the VS Code section in Filling Tests for Features under Development to explore tests targeting EVM features under development. +
+
+

Filling and Debugging Test Cases

+

VS Code Testing Tab

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/filling_tests/getting_started/index.html b/docs/public/main/filling_tests/getting_started/index.html new file mode 100644 index 00000000000..7e980979283 --- /dev/null +++ b/docs/public/main/filling_tests/getting_started/index.html @@ -0,0 +1,1337 @@ + + + + + + + Getting Started - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

Getting Started

+
+ +
+

Getting Started: Filling Tests

+

This guide describes how to get started with fill and commonly-used command-line options.

+
    +
  1. +

    Explore test cases via --collect-only and search for test cases that combine PUSH0 and DELEGATECALL in the EVM functionality introduced in the Shanghai hard fork:

    +
    uv run fill --collect-only -k "push0 and delegatecall" tests/shanghai/
    +

    The fill command is based on pytest. The above command uses the optional pytest arguments:

    +
      +
    • --collect-only only collect test cases; don’t execute them.
    • +
    • -k <expression> filter test cases by their test case ID based on the given expression.
    • +
    • tests/shanghai the directory containing the test cases (tells fill to only discover test cases in this directory; default: tests/).
    • +
    +

    Expected console output:

    +
    + ![Screenshot of pytest test collection console output](./img/pytest_collect_only.png){align=center} +
    +
  2. +
  3. +

    Fill state_test fixtures for these test cases:

    +
    uv run fill -k "push0 and delegatecall" tests/shanghai/ -m state_test -v
    +

    where:

    +
      +
    • -m state_test only fills test cases marked as a state_test (see all available markers via uv run fill --markers).
    • +
    • -v enables verbose output.
    • +
    +

    Expected console output:

    +
    + ![Screenshot of fill test collection console output](./img/pytest_run_example.png){align=center} +
    +
  4. +
  5. +

    Verify the generated fixtures:

    +

    a. Check the corresponding fixture file has been generated:

    +
    head fixtures/state_tests/shanghai/eip3855_push0/push0/push0_contract_during_call_contexts.json
    +

    b. Open the generated HTML test using the link provided at the bottom of the console output. This is written to the output directory at:

    +
    ./fixtures/.meta/report_fill.html
    +
  6. +
+

Next Steps

+
    +
  1. Learn useful command-line flags.
  2. +
  3. Execute tests for features under development via the --fork flag.
  4. +
  5. Optional: Configure VS Code to auto-format Python code and execute tests within VS Code.
  6. +
  7. Implement a new test case, see Writing Tests.
  8. +
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/filling_tests/img/evm_dump_dir_in_html_report.png b/docs/public/main/filling_tests/img/evm_dump_dir_in_html_report.png new file mode 100644 index 00000000000..1979b5dd40f Binary files /dev/null and b/docs/public/main/filling_tests/img/evm_dump_dir_in_html_report.png differ diff --git a/docs/public/main/filling_tests/img/pytest_collect_only.png b/docs/public/main/filling_tests/img/pytest_collect_only.png new file mode 100644 index 00000000000..a20e58c2c8c Binary files /dev/null and b/docs/public/main/filling_tests/img/pytest_collect_only.png differ diff --git a/docs/public/main/filling_tests/img/pytest_run_example.png b/docs/public/main/filling_tests/img/pytest_run_example.png new file mode 100644 index 00000000000..96df337a21f Binary files /dev/null and b/docs/public/main/filling_tests/img/pytest_run_example.png differ diff --git a/docs/public/main/filling_tests/img/vs_code_executing_tests.png b/docs/public/main/filling_tests/img/vs_code_executing_tests.png new file mode 100644 index 00000000000..7c46ae2849b Binary files /dev/null and b/docs/public/main/filling_tests/img/vs_code_executing_tests.png differ diff --git a/docs/public/main/filling_tests/img/vs_code_exploring_tests.png b/docs/public/main/filling_tests/img/vs_code_exploring_tests.png new file mode 100644 index 00000000000..3618a2249d6 Binary files /dev/null and b/docs/public/main/filling_tests/img/vs_code_exploring_tests.png differ diff --git a/docs/public/main/filling_tests/main/index.html b/docs/public/main/filling_tests/main/index.html new file mode 100644 index 00000000000..a1223e9aaf2 --- /dev/null +++ b/docs/public/main/filling_tests/main/index.html @@ -0,0 +1,1326 @@ + + + + + + + Filling Tests - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

Filling Tests

+
+ +
+

Execution of test cases against clients is a two-step process:

+
    +
  1. JSON test fixtures are generated from the Python test cases found in ./tests using fill and an EVM transition tool (t8n) implementation.
  2. +
  3. Clients “consume” the JSON fixtures via either a dedicated, client-specific interface or a testing environment such as Hive.
  4. +
+

The process of generating fixtures is often referred to as “filling” the tests.

+ + +
+
The execute command
+
+ The execute command directly executes Python test cases against a client via its RPC without using generated JSON fixtures. For all other methods of testing clients, the JSON fixtures are required. For more information, see Executing Tests. +
+
+

Transition Tools (t8n)

+

The fill command requires an EVM t8n tool provided by most clients in order to generate the JSON fixtures. The t8n tool is mainly responsible for calculating the post-state of the EVM after executing a transaction, most relevantly, it calculates the updated state root.

+

Ethereum Execution Layer Specification (EELS)

+

By default, the Ethereum Execution Layer Specification (EELS) reference implementation of the t8n tool is used to generate test fixtures for all forks that have been deployed to Ethereum mainnet. We strong encourage EIP authors to provide a reference implementation of their EIP in EELS, so that it can be used to generate test fixtures for features under active development.

+

Limitations of Filling

+

The “fill-consume” method follows a differential testing approach: A reference implementation is used to generate JSON test fixtures, which can then be executed against other EVM clients. However:

+ + +
+
Successfully filling does not guarantee correctness
+
+

Some tests cases, particularly those without straightforward post-checks, such as certain gas calculations, may allow subtle inconsistencies to slip through during filling.

+

Consequently, filling the tests does not ensure the client’s correctness. Clients must consume the tests to be considered correctly tested, even if that client was used to fill the tests.

+ +
+
+

Filling Static Tests from ethereum/tests

+

Filling static test fillers in YAML or JSON formats from ethereum/tests is possible by adding the --fill-static-tests to the fill command.

+

This functionality is only available for backwards compatibility and copying legacy tests from the ethereum/tests repository into this one.

+

Adding new static test fillers is otherwise not allowed.

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/filling_tests/test_ids/index.html b/docs/public/main/filling_tests/test_ids/index.html new file mode 100644 index 00000000000..3c5824695c4 --- /dev/null +++ b/docs/public/main/filling_tests/test_ids/index.html @@ -0,0 +1,1351 @@ + + + + + + + An Explanation of Test IDs - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

An Explanation of Test IDs

+
+ +
+

Test Case Organization

+

Test cases are implemented in Python “modules”, which are organized by folder, named after the fork where the feature-under-test was introduced, for example:

+
    +
  • tests/cancun/ contains tests for features added in the Cancun hardfork.
  • +
  • tests/prague/ contains tests for features added in the Prague hardfork.
  • +
+

Test ID generation

+

A test ID is a string, generated by the test framework, that uniquely identifies a test case. It’s format is:

+
<python_test_module_path>::<python_test_function_name>[<parameter_1_id>-...-<parameter_N_id]
+

Let’s use the following simple test case example to understand this format:

+
tests/istanbul/eip1344_chainid/test_chainid.py::test_chainid[fork_Cancun-blockchain_test]
+

The components map as following:

+
    +
  • <python_test_module_path> - the Python “module” (file) where the test is implemented tests/istanbul/eip1344_chainid/test_chainid.py,
  • +
  • <python_test_function_name> - the Python test function: test_chainid,
  • +
  • [<parameter_1_id>-...-<parameter_N_id] - the test parameters, this test case has the following parameters: +
      +
    • fork_Cancun, to read “fork = Cancun”, the fork the test case is filled for,
    • +
    • blockchain_test, the test type.
    • +
    +
  • +
+

Although test_chainid is not directly parametrized on the test function level, the framework always parametrizes tests by fork and, if possible, by test type. If we inspect its function signature, we see that it’s native test format is of type StateTestFiller:

+
@pytest.mark.valid_from("Istanbul")
+def test_chainid(state_test: StateTestFiller, pre: Alloc):
+    """Test CHAINID opcode."""
+    ...
+

Parametrization by Fork

+

Every test case is parametrized by the fork where the feature-under-test remains valid, for example:

+
    +
  • Test cases in tests/cancun/ get filled for Cancun and Prague.
  • +
  • Test cases in tests/prague/, only get filled for Prague, at the time of writing, as Prague is the current fork in development.
  • +
+

All test IDs contain the fork_<name> parameter used to generate the test case in the test ID, e.g., test_Cancun.

+

Transition Forks

+

The test framework can also generate blockchain tests containing blocks that span a fork boundary, these test cases receive a special fork parameter name which contain both fork names and the timestamp at which the transition was made, e.g., fork_CancunToPragueAtTime15k.

+

Parametrization by Test Type

+

Each Python test case is also typically parametrized by test type, respectively fixture format. For example, if the test is implemented as a state_test, the test framework will additionally generate the following blockchain test fixtures (consisting of a single block with a single transaction):

+
    +
  • a blockchain_test which can be tested via the Hive eest/consume-rlp simulator (or directly via a dedicated client interface).
  • +
  • a blockchain_engine_test (for post-merge forks) which can be tested via the Hive eest/consume-engine simulator.
  • +
+

Example: The Test IDs generated for test_chainid

+

To see all the test cases and their IDs that get generated from London until Shanghai for test_chainid, we can execute fill with the --collect-only -q flags:

+
fill tests/istanbul/eip1344_chainid/test_chainid.py --from London --until Shanghai --collect-only -q 
+

which lists the following test IDs:

+
tests/istanbul/eip1344_chainid/test_chainid.py::test_chainid[fork_London-blockchain_test]
+tests/istanbul/eip1344_chainid/test_chainid.py::test_chainid[fork_London-state_test]
+tests/istanbul/eip1344_chainid/test_chainid.py::test_chainid[fork_Paris-blockchain_test]
+tests/istanbul/eip1344_chainid/test_chainid.py::test_chainid[fork_Paris-blockchain_test_engine]
+tests/istanbul/eip1344_chainid/test_chainid.py::test_chainid[fork_Paris-state_test]
+tests/istanbul/eip1344_chainid/test_chainid.py::test_chainid[fork_Shanghai-blockchain_test]
+tests/istanbul/eip1344_chainid/test_chainid.py::test_chainid[fork_Shanghai-blockchain_test_engine]
+tests/istanbul/eip1344_chainid/test_chainid.py::test_chainid[fork_Shanghai-state_test]
+

Additional Parametrization

+

The test function tests/cancun/eip4844_blobs/test_blob_txs.py::test_blob_type_tx_pre_fork is additionally parametrized:

+
tests/cancun/eip4844_blobs/test_blob_txs.py::test_blob_type_tx_pre_fork[fork_ShanghaiToCancunAtTime15k-blockchain_test-no_blob_tx]
+tests/cancun/eip4844_blobs/test_blob_txs.py::test_blob_type_tx_pre_fork[fork_ShanghaiToCancunAtTime15k-blockchain_test-one_blob_tx]
+

The strings no_blob_tx and one_blob_tx are additional descriptive parameter IDs that indicate the focus of the test.

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/filling_tests/transition_tool_support/index.html b/docs/public/main/filling_tests/transition_tool_support/index.html new file mode 100644 index 00000000000..8575ec24324 --- /dev/null +++ b/docs/public/main/filling_tests/transition_tool_support/index.html @@ -0,0 +1,1334 @@ + + + + + + + Transition Tool Support - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

Transition Tool Support

+
+ +
+

The following transition tools are supported by the framework:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Clientt8n ToolTracing Support
ethereum/evmoneevmone-t8nYes
ethereum/execution-specsethereum-spec-evm-resolverYes
ethereumjsethereumjs-t8ntool.shNo
ethereum/go-ethereumevm t8nYes
hyperledger/besuevmtool t8n-serverYes
status-im/nimbus-eth1t8nYes
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/filling_tests_command_line/index.html b/docs/public/main/filling_tests_command_line/index.html new file mode 100644 index 00000000000..f8f1e819e7b --- /dev/null +++ b/docs/public/main/filling_tests_command_line/index.html @@ -0,0 +1,1366 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

Filling Tests at a Prompt

+

The execution-spec-tests test framework uses the pytest framework for test case collection and execution. The fill command is essentially an alias for pytest, which uses several custom pytest plugins to run transition tools against test cases and generate JSON fixtures.

+ + +
+
Options specific to execution-spec-tests
+
+

The command-line options specific to filling tests can be listed via:

+
uv run fill --help
+

See Custom fill Command-Line Options for all options.

+ +
+
+

Collection - Test Exploration

+

The test cases implemented in the ./tests sub-directory can be listed in the console using:

+
uv run fill --collect-only
+

and can be filtered (by test path, function and parameter substring):

+
uv run fill --collect-only -k warm_coinbase
+

Docstrings are additionally displayed when ran verbosely:

+
uv run fill --collect-only -k warm_coinbase -vv
+

Execution

+

By default, test cases are filled for all forks already deployed to mainnet, but not for forks still under active development, i.e., as of time of writing, Q2 2023:

+
uv run fill
+

will generate fixtures for test cases from Frontier to Shanghai.

+

To generate all the test fixtures defined in the ./tests/shanghai sub-directory and write them to the ./fixtures-shanghai directory, run fill in the top-level directory as:

+
uv run fill ./tests/shanghai --output="fixtures-shanghai"
+
+ +
+
Test case verification
+
+ Note, that the (limited set of) test post conditions are tested against the output of the evm t8n command during test generation. +
+
+

To generate all the test fixtures in the tests/shanghai/eip3651_warm_coinbase/test_warm_coinbase.py module, for example, run:

+
uv run fill tests/shanghai/eip3651_warm_coinbase/test_warm_coinbase.py
+

To generate specific test fixtures from a specific test function or even test function and parameter set, obtain the corresponding test ID using:

+
uv run fill --collect-only -q -k test_warm_coinbase
+

This filters the tests by test_warm_coinbase. Then find the relevant test ID in the console output and provide it to fill, for example, for a test function:

+
uv run fill tests/shanghai/eip3651_warm_coinbase/test_warm_coinbase.py::test_warm_coinbase_gas_usage
+

or, for a test function and specific parameter combination:

+
uv run fill tests/shanghai/eip3651_warm_coinbase/test_warm_coinbase.py::test_warm_coinbase_gas_usage[fork_Paris-DELEGATECALL]
+

Execution for Development Forks

+ + +
+
Note
+
+

By default, test cases are not filled for upcoming Ethereum forks so that they can be readily filled using the evm tool from the latest geth release.

+

In order to fill test cases for an upcoming fork, ensure that the evm tool used supports that fork and features under test and use the --until or --fork flag.

+

For example, as of Q2 2023, the current fork under active development is Cancun:

+
uv run fill --until Cancun
+
+
+
+

See: Filling Tests for Features under Development.

+

Debugging the t8n Command

+

The --evm-dump-dir flag can be used to dump the inputs and outputs of every call made to the t8n command for debugging purposes, see Debugging Transition Tools.

+

Other Useful Pytest Command-Line Options

+
uv run fill -vv            # More verbose output
+uv run fill -x             # Exit instantly on first error or failed test case
+uv run fill --pdb -nauto   # Drop into the debugger upon error in a test case
+uv run fill -s             # Print stdout from tests to the console during execution
+

Custom fill Command-Line Options

+

To see all the options available to fill, including pytest and pytest plugin options, use --pytest-help.

+

To list the options that only specific to fill, use:

+
uv run fill --help
+

For a complete, up-to-date list of all command-line options, see the Fill Command-Line Options page, which is automatically generated from the current uv run fill --help output.

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/filling_tests_dev_fork/index.html b/docs/public/main/filling_tests_dev_fork/index.html new file mode 100644 index 00000000000..098bed75174 --- /dev/null +++ b/docs/public/main/filling_tests_dev_fork/index.html @@ -0,0 +1,1512 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

Filling Tests for Features under Development

+

Requirements

+

By default, execution-spec-tests only generates fixtures for forks that have been deployed to mainnet. In order to generate fixtures for evm features that are actively under development:

+
    +
  1. A version of the evm and solc tools that implement the feature must be available (although, typically only a developer version of the evm tool is required, usually the latest stable release of solc is adequate), and,
  2. +
  3. The development fork to test must be explicitly specified on the command-line:
  4. +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
+ + + + + + + +
+ +
+ +
+
uv run fill -k 4844 --fork=Cancun -v
+
+
+ +
+
uv run fill -k 4844 --from=Cancun -v
+
+
+ +
+
uv run fill -k 4844 --until=Cancun -v
+
+
+ +
+
+ + + + + + + + + +
+
Specifying the evm binary via evm-bin
+
+

It is possible to explicitly specify the evm binary used to generate fixtures via the --evm-bin flag, for example,

+
uv run fill --fork=Cancun --evm-bin=/opt/bin/evm -v
+
+
+
+

Further Help

+
    +
  1. geth/evm build documentation.
  2. +
  3. solc build documentation.
  4. +
+ + +
+
Verifying evm and solc versions used
+
+ The versions used to generate fixtures are displayed in the console output: +Screenshot of pytest test collection console output +
+
+

VS Code Setup

+

By default, VS Code’s Testing View will only show tests for stable forks. To show tests for development forks, uncomment the relevant line in the python.testing.pytestArgs configuration section of included settings file (.vscode/settings.json) to enable the --until=FORK flag. See VS Code Setup for help finding the settings files.

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/filling_tests_vs_code/index.html b/docs/public/main/filling_tests_vs_code/index.html new file mode 100644 index 00000000000..fe1e8f4779a --- /dev/null +++ b/docs/public/main/filling_tests_vs_code/index.html @@ -0,0 +1,1313 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

Filling Tests in VS Code

+

Prerequisite: VS Code Setup.

+

Exploring Test Cases

+

Implemented test cases can be explored in VS Code’s “Testing” View; click on the conical flask highlighted in the screenshot below.

+

VS Code Testing Tab

+ + +
+
Testing EVM Features Under Active Development
+
+ See the VS Code section in Filling Tests for Features under Development to explore tests targeting EVM features under development. +
+
+

Filling and Debugging Test Cases

+

VS Code Testing Tab

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/fork_methods/index.html b/docs/public/main/fork_methods/index.html new file mode 100644 index 00000000000..8fbe4ae2bb7 --- /dev/null +++ b/docs/public/main/fork_methods/index.html @@ -0,0 +1,1625 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

Using and Extending Fork Methods

+

This document describes the Fork class in the Ethereum execution spec tests framework, which provides a standardized way to define properties of Ethereum forks. Understanding how to use and extend these fork methods is essential for writing flexible tests that can automatically adapt to different forks.

+

Overview

+

The BaseFork class is an abstract base class that defines the interface for all Ethereum forks. Each implemented fork (like Frontier, Homestead, etc.) extends this class and implements its abstract methods to provide fork-specific behavior.

+

The fork system allows:

+
    +
  1. Defining fork-specific behaviors and parameters
  2. +
  3. Comparing forks chronologically (Paris < Shanghai)
  4. +
  5. Supporting automatic fork transitions
  6. +
  7. Writing tests that automatically adapt to different forks
  8. +
+

Using Fork Methods in Tests

+

Fork methods are powerful tools that allow your tests to adapt to different Ethereum forks automatically. Here are common patterns for using them:

+

1. Check Fork Support for Features

+
def test_some_feature(fork):
+    if fork.supports_blobs(block_number=0, timestamp=0):
+        # Test blob-related functionality
+        ...
+    else:
+        # Test alternative or skip
+        pytest.skip("Fork does not support blobs")
+

2. Get Fork-Specific Parameters

+
def test_transaction_gas(fork, state_test):
+    gas_cost = fork.gas_costs(block_number=0, timestamp=0).G_TRANSACTION
+    
+    # Create a transaction with the correct gas parameters for this fork
+    tx = Transaction(
+        gas_limit=gas_cost + 10000,
+        # ...
+    )
+    
+    state_test(
+        env=Environment(),
+        pre=pre,
+        tx=tx,
+        # ...
+    )
+

3. Determine Valid Transaction Types

+
def test_transaction_types(fork, state_test):
+    for tx_type in fork.tx_types(block_number=0, timestamp=0):
+        # Test each transaction type supported by this fork
+        # ...
+

4. Determine Valid Opcodes

+
def test_opcodes(fork, state_test):
+    # Create bytecode using only opcodes valid for this fork
+    valid_opcodes = fork.valid_opcodes()
+    
+    # Use these opcodes to create test bytecode
+    # ...
+

5. Test Fork Transitions

+
def test_fork_transition(transition_fork, blockchain_test):
+    # The transition_fork is a special fork type that changes behavior
+    # based on block number or timestamp
+    fork_before = transition_fork.fork_at(block_number=4, timestamp=0)
+    fork_after = transition_fork.fork_at(block_number=5, timestamp=0)
+    
+    # Test behavior before and after transition
+    # ...
+

Important Fork Methods

+

Header Information

+

These methods determine what fields are required in block headers for a given fork:

+
fork.header_base_fee_required(block_number=0, timestamp=0)  # Added in London
+fork.header_prev_randao_required(block_number=0, timestamp=0)  # Added in Paris
+fork.header_withdrawals_required(block_number=0, timestamp=0)  # Added in Shanghai
+fork.header_excess_blob_gas_required(block_number=0, timestamp=0)  # Added in Cancun
+fork.header_blob_gas_used_required(block_number=0, timestamp=0)  # Added in Cancun
+fork.header_beacon_root_required(block_number=0, timestamp=0)  # Added in Cancun
+fork.header_requests_required(block_number=0, timestamp=0)  # Added in Prague
+

Gas Parameters

+

Methods for determining gas costs and calculations:

+
fork.gas_costs(block_number=0, timestamp=0)  # Returns a GasCosts dataclass
+fork.memory_expansion_gas_calculator(block_number=0, timestamp=0)  # Returns a callable
+fork.transaction_intrinsic_cost_calculator(block_number=0, timestamp=0)  # Returns a callable
+

Transaction Types

+

Methods for determining valid transaction types:

+
fork.tx_types(block_number=0, timestamp=0)  # Returns list of supported transaction types
+fork.contract_creating_tx_types(block_number=0, timestamp=0)  # Returns list of tx types that can create contracts 
+fork.precompiles(block_number=0, timestamp=0)  # Returns list of precompile addresses
+fork.system_contracts(block_number=0, timestamp=0)  # Returns list of system contract addresses
+

EVM Features

+

Methods for determining EVM features and valid opcodes:

+
fork.evm_code_types(block_number=0, timestamp=0)  # Returns list of supported code types (e.g., Legacy, EOF)
+fork.valid_opcodes()  # Returns list of valid opcodes for this fork
+fork.call_opcodes(block_number=0, timestamp=0)  # Returns list of call opcodes with their code types
+fork.create_opcodes(block_number=0, timestamp=0)  # Returns list of create opcodes with their code types
+
+

Methods for blob transaction support:

+
fork.supports_blobs(block_number=0, timestamp=0)  # Returns whether blobs are supported
+fork.blob_gas_price_calculator(block_number=0, timestamp=0)  # Returns a callable
+fork.excess_blob_gas_calculator(block_number=0, timestamp=0)  # Returns a callable
+fork.min_base_fee_per_blob_gas(block_number=0, timestamp=0)  # Returns minimum base fee per blob gas
+fork.blob_gas_per_blob(block_number=0, timestamp=0)  # Returns blob gas per blob
+fork.target_blobs_per_block(block_number=0, timestamp=0)  # Returns target blobs per block
+fork.max_blobs_per_block(block_number=0, timestamp=0)  # Returns max blobs per block
+

Meta Information

+

Methods for fork identification and comparison:

+
fork.name()  # Returns the name of the fork
+fork.transition_tool_name(block_number=0, timestamp=0)  # Returns name for transition tools
+fork.is_deployed()  # Returns whether the fork is deployed to mainnet
+

Fork Transitions

+

The framework supports creating transition forks that change behavior at specific block numbers or timestamps:

+
@transition_fork(to_fork=Shanghai, at_timestamp=15_000)
+class ParisToShanghaiAtTime15k(Paris):
+    """Paris to Shanghai transition at Timestamp 15k."""
+    pass
+

With transition forks, you can test how behavior changes across fork boundaries:

+
# Behavior changes at block 5
+fork = BerlinToLondonAt5
+assert not fork.header_base_fee_required(block_number=4)  # Berlin doesn't require base fee
+assert fork.header_base_fee_required(block_number=5)      # London requires base fee
+

Adding New Fork Methods

+

When adding new fork methods, follow these guidelines:

+
    +
  1. Abstract Method Definition: Add the new abstract method to BaseFork in base_fork.py
  2. +
  3. Consistent Parameter Pattern: Use block_number and timestamp parameters with default values
  4. +
  5. Method Documentation: Add docstrings explaining the purpose and behavior
  6. +
  7. Implementation in Subsequent Forks: Implement the method in every subsequent fork class only if the fork updates the value from previous forks.
  8. +
+

Example of adding a new method:

+
@classmethod
+@abstractmethod
+def supports_new_feature(cls, block_number: int = 0, timestamp: int = 0) -> bool:
+    """Return whether the given fork supports the new feature."""
+    pass
+

Implementation in a fork class:

+
@classmethod
+def supports_new_feature(cls, block_number: int = 0, timestamp: int = 0) -> bool:
+    """Return whether the given fork supports the new feature."""
+    return False  # Frontier doesn't support this feature
+

Implementation in a newer fork class:

+
@classmethod
+def supports_new_feature(cls, block_number: int = 0, timestamp: int = 0) -> bool:
+    """Return whether the given fork supports the new feature."""
+    return True  # This fork does support the feature
+

When to Add a New Fork Method

+

Add a new fork method when:

+
    +
  1. A New EIP Introduces a Feature: Add methods describing the new feature’s behavior
  2. +
  3. Tests Need to Behave Differently: When tests need to adapt to different fork behaviors
  4. +
  5. Common Fork Information is Needed: When multiple tests need the same fork-specific information
  6. +
  7. Intrinsic Fork Properties Change: When gas costs, opcodes, or other intrinsic properties change
  8. +
+

Do not add a new fork method when:

+
    +
  1. The information is only needed for one specific test
  2. +
  3. The information is not directly related to fork behavior
  4. +
  5. The information can be calculated using existing methods
  6. +
+

Best Practices

+
    +
  1. Use Existing Methods: Check if there’s already a method that provides the information you need
  2. +
  3. Name Methods Clearly: Method names should clearly describe what they return
  4. +
  5. Document Behavior: Include clear docstrings explaining the method’s purpose and return value
  6. +
  7. Avoid Hard-coding: Use fork methods in tests instead of hard-coding fork-specific behavior
  8. +
  9. Test Transitions: Ensure your method works correctly with transition forks
  10. +
+

Example: Complete Test Using Fork Methods

+

Here’s an example of a test that fully utilizes fork methods to adapt its behavior:

+
def test_transaction_with_fork_adaptability(fork, state_test):
+    # Prepare pre-state
+    pre = Alloc()
+    sender = pre.fund_eoa()
+    
+    # Define transaction based on fork capabilities
+    tx_params = {
+        "gas_limit": 1_000_000,
+        "sender": sender,
+    }
+    
+    # Add appropriate transaction type based on fork
+    tx_types = fork.tx_types(block_number=0, timestamp=0)
+    if 3 in tx_types and fork.supports_blobs(block_number=0, timestamp=0):
+        # EIP-4844 blob transaction (type 3)
+        tx_params["blob_versioned_hashes"] = [Hash.generate_zero_hashes(1)[0]]
+    elif 2 in tx_types:
+        # EIP-1559 transaction (type 2)
+        tx_params["max_fee_per_gas"] = 10
+        tx_params["max_priority_fee_per_gas"] = 1
+    elif 1 in tx_types:
+        # EIP-2930 transaction (type 1)
+        tx_params["access_list"] = []
+        
+    # Create and run the test
+    tx = Transaction(**tx_params)
+    
+    state_test(
+        env=Environment(),
+        pre=pre,
+        tx=tx,
+        post={
+            sender: Account(nonce=1),
+        },
+    )
+

Conclusion

+

The Fork class is a powerful abstraction that allows tests to adapt to different Ethereum forks. By using fork methods consistently, you can write tests that automatically handle fork-specific behavior, making your tests more maintainable and future-proof.

+

When adding new fork methods, keep them focused, well-documented, and implement them across all forks. This will ensure that all tests can benefit from the information and that transitions between forks are handled correctly.

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/getting_help/index.html b/docs/public/main/getting_help/index.html new file mode 100644 index 00000000000..0071357c580 --- /dev/null +++ b/docs/public/main/getting_help/index.html @@ -0,0 +1,1296 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

Getting Help

+

The tests in this repository are a community effort to help improve the development cycle of all Ethereum execution clients.

+

We encourage contributions and recognize that Python is not everyone’s primary language - if you stumble over issues or need help, please reach out to one of the execution-spec-tests maintainers either directly or in the #el-testing channel in the Ethereum R&D Discord Server.

+

Contact the Maintainers

+

Write to:

+ +
+ ![ukiyo-e style design of 3 furry happy pandas playfully doing experiments on ethereum in a laboratory](img/testing_pandas.png){width="400"} +
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/getting_started/code_standards/index.html b/docs/public/main/getting_started/code_standards/index.html new file mode 100644 index 00000000000..a12437d614c --- /dev/null +++ b/docs/public/main/getting_started/code_standards/index.html @@ -0,0 +1,1525 @@ + + + + + + + Code Standards - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

Code Standards

+
+ +
+

This document outlines the coding standards and practices used in the ethereum/execution-spec-tests repository.

+

Code and CI Requirements

+

Code pushed to execution-spec-tests must fulfill the following checks in CI:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TypeExplanationTox Command
Lint & code formattinguvx --with=tox-uv tox -e lintPython lint, format and module import check via ruff
Typecheckuvx --with=tox-uv tox -e typecheckObjects that provide typehints pass type-checking via mypy
Framework unit testsuvx --with=tox-uv tox -e pytestAll framework unit tests must execute correctly
EL Client test casesuvx --with=tox-uv tox -e tests-deployedAll client test cases for deployed forks can be generated
Benchmark EL Test casesuvx --with=tox-uv tox -e tests-deployed-benchmarkAll client test cases specific to benchmarks for deployed forks can be generated
HTML doc builduvx --with=tox-uv tox -e hugoDocumentation generated without warnings
Spellcheckuvx --with=tox-uv tox -e spellcheckCode and documentation spell-check using codespell
Markdown lintuvx --with=tox-uv tox -e markdownlintMarkdown lint (requires additional dependency)
Changelog validationuvx --with=tox-uv tox -e changelogValidates changelog entries format and structure in docs/CHANGELOG.md
+ + + + +
+
Avoid CI surprises - Use pre-commit hooks!
+
+

We strongly encourage all contributors to install and use pre-commit hooks! This will run fast checks (lint, typecheck, spellcheck) automatically before each commit, helping you catch issues early and avoid frustrating CI failures after pushing your changes.

+

Install with one simple command:

+
uvx pre-commit install
+

This saves you time by catching formatting issues, type errors, and spelling mistakes before they reach CI.

+ +
+
+ + +
+
Running checks easily
+
+

Add an alias:

+
alias tox="uvx --with=tox-uv tox"
+

Run all checks in parallel:

+
uvx --with=tox-uv tox run-parallel
+

Run sequentially:

+
uvx --with=tox-uv tox
+

Run specific, faster checks:

+
uvx --with=tox-uv tox -e lint,typecheck
+
+
+
+ + +
+
Lint & code formatting: Using ruff and VS Code to help autoformat and fix module imports
+
+

On the command-line, solve fixable issues with:

+
uv run ruff check --fix
+

Use VS Code, see VS Code Setup, to autoformat code, automatically organize Python module imports and highlight typechecking and spelling issues.

+ +
+
+ + +
+
Typechecking
+
+ Adding the correct typehints can sometimes be tricky and there are exceptions that require manually disabling typechecking on a per-line basis. Please reach out to the maintainers if you need help, either directly or in a PR. +
+
+

Python Coding Preferences

+
    +
  • Line Length: 100 characters maximum.
  • +
  • Formatting: Enforced by ruff (similar to black).
  • +
  • Documentation: +
      +
    • All public functions and classes should have docstrings
    • +
    • Docstrings should have a good one-line summary which uses the imperative (“Return” not “Returns”).
    • +
    • Add a blank line after the summary for multi-line docstrings.
    • +
    • Single-line docstrings should have triple quotes on the same line.
    • +
    +
  • +
  • Imports: Use explicit imports (no from module import *).
  • +
  • Relative Imports: Use relative imports within the same package
  • +
  • Error Handling: Use explicit exception types and meaningful error messages.
  • +
  • Type Hints: All functions should include type annotations.
  • +
  • Variable Naming: +
      +
    • Use snake_case for variables, functions, and modules.
    • +
    • Use PascalCase for classes.
    • +
    • Use UPPER_CASE for constants.
    • +
    +
  • +
  • File Paths: Strongly prefer pathlib over os.path for file system operations.
  • +
+

Editor Setup

+

A correctly configured editor will automatically handle most formatting requirements. See VS Code Setup for recommended settings.

+

Detailed Information

+

See the Detailed Code Standards page for more information on:

+ +
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/getting_started/code_standards_details/index.html b/docs/public/main/getting_started/code_standards_details/index.html new file mode 100644 index 00000000000..b45779b5778 --- /dev/null +++ b/docs/public/main/getting_started/code_standards_details/index.html @@ -0,0 +1,1415 @@ + + + + + + + Detailed Code Standards - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

Detailed Code Standards

+
+ +
+

This page provides in-depth information about the code standards and verification processes in ethereum/execution-spec-tests.

+

Running Tox Environments

+

Execution Options

+

Run all tox environments in parallel:

+
uvx --with=tox-uv tox run-parallel
+

Run environments sequentially with verbose output:

+
uvx --with=tox-uv tox -v
+

List all available environments:

+
uvx --with=tox-uv tox -av
+

Specific Environment Commands

+

Run specific environments using the -e flag:

+
uvx --with=tox-uv tox -e lint,typecheck,spellcheck
+

For Test Case Changes (./tests/)

+
uvx --with=tox-uv tox -e lint,typecheck,spellcheck,tests-deployed
+

For Framework and Library Changes (./src/)

+
uvx --with=tox-uv tox -e lint,typecheck,spellcheck,pytest
+

For Documentation Changes (./docs/)

+
uvx --with=tox-uv tox -e spellcheck,markdownlint,mkdocs,changelog
+
+ +
+
Tox Virtual Environment
+
+ Checks performed by tox are sandboxed in their own virtual environments (created automatically in the .tox/ subdirectory). These can be used to debug errors encountered during tox execution. +
+
+

Additional Dependencies

+

Some checks require external (non-Python) packages:

+

For spellcheck

+

The spellcheck environment uses codespell, which is automatically installed via Python dependencies and checks for common spelling mistakes in code and documentation.

+

To fix spelling errors found by codespell:

+
uv run codespell *.md *.ini .github/ src/ tests/ docs/ --write-changes
+
+ +
+
VS Code Integration
+
+ The whitelist.txt file is still maintained for the VS Code cSpell extension, which provides real-time spell checking in the editor. +
+
+

For markdownlint

+
sudo apt install nodejs
+sudo npm install -g markdownlint-cli2@0.17.2  # the version used in ci
+

Or use a specific node version using nvm.

+

Pre-commit Hooks

+

Certain tox environments can be run automatically as git pre-commit hooks to ensure that your changes meet the project’s standards before committing.

+

Installation

+
uvx pre-commit install
+

For more information, see Pre-commit Hooks Documentation.

+

Formatting and Line Length

+

The Python code in execution-spec-tests is formatted with ruff with a line length of 100 characters.

+

Ignoring Bulk Change Commits

+

The maximum line length was changed from 80 to 100 in Q2 2023. To ignore this bulk change commit in git blame output, use the .git-blame-ignore-revs file:

+
git blame --ignore-revs-file .git-blame-ignore-revs docs/gen_test_case_reference.py
+

To use the revs file persistently with git blame:

+
git config blame.ignoreRevsFile .git-blame-ignore-revs
+

Building and Verifying Docs Locally

+

To quickly build and browse the HTML documentation get latest hugo binary, navigate into the docs folder and run:

+
hugo server
+

Verifying Fixture Changes

+

When writing a PR that modifies either the framework or test cases, verify that changes don’t cause issues with existing test cases.

+

All filled fixtures contain a hash field in the _info object, which is used to verify that the fixture hasn’t changed.

+

Using the Hasher Tool

+

The hasher command can be used to bulk-verify the hashes of fixtures in a directory.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FlagDescription
--files / -fPrints a combined hash per JSON fixture file
--tests / -tPrints the hash of every test vector in JSON fixture files
--root / -rPrints a combined hash for all JSON fixture files in a directory
+ + +

For a quick comparison between two fixture directories:

+
hasher --root fixtures/
+hasher --root fixtures_new/
+

To identify which files are different:

+
diff <(hasher --files fixtures/) <(hasher --files fixtures_new/)
+

For a granular comparison:

+
diff <(hasher --tests fixtures/) <(hasher --tests fixtures_new/)
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/getting_started/getting_help/index.html b/docs/public/main/getting_started/getting_help/index.html new file mode 100644 index 00000000000..062bc1ba9b2 --- /dev/null +++ b/docs/public/main/getting_started/getting_help/index.html @@ -0,0 +1,1288 @@ + + + + + + + Getting Help - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

Getting Help

+
+ +
+

The tests in this repository are a community effort to help improve the development cycle of all Ethereum execution clients.

+

We encourage contributions and recognize that Python is not everyone’s primary language - if you stumble over issues or need help, please reach out to one of the execution-spec-tests maintainers either directly or in the #el-testing channel in the Ethereum R&D Discord Server.

+

Contact the Maintainers

+

Write to:

+ +

ukiyo-e style design of 3 furry happy pandas playfully doing experiments on ethereum in a laboratory

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/getting_started/index.html b/docs/public/main/getting_started/index.html new file mode 100644 index 00000000000..b5510517f37 --- /dev/null +++ b/docs/public/main/getting_started/index.html @@ -0,0 +1,1343 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

Getting Started: Filling Tests

+

This guide describes how to get started with fill and commonly-used command-line options.

+
    +
  1. +

    Explore test cases via --collect-only and search for test cases that combine PUSH0 and DELEGATECALL in the EVM functionality introduced in the Shanghai hard fork:

    +
    uv run fill --collect-only -k "push0 and delegatecall" tests/shanghai/
    +

    The fill command is based on pytest. The above command uses the optional pytest arguments:

    +
      +
    • --collect-only only collect test cases; don’t execute them.
    • +
    • -k <expression> filter test cases by their test case ID based on the given expression.
    • +
    • tests/shanghai the directory containing the test cases (tells fill to only discover test cases in this directory; default: tests/).
    • +
    +

    Expected console output:

    +
    + ![Screenshot of pytest test collection console output](./img/pytest_collect_only.png){align=center} +
    +
  2. +
  3. +

    Fill state_test fixtures for these test cases:

    +
    uv run fill -k "push0 and delegatecall" tests/shanghai/ -m state_test -v
    +

    where:

    +
      +
    • -m state_test only fills test cases marked as a state_test (see all available markers via uv run fill --markers).
    • +
    • -v enables verbose output.
    • +
    +

    Expected console output:

    +
    + ![Screenshot of fill test collection console output](./img/pytest_run_example.png){align=center} +
    +
  4. +
  5. +

    Verify the generated fixtures:

    +

    a. Check the corresponding fixture file has been generated:

    +
    head fixtures/state_tests/shanghai/eip3855_push0/push0/push0_contract_during_call_contexts.json
    +

    b. Open the generated HTML test using the link provided at the bottom of the console output. This is written to the output directory at:

    +
    ./fixtures/.meta/report_fill.html
    +
  6. +
+

Next Steps

+
    +
  1. Learn useful command-line flags.
  2. +
  3. Execute tests for features under development via the --fork flag.
  4. +
  5. Optional: Configure VS Code to auto-format Python code and execute tests within VS Code.
  6. +
  7. Implement a new test case, see Writing Tests.
  8. +
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/getting_started/installation/index.html b/docs/public/main/getting_started/installation/index.html new file mode 100644 index 00000000000..90efc0babcd --- /dev/null +++ b/docs/public/main/getting_started/installation/index.html @@ -0,0 +1,1148 @@ + + + + + + + + Getting Started + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
+ + + + +
+
+

Getting Started

+
+ + +
+

Installation

+

Prerequisites

+

The tools provided by execution-spec-tests use uv (docs.astral.sh/uv) to manage their dependencies and virtual environment.

+

It’s typically recommended to use the latest version of uv, currently uv>=0.5.22 is required.

+

The latest version of uv can be installed via curl (recommended; can self-update via uv self update) or pip (requires Python, can’t self-update):

+ + + + + + + + + + + + + + + + + + + + + + + +
+
+ + + + + +
+ +
+ +
+
curl -LsSf https://astral.sh/uv/install.sh | sh
+
+
+ +
+
pip install uv
+
+
+ +
+
+ + + + + + + +

If installed via curl, uv will download Python for your target platform if one of the required versions (Python 3.11 or 3.12) is not available natively.

+

Installation Commands

+

Clone execution-spec-tests and install its dependencies. We recommend using Python 3.12, the following uses uv to download and configures 3.12 to be the Python version used in execution-spec-tests:

+ + + + + + + + + + + + + + + + + +
+
+ + + +
+ +
+ +
+
    git clone https://github.com/ethereum/execution-spec-tests
+    cd execution-spec-tests
+    uv python install 3.12
+    uv python pin 3.12
+    uv sync --all-extras
+
+
+ +
+
+ + + + + + + +

Static tests/maintainers only: To learn how to build the solc binary from source (optional) follow this guide.

+

Installation Troubleshooting

+

If you encounter issues during installation, see the Installation Troubleshooting guide.

+
+
+
+
+
+ +
+ + + + + + + diff --git a/docs/public/main/getting_started/installation_troubleshooting/index.html b/docs/public/main/getting_started/installation_troubleshooting/index.html new file mode 100644 index 00000000000..1e28472de21 --- /dev/null +++ b/docs/public/main/getting_started/installation_troubleshooting/index.html @@ -0,0 +1,1580 @@ + + + + + + + Installation Troubleshooting - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

Installation Troubleshooting

+
+ +
+

This page provides guidance on how to troubleshoot common issues that may arise when installing ethereum/execution-spec-tests.

+

Problem: Failed building wheel for coincurve

+ + +
+
Problem: Failed building wheel for coincurve
+
+

Installing EEST and its dependencies via uv sync --all-extras fails with:

+
Stored in directory: /tmp/...
+    Building wheel for coincurve (pyproject.toml) ... error
+    error: subprocess-exited-with-error
+    
+    Γ— Building wheel for coincurve (pyproject.toml) did not run successfully.
+    β”‚ exit code: 1
+    ╰─> [27 lines of output]
+        ...
+        571 | #include <secp256k1_extrakeys.h>
+            |          ^~~~~~~~~~~~~~~~~~~~~~~
+        compilation terminated.
+        error: command '/usr/bin/gcc' failed with exit code 1
+        [end of output]
+    
+    note: This error originates from a subprocess, and is likely not a problem with pip.
+    ERROR: Failed building wheel for coincurve
+
+
+
+ + +
+
Solution: Install the libsecp256k1 library
+
+

On Ubuntu, you can install this library with:

+
sudo apt update
+sudo apt-get install libsecp256k1-dev
+
+
+
+

Problem: solc Installation issues

+

Problem: CERTIFICATE_VERIFY_FAILED

+ + +
+
Problem: Failed to ... CERTIFICATE_VERIFY_FAILED
+
+

When running fill you might encounter the following error:

+
Exit: Failed to ...: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:992)>
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + +
+
+ + + + + +
+ +
+ +
+
+
Solution: Update your system’s CA certificates
+
+

On Ubuntu, run the following commands:

+
sudo apt-get update
+sudo apt-get install ca-certificates
+
+
+
+
+ +
+
+
Solution: Update your system’s CA certificates
+
+

On macOS, Python provides a built-in script to install the required certificates:

+
/Applications/Python\ 3.11/Install\ Certificates.command
+
+
+
+
+ +
+
+ + + + + + + + +

Problem: Exception: failed to compile yul source

+ + +
+
Problem: Running fill on static_tests fails with tests that contain yul source code on ARM platforms
+
+ To resolve the issue you must acquire the solc binary e.g. by building solidity from source. The guide below installs v0.8.28 but you might prefer to choose a different version. +
+
+ + +
+
Solution: Build solc from source
+
+

The following steps have been tested on Ubuntu 24.04.2 LTS ARM64:

+
git clone --branch v0.8.28 --depth 1 https://github.com/ethereum/solidity.git
+cd solidity && mkdir build && cd build
+sudo apt install build-essential libboost-all-dev z3
+cmake ..
+make
+mv $HOME/Documents/execution-spec-tests/.venv/bin/solc $HOME/Documents/execution-spec-tests/.venv/bin/solc-x86-64
+cp ./solc/solc $HOME/Documents/execution-spec-tests/.venv/bin/
+chmod +x $HOME/Documents/execution-spec-tests/.venv/bin/solc
+

Running uv run solc --version should now return the expected version.

+ +
+
+

Problem: ValueError: unsupported hash type ripemd160

+ + +
+
Problem: Running fill fails with tests that use the RIPEMD160 precompile (0x03)
+
+

When running fill, you encounter the following error:

+
ValueError: unsupported hash type ripemd160
+# or
+ValueError: [digital envelope routines] unsupported
+

This is due to the removal of certain cryptographic primitives in OpenSSL 3. These were re-introduced in OpenSSL v3.0.7.

+ +
+
+ + +
+
Solution: Modify OpenSSL configuration
+
+

On platforms where OpenSSL v3.0.7 is unavailable (e.g., Ubuntu 22.04), modify your OpenSSL configuration to enable RIPEMD160. Make the following changes in the OpenSSL config file:

+
[openssl_init]
+providers = provider_sect
+
+# List of providers to load
+[provider_sect]
+default = default_sect
+legacy = legacy_sect
+
+[default_sect]
+activate = 1
+
+[legacy_sect]
+activate = 1
+

This will enable the legacy cryptographic algorithms, including RIPEMD160. See ethereum/execution-specs#506 for more information.

+ +
+
+

Other Issues Not Listed?

+

If you’re facing an issue that’s not listed here, you can easily report it on GitHub for resolution.

+

Click here to report a documentation issue related to installation

+

Please include the following details in your report:

+
    +
  1. The command that triggered the issue.
  2. +
  3. Any relevant error messages or screenshots.
  4. +
  5. Relevant version information from the output of uv run eest info (if running consume from within eest).
  6. +
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/getting_started/main/index.html b/docs/public/main/getting_started/main/index.html new file mode 100644 index 00000000000..ced9b9ff74f --- /dev/null +++ b/docs/public/main/getting_started/main/index.html @@ -0,0 +1,1584 @@ + + + + + + + Installation - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

Installation

+
+ +
+

Installation

+

Prerequisites

+

The tools provided by execution-spec-tests use uv to manage their dependencies and virtual environment.

+

It’s typically recommended to use the latest version of uv, currently uv>=0.5.22 is required.

+

The latest version of uv can be installed via curl (recommended; can self-update via uv self update) or pip (requires Python, can’t self-update):

+ + + + + + + + + + + + + + + + + + + + + + + +
+
+ + + + + +
+ +
+ +
+
curl -LsSf https://astral.sh/uv/install.sh | sh
+
+
+ +
+
pip install uv
+
+
+ +
+
+ + + + + + + +

If installed via curl, uv will download Python for your target platform if one of the required versions (Python 3.11 or 3.12) is not available natively.

+

Installation Commands

+

Clone execution-spec-tests and install its dependencies. We recommend using Python 3.12, the following uses uv to download and configures 3.12 to be the Python version used in execution-spec-tests:

+ + + + + + + + + + + + + + + + + +
+
+ + + +
+ +
+ +
+
    git clone https://github.com/ethereum/execution-spec-tests
+    cd execution-spec-tests
+    uv python install 3.12
+    uv python pin 3.12
+    uv sync --all-extras
+
+
+ +
+
+ + + + + + + +

Static tests/maintainers only: To learn how to build the solc binary from source (optional) follow this guide.

+

Installation Troubleshooting

+

If you encounter issues during installation, see the Installation Troubleshooting guide.

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/getting_started/repository_overview/index.html b/docs/public/main/getting_started/repository_overview/index.html new file mode 100644 index 00000000000..c0df19fd0b6 --- /dev/null +++ b/docs/public/main/getting_started/repository_overview/index.html @@ -0,0 +1,1309 @@ + + + + + + + Repository Overview - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

Repository Overview

+
+ +
+

The most relevant folders and files in the repo are:

+
πŸ“ execution-test-specs/
+β”œβ”€β•΄πŸ“ tests/                     # test cases
+β”‚   β”œβ”€β”€ πŸ“ eips/
+β”‚   β”œβ”€β”€ πŸ“ vm/
+β”‚   └── πŸ“ ...
+β”œβ”€β•΄πŸ“ fixtures/                  # default fixture output dir
+β”‚   β”œβ”€β”€ πŸ“ blockchain_tests/
+β”‚   β”œβ”€β”€ πŸ“ blockchain_tests_engine/
+β”‚   β”œβ”€β”€ πŸ“ state_tests/
+β”‚   └── πŸ“ ...
+β”œβ”€β•΄πŸ“ src/                       # library & framework packages
+β”‚   β”œβ”€β”€ πŸ“ ethereum_test_fork/
+β”‚   β”œβ”€β”€ πŸ“ ethereum_test_tools/
+β”‚   └── πŸ“ ...
+β”œβ”€β•΄πŸ“ docs/                      # markdown documentation
+β”‚   β”œβ”€β”€ πŸ“ getting_started
+β”‚   β”œβ”€β”€ πŸ“ dev
+β”‚   └── πŸ“ ...
+β”œβ”€β•΄πŸ“ .vscode/                   # visual studio code config
+β”‚   β”œβ”€β”€ πŸ“„ settings.recommended.json # copy to settings.json
+β”‚   β”œβ”€β”€ πŸ“„ launch.recommended.json
+β”‚   └── πŸ“„ extensions.json
+└── πŸ“„ whitelist.txt             # spellcheck dictionary
+

tests/

+

Contains the implementation of the Ethereum consensus tests available in this repository.

+

src/

+

Contains various packages that help to define test cases and to interface with the evm t8n command. Additionally, it contains some packages that enable test case execution by customizing pytest which acts as the test framework.

+

docs/

+

Contains documentation configuration and source files.

+

.vscode/

+

See VS Code Setup.

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/getting_started/setup_vs_code/index.html b/docs/public/main/getting_started/setup_vs_code/index.html new file mode 100644 index 00000000000..1acaca30f2a --- /dev/null +++ b/docs/public/main/getting_started/setup_vs_code/index.html @@ -0,0 +1,1292 @@ + + + + + + + VS Code Setup - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

VS Code Setup

+
+ +
+

VS Code setup is optional, but does offer the following advantages:

+
    +
  • Auto-format your Python code to conform to the repository’s code standards (we use ruff).
  • +
  • Inline linting and auto-completion (thanks to Python type hints).
  • +
  • Spell-check your code and docs.
  • +
  • Graphical exploration of test cases and easy test execution/debug.
  • +
+

Installation

+

Please refer to the Visual Studio Code docs for help with installation.

+

VS Code Settings file

+

The ethereum/execution-spec-tests repo includes configuration files for VS Code in the .vscode/ sub-directory:

+
πŸ“ execution-test-specs/
+β””β”€β”€πŸ“ .vscode/
+    β”œβ”€β”€ πŸ“„ settings.json
+    β”œβ”€β”€ πŸ“„ extensions.json
+    └── πŸ“„ launch.recommended.json
+

By default, the repository settings are applied via .vscode/settings.json.

+

To enable the recommended launch configurations (that include some useful debugging configurations), copy the recommended launch configuration file to .vscode/launch.json:

+
cp .vscode/launch.recommended.json .vscode/launch.json
+

VS Code Extension Configuration

+

The extensions listed in .vscode/extensions.json are required for a smooth developer experience.

+
    +
  1. +

    Open the root folder of your local execution-spec-tests clone in VS Code, it will prompt you to install the repository’s required extensions (from .vscode/extensions.json - you will be required to trust the executions-spec-tests repository first). These extensions are used to format, lint, type check and run tests on the codebase. After all the required extensions are installed a VS Code reload will be required.

    +
  2. +
  3. +

    If previously installed, ensure that the following ms-python extensions are disabled for the execution-spec-tests workspace to ensure there are no conflicts with the ruff formatter. In the VS Code Extensions tab, search for the each of the extensions below, and if installed and enabled, open the “Disabled” menu and select “Disable (Workspace)”. This ensures that the extensions will be available with other workspaces that may need them.

    + +

    Disabling extensions for the current workspace

    +
  4. +
+

Configuration for Testing EVM Features Under Active Development

+

An additional step is required to enable fixture generations for features from forks that are under active development and have not been deployed to mainnet, see Filling Tests for Features under Development.

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/hive/index.html b/docs/public/main/hive/index.html new file mode 100644 index 00000000000..cf76b431355 --- /dev/null +++ b/docs/public/main/hive/index.html @@ -0,0 +1,1241 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

Executing Tests on a Hive Local Network

+

Tests can be executed on a local hive-controlled single-client network by running the execute hive command.

+

The eest/execute-blobs Simulator

+

The blob_transaction_test execute test spec sends blob transactions to a running client in order to verify its engine_getBlobsVX endpoint behavior. These tests can be run using:

+
./hive --client besu --client-file ./configs/osaka.yaml --sim ethereum/eest/execute-blobs
+

See Hive for help installing and configuring Hive.

+

Running execute tests with Hive in Dev Mode

+

This command requires hive to be running in --dev mode:

+
./hive --dev --client go-ethereum
+

This will start hive in dev mode with the single go-ethereum client available for launching tests.

+

Then the tests can be executed by setting the HIVE_SIMULATOR environment variable

+
export HIVE_SIMULATOR=http://127.0.0.1:3000
+

and running:

+
uv run execute hive --fork=Cancun
+

This will execute all available tests in the tests directory on the Cancun fork by connecting to the hive server running on http://127.0.0.1:3000 and launching a single client with the appropriate genesis file.

+

The genesis file is passed to the client with the appropriate configuration for the fork schedule, system contracts and pre-allocated seed account.

+

All tests will be executed in the same network, in the same client, and serially, but when the -n auto parameter is passed to the command, the tests can also be executed in parallel.

+

One important feature of the execute hive command is that, since there is no consensus client running in the network, the command drives the chain by the use of the Engine API to prompt the execution client to generate new blocks and include the transactions in them.

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/hiveview/index.html b/docs/public/main/hiveview/index.html new file mode 100644 index 00000000000..f73b005276f --- /dev/null +++ b/docs/public/main/hiveview/index.html @@ -0,0 +1,1273 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

Viewing Results

+

Build the result viewer hiveview:

+
go build ./cmd/hiveview
+

Start the server:

+
./hiveview --serve
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/index.html b/docs/public/main/index.html new file mode 100644 index 00000000000..6825a87c705 --- /dev/null +++ b/docs/public/main/index.html @@ -0,0 +1,1671 @@ + + + + + + + Mains - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ + + + + + +
+

Execution Spec Tests Logo

+

ethereum/execution-spec-tests is both a collection of test cases and a framework in Python to generate tests for Ethereum execution clients.

+

The framework collects and executes the test cases in order to generate test fixtures (JSON) which can be consumed by any execution client to verify their implementation of ethereum/execution-specs. The fixtures, which define state transition and block tests, are generated by the framework using one of the t8n command-line tools that are provided by most execution clients, see below for an overview of the supported t8n tools.

+

Test Fixture Generation with execution-spec-tests

+

The generated test fixtures can be used:

+
    +
  1. Directly by client teams’ test frameworks, and,
  2. +
  3. In the integration tests executed in the ethereum/hive framework.
  4. +
+

More information on how to use and download the released test fixtures can be found here.

+

Relationship to ethereum/tests

+

This collection of tests is relatively new (test case development started Q4, 2022) and mainly targets recent and upcoming Ethereum specification changes. It does not replace, but rather complements the existing tests in ethereum/tests.

+

Motivation

+

The motivation to implement test cases in ethereum/execution-spec-tests is:

+
    +
  1. To implement test cases as code and ensure that changes, due to spec changes, for example, can be easily made. Moreover, changes are easily understandable and available in version control.
  2. +
  3. To avoid the 2-step approach often used in ethereum/tests: +
      +
    • Code (often unavailable) -> Test case (YAML).
    • +
    • Test case (YAML) -> Fixtures (JSON).
    • +
    +
  4. +
+ + +
+
Contributing
+
+ Contributions via PR are welcome! +
+
+ + +
+
Reporting a Vulnerability
+
+

Care is required when adding PRs or issues for functionality that is live on Ethereum mainnet. Please report vulnerabilities and verify bounty eligibility via the bug bounty program.

+
    +
  • Please do not create a PR with a vulnerability visible.
  • +
  • Please do not file a public ticket mentioning the vulnerability.
  • +
+
+
+ +
+ + +
+
+ + \ No newline at end of file diff --git a/docs/public/main/index.xml b/docs/public/main/index.xml new file mode 100644 index 00000000000..b3637748dad --- /dev/null +++ b/docs/public/main/index.xml @@ -0,0 +1,509 @@ + + + + Mains on EEST Docs + http://localhost:1313/main/ + Recent content in Mains on EEST Docs + Hugo + en-us + Wed, 09 Jul 2025 12:42:33 +0000 + + + Adding a New Test + http://localhost:1313/main/writing_tests/adding_a_new_test/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/writing_tests/adding_a_new_test/ + <p>All test cases are located underneath the <code>tests</code> directory, which are then organized by fork. Each fork contains sub-directories containing test sub-categories.</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-text" data-lang="text"><span style="display:flex;"><span>πŸ“ execution-test-specs/ </span></span><span style="display:flex;"><span>β”œβ”€β•΄πŸ“ tests/ </span></span><span style="display:flex;"><span>| β”œβ”€β”€ πŸ“„ __init__.py </span></span><span style="display:flex;"><span>β”‚ β”œβ”€β”€ πŸ“ cancun/ </span></span><span style="display:flex;"><span>| | β”œβ”€β”€ πŸ“„ __init__.py </span></span><span style="display:flex;"><span>β”‚ | └── πŸ“ eip4844_blobs/ </span></span><span style="display:flex;"><span>| | β”œβ”€β”€ πŸ“„ __init__.py </span></span><span style="display:flex;"><span>| | β”œβ”€β”€ πŸ“„ test_blobhash_opcode.py </span></span><span style="display:flex;"><span>| | β”œβ”€β”€ πŸ“„ test_excess_blob_gas.py </span></span><span style="display:flex;"><span>| | └── πŸ“„ ... </span></span><span style="display:flex;"><span>| β”œβ”€β”€ πŸ“ shanghai </span></span><span style="display:flex;"><span>| | β”œβ”€β”€ πŸ“ eip3651_warm_coinbase </span></span><span style="display:flex;"><span>| | | β”œβ”€β”€ πŸ“„ __init__.py </span></span><span style="display:flex;"><span>| | | └── πŸ“„ test_warm_coinbase.py </span></span><span style="display:flex;"><span>| | β”œβ”€β”€ πŸ“ eip3855_push0 </span></span><span style="display:flex;"><span>| | | β”œβ”€β”€ πŸ“„ __init__.py </span></span><span style="display:flex;"><span>| | | └── πŸ“„ test_push0.py </span></span><span style="display:flex;"><span>| | β”œβ”€β”€ πŸ“... </span></span><span style="display:flex;"><span>| | ... </span></span><span style="display:flex;"><span>β”‚ └── πŸ“ ... </span></span></code></pre></div><p>Each category/sub-directory may have multiple Python test modules (<code>*.py</code>) which in turn may contain many test functions. The test functions themselves are always parametrized by fork (by the framework).</p> + + + Getting Started + http://localhost:1313/main/filling_tests/getting_started/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/filling_tests/getting_started/ + <h1 id="getting-started-filling-tests">Getting Started: Filling Tests</h1> <p>This guide describes how to get started with <code>fill</code> and commonly-used command-line options.</p> <ol> <li> <p>Explore test cases via <code>--collect-only</code> and search for test cases that combine <code>PUSH0</code> and <code>DELEGATECALL</code> in the EVM functionality introduced in the Shanghai hard fork:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-console" data-lang="console"><span style="display:flex;"><span>uv run fill --collect-only -k &#34;push0 and delegatecall&#34; tests/shanghai/ </span></span></code></pre></div><p>The <code>fill</code> command is based on <a href="https://docs.pytest.org/en/stable/" target="_blank" rel="noopener"><code>pytest</code></a>. The above command uses the <a href="https://docs.pytest.org/en/stable/how-to/usage.html" target="_blank" rel="noopener">optional pytest arguments</a>:</p> <ul> <li><code>--collect-only</code> only collect test cases; don&rsquo;t execute them.</li> <li><code>-k &lt;expression&gt;</code> filter test cases by their test case ID based on the given expression.</li> <li><code>tests/shanghai</code> the directory containing the test cases (tells <code>fill</code> to only discover test cases in this directory; default: <code>tests/</code>).</li> </ul> <p>Expected console output:</p> + + + Managing Configurations + http://localhost:1313/main/dev_docs/configurations/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/dev_docs/configurations/ + <p>Configurations are managed by the <code>config</code> package. It provides both environment and application configurations.</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-console" data-lang="console"><span style="display:flex;"><span>. </span></span><span style="display:flex;"><span>β”œβ”€β”€ src </span></span><span style="display:flex;"><span>β”‚ └── πŸ“ config [Application wide environment and configurations] </span></span><span style="display:flex;"><span>β”‚ β”œβ”€β”€ πŸ“„ __init__.py </span></span><span style="display:flex;"><span>β”‚ β”œβ”€β”€ πŸ“„ app.py [Configurations for application framework] </span></span><span style="display:flex;"><span>β”‚ β”œβ”€β”€ πŸ“„ docs.py [Configurations for documentation] </span></span><span style="display:flex;"><span>β”‚ └── πŸ“„ env.py [Exposes `env.yaml` to the application] </span></span><span style="display:flex;"><span>└── πŸ“„ env.yaml [Environment file (git ignored)] </span></span></code></pre></div><h2 id="environment-configurations">Environment Configurations</h2> <p>Application-wide <a href="https://www.12factor.net/config" target="_blank" rel="noopener">environment configuration</a>, which varies across staging, production, and development environments are read from <code>env.yaml</code> in the project root.</p> + + + Methods of Running Tests + http://localhost:1313/main/running_tests/running/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/running_tests/running/ + <p>EEST has two commands, <code>consume</code> and <code>execute</code>, that run test cases against EL clients:</p> <ol> <li><code>consume</code> runs JSON test fixtures against a client - the client is said to &ldquo;consume&rdquo; the test case fixture.</li> <li><code>execute</code> runs test cases from Python source against a client - the test case is &ldquo;executed&rdquo; against the client.</li> </ol> <h2 id="top-level-comparison">Top-Level Comparison</h2> <p>Both <code>consume</code> and <code>execute</code> provide sub-commands which correspond to different methods of testing EL clients using EEST test cases:</p> + + + EEST Fixture Releases + http://localhost:1313/main/running_tests/releases/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/running_tests/releases/ + <h2 id="formats-and-release-layout">Formats and Release Layout</h2> <p>@ethereum/execution-spec-tests releases contain JSON test fixtures in various formats. Note that transaction type tests are executed directly from Python source using the <a href="./execute/main.md"><code>execute</code></a> command.</p> <table> <thead> <tr> <th>Format</th> <th>Consumed by the client</th> <th>Location in <code>.tar.gz</code> release</th> </tr> </thead> <tbody> <tr> <td><a href="./test_formats/state_test.md">State Tests</a></td> <td>- directly via a <code>statetest</code>-like command<br/> (e.g., <a href="https://github.com/ethereum/go-ethereum/blob/4bb097b7ffc32256791e55ff16ca50ef83c4609b/cmd/evm/staterunner.go" target="_blank" rel="noopener">go-ethereum/cmd/evm/staterunner.go</a>)</td> <td><code>./fixtures/state_tests/</code></td> </tr> <tr> <td><a href="./test_formats/blockchain_test.md">Blockchain Tests</a></td> <td>- directly via a <code>blocktest</code>-like command<br/> (e.g., <a href="https://github.com/ethereum/go-ethereum/blob/4bb097b7ffc32256791e55ff16ca50ef83c4609b/cmd/evm/blockrunner.go" target="_blank" rel="noopener">go-ethereum/cmd/evm/blockrunner.go</a>)</br>- using the <a href="./running.md#rlp">RLPeest/consume-rlp Simulator</a> via block import</td> <td><code>./fixtures/blockchain_tests/</code></td> </tr> <tr> <td><a href="./test_formats/blockchain_test_engine.md">Blockchain Engine Tests</a></td> <td>- using the <a href="./running.md#engine">eest/consume-engine Simulator</a> and the Engine API</td> <td><code>./fixtures/blockchain_tests_engine/</code></td> </tr> <tr> <td><a href="./test_formats/transaction_test.md">Transaction Tests</a></td> <td>- using a new simulator coming soon</td> <td>None; executed directly from Python source,</br>using a release tag</td> </tr> <tr> <td>Blob Transaction Tests</td> <td>- using the <a href="./execute/hive.md#the-eestexecute-blobs-simulator">eest/execute-blobs Simulator</a> and</td> <td>None; executed directly from Python source,</br>using a release tag</td> </tr> </tbody> </table> <h2 id="release-urls-and-tarballs">Release URLs and Tarballs</h2> <h3 id="versioning-scheme">Versioning Scheme</h3> <p>EEST framework and test sources and fixture releases are tagged use a semantic versioning scheme, <code>&lt;optional:&lt;pre_release_name@&gt;&gt;v&lt;MAJOR&gt;.&lt;MINOR&gt;.&lt;PATCH&gt;</code> as following:</p> + + + Installation Troubleshooting + http://localhost:1313/main/getting_started/installation_troubleshooting/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/getting_started/installation_troubleshooting/ + <p>This page provides guidance on how to troubleshoot common issues that may arise when installing <a href="https://github.com/ethereum/execution-spec-tests" target="_blank" rel="noopener">ethereum/execution-spec-tests</a>.</p> <h2 id="problem-failed-building-wheel-for-coincurve">Problem: <code>Failed building wheel for coincurve</code></h2> <div class="callout callout-danger"> <div class="callout-title">Problem: <code>Failed building wheel for coincurve</code></div> <div class="callout-content"> <p>Installing EEST and its dependencies via <code>uv sync --all-extras</code> fails with:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-bash" data-lang="bash"><span style="display:flex;"><span>Stored in directory: /tmp/... </span></span><span style="display:flex;"><span> Building wheel <span style="color:#66d9ef">for</span> coincurve <span style="color:#f92672">(</span>pyproject.toml<span style="color:#f92672">)</span> ... error </span></span><span style="display:flex;"><span> error: subprocess-exited-with-error </span></span><span style="display:flex;"><span> </span></span><span style="display:flex;"><span> Γ— Building wheel <span style="color:#66d9ef">for</span> coincurve <span style="color:#f92672">(</span>pyproject.toml<span style="color:#f92672">)</span> did not run successfully. </span></span><span style="display:flex;"><span> β”‚ exit code: <span style="color:#ae81ff">1</span> </span></span><span style="display:flex;"><span> ╰─&gt; <span style="color:#f92672">[</span><span style="color:#ae81ff">27</span> lines of output<span style="color:#f92672">]</span> </span></span><span style="display:flex;"><span> ... </span></span><span style="display:flex;"><span> <span style="color:#ae81ff">571</span> | <span style="color:#75715e">#include &lt;secp256k1_extrakeys.h&gt;</span> </span></span><span style="display:flex;"><span> | ^~~~~~~~~~~~~~~~~~~~~~~ </span></span><span style="display:flex;"><span> compilation terminated. </span></span><span style="display:flex;"><span> error: command <span style="color:#e6db74">&#39;/usr/bin/gcc&#39;</span> failed with exit code <span style="color:#ae81ff">1</span> </span></span><span style="display:flex;"><span> <span style="color:#f92672">[</span>end of output<span style="color:#f92672">]</span> </span></span><span style="display:flex;"><span> </span></span><span style="display:flex;"><span> note: This error originates from a subprocess, and is likely not a problem with pip. </span></span><span style="display:flex;"><span> ERROR: Failed building wheel <span style="color:#66d9ef">for</span> coincurve </span></span></code></pre></div> </div> </div> <div class="callout callout-success"> <div class="callout-title">Solution: Install the <code>libsecp256k1</code> library</div> <div class="callout-content"> <p>On Ubuntu, you can install this library with:</p> + + + Interactive Library Usage + http://localhost:1313/main/dev_docs/interactive_usage/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/dev_docs/interactive_usage/ + <p>You can work with EEST Python packages interactively with <code>ipython</code> using:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-console" data-lang="console"><span style="display:flex;"><span>uvx --with-editable . ipython </span></span></code></pre></div><p>This command will create a virtual environment, install EEST&rsquo;s packages in &ldquo;<a href="https://setuptools.pypa.io/en/latest/userguide/development_mode.html" target="_blank" rel="noopener">editable mode</a>&rdquo; (source changes get reflected in the interactive shell), and start an <code>ipython</code> shell. You can then import any of the packages and experiment with them interactively.</p> <div class="callout callout-info"> <div class="callout-title">Example: Working with <code>ethereum_test_forks</code></div> <div class="callout-content"> <p>See which defined forks are &ldquo;ignored&rdquo; by default:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-python" data-lang="python"><span style="display:flex;"><span><span style="color:#f92672">from</span> ethereum_test_forks <span style="color:#f92672">import</span> forks, get_forks </span></span><span style="display:flex;"><span>forks <span style="color:#f92672">=</span> set([fork <span style="color:#66d9ef">for</span> fork <span style="color:#f92672">in</span> get_forks() <span style="color:#66d9ef">if</span> fork<span style="color:#f92672">.</span>ignore()]) </span></span><span style="display:flex;"><span>print(forks) </span></span><span style="display:flex;"><span><span style="color:#75715e"># -&gt; {MuirGlacier, ArrowGlacier, GrayGlacier}</span> </span></span></code></pre></div> </div> </div> <h2 id="required-ipython-configuration">Required <code>ipython</code> Configuration</h2> <p>To enable <a href="https://ipython.readthedocs.io/en/stable/config/extensions/autoreload.html" target="_blank" rel="noopener">autoreload</a> of changed modules in the current <code>ipython</code> session, type:</p> + + + Types of Test + http://localhost:1313/main/writing_tests/types_of_tests/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/writing_tests/types_of_tests/ + <p>There are currently three types of tests that can be produced by a test spec:</p> <ol> <li>State Tests</li> <li>Blockchain Tests</li> <li>Transaction Tests</li> </ol> <h2 id="state-tests">State Tests</h2> <h3 id="purpose">Purpose</h3> <p>Tests the effects of individual transactions (ideally a single one) that span a single block in a controlled environment.</p> <h3 id="use-cases">Use cases</h3> <ul> <li>Test a single opcode behavior.</li> <li>Verify opcode gas costs.</li> <li>Test interactions between multiple smart contracts.</li> <li>Test creation of smart contracts.</li> </ul> <div class="callout callout-info"> <div class="callout-title">Info</div> <div class="callout-content"> The fill function will automatically generate a <code>blockchain_test</code> fixture from <code>state_tests</code>, consisting of one block and one transaction. </div> </div> <h2 id="blockchain-tests">Blockchain Tests</h2> <h3 id="purpose-1">Purpose</h3> <p>Blockchain tests span multiple blocks which may or may not contain transactions and mainly focus on the block to block effects to the Ethereum state.</p> + + + Documentation + http://localhost:1313/main/dev_docs/docs/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/dev_docs/docs/ + <p>The <code>execution-spec-tests</code> documentation is generated via <a href="https://github.com/gohugoio/hugo" target="_blank" rel="noopener"><code>hugo</code></a> and hosted remotely on Github Pages at <a href="https://eest.ethereum.org/" target="_blank" rel="noopener">eest.ethereum.org</a>.</p> <h2 id="prerequisites">Prerequisites</h2> <p>Grab the latest <code>hugo</code> binary from the official release page or build it yourself. Then make the binary executable and add it to the PATH (or to a directory that has already been added to the PATH like e.g. <code>/usr/local/bin/</code>). We do not require any additional plugins or dependencies.</p> <h2 id="build-and-locally-host-the-documentation">Build and Locally Host the Documentation</h2> <p>Build the docs:</p> + + + Useful Pytest Options + http://localhost:1313/main/running_tests/useful_pytest_options/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/running_tests/useful_pytest_options/ + <p>The EEST commands to run tests are customizations to the pytest framework, which provides many helpful options for test selection, parallel execution, report output and debugging. This section provides the most relevant options, a full overview is available in the <a href="https://docs.pytest.org/en/8.3.x/" target="_blank" rel="noopener">pytest docs</a>.</p> <h2 id="fixture-inputs-consume-commands">Fixture Inputs (Consume Commands)</h2> <p>See <a href="./consume/cache.md">Consume Cache and Fixture Inputs</a>.</p> <h2 id="dry-run">Dry-Run</h2> <p>List collected tests, <code>-q</code> restricts output to <a href="../filling_tests/test_ids.md">test IDs</a> only:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-bash" data-lang="bash"><span style="display:flex;"><span>uv run consume engine --input<span style="color:#f92672">=</span>&lt;fixture_input&gt; --collect-only -q </span></span></code></pre></div><p>In <code>./hive</code> <a href="./hive/main.md">standalone mode</a>, this can be achieved via EEST&rsquo;s <a href="./hive/common_options.md#collect-onlydry-run"><code>--sim.limit</code> &ldquo;collectonly&rdquo; prefix</a>.</p> + + + Writing a New Test + http://localhost:1313/main/writing_tests/writing_a_new_test/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/writing_tests/writing_a_new_test/ + <h2 id="test-functions">Test Functions</h2> <p>Every test case is defined as a Python function that implements a single <code>StateTest</code> or <code>BlockchainTest</code> using the <code>state_test</code> or <code>blockchain_test</code> objects made available by the framework (<a href="http://localhost:1313/main/writing_tests/types_of_tests/#deciding-on-a-test-type">learn how to decide on a test type</a>). Test cases, and the respective test modules, must fulfill the following requirements:</p> <table class="styled-table"> <thead> <tr> <th>Requirement</th> <th>When</th> </tr> </thead> <tbody> <tr> <td>Be <a href="#specifying-which-forks-tests-are-valid-for">decorated with validity markers</a></td> <td>If the test case is not valid for all forks</td> </tr> <tr> <td>Use one of <code>state_test</code> or <code>blockchain_test</code> <a href="#the-state_test-and-blockchain_test-test-function-arguments">in its function arguments</a></td> <td>Always</td> </tr> <tr> <td>Call the <code>state_test</code> or <code>blockchain_test</code> in its test body</td> <td>Always</td> </tr> <tr> <td>Add a <a href="http://localhost:1313/main/writing_tests/reference_specification/" target="_blank" rel="noopener">reference version of the EIP spec</a> under test</td> <td>Test path contains <code>eip</code></td> </tr> </tbody> </table> <style> .styled-table { border-collapse: collapse; width: 100%; margin: 1.5rem 0; border: 1px solid #ddd; } .styled-table th, .styled-table td { border: 1px solid #ddd; padding: 0.75rem; text-align: left; } .styled-table th { background-color: #f5f5f5; font-weight: 600; } .styled-table tr:nth-child(even) { background-color: #f9f9f9; } .styled-table code { background-color: #f4f4f4; padding: 0.2rem 0.4rem; border-radius: 3px; font-size: 0.9em; } </style> <h3 id="specifying-which-forks-tests-are-valid-for">Specifying which Forks Tests are Valid For</h3> <p>Test cases can (and it most cases should) be decorated with one or more &ldquo;validity markers&rdquo; that define which the forks the test is valid for. This is achieved by applying:</p> + + + Documenting CLI Commands + http://localhost:1313/main/dev_docs/documenting_clis/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/dev_docs/documenting_clis/ + <p>EEST command line interfaces (CLIs) are documented using the <a href="https://click.palletsprojects.com" target="_blank" rel="noopener"><code>click</code></a> library&rsquo;s built-in help system and the <a href="https://github.com/mkdocs/mkdocs-click" target="_blank" rel="noopener"><code>mkdocs-click</code></a> extension for mkdocs. This allows generation of CLI documentation directly from the (click) source code, ensuring that the documentation is always up-to-date with the code.</p> <p>Current limitations:</p> <ol> <li><code>mkdocs serve</code> does not automatically update the CLI documentation when the source code changes. You must restart the server to see the changes.</li> <li><code>mkdocs-click</code> does not automatically generate a short help string from sub-command docstrings. You must provide a short help string for each sub-command in the source code with <code>@click.command(short_help=&quot;...&quot;)</code>.</li> </ol> <p>See the <a href="https://github.com/ethereum/execution-spec-tests/blob/main/docs/library/cli/evm_bytes.md" target="_blank" rel="noopener">markdown</a> and corresponding <a href="https://github.com/ethereum/execution-spec-tests/blob/main/src/cli/evm_bytes.py" target="_blank" rel="noopener">Python docstrings</a> for the <a href="../library/cli/evm_bytes.md"><code>evm_bytes</code> CLI documentation</a> as an example of how to document a CLI using <code>mkdocs-click</code>.</p> + + + Test Markers + http://localhost:1313/main/writing_tests/test_markers/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/writing_tests/test_markers/ + <p>Test markers are used to categorize tests and to run specific subsets of tests. They are defined in the test files using the <code>pytest.mark</code> decorator.</p> <p>The examples below use <code>StateTestFiller</code> tests, but the same markers can also be applied to <code>BlockchainTestFiller</code> tests.</p> <h2 id="fork-markers">Fork Markers</h2> <p>These markers are used to specify the forks for which a test is valid.</p> <h3 id="pytestmarkvalid_fromfork_name"><code>@pytest.mark.valid_from(&quot;FORK_NAME&quot;)</code></h3> <p>Bases: <code>ValidityMarker</code></p> <p>Marker used to specify the fork from which the test is valid. The test will not be filled for forks before the specified fork.</p> + + + Code Standards + http://localhost:1313/main/getting_started/code_standards/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/getting_started/code_standards/ + <p>This document outlines the coding standards and practices used in the <a href="https://github.com/ethereum/execution-spec-tests/" target="_blank" rel="noopener">ethereum/execution-spec-tests</a> repository.</p> <h2 id="code-and-ci-requirements">Code and CI Requirements</h2> <p>Code pushed to execution-spec-tests must fulfill the following checks in <a href="https://github.com/ethereum/execution-spec-tests/actions/workflows/tox_verify.yaml" target="_blank" rel="noopener">CI</a>:</p> <table class="styled-table"> <thead> <tr> <th>Type</th> <th>Explanation</th> <th>Tox Command</th> </tr> </thead> <tbody> <tr> <td>Lint &amp; code formatting</td> <td><code>uvx --with=tox-uv tox -e lint</code></td> <td>Python lint, format and module import check via <code>ruff</code></td> </tr> <tr> <td>Typecheck</td> <td><code>uvx --with=tox-uv tox -e typecheck</code></td> <td>Objects that provide typehints pass type-checking via <code>mypy</code></td> </tr> <tr> <td>Framework unit tests</td> <td><code>uvx --with=tox-uv tox -e pytest</code></td> <td>All framework unit tests must execute correctly</td> </tr> <tr> <td>EL Client test cases</td> <td><code>uvx --with=tox-uv tox -e tests-deployed</code></td> <td>All client test cases for deployed forks can be generated</td> </tr> <tr> <td>Benchmark EL Test cases</td> <td><code>uvx --with=tox-uv tox -e tests-deployed-benchmark</code></td> <td>All client test cases specific to benchmarks for deployed forks can be generated</td> </tr> <tr> <td>HTML doc build</td> <td><code>uvx --with=tox-uv tox -e hugo</code></td> <td>Documentation generated without warnings</td> </tr> <tr> <td>Spellcheck</td> <td><code>uvx --with=tox-uv tox -e spellcheck</code></td> <td>Code and documentation spell-check using codespell</td> </tr> <tr> <td>Markdown lint</td> <td><code>uvx --with=tox-uv tox -e markdownlint</code></td> <td>Markdown lint (requires <a href="http://localhost:1313/main/getting_started/code_standards_details/#additional-dependencies" target="_blank" rel="noopener">additional dependency</a>)</td> </tr> <tr> <td>Changelog validation</td> <td><code>uvx --with=tox-uv tox -e changelog</code></td> <td>Validates changelog entries format and structure in <code>docs/CHANGELOG.md</code></td> </tr> </tbody> </table> <style> .styled-table { border-collapse: collapse; width: 100%; margin: 1.5rem 0; border: 1px solid #ddd; } .styled-table th, .styled-table td { border: 1px solid #ddd; padding: 0.75rem; text-align: left; } .styled-table th { background-color: #f5f5f5; font-weight: 600; } .styled-table tr:nth-child(even) { background-color: #f9f9f9; } .styled-table code { background-color: #f4f4f4; padding: 0.2rem 0.4rem; border-radius: 3px; font-size: 0.9em; } </style> <div class="callout callout-warning"> <div class="callout-title">Avoid CI surprises - Use pre-commit hooks!</div> <div class="callout-content"> <p><strong>We strongly encourage all contributors to install and use pre-commit hooks!</strong> This will run fast checks (lint, typecheck, spellcheck) automatically before each commit, helping you catch issues early and avoid frustrating CI failures after pushing your changes.</p> + + + Coding Style + http://localhost:1313/main/dev_docs/coding_style/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/dev_docs/coding_style/ + <div class="callout callout-warning"> <div class="callout-title">Documentation Moved</div> <div class="callout-content"> This documentation has been relocated to <a href="../getting_started/code_standards.md">Getting Started -&gt; Code Standards</a>. Please use the new location for the most up-to-date information. </div> </div> + + + Verifying Changes + http://localhost:1313/main/writing_tests/verifying_changes/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/writing_tests/verifying_changes/ + <div class="callout callout-warning"> <div class="callout-title">Documentation Moved</div> <div class="callout-content"> This documentation has been relocated to <a href="../getting_started/code_standards_details.md">Detailed Code Standards</a>. Please use the new location for the most up-to-date information. </div> </div> + + + Code Standards + http://localhost:1313/main/writing_tests/code_standards/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/writing_tests/code_standards/ + <h1 id="code-standards"><a href="#code-standards">Code Standards</a></h1> <p>This documentation has been relocated.</p> + + + Detailed Code Standards + http://localhost:1313/main/getting_started/code_standards_details/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/getting_started/code_standards_details/ + <p>This page provides in-depth information about the code standards and verification processes in <a href="https://github.com/ethereum/execution-spec-tests/" target="_blank" rel="noopener">ethereum/execution-spec-tests</a>.</p> <h2 id="running-tox-environments">Running Tox Environments</h2> <h3 id="execution-options">Execution Options</h3> <p>Run all <code>tox</code> environments in parallel:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-console" data-lang="console"><span style="display:flex;"><span>uvx --with=tox-uv tox run-parallel </span></span></code></pre></div><p>Run environments sequentially with verbose output:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-console" data-lang="console"><span style="display:flex;"><span>uvx --with=tox-uv tox -v </span></span></code></pre></div><p>List all available environments:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-console" data-lang="console"><span style="display:flex;"><span>uvx --with=tox-uv tox -av </span></span></code></pre></div><h3 id="specific-environment-commands">Specific Environment Commands</h3> <p>Run specific environments using the <code>-e</code> flag:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-console" data-lang="console"><span style="display:flex;"><span>uvx --with=tox-uv tox -e lint,typecheck,spellcheck </span></span></code></pre></div><h4 id="for-test-case-changes-tests">For Test Case Changes (<code>./tests/</code>)</h4> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-console" data-lang="console"><span style="display:flex;"><span>uvx --with=tox-uv tox -e lint,typecheck,spellcheck,tests-deployed </span></span></code></pre></div><h4 id="for-framework-and-library-changes-src">For Framework and Library Changes (<code>./src/</code>)</h4> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-console" data-lang="console"><span style="display:flex;"><span>uvx --with=tox-uv tox -e lint,typecheck,spellcheck,pytest </span></span></code></pre></div><h4 id="for-documentation-changes-docs">For Documentation Changes (<code>./docs/</code>)</h4> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-console" data-lang="console"><span style="display:flex;"><span>uvx --with=tox-uv tox -e spellcheck,markdownlint,mkdocs,changelog </span></span></code></pre></div> <div class="callout callout-info"> <div class="callout-title">Tox Virtual Environment</div> <div class="callout-content"> Checks performed by <code>tox</code> are sandboxed in their own virtual environments (created automatically in the <code>.tox/</code> subdirectory). These can be used to debug errors encountered during <code>tox</code> execution. </div> </div> <h3 id="additional-dependencies">Additional Dependencies</h3> <p>Some checks require external (non-Python) packages:</p> + + + Logging + http://localhost:1313/main/dev_docs/logging/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/dev_docs/logging/ + <p>This document describes the logging system used in the Ethereum Execution Spec Tests project. Currently, logging is only supported for <code>consume</code> commands.</p> <h2 id="overview">Overview</h2> <p>The project uses Python&rsquo;s standard logging module with custom extensions to provide enhanced logging capabilities. Our logging system is implemented in the <code>src/pytest_plugins/logging.py</code> module and provides the following features:</p> <ul> <li>Custom log levels between the standard Python log levels</li> <li>Timestamps with millisecond precision in UTC</li> <li>Color-coded log output (when not running in Docker)</li> <li>File logging with a consistent naming pattern</li> <li>Integration with pytest&rsquo;s output capture</li> <li>Support for distributed test execution with pytest-xdist</li> </ul> <h2 id="custom-log-levels">Custom Log Levels</h2> <p>In addition to the standard Python log levels (DEBUG, INFO, WARNING, ERROR, CRITICAL), we&rsquo;ve added the following custom levels:</p> + + + Enabling Pre-Commit Checks + http://localhost:1313/main/dev_docs/precommit/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/dev_docs/precommit/ + <p>There&rsquo;s a <a href="https://pre-commit.com/" target="_blank" rel="noopener">pre-commit</a> config file available in the repository root (<code>.pre-commit-config.yaml</code>) that can be used to enable automatic checks upon commit - the commit will not go through if the checks don&rsquo;t pass.</p> <p>To enable pre-commit, the following must be run once:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-console" data-lang="console"><span style="display:flex;"><span>uvx pre-commit install </span></span></code></pre></div> <div class="callout callout-info"> <div class="callout-title">Bypassing pre-commit checks</div> <div class="callout-content"> <p>Enabling of pre-commit checks is not mandatory (it cannot be enforced) and even if it is enabled, it can always be bypassed with:</p> + + + Exception Tests + http://localhost:1313/main/writing_tests/exception_tests/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/writing_tests/exception_tests/ + <p>Exception tests are a special type of test which verify that an invalid transaction or an invalid block are correctly rejected with the expected error.</p> <h2 id="creating-an-exception-test">Creating an Exception Test</h2> <p>To test for an exception, the test can use either of the following types from <code>ethereum_test_exceptions</code> library:</p> <ol> <li> <p><a href="../library/ethereum_test_exceptions.md#ethereum_test_exceptions.TransactionException"><code>TransactionException</code></a>: To be added to the <code>error</code> field of the <code>Transaction</code> object, and to the <code>exception</code> field of the <code>Block</code> object that includes the transaction; this exception type is used when a transaction is invalid, and therefore when included in a block, the block is expected to be invalid too. This is different from valid transactions where an exception during EVM execution is expected (e.g. a revert, or out-of-gas), which can be included in valid blocks.</p> + + + VS Code Setup + http://localhost:1313/main/getting_started/setup_vs_code/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/getting_started/setup_vs_code/ + <p>VS Code setup is optional, but does offer the following advantages:</p> <ul> <li>Auto-format your Python code to conform to the repository&rsquo;s <a href="http://localhost:1313/main/writing_tests/code_standards/">code standards</a> (we use <a href="https://docs.astral.sh/ruff/" target="_blank" rel="noopener">ruff</a>).</li> <li>Inline linting and auto-completion (thanks to Python type hints).</li> <li>Spell-check your code and docs.</li> <li>Graphical exploration of test cases and easy test execution/debug.</li> </ul> <h2 id="installation">Installation</h2> <p>Please refer to the <a href="https://code.visualstudio.com/docs/setup/setup-overview" target="_blank" rel="noopener">Visual Studio Code docs</a> for help with installation.</p> <h2 id="vs-code-settings-file">VS Code Settings file</h2> <p>The <a href="https://github.com/ethereum/execution-spec-tests" target="_blank" rel="noopener">ethereum/execution-spec-tests</a> repo includes configuration files for VS Code in the <code>.vscode/</code> sub-directory:</p> + + + Repository Overview + http://localhost:1313/main/getting_started/repository_overview/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/getting_started/repository_overview/ + <p>The most relevant folders and files in the repo are:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-text" data-lang="text"><span style="display:flex;"><span>πŸ“ execution-test-specs/ </span></span><span style="display:flex;"><span>β”œβ”€β•΄πŸ“ tests/ # test cases </span></span><span style="display:flex;"><span>β”‚ β”œβ”€β”€ πŸ“ eips/ </span></span><span style="display:flex;"><span>β”‚ β”œβ”€β”€ πŸ“ vm/ </span></span><span style="display:flex;"><span>β”‚ └── πŸ“ ... </span></span><span style="display:flex;"><span>β”œβ”€β•΄πŸ“ fixtures/ # default fixture output dir </span></span><span style="display:flex;"><span>β”‚ β”œβ”€β”€ πŸ“ blockchain_tests/ </span></span><span style="display:flex;"><span>β”‚ β”œβ”€β”€ πŸ“ blockchain_tests_engine/ </span></span><span style="display:flex;"><span>β”‚ β”œβ”€β”€ πŸ“ state_tests/ </span></span><span style="display:flex;"><span>β”‚ └── πŸ“ ... </span></span><span style="display:flex;"><span>β”œβ”€β•΄πŸ“ src/ # library &amp; framework packages </span></span><span style="display:flex;"><span>β”‚ β”œβ”€β”€ πŸ“ ethereum_test_fork/ </span></span><span style="display:flex;"><span>β”‚ β”œβ”€β”€ πŸ“ ethereum_test_tools/ </span></span><span style="display:flex;"><span>β”‚ └── πŸ“ ... </span></span><span style="display:flex;"><span>β”œβ”€β•΄πŸ“ docs/ # markdown documentation </span></span><span style="display:flex;"><span>β”‚ β”œβ”€β”€ πŸ“ getting_started </span></span><span style="display:flex;"><span>β”‚ β”œβ”€β”€ πŸ“ dev </span></span><span style="display:flex;"><span>β”‚ └── πŸ“ ... </span></span><span style="display:flex;"><span>β”œβ”€β•΄πŸ“ .vscode/ # visual studio code config </span></span><span style="display:flex;"><span>β”‚ β”œβ”€β”€ πŸ“„ settings.recommended.json # copy to settings.json </span></span><span style="display:flex;"><span>β”‚ β”œβ”€β”€ πŸ“„ launch.recommended.json </span></span><span style="display:flex;"><span>β”‚ └── πŸ“„ extensions.json </span></span><span style="display:flex;"><span>└── πŸ“„ whitelist.txt # spellcheck dictionary </span></span></code></pre></div><h4 id="tests"><code>tests/</code></h4> <p>Contains the implementation of the Ethereum consensus tests available in this repository.</p> + + + Running Github Actions Locally + http://localhost:1313/main/dev_docs/test_actions_locally/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/dev_docs/test_actions_locally/ + <p>The Github Actions workflows can be tested locally using <a href="https://github.com/nektos/act" target="_blank" rel="noopener">nektos/act</a> without pushing changes to the remote. The local repository state will be used in the executed workflow.</p> <h2 id="prerequisites">Prerequisites</h2> <ol> <li> <p>A docker installation without <code>sudo</code> prefix requirement (<a href="https://docs.docker.com/engine/install/linux-postinstall/#manage-docker-as-a-non-root-user" target="_blank" rel="noopener">see also dockerdocs</a>):</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-bash" data-lang="bash"><span style="display:flex;"><span>sudo usermod -aG docker $USER </span></span></code></pre></div></li> <li> <p>Install the Github CLI (<code>gh</code>): <a href="https://github.com/cli/cli/blob/trunk/docs/install_linux.md" target="_blank" rel="noopener">linux</a>, <a href="https://github.com/cli/cli/tree/trunk?tab=readme-ov-file#macos" target="_blank" rel="noopener">macos</a>.</p> </li> <li> <p>Authenticate your Github account with the Github CLI:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-bash" data-lang="bash"><span style="display:flex;"><span>gh auth login </span></span></code></pre></div><p>This is required to set <code>GITHUB_TOKEN</code> to the output of <code>gh auth token</code> when running the workflows.</p> + + + Using and Extending Fork Methods + http://localhost:1313/main/writing_tests/fork_methods/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/writing_tests/fork_methods/ + <p>This document describes the Fork class in the Ethereum execution spec tests framework, which provides a standardized way to define properties of Ethereum forks. Understanding how to use and extend these fork methods is essential for writing flexible tests that can automatically adapt to different forks.</p> <h2 id="overview">Overview</h2> <p>The <code>BaseFork</code> class is an abstract base class that defines the interface for all Ethereum forks. Each implemented fork (like Frontier, Homestead, etc.) extends this class and implements its abstract methods to provide fork-specific behavior.</p> + + + Dependency Management and Packaging + http://localhost:1313/main/dev_docs/deps_and_packaging/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/dev_docs/deps_and_packaging/ + <p>EEST uses <a href="https://docs.astral.sh/uv/" target="_blank" rel="noopener"><code>uv</code></a> to manage and pin its dependencies.</p> <p>Please use <code>uv&gt;=0.7.0</code> to ensure <code>uv</code> writes <code>uv.lock</code> files with consistent fields and formatting (see <a href="https://github.com/ethereum/execution-spec-tests/pull/1597" target="_blank" rel="noopener">ethereum/execution-spec-tests#1597</a>).</p> <h2 id="managing-dependencies">Managing Dependencies</h2> <p>We aim to provide specific <a href="https://peps.python.org/pep-0440/#version-specifiers" target="_blank" rel="noopener">version specifiers</a> for each of our direct and extra dependencies.</p> <div class="callout callout-info"> <div class="callout-title">Packages should be managed via <code>uv</code></div> <div class="callout-content"> <p>Dependencies should be managed using <code>uv</code> on the command-line to ensure that version compatibility is ensured across all dependencies and that <code>uv.lock</code> is updated as required.</p> + + + Getting Help + http://localhost:1313/main/getting_started/getting_help/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/getting_started/getting_help/ + <p>The tests in this repository are a community effort to help improve the development cycle of all Ethereum execution clients.</p> <p>We encourage contributions and recognize that Python is not everyone&rsquo;s primary language - if you stumble over issues or need help, please reach out to one of the execution-spec-tests maintainers either directly or in the <code>#el-testing</code> channel in the <a href="https://discord.com/invite/qGpsxSA" target="_blank" rel="noopener">Ethereum R&amp;D Discord Server</a>.</p> <h2 id="contact-the-maintainers">Contact the Maintainers</h2> <p>Write to:</p> <ul> <li>Dan on <a href="https://discordapp.com/users/danceratopz" target="_blank" rel="noopener">Discord</a> or <a href="https://t.me/danceratopz" target="_blank" rel="noopener">Telegram</a>.</li> <li>Spencer on <a href="https://discordapp.com/users/spencertaylorbrown" target="_blank" rel="noopener">Discord</a> or <a href="https://t.me/spencertb" target="_blank" rel="noopener">Telegram</a>.</li> <li>Mario on <a href="https://discordapp.com/users/marioevz" target="_blank" rel="noopener">Discord</a> or <a href="https://t.me/marioevz" target="_blank" rel="noopener">Telegram</a>.</li> <li>Felix on <a href="https://discordapp.com/users/felix314159_" target="_blank" rel="noopener">Discord</a> or <a href="https://t.me/felix_eest" target="_blank" rel="noopener">Telegram</a>.</li> </ul> <p><img src="http://localhost:1313/images/getting_started/testing_pandas.png" alt="ukiyo-e style design of 3 furry happy pandas playfully doing experiments on ethereum in a laboratory"></p> + + + Referencing an EIP Spec Version + http://localhost:1313/main/writing_tests/reference_specification/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/writing_tests/reference_specification/ + <p>Tests that implement features from an Ethereum Improvement Proposal (<a href="https://github.com/ethereum/EIPs/tree/master/EIPS" target="_blank" rel="noopener">ethereum/EIPs</a>) must define the EIP&rsquo;s markdown SHA digest within the test&rsquo;s Python module. This ensures our tests stay up-to-date with any changes to the EIP specifications.</p> <p>The <code>check_eip_versions</code> command-line utility automatically verifies that all EIP references in the codebase are current. It works by comparing the SHA specified in the test against the latest version in the ethereum/EIPs repository. This utility uses pytest to generate test cases for every module that includes &ldquo;eip&rdquo; in its path.</p> + + + EIP Checklist Generation + http://localhost:1313/main/writing_tests/eip_checklist/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/writing_tests/eip_checklist/ + <p>The EIP checklist feature helps track test coverage for EIP implementations by automatically generating filled checklists based on test markers.</p> <h2 id="overview">Overview</h2> <p>When implementing tests for an EIP, you can mark specific tests as covering checklist items from the <a href="../writing_tests/checklist_templates/eip_testing_checklist_template.md">EIP testing checklist template</a>. The framework will then generate a filled checklist showing which items have been implemented.</p> <h2 id="marking-tests-as-implementing-eip-checklist-items">Marking Tests as implementing EIP Checklist Items</h2> <p>To mark a test as implementing a specific checklist item, use the structured <code>EIPChecklist</code> class:</p> + + + Post-Mortems + http://localhost:1313/main/writing_tests/post_mortems/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/writing_tests/post_mortems/ + <p>This page contains a collection of post-mortem analyses for test cases that were not initially identified by the testing process.</p> <p>The objective is to document and learn from missed scenarios β€” including those that were caught on the client side due to consensus issue, client developer raised issues, external reviewers, or external bug bounties β€” in order to improve test coverage and reduce the likelihood of similar omissions in the future.</p> + + + Porting Legacy Tests + http://localhost:1313/main/writing_tests/porting_legacy_tests/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/writing_tests/porting_legacy_tests/ + <h2 id="background">Background</h2> <p>EEST is the successor to <a href="https://github.com/ethereum/tests" target="_blank" rel="noopener">ethereum/tests</a> (aka &ldquo;original tests&rdquo;), a repository that defined EVM test cases from the <a href="https://ethereum.org/en/history/#frontier" target="_blank" rel="noopener">Frontier</a> phase up to and including <a href="https://ethereum.org/en/history/#paris" target="_blank" rel="noopener">The Merge</a>. These test cases are specified as YAML (and occasionally JSON) files in the <a href="https://github.com/ethereum/tests/tree/develop/src" target="_blank" rel="noopener"><code>./src/</code></a> sub-directory. JSON test fixtures, which are fully-populated tests that can be executed against clients, are generated using <a href="https://github.com/ethereum/retesteth" target="_blank" rel="noopener">ethereum/retesteth</a>. These JSON artifacts are regenerated when needed and added to the repository, typically in the <a href="https://github.com/ethereum/execution-spec-tests/tree/main/tests/static/state_tests" target="_blank" rel="noopener"><code>tests/static/state_tests</code></a> sub-directory.</p> + + + Changelog + http://localhost:1313/main/changelog/ + Wed, 09 Jul 2025 12:42:33 +0000 + http://localhost:1313/main/changelog/ + <p>Test fixtures for use by clients are available for each release on the <a href="https://github.com/ethereum/execution-spec-tests/releases" target="_blank" rel="noopener">Github releases page</a>.</p> <p><strong>Key:</strong> ✨ = New, 🐞 = Fixed, πŸ”€ = Changed. πŸ’₯ = Breaking</p> <h2 id="-unreleased">πŸ”œ [Unreleased]</h2> <h3 id="-breaking-changes">πŸ’₯ Breaking Changes</h3> <ul> <li>Python 3.10 support was removed in this release (<a href="https://github.com/ethereum/execution-spec-tests/pull/1808" target="_blank" rel="noopener">#1808</a>).</li> </ul> <h4 id="-important-change-for-test-contributors">πŸ’₯ Important Change for test contributors</h4> <ul> <li>EEST no longer allows usage of Yul code in Python tests. From now on, please make use of our opcode wrapper. Yul code is now only allowed in the &ldquo;static tests&rdquo; located in <code>./tests/static/</code> (these are test cases defined by JSON and YAML files instead of Python test functions that were originally maintained in <a href="https://github.com/ethereum/tests" target="_blank" rel="noopener">ethereum/tests</a>).</li> <li>In order to fill the static tests (which is not the case by default), please ensure that <code>solc</code> is located in your <code>PATH</code>.</li> </ul> <h4 id="-important-change-for-fill-users">πŸ’₯ Important Change for <code>fill</code> Users</h4> <p>The output behavior of <code>fill</code> has changed (<a href="https://github.com/ethereum/execution-spec-tests/pull/1608" target="_blank" rel="noopener">#1608</a>):</p> + + + Checklist Templates + http://localhost:1313/main/writing_tests/checklist_templates/main/ + Wed, 09 Jul 2025 12:42:33 +0000 + http://localhost:1313/main/writing_tests/checklist_templates/main/ + <h1 id="testing-checklist-templates">Testing Checklist Templates</h1> <p>This page includes checklist templates that must be followed to guarantee a minimum base testing coverage of new EIP feature.</p> + + + Consume + http://localhost:1313/main/running_tests/consume/main/ + Wed, 09 Jul 2025 12:42:33 +0000 + http://localhost:1313/main/running_tests/consume/main/ + <h1 id="the-consume-command">The <code>consume</code> Command</h1> <p>The EEST <code>consume</code> command implements different methods to run EEST-generated test fixtures against clients:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-bash" data-lang="bash"><span style="display:flex;"><span>uv run consume <span style="color:#f92672">[</span>OPTIONS<span style="color:#f92672">]</span> SUBCOMMAND <span style="color:#f92672">[</span>ARGS<span style="color:#f92672">]</span>... </span></span></code></pre></div><p>For help with installation, see <a href="../../getting_started/main.md">Installation</a>.</p> <p>This section provides help for running the EEST commands directly (as opposed to running as a <code>./hive</code> <a href="../hive/main.md">standalone command</a>, where applicable) see:</p> <ol> <li> <p><a href="./cache.md">Consume Cache &amp; Fixture Inputs</a> for how to specify <code>consume</code> fixture input.</p> </li> <li> <p><a href="./direct.md">Consume Direct</a> to run test fixtures against direct client interfaces.</p> </li> <li> <p><a href="./simulators.md">Consume Simulators</a> for help with Hive Simulators.</p> + + + Developer Documentation + http://localhost:1313/main/dev_docs/main/ + Wed, 09 Jul 2025 12:42:33 +0000 + http://localhost:1313/main/dev_docs/main/ + <p>This documentation is aimed at <code>execution-spec-tests</code> developers:</p> <ul> <li><a href="./configurations.md">Managing configurations</a>: Instructions for setting up and modifying test configurations.</li> <li><a href="./interactive_usage.md">Interactive usage</a>: Guide on interactive use of EEST packages using <code>ipython</code>.</li> <li><a href="./documenting_clis.md">Documenting CLI commands</a>: Instructions for documenting command line interfaces (CLIs).</li> <li><a href="./coding_style.md">Coding style</a>: Standards and best practices for code formatting and to maintain consistency across the repository.</li> <li><a href="./logging.md">Logging</a>: Documentation on using the custom logging system with enhanced features.</li> <li><a href="./precommit.md">Enabling pre-commit checks</a>: A guide for setting up pre-commit hooks to enforce code quality before commits.</li> <li><a href="./test_actions_locally.md">Running github actions locally</a>: Instructions for testing GitHub Actions workflows on your local machine to streamline development and debugging.</li> </ul> <p>These sections are primarily aimed at <code>execution-spec-tests</code> maintainers:</p> + + + Execute + http://localhost:1313/main/running_tests/execute/main/ + Wed, 09 Jul 2025 12:42:33 +0000 + http://localhost:1313/main/running_tests/execute/main/ + <h1 id="executing-tests-on-local-networks-or-hive">Executing Tests on Local Networks or Hive</h1> <p>@ethereum/execution-spec-tests is capable of running tests on local networks or on Hive with a few considerations. The <code>execute</code> command runs test cases directly from the Python source (without the use of JSON fixtures).</p> <p>See:</p> <ul> <li><a href="./hive.md">Execute Hive</a> for help with the <code>execute</code> simulator in order to run tests on a single-client local network.</li> <li><a href="./remote.md">Execute Remote</a> for help with executing tests on a remote network such as a devnet, or even mainnet.</li> </ul> <p>The rest of this page describes how <code>execute</code> works and explains its architecture.</p> + + + Execution Spec Tests + http://localhost:1313/main/main/ + Wed, 09 Jul 2025 12:42:33 +0000 + http://localhost:1313/main/main/ + <p><img src="http://localhost:1313/images/main/execution_spec_tests.jpg" alt="Execution Spec Tests Logo"></p> <p><a href="https://github.com/ethereum/execution-spec-tests/" target="_blank" rel="noopener">ethereum/execution-spec-tests</a> is both a collection of test cases and a framework in Python to generate tests for Ethereum execution clients.</p> <p>The framework collects and executes the test cases in order to generate <em>test fixtures</em> (JSON) which can be consumed by any execution client to verify their implementation of <a href="https://github.com/ethereum/execution-specs" target="_blank" rel="noopener">ethereum/execution-specs</a>. The fixtures, which define state transition and block tests, are generated by the framework using one of the <code>t8n</code> command-line tools that are provided by most execution clients, see below for an overview of the supported <code>t8n</code> tools.</p> + + + Filling Tests + http://localhost:1313/main/filling_tests/main/ + Wed, 09 Jul 2025 12:42:33 +0000 + http://localhost:1313/main/filling_tests/main/ + <p>Execution of test cases against clients is a two-step process:</p> <ol> <li>JSON test fixtures are generated from the Python test cases found in <code>./tests</code> using <code>fill</code> and an EVM transition tool (<code>t8n</code>) implementation.</li> <li>Clients &ldquo;consume&rdquo; the JSON fixtures via either a dedicated, client-specific interface or a testing environment such as Hive.</li> </ol> <p>The process of generating fixtures is often referred to as &ldquo;filling&rdquo; the tests.</p> <div class="callout callout-info"> <div class="callout-title">The <code>execute</code> command</div> <div class="callout-content"> The <code>execute</code> command directly executes Python test cases against a client via its RPC without using generated JSON fixtures. For all other methods of testing clients, the JSON fixtures are required. For more information, see <a href="../running_tests/execute/main.md">Executing Tests</a>. </div> </div> <h2 id="transition-tools-t8n">Transition Tools (<code>t8n</code>)</h2> <p>The <code>fill</code> command requires an EVM <code>t8n</code> tool provided by most clients in order to generate the JSON fixtures. The <code>t8n</code> tool is mainly responsible for calculating the post-state of the EVM after executing a transaction, most relevantly, it calculates the updated state root.</p> + + + Hive + http://localhost:1313/main/running_tests/hive/main/ + Wed, 09 Jul 2025 12:42:33 +0000 + http://localhost:1313/main/running_tests/hive/main/ + <h1 id="hive">Hive</h1> <p>@ethereum/hive is a containerized testing framework that helps orchestrate test execution against Ethereum clients. Hive is incredibly extensible; new test suites can be implemented in a module manner as &ldquo;simulators&rdquo; that interact with clients to test certain aspects of their behavior. EEST implements several simulators, see <a href="../running.md">Running Tests</a> for an overview.</p> <h2 id="quick-start">Quick Start</h2> <h3 id="prerequisites">Prerequisites</h3> <ol> <li>Docker: <a href="https://docs.docker.com/get-docker/" target="_blank" rel="noopener">https://docs.docker.com/get-docker/</a>.</li> <li>Golang 1.22+: <a href="https://go.dev/doc/install" target="_blank" rel="noopener">https://go.dev/doc/install</a>.</li> </ol> <h3 id="installation">Installation</h3> <p>Clone @ethereum/hive and build the <code>./hive</code> command:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-bash" data-lang="bash"><span style="display:flex;"><span>git clone https://github.com/ethereum/hive </span></span><span style="display:flex;"><span>cd hive </span></span><span style="display:flex;"><span>go build . </span></span></code></pre></div> + + + Installation + http://localhost:1313/main/getting_started/main/ + Wed, 09 Jul 2025 12:42:33 +0000 + http://localhost:1313/main/getting_started/main/ + <h1 id="installation">Installation</h1> <h2 id="prerequisites">Prerequisites</h2> <p>The tools provided by <a href="https://github.com/ethereum/execution-spec-tests" target="_blank" rel="noopener">execution-spec-tests</a> use <a href="https://docs.astral.sh/uv/" target="_blank" rel="noopener"><code>uv</code></a> to manage their dependencies and virtual environment.<br><br></p> <p>It&rsquo;s typically recommended to use the latest version of <code>uv</code>, currently <code>uv&gt;=0.5.22</code> is required.<br><br></p> <p>The latest version of <code>uv</code> can be installed via <code>curl</code> (recommended; can self-update via <code>uv self update</code>) or pip (requires Python, can&rsquo;t self-update):</p> <div class="tab-container" data-tab-group="tabs-0"> <div class="tab-header"> <button class="tab-button active" onclick="switchTab('tabs-0', 0 )"> curl </button> <button class="tab-button " onclick="switchTab('tabs-0', 1 )"> pip </button> </div> <div class="tab-panels"> <div class="tab-panel active"> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-console" data-lang="console"><span style="display:flex;"><span>curl -LsSf https://astral.sh/uv/install.sh | sh </span></span></code></pre></div> </div> <div class="tab-panel "> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-console" data-lang="console"><span style="display:flex;"><span>pip install uv </span></span></code></pre></div> </div> </div> </div> <style> .tab-container { margin: 1.5rem 0; background: #f8f9fa; border-radius: 8px; overflow: hidden; box-shadow: 0 1px 3px rgba(0,0,0,0.1); } .tab-header { display: flex; background: #e9ecef; } .tab-button { flex: 1; padding: 0.75rem 1rem; border: none; background: transparent; cursor: pointer; font-size: 14px; white-space: nowrap; transition: all 0.2s; position: relative; text-align: center; overflow: hidden; text-overflow: ellipsis; } .tab-button:hover { background: rgba(0,0,0,0.05); } .tab-button.active { background: #f8f9fa; font-weight: 600; color: #007bff; } .tab-button.active::after { content: ''; position: absolute; bottom: 0; left: 0; right: 0; height: 3px; background: #007bff; } .tab-button code { background: rgba(0,0,0,0.1); padding: 2px 4px; border-radius: 3px; font-size: 12px; } .tab-panel { display: none; padding: 1.5rem; background: white; } .tab-panel.active { display: block; } .tab-panel pre { margin: 0; background: #f6f8fa; border: 1px solid #e1e4e8; } @media (max-width: 768px) { .tab-header { flex-wrap: wrap; } .tab-button { flex: 1 1 50%; padding: 0.5rem 0.75rem; font-size: 13px; } @media (max-width: 480px) { .tab-button { flex: 1 1 100%; } } } </style> <script> function switchTab(groupId, tabIndex) { const container = document.querySelector(`[data-tab-group="${groupId}"]`); container.querySelectorAll('.tab-button').forEach((btn, idx) => { btn.classList.toggle('active', idx === tabIndex); }); container.querySelectorAll('.tab-panel').forEach((panel, idx) => { panel.classList.toggle('active', idx === tabIndex); }); } </script> <p>If installed via <code>curl</code>, <code>uv</code> will download Python for your target platform if one of the required versions (Python 3.11 or 3.12) is not available natively.</p> + + + Running Tests + http://localhost:1313/main/running_tests/main/ + Wed, 09 Jul 2025 12:42:33 +0000 + http://localhost:1313/main/running_tests/main/ + <p>This section documents how EL clients can run EEST tests to verify their implementations. The information is organized as follows:</p> <ol> <li> <p><strong><a href="http://localhost:1313/main/running_tests/running/">Methods of Running Tests</a>:</strong> A detailed overview and comparison.</p> </li> <li> <p><strong><a href="http://localhost:1313/main/running_tests/releases/">EEST Fixture Releases</a>:</strong> The available release types; release versioning.</p> </li> <li> <p><strong><a href="http://localhost:1313/main/running_tests/test_formats/main/">Test Fixture Specifications</a></strong> and guides to implement direct consumer interfaces.</p> </li> <li> <p><strong><a href="http://localhost:1313/main/running_tests/hive/main/">Hive</a>:</strong> Help running EEST Hive simulators.</p> </li> <li> <p><strong><a href="http://localhost:1313/main/running_tests/consume/main/">Consume</a>:</strong> Commands that help clients run tests by consuming test fixtures.</p> </li> <li> <p><strong><a href="http://localhost:1313/main/running_tests/execute/main/">Execute</a>:</strong> Commands that help clients run tests by executing test source.</p> + + + Test Formats + http://localhost:1313/main/running_tests/test_formats/main/ + Wed, 09 Jul 2025 12:42:33 +0000 + http://localhost:1313/main/running_tests/test_formats/main/ + <h1 id="test-fixture-specifications">Test Fixture Specifications</h1> <p>The following sub-sections provide:</p> <ul> <li>Specifications for each test fixture format with an explanation of each field and its type.</li> <li>Guides on how to consume each format.</li> </ul> + + + Tutorials + http://localhost:1313/main/writing_tests/tutorials/main/ + Wed, 09 Jul 2025 12:42:33 +0000 + http://localhost:1313/main/writing_tests/tutorials/main/ + <h1 id="tutorials">Tutorials</h1> <p>Show overview of existing tutorials</p> + + + Writing Tests + http://localhost:1313/main/writing_tests/main/ + Wed, 09 Jul 2025 12:42:33 +0000 + http://localhost:1313/main/writing_tests/main/ + <p>The easiest way to get started is to use the interactive CLI:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-console" data-lang="console"><span style="display:flex;"><span>uv run eest make test </span></span></code></pre></div><p>and modify the generated test module to suit your needs.</p> <p><img src="http://localhost:1313/images/writing_tests/eest_make_test.gif" alt="Gif that shows how to create a test in EEST"></p> <p>For help deciding which test format to select, see <a href="http://localhost:1313/main/writing_tests/types_of_tests/">Types of Tests</a>, in particular <a href="http://localhost:1313/main/writing_tests/types_of_tests/#deciding-on-a-test-type">Deciding on a Test Type</a>.</p> <h2 id="key-resources">Key Resources</h2> <ul> <li><a href="http://localhost:1313/main/writing_tests/code_standards/#code-standards">Coding Standards</a> - Code style and standards for this repository</li> <li><a href="http://localhost:1313/main/writing_tests/adding_a_new_test/">Adding a New Test</a> - Step-by-step guide to adding new tests</li> <li><a href="http://localhost:1313/main/writing_tests/writing_a_new_test/">Writing a New Test</a> - Detailed guide on writing different test types</li> <li><a href="http://localhost:1313/main/writing_tests/fork_methods/">Using and Extending Fork Methods</a> - How to use fork methods to write fork-adaptive tests</li> <li><a href="http://localhost:1313/main/writing_tests/porting_legacy_tests/">Porting tests</a>: A guide to porting <a href="https://github.com/ethereum/tests" target="_blank" rel="noopener">ethereum/tests</a> to EEST.</li> </ul> <p>Please check that your code adheres to the repo&rsquo;s coding standards and read the other pages in this section for more background and an explanation of how to implement state transition and blockchain tests.</p> + + + + http://localhost:1313/main/running_tests/consume/cache/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/running_tests/consume/cache/ + <h1 id="consume-cache-and-fixture-inputs">Consume Cache and Fixture Inputs</h1> <p>The <code>consume cache</code> command can be used to resolve, download and cache fixture releases:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-console" data-lang="console"><span style="display:flex;"><span>consume cache --input=stable@v4.5.0 </span></span></code></pre></div><p>All <code>consume</code> subcommands have an <code>--input</code> argument, which implements the same functionality as <code>consume cache</code> to download and cache fixtures, respectively obtain downloaded fixtures from the cache.</p> <h2 id="example-two-liner-to-download-the-latest-fixture-release">Example: Two-liner to Download the Latest Fixture Release</h2> <p>Releases can be downloaded using EEST tooling without (manually) cloning and installing the @ethereum/execution-spec-tests tools as following:</p> + + + + http://localhost:1313/main/running_tests/consume/direct/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/running_tests/consume/direct/ + <h1 id="the-consume-direct-command">The <code>consume direct</code> Command</h1> <p>The <code>direct</code> method provides the fastest way to test EVM functionality by executing tests directly through a client&rsquo;s dedicated test interface (e.g. <a href="https://github.com/ethereum/go-ethereum/blob/4bb097b7ffc32256791e55ff16ca50ef83c4609b/cmd/evm/staterunner.go" target="_blank" rel="noopener"><code>statetest</code></a> or <a href="https://github.com/ethereum/go-ethereum/blob/35dd84ce2999ecf5ca8ace50a4d1a6abc231c370/cmd/evm/blockrunner.go" target="_blank" rel="noopener"><code>blocktest</code></a>).</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-bash" data-lang="bash"><span style="display:flex;"><span>uv run consume direct --bin<span style="color:#f92672">=</span>&lt;evm-binary&gt; <span style="color:#f92672">[</span>OPTIONS<span style="color:#f92672">]</span> </span></span></code></pre></div><ul> <li><code>--bin EVM_BIN</code>: Path to an evm executable that can process <code>StateTestFixture</code> and/or <code>BlockTestFixture</code> formats.</li> <li><code>--traces</code>: Collect execution traces from the evm executable.</li> </ul> <div class="callout callout-warning"> <div class="callout-title">Limited Client Support</div> <div class="callout-content"> <p>Currently, only the following clients can be used with <code>consume direct</code>:</p> <ul> <li>go-ethereum <code>statetest</code> and <code>blocktest</code>.</li> <li>Nethermind <code>nethtest</code>.</li> </ul> </div> </div> <h2 id="advantages">Advantages</h2> <ul> <li><strong>Speed</strong>: Fastest test execution method.</li> <li><strong>Simplicity</strong>: No container or network overhead.</li> <li><strong>Debugging</strong>: Easy access to traces and logs.</li> </ul> <h2 id="limitations">Limitations</h2> <ul> <li><strong>Limited client support</strong>: Only go-ethereum and Nethermind.</li> <li><strong>Module scope</strong>: Tests EVM, respectively block import, in isolation, not full client behavior.</li> <li><strong>Interface dependency</strong>: Requires client-specific test interfaces.</li> </ul> <h2 id="example-usage">Example Usage</h2> <p>Only run state tests (by using a mark filter, <code>-m</code>) from a local <code>fixtures</code> folder with go-ethereum:</p> + + + + http://localhost:1313/main/running_tests/consume/exceptions/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/running_tests/consume/exceptions/ + <h1 id="exception-tests">Exception Tests</h1> <h2 id="overview">Overview</h2> <p>Exception tests validate that clients correctly reject invalid blocks and transactions with appropriate error messages. The Engine simulator provides advanced exception verification using client-specific mappers to handle varying error message formats across different clients.</p> <h2 id="how-exception-testing-works">How Exception Testing Works</h2> <ol> <li><strong>Test fixtures specify expected exceptions</strong> - Each test defines what error should occur</li> <li><strong>Clients reject invalid payloads</strong> - Via Engine API or block import</li> <li><strong>Exception mappers translate errors</strong> - Client-specific error messages are normalized</li> <li><strong>Test framework validates</strong> - Ensures the correct exception type was raised</li> </ol> <h2 id="client-exception-mappers">Client Exception Mappers</h2> <p>Each client has unique error message formats. EEST maintains exception mappers that translate client-specific errors to standardized exception types.</p> + + + + http://localhost:1313/main/running_tests/consume/simulators/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/running_tests/consume/simulators/ + <h1 id="consume-simulators">Consume Simulators</h1> <p>The <code>engine</code> and <code>rlp</code> simulators test clients by importing blocks through different interfaces. These simulators run within the Hive testing framework to provide containerized, isolated testing environments.</p> <h2 id="command-syntax">Command Syntax</h2> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-bash" data-lang="bash"><span style="display:flex;"><span>uv run consume &lt;engine|rlp&gt; <span style="color:#f92672">[</span>OPTIONS<span style="color:#f92672">]</span> </span></span></code></pre></div><h2 id="relevant-information">Relevant Information</h2> <ul> <li>To install the <code>consume</code> command, see <a href="../../getting_started/main.md">Installation</a>.</li> <li>Help <a href="../hive/main.md">setting up</a> and <a href="../hive/dev_mode.md">starting Hive in dev mode</a>.</li> <li>For an explanation of how the <code>consume</code> simulators work, see the <a href="../running.md#engine">Engine</a> and <a href="../running.md#rlp">RLP</a> sections in <a href="../running.md">Running Tests</a>.</li> <li>Help for relevant options can be found in <a href="./cache.md">Consume Cache and Fixture Inputs</a> and <a href="../useful_pytest_options.md">Useful Pytest Options</a>.</li> </ul> + + + + http://localhost:1313/main/running_tests/execute/hive/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/running_tests/execute/hive/ + <h1 id="executing-tests-on-a-hive-local-network">Executing Tests on a Hive Local Network</h1> <p>Tests can be executed on a local hive-controlled single-client network by running the <code>execute hive</code> command.</p> <h2 id="the-eestexecute-blobs-simulator">The <code>eest/execute-blobs</code> Simulator</h2> <p>The <code>blob_transaction_test</code> execute test spec sends blob transactions to a running client in order to verify its <code>engine_getBlobsVX</code> endpoint behavior. These tests can be run using:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-bash" data-lang="bash"><span style="display:flex;"><span>./hive --client besu --client-file ./configs/osaka.yaml --sim ethereum/eest/execute-blobs </span></span></code></pre></div><p>See <a href="../hive/main.md">Hive</a> for help installing and configuring Hive.</p> <h2 id="running-execute-tests-with-hive-in-dev-mode">Running <code>execute</code> tests with Hive in Dev Mode</h2> <p>This command requires hive to be running in <code>--dev</code> mode:</p> + + + + http://localhost:1313/main/running_tests/execute/remote/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/running_tests/execute/remote/ + <h1 id="running-test-on-a-live-remote-network">Running Test on a Live Remote Network</h1> <p>Tests can be executed on a live remote network by running the <code>execute remote</code> command.</p> <p>The command requires the <code>--fork</code> flag which must match the fork that is currently active in the network (fork transition tests are not supported yet).</p> <p>The <code>execute remote</code> command requires to be pointed to an RPC endpoint of a client that is connected to the network, which can be specified by using the <code>--rpc-endpoint</code> flag:</p> + + + + http://localhost:1313/main/running_tests/hive/ci_integration/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/running_tests/hive/ci_integration/ + <h1 id="continuous-integration-and-automated-testing">Continuous Integration and Automated Testing</h1> <p>The Ethereum Foundation maintains continuous testing infrastructure:</p> <ul> <li><strong>Production results</strong>: <a href="https://hive.ethpandaops.io" target="_blank" rel="noopener">hive.ethpandaops.io</a></li> <li><strong>GitHub Actions</strong>: <a href="https://github.com/ethpandaops/hive-github-action" target="_blank" rel="noopener">ethpandaops/hive-github-action</a></li> </ul> + + + + http://localhost:1313/main/running_tests/hive/client_config/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/running_tests/hive/client_config/ + <h1 id="client-configuration-guide">Client Configuration Guide</h1> <p>Clients ran in Hive are configured via the following <code>./hive</code> options:</p> <ol> <li><code>--client-file=client_config.yaml</code>: Specifies a YAML file defining which and how clients are built.</li> <li><code>--client=client1,client2</code>: Selects a subset of clients to run from the YAML via <code>nametag</code>.</li> </ol> <h2 id="client-yaml-file-format">Client YAML File Format</h2> <p>Multiple client configurations can be defined as a list in a client YAML file with the following structure:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-yaml" data-lang="yaml"><span style="display:flex;"><span>- <span style="color:#f92672">client</span>: <span style="color:#ae81ff">&lt;client-name-1&gt;</span> </span></span><span style="display:flex;"><span> <span style="color:#f92672">nametag</span>: <span style="color:#ae81ff">&lt;unique-identifier&gt;</span> </span></span><span style="display:flex;"><span> <span style="color:#f92672">dockerfile</span>: <span style="color:#ae81ff">&lt;dockerfile-variant&gt;</span> </span></span><span style="display:flex;"><span> <span style="color:#f92672">build_args</span>: </span></span><span style="display:flex;"><span> <span style="color:#f92672">&lt;key&gt;</span>: <span style="color:#ae81ff">&lt;value&gt;</span> </span></span><span style="display:flex;"><span> <span style="color:#ae81ff">...</span> </span></span><span style="display:flex;"><span>- <span style="color:#f92672">client</span>: <span style="color:#ae81ff">&lt;client-name-2&gt;</span> </span></span><span style="display:flex;"><span> <span style="color:#ae81ff">...</span> </span></span></code></pre></div><h2 id="client-build-variants">Client Build Variants</h2> <p>Hive runs client images in Docker containers. There are three different ways to specify how a client image should be built:</p> + + + + http://localhost:1313/main/running_tests/hive/common_options/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/running_tests/hive/common_options/ + <h1 id="common-simulator-options">Common Simulator Options</h1> <p>All EEST Hive simulators share common command-line options and patterns.</p> <h2 id="basic-usage">Basic Usage</h2> <p>While they may be omitted, it&rsquo;s recommended to specify the <code>fixtures</code> and <code>branch</code> simulator build arguments when running EEST simulators.</p> <p>For example, this runs &ldquo;stable&rdquo; fixtures from the v4.3.0 <a href="../releases.md#standard-releases">latest stable release</a> and builds the simulator at the v4.3.0 tag:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-bash" data-lang="bash"><span style="display:flex;"><span>./hive --sim ethereum/eest/consume-engine <span style="color:#ae81ff">\ </span></span></span><span style="display:flex;"><span><span style="color:#ae81ff"></span> --sim.buildarg fixtures<span style="color:#f92672">=</span>stable@v4.3.0 <span style="color:#ae81ff">\ </span></span></span><span style="display:flex;"><span><span style="color:#ae81ff"></span> --sim.buildarg branch<span style="color:#f92672">=</span>v4.3.0 <span style="color:#ae81ff">\ </span></span></span><span style="display:flex;"><span><span style="color:#ae81ff"></span> --client go-ethereum </span></span></code></pre></div><h2 id="test-selection">Test Selection</h2> <p>Run a subset of tests by filtering tests using <code>--sim.limit=&lt;regex&gt;</code> to perform a regular expression match against test IDs:</p> + + + + http://localhost:1313/main/running_tests/hive/dev_mode/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/running_tests/hive/dev_mode/ + <h1 id="hive-development-mode">Hive Development Mode</h1> <p>This section explains how to run EEST simulators using their EEST commands, e.g., <code>uv run consume engine</code>, against a Hive &ldquo;development&rdquo; server as apposed to using the standalone <code>./hive</code> command.</p> <p>This avoids running the simulator in a dockerized environment and has several advantages:</p> <ol> <li>A local directory containing fixtures can be specified (<code>--input=./fixtures/</code>).</li> <li>Allows dropping into a Python debugger (via <code>--pdb</code>) upon test failure to inspect the response or ssh to the client container.</li> <li>Provides access to a larger set of the simulator&rsquo;s command-line options,</li> <li>Runs are faster; there are no docker image rebuilds in between runs. In particular, modifications to the simulator do not require a an image rebuild.</li> </ol> <h2 id="platform-support">Platform Support</h2> <ul> <li>Linux: Direct development mode supported.</li> <li>macOS: Must be ran from a Linux environment or use a Docker-based workaround (see macOS Setup).</li> </ul> <h2 id="quick-start">Quick Start</h2> <h3 id="prerequisites">Prerequisites</h3> <ul> <li>EEST is installed, see <a href="../../getting_started/main.md">Installation</a></li> <li>Hive is built, see <a href="../hive/main.md#quick-start">Hive</a>.</li> </ul> <h2 id="hive-dev-setup-on-linux">Hive Dev Setup on Linux</h2> <ol> <li> <p>Start Hive in development mode, e.g.:</p> + + + + http://localhost:1313/main/running_tests/hive/hiveview/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/running_tests/hive/hiveview/ + <h1 id="viewing-results">Viewing Results</h1> <p>Build the result viewer <code>hiveview</code>:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-bash" data-lang="bash"><span style="display:flex;"><span>go build ./cmd/hiveview </span></span></code></pre></div><p>Start the server:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-bash" data-lang="bash"><span style="display:flex;"><span>./hiveview --serve </span></span></code></pre></div> + + + + http://localhost:1313/main/running_tests/test_formats/blockchain_test/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/running_tests/test_formats/blockchain_test/ + <h1 id="blockchain-tests">Blockchain Tests <!-- markdownlint-disable MD051 (MD051=link-fragments "Link fragments should be valid") --></h1> <p>The Blockchain Test fixture format tests are included in the fixtures subdirectory <code>blockchain_tests</code>.</p> <p>These are produced by the <code>StateTest</code> and <code>BlockchainTest</code> test specs.</p> <h2 id="description">Description</h2> <p>The blockchain test fixture format is used to test block validation and the consensus rules of the Ethereum blockchain.</p> <p>It does so by defining a pre-execution state, a series of blocks, and a post-execution state, verifying that, after all the blocks have been processed, appended if valid or rejected if invalid, the result is the expected post-execution state.</p> + + + + http://localhost:1313/main/running_tests/test_formats/blockchain_test_engine/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/running_tests/test_formats/blockchain_test_engine/ + <h1 id="blockchain-engine-tests">Blockchain Engine Tests <!-- markdownlint-disable MD051 (MD051=link-fragments "Link fragments should be valid") --></h1> <p>The Blockchain Engine Test fixture format tests are included in the fixtures subdirectory <code>blockchain_tests_engine</code>, and use Engine API directives instead of the usual BlockchainTest format.</p> <p>These are produced by the <code>StateTest</code> and <code>BlockchainTest</code> test specs.</p> <h2 id="description">Description</h2> <p>The Blockchain Engine Test fixture format is used to test block validation and the consensus rules of the Ethereum blockchain, when a block is delivered through the Engine API as a <code>engine_newPayloadVX</code> directive.</p> + + + + http://localhost:1313/main/running_tests/test_formats/blockchain_test_engine_x/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/running_tests/test_formats/blockchain_test_engine_x/ + <h1 id="blockchain-engine-x-tests">Blockchain Engine X Tests <!-- markdownlint-disable MD051 (MD051=link-fragments "Link fragments should be valid") --></h1> <p>The Blockchain Engine X Test fixture format tests are included in the fixtures subdirectory <code>blockchain_tests_engine_x</code>, and use Engine API directives with optimized pre-allocation groups for improved execution performance.</p> <p>These are produced by the <code>StateTest</code> and <code>BlockchainTest</code> test specs when using the <code>--generate-pre-alloc-groups</code> and <code>--use-pre-alloc-groups</code> flags.</p> <h2 id="description">Description</h2> <p>The Blockchain Engine X Test fixture format is an optimized variant of the <a href="./blockchain_test_engine.md">Blockchain Engine Test</a> format designed for large-scale test execution with performance optimizations.</p> + + + + http://localhost:1313/main/running_tests/test_formats/common_types/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/running_tests/test_formats/common_types/ + <h1 id="common-types">Common Types</h1> <h2 id="basic-types">Basic Types</h2> <h3 id="address"><code>Address</code></h3> <p><a href="#bytes">Bytes</a> of a 20-byte fixed length.</p> <h3 id="bloom"><code>Bloom</code></h3> <p><a href="#bytes">Bytes</a> of a 256-byte fixed length.</p> <h3 id="bytes"><code>Bytes</code></h3> <p>Hexadecimal representation of binary data of any length encoded as a JSON string, with a &ldquo;0x&rdquo; prefix.</p> <h3 id="emptyaddress"><code>EmptyAddress</code></h3> <p>An empty JSON string <code>&quot;&quot;</code>, used to represent an empty address. E.g. in the <code>to</code> field of a transaction when it is a contract creation.</p> <h3 id="hash"><code>Hash</code></h3> <p><a href="#bytes">Bytes</a> of a 32-byte fixed length.</p> <h3 id="headernonce"><code>HeaderNonce</code></h3> <p><a href="#bytes">Bytes</a> of a 8-byte fixed length.</p> + + + + http://localhost:1313/main/running_tests/test_formats/exceptions/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/running_tests/test_formats/exceptions/ + <h1 id="exceptions">Exceptions</h1> <p>Exception types are represented as a JSON string in the test fixtures.</p> <p>The exception converted into a string is composed of the exception type name, followed by a period, followed by the specific exception name.</p> <p>For example, the exception <code>INSUFFICIENT_ACCOUNT_FUNDS</code> of type <code>TransactionException</code> is represented as <code>&quot;TransactionException.INSUFFICIENT_ACCOUNT_FUNDS&quot;</code>.</p> <p>The JSON string can contain multiple exception types, separated by the <code>|</code> character, denoting that the transaction or block can throw either one of the exceptions.</p> + + + + http://localhost:1313/main/running_tests/test_formats/state_test/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/running_tests/test_formats/state_test/ + <h1 id="state-tests">State Tests <!-- markdownlint-disable MD051 (MD051=link-fragments "Link fragments should be valid") --></h1> <p>The State Test fixture format tests are included in the fixtures subdirectory <code>state_tests</code>.</p> <p>These are produced by the <code>StateTest</code> and <code>StateTestOnly</code> test specs.</p> <h2 id="description">Description</h2> <p>The state test fixture format is used to test the state transition function of the Ethereum Virtual Machine (EVM).</p> <p>It does so by defining a transaction, a pre-execution state, and a post-execution state, and verifying that the transaction execution results in the expected post-execution state.</p> + + + + http://localhost:1313/main/running_tests/test_formats/transaction_test/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/running_tests/test_formats/transaction_test/ + <h1 id="transaction-tests">Transaction Tests <!-- markdownlint-disable MD051 (MD051=link-fragments "Link fragments should be valid") --></h1> <p>The Transaction Test fixture format tests are included in the fixtures subdirectory <code>transaction_tests</code>.</p> <p>These are produced by the <code>TransactionTest</code> test spec.</p> <h2 id="description">Description</h2> <p>The transaction test fixture format is used to test client&rsquo;s transaction RLP parsing without executing the transaction on the EVM.</p> <p>It does so by defining a transaction binary RLP representation, and whether the transaction should be accepted or rejected by the client in each fork.</p> + + + + http://localhost:1313/main/writing_tests/checklist_templates/eip_testing_checklist_template/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/writing_tests/checklist_templates/eip_testing_checklist_template/ + <!-- markdownlint-disable MD001 (MD001=heading-increment) --> <h1 id="eip-execution-layer-testing-checklist-template">EIP Execution Layer Testing Checklist Template</h1> <p>Depending on the changes introduced by an EIP, the following template is the minimum baseline to guarantee test coverage of the Execution Layer features.</p> <h2 id="checklist-progress-tracker">Checklist Progress Tracker</h2> <table> <thead> <tr> <th>Total Checklist Items</th> <th>Covered Checklist Items</th> <th>Percentage</th> </tr> </thead> <tbody> <tr> <td>TOTAL_CHECKLIST_ITEMS</td> <td>COVERED_CHECKLIST_ITEMS</td> <td>PERCENTAGE</td> </tr> </tbody> </table> <h2 id="general">General</h2> <h4 id="code-coverage">Code coverage</h4> <table> <thead> <tr> <th>ID</th> <th>Description</th> <th>Status</th> <th>Tests</th> </tr> </thead> <tbody> <tr> <td><code>general/code_coverage/eels</code></td> <td>Run produced tests against <a href="https://github.com/ethereum/execution-specs" target="_blank" rel="noopener">EELS</a> and verify that line code coverage of new added lines for the EIP is 100%, with only exceptions being unreachable code lines.</td> <td></td> <td></td> </tr> <tr> <td><code>general/code_coverage/test_coverage</code></td> <td>Run coverage on the test code itself (as a basic logic sanity check), i.e., <code>uv run fill --cov tests</code>.</td> <td></td> <td></td> </tr> <tr> <td><code>general/code_coverage/second_client</code></td> <td>Optional - Run against a second client and verify sufficient code coverage over new code added for the EIP.</td> <td></td> <td></td> </tr> </tbody> </table> <h4 id="fuzzing">Fuzzing</h4> <p>Fuzzing is recommended to be performed on EIPs that introduce new cryptography primitives.</p> + + + + http://localhost:1313/main/writing_tests/tutorials/blockchain/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/writing_tests/tutorials/blockchain/ + <h1 id="blockchain-tests">Blockchain Tests</h1> <p>This tutorial teaches you to create a blockchain execution specification test. These tests verify that a blockchain, starting from a defined pre-state, will process given blocks and arrive at a defined post-state.</p> <h2 id="pre-requisites">Pre-requisites</h2> <p>Before proceeding with this tutorial, it is assumed that you have prior knowledge and experience with the following:</p> <ul> <li>Repository set-up, see <a href="../../getting_started/main.md">installation</a>.and run an execution specification test as outlined in the .</li> <li>Able to run <code>fill</code>, see <a href="../../filling_tests/getting_started.md">Getting Started: Filling Tests</a>.</li> <li>Understand how to read a <a href="https://ethereum-tests.readthedocs.io/en/latest/test_filler/blockchain_filler.html" target="_blank" rel="noopener">blockchain test</a>.</li> <li>Familiarity with <a href="https://docs.python.org/3/tutorial/" target="_blank" rel="noopener">Python</a>.</li> <li>Understand how to write an execution spec <a href="./state_transition.md">state transition test</a>.</li> </ul> <h2 id="example-tests">Example Tests</h2> <p>In this tutorial we will go over [test_block_number] in <code>test_block_example.py</code>.</p> + + + + http://localhost:1313/main/writing_tests/tutorials/state_transition/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/writing_tests/tutorials/state_transition/ + <h1 id="state-transition-tests">State Transition Tests</h1> <p>This tutorial teaches you to create a state transition execution specification test using the Python Opcodes minilang for writing EVM bytecode. These tests verify that a starting pre-state will reach a specified post-state after executing a single transaction. In this example, we&rsquo;ll create a simple contract using bytecode and then interact with it through a transaction to verify the expected state changes.</p> <p>For an overview of different test types available, see <a href="../../writing_tests/types_of_tests.md">Types of Tests</a>.</p> + + + An Explanation of Test IDs + http://localhost:1313/main/filling_tests/test_ids/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/filling_tests/test_ids/ + <h2 id="test-case-organization">Test Case Organization</h2> <p>Test cases are implemented in Python &ldquo;modules&rdquo;, which are organized by folder, named after the fork where the feature-under-test was introduced, for example:</p> <ul> <li><code>tests/cancun/</code> contains tests for features added in the Cancun hardfork.</li> <li><code>tests/prague/</code> contains tests for features added in the Prague hardfork.</li> </ul> <h2 id="test-id-generation">Test ID generation</h2> <p>A test ID is a string, generated by the test framework, that uniquely identifies a test case. It&rsquo;s format is:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-text" data-lang="text"><span style="display:flex;"><span>&lt;python_test_module_path&gt;::&lt;python_test_function_name&gt;[&lt;parameter_1_id&gt;-...-&lt;parameter_N_id] </span></span></code></pre></div><p>Let&rsquo;s use the following simple test case example to understand this format:</p> + + + Debugging Transition Tools + http://localhost:1313/main/filling_tests/debugging_t8n_tools/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/filling_tests/debugging_t8n_tools/ + <p>There are two flags that can help debugging <code>t8n</code> tools or the execution-spec-tests framework:</p> <ol> <li><code>--evm-dump-dir</code> (Default: <repo>/logs/evm): Write debug information from <code>t8n</code> tool calls to the specified directory.</li> <li><code>--traces</code>: Collect traces of the execution from the transition tool.</li> <li><code>--verify-fixtures</code>: Run go-ethereum&rsquo;s <code>evm blocktest</code> command to verify the generated test fixtures.</li> </ol> <h2 id="evm-dump-directory">EVM Dump Directory</h2> <p>The <code>--evm-dump-dir</code> flag tells the framework to write the inputs and outputs of every call made to the <code>t8n</code> command to the specified output directory. The aim is to help debugging or simply understand how a test is interacting with the EVM. The default location is <code>logs/evm</code> in the project root.</p> + + + Filling Tests at a Prompt + http://localhost:1313/main/filling_tests/filling_tests_command_line/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/filling_tests/filling_tests_command_line/ + <p>The execution-spec-tests test framework uses the <a href="https://docs.pytest.org/en/latest/" target="_blank" rel="noopener">pytest framework</a> for test case collection and execution. The <code>fill</code> command is essentially an alias for <code>pytest</code>, which uses several <a href="../library/pytest_plugins/main.md">custom pytest plugins</a> to run transition tools against test cases and generate JSON fixtures.</p> <div class="callout callout-info"> <div class="callout-title">Options specific to execution-spec-tests</div> <div class="callout-content"> <p>The command-line options specific to filling tests can be listed via:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-console" data-lang="console"><span style="display:flex;"><span>uv run fill --help </span></span></code></pre></div><p>See <a href="#custom-fill-command-line-options">Custom <code>fill</code> Command-Line Options</a> for all options.</p> </div> </div> <h2 id="collection---test-exploration">Collection - Test Exploration</h2> <p>The test cases implemented in the <code>./tests</code> sub-directory can be listed in the console using:</p> + + + Filling Tests for Features under Development + http://localhost:1313/main/filling_tests/filling_tests_dev_fork/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/filling_tests/filling_tests_dev_fork/ + <h2 id="requirements">Requirements</h2> <p>By default, execution-spec-tests only generates fixtures for forks that have been deployed to mainnet. In order to generate fixtures for evm features that are actively under development:</p> <ol> <li>A version of the <code>evm</code> and <code>solc</code> tools that implement the feature must be available (although, typically only a developer version of the <code>evm</code> tool is required, usually the latest stable release of <code>solc</code> is adequate), and,</li> <li>The development fork to test must be explicitly specified on the command-line:</li> </ol> <div class="tab-container" data-tab-group="tabs-0"> <div class="tab-header"> <button class="tab-button active" onclick="switchTab('tabs-0', 0 )"> via the <code>--fork</code> flag </button> <button class="tab-button " onclick="switchTab('tabs-0', 1 )"> via the <code>--from</code> flag </button> <button class="tab-button " onclick="switchTab('tabs-0', 2 )"> via the <code>--until</code> flag </button> </div> <div class="tab-panels"> <div class="tab-panel active"> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-console" data-lang="console"><span style="display:flex;"><span>uv run fill -k 4844 --fork=Cancun -v </span></span></code></pre></div> </div> <div class="tab-panel "> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-console" data-lang="console"><span style="display:flex;"><span>uv run fill -k 4844 --from=Cancun -v </span></span></code></pre></div> </div> <div class="tab-panel "> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-console" data-lang="console"><span style="display:flex;"><span>uv run fill -k 4844 --until=Cancun -v </span></span></code></pre></div> </div> </div> </div> <style> .tab-container { margin: 1.5rem 0; background: #f8f9fa; border-radius: 8px; overflow: hidden; box-shadow: 0 1px 3px rgba(0,0,0,0.1); } .tab-header { display: flex; background: #e9ecef; } .tab-button { flex: 1; padding: 0.75rem 1rem; border: none; background: transparent; cursor: pointer; font-size: 14px; white-space: nowrap; transition: all 0.2s; position: relative; text-align: center; overflow: hidden; text-overflow: ellipsis; } .tab-button:hover { background: rgba(0,0,0,0.05); } .tab-button.active { background: #f8f9fa; font-weight: 600; color: #007bff; } .tab-button.active::after { content: ''; position: absolute; bottom: 0; left: 0; right: 0; height: 3px; background: #007bff; } .tab-button code { background: rgba(0,0,0,0.1); padding: 2px 4px; border-radius: 3px; font-size: 12px; } .tab-panel { display: none; padding: 1.5rem; background: white; } .tab-panel.active { display: block; } .tab-panel pre { margin: 0; background: #f6f8fa; border: 1px solid #e1e4e8; } @media (max-width: 768px) { .tab-header { flex-wrap: wrap; } .tab-button { flex: 1 1 50%; padding: 0.5rem 0.75rem; font-size: 13px; } @media (max-width: 480px) { .tab-button { flex: 1 1 100%; } } } </style> <script> function switchTab(groupId, tabIndex) { const container = document.querySelector(`[data-tab-group="${groupId}"]`); container.querySelectorAll('.tab-button').forEach((btn, idx) => { btn.classList.toggle('active', idx === tabIndex); }); container.querySelectorAll('.tab-panel').forEach((panel, idx) => { panel.classList.toggle('active', idx === tabIndex); }); } </script> <div class="callout callout-info"> <div class="callout-title">Specifying the <code>evm</code> binary via <code>evm-bin</code></div> <div class="callout-content"> <p>It is possible to explicitly specify the <code>evm</code> binary used to generate fixtures via the <code>--evm-bin</code> flag, for example,</p> + + + Filling Tests in VS Code + http://localhost:1313/main/filling_tests/filling_tests_vs_code/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/filling_tests/filling_tests_vs_code/ + <p>Prerequisite: <a href="../getting_started/setup_vs_code.md">VS Code Setup</a>.</p> <h2 id="exploring-test-cases">Exploring Test Cases</h2> <p>Implemented test cases can be explored in VS Code&rsquo;s &ldquo;Testing&rdquo; View; click on the conical flask highlighted in the screenshot below.</p> <p><img src="http://localhost:1313/images/filling_tests/vs_code_exploring_tests.png" alt="VS Code Testing Tab"></p> <div class="callout callout-info"> <div class="callout-title">Testing EVM Features Under Active Development</div> <div class="callout-content"> See <a href="./filling_tests_dev_fork.md#vs-code-setup">the VS Code section</a> in <a href="./filling_tests_dev_fork.md">Filling Tests for Features under Development</a> to explore tests targeting EVM features under development. </div> </div> <h2 id="filling-and-debugging-test-cases">Filling and Debugging Test Cases</h2> <p><img src="http://localhost:1313/images/filling_tests/vs_code_executing_tests.png" alt="VS Code Testing Tab"></p> + + + Transition Tool Support + http://localhost:1313/main/filling_tests/transition_tool_support/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/main/filling_tests/transition_tool_support/ + <p>The following transition tools are supported by the framework:</p> <table> <thead> <tr> <th>Client</th> <th><code>t8n</code> Tool</th> <th>Tracing Support</th> </tr> </thead> <tbody> <tr> <td><a href="https://github.com/ethereum/evmone" target="_blank" rel="noopener">ethereum/evmone</a></td> <td><code>evmone-t8n</code></td> <td>Yes</td> </tr> <tr> <td><a href="https://github.com/ethereum/execution-specs" target="_blank" rel="noopener">ethereum/execution-specs</a></td> <td><a href="https://github.com/petertdavies/ethereum-spec-evm-resolver" target="_blank" rel="noopener"><code>ethereum-spec-evm-resolver</code></a></td> <td>Yes</td> </tr> <tr> <td><a href="https://github.com/ethereumjs/ethereumjs-monorepo" target="_blank" rel="noopener">ethereumjs</a></td> <td><a href="https://github.com/ethereumjs/ethereumjs-monorepo/tree/master/packages/vm/test/t8n" target="_blank" rel="noopener"><code>ethereumjs-t8ntool.sh</code></a></td> <td>No</td> </tr> <tr> <td><a href="https://github.com/ethereum/go-ethereum" target="_blank" rel="noopener">ethereum/go-ethereum</a></td> <td><a href="https://github.com/ethereum/go-ethereum/tree/master/cmd/evm" target="_blank" rel="noopener"><code>evm t8n</code></a></td> <td>Yes</td> </tr> <tr> <td><a href="https://github.com/hyperledger/besu/tree/main/ethereum/evmtool" target="_blank" rel="noopener">hyperledger/besu</a></td> <td><a href="https://github.com/hyperledger/besu/tree/main/ethereum/evmtool" target="_blank" rel="noopener"><code>evmtool t8n-server</code></a></td> <td>Yes</td> </tr> <tr> <td><a href="https://github.com/status-im/nimbus-eth1" target="_blank" rel="noopener">status-im/nimbus-eth1</a></td> <td><a href="https://github.com/status-im/nimbus-eth1/blob/master/tools/t8n/readme.md" target="_blank" rel="noopener"><code>t8n</code></a></td> <td>Yes</td> </tr> </tbody> </table> + + + diff --git a/docs/public/main/installation_troubleshooting/index.html b/docs/public/main/installation_troubleshooting/index.html new file mode 100644 index 00000000000..7078bedaf32 --- /dev/null +++ b/docs/public/main/installation_troubleshooting/index.html @@ -0,0 +1,1430 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

Installation Troubleshooting

+

This page provides guidance on how to troubleshoot common issues that may arise when installing ethereum/execution-spec-tests.

+

Problem: Failed building wheel for coincurve

+ + +
+
Problem: Failed building wheel for coincurve
+
+

Installing EEST and its dependencies via uv sync --all-extras fails with:

+
Stored in directory: /tmp/...
+    Building wheel for coincurve (pyproject.toml) ... error
+    error: subprocess-exited-with-error
+    
+    Γ— Building wheel for coincurve (pyproject.toml) did not run successfully.
+    β”‚ exit code: 1
+    ╰─> [27 lines of output]
+        ...
+        571 | #include <secp256k1_extrakeys.h>
+            |          ^~~~~~~~~~~~~~~~~~~~~~~
+        compilation terminated.
+        error: command '/usr/bin/gcc' failed with exit code 1
+        [end of output]
+    
+    note: This error originates from a subprocess, and is likely not a problem with pip.
+    ERROR: Failed building wheel for coincurve
+
+
+
+ + +
+
Solution: Install the libsecp256k1 library
+
+

On Ubuntu, you can install this library with:

+
sudo apt update
+sudo apt-get install libsecp256k1-dev
+
+
+
+

Problem: solc Installation issues

+

Problem: CERTIFICATE_VERIFY_FAILED

+ + +
+
Problem: Failed to ... CERTIFICATE_VERIFY_FAILED
+
+

When running fill you might encounter the following error:

+
Exit: Failed to ...: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:992)>
+
+
+
+

=== “Ubuntu”

+ + +
+
Solution: Update your system’s CA certificates
+
+

On Ubuntu, run the following commands:

+
sudo apt-get update
+sudo apt-get install ca-certificates
+
+
+
+

=== “macOS” + + +

+
Solution: Update your system’s CA certificates
+
+

On macOS, Python provides a built-in script to install the required certificates:

+
/Applications/Python\ 3.11/Install\ Certificates.command
+
+
+

+

Problem: Exception: failed to compile yul source

+ + +
+
Problem: Running fill on static_tests fails with tests that contain yul source code on ARM platforms
+
+ To resolve the issue you must acquire the solc binary e.g. by building solidity from source. The guide below installs v0.8.28 but you might prefer to choose a different version. +
+
+ + +
+
Solution: Build solc from source
+
+

The following steps have been tested on Ubuntu 24.04.2 LTS ARM64:

+
git clone --branch v0.8.28 --depth 1 https://github.com/ethereum/solidity.git
+cd solidity && mkdir build && cd build
+sudo apt install build-essential libboost-all-dev z3
+cmake ..
+make
+mv $HOME/Documents/execution-spec-tests/.venv/bin/solc $HOME/Documents/execution-spec-tests/.venv/bin/solc-x86-64
+cp ./solc/solc $HOME/Documents/execution-spec-tests/.venv/bin/
+chmod +x $HOME/Documents/execution-spec-tests/.venv/bin/solc
+

Running uv run solc --version should now return the expected version.

+ +
+
+

Problem: ValueError: unsupported hash type ripemd160

+ + +
+
Problem: Running fill fails with tests that use the RIPEMD160 precompile (0x03)
+
+

When running fill, you encounter the following error:

+
ValueError: unsupported hash type ripemd160
+# or
+ValueError: [digital envelope routines] unsupported
+

This is due to the removal of certain cryptographic primitives in OpenSSL 3. These were re-introduced in OpenSSL v3.0.7.

+ +
+
+ + +
+
Solution: Modify OpenSSL configuration
+
+

On platforms where OpenSSL v3.0.7 is unavailable (e.g., Ubuntu 22.04), modify your OpenSSL configuration to enable RIPEMD160. Make the following changes in the OpenSSL config file:

+
[openssl_init]
+providers = provider_sect
+
+# List of providers to load
+[provider_sect]
+default = default_sect
+legacy = legacy_sect
+
+[default_sect]
+activate = 1
+
+[legacy_sect]
+activate = 1
+

This will enable the legacy cryptographic algorithms, including RIPEMD160. See ethereum/execution-specs#506 for more information.

+ +
+
+

Other Issues Not Listed?

+

If you’re facing an issue that’s not listed here, you can easily report it on GitHub for resolution.

+

Click here to report a documentation issue related to installation

+

Please include the following details in your report:

+
    +
  1. The command that triggered the issue.
  2. +
  3. Any relevant error messages or screenshots.
  4. +
  5. Relevant version information from the output of uv run eest info (if running consume from within eest).
  6. +
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/interactive_usage/index.html b/docs/public/main/interactive_usage/index.html new file mode 100644 index 00000000000..e0c3d6e11d7 --- /dev/null +++ b/docs/public/main/interactive_usage/index.html @@ -0,0 +1,1352 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

Working with EEST Libraries Interactively

+

You can work with EEST Python packages interactively with ipython using:

+
uvx  --with-editable . ipython
+

This command will create a virtual environment, install EEST’s packages in “editable mode” (source changes get reflected in the interactive shell), and start an ipython shell. You can then import any of the packages and experiment with them interactively.

+ + +
+
Example: Working with ethereum_test_forks
+
+

See which defined forks are “ignored” by default:

+
from ethereum_test_forks import forks, get_forks
+forks = set([fork for fork in get_forks() if fork.ignore()])
+print(forks)
+# -> {MuirGlacier, ArrowGlacier, GrayGlacier}
+
+
+
+

Required ipython Configuration

+

To enable autoreload of changed modules in the current ipython session, type:

+
%load_ext autoreload
+%autoreload 2
+

To make this configuration persistent, add/uncomment the following lines to ~/.ipython/profile_default/ipython_config.py:

+
c.InteractiveShellApp.exec_lines = ["%autoreload 2"]
+c.InteractiveShellApp.extensions = ["autoreload"]
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/logging/index.html b/docs/public/main/logging/index.html new file mode 100644 index 00000000000..279524b1955 --- /dev/null +++ b/docs/public/main/logging/index.html @@ -0,0 +1,1476 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

Logging

+

This document describes the logging system used in the Ethereum Execution Spec Tests project. Currently, logging is only supported for consume commands.

+

Overview

+

The project uses Python’s standard logging module with custom extensions to provide enhanced logging capabilities. Our logging system is implemented in the src/pytest_plugins/logging.py module and provides the following features:

+
    +
  • Custom log levels between the standard Python log levels
  • +
  • Timestamps with millisecond precision in UTC
  • +
  • Color-coded log output (when not running in Docker)
  • +
  • File logging with a consistent naming pattern
  • +
  • Integration with pytest’s output capture
  • +
  • Support for distributed test execution with pytest-xdist
  • +
+

Custom Log Levels

+

In addition to the standard Python log levels (DEBUG, INFO, WARNING, ERROR, CRITICAL), we’ve added the following custom levels:

+ + + + + + + + + + + + + + + + + + + + +
LevelNumeric ValuePurpose
VERBOSE15For messages more detailed than INFO but less verbose than DEBUG
FAIL35For test failures and related issues (between WARNING and ERROR)
+

Using the Logger

+

Getting a Logger

+

To use the custom logger in your code, import the get_logger function from the logging module:

+
from pytest_plugins.logging import get_logger
+
+# Create a logger with your module's name
+logger = get_logger(__name__)
+

Logging at Different Levels

+

You can use all standard Python log methods plus our custom methods:

+
# Standard log levels
+logger.debug("Detailed debug information")
+logger.info("General information")
+logger.warning("Warning message")
+logger.error("Error message")
+logger.critical("Critical failure")
+
+# Custom log levels
+logger.verbose("More detailed than INFO, less than DEBUG")
+logger.fail("Test failure or similar issue")
+

When to Use Each Level

+
    +
  • DEBUG (10): For very detailed diagnostic information useful for debugging
  • +
  • VERBOSE (15): For information that’s useful during development but more detailed than INFO
  • +
  • INFO (20): For general information about program operation
  • +
  • WARNING (30): For potential issues that don’t prevent program execution
  • +
  • FAIL (35): For test failures and related issues
  • +
  • ERROR (40): For errors that prevent an operation from completing
  • +
  • CRITICAL (50): For critical errors that may prevent the program from continuing
  • +
+

Configuration

+

Setting Log Level on the Command Line

+

You can adjust the log level when running pytest with the --eest-log-level option:

+
consume engine --input=latest@stable --eest-log-level=VERBOSE -s --sim.limit=".*chainid.*"
+

The argument accepts both log level names (e.g., “DEBUG”, “VERBOSE”, “INFO”) and numeric values.

+

Adding pytest’s -s flag writes the logging messages to the terminal; otherwise output will be written to the log file that is reported in the test session header at the end of the test session.

+

Log File Output

+

Log files are automatically created in the logs/ directory with a naming pattern that includes:

+
    +
  • The command name, e.g. consume,
  • +
  • An optional subcommand (e.g., engine),
  • +
  • A timestamp in UTC,
  • +
  • The worker ID (when using pytest-xdist).
  • +
+

Example: consume-engine-20240101-123456-main.log

+

The log file path is displayed in the pytest header and summary.

+

Using the Standalone Configuration in Non-Pytest Projects

+

The logging module can also be used in non-pytest projects by using the configure_logging function:

+
from pytest_plugins.logging import configure_logging, get_logger
+
+# Configure logging with custom settings
+configure_logging(
+    log_level="VERBOSE",
+    log_file="my_application.log",
+    log_to_stdout=True,
+    log_format="%(asctime)s [%(levelname)s] %(name)s: %(message)s",
+    use_color=True
+)
+
+# Get a logger and use it
+logger = get_logger(__name__)
+logger.verbose("Logging configured in standalone application!")
+

The configure_logging function accepts the following parameters:

+
    +
  • log_level: A string or numeric log level (default: “INFO”)
  • +
  • log_file: Path to a log file, or None to disable file logging (default: None)
  • +
  • log_to_stdout: Whether to log to stdout (default: True)
  • +
  • log_format: The format string for log messages (default: “%(asctime)s [%(levelname)s] %(name)s: %(message)s”)
  • +
  • use_color: Whether to use colors in stdout output, or None to auto-detect (default: None)
  • +
+

Implementation Details

+

The EESTLogger Class

+

The EESTLogger class extends Python’s Logger class to add the custom log methods. The main module logger is automatically configured to use this class.

+

Formatters

+

Two formatter classes are available:

+
    +
  • UTCFormatter: Formats timestamps with millisecond precision in UTC
  • +
  • ColorFormatter: Extends UTCFormatter to add ANSI colors to log level names in terminal output
  • +
+

Pytest and Hive Integration

+

The logging module includes several pytest hooks to:

+
    +
  • Configure logging at the start of a test session
  • +
  • Record logs during test execution
  • +
  • Display the log file path in the test report
  • +
  • Ensure logs are captured properly during fixture teardown
  • +
+

The hive_pytest plugin has been extended to propagate the logs to the hiveview UI via the test case’s details (“description” in hiveview).

+

Example Usage

+

A complete example of using the logging system in a consume test (or plugin):

+
from pytest_plugins.logging import get_logger
+
+# Get a properly typed logger for your module
+logger = get_logger(__name__)
+
+def test_something():
+    # Use standard log levels
+    logger.debug("Setting up test variables")
+    logger.info("Starting test")
+    
+    # Use custom log levels
+    logger.verbose("Additional details about test execution")
+    
+    # Log warnings or errors as needed
+    if something_concerning:
+        logger.warning("Something looks suspicious")
+    
+    if something_failed:
+        logger.fail("Test condition not met")
+        assert False, "Test failed"
+    
+    # Log successful completion
+    logger.info("Test completed successfully")
+

All log messages will be displayed according to the configured log level and captured in the log file.

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/main/index.html b/docs/public/main/main/index.html new file mode 100644 index 00000000000..b243aa046e3 --- /dev/null +++ b/docs/public/main/main/index.html @@ -0,0 +1,1667 @@ + + + + + + + Execution Spec Tests - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

Execution Spec Tests

+
+ +
+

Execution Spec Tests Logo

+

ethereum/execution-spec-tests is both a collection of test cases and a framework in Python to generate tests for Ethereum execution clients.

+

The framework collects and executes the test cases in order to generate test fixtures (JSON) which can be consumed by any execution client to verify their implementation of ethereum/execution-specs. The fixtures, which define state transition and block tests, are generated by the framework using one of the t8n command-line tools that are provided by most execution clients, see below for an overview of the supported t8n tools.

+

Test Fixture Generation with execution-spec-tests

+

The generated test fixtures can be used:

+
    +
  1. Directly by client teams’ test frameworks, and,
  2. +
  3. In the integration tests executed in the ethereum/hive framework.
  4. +
+

More information on how to use and download the released test fixtures can be found here.

+

Relationship to ethereum/tests

+

This collection of tests is relatively new (test case development started Q4, 2022) and mainly targets recent and upcoming Ethereum specification changes. It does not replace, but rather complements the existing tests in ethereum/tests.

+

Motivation

+

The motivation to implement test cases in ethereum/execution-spec-tests is:

+
    +
  1. To implement test cases as code and ensure that changes, due to spec changes, for example, can be easily made. Moreover, changes are easily understandable and available in version control.
  2. +
  3. To avoid the 2-step approach often used in ethereum/tests: +
      +
    • Code (often unavailable) -> Test case (YAML).
    • +
    • Test case (YAML) -> Fixtures (JSON).
    • +
    +
  4. +
+ + +
+
Contributing
+
+ Contributions via PR are welcome! +
+
+ + +
+
Reporting a Vulnerability
+
+

Care is required when adding PRs or issues for functionality that is live on Ethereum mainnet. Please report vulnerabilities and verify bounty eligibility via the bug bounty program.

+
    +
  • Please do not create a PR with a vulnerability visible.
  • +
  • Please do not file a public ticket mentioning the vulnerability.
  • +
+
+
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/navigation/index.html b/docs/public/main/navigation/index.html new file mode 100644 index 00000000000..62713c6a336 --- /dev/null +++ b/docs/public/main/navigation/index.html @@ -0,0 +1,1769 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ + +
+ +
+

+
+ +
+
+ + +
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/page/1/index.html b/docs/public/main/page/1/index.html new file mode 100644 index 00000000000..ecb1cd6f98e --- /dev/null +++ b/docs/public/main/page/1/index.html @@ -0,0 +1,10 @@ + + + + http://localhost:1313/main/ + + + + + + diff --git a/docs/public/main/page/10/index.html b/docs/public/main/page/10/index.html new file mode 100644 index 00000000000..d88635e4d83 --- /dev/null +++ b/docs/public/main/page/10/index.html @@ -0,0 +1,178 @@ + + + + + + + + Mains + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

Mains

+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+ +
+
+ +
+ + + + + + + diff --git a/docs/public/main/page/11/index.html b/docs/public/main/page/11/index.html new file mode 100644 index 00000000000..ce4b4a7dcac --- /dev/null +++ b/docs/public/main/page/11/index.html @@ -0,0 +1,178 @@ + + + + + + + + Mains + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

Mains

+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+ +
+
+ +
+ + + + + + + diff --git a/docs/public/main/page/12/index.html b/docs/public/main/page/12/index.html new file mode 100644 index 00000000000..67bc8a0ff34 --- /dev/null +++ b/docs/public/main/page/12/index.html @@ -0,0 +1,178 @@ + + + + + + + + Mains + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

Mains

+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+ +
+
+ +
+ + + + + + + diff --git a/docs/public/main/page/13/index.html b/docs/public/main/page/13/index.html new file mode 100644 index 00000000000..2b5308af64a --- /dev/null +++ b/docs/public/main/page/13/index.html @@ -0,0 +1,178 @@ + + + + + + + + Mains + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

Mains

+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+ +
+
+ +
+ + + + + + + diff --git a/docs/public/main/page/14/index.html b/docs/public/main/page/14/index.html new file mode 100644 index 00000000000..18f5008a82a --- /dev/null +++ b/docs/public/main/page/14/index.html @@ -0,0 +1,178 @@ + + + + + + + + Mains + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

Mains

+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+ +
+
+ +
+ + + + + + + diff --git a/docs/public/main/page/15/index.html b/docs/public/main/page/15/index.html new file mode 100644 index 00000000000..f4c6b20ddd5 --- /dev/null +++ b/docs/public/main/page/15/index.html @@ -0,0 +1,118 @@ + + + + + + + + Mains + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

Mains

+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+ +
+
+ +
+ + + + + + + diff --git a/docs/public/main/page/2/index.html b/docs/public/main/page/2/index.html new file mode 100644 index 00000000000..c441d0c0779 --- /dev/null +++ b/docs/public/main/page/2/index.html @@ -0,0 +1,291 @@ + + + + + + + + Mains + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

Mains

+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+ +
+
+ +
+ + + + + + + diff --git a/docs/public/main/page/3/index.html b/docs/public/main/page/3/index.html new file mode 100644 index 00000000000..c441d0c0779 --- /dev/null +++ b/docs/public/main/page/3/index.html @@ -0,0 +1,291 @@ + + + + + + + + Mains + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

Mains

+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+ +
+
+ +
+ + + + + + + diff --git a/docs/public/main/page/4/index.html b/docs/public/main/page/4/index.html new file mode 100644 index 00000000000..c441d0c0779 --- /dev/null +++ b/docs/public/main/page/4/index.html @@ -0,0 +1,291 @@ + + + + + + + + Mains + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

Mains

+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+ +
+
+ +
+ + + + + + + diff --git a/docs/public/main/page/5/index.html b/docs/public/main/page/5/index.html new file mode 100644 index 00000000000..c441d0c0779 --- /dev/null +++ b/docs/public/main/page/5/index.html @@ -0,0 +1,291 @@ + + + + + + + + Mains + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

Mains

+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+ +
+
+ +
+ + + + + + + diff --git a/docs/public/main/page/6/index.html b/docs/public/main/page/6/index.html new file mode 100644 index 00000000000..c441d0c0779 --- /dev/null +++ b/docs/public/main/page/6/index.html @@ -0,0 +1,291 @@ + + + + + + + + Mains + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

Mains

+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+ +
+
+ +
+ + + + + + + diff --git a/docs/public/main/page/7/index.html b/docs/public/main/page/7/index.html new file mode 100644 index 00000000000..18845dddb3b --- /dev/null +++ b/docs/public/main/page/7/index.html @@ -0,0 +1,178 @@ + + + + + + + + Mains + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

Mains

+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+ +
+
+ +
+ + + + + + + diff --git a/docs/public/main/page/8/index.html b/docs/public/main/page/8/index.html new file mode 100644 index 00000000000..3d9e5310ba1 --- /dev/null +++ b/docs/public/main/page/8/index.html @@ -0,0 +1,178 @@ + + + + + + + + Mains + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

Mains

+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+ +
+
+ +
+ + + + + + + diff --git a/docs/public/main/page/9/index.html b/docs/public/main/page/9/index.html new file mode 100644 index 00000000000..4481711bfe8 --- /dev/null +++ b/docs/public/main/page/9/index.html @@ -0,0 +1,178 @@ + + + + + + + + Mains + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

Mains

+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+ +
+
+ +
+ + + + + + + diff --git a/docs/public/main/porting_legacy_tests/index.html b/docs/public/main/porting_legacy_tests/index.html new file mode 100644 index 00000000000..6210c9ac89e --- /dev/null +++ b/docs/public/main/porting_legacy_tests/index.html @@ -0,0 +1,1558 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

A Guide to Porting Original Ethereum Tests to EEST

+

Background

+

EEST is the successor to ethereum/tests (aka “original tests”), a repository that defined EVM test cases from the Frontier phase up to and including The Merge. These test cases are specified as YAML (and occasionally JSON) files in the ./src/ sub-directory. JSON test fixtures, which are fully-populated tests that can be executed against clients, are generated using ethereum/retesteth. These JSON artifacts are regenerated when needed and added to the repository, typically in the tests/static/state_tests sub-directory.

+

From Shanghai onward, new test cases β€” especially for new features introduced in hard forksβ€”are defined in Python within EEST. While the existing test cases remain important for client testing, porting ethereum/tests to EEST will help maintain and generate tests for newer forks. This also ensures feature parity, as client teams will only need to obtain test fixture releases from one source.

+

While automating the conversion of the remaining YAML (or JSON) test cases to Python is possible, manually porting individual test cases offers several benefits:

+
    +
  • Reducing the number of test cases by combining multiple YAML (or JSON) cases into a single Python test function using parametrization.
  • +
  • Potentially improving coverage by parametrizing the Python version.
  • +
  • Producing higher quality code and documentation, which are typically clearer than an automated conversion.
  • +
  • Ensuring better organization of tests within the ./tests folder of execution-spec-tests by fork and EIP.
  • +
+

Porting an original test

+
    +
  1. +

    Select one or more test cases from ./tests/static/state_tests/ to port and create an issue in this repository AND comment on this tracker issue.

    +
  2. +
  3. +

    Add a new test in the appropriate fork folder, following the guidelines for choosing a test type.

    +
  4. +
  5. +

    Submit a PR with the ported tests:

    +
      +
    1. +

      Add the list of ported files using python marker to the head of your python test.

      +

      Example:

      +
       @pytest.mark.ported_from(
      +[
      +    "https://github.com/ethereum/tests/blob/v13.3/src/GeneralStateTestsFiller/stCreateTest/CREATE_ContractSuicideDuringInit_ThenStoreThenReturnFiller.json",
      +    "https://github.com/ethereum/tests/blob/v13.3/src/GeneralStateTestsFiller/stCreateTest/CREATE_ContractSuicideDuringInit_WithValueFiller.json",
      +],
      +pr=["https://github.com/ethereum/execution-spec-tests/pull/1871"],
      +# coverage_missed_reason="Converting solidity code result in following opcode not being used:",
      +

      Replace test names with your chosen tests and PR number.

      +

      Uncomment coverage_missed_reason when all the missed coverage lines are approved, usually some opcodes end up not used after translating test logic from lllc, yul.

      +

      But sometimes missed coverage line could hint that you forgot to account important test logic.

      +

      If no coverage is missed, you are good!

      +
    2. +
    3. +

      Remove the ported files from .tests/static/state_tests in your PR

      +
    4. +
    +
  6. +
+
+

See also: πŸ“„ Getting started with EEST.

+

Filling tests

+

EEST uses pytest to run tests against EELS (an EVM implementation for testing). This process is known as “filling” and verifies the assertions in your tests. You can use the fill CLI for this. For example, see how to fill the PUSH opcode.

+
uv run fill tests/frontier/opcodes/test_push.py
+

See also: πŸ“„ Documentation for the fill command.

+
+

If the tests can’t currently be filled, please explain the issue (feel free to also open a Discussion).

+

Debugging tests

+

By default, EVM logs are stored in the logs folder at the repository root. You can check the output folder to review transaction results. If needed, review a previous PR that ported tests (e.g., the PR porting the PUSH opcode, and other port PRs).

+

Test coverage

+

It’s crucial that ported tests maintain coverage parity with original tests. This ensures that no critical functions are left untested and prevents the introduction of bugs. A CI workflow automatically checks for coverage.

+

If coverage action fails (See: πŸ“„ An example of a failing test coverage), it’s recommended to run the coverage action locally (see: πŸ“„ How to run GitHub actions locally), which should generate a evmtest_coverage directory:

+
❯ tree evmtest_coverage  -L 2
+evmtest_coverage
+└── coverage
+    β”œβ”€β”€ BASE
+    β”œβ”€β”€ BASE_TESTS
+    β”œβ”€β”€ coverage_BASE.lcov
+    β”œβ”€β”€ coverage_PATCH.lcov
+    β”œβ”€β”€ DIFF
+    β”œβ”€β”€ difflog.txt
+    β”œβ”€β”€ PATCH
+    └── PATCH_TESTS
+

Here BASEis original tests, PATCH is the ported test, and DIFF is the coverage difference on EVMONE. Open evmtest_coverage/coverage/DIFF/index.html in browser:

+

Annotated coverage

+ + + + + + + + + + + + + + + + + + + + + + + + + +
LabelDescription
LBCLost base coverage: Code that was tested before, but is untested now.
UBCUncovered baseline code: Code that was untested before and untested now.
GBCGained baseline coverage: Code that was untested before, but is tested now.
CBCCovered baseline code: Code that was tested before and is tested now.
+

Follow the hyperlinks for lost base coverage (LBC) to address coverage gaps. Here is an example coverage loss:

+

Missing original coverage

+
+

Lost line coverage from a coverage report. In this case, caused by a missing invocation of CALLDATALOAD.

+ + +
+
Expected coverage loss
+
+

EEST uses pytest, a popular Python testing framework, to help orchestrate testing Ethereum specifications, while original tests relied on large, static contracts and the EVM to handle much of the execution. This difference can lead to coverage gaps. EEST favors dynamic contract creation for each test vector, while original tests preferred a single static contract with multiple test vectors determined by transaction input data.

+

It’s important to note that coverage helps identify missing test paths. If you believe the coverage loss is due to differences in “setup” code between frameworks and doesn’t impact the feature you’re testing, explain this in your PR. A team member can help with the review.

+

For example, review the discussion in this PR to see an example of why and how coverage loss can occur.

+ +
+
+

Resolving Coverage Gaps from Yul Compilation

+

When porting tests from ethereum/tests, you may encounter coverage gaps that are false positives. This commonly occurs because:

+
    +
  • Original tests often used Yul to define smart contracts, and solc compilation introduces additional opcodes that aren’t specifically under test
  • +
  • EEST ports use the explicit EEST Opcode mini-language, which is more precise in opcode definition
  • +
+

If coverage analysis shows missing opcodes that were only present due to Yul compilation artifacts (not the actual feature being tested), this can be resolved during PR review by adding the coverage_missed_reason parameter:

+
@pytest.mark.ported_from(
+    ["path/to/original_test.json"],
+    coverage_missed_reason="Missing opcodes are Yul compilation artifacts, not part of tested feature"
+)
+
+ +
+
Add coverage_missed_reason only after PR review
+
+ Only add coverage_missed_reason after PR review determines the coverage gap is acceptable, never preemptively. This helps maintain test coverage integrity while accounting for legitimate differences between Yul-based and EEST opcode-based implementations. +
+
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/post_mortems/index.html b/docs/public/main/post_mortems/index.html new file mode 100644 index 00000000000..56805d2a46c --- /dev/null +++ b/docs/public/main/post_mortems/index.html @@ -0,0 +1,1465 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

Post-Mortems of Missed Test Scenarios

+

This page contains a collection of post-mortem analyses for test cases that were not initially identified by the testing process.

+

The objective is to document and learn from missed scenarios β€” including those that were caught on the client side due to consensus issue, client developer raised issues, external reviewers, or external bug bounties β€” in order to improve test coverage and reduce the likelihood of similar omissions in the future.

+

Each entry must include an explanation of why the test case was missed plus the changes that were implemented in documentation or framework to improve the testing process.

+

List

+

TEMPLATE

+

Date - Title - Fork

+

Description

+

Provide a concise summary of the issue, how it was discovered, emphasizing the how it relates to the specifications and testing.

+

Example:

+
+

A consensus-breaking issue was found during the bug-bounty phase of the Pectra fork specifically in the EIP-2537, which involved calling the BLS pairing precompile using two special points: the infinity point and a point that is outside of the BLS12-381 curve. +The specification correctly specified the behavior of the precompile when one of these inputs was used, but it did not specify the behavior of the combined input.

+

Root Cause Analysis

+

Explain why this scenario was not covered by the test suite. Consider whether it was due to ambiguous specification wording, gaps in test generation logic, overlooked edge cases, or incorrect assumptions about expected behavior.

+

Consider prompting questions:

+
    +
  • Was the behavior implied but not explicitly stated in the specification?
  • +
  • Was the area considered low-risk or assumed covered elsewhere?
  • +
  • Were there limitations in the current test generation tools or processes?
  • +
  • Was there any different type of testing that could have caught the issue at an earlier stage? (Fuzzing, property based testing)
  • +
+

Steps Taken To Avoid Recurrence

+

List the actions taken to reduce the chance of this type of miss happening again. E.g. procedure changes, checklist updates, review practices, framework improvements.

+

Implemented Test Case

+

IDs of the tests added that now cover the missed scenario and link to the documentation page where they are included.

+

Example:

+ +

Framework/Documentation Changes

+

Note any modifications that were introduced in the framework and/or documentation to prevent similar misses.

+

Example:

+
    +
  • Updated EIP checklist to include testing combinations of interesting points related to the elliptic-curve under test, and all combinations between them.
  • +
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/precommit/index.html b/docs/public/main/precommit/index.html new file mode 100644 index 00000000000..65396a6b5bc --- /dev/null +++ b/docs/public/main/precommit/index.html @@ -0,0 +1,1342 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

Enabling Pre-Commit Checks

+

There’s a pre-commit config file available in the repository root (.pre-commit-config.yaml) that can be used to enable automatic checks upon commit - the commit will not go through if the checks don’t pass.

+

To enable pre-commit, the following must be run once:

+
uvx pre-commit install
+
+ +
+
Bypassing pre-commit checks
+
+

Enabling of pre-commit checks is not mandatory (it cannot be enforced) and even if it is enabled, it can always be bypassed with:

+
git commit --no-verify
+
+
+
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/reference_specification/index.html b/docs/public/main/reference_specification/index.html new file mode 100644 index 00000000000..71408af7a54 --- /dev/null +++ b/docs/public/main/reference_specification/index.html @@ -0,0 +1,1550 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

Referencing an EIP Spec Version

+

Tests that implement features from an Ethereum Improvement Proposal (ethereum/EIPs) must define the EIP’s markdown SHA digest within the test’s Python module. This ensures our tests stay up-to-date with any changes to the EIP specifications.

+

The check_eip_versions command-line utility automatically verifies that all EIP references in the codebase are current. It works by comparing the SHA specified in the test against the latest version in the ethereum/EIPs repository. This utility uses pytest to generate test cases for every module that includes “eip” in its path.

+

Test framework summary for a failing EIP spec version test

+ + +
+
The SHA digest value is provided in the failure message of the corresponding test
+
+ EIP spec version test fail +
+
+ + +
+
Understanding and Retrieving the EIP Markdown’s SHA Digest
+
+

The SHA value is the output from git’s hash-object command, for example:

+
git clone git@github.com:ethereum/EIPs
+git hash-object EIPS/EIPS/eip-3651.md
+# output: d94c694c6f12291bb6626669c3e8587eef3adff1
+

and can be retrieved from the remote repo via the Github API on the command-line as following:

+
sudo apt install jq
+curl -s -H "Accept: application/vnd.github.v3+json" \
+https://api.github.com/repos/ethereum/EIPs/contents/EIPS/eip-3651.md |\
+jq -r '.sha'
+# output: d94c694c6f12291bb6626669c3e8587eef3adff1
+
+
+
+

How to Add a Spec Version Check

+

This check accomplished by adding the following two global variables anywhere in the Python source file:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Variable NameExplanation
REFERENCE_SPEC_GIT_PATHThe relative path of the EIP markdown file in the ethereum/EIPs repository, e.g. “EIPS/eip-1234.md
REFERENCE_SPEC_VERSIONThe SHA hash of the latest version of the file retrieved from the Github API: https://api.github.com/repos/ethereum/EIPs/contents/EIPS/eip-<EIP Number>.md
+ + +

Running the check_eip_versions Command Locally

+

A Github Personal Access Token (PAT) is required to avoid rate-limiting issues when using the Github API. The token can be specified via an environment variable or via the command-line. For example, the Github CLI can be used to obtain a token:

+
uv run check_eip_versions --github-token=$(gh auth token)
+

or a PAT can be created at: https://github.com/settings/personal-access-tokens/new.

+

By default, only tests up to and including the current fork under development will be checked. This is controlled by the UNTIL_FORK setting in the src/config/check_eip_versions.py configuration file. You can also pass a specific test path to limit the scope:

+
uv run check_eip_versions --github-token=$(gh auth token) tests/shanghai/eip3651_warm_coinbase/
+

This would only check EIP versions for the EIP-3651 tests in the shanghai/eip3651_warm_coinbase sub-directory.

+

Automated Checks via GitHub Actions

+

The repository includes a GitHub Actions workflow that automatically runs check_eip_versions on a daily schedule. If any outdated EIP references are detected, the workflow creates an issue in the repository with details about which references need to be updated.

+

This workflow uses GitHub’s built-in token for authentication, so there’s no need to configure personal access tokens for the automated checks. The issue will include links to the relevant workflow run and details about which tests need updating.

+

Example

+

Here is an example from ./tests/shanghai/eip3651_warm_coinbase/test_warm_coinbase.py:

+
REFERENCE_SPEC_GIT_PATH = "EIPS/eip-3651.md"
+REFERENCE_SPEC_VERSION = "d94c694c6f12291bb6626669c3e8587eef3adff1"
+

While the code uses variable names the shown constants can be found in spec.py. The SHA digest was retrieved from here.

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/releases/index.html b/docs/public/main/releases/index.html new file mode 100644 index 00000000000..5193041e4a7 --- /dev/null +++ b/docs/public/main/releases/index.html @@ -0,0 +1,1497 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

EEST Fixture Releases

+

Formats and Release Layout

+

@ethereum/execution-spec-tests releases contain JSON test fixtures in various formats. Note that transaction type tests are executed directly from Python source using the execute command.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FormatConsumed by the clientLocation in .tar.gz release
State Tests- directly via a statetest-like command
(e.g., go-ethereum/cmd/evm/staterunner.go)
./fixtures/state_tests/
Blockchain Tests- directly via a blocktest-like command
(e.g., go-ethereum/cmd/evm/blockrunner.go)
- using the RLPeest/consume-rlp Simulator via block import
./fixtures/blockchain_tests/
Blockchain Engine Tests- using the eest/consume-engine Simulator and the Engine API./fixtures/blockchain_tests_engine/
Transaction Tests- using a new simulator coming soonNone; executed directly from Python source,
using a release tag
Blob Transaction Tests- using the eest/execute-blobs Simulator andNone; executed directly from Python source,
using a release tag
+

Release URLs and Tarballs

+

Versioning Scheme

+

EEST framework and test sources and fixture releases are tagged use a semantic versioning scheme, <optional:<pre_release_name@>>v<MAJOR>.<MINOR>.<PATCH> as following:

+
    +
  • <MAJOR>: An existing fixture format has changed (potentially breaking change). Action must be taken by client teams to ensure smooth upgrade to the new format.
  • +
  • <MINOR>: Additional coverage (new tests, or a new format) have been added to the release.
  • +
  • <PATCH>: A bug-fix release; an error in the tests or framework has been patched.
  • +
+

Please see below for an explanation of the optional <pre_release_name> that is used in pre-releases.

+

Standard Releases

+

Releases are published on the @ethereum/execution-spec-tests releases page. Standard releases are tagged using the format vX.Y.Z (they don’t have a <pre_release_name>).

+

For standard releases, two tarballs are available:

+ + + + + + + + + + + + + + + + + +
Release ArtifactFork/feature scope
fixtures_stable.tar.gzTests for all forks up to and including the last deployed (“stable”) mainnet fork (“must pass”)
fixtures_develop.tar.gzTests for all forks up to and including the last development fork
+

I.e., fixtures_develop are a superset of fixtures_stable.

+

Pre-Release and Devnet Releases

+

Intermediate releases that target specific subsets of features or tests under active development are published at @ethereum/execution-spec-tests releases.

+

These releases are tagged using the format <pre_release_name>@vX.Y.Z.

+

Examples:

+ +

Devnet releases should be treated as WIP and may not yet contain full test coverage (or even coverage for all EIPs). The coverage provided by these releases is detailed in the corresponding release notes.

+

Help Downloading Releases

+

The consume cache command can be used to resolve EEST release and pre-release tags to release URLs and download them.

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/remote/index.html b/docs/public/main/remote/index.html new file mode 100644 index 00000000000..26da2da7c72 --- /dev/null +++ b/docs/public/main/remote/index.html @@ -0,0 +1,1246 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

Running Test on a Live Remote Network

+

Tests can be executed on a live remote network by running the execute remote command.

+

The command requires the --fork flag which must match the fork that is currently active in the network (fork transition tests are not supported yet).

+

The execute remote command requires to be pointed to an RPC endpoint of a client that is connected to the network, which can be specified by using the --rpc-endpoint flag:

+
uv run execute remote --fork=Prague --rpc-endpoint=https://rpc.endpoint.io
+

Another requirement is that the command is provided with a seed account that has funds available in the network to deploy contracts and fund accounts. This can be done by setting the --rpc-seed-key flag:

+
uv run execute remote --fork=Prague --rpc-endpoint=https://rpc.endpoint.io --rpc-seed-key 0x000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
+

The value needs to be a private key that is used to sign the transactions that deploy the contracts and fund the accounts.

+

One last requirement is that the --rpc-chain-id flag is set to the chain id of the network that is being tested:

+
uv run execute remote --fork=Prague --rpc-endpoint=https://rpc.endpoint.io --rpc-seed-key 0x000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f --rpc-chain-id 12345
+

The execute remote command will connect to the client via the RPC endpoint and will start executing every test in the ./tests folder in the same way as the execute hive command, but instead of using the Engine API to generate blocks, it will send the transactions to the client via the RPC endpoint.

+

It is recommended to only run a subset of the tests when executing on a live network. To do so, a path to a specific test can be provided to the command:

+
uv run execute remote --fork=Prague --rpc-endpoint=https://rpc.endpoint.io --rpc-seed-key 0x000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f --rpc-chain-id 12345 ./tests/prague/eip7702_set_code_tx/test_set_code_txs.py::test_set_code_to_sstore
+

execute Command Test Execution

+

The execute remote and execute hive commands first creates a random sender account from which all required test accounts will be deployed and funded, and this account is funded by sweeping (by default) this “seed” account.

+

The sweep amount can be configured by setting the --seed-account-sweep-amount flag:

+
--seed-account-sweep-amount "1000 ether"
+

Once the sender account is funded, the command will start executing tests one by one by sending the transactions from this account to the network.

+

Test transactions are not sent from the main sender account though, they are sent from a different unique account that is created for each test (accounts returned by pre.fund_eoa).

+

Use with Parallel Execution

+

If the execute is run using the -n=N flag (respectively --sim-parallelism=N), n>1, the tests will be executed in parallel, and each process will have its own separate sender account, so the amount that is swept from the seed account is divided by the number of processes, and this has to be taken into account when setting the sweep amount and also when funding the seed account.

+

After finishing each test the command will check the remaining balance of all accounts and will attempt to recover the funds back to the sender account, and at the end of all tests, the remaining balance of the sender account will be swept back to the seed account.

+

There are instances where it will be impossible to recover the funds back from a test, for example, funds that are sent to a contract that has no built-in way to send them back, the funds will be stuck in the contract and they will not be recoverable.

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/repository_overview/index.html b/docs/public/main/repository_overview/index.html new file mode 100644 index 00000000000..7ba73ee38c7 --- /dev/null +++ b/docs/public/main/repository_overview/index.html @@ -0,0 +1,1317 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+
+

Repository Overview

+

The most relevant folders and files in the repo are:

+
πŸ“ execution-test-specs/
+β”œβ”€β•΄πŸ“ tests/                     # test cases
+β”‚   β”œβ”€β”€ πŸ“ eips/
+β”‚   β”œβ”€β”€ πŸ“ vm/
+β”‚   └── πŸ“ ...
+β”œβ”€β•΄πŸ“ fixtures/                  # default fixture output dir
+β”‚   β”œβ”€β”€ πŸ“ blockchain_tests/
+β”‚   β”œβ”€β”€ πŸ“ blockchain_tests_engine/
+β”‚   β”œβ”€β”€ πŸ“ state_tests/
+β”‚   └── πŸ“ ...
+β”œβ”€β•΄πŸ“ src/                       # library & framework packages
+β”‚   β”œβ”€β”€ πŸ“ ethereum_test_fork/
+β”‚   β”œβ”€β”€ πŸ“ ethereum_test_tools/
+β”‚   └── πŸ“ ...
+β”œβ”€β•΄πŸ“ docs/                      # markdown documentation
+β”‚   β”œβ”€β”€ πŸ“ getting_started
+β”‚   β”œβ”€β”€ πŸ“ dev
+β”‚   └── πŸ“ ...
+β”œβ”€β•΄πŸ“ .vscode/                   # visual studio code config
+β”‚   β”œβ”€β”€ πŸ“„ settings.recommended.json # copy to settings.json
+β”‚   β”œβ”€β”€ πŸ“„ launch.recommended.json
+β”‚   └── πŸ“„ extensions.json
+└── πŸ“„ whitelist.txt             # spellcheck dictionary
+

tests/

+

Contains the implementation of the Ethereum consensus tests available in this repository.

+

src/

+

Contains various packages that help to define test cases and to interface with the evm t8n command. Additionally, it contains some packages that enable test case execution by customizing pytest which acts as the test framework.

+

docs/

+

Contains documentation configuration and source files.

+

.vscode/

+

See VS Code Setup.

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/running/index.html b/docs/public/main/running/index.html new file mode 100644 index 00000000000..bf1ba9b6a8a --- /dev/null +++ b/docs/public/main/running/index.html @@ -0,0 +1,1650 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

Methods of Running Tests

+

EEST has two commands, consume and execute, that run test cases against EL clients:

+
    +
  1. consume runs JSON test fixtures against a client - the client is said to “consume” the test case fixture.
  2. +
  3. execute runs test cases from Python source against a client - the test case is “executed” against the client.
  4. +
+

Top-Level Comparison

+

Both consume and execute provide sub-commands which correspond to different methods of testing EL clients using EEST test cases:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CommandDescriptionComponents testedEnvironmentScope
consume directClient consume tests via a statetest interfaceEVMNoneModule test
consume directClient consume tests via a blocktest interfaceEVM, block processingNoneModule test,
Integration test
consume engineClient imports blocks via Engine API EngineNewPayload in HiveEVM, block processing, Engine APIStaging, HiveSystem test
consume rlpClient imports RLP-encoded blocks upon start-up in HiveEVM, block processing, RLP import (sync*)Staging, HiveSystem test
execute hiveTests executed against a client via JSON RPC eth_sendRawTransaction in HiveEVM, JSON RPC, mempoolStaging, HiveSystem test
execute remoteTests executed against a client via JSON RPC eth_sendRawTransaction on a live networkEVM, JSON RPC, mempool, EL-EL/EL-CL interaction (indirectly)ProductionSystem Test
+

*sync: Depending on code paths used in the client implementation, see the RLP vs Engine Simulator section below.

+

The following sections describe the different methods in more detail.

+ + +
+
./hive --sim=eest/consume-engine vs consume engine
+
+ EEST simulators can be ran either standalone using the ./hive command or via an EEST command against a ./hive --dev backend, more details are provided below. +
+
+

Direct

+ + + + + + + + + + + + + + + + + + + + + +
Nomenclature
Commandconsume direct
SimulatorNone
Fixture Formatsstate_test,
blockchain_test
+

The direct method provides the fastest way to test EVM functionality by executing tests directly through a client’s dedicated test interface (e.g. statetest or blocktest). This method requires clients to implement a custom interface to read tests and pass their inputs through appropriate code paths; implementation guides available for state tests and blockchain tests.

+

The EEST consume direct command is a small wrapper around client direct interfaces that allows fast and easy selection of test subsets to execute via test ID regex match (thanks to an index file). See Consume Direct and the Cache and Fixture Inputs and Useful Pytest Options pages for help with options.

+ + +
+
Rapid EVM development
+
+ The direct method with the StateTest format should be used for the fastest EVM development feedback loop. Additionally, EVM traces can be readily generated and compared to other implementations. +
+
+

Engine

+ + + + + + + + + + + + + + + + + + + + + +
Nomenclature
Commandconsume engine
Simulatoreest/consume-engine
Fixture formatblockchain_test_engine
+

The consume engine method tests execution clients via the Engine API by sending block payloads and verifying the response (post-merge forks only). This method provides the most realistic testing environment for production Ethereum client behavior, covering consensus integration, payload validation, and state synchronization.

+

The consume engine command:

+
    +
  1. Initializes the execution client with genesis state.
  2. +
  3. Connects via Engine API (port 8551), primitively mocking a consensus client.
  4. +
  5. Sends a forkchoice update to establish the chain head.
  6. +
  7. Submits payloads using engine_newPayload calls.
  8. +
  9. Validates responses against expected results.
  10. +
  11. Tests error conditions and exception handling.
  12. +
+

RLP

+ + + + + + + + + + + + + + + + + + + + + +
Nomenclature
Commandconsume rlp
Simulatoreest/consume-rlp
Fixture formatblockchain_test
+

The RLP consumption method tests execution clients by providing them with RLP-encoded blocks to load upon startup, similar to the block import process during historical synchronization. This method tests the client’s core block processing logic without the overhead of network protocols.

+

The consume rlp command:

+
    +
  1. Reads blockchain test fixtures from the specified input source.
  2. +
  3. Extracts RLP-encoded blocks from the fixture files.
  4. +
  5. Copies blocks to the client’s container via files in the /blocks/ directory.
  6. +
  7. Starts the client with the genesis state and block files.
  8. +
  9. Validates the client’s final blockHash via JSON RPC against the test’s expectations.
  10. +
+

This method simulates how clients import blocks during historical sync, testing the complete block validation and state transition pipeline, see below for more details and a comparison to consumption via the Engine API.

+

Engine vs RLP Simulator

+

The RLP Simulator (eest/consume-rlp) and the Engine Simulator (eest/consume-engine) should be seen as complimentary to one another. Although they execute the same underlying EVM test cases, the block validation logic is executed via different client code paths (using different fixture formats). Therefore, ideally, both simulators should be executed for full coverage.

+

Code Path Choices

+

Clients consume fixtures in the eest/consume-engine simulator via the Engine API’s EngineNewPayloadv* endpoint; a natural way to validate, respectively invalidate, block payloads. In this case, there is no flexibility in the choice of code path - it directly harnesses mainnet client functionality. The eest/consume-rlp Simulator, however, allows clients more freedom, as the rlp-encoded blocks are imported upon client startup. Clients are recommended to try and hook the block import into the code path used for historical syncing.

+

Differences

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
eest/consume-rlpeest/consume-engine
Fixture Format UsedBlockchainTestBlockchainTestEngine
Fork supportAll forks (including pre-merge)Post-merge forks only (Paris+)
Client code pathHistorical sync / block import pipelineEngine API / consensus integration
Real-world analogyBlocks received during syncBlocks received from consensus client
InterfaceBlock import upon start-up via RLP filesEngine API calls (newPayload, forkchoiceUpdated)
Exception testingBasic exception handlingAdvanced exception verification with client-specific mappers
+ + +
+
Running both simulators adds some redundancy that can assist test debugging
+
+ If Engine tests fail but RLP tests pass, the issue is likely in your Engine API implementation rather than core EVM logic. +
+
+

Execute

+

See Execute Command.

+

Two Methods to Run EEST Simulators

+

Many of the methods use the Hive Testing Environment to interact with clients and run tests against them. These methods are also called Hive simulators. While Hive is always necessary to run simulators, they can be called in two different ways. Both of these commands execute the same simulator code, but in different environments, we take the example of the eest/consume-engine simulator:

+
    +
  1. ./hive --sim=eest/consume-engine is a standalone command that installs EEST and the consume command in a dockerized container managed by Hive. This is the standard method to execute EEST fixture releases against clients in CI environments and is the method to generate the results at hive.ethpandaops.io. See Hive and its Common Options for help with this method.
  2. +
  3. uv run consume engine requires the user to clone and install EEST and start a Hive server in development mode. In this case, the simulator runs on the native system and communicate to the client via the Hive API. This is particularly useful during test development as fixtures on the local disk can be specified via --input=fixtures/. As the simulator runs natively, it is easy to drop into a debugger and inspect the simulator or client container state. See Hive Developer Mode for help with this method.
  4. +
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/running_tests/consume/cache/index.html b/docs/public/main/running_tests/consume/cache/index.html new file mode 100644 index 00000000000..5c32406d300 --- /dev/null +++ b/docs/public/main/running_tests/consume/cache/index.html @@ -0,0 +1,1364 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

+
+ +
+

Consume Cache and Fixture Inputs

+

The consume cache command can be used to resolve, download and cache fixture releases:

+
consume cache --input=stable@v4.5.0
+

All consume subcommands have an --input argument, which implements the same functionality as consume cache to download and cache fixtures, respectively obtain downloaded fixtures from the cache.

+

Example: Two-liner to Download the Latest Fixture Release

+

Releases can be downloaded using EEST tooling without (manually) cloning and installing the @ethereum/execution-spec-tests tools as following:

+
    +
  1. +

    Install uv (a fast, rust-based Python package manager):

    +
    curl -LsSf https://astral.sh/uv/install.sh | sh
    +
  2. +
  3. +

    Run EEST’s consume cache command via uv and request the latest “stable” fixture release:

    +
    uvx --from git+https://github.com/ethereum/execution-spec-tests \
    +    consume cache --input=stable@latest
    +

    Expected output, as of v4.5.0:

    +
    Updated https://github.com/ethereum/execution-spec-tests (8c3cbd7a4eef3967abd78db32ee45ef8f7cf8271)
    +Updated https://github.com/petertdavies/ethereum-spec-evm-resolver (623ac4565025e72b65f45b926da2a3552041b469)
    +Built ethereum-execution-spec-tests @ git+https://github.com/ethereum/execution-spec-tests@8c3cbd7a4eef3967abd78db32ee45ef8f7cf8271
    +
    +Installed 69 packages in 10ms
    +Exit: Fixtures downloaded and cached.
    +Path: /home/dtopz/.cache/ethereum-execution-spec-tests/cached_downloads/ethereum/execution-spec-tests/v4.5.0/fixtures_stable/fixtures
    +Input: https://github.com/ethereum/execution-spec-tests/releases/download/v4.5.0/fixtures_stable.tar.gz
    +Release page: https://github.com/ethereum/execution-spec-tests/releases/tag/v4.5.0
    +

    Note: Use direct URLs to avoid GitHub API calls (better for CI environments). Version specifiers like stable@latest will always use the GitHub API to resolve versions. More details on the arguments to --input are provided below.

    +

    Explanation: uv creates a local Python virtual environment in ~/.cache/uv/, installs EEST and executes the consume cache command to resolve and download the release, which gets cached at ~/.cache/ethereum-execution-spec-tests. Subsequent commands will use the cached version of the fixtures.

    +
  4. +
+

The --input Flag to Specify Fixtures

+

All consume sub-commands take an --input=<fixture_path>|<release_spec>|<url> flag to specify which fixtures should be used for the command, <fixtures> may be:

+
    +
  1. A local directory: Fixtures from your local file system.
  2. +
  3. A release specification: An EEST release tag or “release specification” stable@latest, fusaka-devnet-1@v1.0.0, etc.
  4. +
  5. A URLs: A full URL to a custom hosted release or a Github release.
  6. +
+

Release Specifications

+

A release specification has the format <release_name>@<version>.

+

Supported release names:

+
    +
  • stable: Latest stable fork release.
  • +
  • develop: Latest development fork release.
  • +
  • Custom release names: e.g., pectra-devnet-4, eip7692.
  • +
+

Supported version formats:

+
    +
  • latest: Most recent release for the specified name.
  • +
  • v1.2.3: Specific semantic version.
  • +
+

Examples

+

Examples using a release specification:

+
# Latest standard, full stable release (all forks up to and including the latest deployed mainnet fork)
+uv run consume engine --input stable@latest
+
+# Latest standard, full development release (all forks up to and including the latest development fork)
+uv run consume rlp --input develop@latest
+
+# Standard, full releases by tag
+uv run consume engine --input stable@v4.1.0
+uv run consume rlp --input develop@v4.2.1
+
+# Pre-release tags
+uv run consume cache --input pectra-devnet-6@v1.0.0
+uv run consume direct --input eip7692@latest --bin ../go-ethereum/build/bin/evm
+

Examples using a URL, the target must be a .tar.gz:

+
# GitHub release URL
+uv run consume engine --input https://github.com/ethereum/execution-spec-tests/releases/download/v4.1.0/fixtures_develop.tar.gz
+
+# Direct archive URL
+uv run consume rlp --input https://example.com/custom-fixtures.tar.gz
+

Caching System

+

Automatic Caching

+

All remote fixture sources are automatically cached to avoid repeated downloads:

+

Default cache location:

+
~/.cache/ethereum-execution-spec-tests/cached_downloads/
+

You can override this location with the --cache-folder flag:

+
uv run consume cache --input stable@latest --cache-folder /path/to/custom/cache
+

Cache structure:

+
❯ tree ~/.cache/ethereum-execution-spec-tests/ -L 5
+/home/dtopz/.cache/ethereum-execution-spec-tests/
+β”œβ”€β”€ cached_downloads
+β”‚Β Β  β”œβ”€β”€ ethereum
+β”‚Β Β  β”‚Β Β  └── execution-spec-tests
+β”‚Β Β  β”‚Β Β      β”œβ”€β”€ pectra-devnet-5%40v1.0.0
+β”‚Β Β  β”‚Β Β      β”‚Β Β  └── fixtures_pectra-devnet-5
+β”‚Β Β  β”‚Β Β      β”œβ”€β”€ pectra-devnet-6%40v1.0.0
+β”‚Β Β  β”‚Β Β      β”‚Β Β  └── fixtures_pectra-devnet-6
+β”‚Β Β  β”‚Β Β      β”œβ”€β”€ v4.0.0
+β”‚Β Β  β”‚Β Β      β”‚Β Β  └── fixtures_develop
+β”‚Β Β  β”‚Β Β      β”œβ”€β”€ v4.1.0
+β”‚Β Β  β”‚Β Β      β”‚Β Β  └── fixtures_develop
+β”‚Β Β  β”‚Β Β      β”œβ”€β”€ v4.2.0
+β”‚Β Β  β”‚Β Β      β”‚Β Β  β”œβ”€β”€ fixtures_develop
+β”‚Β Β  β”‚Β Β      β”‚Β Β  β”œβ”€β”€ fixtures_eip7692
+β”‚Β Β  β”‚Β Β      β”‚Β Β  └── fixtures_stable
+β”‚Β Β  β”‚Β Β      β”œβ”€β”€ v4.3.0
+β”‚Β Β  β”‚Β Β      β”‚Β Β  └── fixtures_develop
+β”‚Β Β  β”‚Β Β      └── v4.5.0
+β”‚Β Β  β”‚Β Β          └── fixtures_stable
+β”‚Β Β  └── other
+└── release_information.json
+

The Fixture Index File

+

The fill command generates a JSON file <fixture_path>/.meta/index.json that indexes the fixtures its generated. This index file is used by consume commands to allow fast collection of test subsets specified on the command-line, for example, via the --sim.limit flag. For help with --sim.limit when running ./hive, see Hive Common Options, for an overview of other available test selection flags when running consume directly, see Useful Pytest Options.

+

CI-Friendly Behavior for Direct URLs

+

When using direct GitHub release URLs (instead of version specifiers), the consume command automatically avoids unnecessary GitHub API calls to prevent rate limiting in CI environments:

+
consume cache --input=https://github.com/ethereum/execution-spec-tests/releases/download/v4.5.0/fixtures_stable.tar.gz
+

API Call Behavior:

+
    +
  • βœ… Direct URLs: No API calls made, cleaner output (no “Release page:” line).
  • +
  • ℹ️ Version specifiers: API calls required to resolve versions, includes release page info.
  • +
+

Examples:

+
# No API calls - direct download
+consume cache --input=https://github.com/ethereum/execution-spec-tests/releases/download/v4.5.0/fixtures_stable.tar.gz
+
+# API calls required - version resolution  
+consume cache --input=stable@latest
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/running_tests/consume/direct/index.html b/docs/public/main/running_tests/consume/direct/index.html new file mode 100644 index 00000000000..b51b4d06f5d --- /dev/null +++ b/docs/public/main/running_tests/consume/direct/index.html @@ -0,0 +1,1291 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

+
+ +
+

The consume direct Command

+

The direct method provides the fastest way to test EVM functionality by executing tests directly through a client’s dedicated test interface (e.g. statetest or blocktest).

+
uv run consume direct --bin=<evm-binary> [OPTIONS]
+
    +
  • --bin EVM_BIN: Path to an evm executable that can process StateTestFixture and/or BlockTestFixture formats.
  • +
  • --traces: Collect execution traces from the evm executable.
  • +
+ + +
+
Limited Client Support
+
+

Currently, only the following clients can be used with consume direct:

+
    +
  • go-ethereum statetest and blocktest.
  • +
  • Nethermind nethtest.
  • +
+
+
+

Advantages

+
    +
  • Speed: Fastest test execution method.
  • +
  • Simplicity: No container or network overhead.
  • +
  • Debugging: Easy access to traces and logs.
  • +
+

Limitations

+
    +
  • Limited client support: Only go-ethereum and Nethermind.
  • +
  • Module scope: Tests EVM, respectively block import, in isolation, not full client behavior.
  • +
  • Interface dependency: Requires client-specific test interfaces.
  • +
+

Example Usage

+

Only run state tests (by using a mark filter, -m) from a local fixtures folder with go-ethereum:

+
uv run consume direct --input ./fixtures -m state_test --bin=evm
+

or Nethermind:

+
uv run consume direct --input ./fixtures -m state_test --bin=nethtest
+

Run fixtures in the blockchain test format for the Prague fork:

+
uv run consume direct --input ./fixtures -m "blockchain_test and Prague" --bin=evm
+

Test selection via a regular expression match on collected fixture IDs:

+
uv run consume direct --input ./fixtures --sim.limit ".*push0.*"
+

Test selection via pytest keyword expression match:

+
uv run consume direct --input ./fixtures -k "eip3855 or Prague"
+

Use --collect-only -q to get a list of available test fixture IDs:

+
uv run consume direct --input ./fixtures -k "eip3855 or Prague" --collect-only -q
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/running_tests/consume/exceptions/index.html b/docs/public/main/running_tests/consume/exceptions/index.html new file mode 100644 index 00000000000..7beedade639 --- /dev/null +++ b/docs/public/main/running_tests/consume/exceptions/index.html @@ -0,0 +1,1348 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

+
+ +
+

Exception Tests

+

Overview

+

Exception tests validate that clients correctly reject invalid blocks and transactions with appropriate error messages. The Engine simulator provides advanced exception verification using client-specific mappers to handle varying error message formats across different clients.

+

How Exception Testing Works

+
    +
  1. Test fixtures specify expected exceptions - Each test defines what error should occur
  2. +
  3. Clients reject invalid payloads - Via Engine API or block import
  4. +
  5. Exception mappers translate errors - Client-specific error messages are normalized
  6. +
  7. Test framework validates - Ensures the correct exception type was raised
  8. +
+

Client Exception Mappers

+

Each client has unique error message formats. EEST maintains exception mappers that translate client-specific errors to standardized exception types.

+

Mapper Location

+

Exception mappers are defined in the EEST codebase:

+
    +
  • src/ethereum_clis/clis/<client>.py (e.g., geth.py, besu.py, nethermind.py)
  • +
+

Example Mapper Structure

+
# Simplified example
+GETH_EXCEPTIONS = {
+    "invalid block: gas limit reached": ExceptionType.GAS_LIMIT_EXCEEDED,
+    "block gas cost exceeds gas limit": ExceptionType.GAS_LIMIT_EXCEEDED,
+    "insufficient balance for transfer": ExceptionType.INSUFFICIENT_BALANCE,
+}
+

Updating Client Exception Messages

+

When clients change their error messages or you encounter unmapped exceptions:

+

1. Identify the Unmapped Exception

+

Run the test and observe the actual error message:

+
uv run consume engine -k "test_invalid_gas_limit" -v
+

Look for output like:

+
Unmapped exception from client 'go-ethereum': "block gas cost exceeds limit: have 30000001, limit 30000000"
+

2. Update the Exception Mapper

+

Edit the client’s exception mapper in src/ethereum_clis/clis/<client>.py:

+
# In src/ethereum_clis/clis/geth.py
+class GethCLI(TransitionTool):
+    exception_map = {
+        # Existing mappings...
+        "block gas cost exceeds limit": ExceptionType.GAS_LIMIT_EXCEEDED,  # New mapping
+    }
+

3. Test the Update

+

Re-run the test to verify the exception is now properly mapped:

+
uv run consume engine -k "test_invalid_gas_limit" --disable-strict-exception-matching=false
+

4. Submit Changes

+

Create a pull request with:

+
    +
  • Updated exception mappings
  • +
  • Test results showing the fix
  • +
  • Any relevant client version information
  • +
+

Disabling Strict Exception Matching

+

For development or when exception mappings are incomplete:

+
# Disable for specific clients
+uv run consume engine --disable-strict-exception-matching=nimbus,besu
+
+# Via Hive
+./hive --sim ethereum/eest/consume-engine \
+  --sim.disable-strict-exception-matching=nimbus
+
+ +
+
Production Testing
+
+ Always enable strict exception matching for production test runs to ensure clients properly validate consensus rules. +
+
+

Debugging Exception Test Failures

+

Check Client Logs

+

Enable verbose client output:

+
./hive --sim ethereum/eest/consume-engine \
+  --docker.output \
+  --sim.loglevel 5
+

Verify Exception Type

+

Ensure the test expects the correct exception:

+
# In test file
+post = {
+    address: Account(
+        balance=0,
+        storage={},
+        exception=TransactionException.INSUFFICIENT_BALANCE  # Expected exception
+    )
+}
+

Test Without Exceptions

+

Temporarily modify the test to see what happens without the invalid condition:

+
# Run specific test in isolation
+uv run consume engine -k "test_name_without_invalid"
+

Contributing Exception Mappings

+

When contributing new exception mappings:

+
    +
  1. Document the client version - Exception messages may change between versions
  2. +
  3. Use regex patterns - For flexible matching: r"gas limit.*exceeded"
  4. +
  5. Test multiple scenarios - Ensure the pattern doesn’t over-match
  6. +
  7. Add comments - Explain non-obvious mappings
  8. +
+

Example contribution:

+
# Besu v24.1.0+ changed gas limit error format
+BESU_EXCEPTIONS = {
+    # Old format (pre-24.1.0)
+    "Transaction gas limit exceeds block gas limit": ExceptionType.GAS_LIMIT_EXCEEDED,
+    # New format (24.1.0+)
+    r"block gas limit \(\d+\) exceeded by transaction": ExceptionType.GAS_LIMIT_EXCEEDED,
+}
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/running_tests/consume/index.html b/docs/public/main/running_tests/consume/index.html new file mode 100644 index 00000000000..6d10d291798 --- /dev/null +++ b/docs/public/main/running_tests/consume/index.html @@ -0,0 +1,727 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
+ + + + +
+
+

+
+ + +
+

The consume Command

+

The EEST consume command implements different methods to run EEST-generated test fixtures against clients:

+
uv run consume [OPTIONS] SUBCOMMAND [ARGS]...
+

For help with installation, see Installation.

+

This section provides help for running the EEST commands directly (as opposed to running as a ./hive standalone command, where applicable) see:

+
    +
  1. +

    Consume Cache & Fixture Inputs for how to specify consume fixture input.

    +
  2. +
  3. +

    Consume Direct to run test fixtures against direct client interfaces.

    +
  4. +
  5. +

    Consume Simulators for help with Hive Simulators.

    +
  6. +
+
+
+
+
+
+ +
+ + + + + + + diff --git a/docs/public/main/running_tests/consume/main/index.html b/docs/public/main/running_tests/consume/main/index.html new file mode 100644 index 00000000000..73d9139ee74 --- /dev/null +++ b/docs/public/main/running_tests/consume/main/index.html @@ -0,0 +1,1263 @@ + + + + + + + Consume - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

Consume

+
+ +
+

The consume Command

+

The EEST consume command implements different methods to run EEST-generated test fixtures against clients:

+
uv run consume [OPTIONS] SUBCOMMAND [ARGS]...
+

For help with installation, see Installation.

+

This section provides help for running the EEST commands directly (as opposed to running as a ./hive standalone command, where applicable) see:

+
    +
  1. +

    Consume Cache & Fixture Inputs for how to specify consume fixture input.

    +
  2. +
  3. +

    Consume Direct to run test fixtures against direct client interfaces.

    +
  4. +
  5. +

    Consume Simulators for help with Hive Simulators.

    +
  6. +
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/running_tests/consume/simulators/index.html b/docs/public/main/running_tests/consume/simulators/index.html new file mode 100644 index 00000000000..5fbfcaa3b4c --- /dev/null +++ b/docs/public/main/running_tests/consume/simulators/index.html @@ -0,0 +1,1258 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

+
+ +
+

Consume Simulators

+

The engine and rlp simulators test clients by importing blocks through different interfaces. These simulators run within the Hive testing framework to provide containerized, isolated testing environments.

+

Command Syntax

+
uv run consume <engine|rlp> [OPTIONS]
+

Relevant Information

+ +
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/running_tests/execute/hive/index.html b/docs/public/main/running_tests/execute/hive/index.html new file mode 100644 index 00000000000..663ab41267b --- /dev/null +++ b/docs/public/main/running_tests/execute/hive/index.html @@ -0,0 +1,1235 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

+
+ +
+

Executing Tests on a Hive Local Network

+

Tests can be executed on a local hive-controlled single-client network by running the execute hive command.

+

The eest/execute-blobs Simulator

+

The blob_transaction_test execute test spec sends blob transactions to a running client in order to verify its engine_getBlobsVX endpoint behavior. These tests can be run using:

+
./hive --client besu --client-file ./configs/osaka.yaml --sim ethereum/eest/execute-blobs
+

See Hive for help installing and configuring Hive.

+

Running execute tests with Hive in Dev Mode

+

This command requires hive to be running in --dev mode:

+
./hive --dev --client go-ethereum
+

This will start hive in dev mode with the single go-ethereum client available for launching tests.

+

Then the tests can be executed by setting the HIVE_SIMULATOR environment variable

+
export HIVE_SIMULATOR=http://127.0.0.1:3000
+

and running:

+
uv run execute hive --fork=Cancun
+

This will execute all available tests in the tests directory on the Cancun fork by connecting to the hive server running on http://127.0.0.1:3000 and launching a single client with the appropriate genesis file.

+

The genesis file is passed to the client with the appropriate configuration for the fork schedule, system contracts and pre-allocated seed account.

+

All tests will be executed in the same network, in the same client, and serially, but when the -n auto parameter is passed to the command, the tests can also be executed in parallel.

+

One important feature of the execute hive command is that, since there is no consensus client running in the network, the command drives the chain by the use of the Engine API to prompt the execution client to generate new blocks and include the transactions in them.

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/running_tests/execute/index.html b/docs/public/main/running_tests/execute/index.html new file mode 100644 index 00000000000..01f2e0b88a3 --- /dev/null +++ b/docs/public/main/running_tests/execute/index.html @@ -0,0 +1,720 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
+ + + + +
+
+

+
+ + +
+

Executing Tests on Local Networks or Hive

+

@ethereum/execution-spec-tests is capable of running tests on local networks or on Hive with a few considerations. The execute command runs test cases directly from the Python source (without the use of JSON fixtures).

+

See:

+
    +
  • Execute Hive for help with the execute simulator in order to run tests on a single-client local network.
  • +
  • Execute Remote for help with executing tests on a remote network such as a devnet, or even mainnet.
  • +
+

The rest of this page describes how execute works and explains its architecture.

+

The execute command and pytest plugin

+

The execute command is capable of parsing and executing all tests in the ./tests directory, collect the transactions it requires, send them to a client connected to a network, wait for the network to include them in a block and, finally, check the resulting state of the involved smart-contracts against the expected state to validate the behavior of the clients.

+

It will not check for the state of the network itself, only the state of the smart-contracts, accounts and transactions involved in the tests, so it is possible that the network becomes unstable or forks during the execution of the tests, but this will not be detected by the command.

+

The way this is achieved is by using a pytest plugin that will collect all the tests the same way as the fill plugin does, but instead of compiling the transactions and sending them as a batch to the transition tool, they are prepared and sent to the client one by one.

+

Before sending the actual test transactions to the client, the plugin uses a special pre-allocation object that collects the contracts and EOAs that are used by the tests and, instead of pre-allocating them in a dictionary as the fill plugin does, it sends transactions to deploy contracts or fund the accounts for them to be available in the network.

+

The pre-allocation object requires a seed account with funds available in the network to be able to deploy contracts and fund accounts. In the case of a live remote network, the seed account needs to be provided via a command-line parameter, but in the case of a local hive network, the seed account is automatically created and funded by the plugin via the genesis file.

+

At the end of each test, the plugin will also check the remaining balance of all accounts and will attempt to automatically recover the funds back to the seed account in order to execute the following tests.

+

Differences between the fill and execute plugins

+

The test execution with the execute plugin is different from the fill plugin in a few ways:

+

EOA and Contract Addresses

+

The fill plugin will pre-allocate all the accounts and contracts that are used in the tests, so the addresses of the accounts and contracts will be known before the tests are executed, Further more, the test contracts will start from the same address on different tests, so there are collisions on the account addresses used across different tests. This is not the case with the execute plugin, as the accounts and contracts are deployed on the fly, from sender keys that are randomly generated and therefore are different in each execution.

+

Reasoning behind the random generation of the sender keys is that one can execute the same test multiple times in the same network and the plugin will not fail because the accounts and contracts are already deployed.

+

Transactions Gas Price

+

The fill plugin will use a fixed and minimum gas price for all the transactions it uses for testing, but this is not possible with the execute plugin, as the gas price is determined by the current state of the network.

+

At the moment, the execute plugin does not query the client for the current gas price, but instead uses a fixed increment to the gas price in order to avoid the transactions to be stuck in the mempool.

+
+
+
+
+
+ +
+ + + + + + + diff --git a/docs/public/main/running_tests/execute/main/index.html b/docs/public/main/running_tests/execute/main/index.html new file mode 100644 index 00000000000..e7a3bf196c4 --- /dev/null +++ b/docs/public/main/running_tests/execute/main/index.html @@ -0,0 +1,1240 @@ + + + + + + + Execute - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

Execute

+
+ +
+

Executing Tests on Local Networks or Hive

+

@ethereum/execution-spec-tests is capable of running tests on local networks or on Hive with a few considerations. The execute command runs test cases directly from the Python source (without the use of JSON fixtures).

+

See:

+
    +
  • Execute Hive for help with the execute simulator in order to run tests on a single-client local network.
  • +
  • Execute Remote for help with executing tests on a remote network such as a devnet, or even mainnet.
  • +
+

The rest of this page describes how execute works and explains its architecture.

+

The execute command and pytest plugin

+

The execute command is capable of parsing and executing all tests in the ./tests directory, collect the transactions it requires, send them to a client connected to a network, wait for the network to include them in a block and, finally, check the resulting state of the involved smart-contracts against the expected state to validate the behavior of the clients.

+

It will not check for the state of the network itself, only the state of the smart-contracts, accounts and transactions involved in the tests, so it is possible that the network becomes unstable or forks during the execution of the tests, but this will not be detected by the command.

+

The way this is achieved is by using a pytest plugin that will collect all the tests the same way as the fill plugin does, but instead of compiling the transactions and sending them as a batch to the transition tool, they are prepared and sent to the client one by one.

+

Before sending the actual test transactions to the client, the plugin uses a special pre-allocation object that collects the contracts and EOAs that are used by the tests and, instead of pre-allocating them in a dictionary as the fill plugin does, it sends transactions to deploy contracts or fund the accounts for them to be available in the network.

+

The pre-allocation object requires a seed account with funds available in the network to be able to deploy contracts and fund accounts. In the case of a live remote network, the seed account needs to be provided via a command-line parameter, but in the case of a local hive network, the seed account is automatically created and funded by the plugin via the genesis file.

+

At the end of each test, the plugin will also check the remaining balance of all accounts and will attempt to automatically recover the funds back to the seed account in order to execute the following tests.

+

Differences between the fill and execute plugins

+

The test execution with the execute plugin is different from the fill plugin in a few ways:

+

EOA and Contract Addresses

+

The fill plugin will pre-allocate all the accounts and contracts that are used in the tests, so the addresses of the accounts and contracts will be known before the tests are executed, Further more, the test contracts will start from the same address on different tests, so there are collisions on the account addresses used across different tests. This is not the case with the execute plugin, as the accounts and contracts are deployed on the fly, from sender keys that are randomly generated and therefore are different in each execution.

+

Reasoning behind the random generation of the sender keys is that one can execute the same test multiple times in the same network and the plugin will not fail because the accounts and contracts are already deployed.

+

Transactions Gas Price

+

The fill plugin will use a fixed and minimum gas price for all the transactions it uses for testing, but this is not possible with the execute plugin, as the gas price is determined by the current state of the network.

+

At the moment, the execute plugin does not query the client for the current gas price, but instead uses a fixed increment to the gas price in order to avoid the transactions to be stuck in the mempool.

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/running_tests/execute/remote/index.html b/docs/public/main/running_tests/execute/remote/index.html new file mode 100644 index 00000000000..7c33a620bef --- /dev/null +++ b/docs/public/main/running_tests/execute/remote/index.html @@ -0,0 +1,1240 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

+
+ +
+

Running Test on a Live Remote Network

+

Tests can be executed on a live remote network by running the execute remote command.

+

The command requires the --fork flag which must match the fork that is currently active in the network (fork transition tests are not supported yet).

+

The execute remote command requires to be pointed to an RPC endpoint of a client that is connected to the network, which can be specified by using the --rpc-endpoint flag:

+
uv run execute remote --fork=Prague --rpc-endpoint=https://rpc.endpoint.io
+

Another requirement is that the command is provided with a seed account that has funds available in the network to deploy contracts and fund accounts. This can be done by setting the --rpc-seed-key flag:

+
uv run execute remote --fork=Prague --rpc-endpoint=https://rpc.endpoint.io --rpc-seed-key 0x000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
+

The value needs to be a private key that is used to sign the transactions that deploy the contracts and fund the accounts.

+

One last requirement is that the --rpc-chain-id flag is set to the chain id of the network that is being tested:

+
uv run execute remote --fork=Prague --rpc-endpoint=https://rpc.endpoint.io --rpc-seed-key 0x000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f --rpc-chain-id 12345
+

The execute remote command will connect to the client via the RPC endpoint and will start executing every test in the ./tests folder in the same way as the execute hive command, but instead of using the Engine API to generate blocks, it will send the transactions to the client via the RPC endpoint.

+

It is recommended to only run a subset of the tests when executing on a live network. To do so, a path to a specific test can be provided to the command:

+
uv run execute remote --fork=Prague --rpc-endpoint=https://rpc.endpoint.io --rpc-seed-key 0x000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f --rpc-chain-id 12345 ./tests/prague/eip7702_set_code_tx/test_set_code_txs.py::test_set_code_to_sstore
+

execute Command Test Execution

+

The execute remote and execute hive commands first creates a random sender account from which all required test accounts will be deployed and funded, and this account is funded by sweeping (by default) this “seed” account.

+

The sweep amount can be configured by setting the --seed-account-sweep-amount flag:

+
--seed-account-sweep-amount "1000 ether"
+

Once the sender account is funded, the command will start executing tests one by one by sending the transactions from this account to the network.

+

Test transactions are not sent from the main sender account though, they are sent from a different unique account that is created for each test (accounts returned by pre.fund_eoa).

+

Use with Parallel Execution

+

If the execute is run using the -n=N flag (respectively --sim-parallelism=N), n>1, the tests will be executed in parallel, and each process will have its own separate sender account, so the amount that is swept from the seed account is divided by the number of processes, and this has to be taken into account when setting the sweep amount and also when funding the seed account.

+

After finishing each test the command will check the remaining balance of all accounts and will attempt to recover the funds back to the sender account, and at the end of all tests, the remaining balance of the sender account will be swept back to the seed account.

+

There are instances where it will be impossible to recover the funds back from a test, for example, funds that are sent to a contract that has no built-in way to send them back, the funds will be stuck in the contract and they will not be recoverable.

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/running_tests/hive/ci_integration/index.html b/docs/public/main/running_tests/hive/ci_integration/index.html new file mode 100644 index 00000000000..85eb10f4bf6 --- /dev/null +++ b/docs/public/main/running_tests/hive/ci_integration/index.html @@ -0,0 +1,1268 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

+
+ +
+

Continuous Integration and Automated Testing

+

The Ethereum Foundation maintains continuous testing infrastructure:

+ +
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/running_tests/hive/client_config/index.html b/docs/public/main/running_tests/hive/client_config/index.html new file mode 100644 index 00000000000..6338501889e --- /dev/null +++ b/docs/public/main/running_tests/hive/client_config/index.html @@ -0,0 +1,1377 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

+
+ +
+

Client Configuration Guide

+

Clients ran in Hive are configured via the following ./hive options:

+
    +
  1. --client-file=client_config.yaml: Specifies a YAML file defining which and how clients are built.
  2. +
  3. --client=client1,client2: Selects a subset of clients to run from the YAML via nametag.
  4. +
+

Client YAML File Format

+

Multiple client configurations can be defined as a list in a client YAML file with the following structure:

+
- client: <client-name-1>
+  nametag: <unique-identifier>
+  dockerfile: <dockerfile-variant>
+  build_args:
+    <key>: <value>
+    ...
+- client: <client-name-2>
+  ...
+

Client Build Variants

+

Hive runs client images in Docker containers. There are three different ways to specify how a client image should be built:

+ + + + + + + + + + + + + + + + + + + + + + + + + +
DockerfilePurposeExample Usage
DockerfileDefault production builddockerfile: "" (default)
Dockerfile.gitClone from Github and build from sourcedockerfile: git
Dockerfile.localBuild from local sourcedockerfile: local
+

These Dockerfiles are maintained for each supported client in @ethereum/hive in the ./clients/ subfolder.

+

Production Image

+

A pre-built image can be specified, for example, for Besu with:

+
- client: besu
+  nametag: pectra
+  build_args:
+    baseimage: hyperledger/besu
+    tag: 25.4.1
+

Git Dockerfile

+

“Git Dockerfiles” clone a branch of the client from Github and build it from source, for example:

+
- client: go-ethereum
+  nametag: experimental
+  dockerfile: git
+  build_args:
+    github: your-username/go-ethereum
+    tag: experimental-branch
+

Using A “Local Dockerfile”

+

“Local Dockerfiles” can be used to build a client from local source for testing local modifications:

+
- client: go-ethereum
+  nametag: local-dev
+  dockerfile: local
+  build_args:
+    local_path: ./clients/go-ethereum/go-ethereum-local
+

This requires copying the local client source code to the Hive directory:

+
cp -r /path/to/your/go-ethereum ./clients/go-ethereum/go-ethereum-local
+

Required Fields

+
    +
  • client: Must match a directory name in clients/ within the Hive repository
  • +
  • nametag: Unique identifier for this client configuration
  • +
+

Optional Fields

+
    +
  • dockerfile: Alternative Dockerfile to use (default: Dockerfile)
  • +
  • build_args: Docker build arguments passed to the Dockerfile
  • +
+

Build Arguments

+

Common Build Arguments

+ + + + + + + + + + + + + + + + + + + + + + + + + +
ArgumentDescriptionExample
tagGit commit/tag/branch or Docker tagmaster, v1.13.8, latest
githubGitHub repository for source buildsethereum/go-ethereum
baseimageDocker Hub image for binary buildsethereum/client-go
+

Troubleshooting

+

Build Issues

+

Force rebuild base images:

+
./hive --docker.pull --sim ethereum/eest/consume-engine
+

Force rebuild specific client:

+
./hive --docker.nocache "clients/go-ethereum" --sim ethereum/eest/consume-engine
+

Show the docker container build output:

+
./hive --docker.buildoutput --sim ethereum/eest/consume-engine
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/running_tests/hive/common_options/index.html b/docs/public/main/running_tests/hive/common_options/index.html new file mode 100644 index 00000000000..91639c4f117 --- /dev/null +++ b/docs/public/main/running_tests/hive/common_options/index.html @@ -0,0 +1,1297 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

+
+ +
+

Common Simulator Options

+

All EEST Hive simulators share common command-line options and patterns.

+

Basic Usage

+

While they may be omitted, it’s recommended to specify the fixtures and branch simulator build arguments when running EEST simulators.

+

For example, this runs “stable” fixtures from the v4.3.0 latest stable release and builds the simulator at the v4.3.0 tag:

+
./hive --sim ethereum/eest/consume-engine \
+  --sim.buildarg fixtures=stable@v4.3.0 \
+  --sim.buildarg branch=v4.3.0 \
+  --client go-ethereum
+

Test Selection

+

Run a subset of tests by filtering tests using --sim.limit=<regex> to perform a regular expression match against test IDs:

+
./hive --sim ethereum/eest/consume-engine --sim.limit ".*eip4844.*"
+

Collect Only/Dry-Run

+

The collectonly: prefix can be used to inspect which tests would match an expression (dry-run), --docker.output must be specified to see the simulator’s collection result:

+
./hive --sim ethereum/eest/consume-engine \
+     --sim.buildarg fixtures=stable@v4.3.0 \
+     --sim.buildarg branch=v4.3.0 \
+     --docker.output \
+     --sim.limit="collectonly:.*eip4844.*"
+

Exact test ID Match

+

The id: prefix can be used to select a single test via its ID (this will automatically escape any special characters in the test case ID):

+
./hive --sim ethereum/eest/consume-engine \
+     --sim.buildarg fixtures=stable@v4.3.0 \
+     --sim.buildarg branch=v4.3.0 \
+     --docker.output \
+     --sim.limit "id:tests/cancun/eip4844_blobs/test_blob_txs.py::test_sufficient_balance_blob_tx"
+

Parallelism

+

To run multiple tests in parallel, use --sim.parallelism:

+
./hive --sim ethereum/eest/consume-rlp --sim.parallelism 4
+

Output Options

+

See hive log output in the console:

+
./hive --sim ethereum/eest/consume-engine --sim.loglevel 5
+

Container Issues

+

Increase client timeout:

+
./hive --client.checktimelimit=180s --sim ethereum/eest/consume-engine
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/running_tests/hive/dev_mode/index.html b/docs/public/main/running_tests/hive/dev_mode/index.html new file mode 100644 index 00000000000..8e5c21ba228 --- /dev/null +++ b/docs/public/main/running_tests/hive/dev_mode/index.html @@ -0,0 +1,1382 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

+
+ +
+

Hive Development Mode

+

This section explains how to run EEST simulators using their EEST commands, e.g., uv run consume engine, against a Hive “development” server as apposed to using the standalone ./hive command.

+

This avoids running the simulator in a dockerized environment and has several advantages:

+
    +
  1. A local directory containing fixtures can be specified (--input=./fixtures/).
  2. +
  3. Allows dropping into a Python debugger (via --pdb) upon test failure to inspect the response or ssh to the client container.
  4. +
  5. Provides access to a larger set of the simulator’s command-line options,
  6. +
  7. Runs are faster; there are no docker image rebuilds in between runs. In particular, modifications to the simulator do not require a an image rebuild.
  8. +
+

Platform Support

+
    +
  • Linux: Direct development mode supported.
  • +
  • macOS: Must be ran from a Linux environment or use a Docker-based workaround (see macOS Setup).
  • +
+

Quick Start

+

Prerequisites

+ +

Hive Dev Setup on Linux

+
    +
  1. +

    Start Hive in development mode, e.g.:

    +
    ./hive --dev --client go-ethereum --client-file clients.yaml --docker.output
    +
  2. +
  3. +

    In a separate shell, configure environment for EEST:

    +

    === “bash/zsh”

    +
     ```bash
    + export HIVE_SIMULATOR=http://127.0.0.1:3000
    + ```
    +
    +

    === “fish”

    +
     ```console
    + set -x HIVE_SIMULATOR http://127.0.0.1:3000
    + ```
    +
    +
  4. +
  5. +

    Run EEST consume commands

    +
    uv run consume engine --input ./fixtures -k "test_chainid"
    +uv run consume rlp --input stable@latest
    +
  6. +
+

Hive Dev Setup on macOS

+

Due to Docker running within a VM on macOS, the host machine and Docker containers don’t share the same network namespace, preventing direct communication with Hive’s development server. To run development mode on macOS, you have the following options:

+
    +
  1. Linux VM: Run a Linux virtual machine on your macOS and execute the standard development workflow above from within the VM.
  2. +
  3. Remote Linux: SSH into a remote Linux environment (server or cloud instance) and run development mode there.
  4. +
  5. Docker Development Image: Create a containerized EEST environment that runs within Docker’s network namespace (recommended).
  6. +
+

The following section details the setup and usage of option 3.

+

EEST Docker Development Image

+

Within the eest/ directory of hive, a new dockerfile must be created: Dockerfile.dev, with the following contents:

+
FROM ghcr.io/astral-sh/uv:python3.12-bookworm-slim
+ARG branch=main
+ENV GIT_REF=${branch} 
+
+RUN apt-get update && apt-get install -y git
+RUN git init execution-spec-tests && \
+    cd execution-spec-tests && \
+    git remote add origin https://github.com/ethereum/execution-spec-tests.git && \
+    git fetch --depth 1 origin $GIT_REF && \
+    git checkout FETCH_HEAD;
+
+WORKDIR /execution-spec-tests
+RUN uv sync
+ENTRYPOINT ["/bin/bash"]
+

This dockerfile will be our entry point for running EEST commands.

+

eest/ Hive Directory Structure

+
β”œβ”€β”€ eest
+β”‚   β”œβ”€β”€ Dockerfile.dev
+β”‚   β”œβ”€β”€ consume-block-rlp
+β”‚   β”‚   └── Dockerfile
+β”‚   └── consume-engine
+β”‚       └── Dockerfile
+

Running Consume

+
    +
  1. +

    Get your local IP address:

    +
    ipconfig getifaddr en0
    +
  2. +
  3. +

    Start Hive in development mode with your local IP:

    +
    ./hive --dev --dev.addr <LOCAL_IP>:3000 --client go-ethereum --client-file clients.yaml 
    +
  4. +
  5. +

    In a separate terminal session, build the EEST development image:

    +
    cd simulators/ethereum/eest/
    +docker build -t macos-consume-dev -f Dockerfile.dev .
    +
  6. +
  7. +

    Run the container with the Hive simulator environment:

    +
    docker run -it -e HIVE_SIMULATOR=http://<LOCAL_IP>:3000 macos-consume-dev
    +
  8. +
  9. +

    Inside the Docker container, run consume commands:

    +
    uv run consume engine -v
    +
  10. +
+

How Development Mode Works

+

When Hive runs in dev mode:

+
    +
  1. Starts the Hive API server (default: http://127.0.0.1:3000).
  2. +
  3. Builds and maintains client containers.
  4. +
  5. Keeps the Hive Proxy container running between test executions.
  6. +
  7. Waits for external simulator connections via the API.
  8. +
+

This allows EEST’s consume commands to connect to the running Hive instance and execute tests interactively.

+

More Options Available

+

There are many useful native pytest options available in dev mode, see Useful Options.

+

Custom API Endpoint

+

Specify a custom address and port via --dev.addr:

+
./hive --dev \
+  --dev.addr 127.0.0.1:5000 \
+  --client reth \
+  --client-file clients.yaml
+

Then connect with:

+
export HIVE_SIMULATOR=http://127.0.0.1:5000
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/running_tests/hive/hiveview/index.html b/docs/public/main/running_tests/hive/hiveview/index.html new file mode 100644 index 00000000000..81e9f0aacbf --- /dev/null +++ b/docs/public/main/running_tests/hive/hiveview/index.html @@ -0,0 +1,1267 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

+
+ +
+

Viewing Results

+

Build the result viewer hiveview:

+
go build ./cmd/hiveview
+

Start the server:

+
./hiveview --serve
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/running_tests/hive/index.html b/docs/public/main/running_tests/hive/index.html new file mode 100644 index 00000000000..e8ab882fbde --- /dev/null +++ b/docs/public/main/running_tests/hive/index.html @@ -0,0 +1,675 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
+ + + + +
+
+

+
+ + +
+

Hive

+

@ethereum/hive is a containerized testing framework that helps orchestrate test execution against Ethereum clients. Hive is incredibly extensible; new test suites can be implemented in a module manner as “simulators” that interact with clients to test certain aspects of their behavior. EEST implements several simulators, see Running Tests for an overview.

+

Quick Start

+

Prerequisites

+
    +
  1. Docker: https://docs.docker.com/get-docker/.
  2. +
  3. Golang 1.22+: https://go.dev/doc/install.
  4. +
+

Installation

+

Clone @ethereum/hive and build the ./hive command:

+
git clone https://github.com/ethereum/hive
+cd hive
+go build .
+
+
+
+
+
+ +
+ + + + + + + diff --git a/docs/public/main/running_tests/hive/main/index.html b/docs/public/main/running_tests/hive/main/index.html new file mode 100644 index 00000000000..80bfdfa3f41 --- /dev/null +++ b/docs/public/main/running_tests/hive/main/index.html @@ -0,0 +1,1275 @@ + + + + + + + Hive - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

Hive

+
+ +
+

Hive

+

@ethereum/hive is a containerized testing framework that helps orchestrate test execution against Ethereum clients. Hive is incredibly extensible; new test suites can be implemented in a module manner as “simulators” that interact with clients to test certain aspects of their behavior. EEST implements several simulators, see Running Tests for an overview.

+

Quick Start

+

Prerequisites

+
    +
  1. Docker: https://docs.docker.com/get-docker/.
  2. +
  3. Golang 1.22+: https://go.dev/doc/install.
  4. +
+

Installation

+

Clone @ethereum/hive and build the ./hive command:

+
git clone https://github.com/ethereum/hive
+cd hive
+go build .
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/running_tests/index.html b/docs/public/main/running_tests/index.html new file mode 100644 index 00000000000..1294994fc07 --- /dev/null +++ b/docs/public/main/running_tests/index.html @@ -0,0 +1,670 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
+ + + + +
+
+

+
+ + +
+

Running Tests

+

This section documents how EL clients can run EEST tests to verify their implementations. The information is organized as follows:

+
    +
  1. +

    Methods of Running Tests: A detailed overview and comparison.

    +
  2. +
  3. +

    EEST Fixture Releases: The available release types; release versioning.

    +
  4. +
  5. +

    Test Fixture Specifications and guides to implement direct consumer interfaces.

    +
  6. +
  7. +

    Hive: Help running EEST Hive simulators.

    +
  8. +
  9. +

    Consume: Commands that help clients run tests by consuming test fixtures.

    +
  10. +
  11. +

    Execute: Commands that help clients run tests by executing test source.

    +
  12. +
+
+
+
+
+
+ +
+ + + + + + + diff --git a/docs/public/main/running_tests/main/index.html b/docs/public/main/running_tests/main/index.html new file mode 100644 index 00000000000..479202325cc --- /dev/null +++ b/docs/public/main/running_tests/main/index.html @@ -0,0 +1,1431 @@ + + + + + + + Running Tests - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

Running Tests

+
+ +
+

This section documents how EL clients can run EEST tests to verify their implementations. The information is organized as follows:

+
    +
  1. +

    Methods of Running Tests: A detailed overview and comparison.

    +
  2. +
  3. +

    EEST Fixture Releases: The available release types; release versioning.

    +
  4. +
  5. +

    Test Fixture Specifications and guides to implement direct consumer interfaces.

    +
  6. +
  7. +

    Hive: Help running EEST Hive simulators.

    +
  8. +
  9. +

    Consume: Commands that help clients run tests by consuming test fixtures.

    +
  10. +
  11. +

    Execute: Commands that help clients run tests by executing test source.

    +
  12. +
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/running_tests/releases/index.html b/docs/public/main/running_tests/releases/index.html new file mode 100644 index 00000000000..ac3dc6a4eea --- /dev/null +++ b/docs/public/main/running_tests/releases/index.html @@ -0,0 +1,1490 @@ + + + + + + + EEST Fixture Releases - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

EEST Fixture Releases

+
+ +
+

Formats and Release Layout

+

@ethereum/execution-spec-tests releases contain JSON test fixtures in various formats. Note that transaction type tests are executed directly from Python source using the execute command.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FormatConsumed by the clientLocation in .tar.gz release
State Tests- directly via a statetest-like command
(e.g., go-ethereum/cmd/evm/staterunner.go)
./fixtures/state_tests/
Blockchain Tests- directly via a blocktest-like command
(e.g., go-ethereum/cmd/evm/blockrunner.go)
- using the RLPeest/consume-rlp Simulator via block import
./fixtures/blockchain_tests/
Blockchain Engine Tests- using the eest/consume-engine Simulator and the Engine API./fixtures/blockchain_tests_engine/
Transaction Tests- using a new simulator coming soonNone; executed directly from Python source,
using a release tag
Blob Transaction Tests- using the eest/execute-blobs Simulator andNone; executed directly from Python source,
using a release tag
+

Release URLs and Tarballs

+

Versioning Scheme

+

EEST framework and test sources and fixture releases are tagged use a semantic versioning scheme, <optional:<pre_release_name@>>v<MAJOR>.<MINOR>.<PATCH> as following:

+
    +
  • <MAJOR>: An existing fixture format has changed (potentially breaking change). Action must be taken by client teams to ensure smooth upgrade to the new format.
  • +
  • <MINOR>: Additional coverage (new tests, or a new format) have been added to the release.
  • +
  • <PATCH>: A bug-fix release; an error in the tests or framework has been patched.
  • +
+

Please see below for an explanation of the optional <pre_release_name> that is used in pre-releases.

+

Standard Releases

+

Releases are published on the @ethereum/execution-spec-tests releases page. Standard releases are tagged using the format vX.Y.Z (they don’t have a <pre_release_name>).

+

For standard releases, two tarballs are available:

+ + + + + + + + + + + + + + + + + +
Release ArtifactFork/feature scope
fixtures_stable.tar.gzTests for all forks up to and including the last deployed (“stable”) mainnet fork (“must pass”)
fixtures_develop.tar.gzTests for all forks up to and including the last development fork
+

I.e., fixtures_develop are a superset of fixtures_stable.

+

Pre-Release and Devnet Releases

+

Intermediate releases that target specific subsets of features or tests under active development are published at @ethereum/execution-spec-tests releases.

+

These releases are tagged using the format <pre_release_name>@vX.Y.Z.

+

Examples:

+ +

Devnet releases should be treated as WIP and may not yet contain full test coverage (or even coverage for all EIPs). The coverage provided by these releases is detailed in the corresponding release notes.

+

Help Downloading Releases

+

The consume cache command can be used to resolve EEST release and pre-release tags to release URLs and download them.

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/running_tests/running/index.html b/docs/public/main/running_tests/running/index.html new file mode 100644 index 00000000000..f6638a24527 --- /dev/null +++ b/docs/public/main/running_tests/running/index.html @@ -0,0 +1,1643 @@ + + + + + + + Methods of Running Tests - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

Methods of Running Tests

+
+ +
+

EEST has two commands, consume and execute, that run test cases against EL clients:

+
    +
  1. consume runs JSON test fixtures against a client - the client is said to “consume” the test case fixture.
  2. +
  3. execute runs test cases from Python source against a client - the test case is “executed” against the client.
  4. +
+

Top-Level Comparison

+

Both consume and execute provide sub-commands which correspond to different methods of testing EL clients using EEST test cases:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CommandDescriptionComponents testedEnvironmentScope
consume directClient consume tests via a statetest interfaceEVMNoneModule test
consume directClient consume tests via a blocktest interfaceEVM, block processingNoneModule test,
Integration test
consume engineClient imports blocks via Engine API EngineNewPayload in HiveEVM, block processing, Engine APIStaging, HiveSystem test
consume rlpClient imports RLP-encoded blocks upon start-up in HiveEVM, block processing, RLP import (sync*)Staging, HiveSystem test
execute hiveTests executed against a client via JSON RPC eth_sendRawTransaction in HiveEVM, JSON RPC, mempoolStaging, HiveSystem test
execute remoteTests executed against a client via JSON RPC eth_sendRawTransaction on a live networkEVM, JSON RPC, mempool, EL-EL/EL-CL interaction (indirectly)ProductionSystem Test
+

*sync: Depending on code paths used in the client implementation, see the RLP vs Engine Simulator section below.

+

The following sections describe the different methods in more detail.

+ + +
+
./hive --sim=eest/consume-engine vs consume engine
+
+ EEST simulators can be ran either standalone using the ./hive command or via an EEST command against a ./hive --dev backend, more details are provided below. +
+
+

Direct

+ + + + + + + + + + + + + + + + + + + + + +
Nomenclature
Commandconsume direct
SimulatorNone
Fixture Formatsstate_test,
blockchain_test
+

The direct method provides the fastest way to test EVM functionality by executing tests directly through a client’s dedicated test interface (e.g. statetest or blocktest). This method requires clients to implement a custom interface to read tests and pass their inputs through appropriate code paths; implementation guides available for state tests and blockchain tests.

+

The EEST consume direct command is a small wrapper around client direct interfaces that allows fast and easy selection of test subsets to execute via test ID regex match (thanks to an index file). See Consume Direct and the Cache and Fixture Inputs and Useful Pytest Options pages for help with options.

+ + +
+
Rapid EVM development
+
+ The direct method with the StateTest format should be used for the fastest EVM development feedback loop. Additionally, EVM traces can be readily generated and compared to other implementations. +
+
+

Engine

+ + + + + + + + + + + + + + + + + + + + + +
Nomenclature
Commandconsume engine
Simulatoreest/consume-engine
Fixture formatblockchain_test_engine
+

The consume engine method tests execution clients via the Engine API by sending block payloads and verifying the response (post-merge forks only). This method provides the most realistic testing environment for production Ethereum client behavior, covering consensus integration, payload validation, and state synchronization.

+

The consume engine command:

+
    +
  1. Initializes the execution client with genesis state.
  2. +
  3. Connects via Engine API (port 8551), primitively mocking a consensus client.
  4. +
  5. Sends a forkchoice update to establish the chain head.
  6. +
  7. Submits payloads using engine_newPayload calls.
  8. +
  9. Validates responses against expected results.
  10. +
  11. Tests error conditions and exception handling.
  12. +
+

RLP

+ + + + + + + + + + + + + + + + + + + + + +
Nomenclature
Commandconsume rlp
Simulatoreest/consume-rlp
Fixture formatblockchain_test
+

The RLP consumption method tests execution clients by providing them with RLP-encoded blocks to load upon startup, similar to the block import process during historical synchronization. This method tests the client’s core block processing logic without the overhead of network protocols.

+

The consume rlp command:

+
    +
  1. Reads blockchain test fixtures from the specified input source.
  2. +
  3. Extracts RLP-encoded blocks from the fixture files.
  4. +
  5. Copies blocks to the client’s container via files in the /blocks/ directory.
  6. +
  7. Starts the client with the genesis state and block files.
  8. +
  9. Validates the client’s final blockHash via JSON RPC against the test’s expectations.
  10. +
+

This method simulates how clients import blocks during historical sync, testing the complete block validation and state transition pipeline, see below for more details and a comparison to consumption via the Engine API.

+

Engine vs RLP Simulator

+

The RLP Simulator (eest/consume-rlp) and the Engine Simulator (eest/consume-engine) should be seen as complimentary to one another. Although they execute the same underlying EVM test cases, the block validation logic is executed via different client code paths (using different fixture formats). Therefore, ideally, both simulators should be executed for full coverage.

+

Code Path Choices

+

Clients consume fixtures in the eest/consume-engine simulator via the Engine API’s EngineNewPayloadv* endpoint; a natural way to validate, respectively invalidate, block payloads. In this case, there is no flexibility in the choice of code path - it directly harnesses mainnet client functionality. The eest/consume-rlp Simulator, however, allows clients more freedom, as the rlp-encoded blocks are imported upon client startup. Clients are recommended to try and hook the block import into the code path used for historical syncing.

+

Differences

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
eest/consume-rlpeest/consume-engine
Fixture Format UsedBlockchainTestBlockchainTestEngine
Fork supportAll forks (including pre-merge)Post-merge forks only (Paris+)
Client code pathHistorical sync / block import pipelineEngine API / consensus integration
Real-world analogyBlocks received during syncBlocks received from consensus client
InterfaceBlock import upon start-up via RLP filesEngine API calls (newPayload, forkchoiceUpdated)
Exception testingBasic exception handlingAdvanced exception verification with client-specific mappers
+ + +
+
Running both simulators adds some redundancy that can assist test debugging
+
+ If Engine tests fail but RLP tests pass, the issue is likely in your Engine API implementation rather than core EVM logic. +
+
+

Execute

+

See Execute Command.

+

Two Methods to Run EEST Simulators

+

Many of the methods use the Hive Testing Environment to interact with clients and run tests against them. These methods are also called Hive simulators. While Hive is always necessary to run simulators, they can be called in two different ways. Both of these commands execute the same simulator code, but in different environments, we take the example of the eest/consume-engine simulator:

+
    +
  1. ./hive --sim=eest/consume-engine is a standalone command that installs EEST and the consume command in a dockerized container managed by Hive. This is the standard method to execute EEST fixture releases against clients in CI environments and is the method to generate the results at hive.ethpandaops.io. See Hive and its Common Options for help with this method.
  2. +
  3. uv run consume engine requires the user to clone and install EEST and start a Hive server in development mode. In this case, the simulator runs on the native system and communicate to the client via the Hive API. This is particularly useful during test development as fixtures on the local disk can be specified via --input=fixtures/. As the simulator runs natively, it is easy to drop into a debugger and inspect the simulator or client container state. See Hive Developer Mode for help with this method.
  4. +
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/running_tests/test_formats/blockchain_test/index.html b/docs/public/main/running_tests/test_formats/blockchain_test/index.html new file mode 100644 index 00000000000..9d0ac78bc33 --- /dev/null +++ b/docs/public/main/running_tests/test_formats/blockchain_test/index.html @@ -0,0 +1,1505 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

+
+ +
+

Blockchain Tests

+

The Blockchain Test fixture format tests are included in the fixtures subdirectory blockchain_tests.

+

These are produced by the StateTest and BlockchainTest test specs.

+

Description

+

The blockchain test fixture format is used to test block validation and the consensus rules of the Ethereum blockchain.

+

It does so by defining a pre-execution state, a series of blocks, and a post-execution state, verifying that, after all the blocks have been processed, appended if valid or rejected if invalid, the result is the expected post-execution state.

+

A single JSON fixture file is composed of a JSON object where each key-value pair is a different Fixture test object, with the key string representing the test name.

+

The JSON file path plus the test name are used as the unique test identifier.

+

Consumption

+

For each Fixture test object in the JSON fixture file, perform the following steps:

+
    +
  1. +

    Use network to configure the execution fork schedule according to the Fork type definition.

    +
  2. +
  3. +

    Use pre as the starting state allocation of the execution environment for the test and calculate the genesis state root.

    +
  4. +
  5. +

    Decode genesisRLP to obtain the genesis block header, if the block cannot be decoded, fail the test.

    +
  6. +
  7. +

    Compare the genesis block header with genesisBlockHeader, if any field does not match, fail the test.

    +
  8. +
  9. +

    Compare the state root calculated on step 2 with the state root in the genesis block header, if they do not match, fail the test.

    +
  10. +
  11. +

    Set the genesis block as the current head of the chain.

    +
  12. +
  13. +

    If blocks contains at least one block, perform the following steps for each FixtureBlock or InvalidFixtureBlock:

    +
      +
    1. +

      Determine whether the current block is valid or invalid:

      +
        +
      1. If the expectException field is not present, it is valid, and object must be decoded as a FixtureBlock.
      2. +
      3. If the expectException field is present, it is invalid, and object must be decoded as a InvalidFixtureBlock.
      4. +
      +
    2. +
    3. +

      Attempt to decode field rlp as the current block

      +
        +
      1. If the block cannot be decoded: +
          +
        • If an rlp decoding exception is not expected for the current block, fail the test.
        • +
        • If an rlp decoding error is expected, pass the test (Note: A block with an expected exception will be the last block in the fixture).
        • +
        +
      2. +
      3. If the block can be decoded, proceed to the next step.
      4. +
      +
    4. +
    5. +

      Attempt to apply the current decoded block on top of the current head of the chain

      +
        +
      1. If the block cannot be applied: +
          +
        • If an exception is expected on the current block and it matches the exception obtained upon execution, pass the test. (Note: A block with an expected exception will be the last block in the fixture)
        • +
        • If an exception is not expected on the current block, fail the test
        • +
        +
      2. +
      3. If the block can be applied: +
          +
        • If an exception is expected on the current block, fail the test
        • +
        • If an exception is not expected on the current block, set the decoded block as the current head of the chain and proceed to the next block until you reach the last block in the fixture.
        • +
        +
      4. +
      +
    6. +
    +
  14. +
  15. +

    Compare the hash of the current head of the chain against lastblockhash, if they do not match, fail the test.

    +
  16. +
  17. +

    Compare all accounts and the fields described in post against the current state, if any do not match, fail the test.

    +
  18. +
+

Structures

+

Fixture

+

- network: Fork

+
TO BE DEPRECATED
+

Fork configuration for the test.

+

This field is going to be replaced by the value contained in config.network.

+

- pre: Alloc

+

Starting account allocation for the test. State root calculated from this allocation must match the one in the genesis block.

+

- genesisRLP: Bytes

+

RLP serialized version of the genesis block.

+

- genesisBlockHeader: FixtureHeader

+

Genesis block header.

+

- blocks: List[FixtureBlock|InvalidFixtureBlock]

+

List of blocks to be processed after the genesis block.

+

- lastblockhash: Hash

+

Hash of the last valid block, or the genesis block hash if the list of blocks is empty, or contains a single invalid block.

+

- post: Alloc

+

Account allocation for verification after all the blocks have been processed.

+

- sealEngine: str

+

Deprecated: Seal engine used to mine the blocks.

+

- config: FixtureConfig

+

Chain configuration object to be applied to the client running the blockchain test.

+

FixtureConfig

+

- network: Fork

+

Fork configuration for the test. It is guaranteed that this field contains the same value as the root field network.

+

- blobSchedule: BlobSchedule

+

Optional; present from Cancun on. Maps forks to their blob schedule configurations as defined by EIP-7840.

+

FixtureHeader

+

- parentHash: Hash

+

Hash of the parent block.

+

- uncleHash: Hash

+

Hash of the uncle block list.

+

- coinbase: Address

+

Address of the account that will receive the rewards for building the block.

+

- stateRoot: Hash

+

Root hash of the state trie.

+

- transactionsTrie: Hash

+

Root hash of the transactions trie.

+

- receiptTrie: Hash

+

Root hash of the receipts trie.

+

- bloom: Bloom

+

Bloom filter composed of the logs of all the transactions in the block.

+

- difficulty: ZeroPaddedHexNumber

+

Difficulty of the block.

+

- number: ZeroPaddedHexNumber

+

Number of the block.

+

- gasLimit: ZeroPaddedHexNumber

+

Total gas limit of the block.

+

- gasUsed: ZeroPaddedHexNumber

+

Total gas used by all the transactions in the block.

+

- timestamp: ZeroPaddedHexNumber

+

Timestamp of the block.

+

- extraData: Bytes

+

Extra data of the block.

+

- mixHash: Hash

+

Mix hash or PrevRandao of the block.

+

- nonce: HeaderNonce

+

Nonce of the block.

+

- hash: Hash

+

Hash of the block.

+

- baseFeePerGas: ZeroPaddedHexNumber (fork: London)

+

Base fee per gas of the block.

+

- withdrawalsRoot: Hash (fork: Shanghai)

+

Root hash of the withdrawals trie.

+

- blobGasUsed: ZeroPaddedHexNumber (fork: Cancun)

+

Total blob gas used by all the transactions in the block.

+

- excessBlobGas: ZeroPaddedHexNumber (fork: Cancun)

+

Excess blob gas of the block used to calculate the blob fee per gas for this block.

+

- parentBeaconBlockRoot: Hash (fork: Cancun)

+

Root hash of the parent beacon block.

+

FixtureBlock

+

- rlp: Bytes

+

RLP serialized version of the block. Field is only optional when embedded in a InvalidFixtureBlock as the rlp_decoded field.

+

- blockHeader: FixtureHeader

+

Decoded block header fields included in the block RLP.

+

- blocknumber: Number

+

Block number.

+

- transactions: List[FixtureTransaction]

+

List of decoded transactions included in the block RLP.

+

- uncleHeaders: List[FixtureHeader]

+

List of uncle headers included in the block RLP. An empty list post merge.

+

- withdrawals: Optional[List[FixtureWithdrawal]] (fork: Shanghai)

+

Optional list of withdrawals included in the block RLP.

+

InvalidFixtureBlock

+

- expectException: TransactionException|BlockException

+

Expected exception that invalidates the block.

+

- rlp: Bytes

+

RLP serialized version of the block.

+

- rlp_decoded: Optional[FixtureBlock]

+

Decoded block attributes included in the block RLP.

+

FixtureTransaction

+

- type: ZeroPaddedHexNumber

+

Transaction type.

+

- chainId: ZeroPaddedHexNumber

+

Chain ID of the transaction.

+

- nonce: ZeroPaddedHexNumber

+

Nonce of the account that sends the transaction

+

- gasPrice: ZeroPaddedHexNumber

+

Gas price for the transaction (Transaction types 0 & 1)

+

- maxPriorityFeePerGas: HexNumber (fork: London)

+

Max priority fee per gas to pay (Transaction types 2 & 3)

+

- maxFeePerGas: HexNumber (fork: London)

+

Max base fee per gas to pay (Transaction types 2 & 3)

+

- gasLimit: ZeroPaddedHexNumber

+

Gas limit of the transaction

+

- to: Address| null

+

Destination address of the transaction, or null to create a contract

+

- value: ZeroPaddedHexNumber

+

Value of the transaction

+

- data: Bytes

+

Data bytes of the transaction

+

- accessList: List[Mapping[Address,List[Hash]]] (fork: Berlin)

+

Account access lists (Transaction types 1, 2 & 3)

+

- maxFeePerBlobGas: ZeroPaddedHexNumber (fork: Cancun)

+

Max fee per blob gas to pay (Transaction type 3)

+

- blobVersionedHashes: List[Hash] (fork: Cancun)

+

Max fee per blob gas to pay (Transaction type 3)

+

- v: ZeroPaddedHexNumber

+

V value of the transaction signature

+

- r: ZeroPaddedHexNumber

+

R value of the transaction signature

+

- s: ZeroPaddedHexNumber

+

S value of the transaction signature

+

- sender: Address

+

Sender address of the transaction

+

- secretKey: Hash

+

Private key that must be used to sign the transaction

+

FixtureWithdrawal

+

- index: ZeroPaddedHexNumber

+

Index of the withdrawal

+

- validatorIndex: ZeroPaddedHexNumber

+

Withdrawing validator index

+

- address: Address

+

Address to withdraw to

+

- amount: ZeroPaddedHexNumber

+

Amount of the withdrawal

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/running_tests/test_formats/blockchain_test_engine/index.html b/docs/public/main/running_tests/test_formats/blockchain_test_engine/index.html new file mode 100644 index 00000000000..6f7b314bc72 --- /dev/null +++ b/docs/public/main/running_tests/test_formats/blockchain_test_engine/index.html @@ -0,0 +1,1425 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

+
+ +
+

Blockchain Engine Tests

+

The Blockchain Engine Test fixture format tests are included in the fixtures subdirectory blockchain_tests_engine, and use Engine API directives instead of the usual BlockchainTest format.

+

These are produced by the StateTest and BlockchainTest test specs.

+

Description

+

The Blockchain Engine Test fixture format is used to test block validation and the consensus rules of the Ethereum blockchain, when a block is delivered through the Engine API as a engine_newPayloadVX directive.

+

It does so by defining a pre-execution state, a series of blocks as engine_newPayloadVX directives, and a post-execution state, verifying that, after all the blocks have been processed, appended if valid or rejected if invalid, the result is the expected post-execution state.

+

A single JSON fixture file is composed of a JSON object where each key-value pair is a different HiveFixture test object, with the key string representing the test name.

+

The JSON file path plus the test name are used as the unique test identifier.

+

Consumption

+

For each HiveFixture test object in the JSON fixture file, perform the following steps:

+
    +
  1. +

    Start a full node using:

    +
      +
    • network to configure the execution fork schedule according to the Fork type definition.
    • +
    • pre as the starting state allocation of the execution environment for the test and calculate the genesis state root.
    • +
    • genesisBlockHeader as the genesis block header.
    • +
    +
  2. +
  3. +

    Verify the head of the chain is the genesis block, and the state root matches the one calculated on step 1, otherwise fail the test.

    +
  4. +
  5. +

    For each FixtureEngineNewPayload in engineNewPayloads:

    +
      +
    1. Deliver the payload using the engine_newPayloadVX directive, using: + +
    2. +
    3. If errorCode is present: +
        +
      • Verify the directive returns an error, and the error code matches the one in errorCode, otherwise fail the test.
      • +
      • Proceed to the next payload.
      • +
      +
    4. +
    5. If valid is false, verify that the directive returns status field of PayloadStatusV1 as INVALID, otherwise fail the test.
    6. +
    7. If valid is true, verify that the directive returns status field of PayloadStatusV1 as VALID, otherwise fail the test.
    8. +
    +
  6. +
+

Structures

+

HiveFixture

+

- network: Fork

+
TO BE DEPRECATED
+

Fork configuration for the test.

+

This field is going to be replaced by the value contained in config.network.

+

- genesisBlockHeader: FixtureHeader

+

Genesis block header.

+

- engineNewPayloads: List[FixtureEngineNewPayload]

+

List of engine_newPayloadVX directives to be processed after the genesis block.

+

- engineFcuVersion: Number

+

Version of the engine_forkchoiceUpdatedVX directive to use to set the head of the chain.

+

- pre: Alloc

+

Starting account allocation for the test. State root calculated from this allocation must match the one in the genesis block.

+

- lastblockhash: Hash

+

Hash of the last valid block, or the genesis block hash if the list of blocks is empty, or contains a single invalid block.

+

- post: Alloc

+

Account allocation for verification after all the blocks have been processed.

+

- config: FixtureConfig

+

Chain configuration object to be applied to the client running the blockchain engine test.

+

FixtureConfig

+

- network: Fork

+

Fork configuration for the test. It is guaranteed that this field contains the same value as the root field network.

+

- blobSchedule: BlobSchedule

+

Optional; present from Cancun on. Maps forks to their blob schedule configurations as defined by EIP-7840.

+

FixtureEngineNewPayload

+

- executionPayload: FixtureExecutionPayload

+

Execution payload.

+

- blob_versioned_hashes: Optional[List[Hash]] (fork: Cancun)

+

List of hashes of the versioned blobs that are part of the execution payload. +They can mismatch the hashes of the versioned blobs in the execution payload, for negative-testing reasons.

+

- parentBeaconBlockRoot: Optional[Hash] (fork: Cancun)

+

Hash of the parent beacon block root.

+

- validationError: TransactionException|BlockException

+

Validation error expected when executing the payload.

+

When the payload is valid, this field is not present, and a VALID status is +expected in the status field of +PayloadStatusV1.

+

If this field is present, the status field of +PayloadStatusV1 +is expected to be INVALID.

+

- version: Number

+

Version of the engine_newPayloadVX directive to use to deliver the payload.

+

- errorCode: Optional[Number]

+

Error code to be returned by the engine_newPayloadVX directive.

+

FixtureExecutionPayload

+

- parentHash: Hash

+

Hash of the parent block.

+

- feeRecipient: Address

+

Address of the account that will receive the rewards for building the block.

+

- stateRoot: Hash

+

Root hash of the state trie.

+

- receiptsRoot: Hash

+

Root hash of the receipts trie.

+

- logsBloom: Bloom

+

Bloom filter composed of the logs of all the transactions in the block.

+

- blockNumber: HexNumber

+

Number of the block.

+

- gasLimit: HexNumber

+

Total gas limit of the block.

+

- gasUsed: HexNumber

+

Total gas used by all the transactions in the block.

+

- timestamp: HexNumber

+

Timestamp of the block.

+

- extraData: Bytes

+

Extra data of the block.

+

- prevRandao: Hash

+

PrevRandao of the block.

+

- blockHash: Hash

+

Hash of the block.

+

- transactions: List[Bytes]

+

List of transactions in the block, in serialized format.

+

- withdrawals: List[FixtureWithdrawal]

+

List of withdrawals in the block.

+

- baseFeePerGas: HexNumber (fork: London)

+

Base fee per gas of the block.

+

- blobGasUsed: HexNumber (fork: Cancun)

+

Total blob gas used by all the transactions in the block.

+

- excessBlobGas: HexNumber (fork: Cancun)

+

Excess blob gas of the block used to calculate the blob fee per gas for this block.

+

FixtureWithdrawal

+

- index: HexNumber

+

Index of the withdrawal

+

- validatorIndex: HexNumber

+

Withdrawing validator index

+

- address: Address

+

Address to withdraw to

+

- amount: HexNumber

+

Amount of the withdrawal

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/running_tests/test_formats/blockchain_test_engine_x/index.html b/docs/public/main/running_tests/test_formats/blockchain_test_engine_x/index.html new file mode 100644 index 00000000000..0cccc285917 --- /dev/null +++ b/docs/public/main/running_tests/test_formats/blockchain_test_engine_x/index.html @@ -0,0 +1,1414 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

+
+ +
+

Blockchain Engine X Tests

+

The Blockchain Engine X Test fixture format tests are included in the fixtures subdirectory blockchain_tests_engine_x, and use Engine API directives with optimized pre-allocation groups for improved execution performance.

+

These are produced by the StateTest and BlockchainTest test specs when using the --generate-pre-alloc-groups and --use-pre-alloc-groups flags.

+

Description

+

The Blockchain Engine X Test fixture format is an optimized variant of the Blockchain Engine Test format designed for large-scale test execution with performance optimizations.

+

It uses the Engine API to test block validation and consensus rules while leveraging pre-allocation groups to significantly reduce test execution time and resource usage. Tests are grouped by their initial state (fork + environment + pre-allocation). Each group is executed against the same client instance using a common genesis state.

+

The key optimization is that clients need only be started once per group instead of once per test (as in the original engine fixture format), dramatically improving execution performance for large test suites.

+

Instead of including large pre-allocation state in each test fixture, this format references a pre-allocation groups folder (pre_alloc) which contains all different pre-allocation combinations organized by group.

+

A single JSON fixture file is composed of a JSON object where each key-value pair is a different BlockchainTestEngineXFixture test object, with the key string representing the test name.

+

The JSON file path plus the test name are used as the unique test identifier.

+

Pre-Allocation Groups Folder

+

The blockchain_tests_engine_x directory contains a special directory pre_alloc that stores pre-allocation group files used by all tests in this format, one per pre-allocation group with the name of the pre-alloc hash. This folder is essential for test execution and must be present alongside the test fixtures.

+

Pre-Allocation Group File Structure

+

Each file in the pre_alloc folder corresponds to a pre-allocation group identified by a hash:

+
{
+   "test_count": 88,
+   "pre_account_count": 174,
+   "testIds": ["test1", "test2", ...],
+   "network": "Prague",
+   "environment": { ... },
+   "pre": { ... }
+}
+

Pre-Allocation Group Fields

+
    +
  • test_count: Number of tests in this pre-allocation group
  • +
  • pre_account_count: Number of accounts in the pre-allocation group
  • +
  • testIds: Array of test identifiers that belong to this group
  • +
  • network: Fork name (e.g., “Prague”, “Cancun”)
  • +
  • environment: Complete Environment object with execution context
  • +
  • pre: Pre-allocation group Alloc object containing initial account states
  • +
+

Consumption

+

For each BlockchainTestEngineXFixture test object in the JSON fixture file, perform the following steps:

+
    +
  1. +

    Load Pre-Allocation Group:

    +
      +
    • Read the appropriate file from the pre_alloc folder in the same directory
    • +
    • Locate the pre-allocation group using preHash
    • +
    • Extract the pre allocation and environment from the group
    • +
    +
  2. +
  3. +

    Initialize Client:

    +
      +
    • Use network to configure the execution fork schedule
    • +
    • Use the pre-allocation group’s pre allocation as the starting state
    • +
    • Use the pre-allocation group’s environment as the execution context
    • +
    • Use genesisBlockHeader as the genesis block header
    • +
    +
  4. +
  5. +

    Execute Engine API Sequence:

    + +
  6. +
  7. +

    Verify Final State:

    +
      +
    • Compare the final chain head against lastblockhash
    • +
    • If postStateDiff is present: +
        +
      • Apply the state differences to the pre-allocation group
      • +
      • Verify the resulting state matches the client’s final state
      • +
      +
    • +
    • If post field were present (not typical), verify it directly
    • +
    +
  8. +
+

Structures

+

BlockchainTestEngineXFixture

+

- network: Fork

+
TO BE DEPRECATED
+

Fork configuration for the test.

+

This field is going to be replaced by the value contained in config.network.

+

- preHash: string

+

Hash identifier referencing a pre-allocation group in the pre_alloc folder. This hash uniquely identifies the combination of fork, environment, and pre-allocation state that defines the group.

+

- genesisBlockHeader: FixtureHeader

+

Genesis block header. The state root in this header must match the state root calculated from the pre-allocation group referenced by preHash.

+

- engineNewPayloads: List[FixtureEngineNewPayload]

+

List of engine_newPayloadVX directives to be processed after the genesis block. These define the sequence of blocks to be executed via the Engine API.

+

- syncPayload: Optional[FixtureEngineNewPayload]

+

Optional synchronization payload. When present, this payload is typically used to sync the chain to a specific state before or after the main payload sequence.

+

- lastblockhash: Hash

+

Hash of the last valid block after all payloads have been processed, or the genesis block hash if all payloads are invalid.

+

- postStateDiff: Optional[Alloc]

+

State differences from the pre-allocation group after test execution. This optimization stores only the accounts that changed, were created, or were deleted during test execution, rather than the complete final state.

+

To reconstruct the final state:

+
    +
  1. Start with the pre-allocation group from the pre_alloc folder
  2. +
  3. Apply the changes in postStateDiff: +
      +
    • Modified accounts: Replace existing accounts with new values
    • +
    • New accounts: Add accounts not present in pre-allocation
    • +
    • Deleted accounts: Remove accounts (represented as null values)
    • +
    +
  4. +
+

- config: FixtureConfig

+

Chain configuration object to be applied to the client running the blockchain engine x test.

+

FixtureConfig

+

- network: Fork

+

Fork configuration for the test. It is guaranteed that this field contains the same value as the root field network.

+

- blobSchedule: BlobSchedule

+

Optional; present from Cancun on. Maps forks to their blob schedule configurations as defined by EIP-7840.

+

FixtureEngineNewPayload

+

Engine API payload structure identical to the one defined in Blockchain Engine Tests. Includes execution payload, versioned hashes, parent beacon block root, validation errors, version, and error codes.

+

Usage Notes

+
    +
  • This format is only generated when using --generate-pre-alloc-groups and --use-pre-alloc-groups flags
  • +
  • The pre_alloc folder is essential and must be distributed with the test fixtures
  • +
  • Tests are grouped by identical (fork + environment + pre-allocation) combinations
  • +
  • The format is optimized for Engine API testing (post-Paris forks)
  • +
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/running_tests/test_formats/common_types/index.html b/docs/public/main/running_tests/test_formats/common_types/index.html new file mode 100644 index 00000000000..0387cc97a7c --- /dev/null +++ b/docs/public/main/running_tests/test_formats/common_types/index.html @@ -0,0 +1,1601 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

+
+ +
+

Common Types

+

Basic Types

+

Address

+

Bytes of a 20-byte fixed length.

+

Bloom

+

Bytes of a 256-byte fixed length.

+

Bytes

+

Hexadecimal representation of binary data of any length encoded as a JSON string, with a “0x” prefix.

+

EmptyAddress

+

An empty JSON string "", used to represent an empty address. E.g. in the to field of a transaction when it is a contract creation.

+

Hash

+

Bytes of a 32-byte fixed length.

+

HeaderNonce

+

Bytes of a 8-byte fixed length.

+

HexNumber

+

Hexadecimal number with “0x” prefix encoded as a JSON string.

+

List

+

A JSON array where each element is a specific type, also defined in this document. +E.g. List[Address] is a JSON array where each element is an Ethereum address.

+

Mapping

+

A JSON object where the keys and values are specific types, also defined in this document. +E.g. Mapping[Address, Account] is a JSON object where the keys are Ethereum addresses, and the values are Ethereum accounts.

+

Number

+

Decimal number encoded as a JSON string.

+

Optional

+

Marks a field as optional, meaning that the field can be missing from the JSON object.

+

ZeroPaddedHexNumber

+

Hexadecimal number with “0x” prefix encoded as a JSON string, with a single zero used to pad odd number of digits, and zero represented as “0x00”.

+

Composite Types

+

Storage: Mapping[Hash,Hash]

+

Storage represented as a JSON object, where the keys and values are represented with the Hash type.

+

Account

+

An Ethereum account represented as a JSON object with the following fields:

+

- balance: ZeroPaddedHexNumber

+

Balance of the account.

+

- nonce: ZeroPaddedHexNumber

+

Nonce of the account.

+

- code: Bytes

+

Code of the account.

+

- storage: Storage

+

Storage of the account.

+

Alloc: Mapping[Address,Account]

+

State allocation represented as a JSON object, where the keys are the addresses of the accounts, and the values are the accounts.

+

BlobSchedule: Mapping[Fork,ForkBlobSchedule]

+

Maps forks to blob schedule configurations as defined by EIP-7840.

+

Environment

+

Contains blockchain-related configuration that provides the context in which a test is run.

+

ForkBlobSchedule

+

A fork blob schedule as defined by EIP-7840 as a JSON dictionary with the following entries:

+

- target: ZeroPaddedHexNumber

+

The target blob count for a block.

+

- max: ZeroPaddedHexNumber

+

The maximum possible blob count for a block.

+

- base_fee_update_fraction: ZeroPaddedHexNumber

+

The blob base fee update fraction (adjusts the responsiveness of blob gas pricing per fork).

+

Fork

+

Fork type is represented as a JSON string that can be set to one of the following values:

+

"Frontier"

+
    +
  • Chain ID: 0x00
  • +
+

"Homestead"

+
    +
  • Chain ID: 0x01
  • +
  • Homestead Block: 0x00
  • +
+

"Byzantium"

+
    +
  • Chain ID: 0x01
  • +
  • Homestead Block: 0x00
  • +
  • EIP150 Block: 0x00
  • +
  • EIP155 Block: 0x00
  • +
  • EIP158 Block: 0x00
  • +
  • DAO Fork Block: 0x00
  • +
  • Byzantium Block: 0x00
  • +
+

"Constantinople"

+
    +
  • Chain ID: 0x01
  • +
  • Homestead Block: 0x00
  • +
  • EIP150 Block: 0x00
  • +
  • EIP155 Block: 0x00
  • +
  • EIP158 Block: 0x00
  • +
  • DAO Fork Block: 0x00
  • +
  • Byzantium Block: 0x00
  • +
  • Constantinople Block: 0x00
  • +
+

"ConstantinopleFix"

+
    +
  • Chain ID: 0x01
  • +
  • Homestead Block: 0x00
  • +
  • EIP150 Block: 0x00
  • +
  • EIP155 Block: 0x00
  • +
  • EIP158 Block: 0x00
  • +
  • DAO Fork Block: 0x00
  • +
  • Byzantium Block: 0x00
  • +
  • Constantinople Block: 0x00
  • +
  • Constantinople Fix Block: 0x00
  • +
+

"Istanbul"

+
    +
  • Chain ID: 0x01
  • +
  • Homestead Block: 0x00
  • +
  • EIP150 Block: 0x00
  • +
  • EIP155 Block: 0x00
  • +
  • EIP158 Block: 0x00
  • +
  • DAO Fork Block: 0x00
  • +
  • Byzantium Block: 0x00
  • +
  • Constantinople Block: 0x00
  • +
  • Constantinople Fix Block: 0x00
  • +
  • Istanbul Block: 0x00
  • +
+

"MuirGlacier"

+
    +
  • Chain ID: 0x01
  • +
  • Homestead Block: 0x00
  • +
  • EIP150 Block: 0x00
  • +
  • EIP155 Block: 0x00
  • +
  • EIP158 Block: 0x00
  • +
  • DAO Fork Block: 0x00
  • +
  • Byzantium Block: 0x00
  • +
  • Constantinople Block: 0x00
  • +
  • Constantinople Fix Block: 0x00
  • +
  • Istanbul Block: 0x00
  • +
  • Muir Glacier Block: 0x00
  • +
+

"Berlin"

+
    +
  • Chain ID: 0x01
  • +
  • Homestead Block: 0x00
  • +
  • EIP150 Block: 0x00
  • +
  • EIP155 Block: 0x00
  • +
  • EIP158 Block: 0x00
  • +
  • DAO Fork Block: 0x00
  • +
  • Byzantium Block: 0x00
  • +
  • Constantinople Block: 0x00
  • +
  • Constantinople Fix Block: 0x00
  • +
  • Istanbul Block: 0x00
  • +
  • Muir Glacier Block: 0x00
  • +
  • Berlin Block: 0x00
  • +
+

"BerlinToLondonAt5"

+
    +
  • Chain ID: 0x01
  • +
  • Homestead Block: 0x00
  • +
  • EIP150 Block: 0x00
  • +
  • EIP155 Block: 0x00
  • +
  • EIP158 Block: 0x00
  • +
  • DAO Fork Block: 0x00
  • +
  • Byzantium Block: 0x00
  • +
  • Constantinople Block: 0x00
  • +
  • Constantinople Fix Block: 0x00
  • +
  • Istanbul Block: 0x00
  • +
  • Muir Glacier Block: 0x00
  • +
  • Berlin Block: 0x00
  • +
  • London Block: 0x05
  • +
+

"London"

+
    +
  • Chain ID: 0x01
  • +
  • Homestead Block: 0x00
  • +
  • EIP150 Block: 0x00
  • +
  • EIP155 Block: 0x00
  • +
  • EIP158 Block: 0x00
  • +
  • DAO Fork Block: 0x00
  • +
  • Byzantium Block: 0x00
  • +
  • Constantinople Block: 0x00
  • +
  • Constantinople Fix Block: 0x00
  • +
  • Istanbul Block: 0x00
  • +
  • Muir Glacier Block: 0x00
  • +
  • Berlin Block: 0x00
  • +
  • London Block: 0x00
  • +
+

"ArrowGlacier"

+
    +
  • Chain ID: 0x01
  • +
  • Homestead Block: 0x00
  • +
  • EIP150 Block: 0x00
  • +
  • EIP155 Block: 0x00
  • +
  • EIP158 Block: 0x00
  • +
  • DAO Fork Block: 0x00
  • +
  • Byzantium Block: 0x00
  • +
  • Constantinople Block: 0x00
  • +
  • Constantinople Fix Block: 0x00
  • +
  • Istanbul Block: 0x00
  • +
  • Muir Glacier Block: 0x00
  • +
  • Berlin Block: 0x00
  • +
  • London Block: 0x00
  • +
  • Arrow Glacier Block: 0x00
  • +
+

"GrayGlacier"

+
    +
  • Chain ID: 0x01
  • +
  • Homestead Block: 0x00
  • +
  • EIP150 Block: 0x00
  • +
  • EIP155 Block: 0x00
  • +
  • EIP158 Block: 0x00
  • +
  • DAO Fork Block: 0x00
  • +
  • Byzantium Block: 0x00
  • +
  • Constantinople Block: 0x00
  • +
  • Constantinople Fix Block: 0x00
  • +
  • Istanbul Block: 0x00
  • +
  • Muir Glacier Block: 0x00
  • +
  • Berlin Block: 0x00
  • +
  • London Block: 0x00
  • +
  • Arrow Glacier Block: 0x00
  • +
  • Gray Glacier Block: 0x00
  • +
+

"Merge"

+
    +
  • Chain ID: 0x01
  • +
  • Homestead Block: 0x00
  • +
  • EIP150 Block: 0x00
  • +
  • EIP155 Block: 0x00
  • +
  • EIP158 Block: 0x00
  • +
  • DAO Fork Block: 0x00
  • +
  • Byzantium Block: 0x00
  • +
  • Constantinople Block: 0x00
  • +
  • Constantinople Fix Block: 0x00
  • +
  • Istanbul Block: 0x00
  • +
  • Muir Glacier Block: 0x00
  • +
  • Berlin Block: 0x00
  • +
  • London Block: 0x00
  • +
  • Arrow Glacier Block: 0x00
  • +
  • Gray Glacier Block: 0x00
  • +
  • Terminal Total Difficulty: 0x00
  • +
+

"MergeToShanghaiAtTime15k"

+
    +
  • Chain ID: 0x01
  • +
  • Homestead Block: 0x00
  • +
  • EIP150 Block: 0x00
  • +
  • EIP155 Block: 0x00
  • +
  • EIP158 Block: 0x00
  • +
  • DAO Fork Block: 0x00
  • +
  • Byzantium Block: 0x00
  • +
  • Constantinople Block: 0x00
  • +
  • Constantinople Fix Block: 0x00
  • +
  • Istanbul Block: 0x00
  • +
  • Muir Glacier Block: 0x00
  • +
  • Berlin Block: 0x00
  • +
  • London Block: 0x00
  • +
  • Arrow Glacier Block: 0x00
  • +
  • Gray Glacier Block: 0x00
  • +
  • Terminal Total Difficulty: 0x00
  • +
  • Shanghai Time: 0x3a98
  • +
+

"Shanghai"

+
    +
  • Chain ID: 0x01
  • +
  • Homestead Block: 0x00
  • +
  • EIP150 Block: 0x00
  • +
  • EIP155 Block: 0x00
  • +
  • EIP158 Block: 0x00
  • +
  • DAO Fork Block: 0x00
  • +
  • Byzantium Block: 0x00
  • +
  • Constantinople Block: 0x00
  • +
  • Constantinople Fix Block: 0x00
  • +
  • Istanbul Block: 0x00
  • +
  • Muir Glacier Block: 0x00
  • +
  • Berlin Block: 0x00
  • +
  • London Block: 0x00
  • +
  • Arrow Glacier Block: 0x00
  • +
  • Gray Glacier Block: 0x00
  • +
  • Terminal Total Difficulty: 0x00
  • +
  • Shanghai Time: 0x00
  • +
+

"ShanghaiToCancunAtTime15k"

+
    +
  • Chain ID: 0x01
  • +
  • Homestead Block: 0x00
  • +
  • EIP150 Block: 0x00
  • +
  • EIP155 Block: 0x00
  • +
  • EIP158 Block: 0x00
  • +
  • DAO Fork Block: 0x00
  • +
  • Byzantium Block: 0x00
  • +
  • Constantinople Block: 0x00
  • +
  • Constantinople Fix Block: 0x00
  • +
  • Istanbul Block: 0x00
  • +
  • Muir Glacier Block: 0x00
  • +
  • Berlin Block: 0x00
  • +
  • London Block: 0x00
  • +
  • Arrow Glacier Block: 0x00
  • +
  • Gray Glacier Block: 0x00
  • +
  • Terminal Total Difficulty: 0x00
  • +
  • Shanghai Time: 0x0
  • +
  • Cancun Time: 0x3a98
  • +
+

"Cancun"

+
    +
  • Chain ID: 0x01
  • +
  • Homestead Block: 0x00
  • +
  • EIP150 Block: 0x00
  • +
  • EIP155 Block: 0x00
  • +
  • EIP158 Block: 0x00
  • +
  • DAO Fork Block: 0x00
  • +
  • Byzantium Block: 0x00
  • +
  • Constantinople Block: 0x00
  • +
  • Constantinople Fix Block: 0x00
  • +
  • Istanbul Block: 0x00
  • +
  • Muir Glacier Block: 0x00
  • +
  • Berlin Block: 0x00
  • +
  • London Block: 0x00
  • +
  • Arrow Glacier Block: 0x00
  • +
  • Gray Glacier Block: 0x00
  • +
  • Terminal Total Difficulty: 0x00
  • +
  • Shanghai Time: 0x00
  • +
  • Cancun Time: 0x00
  • +
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/running_tests/test_formats/exceptions/index.html b/docs/public/main/running_tests/test_formats/exceptions/index.html new file mode 100644 index 00000000000..266e64995ee --- /dev/null +++ b/docs/public/main/running_tests/test_formats/exceptions/index.html @@ -0,0 +1,1303 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

+
+ +
+

Exceptions

+

Exception types are represented as a JSON string in the test fixtures.

+

The exception converted into a string is composed of the exception type name, +followed by a period, followed by the specific exception name.

+

For example, the exception INSUFFICIENT_ACCOUNT_FUNDS of type +TransactionException is represented as +"TransactionException.INSUFFICIENT_ACCOUNT_FUNDS".

+

The JSON string can contain multiple exception types, separated by the | +character, denoting that the transaction or block can throw either one of +the exceptions.

+

For a list of all defined exceptions look at Ethereum Test Exceptions Package.

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/running_tests/test_formats/index.html b/docs/public/main/running_tests/test_formats/index.html new file mode 100644 index 00000000000..97eae8eff98 --- /dev/null +++ b/docs/public/main/running_tests/test_formats/index.html @@ -0,0 +1,619 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
+ + + + +
+
+

+
+ + +
+

Test Fixture Specifications

+

The following sub-sections provide:

+
    +
  • Specifications for each test fixture format with an explanation of each field and its type.
  • +
  • Guides on how to consume each format.
  • +
+
+
+
+
+
+ +
+ + + + + + + diff --git a/docs/public/main/running_tests/test_formats/main/index.html b/docs/public/main/running_tests/test_formats/main/index.html new file mode 100644 index 00000000000..817bdc0dd81 --- /dev/null +++ b/docs/public/main/running_tests/test_formats/main/index.html @@ -0,0 +1,1298 @@ + + + + + + + Test Formats - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

Test Formats

+
+ +
+

Test Fixture Specifications

+

The following sub-sections provide:

+
    +
  • Specifications for each test fixture format with an explanation of each field and its type.
  • +
  • Guides on how to consume each format.
  • +
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/running_tests/test_formats/state_test/index.html b/docs/public/main/running_tests/test_formats/state_test/index.html new file mode 100644 index 00000000000..53f5d4a6149 --- /dev/null +++ b/docs/public/main/running_tests/test_formats/state_test/index.html @@ -0,0 +1,1429 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

+
+ +
+

State Tests

+

The State Test fixture format tests are included in the fixtures subdirectory state_tests.

+

These are produced by the StateTest and StateTestOnly test specs.

+

Description

+

The state test fixture format is used to test the state transition function of the Ethereum Virtual Machine (EVM).

+

It does so by defining a transaction, a pre-execution state, and a post-execution state, and verifying that the transaction execution results in the expected post-execution state.

+

A single JSON fixture file is composed of a JSON object where each key-value pair is a different Fixture test object, with the key string representing the test name.

+

The JSON file path plus the test name are used as the unique test identifier.

+

As opposed to other fixture formats, the state test fixture format could contain multiple test vectors per test object, each represented by an element in the mapping of lists of the post field.

+

However tests generated by the execution-spec-tests repository do not use this feature, as every single test object contains only a single test vector.

+

Consumption

+

For each Fixture test object in the JSON fixture file, perform the following steps:

+
    +
  1. +

    Use pre as the starting state allocation of the execution environment for the test.

    +
  2. +
  3. +

    Use env to configure the current execution environment.

    +
  4. +
  5. +

    For each Fork key of post in the test, and for each of the elements of the list of FixtureForkPost values:

    +
      +
    1. +

      Configure the execution fork schedule according to the current Fork key.

      +
    2. +
    3. +

      Using the indexes values, and the transaction object, decode the transaction to be executed.

      +
    4. +
    5. +

      If the serialized version of the decoded transaction does not match txbytes, fail the test.

      +
    6. +
    7. +

      Attempt to apply the transaction using the current execution environment:

      +
        +
      1. If the transaction could not be applied to the current execution context: + +
      2. +
      3. If the transaction could be applied to the current execution context: + +
      4. +
      +
    8. +
    9. +

      Compare the resulting post-state root with the expected post-state root contained in the hash field of the current FixtureForkPost, and fail the test if they do not match.

      +
    10. +
    11. +

      Compare the resulting logs hash with the expected logs contained in the logs field of the current FixtureForkPost, and fail the test if they do not match.

      +
    12. +
    +
  6. +
+

Structures

+

Fixture

+

- env: FixtureEnvironment

+

Execution environment description for the test.

+

- pre: Alloc

+

Starting account allocation for the test.

+

- transaction: FixtureTransaction

+

Transaction to be executed.

+

- post: Mapping(Fork,List[ FixtureForkPost ])

+

Mapping of lists of post for verification per fork, where each element represents a single possible outcome of the transaction execution after being applied to the pre.

+

- config: FixtureConfig

+

Chain configuration object.

+

FixtureConfig

+

At the moment this object can contain only the blobSchedule that is necessary to apply the correct cap to the maximum amount of blobs that a transaction can have. Otherwise, in forks prior to Cancun for example, it will be an empty JSON object.

+

- blobSchedule: BlobSchedule

+

Optional; present from Cancun on. Maps forks to their blob schedule configurations as defined by EIP-7840.

+

FixtureEnvironment

+

- currentCoinbase: Address

+

The address of the account that will receive the rewards for building the block.

+

- currentGasLimit: ZeroPaddedHexNumber

+

Total gas limit of the block where the transaction is executed.

+

- currentNumber: ZeroPaddedHexNumber

+

Number of the block where the transaction is executed.

+

- currentDifficulty: ZeroPaddedHexNumber

+

Difficulty of the block where the transaction is executed.

+

- currentTimestamp: ZeroPaddedHexNumber

+

Timestamp of the block where the transaction is executed.

+

- currentBaseFee: ZeroPaddedHexNumber (fork: London)

+

Base fee of the block where the transaction is executed.

+

- currentRandom: Hash (fork: Paris)

+

Randao value of the block where the transaction is executed.

+

- currentExcessBlobGas: ZeroPaddedHexNumber (fork: Cancun)

+

Excess blob gas of the block where the transaction is executed.

+

FixtureTransaction

+

- nonce: ZeroPaddedHexNumber

+

Nonce of the account that sends the transaction

+

- gasPrice: ZeroPaddedHexNumber

+

Gas price for the transaction (Transaction types 0 & 1)

+

- maxPriorityFeePerGas: HexNumber

+

Max priority fee per gas to pay (Transaction types 2 & 3)

+

- maxFeePerGas: HexNumber

+

Max base fee per gas to pay (Transaction types 2 & 3)

+

- gasLimit: List[ZeroPaddedHexNumber]

+

List of gas limits used on each indexed test combination

+

- to: Address|EmptyAddress

+

Destination address of the transaction, or an empty string to create a contract

+

- value: List[ZeroPaddedHexNumber]

+

List of values used on each indexed test combination

+

- data: List[Bytes]

+

List of data bytes used on each indexed test combination

+

- accessLists: List[List[Mapping[Address,List[Hash]]]] (fork: Berlin)

+

List of account access lists used on each indexed test combination (Transaction types 1, 2 & 3)

+

- maxFeePerBlobGas: HexNumber (fork: Cancun)

+

Max fee per blob gas to pay (Transaction type 3)

+

- blobVersionedHashes: List[Hash] (fork: Cancun)

+

List of blob versioned hashes the transaction includes (Transaction type 3)

+

- sender: Address

+

Sender address of the transaction

+

- secretKey: Hash

+

Private key that must be used to sign the transaction

+

FixtureForkPost

+

- indexes: FixtureForkPostIndexes

+

Transaction field indexes that must be used to obtain the transaction to be executed

+

- txbytes: Bytes

+

Serialized bytes version of the FixtureTransaction that was executed to produce this post-state

+

- hash: Hash

+

Expected state root value that results of applying the transaction to the pre-state

+

- logs: Hash

+

Hash of the RLP representation of the state logs result of applying the transaction to the pre-state +(TODO: double-check this.)

+

- expectException: TransactionException

+

Exception that is expected to be thrown by the transaction execution (Field is missing if the transaction is expected to succeed)

+

- state: Alloc

+

Dictionary that represents the allocation after execution of the transaction.

+

FixtureForkPostIndexes

+

- data: int

+

Index of the data field in the transaction

+

- gas: int

+

Index of the gas limit field in the transaction

+

- value: int

+

Index of the value field in the transaction

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/running_tests/test_formats/transaction_test/index.html b/docs/public/main/running_tests/test_formats/transaction_test/index.html new file mode 100644 index 00000000000..532b399713b --- /dev/null +++ b/docs/public/main/running_tests/test_formats/transaction_test/index.html @@ -0,0 +1,1345 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

+
+ +
+

Transaction Tests

+

The Transaction Test fixture format tests are included in the fixtures subdirectory transaction_tests.

+

These are produced by the TransactionTest test spec.

+

Description

+

The transaction test fixture format is used to test client’s transaction RLP parsing without executing the transaction on the EVM.

+

It does so by defining a transaction binary RLP representation, and whether the transaction should be accepted or rejected by the client in each fork.

+

A single JSON fixture file is composed of a JSON object where each key-value pair is a different Fixture test object, with the key string representing the test name.

+

The JSON file path plus the test name are used as the unique test identifier.

+

The transaction test fixture format could contain multiple test vectors per test object, each represented by an element in the mapping of lists of the result field.

+

However tests generated by the execution-spec-tests repository do not use this feature, as every single test object contains only a single test vector.

+

Consumption

+

For each Fixture test object in the JSON fixture file, perform the following steps:

+
    +
  1. +

    Obtain the txbytes serialized bytes of the transaction to be parsed.

    +
  2. +
  3. +

    For each Fork key of result in the test:

    +
      +
    1. Assume the fork schedule according to the current Fork key.
    2. +
    3. Using the txbytes, attempt to decode the transaction.
    4. +
    5. If the transaction could not be decoded: +
        +
      • If the hash field is present, fail the test.
      • +
      • Compare the exception thrown with the expected exception contained in the exception field, and fail the test if they do not match.
      • +
      • Proceed to the next fork.
      • +
      +
    6. +
    7. If the transaction could be decoded: +
        +
      • Compare the calculated hash with the expected hash contained in the hash field, and fail the test if they do not match.
      • +
      • Compare the calculated intrinsic gas with the expected intrinsic gas contained in the intrinsicGas field, and fail the test if they do not match.
      • +
      • Compare the calculated sender with the expected sender contained in the sender field, and fail the test if they do not match.
      • +
      +
    8. +
    +
  4. +
+

Structures

+

Fixture

+

- txbytes: Bytes

+

Serialized bytes of the transaction under test.

+

- result: Mapping[Fork,FixtureResult ]

+

Mapping of results for verification per fork, where each key-value represents a single possible outcome of the transaction parsed in the given fork.

+

FixtureResult

+

- hash: Hash | None

+

Calculated hash of the transaction (Field is missing if the transaction is expected to fail).

+

- intrinsicGas: ZeroPaddedHexNumber

+

Total intrinsic gas cost of the transaction (Field is missing if the transaction is expected to fail).

+

- sender: Address

+

Sender address of the transaction (Field is missing if the transaction is expected to fail).

+

- exception: TransactionException

+

Exception that is expected to be thrown by the transaction parsing (Field is missing if the transaction is expected to succeed).

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/running_tests/useful_pytest_options/index.html b/docs/public/main/running_tests/useful_pytest_options/index.html new file mode 100644 index 00000000000..967a5999291 --- /dev/null +++ b/docs/public/main/running_tests/useful_pytest_options/index.html @@ -0,0 +1,1485 @@ + + + + + + + Useful Pytest Options - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

Useful Pytest Options

+
+ +
+

The EEST commands to run tests are customizations to the pytest framework, which provides many helpful options for test selection, parallel execution, report output and debugging. This section provides the most relevant options, a full overview is available in the pytest docs.

+

Fixture Inputs (Consume Commands)

+

See Consume Cache and Fixture Inputs.

+

Dry-Run

+

List collected tests, -q restricts output to test IDs only:

+
uv run consume engine --input=<fixture_input> --collect-only -q
+

In ./hive standalone mode, this can be achieved via EEST’s --sim.limit “collectonly” prefix.

+

Output Control

+
    +
  • -v - verbose output.
  • +
  • -vv - more verbose output.
  • +
  • -s - print stdout to the terminal during execution (don’t capture it).
  • +
  • --eest-log-level=<LOG_LEVEL> - write logs during test (helpful in combination with -s).
  • +
+

Report Generation

+

JSON, HTML and XML reports can be generated with:

+
    --json-report \
+    --json-report-file=report.json \
+    --html=report.html \
+    --junitxml=report.xml
+

Test Case Selection Using Test IDs

+

In addition to Hive’s regex-based --sim.limit option, running in dev mode supports pytest’s -k syntax:

+
uv run consume rlp -k "test_chainid and fork_London"
+uv run consume engine -k "eip1559 or eip4844" -m cancun
+

Use --collect-only -q to see which tests would run without executing them:

+
uv run consume engine --collect-only -q -k "fork_Prague"
+

Test Case Selection using Marks

+

Select tests based on pytest marks.

+

Run only state tests:

+
uv run consume direct --input=<fixture_input> -m state_test
+

Run blockchain tests for specific fork:

+
uv run consume engine --input=<fixture_input> -m "blockchain_test and cancun"
+

Combine marks with keyword filtering:

+
uv run consume engine --input=<fixture_input> -m "blockchain_test" -k "eip4844 or blob"
+
+ +
+
Mark Availability
+
+ Not all test marks are available with consume commands. Fork and test type marks work reliably. +
+
+

Parallel Execution

+

Speed up test execution by running tests in parallel using pytest-xdist.

+

Auto-detect CPU count:

+
uv run consume engine --input=<fixture_input> -n auto
+

Specify worker count:

+
uv run consume direct --input=<fixture_input> -n 4
+

Dropping in the Python Debugger

+

Dropping into the Python debugger can be helpful to inspect EEST simulator state or ssh to a client container. Adding the --pdb option will drop into Python debugger upon test failure, -x tells pytest to exit after the first fail:

+
uv run consume engine --pdb -x ...
+

PDB Cheatsheet

+
    +
  • u β†’ up the stack
  • +
  • d β†’ down the stack
  • +
  • l β†’ list lines around current position
  • +
  • ll β†’ list entire function body
  • +
  • p β†’ print expression
  • +
  • pp β†’ pretty-print expression
  • +
+

Sometimes pp is not enough and it’s worth importing rich (import rich) in pdb and doing a rich.print(obj).

+

Early Exit Options

+

Stop after first failure:

+
uv run consume engine --input=<fixture_input> -x
+

Stop after N failures:

+
uv run consume rlp --input=<fixture_input> --maxfail=3
+

Performance and Timing

+

Show slowest tests:

+
uv run consume engine --input=<fixture_input> --durations=10
+

Show all test durations:

+
uv run consume rlp --input=<fixture_input> --durations=0
+

Timeout control (per test):

+
uv run consume direct --input=<fixture_input> --timeout=30
+

Print relevant test stage timings such as client start-up, payload response time (consume only):

+
uv run consume engine --input=<fixture_input> --timing-data
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/setup_vs_code/index.html b/docs/public/main/setup_vs_code/index.html new file mode 100644 index 00000000000..d040612aa10 --- /dev/null +++ b/docs/public/main/setup_vs_code/index.html @@ -0,0 +1,1323 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

VS Code Setup

+

VS Code setup is optional, but does offer the following advantages:

+
    +
  • Auto-format your Python code to conform to the repository’s code standards (ruff).
  • +
  • Inline linting and auto-completion (thanks to Python type hints).
  • +
  • Spell-check your code and docs.
  • +
  • Graphical exploration of test cases and easy test execution/debug.
  • +
+

Installation

+

Please refer to the Visual Studio Code docs for help with installation.

+

VS Code Settings file

+

The ethereum/execution-spec-tests repo includes configuration files for VS Code in the .vscode/ sub-directory:

+
πŸ“ execution-test-specs/
+β””β”€β”€πŸ“ .vscode/
+    β”œβ”€β”€ πŸ“„ settings.json
+    β”œβ”€β”€ πŸ“„ extensions.json
+    └── πŸ“„ launch.recommended.json
+

By default, the repository settings are applied via .vscode/settings.json.

+

To enable the recommended launch configurations (that include some useful debugging configurations), copy the recommended launch configuration file to .vscode/launch.json:

+
cp .vscode/launch.recommended.json .vscode/launch.json
+

VS Code Extension Configuration

+

The extensions listed in .vscode/extensions.json are required for a smooth developer experience.

+
    +
  1. +

    Open the root folder of your local execution-spec-tests clone in VS Code, it will prompt you to install the repository’s required extensions (from .vscode/extensions.json - you will be required to trust the executions-spec-tests repository first). These extensions are used to format, lint, type check and run tests on the codebase. After all the required extensions are installed a VS Code reload will be required.

    +
  2. +
  3. +

    If previously installed, ensure that the following ms-python extensions are disabled for the execution-spec-tests workspace to ensure there are no conflicts with the ruff formatter. In the VS Code Extensions tab, search for the each of the extensions below, and if installed and enabled, open the “Disabled” menu and select “Disable (Workspace)”. This ensures that the extensions will be available with other workspaces that may need them.

    + +
    + ![Disabling extensions for the current workspace](./img/vscode_extension_disable_for_workspace.png){width=auto align=center} +
    +
  4. +
+

Configuration for Testing EVM Features Under Active Development

+

An additional step is required to enable fixture generations for features from forks that are under active development and have not been deployed to mainnet, see Filling Tests for Features under Development.

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/simulators/index.html b/docs/public/main/simulators/index.html new file mode 100644 index 00000000000..79aa7b0118e --- /dev/null +++ b/docs/public/main/simulators/index.html @@ -0,0 +1,1264 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

Consume Simulators

+

The engine and rlp simulators test clients by importing blocks through different interfaces. These simulators run within the Hive testing framework to provide containerized, isolated testing environments.

+

Command Syntax

+
uv run consume <engine|rlp> [OPTIONS]
+

Relevant Information

+ +
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/state_test/index.html b/docs/public/main/state_test/index.html new file mode 100644 index 00000000000..f96758ae5fc --- /dev/null +++ b/docs/public/main/state_test/index.html @@ -0,0 +1,1435 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

State Tests

+

The State Test fixture format tests are included in the fixtures subdirectory state_tests.

+

These are produced by the StateTest and StateTestOnly test specs.

+

Description

+

The state test fixture format is used to test the state transition function of the Ethereum Virtual Machine (EVM).

+

It does so by defining a transaction, a pre-execution state, and a post-execution state, and verifying that the transaction execution results in the expected post-execution state.

+

A single JSON fixture file is composed of a JSON object where each key-value pair is a different Fixture test object, with the key string representing the test name.

+

The JSON file path plus the test name are used as the unique test identifier.

+

As opposed to other fixture formats, the state test fixture format could contain multiple test vectors per test object, each represented by an element in the mapping of lists of the post field.

+

However tests generated by the execution-spec-tests repository do not use this feature, as every single test object contains only a single test vector.

+

Consumption

+

For each Fixture test object in the JSON fixture file, perform the following steps:

+
    +
  1. +

    Use pre as the starting state allocation of the execution environment for the test.

    +
  2. +
  3. +

    Use env to configure the current execution environment.

    +
  4. +
  5. +

    For each Fork key of post in the test, and for each of the elements of the list of FixtureForkPost values:

    +
      +
    1. +

      Configure the execution fork schedule according to the current Fork key.

      +
    2. +
    3. +

      Using the indexes values, and the transaction object, decode the transaction to be executed.

      +
    4. +
    5. +

      If the serialized version of the decoded transaction does not match txbytes, fail the test.

      +
    6. +
    7. +

      Attempt to apply the transaction using the current execution environment:

      +
        +
      1. If the transaction could not be applied to the current execution context: + +
      2. +
      3. If the transaction could be applied to the current execution context: + +
      4. +
      +
    8. +
    9. +

      Compare the resulting post-state root with the expected post-state root contained in the hash field of the current FixtureForkPost, and fail the test if they do not match.

      +
    10. +
    11. +

      Compare the resulting logs hash with the expected logs contained in the logs field of the current FixtureForkPost, and fail the test if they do not match.

      +
    12. +
    +
  6. +
+

Structures

+

Fixture

+

- env: FixtureEnvironment

+

Execution environment description for the test.

+

- pre: Alloc

+

Starting account allocation for the test.

+

- transaction: FixtureTransaction

+

Transaction to be executed.

+

- post: Mapping(Fork,List[ FixtureForkPost ])

+

Mapping of lists of post for verification per fork, where each element represents a single possible outcome of the transaction execution after being applied to the pre.

+

- config: FixtureConfig

+

Chain configuration object.

+

FixtureConfig

+

At the moment this object can contain only the blobSchedule that is necessary to apply the correct cap to the maximum amount of blobs that a transaction can have. Otherwise, in forks prior to Cancun for example, it will be an empty JSON object.

+

- blobSchedule: BlobSchedule

+

Optional; present from Cancun on. Maps forks to their blob schedule configurations as defined by EIP-7840.

+

FixtureEnvironment

+

- currentCoinbase: Address

+

The address of the account that will receive the rewards for building the block.

+

- currentGasLimit: ZeroPaddedHexNumber

+

Total gas limit of the block where the transaction is executed.

+

- currentNumber: ZeroPaddedHexNumber

+

Number of the block where the transaction is executed.

+

- currentDifficulty: ZeroPaddedHexNumber

+

Difficulty of the block where the transaction is executed.

+

- currentTimestamp: ZeroPaddedHexNumber

+

Timestamp of the block where the transaction is executed.

+

- currentBaseFee: ZeroPaddedHexNumber (fork: London)

+

Base fee of the block where the transaction is executed.

+

- currentRandom: Hash (fork: Paris)

+

Randao value of the block where the transaction is executed.

+

- currentExcessBlobGas: ZeroPaddedHexNumber (fork: Cancun)

+

Excess blob gas of the block where the transaction is executed.

+

FixtureTransaction

+

- nonce: ZeroPaddedHexNumber

+

Nonce of the account that sends the transaction

+

- gasPrice: ZeroPaddedHexNumber

+

Gas price for the transaction (Transaction types 0 & 1)

+

- maxPriorityFeePerGas: HexNumber

+

Max priority fee per gas to pay (Transaction types 2 & 3)

+

- maxFeePerGas: HexNumber

+

Max base fee per gas to pay (Transaction types 2 & 3)

+

- gasLimit: List[ZeroPaddedHexNumber]

+

List of gas limits used on each indexed test combination

+

- to: Address|EmptyAddress

+

Destination address of the transaction, or an empty string to create a contract

+

- value: List[ZeroPaddedHexNumber]

+

List of values used on each indexed test combination

+

- data: List[Bytes]

+

List of data bytes used on each indexed test combination

+

- accessLists: List[List[Mapping[Address,List[Hash]]]] (fork: Berlin)

+

List of account access lists used on each indexed test combination (Transaction types 1, 2 & 3)

+

- maxFeePerBlobGas: HexNumber (fork: Cancun)

+

Max fee per blob gas to pay (Transaction type 3)

+

- blobVersionedHashes: List[Hash] (fork: Cancun)

+

List of blob versioned hashes the transaction includes (Transaction type 3)

+

- sender: Address

+

Sender address of the transaction

+

- secretKey: Hash

+

Private key that must be used to sign the transaction

+

FixtureForkPost

+

- indexes: FixtureForkPostIndexes

+

Transaction field indexes that must be used to obtain the transaction to be executed

+

- txbytes: Bytes

+

Serialized bytes version of the FixtureTransaction that was executed to produce this post-state

+

- hash: Hash

+

Expected state root value that results of applying the transaction to the pre-state

+

- logs: Hash

+

Hash of the RLP representation of the state logs result of applying the transaction to the pre-state +(TODO: double-check this.)

+

- expectException: TransactionException

+

Exception that is expected to be thrown by the transaction execution (Field is missing if the transaction is expected to succeed)

+

- state: Alloc

+

Dictionary that represents the allocation after execution of the transaction.

+

FixtureForkPostIndexes

+

- data: int

+

Index of the data field in the transaction

+

- gas: int

+

Index of the gas limit field in the transaction

+

- value: int

+

Index of the value field in the transaction

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/state_transition/index.html b/docs/public/main/state_transition/index.html new file mode 100644 index 00000000000..56aedba075e --- /dev/null +++ b/docs/public/main/state_transition/index.html @@ -0,0 +1,1342 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

State Transition Tests

+

This tutorial teaches you to create a state transition execution specification test using the Python Opcodes minilang for writing EVM bytecode. These tests verify that a starting pre-state will reach a specified post-state after executing a single transaction. In this example, we’ll create a simple contract using bytecode and then interact with it through a transaction to verify the expected state changes.

+

For an overview of different test types available, see Types of Tests.

+

Pre-requisites

+

This tutorial will require some prior knowledge and experience with the following:

+ +

Building a State Test

+

The most effective method of learning how to write tests is to study a straightforward example. In this tutorial we will build a simple state test that deploys a contract with bytecode and verifies its execution.

+

Complete Test Example

+

We’ll examine a simple test that uses the Python Opcodes minilang to write EVM bytecode. This example is based on the CHAINID opcode test from tests/istanbul/eip1344_chainid/test_chainid.py.

+

Let’s examine each section.

+
"""State test tutorial demonstrating contract deployment and interaction."""
+

In Python, multi-line strings are denoted using """. As a convention, a file’s purpose is often described in the opening string of the file.

+
import pytest
+
+from ethereum_test_tools import Account, Alloc, Environment, StateTestFiller, Transaction
+from ethereum_test_tools.vm.opcode import Opcodes as Op
+

In this snippet the required constants, types and helper functions are imported from ethereum_test_tools. The Opcodes class (aliased as Op) provides the Python minilang for writing EVM bytecode. We will go over these as we come across them.

+
@pytest.mark.valid_from("Istanbul")
+

In Python this kind of definition is called a decorator. +It modifies the action of the function after it. +In this case, the decorator is a custom pytest mark defined by the execution-specs-test framework that specifies that the test is valid for the Istanbul fork and all forks after it. The framework will then fill this test case for all forks in the fork range specified by the command-line arguments.

+

For more information about test markers and fork validity, see Test Markers.

+ + +
+
Filling the test
+
+

To fill this test for all the specified forks, we can specify pytest’s -k flag that filters test cases by keyword expression:

+
fill -k test_state_test_example
+

and to fill it for a specific fork range, we can provide the --from and --until command-line arguments:

+
fill -k test_state_test_example --from London --until Paris
+
+
+
+
def test_state_test_example(state_test: StateTestFiller, pre: Alloc):
+    """Test state transition using Opcodes minilang bytecode."""
+

This is the format of a Python function. +It starts with def <function name>(<parameters>):, and then has indented code for the function. +The function definition ends when there is a line that is no longer indented. As with files, by convention functions start with a string that explains what the function does.

+

The function parameters (state_test and pre) are pytest fixtures provided by the execution-spec-tests framework. Pytest fixtures are a powerful dependency injection mechanism that automatically provide objects to your test functions.

+

The state_test fixture is a callable that you must include in state test function arguments. When called at the end of your test function with the environment, pre-state, transaction, and expected post-state, it generates the actual test fixtures. This callable is a wrapper around the StateTest class.

+

The pre fixture provides an Alloc object that manages the pre-state allocation for your test. It offers methods like fund_eoa() and deploy_contract() that automatically generate unique addresses and add accounts to the blockchain state that will exist before your transaction executes. The fixture handles address generation and ensures no conflicts occur.

+
    env = Environment(number=1)
+

This line specifies that env is an [Environment][ethereum_test_types.Environment] object. In this example, we only override the block number to 1, leaving all other values at their defaults. It’s recommended to use default values whenever possible and only specify custom values when required for your specific test scenario. (For all available fields, see the pydantic model fields in the source code of [Environment][ethereum_test_types.Environment] and EnvironmentGeneric from which Environment inherits.)

+

Pre State

+

For every test we need to define the pre-state requirements, so we are certain of what is on the “blockchain” before the transaction is executed. The pre fixture provides an Alloc object with methods to create accounts that are automatically added to the pre-state.

+

In this example we are using the deploy_contract method to deploy a contract to some address available in the pre-state.

+
    contract_address = pre.deploy_contract(
+        code=Op.PUSH1(0x03) + Op.PUSH1(0x00) + Op.SSTORE + Op.STOP
+    )
+

Specifically we deploy a contract written with Opcodes minilang code that stores the value 0x03 at storage slot 0x00. The code consists of:

+
    +
  • PUSH1(0x03): Push the value 3 onto the stack.
  • +
  • PUSH1(0x00): Push the storage key 0 onto the stack.
  • +
  • SSTORE: Store the value at the specified key.
  • +
  • STOP: End execution.
  • +
+

As the return value of the deploy_contract method, we get the address where the contract was deployed. This address is stored in the contract_address variable, which will later be used as the target of our transaction.

+

You can also specify additional parameters for the contract if needed:

+
    +
  • balance parameter to set the contract’s initial balance (though often not necessary for state test contracts)
  • +
  • storage parameter to set initial storage values (though in this example we don’t need initial storage since our contract will set it through the SSTORE opcode)
  • +
+

You can combine opcodes using the + operator to create more complex bytecode sequences.

+

Generally for execution spec tests the SSTORE instruction acts as a high-level assertion method to check pre to post-state changes. The test filler achieves this by verifying that the correct value is held within post-state storage, hence we can validate that the bytecode has run successfully.

+

Next, we need to create an account that will send the transaction to our contract:

+
    sender = pre.fund_eoa()
+

This line creates a single externally owned account (EOA) with a default balance. You can specify a custom amount with amount=0x0BA1A9CE0BA1A9CE if needed.

+

The returned object, which includes a private key, an address, and a nonce, is stored in the sender variable and will later be used as the sender of the transaction.

+

Transactions

+
    tx = Transaction(
+        ty=0x2,
+        sender=sender,
+        to=contract_address,
+        gas_limit=100_000,
+    )
+

With the pre-state built, we can now create the transaction that will call our contract. Let’s examine the key components of this [Transaction][ethereum_test_types.Transaction] (for all available fields, see the source code of [Transaction][ethereum_test_types.Transaction] and TransactionGeneric from which Transaction inherits).

+
    +
  • +

    sender=sender: We use the EOA we created earlier, which already has the necessary information to sign the transaction and contains the correct nonce. The nonce is a protection mechanism to prevent replay attacks - it must equal the number of transactions sent from the sender’s address, starting from zero. The framework automatically manages nonce incrementing for us.

    +
  • +
  • +

    to=contract_address: This specifies the address of the contract we want to call, which is the contract we deployed earlier.

    +
  • +
  • +

    gas_limit=100_000: This sets a high enough gas limit to ensure our simple contract execution doesn’t run out of gas.

    +
  • +
  • +

    ty=0x2: This specifies the transaction type (EIP-1559).

    +
  • +
+

Post State

+

Now we need to define what we expect the blockchain state to look like after our transaction executes:

+
    post = {
+        contract_address: Account(
+            storage={
+                0x00: 0x03,
+            },
+        ),
+    }
+

This is the post-state which is equivalent to expect in static tests, but without the indexes. It is similar to the pre-state, except that we do not need to specify everything, only those accounts and fields we wish to test.

+

In this case, we look at the storage of the contract we called and add to it what we expect to see. In this example storage cell 0x00 should be 0x03 as we stored this value using the SSTORE opcode in our contract bytecode.

+

Running the State Test

+

Finally, we execute the test by calling the state test wrapper with all our defined components:

+
    state_test(env=env, pre=pre, post=post, tx=tx)
+

This line calls the wrapper to the StateTest object that provides all the objects required in order to fill the test, generate the test fixtures and write them to file (by default, ./fixtures/<blockchain,state>_tests/example/state_test_example/test_state_test_example.json).

+

Note that even though we defined a StateTest, the fill command will also generate other derivative test fixtures: BlockchainTest, BlockchainTestEngine, and BlockchainTestEngineX. For more information about test types and when to use each, see Test Types: Prefer StateTest for Single Transactions.

+

Conclusion

+

At this point you should be able to write state transition tests within a single block.

+

Next Steps

+
    +
  • Learn about Adding a New Test to understand test organization and structure.
  • +
  • Explore Fork Methods for writing tests that adapt to different Ethereum forks.
  • +
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/test_actions_locally/index.html b/docs/public/main/test_actions_locally/index.html new file mode 100644 index 00000000000..30c149ca6bf --- /dev/null +++ b/docs/public/main/test_actions_locally/index.html @@ -0,0 +1,1409 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

Running Github Actions Locally

+

The Github Actions workflows can be tested locally using nektos/act without pushing changes to the remote. The local repository state will be used in the executed workflow.

+

Prerequisites

+
    +
  1. +

    A docker installation without sudo prefix requirement (see also dockerdocs):

    +
    sudo usermod -aG docker $USER
    +
  2. +
  3. +

    Install the Github CLI (gh): linux, macos.

    +
  4. +
  5. +

    Authenticate your Github account with the Github CLI:

    +
    gh auth login
    +

    This is required to set GITHUB_TOKEN to the output of gh auth token when running the workflows.

    +
  6. +
  7. +

    Install the act tool as a Github extension (nektos/act docs):

    +
    gh extension install https://github.com/nektos/gh-act
    +

    or use one of the other available methods.

    +
  8. +
+ + +
+
Updating nektos/act to the latest version via the Github CLI
+
+

The act tool can be updated via the Github CLI:

+
gh extension upgrade nektos/act
+
+
+
+

Listing the Available Workflows

+
gh act --list
+

will output something similar to:

+
INFO[0000] Using docker host 'unix:///var/run/docker.sock', and daemon socket 'unix:///var/run/docker.sock'
+Stage  Job ID                Job name                                                      Workflow name                             Workflow file          Events                             
+0      evmone-coverage-diff  evmone-coverage-diff                                          Evmone Coverage Report                    coverage.yaml          pull_request                       
+0      deploy                deploy                                                        Deploy Docs Main                          docs_main.yaml         push                               
+0      deploy                deploy                                                        Deploy Docs Tags                          docs_tags.yaml         push                               
+0      features              features                                                      Build and Package Fixtures                fixtures.yaml          push,workflow_dispatch             
+0      feature-names         feature-names                                                 Build and Package Fixtures for a feature  fixtures_feature.yaml  push,workflow_dispatch             
+0      lint                  Lint python sources with ruff                                 Tox                                       tox_verify.yaml        push,pull_request,workflow_dispatch
+0      typecheck             Typecheck python sources with mypy                            Tox                                       tox_verify.yaml        push,pull_request,workflow_dispatch
+0      spellcheck            Spellcheck sources with pyspelling                            Tox                                       tox_verify.yaml        push,pull_request,workflow_dispatch
+0      markdownlint          Lint markdown files with markdownlint                         Tox                                       tox_verify.yaml        push,pull_request,workflow_dispatch
+0      mkdocs                Build html documentation with mkdocs                          Tox                                       tox_verify.yaml        push,pull_request,workflow_dispatch
+0      pytest_framework      Run unit tests, ${{ matrix.os }}, ${{ matrix.python }}        Tox                                       tox_verify.yaml        push,pull_request,workflow_dispatch
+0      tests_deployed        Fill tests, deployed, ${{ matrix.os }}, ${{ matrix.python }}  Tox                                       tox_verify.yaml        push,pull_request,workflow_dispatch
+1      build                 build                                                         Build and Package Fixtures                fixtures.yaml          push,workflow_dispatch             
+1      build                 build                                                         Build and Package Fixtures for a feature  fixtures_feature.yaml  push,workflow_dispatch             
+2      release               release                                                       Build and Package Fixtures                fixtures.yaml          push,workflow_dispatch             
+2      release               release                                                       Build and Package Fixtures for a feature  fixtures_feature.yaml  push,workflow_dispatch
+

The Job ID is required to run a specific workflow and is provided to the -j option of gh act.

+

Running Workflows that require Github Vars

+

Create a text file containing the required variables and variables, e.g., .act_github_vars (this is in .gitignore):

+
UV_VERSION=0.5.15
+DEFAULT_PYTHON_VERSION=3.12
+

and use the --var-file option to specify the file:

+
gh act --workflows .github/workflows/tox_verify.yaml -s GITHUB_TOKEN=$(gh auth token) --var-file=gh_vars.txt -j lint 
+

Running Workflows that use a Matrix Strategy

+

This is optional, recent versions will automatically detect the matrix strategy and run supported values. To run a specific matrix value, use the --matrix option:

+
gh act --workflows .github/workflows/tox_verify.yaml -s GITHUB_TOKEN=$(gh auth token) --matrix python:3.12 -j pytest_framework
+

Running Release Workflows

+

Release builds require the ref input to be specified. To test a release build locally:

+
    +
  1. +

    Create a JSON file specifying the input data required for a release build (the release tag), e.g, event.json:

    +
    {
    +    "ref": "refs/tags/stable@v4.2.0"
    +}
    +
  2. +
  3. +

    Run act and specify the workflow file, the Github token, and the event file:

    +
    gh act -j build --workflows .github/workflows/fixtures_feature.yaml -s GITHUB_TOKEN=$(gh auth token) -e event.json
    +
  4. +
+

Manually Specifying the Docker Image

+

It’s possible to specify the Docker image used by the act tool for a specific platform defined in a workflow using the -P (--platform) option. For example, use map ubuntu-latest in the workflow to use ubuntu-24.04:

+
-P ubuntu-latest=ubuntu:24.04
+

This can be added to any gh act command.

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/test_ids/index.html b/docs/public/main/test_ids/index.html new file mode 100644 index 00000000000..012f34bf919 --- /dev/null +++ b/docs/public/main/test_ids/index.html @@ -0,0 +1,1358 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

An explanation of test IDs generated by fill

+

Test Case Organization

+

Test cases are implemented in Python “modules”, which are organized by folder, named after the fork where the feature-under-test was introduced, for example:

+
    +
  • tests/cancun/ contains tests for features added in the Cancun hardfork.
  • +
  • tests/prague/ contains tests for features added in the Prague hardfork.
  • +
+

Test ID generation

+

A test ID is a string, generated by the test framework, that uniquely identifies a test case. It’s format is:

+
<python_test_module_path>::<python_test_function_name>[<parameter_1_id>-...-<parameter_N_id]
+

Let’s use the following simple test case example to understand this format:

+
tests/istanbul/eip1344_chainid/test_chainid.py::test_chainid[fork_Cancun-blockchain_test]
+

The components map as following:

+
    +
  • <python_test_module_path> - the Python “module” (file) where the test is implemented tests/istanbul/eip1344_chainid/test_chainid.py,
  • +
  • <python_test_function_name> - the Python test function: test_chainid,
  • +
  • [<parameter_1_id>-...-<parameter_N_id] - the test parameters, this test case has the following parameters: +
      +
    • fork_Cancun, to read “fork = Cancun”, the fork the test case is filled for,
    • +
    • blockchain_test, the test type.
    • +
    +
  • +
+

Although test_chainid is not directly parametrized on the test function level, the framework always parametrizes tests by fork and, if possible, by test type. If we inspect its function signature, we see that it’s native test format is of type StateTestFiller:

+
@pytest.mark.valid_from("Istanbul")
+def test_chainid(state_test: StateTestFiller, pre: Alloc):
+    """Test CHAINID opcode."""
+    ...
+

Parametrization by Fork

+

Every test case is parametrized by the fork where the feature-under-test remains valid, for example:

+
    +
  • Test cases in tests/cancun/ get filled for Cancun and Prague.
  • +
  • Test cases in tests/prague/, only get filled for Prague, at the time of writing, as Prague is the current fork in development.
  • +
+

All test IDs contain the fork_<name> parameter used to generate the test case in the test ID, e.g., test_Cancun.

+

Transition Forks

+

The test framework can also generate blockchain tests containing blocks that span a fork boundary, these test cases receive a special fork parameter name which contain both fork names and the timestamp at which the transition was made, e.g., fork_CancunToPragueAtTime15k.

+

Parametrization by Test Type

+

Each Python test case is also typically parametrized by test type, respectively fixture format. For example, if the test is implemented as a state_test, the test framework will additionally generate the following blockchain test fixtures (consisting of a single block with a single transaction):

+
    +
  • a blockchain_test which can be tested via the Hive eest/consume-rlp simulator (or directly via a dedicated client interface).
  • +
  • a blockchain_engine_test (for post-merge forks) which can be tested via the Hive eest/consume-engine simulator.
  • +
+

Example: The Test IDs generated for test_chainid

+

To see all the test cases and their IDs that get generated from London until Shanghai for test_chainid, we can execute fill with the --collect-only -q flags:

+
fill tests/istanbul/eip1344_chainid/test_chainid.py --from London --until Shanghai --collect-only -q 
+

which lists the following test IDs:

+
tests/istanbul/eip1344_chainid/test_chainid.py::test_chainid[fork_London-blockchain_test]
+tests/istanbul/eip1344_chainid/test_chainid.py::test_chainid[fork_London-state_test]
+tests/istanbul/eip1344_chainid/test_chainid.py::test_chainid[fork_Paris-blockchain_test]
+tests/istanbul/eip1344_chainid/test_chainid.py::test_chainid[fork_Paris-blockchain_test_engine]
+tests/istanbul/eip1344_chainid/test_chainid.py::test_chainid[fork_Paris-state_test]
+tests/istanbul/eip1344_chainid/test_chainid.py::test_chainid[fork_Shanghai-blockchain_test]
+tests/istanbul/eip1344_chainid/test_chainid.py::test_chainid[fork_Shanghai-blockchain_test_engine]
+tests/istanbul/eip1344_chainid/test_chainid.py::test_chainid[fork_Shanghai-state_test]
+

Additional Parametrization

+

The test function tests/cancun/eip4844_blobs/test_blob_txs.py::test_blob_type_tx_pre_fork is additionally parametrized:

+
tests/cancun/eip4844_blobs/test_blob_txs.py::test_blob_type_tx_pre_fork[fork_ShanghaiToCancunAtTime15k-blockchain_test-no_blob_tx]
+tests/cancun/eip4844_blobs/test_blob_txs.py::test_blob_type_tx_pre_fork[fork_ShanghaiToCancunAtTime15k-blockchain_test-one_blob_tx]
+

The strings no_blob_tx and one_blob_tx are additional descriptive parameter IDs that indicate the focus of the test.

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/test_markers/index.html b/docs/public/main/test_markers/index.html new file mode 100644 index 00000000000..9880d10e17f --- /dev/null +++ b/docs/public/main/test_markers/index.html @@ -0,0 +1,1681 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

Test Markers

+

Test markers are used to categorize tests and to run specific subsets of tests. They are defined in the test files using the pytest.mark decorator.

+

The examples below use StateTestFiller tests, but the same markers can also be applied to BlockchainTestFiller tests.

+

Fork Markers

+

These markers are used to specify the forks for which a test is valid.

+

@pytest.mark.valid_from("FORK_NAME")

+

:::pytest_plugins.forks.forks.ValidFrom

+

@pytest.mark.valid_until("FORK_NAME")

+

:::pytest_plugins.forks.forks.ValidUntil

+

@pytest.mark.valid_at("FORK_NAME_1", "FORK_NAME_2", ...)

+

:::pytest_plugins.forks.forks.ValidAt

+

@pytest.mark.valid_at_transition_to("FORK_NAME")

+

:::pytest_plugins.forks.forks.ValidAtTransitionTo

+

Fork Covariant Markers

+

These markers are used in conjunction with the fork validity markers to automatically parameterize tests with values that are valid for the fork being tested.

+

@pytest.mark.with_all_tx_types

+

This marker is used to automatically parameterize a test with all transaction types that are valid for the fork being tested.

+
import pytest
+
+from ethereum_test_tools import Alloc, StateTestFiller
+
+@pytest.mark.with_all_tx_types
+@pytest.mark.valid_from("Berlin")
+def test_something_with_all_tx_types(
+    state_test: StateTestFiller, 
+    pre: Alloc,
+    tx_type: int
+):
+    pass
+

In this example, the test will be parameterized for parameter tx_type with values [0, 1] for fork Berlin, but with values [0, 1, 2] for fork London (because of EIP-1559).

+

@pytest.mark.with_all_contract_creating_tx_types

+

This marker is used to automatically parameterize a test with all contract creating transaction types that are valid for the fork being tested.

+

This marker only differs from pytest.mark.with_all_tx_types in that it does not include transaction type 3 (Blob Transaction type) on fork Cancun and after.

+

@pytest.mark.with_all_precompiles

+

This marker is used to automatically parameterize a test with all precompiles that are valid for the fork being tested.

+
import pytest
+
+from ethereum_test_tools import Alloc, StateTestFiller
+
+@pytest.mark.with_all_precompiles
+@pytest.mark.valid_from("Shanghai")
+def test_something_with_all_precompiles(
+    state_test: StateTestFiller, 
+    pre: Alloc,
+    precompile: int,
+):
+    pass
+

In this example, the test will be parameterized for parameter precompile with values [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] for fork Shanghai, but with values [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10] for fork Cancun which introduced the point evaluation precompile defined in EIP-4844.

+

@pytest.mark.with_all_evm_code_types

+

This marker is used to automatically parameterize a test with all EVM code types that are valid for the fork being tested.

+
import pytest
+
+from ethereum_test_tools import Alloc, StateTestFiller
+
+@pytest.mark.with_all_evm_code_types
+@pytest.mark.valid_from("Frontier")
+def test_something_with_all_evm_code_types(
+    state_test: StateTestFiller,     
+    pre: Alloc,
+):
+    pass
+

In this example, the test will be parameterized for parameter evm_code_type only with value [EVMCodeType.LEGACY] starting on fork Frontier, and eventually it will be parametrized with with values [EVMCodeType.LEGACY, EVMCodeType.EOF_V1] on the EOF activation fork.

+

In all calls to pre.deploy_contract, if the code parameter is Bytecode type, and evm_code_type==EVMCodeType.EOF_V1, the bytecode will be automatically wrapped in an EOF V1 container.

+

Code wrapping might fail in the following circumstances:

+
    +
  • The code contains invalid EOF V1 opcodes.
  • +
  • The code does not end with a valid EOF V1 terminating opcode (such as Op.STOP or Op.REVERT or Op.RETURN).
  • +
+

In the case where the code wrapping fails, evm_code_type can be added as a parameter to the test and the bytecode can be dynamically modified to be compatible with the EOF V1 container.

+

One thing to note is that evm_code_type is not necessary to be added as a parameter to the test because the pre: Alloc fixture automatically consumes this fixture, and therefore it only needs to be added to the test signature if the test’s logic needs it.

+
import pytest
+
+from ethereum_test_tools import Alloc, StateTestFiller
+from ethereum_test_vm import EVMCodeType
+from ethereum_test_vm import Opcodes as Op
+
+@pytest.mark.with_all_evm_code_types
+@pytest.mark.valid_from("Frontier")
+def test_something_with_all_evm_code_types(
+    state_test: StateTestFiller,
+    pre: Alloc,
+    evm_code_type: EVMCodeType
+):
+    code = Op.SSTORE(1, 1)
+    if evm_code_type == EVMCodeType.EOF_V1:
+        # Modify the bytecode to be compatible with EOF V1 container
+        code += Op.STOP
+    pre.deploy_contract(code)
+    ...
+

@pytest.mark.with_all_call_opcodes

+

This marker is used to automatically parameterize a test with all EVM call opcodes that are valid for the fork being tested.

+
import pytest
+
+from ethereum_test_tools import Alloc, StateTestFiller
+from ethereum_test_vm import Opcodes as Op
+
+@pytest.mark.with_all_call_opcodes
+@pytest.mark.valid_from("Frontier")
+def test_something_with_all_call_opcodes(
+    state_test: StateTestFiller,
+    pre: Alloc,
+    call_opcode: Op
+):
+    pass
+

In this example, the test will be parametrized for parameter call_opcode with values [Op.CALL, Op.CALLCODE] starting on fork Frontier, [Op.CALL, Op.CALLCODE, Op.DELEGATECALL] on fork Homestead, [Op.CALL, Op.CALLCODE, Op.DELEGATECALL, Op.STATICCALL] on fork Byzantium, and eventually it will be parametrized with with values [Op.CALL, Op.CALLCODE, Op.DELEGATECALL, Op.STATICCALL, Op.EXTCALL, Op.EXTSTATICCALL, Op.EXTDELEGATECALL] on the EOF activation fork.

+

Parameter evm_code_type will also be parametrized with the correct EVM code type for the opcode under test.

+

@pytest.mark.with_all_create_opcodes

+

This marker is used to automatically parameterize a test with all EVM create opcodes that are valid for the fork being tested.

+
import pytest
+
+from ethereum_test_tools import Alloc, StateTestFiller
+from ethereum_test_vm import Opcodes as Op
+
+@pytest.mark.with_all_create_opcodes
+@pytest.mark.valid_from("Frontier")
+def test_something_with_all_create_opcodes(
+    state_test: StateTestFiller,
+    pre: Alloc,
+    create_opcode: Op
+):
+    pass
+

In this example, the test will be parametrized for parameter create_opcode with values [Op.CREATE] starting on fork Frontier, [Op.CREATE, Op.CREATE2] starting on fork Constantinople, and eventually it will be parametrized with with values [Op.CREATE, Op.CREATE2, Op.EOFCREATE] on the EOF activation fork.

+

Parameter evm_code_type will also be parametrized with the correct EVM code type for the opcode under test.

+

@pytest.mark.with_all_system_contracts

+

This marker is used to automatically parameterize a test with all system contracts that are valid for the fork being tested.

+
import pytest
+
+from ethereum_test_tools import Alloc, StateTestFiller
+from ethereum_test_base_types import Address
+
+@pytest.mark.with_all_system_contracts
+@pytest.mark.valid_from("Cancun")
+def test_something_with_all_system_contracts(
+    state_test: StateTestFiller,
+    pre: Alloc,
+    system_contract: Address,
+):
+    pass
+

In this example, the test will be parameterized for parameter system_contract with value [0x000F3DF6D732807EF1319FB7B8BB8522D0BEAC02] for fork Cancun.

+

Covariant Marker Keyword Arguments

+

All fork covariant markers accept the following keyword arguments:

+

selector

+

A lambda function that can be used to filter the fork covariant values that are valid for this specific test.

+
import pytest
+
+from ethereum_test_tools import Alloc, StateTestFiller
+
+@pytest.mark.with_all_tx_types(selector=lambda tx_type: tx_type != 2)
+@pytest.mark.valid_from("London")
+def test_something_with_all_tx_types(
+    state_test: StateTestFiller, 
+    pre: Alloc,
+    tx_type: int
+):
+    pass
+

Ideally, the lambda function should be used to explicitly filter out values that are not compatible with the test (exclusive filter), rather than explicitly selecting values (inclusive filter), as the parametrized values might change with future forks.

+

marks

+

A marker, list of markers, or a lambda function that can be used to add additional markers to the test.

+
import pytest
+
+@pytest.mark.with_all_tx_types(
+    marks=lambda tx_type: pytest.mark.skip("incompatible") if tx_type == 1 else None,
+)
+@pytest.mark.valid_from("London")
+def test_something_with_all_tx_types_but_skip_type_1(state_test_only, tx_type):
+    assert tx_type != 1
+    ...
+

In this example, the test will be skipped if tx_type is equal to 1 by returning a pytest.mark.skip marker, and return None otherwise.

+

@pytest.mark.parametrize_by_fork

+

A test can be dynamically parametrized based on the fork using the parametrize_by_fork marker.

+

This marker takes two positional arguments:

+
    +
  • argnames: A list of parameter names that will be parametrized using the custom function.
  • +
  • fn: A function that takes the fork as parameter and returns a list of values that will be used to parametrize the test at that specific fork.
  • +
+

And one keyword argument:

+
    +
  • marks (optional): A marker, list of markers, or a lambda function that can be used to add additional markers to the generated tests.
  • +
+

The marked test function will be parametrized by the values returned by the fn function for each fork.

+

If the parameters that are being parametrized is only a single parameter, the return value of fn should be a list of values for that parameter.

+

If the parameters that are being parametrized are multiple, the return value of fn should be a list of tuples/lists, where each tuple contains the values for each parameter.

+
import pytest
+
+def covariant_function(fork):
+    return [[1, 2], [3, 4]] if fork.name() == "Paris" else [[4, 5], [5, 6], [6, 7]]
+
+@pytest.mark.parametrize_by_fork("test_parameter,test_parameter_2", covariant_function)
+@pytest.mark.valid_from("Paris")
+@pytest.mark.valid_until("Shanghai")
+def test_case(state_test_only, test_parameter, test_parameter_2):
+    pass
+

In this example, the test will be parametrized with the values [1, 2] and [3, 4] for the Paris fork, with values 1 and 3 being assigned to test_parameter and 2 and 4 being assigned to test_parameter_2. For the Shanghai fork, the test will be parametrized with the values [4, 5], [5, 6], and [6, 7]. Therefore, more test cases will be generated for the Shanghai fork.

+

If the parameters that are being parametrized is only a single parameter, the return value of fn should be a list of values for that parameter.

+

If the parameters that are being parametrized are multiple, the return value of fn should be a list of tuples/lists, where each tuple contains the values for each parameter.

+

The function can also return a list of pytest.param objects, which allows for additional markers and test IDs to be added to the test.

+

Fill/Execute Markers

+

These markers are used to apply different markers to a test depending on whether it is being filled or executed.

+

@pytest.mark.fill

+

This marker is used to apply markers to a test when it is being filled.

+
import pytest
+
+from ethereum_test_tools import Alloc, StateTestFiller
+
+@pytest.mark.fill(pytest.mark.skip(reason="Only for execution"))
+def test_something(
+    state_test: StateTestFiller, 
+    pre: Alloc
+):
+    pass
+

In this example, the test will be skipped when it is being filled.

+

@pytest.mark.execute

+

This marker is used to apply markers to a test when it is being executed.

+
import pytest
+
+from ethereum_test_tools import Alloc, StateTestFiller
+
+@pytest.mark.execute(pytest.mark.xfail(reason="Depends on block context"))
+def test_something(
+    state_test: StateTestFiller, 
+    pre: Alloc
+):
+    pass
+

In this example, the test will be marked as expected to fail when it is being executed, which is particularly useful so that the test is still executed but does not fail the test run.

+

Other Markers

+

@pytest.mark.slow

+

This marker is used to mark tests that are slow to run. These tests are not run during tox checks, and are only run when a release is being prepared.

+

@pytest.mark.pre_alloc_modify

+

This marker is used to mark tests that modify the pre-alloc in a way that would be impractical to reproduce in a real-world scenario.

+

Examples of this include:

+
    +
  • Modifying the pre-alloc to have a balance of 2^256 - 1.
  • +
  • Address collisions that would require hash collisions.
  • +
+

@pytest.mark.skip()

+

This marker can be used to skip a test.

+
import pytest
+
+from ethereum_test_tools import Alloc, StateTestFiller
+
+@pytest.mark.skip(reason="Not implemented")
+def test_something(state_test: StateTestFiller, pre: Alloc):
+    pass
+

@pytest.mark.xfail()

+

This marker can be used to mark a test as expected to fail.

+
import pytest
+
+from ethereum_test_tools import Alloc, StateTestFiller
+
+@pytest.mark.xfail(reason="EVM binary doesn't support this opcode")
+def test_something(state_test: StateTestFiller, pre: Alloc):
+    pass
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/transaction_test/index.html b/docs/public/main/transaction_test/index.html new file mode 100644 index 00000000000..666413b16e7 --- /dev/null +++ b/docs/public/main/transaction_test/index.html @@ -0,0 +1,1351 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

Transaction Tests

+

The Transaction Test fixture format tests are included in the fixtures subdirectory transaction_tests.

+

These are produced by the TransactionTest test spec.

+

Description

+

The transaction test fixture format is used to test client’s transaction RLP parsing without executing the transaction on the EVM.

+

It does so by defining a transaction binary RLP representation, and whether the transaction should be accepted or rejected by the client in each fork.

+

A single JSON fixture file is composed of a JSON object where each key-value pair is a different Fixture test object, with the key string representing the test name.

+

The JSON file path plus the test name are used as the unique test identifier.

+

The transaction test fixture format could contain multiple test vectors per test object, each represented by an element in the mapping of lists of the result field.

+

However tests generated by the execution-spec-tests repository do not use this feature, as every single test object contains only a single test vector.

+

Consumption

+

For each Fixture test object in the JSON fixture file, perform the following steps:

+
    +
  1. +

    Obtain the txbytes serialized bytes of the transaction to be parsed.

    +
  2. +
  3. +

    For each Fork key of result in the test:

    +
      +
    1. Assume the fork schedule according to the current Fork key.
    2. +
    3. Using the txbytes, attempt to decode the transaction.
    4. +
    5. If the transaction could not be decoded: +
        +
      • If the hash field is present, fail the test.
      • +
      • Compare the exception thrown with the expected exception contained in the exception field, and fail the test if they do not match.
      • +
      • Proceed to the next fork.
      • +
      +
    6. +
    7. If the transaction could be decoded: +
        +
      • Compare the calculated hash with the expected hash contained in the hash field, and fail the test if they do not match.
      • +
      • Compare the calculated intrinsic gas with the expected intrinsic gas contained in the intrinsicGas field, and fail the test if they do not match.
      • +
      • Compare the calculated sender with the expected sender contained in the sender field, and fail the test if they do not match.
      • +
      +
    8. +
    +
  4. +
+

Structures

+

Fixture

+

- txbytes: Bytes

+

Serialized bytes of the transaction under test.

+

- result: Mapping[Fork,FixtureResult ]

+

Mapping of results for verification per fork, where each key-value represents a single possible outcome of the transaction parsed in the given fork.

+

FixtureResult

+

- hash: Hash | None

+

Calculated hash of the transaction (Field is missing if the transaction is expected to fail).

+

- intrinsicGas: ZeroPaddedHexNumber

+

Total intrinsic gas cost of the transaction (Field is missing if the transaction is expected to fail).

+

- sender: Address

+

Sender address of the transaction (Field is missing if the transaction is expected to fail).

+

- exception: TransactionException

+

Exception that is expected to be thrown by the transaction parsing (Field is missing if the transaction is expected to succeed).

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/transition_tool_support/index.html b/docs/public/main/transition_tool_support/index.html new file mode 100644 index 00000000000..80e503a3ce6 --- /dev/null +++ b/docs/public/main/transition_tool_support/index.html @@ -0,0 +1,1341 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

Transition Tool Support

+

The following transition tools are supported by the framework:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Clientt8n ToolTracing Support
ethereum/evmoneevmone-t8nYes
ethereum/execution-specsethereum-spec-evm-resolverYes
ethereumjsethereumjs-t8ntool.shNo
ethereum/go-ethereumevm t8nYes
hyperledger/besuevmtool t8n-serverYes
status-im/nimbus-eth1t8nYes
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/types_of_tests/index.html b/docs/public/main/types_of_tests/index.html new file mode 100644 index 00000000000..01d10db7b70 --- /dev/null +++ b/docs/public/main/types_of_tests/index.html @@ -0,0 +1,1496 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

Types of tests

+

There are currently three types of tests that can be produced by a test spec:

+
    +
  1. State Tests
  2. +
  3. Blockchain Tests
  4. +
  5. Transaction Tests
  6. +
+

State Tests

+

Purpose

+

Tests the effects of individual transactions (ideally a single one) that span a single block in a controlled environment.

+

Use cases

+
    +
  • Test a single opcode behavior.
  • +
  • Verify opcode gas costs.
  • +
  • Test interactions between multiple smart contracts.
  • +
  • Test creation of smart contracts.
  • +
+ + +
+
Note
+
+ The fill function will automatically generate a blockchain_test fixture from state_tests, consisting of one block and one transaction. +
+
+

Blockchain Tests

+

Purpose

+

Blockchain tests span multiple blocks which may or may not contain transactions and mainly focus on the block to block effects to the Ethereum state.

+

Use cases

+
    +
  • Verify system-level operations such as coinbase balance updates or withdrawals.
  • +
  • Verify fork transitions.
  • +
  • Verify blocks with invalid transactions/properties are rejected.
  • +
+

Fork Transition Tests

+

There is a special type of blockchain test that is used to test a fork transition. It’s not executed for all possible forks, rather it targets exactly the blocks at the point of transition from one evm implementation to the next. This type of test must be marked with the valid_at_transition_to marker, for example:

+
@pytest.mark.valid_at_transition_to("Cancun")
+def test_blob_type_tx_pre_fork(
+    blockchain_test: BlockchainTestFiller,
+    pre: Dict,
+    env: Environment,
+    blocks: List[Block],
+):
+    """
+    Reject blocks with blobs before blobs fork
+    """
+

Transaction Tests

+

Purpose

+

Test correct transaction rejection/acceptance of a serialized transaction (currently RLP only).

+

Use cases

+
    +
  • Verify that a badly formatted transaction is correctly rejected by the client.
  • +
  • Verify that a transaction with an invalid value in one of its fields is correctly rejected by the client.
  • +
+ + +
+
Note
+
+ Using the execute command, transaction tests can be sent to clients in a live network using the eth_sendRawTransaction endpoint. +
+
+

Deciding on a test type

+

Prefer state_test for single transactions

+

Whenever possible, use state_test to examine individual transactions. This method is more straightforward and less prone to external influences that can occur during block building.

+

This provides more targeted testing since it does not invoke the client’s block-building machinery. This reduces the risk of encountering false positives, particularly in exception scenarios (e.g., see issue #343: “Zero max_fee_per_blob_gas test is ineffective”).

+

Moreover, the fill command automatically additionally generates a blockchain_test for every state_test by wrapping the state_test’s transaction in a block.

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/useful_pytest_options/index.html b/docs/public/main/useful_pytest_options/index.html new file mode 100644 index 00000000000..a0eaf89f3a9 --- /dev/null +++ b/docs/public/main/useful_pytest_options/index.html @@ -0,0 +1,1492 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

Useful Pytest Options

+

The EEST commands to run tests are customizations to the pytest framework, which provides many helpful options for test selection, parallel execution, report output and debugging. This section provides the most relevant options, a full overview is available in the pytest docs.

+

Fixture Inputs (Consume Commands)

+

See Consume Cache and Fixture Inputs.

+

Dry-Run

+

List collected tests, -q restricts output to test IDs only:

+
uv run consume engine --input=<fixture_input> --collect-only -q
+

In ./hive standalone mode, this can be achieved via EEST’s --sim.limit “collectonly” prefix.

+

Output Control

+
    +
  • -v - verbose output.
  • +
  • -vv - more verbose output.
  • +
  • -s - print stdout to the terminal during execution (don’t capture it).
  • +
  • --eest-log-level=<LOG_LEVEL> - write logs during test (helpful in combination with -s).
  • +
+

Report Generation

+

JSON, HTML and XML reports can be generated with:

+
    --json-report \
+    --json-report-file=report.json \
+    --html=report.html \
+    --junitxml=report.xml
+

Test Case Selection Using Test IDs

+

In addition to Hive’s regex-based --sim.limit option, running in dev mode supports pytest’s -k syntax:

+
uv run consume rlp -k "test_chainid and fork_London"
+uv run consume engine -k "eip1559 or eip4844" -m cancun
+

Use --collect-only -q to see which tests would run without executing them:

+
uv run consume engine --collect-only -q -k "fork_Prague"
+

Test Case Selection using Marks

+

Select tests based on pytest marks.

+

Run only state tests:

+
uv run consume direct --input=<fixture_input> -m state_test
+

Run blockchain tests for specific fork:

+
uv run consume engine --input=<fixture_input> -m "blockchain_test and cancun"
+

Combine marks with keyword filtering:

+
uv run consume engine --input=<fixture_input> -m "blockchain_test" -k "eip4844 or blob"
+
+ +
+
Mark Availability
+
+ Not all test marks are available with consume commands. Fork and test type marks work reliably. +
+
+

Parallel Execution

+

Speed up test execution by running tests in parallel using pytest-xdist.

+

Auto-detect CPU count:

+
uv run consume engine --input=<fixture_input> -n auto
+

Specify worker count:

+
uv run consume direct --input=<fixture_input> -n 4
+

Dropping in the Python Debugger

+

Dropping into the Python debugger can be helpful to inspect EEST simulator state or ssh to a client container. Adding the --pdb option will drop into Python debugger upon test failure, -x tells pytest to exit after the first fail:

+
uv run consume engine --pdb -x ...
+

PDB Cheatsheet

+
    +
  • u β†’ up the stack
  • +
  • d β†’ down the stack
  • +
  • l β†’ list lines around current position
  • +
  • ll β†’ list entire function body
  • +
  • p β†’ print expression
  • +
  • pp β†’ pretty-print expression
  • +
+

Sometimes pp is not enough and it’s worth importing rich (import rich) in pdb and doing a rich.print(obj).

+

Early Exit Options

+

Stop after first failure:

+
uv run consume engine --input=<fixture_input> -x
+

Stop after N failures:

+
uv run consume rlp --input=<fixture_input> --maxfail=3
+

Performance and Timing

+

Show slowest tests:

+
uv run consume engine --input=<fixture_input> --durations=10
+

Show all test durations:

+
uv run consume rlp --input=<fixture_input> --durations=0
+

Timeout control (per test):

+
uv run consume direct --input=<fixture_input> --timeout=30
+

Print relevant test stage timings such as client start-up, payload response time (consume only):

+
uv run consume engine --input=<fixture_input> --timing-data
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/verifying_changes/index.html b/docs/public/main/verifying_changes/index.html new file mode 100644 index 00000000000..34b1004c216 --- /dev/null +++ b/docs/public/main/verifying_changes/index.html @@ -0,0 +1,1438 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

Verifying Changes

+ + +
+
Documentation Moved
+
+ This documentation has been relocated to Detailed Code Standards. Please use the new location for the most up-to-date information. +
+
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/writing_a_new_test/index.html b/docs/public/main/writing_a_new_test/index.html new file mode 100644 index 00000000000..3535b90e30d --- /dev/null +++ b/docs/public/main/writing_a_new_test/index.html @@ -0,0 +1,1694 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + +
+ DEBUG MENU: + +
Name: Execution Spec Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Filling Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/filling_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Getting Started + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/getting_started/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Running Tests + | URL: /main/main/ + | Page: /home/user/Documents/execution-spec-tests/docs/content/main/running_tests/main.md + + | Page.RelPermalink: /main/main/ + | Page.Permalink: http://localhost:1313/main/main/ + + +
Name: Main + | URL: + | Page: + + +
+ + + + + + +
+ + +
+ +
+

+
+ +
+

Writing a New Test

+

Test Functions

+

Every test case is defined as a Python function that implements a single StateTest or BlockchainTest using the state_test or blockchain_test objects made available by the framework (learn how to decide on a test type). Test cases, and the respective test modules, must fulfill the following requirements:

+ + + + + + + + + + + + + + + + + + + + + + + + + +
RequirementWhen
Be decorated with validity markersIf the test case is not valid for all forks
Use one of state_test or blockchain_test in its function argumentsAlways
Call the state_test or blockchain_test in its test bodyAlways
Add a reference version of the EIP spec under testTest path contains eip
+

Specifying which Forks Tests are Valid For

+

Test cases can (and it most cases should) be decorated with one or more “validity markers” that define which the forks the test is valid for. This is achieved by applying:

+
    +
  • pytest.mark.valid_from(FORK) and/or pytest.mark.valid_until(FORK)
  • +
+

or

+
    +
  • pytest.mark.valid_at_transition_to(FORK)
  • +
+

markers on either the test function, test class or test module level:

+

=== “Function”

+
```python
+import pytest
+
+@pytest.mark.valid_from("Berlin")
+@pytest.mark.valid_until("London")
+def test_access_list(state_test: StateTestFiller, fork: Fork):
+```
+
+

=== “Class”

+
```python
+import pytest
+
+
+@pytest.mark.valid_from("Shanghai")
+class TestMultipleWithdrawalsSameAddress:
+```
+
+

=== “Module”

+
```python
+import pytest
+
+pytestmark = pytest.mark.valid_from("Shanghai")
+```
+
+

The ethereum_test_forks package defines the available forks and provides the following helpers that return all forks within the specified range:

+ +

The state_test and blockchain_test Test Function Arguments

+

The test function’s signature must contain exactly one of either a state_test or blockchain_test argument.

+

For example, for state tests:

+
def test_access_list(state_test: StateTestFiller):
+

and for blockchain tests:

+
def test_contract_creating_tx(
+    blockchain_test: BlockchainTestFiller, fork: Fork, initcode: Initcode
+):
+

The state_test and blockchain_test objects are actually wrapper classes to the StateTest, respectively BlockchainTest objects, that once called actually instantiate a new instance of these objects and fill the test case using the evm tool according to the pre and post states and the transactions defined within the test.

+

If a blockchain-type test should only generate a test fixture in the Engine format (EngineFixture), the blockchain_test_engine object can be specified. This object is a wrapper for the BlockchainTestEngine class.

+

StateTest Object

+

The StateTest object represents a single test vector, and contains the +following attributes:

+
    +
  • env: Environment object which describes the global state of the blockchain +before the test starts.
  • +
  • pre: Pre-State containing the information of all Ethereum accounts that exist +before any transaction is executed.
  • +
  • post: Post-State containing the information of all Ethereum accounts that are +created or modified after all transactions are executed.
  • +
  • txs: All transactions to be executed during test execution.
  • +
+

BlockchainTest Object

+

The BlockchainTest object represents a single test vector that evaluates the +Ethereum VM by attempting to append multiple blocks to the chain:

+
    +
  • pre: Pre-State containing the information of all Ethereum accounts that exist +before any block is executed.
  • +
  • post: Post-State containing the information of all Ethereum accounts that are +created or modified after all blocks are executed.
  • +
  • blocks: All blocks to be appended to the blockchain during the test.
  • +
+

BlockchainTestEngine Object

+

The BlockchainTestEngine object has the same properties as the BlockchainTest but it’s used to only generate a blockchain test in the Engine format.

+

Pre/Post State of the Test

+

The pre and post states are elemental to setup and then verify the outcome +of the state test.

+

Both pre and post are mappings of account addresses to account structures (see more info).

+

A single test vector can contain as many accounts in the pre and post states +as required, and they can be also filled dynamically.

+

storage of an account is a key/value dictionary, and its values are +integers within range of [0, 2**256 - 1].

+

txs are the steps which transform the pre-state into the post-state and +must perform specific actions within the accounts (smart contracts) that result +in verifiable changes to the balance, nonce, and/or storage in each of them.

+

post is compared against the outcome of the client after the execution +of each transaction, and any differences are considered a failure

+

When designing a test, all the changes must be ideally saved into the contract’s +storage to be able to verify them in the post-state.

+

Test Transactions

+

Transactions can be crafted by sending them with specific data or to a +specific account, which contains the code to be executed.

+

Transactions can also create more accounts, by setting the to field to an +empty string.

+

Transactions can be designed to fail, and a verification must be made that the +transaction fails with the specific error that matches what is expected by the +test.

+

They can also contain a TransactionReceipt object in field expected_receipt +which allows checking for an exact gas_used value.

+

Writing code for the accounts in the test

+

Account bytecode can be “deployed” in a test’s pre-state using the pre pytest fixture. The @ethereum/execution-spec-tests Python [Opcodes][ethereum_test_vm.Opcodes] minilang can be used to help write the bytecode in a readable form.

+

Using the Python Opcode Minilang

+

EVM bytecode for tests should be written using the Python-based minilang provided by the [Opcodes][ethereum_test_vm.Opcodes] class. This allows you to construct bytecode using symbolic opcodes as Python objects.

+

Example: Simple Addition Contract

+
from ethereum_test_vm.opcode import Opcodes
+
+code = (
+    Opcodes.PUSH1(0x02)
+    + Opcodes.PUSH1(0x03)
+    + Opcodes.ADD()
+    + Opcodes.PUSH1(0x00)
+    + Opcodes.SSTORE()
+    + Opcodes.STOP()
+)
+
+# within a test function, using the "pre" fixture
+contract_address = pre.deploy_contract(code=code)
+

You add this contract to the test’s pre-state using the pre fixture or assign this code to the code field of an account in your test’s post state. See the state test tutorial for more help.

+

For a full list of available opcodes and their usage, see [Opcodes][ethereum_test_vm.Opcodes].

+

Higher-Level Constructs

+

For more complex control flow, you can use constructs like [Switch][ethereum_test_tools.code.generators.Switch] and [Case][ethereum_test_tools.code.generators.Case] from the ethereum_test_tools.code.generators module:

+
from ethereum_test_tools.code.generators import Switch, Case
+from ethereum_test_vm.opcode import Opcodes as Op
+
+code = Switch(
+    cases=[
+        Case(condition=Op.EQ(Op.CALLDATALOAD(0), 1), action=Op.PUSH1(0x01) + Op.STOP()),
+        Case(condition=Op.EQ(Op.CALLDATALOAD(0), 2), action=Op.PUSH1(0x02) + Op.STOP()),
+    ],
+    default_action=Op.PUSH1(0x00) + Op.STOP(),
+)
+

The ethereum_test_tools.code.generators module also defines other high-level constructs like [While][ethereum_test_tools.code.generators.While] and [Conditional][ethereum_test_tools.code.generators.Conditional].

+

Converting Bytecode to Minilang

+

If you have EVM bytecode (as hex or binary), you can use the evm_bytes CLI tool to convert it to the EEST Python opcode minilang automatically, for example:

+
uv run evm_bytes hex-string 0x604260005260206000F3
+# ->
+# Op.PUSH1[0x42] + Op.PUSH1[0x0] + Op.MSTORE + Op.PUSH1[0x20] + Op.PUSH1[0x0] + Op.RETURN
+

Restrictions: No Yul in Python Test Cases

+

As of PR #1779, the use of Yul source in Python test cases is forbidden. All new tests must use the Python opcode minilang as shown above.

+

Verifying the Accounts’ Post States

+

The state of the accounts after all blocks/transactions have been executed is +the way of verifying that the execution client actually behaves like the test +expects.

+

During their filling process, all tests automatically verify that the accounts +specified in their post property actually match what was returned by the +transition tool.

+

Within the post dictionary object, an account address can be:

+
    +
  • None: The account will not be checked for absence or existence in the +result returned by the transition tool.
  • +
  • Account object: The test expects that this account exists and also has +properties equal to the properties specified by the Account object.
  • +
  • Account.NONEXISTENT: The test expects that this account does not exist in +the result returned by the transition tool, and if the account exists, +it results in error. +E.g. when the transaction creating a contract is expected to fail and the +test wants to verify that the address where the contract was supposed to be +created is indeed empty.
  • +
+

The Account object

+

The Account object is used to specify the properties of an account to be +verified in the post state.

+

The python representation can be found in src/ethereum_test_types/account_types.py.

+

It can verify the following properties of an account:

+
    +
  • +

    nonce: the scalar value equal to a) the number of transactions sent by +an Externally Owned Account, b) the amount of contracts created by a contract.

    +
  • +
  • +

    balance: the amount of Wei (10-18 Eth) the account has.

    +
  • +
  • +

    code: Bytecode contained by the account. To verify that an account contains +no code, this property needs to be set to “0x” or “”.

    +
  • +
  • +

    storage: Storage within the account represented as a dict object. +All storage keys that are expected to be set must be specified, and if a +key is skipped, it is implied that its expected value is zero. +Setting this property to {} (empty dict), means that all the keys in the +account must be unset (equal to zero).

    +
  • +
+

All account’s properties are optional, and they can be skipped or set to None, +which means that no check will be performed on that specific account property.

+

Verifying correctness of the new test

+

A well written test performs a single verification output at a time.

+

A verification output can be a single storage slot, the balance of an account, +or a newly created contract.

+

It is not recommended to use balance changes to verify test correctness, as it +can be easily affected by gas cost changes in future EIPs.

+

The best way to verify a transaction/block execution outcome is to check its +storage.

+

A test can be written as a negative verification. E.g. a contract is not +created, or a transaction fails to execute or runs out of gas.

+

This kind of verification must be carefully crafted because it is possible to end up +having a false positive result, which means that the test passed but the +intended verification was never made.

+

To avoid these scenarios, it is important to have a separate verification to +check that test is effective. E.g. when a transaction is supposed to fail, it +is necessary to check that the failure error is actually the one expected by +the test.

+

Failing or invalid transactions

+

Transactions included in a StateTest are expected to be intrinsically valid, +i.e. the account sending the transaction must have enough funds to cover the +gas costs, the max fee of the transaction must be equal or higher than the +base fee of the block, etc.

+

An intrinsically valid transaction can still revert during its execution.

+

Blocks in a BlockchainTest can contain intrinsically invalid transactions but +in this case the block is expected to be completely rejected, along with all +transactions in it, including other valid transactions.

+

Parametrizing tests

+

Tests can be parametrized by using the @pytest.mark.parametrize decorator.

+

Example:

+
import pytest
+
+@pytest.mark.parametrize(
+    "tx_value,expected_balance",
+    [
+        pytest.param(0, 0, id="zero-value"),
+        pytest.param(100, 100, id="non-zero-value"),
+    ],
+)
+def test_contract_creating_tx(
+    blockchain_test: BlockchainTestFiller, fork: Fork, tx_value: int, expected_balance: int
+):
+

This will run the test twice, once with tx_value set to 0 and expected_balance +set to 0, and once with tx_value set to 100 and expected_balance set to 100.

+

The fork fixture is automatically provided by the framework and contains the +current fork under test, and does not need to be parametrized.

+

Tests can also be automatically parametrized with appropriate fork covariant +values using the with_all_* markers listed in the +Test Markers page.

+

The extend_with_defaults Utility

+

::: ethereum_test_tools.utility.pytest.extend_with_defaults

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/writing_tests/adding_a_new_test/index.html b/docs/public/main/writing_tests/adding_a_new_test/index.html new file mode 100644 index 00000000000..dbe9662189d --- /dev/null +++ b/docs/public/main/writing_tests/adding_a_new_test/index.html @@ -0,0 +1,1399 @@ + + + + + + + Adding a New Test - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

Adding a New Test

+
+ +
+

All test cases are located underneath the tests directory, which are then organized by fork. Each fork contains sub-directories containing test sub-categories.

+
πŸ“ execution-test-specs/
+β”œβ”€β•΄πŸ“ tests/
+|   β”œβ”€β”€ πŸ“„ __init__.py
+β”‚   β”œβ”€β”€ πŸ“ cancun/
+|   |    β”œβ”€β”€ πŸ“„ __init__.py
+β”‚   |    └── πŸ“ eip4844_blobs/
+|   |        β”œβ”€β”€ πŸ“„ __init__.py
+|   |        β”œβ”€β”€ πŸ“„ test_blobhash_opcode.py
+|   |        β”œβ”€β”€ πŸ“„ test_excess_blob_gas.py
+|   |        └── πŸ“„ ...
+|   β”œβ”€β”€ πŸ“ shanghai
+|   |    β”œβ”€β”€ πŸ“ eip3651_warm_coinbase
+|   |    |   β”œβ”€β”€ πŸ“„ __init__.py
+|   |    |   └── πŸ“„ test_warm_coinbase.py
+|   |    β”œβ”€β”€ πŸ“ eip3855_push0
+|   |    |   β”œβ”€β”€ πŸ“„ __init__.py
+|   |    |   └── πŸ“„ test_push0.py
+|   |    β”œβ”€β”€ πŸ“...
+|   |    ...
+β”‚   └── πŸ“ ...
+

Each category/sub-directory may have multiple Python test modules (*.py) which in turn may contain many test functions. The test functions themselves are always parametrized by fork (by the framework).

+

A new test can be added by either:

+
    +
  • Adding a new test_ python function to an existing file in any of the existing category subdirectories within tests.
  • +
  • Creating a new source file in an existing category, and populating it with the new test function(s).
  • +
  • Creating an entirely new category by adding a subdirectory in tests with the appropriate source files and test functions.
  • +
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/writing_tests/checklist_templates/eip_testing_checklist_template/index.html b/docs/public/main/writing_tests/checklist_templates/eip_testing_checklist_template/index.html new file mode 100644 index 00000000000..9822f2d02e3 --- /dev/null +++ b/docs/public/main/writing_tests/checklist_templates/eip_testing_checklist_template/index.html @@ -0,0 +1,4334 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

+
+ +
+
+

EIP Execution Layer Testing Checklist Template

+

Depending on the changes introduced by an EIP, the following template is the minimum baseline to guarantee test coverage of the Execution Layer features.

+

Checklist Progress Tracker

+ + + + + + + + + + + + + + + +
Total Checklist ItemsCovered Checklist ItemsPercentage
TOTAL_CHECKLIST_ITEMSCOVERED_CHECKLIST_ITEMSPERCENTAGE
+

General

+

Code coverage

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
general/code_coverage/eelsRun produced tests against EELS and verify that line code coverage of new added lines for the EIP is 100%, with only exceptions being unreachable code lines.
general/code_coverage/test_coverageRun coverage on the test code itself (as a basic logic sanity check), i.e., uv run fill --cov tests.
general/code_coverage/second_clientOptional - Run against a second client and verify sufficient code coverage over new code added for the EIP.
+

Fuzzing

+

Fuzzing is recommended to be performed on EIPs that introduce new cryptography primitives.

+

See holiman/goevmlab for an example of a fuzzing framework for the EVM.

+

New Opcode

+

The EIP introduces one or more new opcodes to the EVM.

+

Test Vectors

+

Memory expansion

+

If the opcode execution can expand the memory size, either by writing to memory or reading from an offset that exceeds current memory, or interaction of both parameters (size of zero should never result in memory expansion, regardless of offset value).

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/mem_exp/zero_bytes_zero_offsetZero bytes expansion with zero-offset.
opcode/test/mem_exp/zero_bytes_max_offsetZero bytes expansion with 2**256-1 offset.
opcode/test/mem_exp/single_byteSingle byte expansion.
opcode/test/mem_exp/31_bytes31 bytes expansion.
opcode/test/mem_exp/32_bytes32 bytes expansion.
opcode/test/mem_exp/33_bytes33 bytes expansion.
opcode/test/mem_exp/64_bytes64 bytes expansion.
opcode/test/mem_exp/2_32_minus_one_bytes2**32-1 bytes expansion.
opcode/test/mem_exp/2_32_bytes2**32 bytes expansion.
opcode/test/mem_exp/2_64_minus_one_bytes2**64-1 bytes expansion.
opcode/test/mem_exp/2_64_bytes2**64 bytes expansion.
opcode/test/mem_exp/2_256_minus_one_bytes2**256-1 bytes expansion (Should always result in Out-of-gas).
+

Stack

+
Stack Overflow
+

If the opcode pushes one or more items to the stack, and the opcode pushes more elements than it pops, verify that the opcode execution results in exceptional abort when pushing elements to the stack would result in the stack having more than 1024 elements.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/stack_overflowStack Overflow.
+
Stack Underflow
+

If the opcode pops one or more items to the stack, or it has a minimum stack height of one or more (e.g. DUPN requires a minimum amount of elements in the stack even when it does not pop any element from it), verify that the opcode execution results in exceptional abort then stack has 1 less item than the minimum stack height expected.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/stack_underflowStack Underflow.
+
Stack Complex Operations
+

If opcode performs stack operations more complex than simple pop/push (e.g. the opcode has a data portion that specifies a variable to access a specific stack element), perform the following test combinations.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/stack_complex_operations/stack_heights/zeroOperation on an empty stack (Potential stack-underflow).
opcode/test/stack_complex_operations/stack_heights/oddOperation on a stack with an odd height.
opcode/test/stack_complex_operations/stack_heights/evenOperation on a stack with an even height.
+
Stack Manipulation With Data Portion Variables
+

If the opcode contains variables in its data portion, for each variable n of the opcode that accesses the nth stack item, test n being.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/stack_complex_operations/data_portion_variables/topTop stack item.
opcode/test/stack_complex_operations/data_portion_variables/bottomBottom stack item.
opcode/test/stack_complex_operations/data_portion_variables/middleMiddle stack item.
+

Execution context

+

Evaluate opcode’s behavior in different execution contexts.

+
CALL
+

Verify opcode operation in a subcall frame originated from a CALL opcode.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/execution_context/callCALL.
+
STATICCALL
+

Verify opcode operation in a subcall frame originated from a STATICCALL opcode.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/execution_context/staticcall/ban_checkVerify exceptional abort if the opcode attempts to modify the code, storage or balance of an account.
opcode/test/execution_context/staticcall/ban_no_modificationIf the opcode is completely banned from static contexts, verify that even when its inputs would not cause any account modification, the opcode still results in exceptional abort of the execution (e.g. PAY with zero value, or SSTORE to the value it already has in the storage).
opcode/test/execution_context/staticcall/sub_callsVerify sub-calls using other opcodes (e.g. CALL, DELEGATECALL, etc) also results in the same exceptional abort behavior.
+
DELEGATECALL
+

Verify opcode operation in a subcall frame originated from a DELEGATECALL opcode.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/execution_context/delegatecallDELEGATECALL.
opcode/test/execution_context/delegatecall/storageIf the opcode modifies the storage of the account currently executing it, verify that only the account that is delegating execution is the one that has its storage modified.
opcode/test/execution_context/delegatecall/balanceIf the opcode modifies the balance of the account currently executing it, verify that only the account that is delegating execution is the one that has its balance modified.
opcode/test/execution_context/delegatecall/codeIf the opcode modifies the code of the account currently executing it, verify that only the account that is delegating execution is the one that has its code modified.
+
CALLCODE
+

Verify opcode operation in a subcall frame originated from a CALLCODE opcode.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/execution_context/callcodeCALLCODE.
+
Initcode
+

Verify opcode behaves as expected when running during the initcode phase of contract creation.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/execution_context/initcode/behaviorInitcode operation.
opcode/test/execution_context/initcode/behavior/txInitcode of a contract creating transaction.
opcode/test/execution_context/initcode/behavior/opcodeInitcode of a contract creating opcode (including itself if opcode creates a contract).
opcode/test/execution_context/initcode/reentryInitcode re-entry: using the same initcode and same address (e.g. CREATE2->REVERT->CREATE2).
+
Set-code Delegated Account
+

Verify opcode operations are applied to the set-code account and do not affect the address that is the target of the delegation.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/execution_context/set_codeSet-code delegated account.
+
Transaction Context
+

If opcode changes behavior depending on particular transaction properties, test using multiple values for each property.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/execution_context/tx_contextTransaction-context dependent opcode.
+
Block Context
+

If opcode changes behavior depending on particular block properties, test using multiple values for each property.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/execution_context/block_contextBlock-context dependent opcode.
+

Return data

+

Verify proper return data buffer overwriting if the opcode is meant to interact with it, otherwise verify that the return data buffer is unaffected.

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/return_data/buffer/currentReturn buffer at current call context.
opcode/test/return_data/buffer/parentReturn buffer at parent call context.
+

Gas Usage

+
Normal Operation
+

Verify gas usage affectation of each stack argument or memory input consumed by the opcode.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/gas_usage/normalNormal operation gas usage.
+
Memory Expansion
+

Verify that the memory expansion correctly follows the gas calculation.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/gas_usage/memory_expansionMemory expansion.
+
Out-Of-Gas
+

Verify that attempting to execute the opcode when gas available is 1 less than the required gas results in exceptional abort.

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/gas_usage/out_of_gas_executionOut-of-gas due to opcode inputs.
opcode/test/gas_usage/out_of_gas_memoryOut-of-gas due to memory expansion.
+
Order-of-operations
+

If the opcode requires different gas stipends for other operations (e.g. contract creation, cold/warm account access), create one case for each operation (ideally independent of each other) and the listed cases for each.

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/gas_usage/order_of_operations/exactSuccess using the exact amount of gas required for the stipend.
opcode/test/gas_usage/order_of_operations/oogOOG with a 1-gas-difference from the gas required for the stipend.
+

Terminating opcode

+

If an opcode is terminating, meaning it results in the current call context to end execution.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/terminating/scenarios/top_levelTop-level call termination.
opcode/test/terminating/scenarios/sub_levelSub-level call termination.
opcode/test/terminating/scenarios/initcodeInitcode termination.
+

Aborting/Reverting opcode

+

If the terminating opcode is meant to rollback the executing call frame, verify the listed events are properly rolled back.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/terminating/rollback/balanceBalance changes.
opcode/test/terminating/rollback/storageStorage changes.
opcode/test/terminating/rollback/contractsContract creations.
opcode/test/terminating/rollback/nonceNonce increments.
opcode/test/terminating/rollback/logsLog events.
+

Out-of-bounds checks

+

If the opcode has out-of-bounds conditions in its parameters/inputs.

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/out_of_bounds/verify/maxMax value for each parameter.
opcode/test/out_of_bounds/verify/max_plus_oneMax value + 1 for each parameter.
+

Exceptional Abort

+

If the opcode has conditions, either inputs or execution context states, that should cause exceptional abort and are different than out-of-gas or stack overflow or underflow.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/exceptional_abortExceptional abort conditions.
+

Data portion

+

If an opcode has a data portion, meaning the N bytes following the opcode in the contract bytecode are skipped from execution.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/data_portion/all_zerosAll zeros data portion.
opcode/test/data_portion/max_valueMax value data portion (2**N-1 where N is the bit size of the data portion).
opcode/test/data_portion/jumpJump into the data portion.
+

Contract creation

+

If the opcode execution results in the creation of a new contract in the state.

+
Correct Creation
+

Verify contract is created at the expected address given multiple inputs.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/contract_creation/addressAddress calculation.
+
Creation Failure
+

The contract creation fails given the listed conditions.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/contract_creation/failure/oogOut-of-gas when available gas is less than minimum contract creation stipend.
opcode/test/contract_creation/failure/insufficient_valueOpcode has a value parameter and the caller does not have enough funds.
opcode/test/contract_creation/failure/collisionCreation would result in an address collision with an existing contract or EOA-delegated address.
+
Recursive Contract Creation
+

Opcode is used to attempt to recreate a contract that is currently mid-creation by a previous call of the same opcode.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/contract_creation/recursiveRecursive contract creation using the opcode.
+

Fork transition

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
opcode/test/fork_transition/invalidExceptional abort if executed before its activation fork/after its deactivation fork.
opcode/test/fork_transition/atVerify correct opcode behavior at transition block, in the case of opcodes which behavior depends on current or parent block information.
+

Framework Changes

+ + + + + + + + + + + +
IDDescriptionStatusTests
+
    +
  • Add opcode to src/ethereum_test_vm/opcode.py
  • +
  • Add opcode to relevant methods in the fork where the EIP is introduced in src/ethereum_test_forks/forks/forks.py
  • +
+

New Precompile

+

The EIP introduces one or more new precompiles.

+

Test Vectors

+

Call contexts

+

Evaluate precompile behavior when called using different call opcodes or called from different execution contexts.

+
CALL
+

Verify precompile operation when called using the CALL opcode.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
precompile/test/call_contexts/normalCALL.
+
DELEGATECALL
+

Verify precompile operation when called using the DELEGATECALL opcode.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
precompile/test/call_contexts/delegateDELEGATECALL.
+
STATICCALL
+

Verify precompile operation when called using the STATICCALL opcode.

+

If the precompile is stateful, meaning calling it affects its storage, this call must result in exceptional abort.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
precompile/test/call_contexts/staticSTATICCALL.
+
CALLCODE
+

Verify precompile operation when called using the CALLCODE opcode.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
precompile/test/call_contexts/callcodeCALLCODE.
+
Transaction Entry-point
+

Verify precompile behavior when it’s used as tx.to.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
precompile/test/call_contexts/tx_entryPrecompile as transaction entry-point.
+
Initcode call
+

Verify calling the opcode during initcode execution of a new contract.

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
precompile/test/call_contexts/initcode/CREATECall from Initcode initiated from a CREATE/CREATE2 opcode.
precompile/test/call_contexts/initcode/txCall from Initcode initiated from a contract-creating transaction (tx.to==None).
+
Precompile as Set-code Delegated Address
+

Test setting the precompile as a set-code delegated address, and verify no precompile logic is executed.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
precompile/test/call_contexts/set_codeSet code delegated address.
+

Inputs

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
precompile/test/inputs/validVerify combinations of valid inputs to the precompile.
precompile/test/inputs/valid/boundaryVerify all boundary values given the precompile functionality.
precompile/test/inputs/valid/cryptoIf precompile performs cryptographic operations, verify behavior on all inputs that have special cryptographic properties (e.g. infinity points as inputs, or input values that result in infinity points returned).
precompile/test/inputs/all_zerosVerify all zeros input.
precompile/test/inputs/max_valuesVerify 2^N-1 where N is a single or multiple valid bit-lengths.
precompile/test/inputs/invalidVerify combinations of invalid inputs to the precompile.
precompile/test/inputs/invalid/cryptoInputs that fail specific mathematical or cryptographic validity checks.
precompile/test/inputs/invalid/corruptedInputs that are malformed/corrupted.
+

Value Transfer

+
Minimum Fee Precompile
+

If the precompile requires a minimum value (fee) to execute, either constant or depending on a formula.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
precompile/test/value_transfer/fee/underCalls with the required value amount minus one, expect failure.
precompile/test/value_transfer/fee/exactCalls with the exact required amount, expect success.
precompile/test/value_transfer/fee/overCalls with extra value than the required amount, expect success.
+
No-Fee Precompile
+

If the precompile does not require any minimum value (fee) to execute.

+

| precompile/test/value_transfer/no_fee | Sending non-zero value does not cause an exception (unless otherwise specified by the EIP). | | |

+

Out-of-bounds checks

+

If the precompile has out-of-bounds conditions in its inputs.

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
precompile/test/out_of_bounds/maxMax value for each input.
precompile/test/out_of_bounds/max_plus_oneMax value + 1 for each input.
+

Input Lengths

+

Verify different combinations of input lengths to the precompile, ensuring the correct minimum fee (if any) is provided.

+
Zero-length Input
+

Regardless of the input requirements for the precompile.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
precompile/test/input_lengths/zeroZero-length calldata.
+
Static Required Input Length
+

If the precompile has a static required input length.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
precompile/test/input_lengths/static/correctCorrect static-length calldata.
precompile/test/input_lengths/static/too_shortCalldata too short, where the value represents a correct but truncated input to the precompile.
precompile/test/input_lengths/static/too_longCalldata too long, where the value represents a correct input to the precompile with padded zeros.
+
Dynamic Required Input Length
+

If the precompile has a variable required input-length based on a formula, test all listed scenarios given different input lengths.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
precompile/test/input_lengths/dynamic/validVerify correct precompile execution for valid lengths.
precompile/test/input_lengths/dynamic/too_shortCalldata too short, where the value represents a correct but truncated input to the precompile.
precompile/test/input_lengths/dynamic/too_longCalldata too long, where the value represents a correct input to the precompile with padded zeros.
+

Gas usage

+
Constant Gas Cost
+

If the precompile always charges the same gas cost regardless of input conditions.

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
precompile/test/gas_usage/constant/exactVerify exact gas consumption.
precompile/test/gas_usage/constant/oogVerify exact gas consumption minus one results in out-of-gas error.
+
Variable Gas Cost
+

If the precompile charges variable gas cost given input conditions, test all listed scenarios using multiple different valid inputs.

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
precompile/test/gas_usage/dynamic/exactVerify exact gas consumption.
precompile/test/gas_usage/dynamic/oogVerify exact gas consumption minus one results in out-of-gas error.
+
Excessive Gas
+

Verify spending all block gas in calls to the precompile (Use Environment().gas_limit as reference max amount).

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
precompile/test/excessive_gas_usageExcessive gas usage.
+

Fork transition

+
Pre-fork Block Call
+

Verify that calling the precompile before its activation fork results in a valid call, even for inputs that are expected to be invalid for the precompile, or a zero-gas call.

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
precompile/test/fork_transition/before/invalid_inputInvalid input call.
precompile/test/fork_transition/before/zero_gasZero-gas call.
+
Cold/Warm Precompile Address State
+

Verify the cold/warm state of the precompile address depending on the fork activation.

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
precompile/test/fork_transition/before/coldPrecompile address is cold by default before the fork activation.
precompile/test/fork_transition/after/warmPrecompile address is warm by default after the fork activation.
+

Framework Changes

+
    +
  • Add precompile address to relevant methods in the fork where the EIP is introduced in src/ethereum_test_forks/forks/forks.py
  • +
+

Removed Precompile

+

The EIP removes one or more precompiles from the existing list of precompiles.

+

Test Vectors

+

Fork transition

+
Precompile Operation
+

Verify that the precompile remains operational up until the last block before the fork is active, and behaves as an account with empty code afterwards.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
removed_precompile/test/fork_transition/operationalPrecompile operation on fork activation.
+
Cold/Warm Precompile Address State
+

Verify the cold/warm state of the precompile address depending on the fork activation.

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
removed_precompile/test/fork_transition/before/warmPrecompile address is warm by default before the fork activation.
removed_precompile/test/fork_transition/after/coldPrecompile address is cold by default after the fork activation.
+

Framework Changes

+
    +
  • Remove the precompile address from relevant methods in the fork where the EIP is removed in src/ethereum_test_forks/forks/forks.py
  • +
+

New System Contract

+

Test Vectors

+

Call contexts

+

Evaluate precompile behavior when called using different call opcodes or called from different execution contexts.

+
CALL
+

Verify system contract operation when called using the CALL opcode.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
system_contract/test/call_contexts/normalCALL.
+
DELEGATECALL
+

Verify system contract operation when called using the DELEGATECALL opcode.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
system_contract/test/call_contexts/delegateDELEGATECALL.
+
STATICCALL
+

Verify system contract operation when called using the STATICCALL opcode.

+

If the system contract is stateful, meaning calling it affects its storage, this call must result in exceptional abort.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
system_contract/test/call_contexts/staticSTATICCALL.
+
CALLCODE
+

Verify system contract operation when called using the CALLCODE opcode.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
system_contract/test/call_contexts/callcodeCALLCODE.
+
Transaction Entry-point
+

Verify system contract behavior when it’s used as tx.to.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
system_contract/test/call_contexts/tx_entrySystem Contract as transaction entry-point.
+
Initcode call
+

Verify calling the opcode during initcode execution of a new contract.

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
system_contract/test/call_contexts/initcode/CREATECall from Initcode initiated from a CREATE/CREATE2 opcode.
system_contract/test/call_contexts/initcode/txCall from Initcode initiated from a contract-creating transaction (tx.to==None).
+
System Contract as Set-code Delegated Address
+

Test setting the system contract as a set-code delegated address, and verify no system contract side-effects are triggered, even if the actual system contract logic is executed.

+

If the system contract requires specific storage pre-conditions to be set for proper execution (e.g. if the contract contains a safety mechanism that prevents it from executing prior to the fork activation), ensure the delegated account has the proper values in the storage to guarantee the correct logic is executed.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
system_contract/test/call_contexts/set_codeSet code delegated address.
+

Inputs

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
system_contract/test/inputs/validVerify combinations of valid inputs to the system contract.
system_contract/test/inputs/boundaryVerify all boundary values given the system contract functionality.
system_contract/test/inputs/all_zerosVerify all zeros input.
system_contract/test/inputs/max_valuesVerify 2^N-1 where N is a single or multiple valid bit-lengths.
system_contract/test/inputs/invalidVerify combinations of invalid inputs to the precompile.
system_contract/test/inputs/invalid/checksInputs that fail validity checks.
system_contract/test/inputs/invalid/cryptoInputs that fail specific mathematical or cryptographic validity checks.
system_contract/test/inputs/invalid/corruptedInputs that are malformed/corrupted.
+

Value Transfer

+
Minimum Fee System Contract
+

If the system contract requires a minimum value (fee) to execute, either constant or depending on a formula.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
system_contract/test/value_transfer/fee/underCalls with the required value amount minus one, expect failure.
system_contract/test/value_transfer/fee/exactCalls with the exact required amount, expect success.
system_contract/test/value_transfer/fee/overCalls with extra value than the required amount, expect success.
+
No-Fee System Contract
+

If the system contract does not require any minimum value (fee) to execute.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
system_contract/test/value_transfer/no_feeSending non-zero value does not cause an exception (unless otherwise specified by the EIP).
+

Out-of-bounds checks

+

If the system contract has out-of-bounds conditions in its inputs.

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
system_contract/test/out_of_bounds/maxMax value for each input.
system_contract/test/out_of_bounds/max_plus_oneMax value + 1 for each input.
+

Input Lengths

+

Verify different combinations of input lengths to the system contract, ensuring the correct minimum fee (if any) is provided.

+
Zero-length Input
+

Regardless of the input requirements for the system contract.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
system_contract/test/input_lengths/zeroZero-length calldata.
+
Static Required Input Length
+

If the system contract has a static required input length.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
system_contract/test/input_lengths/static/correctCorrect static-length calldata.
system_contract/test/input_lengths/static/too_shortCalldata too short, where the value represents a correct but truncated input to the contract.
system_contract/test/input_lengths/static/too_longCalldata too long, where the value represents a correct input to the contract with padded zeros.
+
Dynamic Required Input Length
+

If the system contract has a variable required input-length based on a formula, test all listed scenarios given different input lengths.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
system_contract/test/input_lengths/dynamic/validVerify correct system contract execution for valid lengths.
system_contract/test/input_lengths/dynamic/too_shortCalldata too short, where the value represents a correct but truncated input to the contract.
system_contract/test/input_lengths/dynamic/too_longCalldata too long, where the value represents a correct input to the contract with padded zeros.
+

Gas usage

+
Constant Gas Cost
+

If the system contract always charges the same gas cost regardless of input conditions.

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
system_contract/test/gas_usage/constant/exactVerify exact gas consumption.
system_contract/test/gas_usage/constant/oogVerify exact gas consumption minus one results in out-of-gas error.
+
Variable Gas Cost
+

If the system contract charges variable gas cost given input conditions, test all listed scenarios using multiple different valid inputs.

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
system_contract/test/gas_usage/dynamic/exactVerify exact gas consumption.
system_contract/test/gas_usage/dynamic/oogVerify exact gas consumption minus one results in out-of-gas error.
+

Excessive Gas Cases

+
Excessive Gas Usage During Block Execution
+

Verify spending all block gas in calls to system contract (Use Environment().gas_limit as reference max amount).

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
system_contract/test/excessive_gas/block_gasExhaust block gas limit.
+
Excessive Gas Usage During System Call
+

If possible, produce a scenario where, given all transactions executed within the block result in the execution of the contract by the system address would result in excessive gas usage.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
system_contract/test/excessive_gas/system_callExcessive gas on system call.
+

System Contract Deployment

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
system_contract/test/deployment/missingVerify block execution behavior after fork activation if the system contract has not been deployed (Depending on the EIP, block could be invalid).
system_contract/test/deployment/addressVerify deployment transaction results in the system contract being deployed to the expected address.
+

Contract Variations

+

Verify execution of the different variations of the contract for different networks (if any) results in the expected behavior.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
system_contract/test/contract_variations/networksDifferent network contract variations.
+

Contract Substitution

+

Substitute the default system contract with a mock contract to modify its behavior when called by the system address (at the end of the block execution).

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
system_contract/test/contract_substitution/return_lengthsModified return value lengths.
system_contract/test/contract_substitution/logsModified to emit logs or modified logs.
system_contract/test/contract_substitution/exceptionModified to cause an exception (e.g. invalid opcode).
system_contract/test/contract_substitution/gas_limit_successModified to consume 30,000,000 million gas exactly, execution should be successful.
system_contract/test/contract_substitution/gas_limit_failureModified to consume 30,000,001 million gas exactly, execution should fail.
+

Fork transition

+

Verify calling the system contract before its activation fork results in correct behavior (depends on the system contract implementation).

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
system_contract/test/fork_transition/call_before_forkCall system contract before fork.
+

Framework Changes

+
    +
  • Add system contract address to relevant methods in the fork where the EIP is introduced in src/ethereum_test_forks/forks/forks.py
  • +
  • Add system contract bytecode to the returned value of pre_allocation_blockchain in the fork where the EIP is introduced in src/ethereum_test_forks/forks/forks.py
  • +
+

New Transaction Type

+

Test Vectors

+

Intrinsic Validity

+

Verify the transaction (and the block it is included in) is valid or invalid given the intrinsic validity of the new transaction type, depending on each test scenario.

+

For each new field that affects the intrinsic gas cost of the transaction verify all listed scenarios.

+
Gas Limit
+

Note: Data floor gas cost affects the intrinsic validity of all transaction types, so it must be taken into account when designing all test scenarios.

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/intrinsic_validity/gas_limit/exactProvide the exact intrinsic gas as gas_limit value to the transaction.
transaction_type/test/intrinsic_validity/gas_limit/insufficientProvide the exact intrinsic gas minus one as gas_limit value to the transaction.
+
Gas Fee
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/intrinsic_validity/max_fee/max_priority_lower_than_max_feeInvalid if tx.max_priority_fee_per_gas < tx.max_fee_per_gas.
transaction_type/test/intrinsic_validity/max_fee/max_priority_equal_to_max_feeValid if tx.max_priority_fee_per_gas == tx.max_fee_per_gas.
transaction_type/test/intrinsic_validity/max_fee/base_lowerInvalid if tx.max_fee_per_gas < block.base_fee_per_gas.
transaction_type/test/intrinsic_validity/max_fee/base_equalValid if tx.max_fee_per_gas < block.base_fee_per_gas.
+
Chain ID
+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/intrinsic_validity/chain_idInvalid if tx.chain_id != network.chain_id.
+
Nonce
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/intrinsic_validity/nonce_minus_oneInvalid if tx.nonce == sender.nonce - 1.
transaction_type/test/intrinsic_validity/nonce_plus_oneInvalid if tx.nonce == sender.nonce + 1.
transaction_type/test/intrinsic_validity/nonce_exactValid if tx.nonce == sender.nonce.
+
To
+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/intrinsic_validity/toValid/Invalid if tx.to == None, depending on the EIP.
+
Value
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/intrinsic_validity/value_non_zero_insufficient_balanceInvalid if tx.value == 1 and account.balance == (tx.max_fee_per_gas * tx.gas_price).
transaction_type/test/intrinsic_validity/value_non_zero_sufficient_balanceValid if tx.value == 1 and account.balance == (tx.max_fee_per_gas * tx.gas_price) + 1.
transaction_type/test/intrinsic_validity/value_zero_insufficient_balanceInvalid if tx.value == 0 and account.balance == (tx.max_fee_per_gas * tx.gas_price) - 1.
transaction_type/test/intrinsic_validity/value_zero_sufficient_balanceValid if tx.value == 0 and account.balance == (tx.max_fee_per_gas * tx.gas_price).
+
Data
+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/intrinsic_validity/data_floor_above_intrinsic_gas_costInvalid if data_floor_cost(len(tx.data)) > tx.intrinsic_gas_cost and tx.gas_limit == tx.intrinsic_gas_cost.
transaction_type/test/intrinsic_validity/data_floor_above_intrinsic_gas_costValid if data_floor_cost(len(tx.data)) > tx.intrinsic_gas_cost and tx.gas_limit == data_floor_cost(len(tx.data)).
+

Signature

+

Verify the transaction is correctly rejected if it contains an invalid signature.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/signature/invalid/field_outside_curveV, R, S represent a value that is inside of the field but outside of the curve.
+
V
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/signature/invalid/v/22.
transaction_type/test/signature/invalid/v/2727 (Type-0 transaction valid value).
transaction_type/test/signature/invalid/v/2828 (Type-0 transaction valid value).
transaction_type/test/signature/invalid/v/3535 (Type-0 replay-protected transaction valid value for chain id 1).
transaction_type/test/signature/invalid/v/3636 (Type-0 replay-protected transaction valid value for chain id 1).
transaction_type/test/signature/invalid/v/max2**8-1.
+
R
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/signature/invalid/r/00.
transaction_type/test/signature/invalid/r/secp256k1n_minus_oneSECP256K1N-1.
transaction_type/test/signature/invalid/r/secp256k1nSECP256K1N.
transaction_type/test/signature/invalid/r/secp256k1n_plus_oneSECP256K1N+1.
transaction_type/test/signature/invalid/r/max_minus_one2**256-1.
transaction_type/test/signature/invalid/r/max2**256.
+
S
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/signature/invalid/s/00.
transaction_type/test/signature/invalid/s/secp256k1n_half_minus_oneSECP256K1N//2-1.
transaction_type/test/signature/invalid/s/secp256k1n_halfSECP256K1N//2.
transaction_type/test/signature/invalid/s/secp256k1n_half_plus_oneSECP256K1N//2+1.
transaction_type/test/signature/invalid/s/secp256k1n_minus_oneSECP256K1N-1.
transaction_type/test/signature/invalid/s/secp256k1nSECP256K1N.
transaction_type/test/signature/invalid/s/secp256k1n_plus_oneSECP256K1N+1.
transaction_type/test/signature/invalid/s/max_minus_one2**256-1.
transaction_type/test/signature/invalid/s/max2**256.
transaction_type/test/signature/invalid/s/complementSECP256K1N - S of a valid signature.
+

Transaction Attributes Readable From EVM

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/tx_scoped_attributes/readVerify attributes that can be read in the EVM from transaction fields.
transaction_type/test/tx_scoped_attributes/older_tx_typesVerify attributes specific to the new transaction type that can be read in the EVM behave correctly on older transaction types.
+

Transaction-Scoped Persistent Values

+

Verify values or variables that are persistent through the execution of the transaction (e.g. transient storage, warm/cold accounts).

+

| transaction_type/test/tx_scoped_attributes/persistent/throughout | Persist throughout the entire transaction. | | | +| transaction_type/test/tx_scoped_attributes/persistent/reset | Reset on subsequent transactions in the same block. | | |

+

Encoding (RLP, SSZ)

+

Verify correct transaction rejection in all listed scenarios.

+
Field Sizes
+

Verify all listed scenarios for each transaction field.

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/encoding/field_sizes/leading_zeroAdd leading zero byte.
transaction_type/test/encoding/field_sizes/remove_byteRemove single byte from fixed-byte-length fields.
+
Fields of List Type
+

Verify for each transaction field that is of type list.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/encoding/list_field/zeroZero-element list (Failure depending on EIP).
transaction_type/test/encoding/list_field/maxMax count list.
transaction_type/test/encoding/list_field/max_plus_oneMax count plus one list.
+
Extra/Missing Fields
+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/encoding/missing_fieldsAny fields particular to the new transaction types are missing.
transaction_type/test/encoding/extra_fieldsTransaction contains extra fields.
+
Serialization Corruption
+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/encoding/truncatedSerialized bytes object is truncated by one byte.
transaction_type/test/encoding/extra_bytesSerialized bytes object has one extra byte.
+
Serializable Fields
+

Verify for each serializable field, all previous tests plus following listed scenario.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/encoding/new_types/incorrect_encodingSerializable field is encoded as bytes instead of using the correct encoding (e.g. list in the case of RLP).
+

Out-of-bounds checks

+

Verify if the transaction has out-of-bounds conditions in its fields and verify.

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/out_of_bounds/maxMax value for each field.
transaction_type/test/out_of_bounds/max_plus_oneMax value + 1 for each field.
+

Contract creation

+

Verify that the transaction can create new contracts if the transaction type supports it.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/contract_creationCreate contracts using new transaction type.
+

Sender account modifications

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/sender_account/nonceSender account has its nonce incremented at least by one after the transaction is included in a block (or more if the transaction type introduces a new mechanism that bumps the nonce by more than one).
transaction_type/test/sender_account/balanceSender account has its balance reduced by the correct amount (gas consumed and value) at the start of execution (e.g. using BALANCE).
+

Block Level Interactions

+
Single Transaction In Block
+

Verify a block where the new transaction type is the sole transaction contained in the block.

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/block_interactions/single_tx/invalidInvalid if tx.gas_limit == block.gas_limit + 1.
transaction_type/test/block_interactions/single_tx/validValid if tx.gas_limit == block.gas_limit.
+
Two Transactions In Block
+

Verify a block where the new transaction type is the last transaction contained in a block with two transactions.

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/block_interactions/last_tx/validValid if block.txs[0].gas_used + block.txs[1].gas_limit == block.gas_limit.
transaction_type/test/block_interactions/last_tx/invalidInvalid if (block.txs[0].gas_used + block.txs[1].gas_limit == block.gas_limit + 1) and (block.txs[0].gas_used < block.gas_limit).
+
EIP-7825
+

Verify a transaction of the new type is rejected if its gas limit exceeds the EIP-7825 gas limit for the current fork.

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/block_interactions/eip7825/invalidExceeds EIP-7825 gas limit by one.
transaction_type/test/block_interactions/eip7825/validGas limit is exactly the EIP-7825 gas limit.
+
Mixed transactions
+

Verify a block with all transactions types including the new type is executed correctly.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/block_interactions/mixed_txsMixed transactions.
+

Fork transition

+

Verify that a block prior to fork activation where the new transaction type is introduced and containing the new transaction type is invalid.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
transaction_type/test/fork_transition/beforeNew transaction type included before fork activation block.
+

RPC Tests

+
    +
  • *Verify eth_estimateGas behavior for different valid combinations of the new transaction type.
  • +
  • transaction_type/test/rpc/send_raw | Verify eth_sendRawTransaction using execute.
  • +
+

*Tests must be added to execution-apis repository.

+

Framework Changes

+
    +
  • Modify transaction_intrinsic_cost_calculator in the fork where the EIP is introduced in src/ethereum_test_forks/forks/forks.py, adding the appropriate new fields that the transaction introduced and the logic to the intrinsic gas cost calculation, if any.
  • +
  • Add the transaction type number to tx_types response in the fork where the EIP is introduced in src/ethereum_test_forks/forks/forks.py (If applicable add also to contract_creating_tx_types).
  • +
+

New Block Header Field

+

Test Vectors

+

Genesis value

+

Verify, if possible, that the value can be set at genesis if the network starting fork is the activation fork, and that clients can consume such genesis.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
block_header_field/test/genesisNew block header field at genesis.
+

Value behavior

+

Verify, given multiple initial values, that a block is accepted or rejected depending on the correct expected value for the current block.

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
block_header_field/test/value_behavior/acceptBlock is accepted if the value is the correct expected for the current block, depending on the circumstances that affect the value as defined in the EIP.
block_header_field/test/value_behavior/rejectBlock is rejected if the value is modified (using block.rlp_modifier) to an incorrect value for the current block, depending on the circumstances that affect the value as defined in the EIP.
+

Fork transition

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
block_header_field/test/fork_transition/initialVerify initial value of the field at the first block of the activation fork.
block_header_field/test/fork_transition/beforeVerify that a block containing the new header field before the activation of the fork is invalid.
block_header_field/test/fork_transition/afterVerify that a block lacking the new header field at the activation of the fork is invalid.
+

Framework Changes

+
    +
  • Add the new header field to the relevant objects: +
      +
    • ethereum_test_fixtures.FixtureHeader.
    • +
    • ethereum_test_fixtures.FixtureExecutionPayload.
    • +
    • ethereum_test_specs.Header.
    • +
    +
  • +
  • Add the appropriate header_*_required fork method to BaseFork in ethereum_test_forks.
  • +
+

New Block Body Field

+

Test Vectors

+

Value behavior

+

Verify, given multiple initial values, that a block is accepted or rejected depending on the correct expected value for the current block.

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
block_body_field/test/value_behavior/acceptBlock is accepted if the value is the correct expected for the current block, depending on the circumstances that affect the value as defined in the EIP.
block_body_field/test/value_behavior/rejectBlock is rejected if the value is modified (using appropriate block) to an incorrect value for the current block, depending on the circumstances that affect the value as defined in the EIP.
+

Fork transition

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
block_body_field/test/fork_transition/beforeVerify that a block containing the new block body field before the activation of the fork is invalid.
block_body_field/test/fork_transition/afterVerify that a block lacking the new block field at the activation of the fork is invalid.
+

Framework Changes

+
    +
  • Add the new body field to the relevant objects. +
      +
    • ethereum_test_fixtures.FixtureBlockBase.
    • +
    • ethereum_test_fixtures.FixtureEngineNewPayload.
    • +
    • ethereum_test_specs.Block.
    • +
    +
  • +
  • Modify ethereum_test_specs.BlockchainTest filling behavior to account for the new block field.
  • +
+

Gas Cost Changes

+

Test Vectors

+

Gas Usage

+

Measure and store the gas usage during the operations affected by the gas cost changes and verify the updated behavior.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
gas_cost_changes/test/gas_updates_measurementMeasure updated gas costs.
+

Out-of-gas

+

Verify the operations affected by the gas cost changes can run out-of-gas with the updated limits.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
gas_cost_changes/test/out_of_gasOut-Of-Gas with new gas prices.
+

Fork transition

+

Verify gas costs are updated at the fork transition boundary.

+ + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
gas_cost_changes/test/fork_transition/beforeCosts unaffected before the fork activation block.
gas_cost_changes/test/fork_transition/afterCosts are updated on and after fork activation block.
+

Framework Changes

+
    +
  • Modify transaction_intrinsic_cost_calculator in the fork where the EIP is introduced in src/ethereum_test_forks/forks/forks.py if the EIP affects intrinsic gas cost calculation.
  • +
  • Modify transaction_data_floor_cost_calculator in the fork where the EIP is introduced in src/ethereum_test_forks/forks/forks.py if the EIP affects calldata floor cost.
  • +
  • Modify memory_expansion_gas_calculator in the fork where the EIP is introduced in src/ethereum_test_forks/forks/forks.py if the EIP affects memory expansion gas cost calculation.
  • +
  • Modify gas_costs in the fork where the EIP is introduced in src/ethereum_test_forks/forks/forks.py if the EIP affects specific opcode gas costs.
  • +
+

Gas Refunds Changes

+

Test Vectors

+

Refund calculation

+

Verify that the refund does not exceed gas_used // MAX_REFUND_QUOTIENT (MAX_REFUND_QUOTIENT==5 in EIP-3529) in the following scenarios.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
gas_refunds_changes/test/refund_calculation/overrefund == gas_used // MAX_REFUND_QUOTIENT + 1.
gas_refunds_changes/test/refund_calculation/exactrefund == gas_used // MAX_REFUND_QUOTIENT.
gas_refunds_changes/test/refund_calculation/underrefund == gas_used // MAX_REFUND_QUOTIENT - 1.
+

Exceptional Abort

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
gas_refunds_changes/test/exceptional_abort/revertableIf the operation causing the refund can be reverted, verify the refund is not applied if the following cases:.
gas_refunds_changes/test/exceptional_abort/revertable/revertREVERT.
gas_refunds_changes/test/exceptional_abort/revertable/out_of_gasOut-of-gas.
gas_refunds_changes/test/exceptional_abort/revertable/invalid_opcodeInvalid opcode.
gas_refunds_changes/test/exceptional_abort/revertable/upper_revertREVERT of an upper call frame.
gas_refunds_changes/test/exceptional_abort/non_revertableIf the operation causing the refund cannot be reverted (e.g. in the case of a transaction-scoped operation such as authorization refunds in EIP-7702), verify the refund is still applied even in the following cases:.
gas_refunds_changes/test/exceptional_abort/non_revertable/revertREVERT at the top call frame.
gas_refunds_changes/test/exceptional_abort/non_revertable/out_of_gasOut-of-gas at the top call frame.
gas_refunds_changes/test/exceptional_abort/non_revertable/invalid_opcodeInvalid opcode at the top call frame.
+

Cross-Functional Test

+

Verify the following tests are updated to support the new type of refunds.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
gas_refunds_changes/test/cross_functional/calldata_costtests/prague/eip7623_increase_calldata_cost/test_refunds.py.
+

Framework Changes

+

N/A

+

Blob Count Changes

+

Test Vectors

+

Existing Test Updates

+

Verify tests in tests/cancun/eip4844_blobs were correctly and automatically updated to take into account the new blob count values at the new fork activation block.

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
blob_count_changes/test/eip4844_blobs_changesUpdates to tests/cancun/eip4844_blobs were applied correctly.
+

Framework Changes

+
    +
  • Modify blob_base_fee_update_fraction, target_blobs_per_block, max_blobs_per_block in the fork where the EIP is introduced in src/ethereum_test_forks/forks/forks.py if the EIP affects any of the values returned by each function.
  • +
+

New Execution Layer Request

+

Test Vectors

+

Cross-Request-Type Interaction

+ + + + + + + + + + + + + + + + + +
IDDescriptionStatusTests
execution_layer_request/test/cross_request_type/updateUpdate tests/prague/eip7685_general_purpose_el_requests tests to include the new request type in the tests combinations.
+

Framework Changes

+
    +
  • Increment max_request_type in the fork where the EIP is introduced in src/ethereum_test_forks/forks/forks.py to the new maximum request type number after the EIP is activated.
  • +
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/writing_tests/checklist_templates/index.html b/docs/public/main/writing_tests/checklist_templates/index.html new file mode 100644 index 00000000000..0f7a44707a6 --- /dev/null +++ b/docs/public/main/writing_tests/checklist_templates/index.html @@ -0,0 +1,741 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
+ + + + +
+
+

+
+ + +
+

Testing Checklist Templates

+

This page includes checklist templates that must be followed to guarantee a minimum base testing coverage of new EIP feature.

+
+
+
+
+
+ +
+ + + + + + + diff --git a/docs/public/main/writing_tests/checklist_templates/main/index.html b/docs/public/main/writing_tests/checklist_templates/main/index.html new file mode 100644 index 00000000000..ff2492ace3a --- /dev/null +++ b/docs/public/main/writing_tests/checklist_templates/main/index.html @@ -0,0 +1,1204 @@ + + + + + + + Checklist Templates - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

Checklist Templates

+
+ +
+

Testing Checklist Templates

+

This page includes checklist templates that must be followed to guarantee a minimum base testing coverage of new EIP feature.

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/writing_tests/code_standards/index.html b/docs/public/main/writing_tests/code_standards/index.html new file mode 100644 index 00000000000..f87ca8677ee --- /dev/null +++ b/docs/public/main/writing_tests/code_standards/index.html @@ -0,0 +1,1399 @@ + + + + + + + Code Standards - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

Code Standards

+
+ +
+

Code Standards

+

This documentation has been relocated.

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/writing_tests/eest_make_test.gif b/docs/public/main/writing_tests/eest_make_test.gif new file mode 100644 index 00000000000..e2842a9f6ba Binary files /dev/null and b/docs/public/main/writing_tests/eest_make_test.gif differ diff --git a/docs/public/main/writing_tests/eip_checklist/index.html b/docs/public/main/writing_tests/eip_checklist/index.html new file mode 100644 index 00000000000..d006ad534bc --- /dev/null +++ b/docs/public/main/writing_tests/eip_checklist/index.html @@ -0,0 +1,1555 @@ + + + + + + + EIP Checklist Generation - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

EIP Checklist Generation

+
+ +
+

The EIP checklist feature helps track test coverage for EIP implementations by automatically generating filled checklists based on test markers.

+

Overview

+

When implementing tests for an EIP, you can mark specific tests as covering checklist items from the EIP testing checklist template. The framework will then generate a filled checklist showing which items have been implemented.

+

Marking Tests as implementing EIP Checklist Items

+

To mark a test as implementing a specific checklist item, use the structured EIPChecklist class:

+

The EIPChecklist Class

+
import pytest
+from ethereum_test_tools import StateTestFiller
+from ethereum_test_checklists import EIPChecklist
+
+@EIPChecklist.TransactionType.Test.IntrinsicValidity.GasLimit.Exact()
+def test_exact_intrinsic_gas(state_test: StateTestFiller):
+    """Test transaction with exact intrinsic gas limit."""
+    # Test implementation
+    pass
+
+# You can also use the marker without parentheses
+@EIPChecklist.TransactionType.Test.IntrinsicValidity.GasLimit.Insufficient
+def test_insufficient_intrinsic_gas(state_test: StateTestFiller):
+    """Test transaction with insufficient intrinsic gas limit."""
+    # Test implementation
+    pass
+

The EIPChecklist class provides type safety and IDE autocompletion, making it easier to find and reference checklist items correctly.

+

Marker Parameters

+
    +
  • First positional parameter (required): The checklist item ID (EIPChecklist reference)
  • +
  • eip keyword parameter (optional): List of additional EIPs covered by the test
  • +
+

Example with multiple EIPs covered by the same test:

+
@EIPChecklist.TransactionType.Test.Signature.Invalid.V.Two(
+    eip=[7702, 2930]
+)
+def test_invalid_signature(state_test: StateTestFiller):
+    """Test invalid signature that affects multiple EIPs."""
+    pass
+

Partial ID Matching

+

You can use partial IDs that will match all checklist items starting with that prefix:

+
@EIPChecklist.TransactionType.Test.Signature.Invalid()
+def test_all_invalid_signatures(state_test: StateTestFiller):
+    """Test covering all invalid signature scenarios."""
+    pass
+

Generating Checklists

+

Using the Dedicated checklist Command

+

To generate only checklists without filling fixtures:

+
# Generate checklists for all EIPs
+uv run checklist
+
+# Generate checklist for specific EIP
+uv run checklist --eip 7702
+
+# Specify output directory
+uv run checklist --output ./my-checklists
+
+# Multiple EIPs
+uv run checklist --eip 7702 --eip 2930
+

Automatic Generation in Documentation

+

When building the documentation with mkdocs, checklists are automatically generated for all EIPs that have tests with checklist markers. The checklists appear in the test documentation alongside the test modules.

+

External Coverage and Not Applicable Items

+

External Coverage

+

For checklist items that are covered by external tests, procedures, or tools (e.g., EELS coverage), create a file named eip_checklist_external_coverage.txt in the EIP test directory:

+
# tests/prague/eip7702_set_code_tx/eip_checklist_external_coverage.txt
+general/code_coverage/eels = Covered by EELS test suite
+general/code_coverage/second_client = Covered by Nethermind tests
+

Format: checklist_item_id = reason

+

Not Applicable Items

+

For checklist items that are not applicable to a specific EIP, create a file named eip_checklist_not_applicable.txt in the EIP test directory:

+
# tests/prague/eip7702_set_code_tx/eip_checklist_not_applicable.txt
+system_contract = EIP-7702 does not introduce a system contract
+precompile = EIP-7702 does not introduce a precompile
+

Format: checklist_item_id = reason

+

Both files support partial ID matching, so you can mark entire sections as not applicable:

+

MyPy Type Checking Support

+

The EIPChecklist classes are made callable through a companion .pyi stub file that provides proper type hints for mypy. This allows you to use both decorator patterns without type checking errors:

+
# Both of these work with proper mypy support
+@EIPChecklist.Opcode.Test.StackComplexOperations()  # With parentheses
+@EIPChecklist.Opcode.Test.StackComplexOperations   # Without parentheses
+

Regenerating Type Stubs

+

If you modify the EIPChecklist class structure in src/ethereum_test_checklists/eip_checklist.py, you need to regenerate the type stub file:

+
# Generate the stub file (for maintainers):
+uv run generate_checklist_stubs
+
+# Preview what would be generated without writing the file
+uv run generate_checklist_stubs --dry-run
+
+# Generate to a custom location
+uv run generate_checklist_stubs --output path/to/custom/stubs.pyi
+

The generated stub file (eip_checklist.pyi) should be committed to the repository to ensure proper type checking for all developers.

+
# Mark all system contract items as not applicable
+system_contract/ = EIP does not introduce system contracts
+

Output Format

+

The generated checklist will show:

+
    +
  • βœ… for completed items (either by tests or external coverage)
  • +
  • N/A for not applicable items
  • +
  • Test names that implement each item
  • +
  • External coverage reasons where applicable
  • +
  • A percentage of covered checklist items (excluding N/A items)
  • +
  • Color-coded completion status: 🟒 (100%), 🟑 (>50%), πŸ”΄ (≀50%)
  • +
+

Example output snippet:

+
# EIP-7702 Test Checklist
+
+## Checklist Progress Tracker
+
+| Total Checklist Items | Covered Checklist Items | Percentage |
+| --------------------- | ----------------------- | ---------- |
+| 45 | 32 | 🟑 71.11% |
+
+## General
+
+#### Code coverage
+
+| ID | Description | Status | Tests |
+| -- | ----------- | ------ | ----- |
+| `general/code_coverage/eels` | Run produced tests against EELS... | βœ… | Covered by EELS test suite |
+| `general/code_coverage/test_coverage` | Run coverage on the test code itself... | βœ… | `tests/prague/eip7702_set_code_tx/test_set_code_txs.py::test_set_code_txs` |
+
+## Transaction Type
+
+| ID | Description | Status | Tests |
+| -- | ----------- | ------ | ----- |
+| `transaction_type/test/intrinsic_validity/gas_limit/exact` | Provide the exact intrinsic gas... | βœ… | `tests/prague/eip7702_set_code_tx/test_checklist_example.py::test_exact_intrinsic_gas` |
+| `transaction_type/test/intrinsic_validity/gas_limit/insufficient` | Provide the exact intrinsic gas minus one... |  |  |
+
+## System Contract
+
+| ID | Description | Status | Tests |
+| -- | ----------- | ------ | ----- |
+| `system_contract/test/deployment/missing` | Verify block execution behavior... | N/A | EIP-7702 does not introduce a system contract |
+

Best Practices

+
    +
  1. Start with the checklist: Review the checklist template before writing tests to ensure comprehensive coverage
  2. +
  3. Use the EIPChecklist class: Use EIPChecklist.Opcode.Test.GasUsage.Normal for type safety and IDE autocompletion
  4. +
  5. Use descriptive test names: The test name will appear in the checklist, so make it clear what the test covers
  6. +
  7. Mark items as you go: Add eip_checklist markers while writing tests, not as an afterthought
  8. +
  9. Document external coverage: If items are covered by external tools/tests, document this in eip_checklist_external_coverage.txt
  10. +
  11. Be explicit about N/A items: Document why items are not applicable in eip_checklist_not_applicable.txt
  12. +
  13. Use partial IDs wisely: When a test covers multiple related items, use partial IDs to mark them all
  14. +
  15. Verify IDs before using: Use str(EIPChecklist.Section.Subsection) to verify the exact string ID when needed
  16. +
+

Workflow Example

+
    +
  1. +

    Create test directory structure:

    +
    tests/prague/eip9999_new_feature/
    +β”œβ”€β”€ __init__.py
    +β”œβ”€β”€ spec.py
    +β”œβ”€β”€ test_basic.py
    +β”œβ”€β”€ eip_checklist_external_coverage.txt
    +└── eip_checklist_not_applicable.txt
    +
  2. +
  3. +

    Mark tests as you implement them:

    +
    from ethereum_test_checklists import EIPChecklist
    +
    +@EIPChecklist.Opcode.Test.GasUsage.Normal()
    +def test_opcode_gas_consumption(state_test: StateTestFiller):
    +   """Test normal gas consumption of the new opcode."""
    +   pass
    +
  4. +
  5. +

    Document external coverage:

    +
    # eip_checklist_external_coverage.txt
    +general/code_coverage/eels = Covered by ethereum/execution-specs PR #1234
    +

    You can verify the correct ID using:

    +
    # str(EIPChecklist.General.CodeCoverage.Eels) = "general/code_coverage/eels"
    +
  6. +
  7. +

    Mark non-applicable items:

    +
    # eip_checklist_not_applicable.txt
    +precompile/ = EIP-9999 introduces an opcode, not a precompile
    +

    You can verify the correct ID using:

    +
    # str(EIPChecklist.Precompile) = "precompile"
    +
  8. +
  9. +

    Generate and review checklist:

    +
    checklist --eip 9999
    +# Review the generated checklist for completeness
    +
  10. +
+

See Also

+ +
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/writing_tests/exception_tests/index.html b/docs/public/main/writing_tests/exception_tests/index.html new file mode 100644 index 00000000000..1de574a53a9 --- /dev/null +++ b/docs/public/main/writing_tests/exception_tests/index.html @@ -0,0 +1,1394 @@ + + + + + + + Exception Tests - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

Exception Tests

+
+ +
+

Exception tests are a special type of test which verify that an invalid transaction or an invalid block are correctly rejected with the expected error.

+

Creating an Exception Test

+

To test for an exception, the test can use either of the following types from ethereum_test_exceptions library:

+
    +
  1. +

    TransactionException: To be added to the error field of the Transaction object, and to the exception field of the Block object that includes the transaction; this exception type is used when a transaction is invalid, and therefore when included in a block, the block is expected to be invalid too. This is different from valid transactions where an exception during EVM execution is expected (e.g. a revert, or out-of-gas), which can be included in valid blocks.

    +

    For an example, see eip3860_initcode.test_initcode.test_contract_creating_tx which raises TransactionException.INITCODE_SIZE_EXCEEDED in the case that the initcode size exceeds the maximum allowed size.

    +
  2. +
  3. +

    BlockException: To be added to the exception field of the Block object; this exception type is used when a block is expected to be invalid, but the exception is related to a block property, e.g. an invalid value of the block header.

    +

    For an example, see eip4844_blobs.test_excess_blob_gas.test_invalid_static_excess_blob_gas which raises BlockException.INCORRECT_EXCESS_BLOB_GAS in the case that the excessBlobGas remains unchanged +but the parent blobs included are not TARGET_BLOBS_PER_BLOCK.

    +
  4. +
+

Although exceptions can be combined with the | operator to indicate that a test vector can throw either one of multiple exceptions, ideally the tester should aim to use only one exception per test vector, and only use multiple exceptions on the rare instance when it is not possible to know which exception will be thrown because it depends on client implementation.

+

Adding a new exception

+

If a test requires a new exception, because none of the existing ones is suitable for the test, a new exception can be added to either TransactionException or BlockException classes.

+

The new exception should be added as a new enum value, and the docstring of the attribute should be a string that describes the exception.

+

The name of the exception should be unique, and should not be used by any other exception.

+

Test runner behavior on exception tests

+

When an exception is added to a test vector, the test runner must check that the transaction or block is rejected with the expected exception.

+

The test runner must map the exception key to the corresponding error string that is expected to be returned by the client.

+

Exception mapping are particularly important in blockchain tests because the block can be invalid for multiple reasons, and the client returning a different error can mean that a verification in the client is faulty.

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/writing_tests/fork_methods/index.html b/docs/public/main/writing_tests/fork_methods/index.html new file mode 100644 index 00000000000..f817c30c4ce --- /dev/null +++ b/docs/public/main/writing_tests/fork_methods/index.html @@ -0,0 +1,1566 @@ + + + + + + + Using and Extending Fork Methods - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

Using and Extending Fork Methods

+
+ +
+

This document describes the Fork class in the Ethereum execution spec tests framework, which provides a standardized way to define properties of Ethereum forks. Understanding how to use and extend these fork methods is essential for writing flexible tests that can automatically adapt to different forks.

+

Overview

+

The BaseFork class is an abstract base class that defines the interface for all Ethereum forks. Each implemented fork (like Frontier, Homestead, etc.) extends this class and implements its abstract methods to provide fork-specific behavior.

+

The fork system allows:

+
    +
  1. Defining fork-specific behaviors and parameters
  2. +
  3. Comparing forks chronologically (Paris < Shanghai)
  4. +
  5. Supporting automatic fork transitions
  6. +
  7. Writing tests that automatically adapt to different forks
  8. +
+

Using Fork Methods in Tests

+

Fork methods are powerful tools that allow your tests to adapt to different Ethereum forks automatically. Here are common patterns for using them:

+

1. Check Fork Support for Features

+
def test_some_feature(fork):
+    if fork.supports_blobs(block_number=0, timestamp=0):
+        # Test blob-related functionality
+        ...
+    else:
+        # Test alternative or skip
+        pytest.skip("Fork does not support blobs")
+

2. Get Fork-Specific Parameters

+
def test_transaction_gas(fork, state_test):
+    gas_cost = fork.gas_costs(block_number=0, timestamp=0).G_TRANSACTION
+    
+    # Create a transaction with the correct gas parameters for this fork
+    tx = Transaction(
+        gas_limit=gas_cost + 10000,
+        # ...
+    )
+    
+    state_test(
+        env=Environment(),
+        pre=pre,
+        tx=tx,
+        # ...
+    )
+

3. Determine Valid Transaction Types

+
def test_transaction_types(fork, state_test):
+    for tx_type in fork.tx_types(block_number=0, timestamp=0):
+        # Test each transaction type supported by this fork
+        # ...
+

4. Determine Valid Opcodes

+
def test_opcodes(fork, state_test):
+    # Create bytecode using only opcodes valid for this fork
+    valid_opcodes = fork.valid_opcodes()
+    
+    # Use these opcodes to create test bytecode
+    # ...
+

5. Test Fork Transitions

+
def test_fork_transition(transition_fork, blockchain_test):
+    # The transition_fork is a special fork type that changes behavior
+    # based on block number or timestamp
+    fork_before = transition_fork.fork_at(block_number=4, timestamp=0)
+    fork_after = transition_fork.fork_at(block_number=5, timestamp=0)
+    
+    # Test behavior before and after transition
+    # ...
+

Important Fork Methods

+

Header Information

+

These methods determine what fields are required in block headers for a given fork:

+
fork.header_base_fee_required(block_number=0, timestamp=0)  # Added in London
+fork.header_prev_randao_required(block_number=0, timestamp=0)  # Added in Paris
+fork.header_withdrawals_required(block_number=0, timestamp=0)  # Added in Shanghai
+fork.header_excess_blob_gas_required(block_number=0, timestamp=0)  # Added in Cancun
+fork.header_blob_gas_used_required(block_number=0, timestamp=0)  # Added in Cancun
+fork.header_beacon_root_required(block_number=0, timestamp=0)  # Added in Cancun
+fork.header_requests_required(block_number=0, timestamp=0)  # Added in Prague
+

Gas Parameters

+

Methods for determining gas costs and calculations:

+
fork.gas_costs(block_number=0, timestamp=0)  # Returns a GasCosts dataclass
+fork.memory_expansion_gas_calculator(block_number=0, timestamp=0)  # Returns a callable
+fork.transaction_intrinsic_cost_calculator(block_number=0, timestamp=0)  # Returns a callable
+

Transaction Types

+

Methods for determining valid transaction types:

+
fork.tx_types(block_number=0, timestamp=0)  # Returns list of supported transaction types
+fork.contract_creating_tx_types(block_number=0, timestamp=0)  # Returns list of tx types that can create contracts 
+fork.precompiles(block_number=0, timestamp=0)  # Returns list of precompile addresses
+fork.system_contracts(block_number=0, timestamp=0)  # Returns list of system contract addresses
+

EVM Features

+

Methods for determining EVM features and valid opcodes:

+
fork.evm_code_types(block_number=0, timestamp=0)  # Returns list of supported code types (e.g., Legacy, EOF)
+fork.valid_opcodes()  # Returns list of valid opcodes for this fork
+fork.call_opcodes(block_number=0, timestamp=0)  # Returns list of call opcodes with their code types
+fork.create_opcodes(block_number=0, timestamp=0)  # Returns list of create opcodes with their code types
+
+

Methods for blob transaction support:

+
fork.supports_blobs(block_number=0, timestamp=0)  # Returns whether blobs are supported
+fork.blob_gas_price_calculator(block_number=0, timestamp=0)  # Returns a callable
+fork.excess_blob_gas_calculator(block_number=0, timestamp=0)  # Returns a callable
+fork.min_base_fee_per_blob_gas(block_number=0, timestamp=0)  # Returns minimum base fee per blob gas
+fork.blob_gas_per_blob(block_number=0, timestamp=0)  # Returns blob gas per blob
+fork.target_blobs_per_block(block_number=0, timestamp=0)  # Returns target blobs per block
+fork.max_blobs_per_block(block_number=0, timestamp=0)  # Returns max blobs per block
+

Meta Information

+

Methods for fork identification and comparison:

+
fork.name()  # Returns the name of the fork
+fork.transition_tool_name(block_number=0, timestamp=0)  # Returns name for transition tools
+fork.is_deployed()  # Returns whether the fork is deployed to mainnet
+

Fork Transitions

+

The framework supports creating transition forks that change behavior at specific block numbers or timestamps:

+
@transition_fork(to_fork=Shanghai, at_timestamp=15_000)
+class ParisToShanghaiAtTime15k(Paris):
+    """Paris to Shanghai transition at Timestamp 15k."""
+    pass
+

With transition forks, you can test how behavior changes across fork boundaries:

+
# Behavior changes at block 5
+fork = BerlinToLondonAt5
+assert not fork.header_base_fee_required(block_number=4)  # Berlin doesn't require base fee
+assert fork.header_base_fee_required(block_number=5)      # London requires base fee
+

Adding New Fork Methods

+

When adding new fork methods, follow these guidelines:

+
    +
  1. Abstract Method Definition: Add the new abstract method to BaseFork in base_fork.py
  2. +
  3. Consistent Parameter Pattern: Use block_number and timestamp parameters with default values
  4. +
  5. Method Documentation: Add docstrings explaining the purpose and behavior
  6. +
  7. Implementation in Subsequent Forks: Implement the method in every subsequent fork class only if the fork updates the value from previous forks.
  8. +
+

Example of adding a new method:

+
@classmethod
+@abstractmethod
+def supports_new_feature(cls, block_number: int = 0, timestamp: int = 0) -> bool:
+    """Return whether the given fork supports the new feature."""
+    pass
+

Implementation in a fork class:

+
@classmethod
+def supports_new_feature(cls, block_number: int = 0, timestamp: int = 0) -> bool:
+    """Return whether the given fork supports the new feature."""
+    return False  # Frontier doesn't support this feature
+

Implementation in a newer fork class:

+
@classmethod
+def supports_new_feature(cls, block_number: int = 0, timestamp: int = 0) -> bool:
+    """Return whether the given fork supports the new feature."""
+    return True  # This fork does support the feature
+

When to Add a New Fork Method

+

Add a new fork method when:

+
    +
  1. A New EIP Introduces a Feature: Add methods describing the new feature’s behavior
  2. +
  3. Tests Need to Behave Differently: When tests need to adapt to different fork behaviors
  4. +
  5. Common Fork Information is Needed: When multiple tests need the same fork-specific information
  6. +
  7. Intrinsic Fork Properties Change: When gas costs, opcodes, or other intrinsic properties change
  8. +
+

Do not add a new fork method when:

+
    +
  1. The information is only needed for one specific test
  2. +
  3. The information is not directly related to fork behavior
  4. +
  5. The information can be calculated using existing methods
  6. +
+

Best Practices

+
    +
  1. Use Existing Methods: Check if there’s already a method that provides the information you need
  2. +
  3. Name Methods Clearly: Method names should clearly describe what they return
  4. +
  5. Document Behavior: Include clear docstrings explaining the method’s purpose and return value
  6. +
  7. Avoid Hard-coding: Use fork methods in tests instead of hard-coding fork-specific behavior
  8. +
  9. Test Transitions: Ensure your method works correctly with transition forks
  10. +
+

Example: Complete Test Using Fork Methods

+

Here’s an example of a test that fully utilizes fork methods to adapt its behavior:

+
def test_transaction_with_fork_adaptability(fork, state_test):
+    # Prepare pre-state
+    pre = Alloc()
+    sender = pre.fund_eoa()
+    
+    # Define transaction based on fork capabilities
+    tx_params = {
+        "gas_limit": 1_000_000,
+        "sender": sender,
+    }
+    
+    # Add appropriate transaction type based on fork
+    tx_types = fork.tx_types(block_number=0, timestamp=0)
+    if 3 in tx_types and fork.supports_blobs(block_number=0, timestamp=0):
+        # EIP-4844 blob transaction (type 3)
+        tx_params["blob_versioned_hashes"] = [Hash.generate_zero_hashes(1)[0]]
+    elif 2 in tx_types:
+        # EIP-1559 transaction (type 2)
+        tx_params["max_fee_per_gas"] = 10
+        tx_params["max_priority_fee_per_gas"] = 1
+    elif 1 in tx_types:
+        # EIP-2930 transaction (type 1)
+        tx_params["access_list"] = []
+        
+    # Create and run the test
+    tx = Transaction(**tx_params)
+    
+    state_test(
+        env=Environment(),
+        pre=pre,
+        tx=tx,
+        post={
+            sender: Account(nonce=1),
+        },
+    )
+

Conclusion

+

The Fork class is a powerful abstraction that allows tests to adapt to different Ethereum forks. By using fork methods consistently, you can write tests that automatically handle fork-specific behavior, making your tests more maintainable and future-proof.

+

When adding new fork methods, keep them focused, well-documented, and implement them across all forks. This will ensure that all tests can benefit from the information and that transitions between forks are handled correctly.

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/writing_tests/img/eest_make_test.mp4 b/docs/public/main/writing_tests/img/eest_make_test.mp4 new file mode 100644 index 00000000000..5694dc8de07 Binary files /dev/null and b/docs/public/main/writing_tests/img/eest_make_test.mp4 differ diff --git a/docs/public/main/writing_tests/img/eip_reference_spec_console_output.png b/docs/public/main/writing_tests/img/eip_reference_spec_console_output.png new file mode 100644 index 00000000000..f043ed2fef4 Binary files /dev/null and b/docs/public/main/writing_tests/img/eip_reference_spec_console_output.png differ diff --git a/docs/public/main/writing_tests/img/eip_reference_spec_console_output_fail.png b/docs/public/main/writing_tests/img/eip_reference_spec_console_output_fail.png new file mode 100644 index 00000000000..2c36f0dfbaf Binary files /dev/null and b/docs/public/main/writing_tests/img/eip_reference_spec_console_output_fail.png differ diff --git a/docs/public/main/writing_tests/main/index.html b/docs/public/main/writing_tests/main/index.html new file mode 100644 index 00000000000..9b64716d3f0 --- /dev/null +++ b/docs/public/main/writing_tests/main/index.html @@ -0,0 +1,1385 @@ + + + + + + + Writing Tests - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

Writing Tests

+
+ +
+

The easiest way to get started is to use the interactive CLI:

+
uv run eest make test
+

and modify the generated test module to suit your needs.

+

Gif that shows how to create a test in EEST

+

For help deciding which test format to select, see Types of Tests, in particular Deciding on a Test Type.

+

Key Resources

+ +

Please check that your code adheres to the repo’s coding standards and read the other pages in this section for more background and an explanation of how to implement state transition and blockchain tests.

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/writing_tests/porting_legacy_tests/index.html b/docs/public/main/writing_tests/porting_legacy_tests/index.html new file mode 100644 index 00000000000..e0b32621ec5 --- /dev/null +++ b/docs/public/main/writing_tests/porting_legacy_tests/index.html @@ -0,0 +1,1499 @@ + + + + + + + Porting Legacy Tests - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

Porting Legacy Tests

+
+ +
+

Background

+

EEST is the successor to ethereum/tests (aka “original tests”), a repository that defined EVM test cases from the Frontier phase up to and including The Merge. These test cases are specified as YAML (and occasionally JSON) files in the ./src/ sub-directory. JSON test fixtures, which are fully-populated tests that can be executed against clients, are generated using ethereum/retesteth. These JSON artifacts are regenerated when needed and added to the repository, typically in the tests/static/state_tests sub-directory.

+

From Shanghai onward, new test cases β€” especially for new features introduced in hard forksβ€”are defined in Python within EEST. While the existing test cases remain important for client testing, porting ethereum/tests to EEST will help maintain and generate tests for newer forks. This also ensures feature parity, as client teams will only need to obtain test fixture releases from one source.

+

While automating the conversion of the remaining YAML (or JSON) test cases to Python is possible, manually porting individual test cases offers several benefits:

+
    +
  • Reducing the number of test cases by combining multiple YAML (or JSON) cases into a single Python test function using parametrization.
  • +
  • Potentially improving coverage by parametrizing the Python version.
  • +
  • Producing higher quality code and documentation, which are typically clearer than an automated conversion.
  • +
  • Ensuring better organization of tests within the ./tests folder of execution-spec-tests by fork and EIP.
  • +
+

Porting an original test

+
    +
  1. +

    Select one or more test cases from ./tests/static/state_tests/ to port and create an issue in this repository AND comment on this tracker issue.

    +
  2. +
  3. +

    Add a new test in the appropriate fork folder, following the guidelines for choosing a test type.

    +
  4. +
  5. +

    Submit a PR with the ported tests:

    +
      +
    1. +

      Add the list of ported files using python marker to the head of your python test.

      +

      Example:

      +
       @pytest.mark.ported_from(
      +[
      +    "https://github.com/ethereum/tests/blob/v13.3/src/GeneralStateTestsFiller/stCreateTest/CREATE_ContractSuicideDuringInit_ThenStoreThenReturnFiller.json",
      +    "https://github.com/ethereum/tests/blob/v13.3/src/GeneralStateTestsFiller/stCreateTest/CREATE_ContractSuicideDuringInit_WithValueFiller.json",
      +],
      +pr=["https://github.com/ethereum/execution-spec-tests/pull/1871"],
      +# coverage_missed_reason="Converting solidity code result in following opcode not being used:",
      +

      Replace test names with your chosen tests and PR number.

      +

      Uncomment coverage_missed_reason when all the missed coverage lines are approved, usually some opcodes end up not used after translating test logic from lllc, yul.

      +

      But sometimes missed coverage line could hint that you forgot to account important test logic.

      +

      If no coverage is missed, you are good!

      +
    2. +
    3. +

      Remove the ported files from .tests/static/state_tests in your PR

      +
    4. +
    +
  6. +
+
+

See also: πŸ“„ Getting started with EEST.

+

Filling tests

+

EEST uses pytest to run tests against EELS (an EVM implementation for testing). This process is known as “filling” and verifies the assertions in your tests. You can use the fill CLI for this. For example, see how to fill the PUSH opcode.

+
uv run fill tests/frontier/opcodes/test_push.py
+

See also: πŸ“„ Documentation for the fill command.

+
+

If the tests can’t currently be filled, please explain the issue (feel free to also open a Discussion).

+

Debugging tests

+

By default, EVM logs are stored in the logs folder at the repository root. You can check the output folder to review transaction results. If needed, review a previous PR that ported tests (e.g., the PR porting the PUSH opcode, and other port PRs).

+

Test coverage

+

It’s crucial that ported tests maintain coverage parity with original tests. This ensures that no critical functions are left untested and prevents the introduction of bugs. A CI workflow automatically checks for coverage.

+

If coverage action fails (See: πŸ“„ An example of a failing test coverage), it’s recommended to run the coverage action locally (see: πŸ“„ How to run GitHub actions locally), which should generate a evmtest_coverage directory:

+
❯ tree evmtest_coverage  -L 2
+evmtest_coverage
+└── coverage
+    β”œβ”€β”€ BASE
+    β”œβ”€β”€ BASE_TESTS
+    β”œβ”€β”€ coverage_BASE.lcov
+    β”œβ”€β”€ coverage_PATCH.lcov
+    β”œβ”€β”€ DIFF
+    β”œβ”€β”€ difflog.txt
+    β”œβ”€β”€ PATCH
+    └── PATCH_TESTS
+

Here BASEis original tests, PATCH is the ported test, and DIFF is the coverage difference on EVMONE. Open evmtest_coverage/coverage/DIFF/index.html in browser:

+

Annotated coverage

+ + + + + + + + + + + + + + + + + + + + + + + + + +
LabelDescription
LBCLost base coverage: Code that was tested before, but is untested now.
UBCUncovered baseline code: Code that was untested before and untested now.
GBCGained baseline coverage: Code that was untested before, but is tested now.
CBCCovered baseline code: Code that was tested before and is tested now.
+

Follow the hyperlinks for lost base coverage (LBC) to address coverage gaps. Here is an example coverage loss:

+

Missing original coverage

+
+

Lost line coverage from a coverage report. In this case, caused by a missing invocation of CALLDATALOAD.

+ + +
+
Expected coverage loss
+
+

EEST uses pytest, a popular Python testing framework, to help orchestrate testing Ethereum specifications, while original tests relied on large, static contracts and the EVM to handle much of the execution. This difference can lead to coverage gaps. EEST favors dynamic contract creation for each test vector, while original tests preferred a single static contract with multiple test vectors determined by transaction input data.

+

It’s important to note that coverage helps identify missing test paths. If you believe the coverage loss is due to differences in “setup” code between frameworks and doesn’t impact the feature you’re testing, explain this in your PR. A team member can help with the review.

+

For example, review the discussion in this PR to see an example of why and how coverage loss can occur.

+ +
+
+

Resolving Coverage Gaps from Yul Compilation

+

When porting tests from ethereum/tests, you may encounter coverage gaps that are false positives. This commonly occurs because:

+
    +
  • Original tests often used Yul to define smart contracts, and solc compilation introduces additional opcodes that aren’t specifically under test
  • +
  • EEST ports use the explicit EEST Opcode mini-language, which is more precise in opcode definition
  • +
+

If coverage analysis shows missing opcodes that were only present due to Yul compilation artifacts (not the actual feature being tested), this can be resolved during PR review by adding the coverage_missed_reason parameter:

+
@pytest.mark.ported_from(
+    ["path/to/original_test.json"],
+    coverage_missed_reason="Missing opcodes are Yul compilation artifacts, not part of tested feature"
+)
+
+ +
+
Add coverage_missed_reason only after PR review
+
+ Only add coverage_missed_reason after PR review determines the coverage gap is acceptable, never preemptively. This helps maintain test coverage integrity while accounting for legitimate differences between Yul-based and EEST opcode-based implementations. +
+
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/writing_tests/post_mortems/index.html b/docs/public/main/writing_tests/post_mortems/index.html new file mode 100644 index 00000000000..da8a206943f --- /dev/null +++ b/docs/public/main/writing_tests/post_mortems/index.html @@ -0,0 +1,1406 @@ + + + + + + + Post-Mortems - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

Post-Mortems

+
+ +
+

This page contains a collection of post-mortem analyses for test cases that were not initially identified by the testing process.

+

The objective is to document and learn from missed scenarios β€” including those that were caught on the client side due to consensus issue, client developer raised issues, external reviewers, or external bug bounties β€” in order to improve test coverage and reduce the likelihood of similar omissions in the future.

+

Each entry must include an explanation of why the test case was missed plus the changes that were implemented in documentation or framework to improve the testing process.

+

List

+

TEMPLATE

+

Date - Title - Fork

+

Description

+

Provide a concise summary of the issue, how it was discovered, emphasizing the how it relates to the specifications and testing.

+

Example:

+
+

A consensus-breaking issue was found during the bug-bounty phase of the Pectra fork specifically in the EIP-2537, which involved calling the BLS pairing precompile using two special points: the infinity point and a point that is outside of the BLS12-381 curve. +The specification correctly specified the behavior of the precompile when one of these inputs was used, but it did not specify the behavior of the combined input.

+

Root Cause Analysis

+

Explain why this scenario was not covered by the test suite. Consider whether it was due to ambiguous specification wording, gaps in test generation logic, overlooked edge cases, or incorrect assumptions about expected behavior.

+

Consider prompting questions:

+
    +
  • Was the behavior implied but not explicitly stated in the specification?
  • +
  • Was the area considered low-risk or assumed covered elsewhere?
  • +
  • Were there limitations in the current test generation tools or processes?
  • +
  • Was there any different type of testing that could have caught the issue at an earlier stage? (Fuzzing, property based testing)
  • +
+

Steps Taken To Avoid Recurrence

+

List the actions taken to reduce the chance of this type of miss happening again. E.g. procedure changes, checklist updates, review practices, framework improvements.

+

Implemented Test Case

+

IDs of the tests added that now cover the missed scenario and link to the documentation page where they are included.

+

Example:

+ +

Framework/Documentation Changes

+

Note any modifications that were introduced in the framework and/or documentation to prevent similar misses.

+

Example:

+
    +
  • Updated EIP checklist to include testing combinations of interesting points related to the elliptic-curve under test, and all combinations between them.
  • +
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/writing_tests/reference_specification/index.html b/docs/public/main/writing_tests/reference_specification/index.html new file mode 100644 index 00000000000..c641c549e3e --- /dev/null +++ b/docs/public/main/writing_tests/reference_specification/index.html @@ -0,0 +1,1491 @@ + + + + + + + Referencing an EIP Spec Version - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

Referencing an EIP Spec Version

+
+ +
+

Tests that implement features from an Ethereum Improvement Proposal (ethereum/EIPs) must define the EIP’s markdown SHA digest within the test’s Python module. This ensures our tests stay up-to-date with any changes to the EIP specifications.

+

The check_eip_versions command-line utility automatically verifies that all EIP references in the codebase are current. It works by comparing the SHA specified in the test against the latest version in the ethereum/EIPs repository. This utility uses pytest to generate test cases for every module that includes “eip” in its path.

+

Test framework summary for a failing EIP spec version test

+ + +
+
The SHA digest value is provided in the failure message of the corresponding test
+
+ EIP spec version test fail +
+
+ + +
+
Understanding and Retrieving the EIP Markdown’s SHA Digest
+
+

The SHA value is the output from git’s hash-object command, for example:

+
git clone git@github.com:ethereum/EIPs
+git hash-object EIPS/EIPS/eip-3651.md
+# output: d94c694c6f12291bb6626669c3e8587eef3adff1
+

and can be retrieved from the remote repo via the Github API on the command-line as following:

+
sudo apt install jq
+curl -s -H "Accept: application/vnd.github.v3+json" \
+https://api.github.com/repos/ethereum/EIPs/contents/EIPS/eip-3651.md |\
+jq -r '.sha'
+# output: d94c694c6f12291bb6626669c3e8587eef3adff1
+
+
+
+

How to Add a Spec Version Check

+

This check accomplished by adding the following two global variables anywhere in the Python source file:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Variable NameExplanation
REFERENCE_SPEC_GIT_PATHThe relative path of the EIP markdown file in the ethereum/EIPs repository, e.g. “EIPS/eip-1234.md
REFERENCE_SPEC_VERSIONThe SHA hash of the latest version of the file retrieved from the Github API: https://api.github.com/repos/ethereum/EIPs/contents/EIPS/eip-<EIP Number>.md
+ + +

Running the check_eip_versions Command Locally

+

A Github Personal Access Token (PAT) is required to avoid rate-limiting issues when using the Github API. The token can be specified via an environment variable or via the command-line. For example, the Github CLI can be used to obtain a token:

+
uv run check_eip_versions --github-token=$(gh auth token)
+

or a PAT can be created at: https://github.com/settings/personal-access-tokens/new.

+

By default, only tests up to and including the current fork under development will be checked. This is controlled by the UNTIL_FORK setting in the src/config/check_eip_versions.py configuration file. You can also pass a specific test path to limit the scope:

+
uv run check_eip_versions --github-token=$(gh auth token) tests/shanghai/eip3651_warm_coinbase/
+

This would only check EIP versions for the EIP-3651 tests in the shanghai/eip3651_warm_coinbase sub-directory.

+

Automated Checks via GitHub Actions

+

The repository includes a GitHub Actions workflow that automatically runs check_eip_versions on a daily schedule. If any outdated EIP references are detected, the workflow creates an issue in the repository with details about which references need to be updated.

+

This workflow uses GitHub’s built-in token for authentication, so there’s no need to configure personal access tokens for the automated checks. The issue will include links to the relevant workflow run and details about which tests need updating.

+

Example

+

Here is an example from ./tests/shanghai/eip3651_warm_coinbase/test_warm_coinbase.py:

+
REFERENCE_SPEC_GIT_PATH = "EIPS/eip-3651.md"
+REFERENCE_SPEC_VERSION = "d94c694c6f12291bb6626669c3e8587eef3adff1"
+

While the code uses variable names the shown constants can be found in spec.py. The SHA digest was retrieved from here.

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/writing_tests/test_markers/index.html b/docs/public/main/writing_tests/test_markers/index.html new file mode 100644 index 00000000000..a92a522df82 --- /dev/null +++ b/docs/public/main/writing_tests/test_markers/index.html @@ -0,0 +1,1715 @@ + + + + + + + Test Markers - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

Test Markers

+
+ +
+

Test markers are used to categorize tests and to run specific subsets of tests. They are defined in the test files using the pytest.mark decorator.

+

The examples below use StateTestFiller tests, but the same markers can also be applied to BlockchainTestFiller tests.

+

Fork Markers

+

These markers are used to specify the forks for which a test is valid.

+

@pytest.mark.valid_from("FORK_NAME")

+

Bases: ValidityMarker

+

Marker used to specify the fork from which the test is valid. The test will not be filled for forks before the specified fork.

+
import pytest
+
+from ethereum_test_tools import Alloc, StateTestFiller
+
+@pytest.mark.valid_from("London")
+def test_something_only_valid_after_london(
+    state_test: StateTestFiller,
+    pre: Alloc
+):
+    pass
+

In this example, the test will only be filled for the London fork and after, e.g. London, Paris, Shanghai, Cancun, etc.

+
+
+ +

@pytest.mark.valid_until("FORK_NAME")

+

Bases: ValidityMarker

+

Marker to specify the fork until which the test is valid. The test will not be filled for forks after the specified fork.

+
import pytest
+
+from ethereum_test_tools import Alloc, StateTestFiller
+
+@pytest.mark.valid_until("London")
+def test_something_only_valid_until_london(
+    state_test: StateTestFiller,
+    pre: Alloc
+):
+    pass
+

In this example, the test will only be filled for the London fork and before, e.g. London, Berlin, Istanbul, etc.

+
+
+ +

@pytest.mark.valid_at("FORK_NAME_1", "FORK_NAME_2", ...)

+

Bases: ValidityMarker

+

Marker to specify each fork individually for which the test is valid.

+
import pytest
+
+from ethereum_test_tools import Alloc, StateTestFiller
+
+@pytest.mark.valid_at("London", "Cancun")
+def test_something_only_valid_at_london_and_cancun(
+    state_test: StateTestFiller,
+    pre: Alloc
+):
+    pass
+

In this example, the test will only be filled for the London and Cancun forks.

+
+
+ +

@pytest.mark.valid_at_transition_to("FORK_NAME")

+

Bases: ValidityMarker

+

Marker to specify that a test is only meant to be filled at the transition to the specified fork.

+

The test usually starts at the fork prior to the specified fork at genesis and at block 5 (for pre-merge forks) or at timestamp 15,000 (for post-merge forks) the fork transition occurs.

+
import pytest
+
+from ethereum_test_tools import Alloc, BlockchainTestFiller
+
+@pytest.mark.valid_at_transition_to("London")
+def test_something_that_happens_during_the_fork_transition_to_london(
+    blockchain_test: BlockchainTestFiller,
+    pre: Alloc
+):
+    pass
+

In this example, the test will only be filled for the fork that transitions to London at block number 5, BerlinToLondonAt5, and no other forks.

+

To see or add a new transition fork, see the ethereum_test_forks.forks.transition module.

+

Note that the test uses a BlockchainTestFiller fixture instead of a StateTestFiller, as the transition forks are used to test changes throughout the blockchain progression, and not just the state change of a single transaction.

+

This marker also accepts the following keyword arguments:

+
    +
  • subsequent_transitions: Force the test to also fill for subsequent fork transitions.
  • +
  • until: Implies subsequent_transitions and puts a limit on which transition fork will the test filling will be limited to.
  • +
+

For example:

+
@pytest.mark.valid_at_transition_to("Cancun", subsequent_transitions=True)
+

produces tests on ShanghaiToCancunAtTime15k and CancunToPragueAtTime15k, and any transition fork after that. +And:

+
@pytest.mark.valid_at_transition_to("Cancun", subsequent_transitions=True, until="Prague")
+

produces tests on ShanghaiToCancunAtTime15k and CancunToPragueAtTime15k, but no forks after Prague.

+ +

Fork Covariant Markers

+

These markers are used in conjunction with the fork validity markers to automatically parameterize tests with values that are valid for the fork being tested.

+

@pytest.mark.with_all_tx_types

+

This marker is used to automatically parameterize a test with all transaction types that are valid for the fork being tested.

+
import pytest
+
+from ethereum_test_tools import Alloc, StateTestFiller
+
+@pytest.mark.with_all_tx_types
+@pytest.mark.valid_from("Berlin")
+def test_something_with_all_tx_types(
+    state_test: StateTestFiller, 
+    pre: Alloc,
+    tx_type: int
+):
+    pass
+

In this example, the test will be parameterized for parameter tx_type with values [0, 1] for fork Berlin, but with values [0, 1, 2] for fork London (because of EIP-1559).

+
+
+ +

@pytest.mark.with_all_contract_creating_tx_types

+

This marker is used to automatically parameterize a test with all contract creating transaction types that are valid for the fork being tested.

+

This marker only differs from pytest.mark.with_all_tx_types in that it does not include transaction type 3 (Blob Transaction type) on fork Cancun and after.

+
+
+ +

@pytest.mark.with_all_precompiles

+

This marker is used to automatically parameterize a test with all precompiles that are valid for the fork being tested.

+
import pytest
+
+from ethereum_test_tools import Alloc, StateTestFiller
+
+@pytest.mark.with_all_precompiles
+@pytest.mark.valid_from("Shanghai")
+def test_something_with_all_precompiles(
+    state_test: StateTestFiller, 
+    pre: Alloc,
+    precompile: int,
+):
+    pass
+

In this example, the test will be parameterized for parameter precompile with values [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] for fork Shanghai, but with values [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10] for fork Cancun which introduced the point evaluation precompile defined in EIP-4844.

+
+
+ +

@pytest.mark.with_all_evm_code_types

+

This marker is used to automatically parameterize a test with all EVM code types that are valid for the fork being tested.

+
import pytest
+
+from ethereum_test_tools import Alloc, StateTestFiller
+
+@pytest.mark.with_all_evm_code_types
+@pytest.mark.valid_from("Frontier")
+def test_something_with_all_evm_code_types(
+    state_test: StateTestFiller,     
+    pre: Alloc,
+):
+    pass
+

In this example, the test will be parameterized for parameter evm_code_type only with value [EVMCodeType.LEGACY] starting on fork Frontier, and eventually it will be parametrized with with values [EVMCodeType.LEGACY, EVMCodeType.EOF_V1] on the EOF activation fork.

+

In all calls to pre.deploy_contract, if the code parameter is Bytecode type, and evm_code_type==EVMCodeType.EOF_V1, the bytecode will be automatically wrapped in an EOF V1 container.

+

Code wrapping might fail in the following circumstances:

+
    +
  • The code contains invalid EOF V1 opcodes.
  • +
  • The code does not end with a valid EOF V1 terminating opcode (such as Op.STOP or Op.REVERT or Op.RETURN).
  • +
+

In the case where the code wrapping fails, evm_code_type can be added as a parameter to the test and the bytecode can be dynamically modified to be compatible with the EOF V1 container.

+

One thing to note is that evm_code_type is not necessary to be added as a parameter to the test because the pre: Alloc fixture automatically consumes this fixture, and therefore it only needs to be added to the test signature if the test’s logic needs it.

+
import pytest
+
+from ethereum_test_tools import Alloc, StateTestFiller
+from ethereum_test_vm import EVMCodeType
+from ethereum_test_vm import Opcodes as Op
+
+@pytest.mark.with_all_evm_code_types
+@pytest.mark.valid_from("Frontier")
+def test_something_with_all_evm_code_types(
+    state_test: StateTestFiller,
+    pre: Alloc,
+    evm_code_type: EVMCodeType
+):
+    code = Op.SSTORE(1, 1)
+    if evm_code_type == EVMCodeType.EOF_V1:
+        # Modify the bytecode to be compatible with EOF V1 container
+        code += Op.STOP
+    pre.deploy_contract(code)
+    ...
+

+
+ +

@pytest.mark.with_all_call_opcodes

+

This marker is used to automatically parameterize a test with all EVM call opcodes that are valid for the fork being tested.

+
import pytest
+
+from ethereum_test_tools import Alloc, StateTestFiller
+from ethereum_test_vm import Opcodes as Op
+
+@pytest.mark.with_all_call_opcodes
+@pytest.mark.valid_from("Frontier")
+def test_something_with_all_call_opcodes(
+    state_test: StateTestFiller,
+    pre: Alloc,
+    call_opcode: Op
+):
+    pass
+

In this example, the test will be parametrized for parameter call_opcode with values [Op.CALL, Op.CALLCODE] starting on fork Frontier, [Op.CALL, Op.CALLCODE, Op.DELEGATECALL] on fork Homestead, [Op.CALL, Op.CALLCODE, Op.DELEGATECALL, Op.STATICCALL] on fork Byzantium, and eventually it will be parametrized with with values [Op.CALL, Op.CALLCODE, Op.DELEGATECALL, Op.STATICCALL, Op.EXTCALL, Op.EXTSTATICCALL, Op.EXTDELEGATECALL] on the EOF activation fork.

+

Parameter evm_code_type will also be parametrized with the correct EVM code type for the opcode under test.

+
+
+ +

@pytest.mark.with_all_create_opcodes

+

This marker is used to automatically parameterize a test with all EVM create opcodes that are valid for the fork being tested.

+
import pytest
+
+from ethereum_test_tools import Alloc, StateTestFiller
+from ethereum_test_vm import Opcodes as Op
+
+@pytest.mark.with_all_create_opcodes
+@pytest.mark.valid_from("Frontier")
+def test_something_with_all_create_opcodes(
+    state_test: StateTestFiller,
+    pre: Alloc,
+    create_opcode: Op
+):
+    pass
+

In this example, the test will be parametrized for parameter create_opcode with values [Op.CREATE] starting on fork Frontier, [Op.CREATE, Op.CREATE2] starting on fork Constantinople, and eventually it will be parametrized with with values [Op.CREATE, Op.CREATE2, Op.EOFCREATE] on the EOF activation fork.

+

Parameter evm_code_type will also be parametrized with the correct EVM code type for the opcode under test.

+
+
+ +

@pytest.mark.with_all_system_contracts

+

This marker is used to automatically parameterize a test with all system contracts that are valid for the fork being tested.

+
import pytest
+
+from ethereum_test_tools import Alloc, StateTestFiller
+from ethereum_test_base_types import Address
+
+@pytest.mark.with_all_system_contracts
+@pytest.mark.valid_from("Cancun")
+def test_something_with_all_system_contracts(
+    state_test: StateTestFiller,
+    pre: Alloc,
+    system_contract: Address,
+):
+    pass
+

In this example, the test will be parameterized for parameter system_contract with value [0x000F3DF6D732807EF1319FB7B8BB8522D0BEAC02] for fork Cancun.

+
+
+ +

Covariant Marker Keyword Arguments

+

All fork covariant markers accept the following keyword arguments:

+

selector

+

A lambda function that can be used to filter the fork covariant values that are valid for this specific test.

+
import pytest
+
+from ethereum_test_tools import Alloc, StateTestFiller
+
+@pytest.mark.with_all_tx_types(selector=lambda tx_type: tx_type != 2)
+@pytest.mark.valid_from("London")
+def test_something_with_all_tx_types(
+    state_test: StateTestFiller, 
+    pre: Alloc,
+    tx_type: int
+):
+    pass
+

Ideally, the lambda function should be used to explicitly filter out values that are not compatible with the test (exclusive filter), rather than explicitly selecting values (inclusive filter), as the parametrized values might change with future forks.

+

marks

+

A marker, list of markers, or a lambda function that can be used to add additional markers to the test.

+
import pytest
+
+@pytest.mark.with_all_tx_types(
+    marks=lambda tx_type: pytest.mark.skip("incompatible") if tx_type == 1 else None,
+)
+@pytest.mark.valid_from("London")
+def test_something_with_all_tx_types_but_skip_type_1(state_test_only, tx_type):
+    assert tx_type != 1
+    ...
+

In this example, the test will be skipped if tx_type is equal to 1 by returning a pytest.mark.skip marker, and return None otherwise.

+

@pytest.mark.parametrize_by_fork

+

A test can be dynamically parametrized based on the fork using the parametrize_by_fork marker.

+

This marker takes two positional arguments:

+
    +
  • argnames: A list of parameter names that will be parametrized using the custom function.
  • +
  • fn: A function that takes the fork as parameter and returns a list of values that will be used to parametrize the test at that specific fork.
  • +
+

And one keyword argument:

+
    +
  • marks (optional): A marker, list of markers, or a lambda function that can be used to add additional markers to the generated tests.
  • +
+

The marked test function will be parametrized by the values returned by the fn function for each fork.

+

If the parameters that are being parametrized is only a single parameter, the return value of fn should be a list of values for that parameter.

+

If the parameters that are being parametrized are multiple, the return value of fn should be a list of tuples/lists, where each tuple contains the values for each parameter.

+
import pytest
+
+def covariant_function(fork):
+    return [[1, 2], [3, 4]] if fork.name() == "Paris" else [[4, 5], [5, 6], [6, 7]]
+
+@pytest.mark.parametrize_by_fork("test_parameter,test_parameter_2", covariant_function)
+@pytest.mark.valid_from("Paris")
+@pytest.mark.valid_until("Shanghai")
+def test_case(state_test_only, test_parameter, test_parameter_2):
+    pass
+

In this example, the test will be parametrized with the values [1, 2] and [3, 4] for the Paris fork, with values 1 and 3 being assigned to test_parameter and 2 and 4 being assigned to test_parameter_2. For the Shanghai fork, the test will be parametrized with the values [4, 5], [5, 6], and [6, 7]. Therefore, more test cases will be generated for the Shanghai fork.

+

If the parameters that are being parametrized is only a single parameter, the return value of fn should be a list of values for that parameter.

+

If the parameters that are being parametrized are multiple, the return value of fn should be a list of tuples/lists, where each tuple contains the values for each parameter.

+

The function can also return a list of pytest.param objects, which allows for additional markers and test IDs to be added to the test.

+

Fill/Execute Markers

+

These markers are used to apply different markers to a test depending on whether it is being filled or executed.

+

@pytest.mark.fill

+

This marker is used to apply markers to a test when it is being filled.

+
import pytest
+
+from ethereum_test_tools import Alloc, StateTestFiller
+
+@pytest.mark.fill(pytest.mark.skip(reason="Only for execution"))
+def test_something(
+    state_test: StateTestFiller, 
+    pre: Alloc
+):
+    pass
+

In this example, the test will be skipped when it is being filled.

+

@pytest.mark.execute

+

This marker is used to apply markers to a test when it is being executed.

+
import pytest
+
+from ethereum_test_tools import Alloc, StateTestFiller
+
+@pytest.mark.execute(pytest.mark.xfail(reason="Depends on block context"))
+def test_something(
+    state_test: StateTestFiller, 
+    pre: Alloc
+):
+    pass
+

In this example, the test will be marked as expected to fail when it is being executed, which is particularly useful so that the test is still executed but does not fail the test run.

+

Other Markers

+

@pytest.mark.slow

+

This marker is used to mark tests that are slow to run. These tests are not run during tox checks, and are only run when a release is being prepared.

+

@pytest.mark.pre_alloc_modify

+

This marker is used to mark tests that modify the pre-alloc in a way that would be impractical to reproduce in a real-world scenario.

+

Examples of this include:

+
    +
  • Modifying the pre-alloc to have a balance of 2^256 - 1.
  • +
  • Address collisions that would require hash collisions.
  • +
+

@pytest.mark.skip()

+

This marker can be used to skip a test.

+
import pytest
+
+from ethereum_test_tools import Alloc, StateTestFiller
+
+@pytest.mark.skip(reason="Not implemented")
+def test_something(state_test: StateTestFiller, pre: Alloc):
+    pass
+

@pytest.mark.xfail()

+

This marker can be used to mark a test as expected to fail.

+
import pytest
+
+from ethereum_test_tools import Alloc, StateTestFiller
+
+@pytest.mark.xfail(reason="EVM binary doesn't support this opcode")
+def test_something(state_test: StateTestFiller, pre: Alloc):
+    pass
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/writing_tests/tutorials/blockchain/index.html b/docs/public/main/writing_tests/tutorials/blockchain/index.html new file mode 100644 index 00000000000..4db4a1e3435 --- /dev/null +++ b/docs/public/main/writing_tests/tutorials/blockchain/index.html @@ -0,0 +1,1309 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

+
+ +
+

Blockchain Tests

+

This tutorial teaches you to create a blockchain execution specification test. These tests verify that a blockchain, starting from a defined pre-state, will process given blocks and arrive at a defined post-state.

+

Pre-requisites

+

Before proceeding with this tutorial, it is assumed that you have prior knowledge and experience with the following:

+ +

Example Tests

+

In this tutorial we will go over [test_block_number] in test_block_example.py.

+

It is assumed you have already gone through the state transition test tutorial. Only new concepts will be discussed.

+

Smart Contract

+

A smart contract is defined that is called by each transaction in the test. It stores a pointer to storage at storage[0]. When it is called storage cell 0 gets the current block number, and the pointer is incremented to the next value.

+
contract_addr: Account(
+    balance=1000000000000000000000,
+    code=code,
+    storage={
+        0x00: 0x01,
+    },
+),
+

Transaction Generator

+

The transactions used in this test are nearly identical. Their only difference is the nonce value which needs to be incremented.

+
def tx_generator():
+    nonce = 0  # Initial value
+    while True:
+        tx = Transaction(
+            ty=0x0,
+            chain_id=0x0,
+            nonce=nonce,
+            to=contractAddr,
+            gas_limit=500000,
+            gas_price=10,
+        )
+        nonce = nonce + 1
+        yield tx
+
+tx_generator = tx_generator()
+

This looks like an infinite loop but it isn’t because this is a generator function. When generator encounters the yield keyword it returns the value and stops execution, keeping a copy of all the local variables, until it is called again. Hence infinite loops inside a generator are not a problem as long as they include yield. This code section is responsible for creating the Transaction object and incrementing the nonce.

+

Every time the function tx_generator() is called, it returns a new generator with a nonce of zero. To increment the nonce we need to use the same generator. We assign this generator to tx_generator.

+

Blocks

+

Each integer in the tx_per_block array is the number of transactions in a block. The genesis block is block 0 (no transactions). It follows that we have 2 transactions in block 1, 0 in block two, 4 in block 3, …, and 50 in block 9.

+
tx_per_block = [2, 0, 4, 8, 0, 0, 20, 1, 50]
+

The code section that creates the blocks is a bit complex in this test. For some simpler definitions of Block creation you can browse tests within test_withdrawals.py.

+
blocks = map(
+    lambda len: Block(
+        txs=list(map(lambda x: next(tx_generator), range(len)))
+    ),
+    tx_per_block,
+)
+

We use lambda notation to specify short functions. In this case, the function doesn’t actually care about its input, it just returns the next transaction from the generator.

+
lambda x: next(tx_generator)
+

Python uses range(n) to create a list of numbers from 0 to n-1. Among other things, it’s a simple way to create a list of n values.

+
range(len)
+

The map function runs the function (the first parameter) on every element of the list (the second parameter). Putting together what we know, it means that it runs next(tx_generator) len times, giving us len transactions. We then use list to turn the transactions into a list that we can provide as the txs parameter to the Block constructor.

+
list(map(lambda x: next(tx_generator), range(len)))
+

The outer lambda function takes an integer, len, and creates a Block object with len transactions. This function is then run on every value of tx_per_block to generate the blocks.

+
blocks = map(
+    lambda len: Block(
+        txs=list of len transactions
+    ),
+    tx_per_block,
+)
+

For example, if we had tx_per_block = [0,2,4], we’d get this result:

+
blocks = [
+    Blocks(txs=[]),
+    Blocks(txs=[next(tx_generator), next(tx_generator)]),
+    Blocks(txs=[next(tx_generator), next(tx_generator), next(tx_generator), next(tx_generator)])        
+]
+

Post State

+

Recall that storage slot 0 retains the value of the next slot that the block number is written into. It starts at one and is incremented after each transaction. Hence it’s the total number of transactions plus 1.

+
storage = {0: sum(tx_per_block) + 1}
+

For every block and transaction within the block, we write the block number and increment the next slot number in storage slot 0. As Python lists are 0 indexed, we must increment the block number by 1.

+
next_slot = 1
+for blocknum in range(len(tx_per_block)):
+    for _ in range(tx_per_block[blocknum]):
+        storage[next_slot] = blocknum + 1
+        next_slot = next_slot + 1
+

Now that the expected storage values are calculated, the post state can be defined and yielded within the BlockchainTest, synonymous to the state test example.

+
post = {contract_addr: Account(storage=storage)}
+
+yield BlockchainTest(
+    genesis_environment=env,
+    pre=pre,
+    blocks=blocks,
+    post=post,
+)
+

Note that because of the yield we could have multiple tests under the same name.

+

Conclusion

+

At this point you should be able to write blockchain tests.

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/writing_tests/tutorials/main/index.html b/docs/public/main/writing_tests/tutorials/main/index.html new file mode 100644 index 00000000000..0998953979e --- /dev/null +++ b/docs/public/main/writing_tests/tutorials/main/index.html @@ -0,0 +1,1219 @@ + + + + + + + Tutorials - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

Tutorials

+
+ +
+

Tutorials

+

Show overview of existing tutorials

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/writing_tests/tutorials/state_transition/index.html b/docs/public/main/writing_tests/tutorials/state_transition/index.html new file mode 100644 index 00000000000..4de809ae348 --- /dev/null +++ b/docs/public/main/writing_tests/tutorials/state_transition/index.html @@ -0,0 +1,1336 @@ + + + + + + + - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

+
+ +
+

State Transition Tests

+

This tutorial teaches you to create a state transition execution specification test using the Python Opcodes minilang for writing EVM bytecode. These tests verify that a starting pre-state will reach a specified post-state after executing a single transaction. In this example, we’ll create a simple contract using bytecode and then interact with it through a transaction to verify the expected state changes.

+

For an overview of different test types available, see Types of Tests.

+

Pre-requisites

+

This tutorial will require some prior knowledge and experience with the following:

+ +

Building a State Test

+

The most effective method of learning how to write tests is to study a straightforward example. In this tutorial we will build a simple state test that deploys a contract with bytecode and verifies its execution.

+

Complete Test Example

+

We’ll examine a simple test that uses the Python Opcodes minilang to write EVM bytecode. This example is based on the CHAINID opcode test from tests/istanbul/eip1344_chainid/test_chainid.py.

+

Let’s examine each section.

+
"""State test tutorial demonstrating contract deployment and interaction."""
+

In Python, multi-line strings are denoted using """. As a convention, a file’s purpose is often described in the opening string of the file.

+
import pytest
+
+from ethereum_test_tools import Account, Alloc, Environment, StateTestFiller, Transaction
+from ethereum_test_tools.vm.opcode import Opcodes as Op
+

In this snippet the required constants, types and helper functions are imported from ethereum_test_tools. The Opcodes class (aliased as Op) provides the Python minilang for writing EVM bytecode. We will go over these as we come across them.

+
@pytest.mark.valid_from("Istanbul")
+

In Python this kind of definition is called a decorator. +It modifies the action of the function after it. +In this case, the decorator is a custom pytest mark defined by the execution-specs-test framework that specifies that the test is valid for the Istanbul fork and all forks after it. The framework will then fill this test case for all forks in the fork range specified by the command-line arguments.

+

For more information about test markers and fork validity, see Test Markers.

+ + +
+
Filling the test
+
+

To fill this test for all the specified forks, we can specify pytest’s -k flag that filters test cases by keyword expression:

+
fill -k test_state_test_example
+

and to fill it for a specific fork range, we can provide the --from and --until command-line arguments:

+
fill -k test_state_test_example --from London --until Paris
+
+
+
+
def test_state_test_example(state_test: StateTestFiller, pre: Alloc):
+    """Test state transition using Opcodes minilang bytecode."""
+

This is the format of a Python function. +It starts with def <function name>(<parameters>):, and then has indented code for the function. +The function definition ends when there is a line that is no longer indented. As with files, by convention functions start with a string that explains what the function does.

+

The function parameters (state_test and pre) are pytest fixtures provided by the execution-spec-tests framework. Pytest fixtures are a powerful dependency injection mechanism that automatically provide objects to your test functions.

+

The state_test fixture is a callable that you must include in state test function arguments. When called at the end of your test function with the environment, pre-state, transaction, and expected post-state, it generates the actual test fixtures. This callable is a wrapper around the StateTest class.

+

The pre fixture provides an Alloc object that manages the pre-state allocation for your test. It offers methods like fund_eoa() and deploy_contract() that automatically generate unique addresses and add accounts to the blockchain state that will exist before your transaction executes. The fixture handles address generation and ensures no conflicts occur.

+
    env = Environment(number=1)
+

This line specifies that env is an [Environment][ethereum_test_types.Environment] object. In this example, we only override the block number to 1, leaving all other values at their defaults. It’s recommended to use default values whenever possible and only specify custom values when required for your specific test scenario. (For all available fields, see the pydantic model fields in the source code of [Environment][ethereum_test_types.Environment] and EnvironmentGeneric from which Environment inherits.)

+

Pre State

+

For every test we need to define the pre-state requirements, so we are certain of what is on the “blockchain” before the transaction is executed. The pre fixture provides an Alloc object with methods to create accounts that are automatically added to the pre-state.

+

In this example we are using the deploy_contract method to deploy a contract to some address available in the pre-state.

+
    contract_address = pre.deploy_contract(
+        code=Op.PUSH1(0x03) + Op.PUSH1(0x00) + Op.SSTORE + Op.STOP
+    )
+

Specifically we deploy a contract written with Opcodes minilang code that stores the value 0x03 at storage slot 0x00. The code consists of:

+
    +
  • PUSH1(0x03): Push the value 3 onto the stack.
  • +
  • PUSH1(0x00): Push the storage key 0 onto the stack.
  • +
  • SSTORE: Store the value at the specified key.
  • +
  • STOP: End execution.
  • +
+

As the return value of the deploy_contract method, we get the address where the contract was deployed. This address is stored in the contract_address variable, which will later be used as the target of our transaction.

+

You can also specify additional parameters for the contract if needed:

+
    +
  • balance parameter to set the contract’s initial balance (though often not necessary for state test contracts)
  • +
  • storage parameter to set initial storage values (though in this example we don’t need initial storage since our contract will set it through the SSTORE opcode)
  • +
+

You can combine opcodes using the + operator to create more complex bytecode sequences.

+

Generally for execution spec tests the SSTORE instruction acts as a high-level assertion method to check pre to post-state changes. The test filler achieves this by verifying that the correct value is held within post-state storage, hence we can validate that the bytecode has run successfully.

+

Next, we need to create an account that will send the transaction to our contract:

+
    sender = pre.fund_eoa()
+

This line creates a single externally owned account (EOA) with a default balance. You can specify a custom amount with amount=0x0BA1A9CE0BA1A9CE if needed.

+

The returned object, which includes a private key, an address, and a nonce, is stored in the sender variable and will later be used as the sender of the transaction.

+

Transactions

+
    tx = Transaction(
+        ty=0x2,
+        sender=sender,
+        to=contract_address,
+        gas_limit=100_000,
+    )
+

With the pre-state built, we can now create the transaction that will call our contract. Let’s examine the key components of this [Transaction][ethereum_test_types.Transaction] (for all available fields, see the source code of [Transaction][ethereum_test_types.Transaction] and TransactionGeneric from which Transaction inherits).

+
    +
  • +

    sender=sender: We use the EOA we created earlier, which already has the necessary information to sign the transaction and contains the correct nonce. The nonce is a protection mechanism to prevent replay attacks - it must equal the number of transactions sent from the sender’s address, starting from zero. The framework automatically manages nonce incrementing for us.

    +
  • +
  • +

    to=contract_address: This specifies the address of the contract we want to call, which is the contract we deployed earlier.

    +
  • +
  • +

    gas_limit=100_000: This sets a high enough gas limit to ensure our simple contract execution doesn’t run out of gas.

    +
  • +
  • +

    ty=0x2: This specifies the transaction type (EIP-1559).

    +
  • +
+

Post State

+

Now we need to define what we expect the blockchain state to look like after our transaction executes:

+
    post = {
+        contract_address: Account(
+            storage={
+                0x00: 0x03,
+            },
+        ),
+    }
+

This is the post-state which is equivalent to expect in static tests, but without the indexes. It is similar to the pre-state, except that we do not need to specify everything, only those accounts and fields we wish to test.

+

In this case, we look at the storage of the contract we called and add to it what we expect to see. In this example storage cell 0x00 should be 0x03 as we stored this value using the SSTORE opcode in our contract bytecode.

+

Running the State Test

+

Finally, we execute the test by calling the state test wrapper with all our defined components:

+
    state_test(env=env, pre=pre, post=post, tx=tx)
+

This line calls the wrapper to the StateTest object that provides all the objects required in order to fill the test, generate the test fixtures and write them to file (by default, ./fixtures/<blockchain,state>_tests/example/state_test_example/test_state_test_example.json).

+

Note that even though we defined a StateTest, the fill command will also generate other derivative test fixtures: BlockchainTest, BlockchainTestEngine, and BlockchainTestEngineX. For more information about test types and when to use each, see Test Types: Prefer StateTest for Single Transactions.

+

Conclusion

+

At this point you should be able to write state transition tests within a single block.

+

Next Steps

+
    +
  • Learn about Adding a New Test to understand test organization and structure.
  • +
  • Explore Fork Methods for writing tests that adapt to different Ethereum forks.
  • +
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/writing_tests/types_of_tests/index.html b/docs/public/main/writing_tests/types_of_tests/index.html new file mode 100644 index 00000000000..9f7d91eb74b --- /dev/null +++ b/docs/public/main/writing_tests/types_of_tests/index.html @@ -0,0 +1,1437 @@ + + + + + + + Types of Test - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

Types of Test

+
+ +
+

There are currently three types of tests that can be produced by a test spec:

+
    +
  1. State Tests
  2. +
  3. Blockchain Tests
  4. +
  5. Transaction Tests
  6. +
+

State Tests

+

Purpose

+

Tests the effects of individual transactions (ideally a single one) that span a single block in a controlled environment.

+

Use cases

+
    +
  • Test a single opcode behavior.
  • +
  • Verify opcode gas costs.
  • +
  • Test interactions between multiple smart contracts.
  • +
  • Test creation of smart contracts.
  • +
+ + +
+
Info
+
+ The fill function will automatically generate a blockchain_test fixture from state_tests, consisting of one block and one transaction. +
+
+

Blockchain Tests

+

Purpose

+

Blockchain tests span multiple blocks which may or may not contain transactions and mainly focus on the block to block effects to the Ethereum state.

+

Use cases

+
    +
  • Verify system-level operations such as coinbase balance updates or withdrawals.
  • +
  • Verify fork transitions.
  • +
  • Verify blocks with invalid transactions/properties are rejected.
  • +
+

Fork Transition Tests

+

There is a special type of blockchain test that is used to test a fork transition. It’s not executed for all possible forks, rather it targets exactly the blocks at the point of transition from one evm implementation to the next. This type of test must be marked with the valid_at_transition_to marker, for example:

+
@pytest.mark.valid_at_transition_to("Cancun")
+def test_blob_type_tx_pre_fork(
+    blockchain_test: BlockchainTestFiller,
+    pre: Dict,
+    env: Environment,
+    blocks: List[Block],
+):
+    """
+    Reject blocks with blobs before blobs fork
+    """
+

Transaction Tests

+

Purpose

+

Test correct transaction rejection/acceptance of a serialized transaction (currently RLP only).

+

Use cases

+
    +
  • Verify that a badly formatted transaction is correctly rejected by the client.
  • +
  • Verify that a transaction with an invalid value in one of its fields is correctly rejected by the client.
  • +
+ + +
+
Note
+
+ Using the execute command, transaction tests can be sent to clients in a live network using the eth_sendRawTransaction endpoint. +
+
+

Deciding on a test type

+

Prefer state_test for single transactions

+

Whenever possible, use state_test to examine individual transactions. This method is more straightforward and less prone to external influences that can occur during block building.

+

This provides more targeted testing since it does not invoke the client’s block-building machinery. This reduces the risk of encountering false positives, particularly in exception scenarios (e.g., see issue #343: “Zero max_fee_per_blob_gas test is ineffective”).

+

Moreover, the fill command automatically additionally generates a blockchain_test for every state_test by wrapping the state_test’s transaction in a block.

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/writing_tests/verifying_changes/index.html b/docs/public/main/writing_tests/verifying_changes/index.html new file mode 100644 index 00000000000..4a6c8914bd0 --- /dev/null +++ b/docs/public/main/writing_tests/verifying_changes/index.html @@ -0,0 +1,1431 @@ + + + + + + + Verifying Changes - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

Verifying Changes

+
+ +
+
+ +
+
Documentation Moved
+
+ This documentation has been relocated to Detailed Code Standards. Please use the new location for the most up-to-date information. +
+
+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/main/writing_tests/writing_a_new_test/index.html b/docs/public/main/writing_tests/writing_a_new_test/index.html new file mode 100644 index 00000000000..6c119442735 --- /dev/null +++ b/docs/public/main/writing_tests/writing_a_new_test/index.html @@ -0,0 +1,1875 @@ + + + + + + + Writing a New Test - EEST Docs + + + + + + + + + + + + + + + +
+ + +
+ +
+

Writing a New Test

+
+ +
+

Test Functions

+

Every test case is defined as a Python function that implements a single StateTest or BlockchainTest using the state_test or blockchain_test objects made available by the framework (learn how to decide on a test type). Test cases, and the respective test modules, must fulfill the following requirements:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
RequirementWhen
Be decorated with validity markersIf the test case is not valid for all forks
Use one of state_test or blockchain_test in its function argumentsAlways
Call the state_test or blockchain_test in its test bodyAlways
Add a reference version of the EIP spec under testTest path contains eip
+ + +

Specifying which Forks Tests are Valid For

+

Test cases can (and it most cases should) be decorated with one or more “validity markers” that define which the forks the test is valid for. This is achieved by applying:

+
    +
  • pytest.mark.valid_from(FORK) and/or pytest.mark.valid_until(FORK)
  • +
+

or

+
    +
  • pytest.mark.valid_at_transition_to(FORK)
  • +
+

markers on either the test function, test class or test module level:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
+ + + + + + + +
+ +
+ +
+
import pytest
+
+@pytest.mark.valid_from("Berlin")
+@pytest.mark.valid_until("London")
+def test_access_list(state_test: StateTestFiller, fork: Fork):
+
+
+ +
+
import pytest
+
+
+@pytest.mark.valid_from("Shanghai")
+class TestMultipleWithdrawalsSameAddress:
+
+
+ +
+
import pytest
+
+pytestmark = pytest.mark.valid_from("Shanghai")
+
+
+ +
+
+ + + + + + + + +

The ethereum_test_forks package defines the available forks and provides the following helpers that return all forks within the specified range:

+
    +
  • forks_from
  • +
  • forks_from_until
  • +
+

The state_test and blockchain_test Test Function Arguments

+

The test function’s signature must contain exactly one of either a state_test or blockchain_test argument.

+

For example, for state tests:

+
def test_access_list(state_test: StateTestFiller):
+

and for blockchain tests:

+
def test_contract_creating_tx(
+    blockchain_test: BlockchainTestFiller, fork: Fork, initcode: Initcode
+):
+

The state_test and blockchain_test objects are actually wrapper classes to the StateTest, respectively BlockchainTest objects, that once called actually instantiate a new instance of these objects and fill the test case using the evm tool according to the pre and post states and the transactions defined within the test.

+

If a blockchain-type test should only generate a test fixture in the Engine format (EngineFixture), the blockchain_test_engine object can be specified. This object is a wrapper for the BlockchainTestEngine class.

+

StateTest Object

+

The StateTest object represents a single test vector, and contains the +following attributes:

+
    +
  • env: Environment object which describes the global state of the blockchain +before the test starts.
  • +
  • pre: Pre-State containing the information of all Ethereum accounts that exist +before any transaction is executed.
  • +
  • post: Post-State containing the information of all Ethereum accounts that are +created or modified after all transactions are executed.
  • +
  • txs: All transactions to be executed during test execution.
  • +
+

BlockchainTest Object

+

The BlockchainTest object represents a single test vector that evaluates the +Ethereum VM by attempting to append multiple blocks to the chain:

+
    +
  • pre: Pre-State containing the information of all Ethereum accounts that exist +before any block is executed.
  • +
  • post: Post-State containing the information of all Ethereum accounts that are +created or modified after all blocks are executed.
  • +
  • blocks: All blocks to be appended to the blockchain during the test.
  • +
+

BlockchainTestEngine Object

+

The BlockchainTestEngine object has the same properties as the BlockchainTest but it’s used to only generate a blockchain test in the Engine format.

+

Pre/Post State of the Test

+

The pre and post states are elemental to setup and then verify the outcome +of the state test.

+

Both pre and post are mappings of account addresses to account structures (see more info).

+

A single test vector can contain as many accounts in the pre and post states +as required, and they can be also filled dynamically.

+

storage of an account is a key/value dictionary, and its values are +integers within range of [0, 2**256 - 1].

+

txs are the steps which transform the pre-state into the post-state and +must perform specific actions within the accounts (smart contracts) that result +in verifiable changes to the balance, nonce, and/or storage in each of them.

+

post is compared against the outcome of the client after the execution +of each transaction, and any differences are considered a failure

+

When designing a test, all the changes must be ideally saved into the contract’s +storage to be able to verify them in the post-state.

+

Test Transactions

+

Transactions can be crafted by sending them with specific data or to a +specific account, which contains the code to be executed.

+

Transactions can also create more accounts, by setting the to field to an +empty string.

+

Transactions can be designed to fail, and a verification must be made that the +transaction fails with the specific error that matches what is expected by the +test.

+

They can also contain a TransactionReceipt object in field expected_receipt +which allows checking for an exact gas_used value.

+

Writing code for the accounts in the test

+

Account bytecode can be “deployed” in a test’s pre-state using the pre pytest fixture. The execution-spec-tests Python Opcodes minilang can be used to help write the bytecode in a readable form.

+

Using the Python Opcode Minilang

+

EVM bytecode for tests should be written using the Python-based minilang provided by the Opcodes class. This allows you to construct bytecode using symbolic opcodes as Python objects.

+

Example: Simple Addition Contract

+
from ethereum_test_vm.opcode import Opcodes
+
+code = (
+    Opcodes.PUSH1(0x02)
+    + Opcodes.PUSH1(0x03)
+    + Opcodes.ADD()
+    + Opcodes.PUSH1(0x00)
+    + Opcodes.SSTORE()
+    + Opcodes.STOP()
+)
+
+# within a test function, using the "pre" fixture
+contract_address = pre.deploy_contract(code=code)
+

You add this contract to the test’s pre-state using the pre fixture or assign this code to the code field of an account in your test’s post state. See the state test tutorial for more help.

+

For a full list of available opcodes and their usage, see Opcodes.

+

Higher-Level Constructs

+

For more complex control flow, you can use constructs like Switch and Case from the ethereum_test_tools.code.generators module:

+
from ethereum_test_tools.code.generators import Switch, Case
+from ethereum_test_vm.opcode import Opcodes as Op
+
+code = Switch(
+    cases=[
+        Case(condition=Op.EQ(Op.CALLDATALOAD(0), 1), action=Op.PUSH1(0x01) + Op.STOP()),
+        Case(condition=Op.EQ(Op.CALLDATALOAD(0), 2), action=Op.PUSH1(0x02) + Op.STOP()),
+    ],
+    default_action=Op.PUSH1(0x00) + Op.STOP(),
+)
+

The ethereum_test_tools.code.generators module also defines other high-level constructs like While and Conditional.

+

Converting Bytecode to Minilang

+

If you have EVM bytecode (as hex or binary), you can use the evm_bytes CLI tool to convert it to the EEST Python opcode minilang automatically, for example:

+
uv run evm_bytes hex-string 0x604260005260206000F3
+# ->
+# Op.PUSH1[0x42] + Op.PUSH1[0x0] + Op.MSTORE + Op.PUSH1[0x20] + Op.PUSH1[0x0] + Op.RETURN
+

Restrictions: No Yul in Python Test Cases

+

As of PR #1779, the use of Yul source in Python test cases is forbidden. All new tests must use the Python opcode minilang as shown above.

+

Verifying the Accounts’ Post States

+

The state of the accounts after all blocks/transactions have been executed is +the way of verifying that the execution client actually behaves like the test +expects.

+

During their filling process, all tests automatically verify that the accounts +specified in their post property actually match what was returned by the +transition tool.

+

Within the post dictionary object, an account address can be:

+
    +
  • None: The account will not be checked for absence or existence in the +result returned by the transition tool.
  • +
  • Account object: The test expects that this account exists and also has +properties equal to the properties specified by the Account object.
  • +
  • Account.NONEXISTENT: The test expects that this account does not exist in +the result returned by the transition tool, and if the account exists, +it results in error. +E.g. when the transaction creating a contract is expected to fail and the +test wants to verify that the address where the contract was supposed to be +created is indeed empty.
  • +
+

The Account object

+

The Account object is used to specify the properties of an account to be +verified in the post state.

+

The python representation can be found in src/ethereum_test_types/account_types.py.

+

It can verify the following properties of an account:

+
    +
  • +

    nonce: the scalar value equal to a) the number of transactions sent by +an Externally Owned Account, b) the amount of contracts created by a contract.

    +
  • +
  • +

    balance: the amount of Wei (10-18 Eth) the account has.

    +
  • +
  • +

    code: Bytecode contained by the account. To verify that an account contains +no code, this property needs to be set to “0x” or “”.

    +
  • +
  • +

    storage: Storage within the account represented as a dict object. +All storage keys that are expected to be set must be specified, and if a +key is skipped, it is implied that its expected value is zero. +Setting this property to {} (empty dict), means that all the keys in the +account must be unset (equal to zero).

    +
  • +
+

All account’s properties are optional, and they can be skipped or set to None, +which means that no check will be performed on that specific account property.

+

Verifying correctness of the new test

+

A well written test performs a single verification output at a time.

+

A verification output can be a single storage slot, the balance of an account, +or a newly created contract.

+

It is not recommended to use balance changes to verify test correctness, as it +can be easily affected by gas cost changes in future EIPs.

+

The best way to verify a transaction/block execution outcome is to check its +storage.

+

A test can be written as a negative verification. E.g. a contract is not +created, or a transaction fails to execute or runs out of gas.

+

This kind of verification must be carefully crafted because it is possible to end up +having a false positive result, which means that the test passed but the +intended verification was never made.

+

To avoid these scenarios, it is important to have a separate verification to +check that test is effective. E.g. when a transaction is supposed to fail, it +is necessary to check that the failure error is actually the one expected by +the test.

+

Failing or invalid transactions

+

Transactions included in a StateTest are expected to be intrinsically valid, +i.e. the account sending the transaction must have enough funds to cover the +gas costs, the max fee of the transaction must be equal or higher than the +base fee of the block, etc.

+

An intrinsically valid transaction can still revert during its execution.

+

Blocks in a BlockchainTest can contain intrinsically invalid transactions but +in this case the block is expected to be completely rejected, along with all +transactions in it, including other valid transactions.

+

Parametrizing tests

+

Tests can be parametrized by using the @pytest.mark.parametrize decorator.

+

Example:

+
import pytest
+
+@pytest.mark.parametrize(
+    "tx_value,expected_balance",
+    [
+        pytest.param(0, 0, id="zero-value"),
+        pytest.param(100, 100, id="non-zero-value"),
+    ],
+)
+def test_contract_creating_tx(
+    blockchain_test: BlockchainTestFiller, fork: Fork, tx_value: int, expected_balance: int
+):
+

This will run the test twice, once with tx_value set to 0 and expected_balance +set to 0, and once with tx_value set to 100 and expected_balance set to 100.

+

The fork fixture is automatically provided by the framework and contains the +current fork under test, and does not need to be parametrized.

+

Tests can also be automatically parametrized with appropriate fork covariant +values using the with_all_* markers listed in the +Test Markers page.

+
+ +
+
+ + \ No newline at end of file diff --git a/docs/public/sitemap.xml b/docs/public/sitemap.xml new file mode 100644 index 00000000000..f1ce5ad92c6 --- /dev/null +++ b/docs/public/sitemap.xml @@ -0,0 +1,170 @@ + + + + http://localhost:1313/main/writing_tests/adding_a_new_test/ + + http://localhost:1313/main/filling_tests/getting_started/ + + http://localhost:1313/main/dev_docs/configurations/ + + http://localhost:1313/main/running_tests/running/ + + http://localhost:1313/main/running_tests/releases/ + + http://localhost:1313/main/getting_started/installation_troubleshooting/ + + http://localhost:1313/main/dev_docs/interactive_usage/ + + http://localhost:1313/main/writing_tests/types_of_tests/ + + http://localhost:1313/main/dev_docs/docs/ + + http://localhost:1313/main/running_tests/useful_pytest_options/ + + http://localhost:1313/main/writing_tests/writing_a_new_test/ + + http://localhost:1313/main/dev_docs/documenting_clis/ + + http://localhost:1313/main/writing_tests/test_markers/ + + http://localhost:1313/main/getting_started/code_standards/ + + http://localhost:1313/main/dev_docs/coding_style/ + + http://localhost:1313/main/writing_tests/verifying_changes/ + + http://localhost:1313/main/writing_tests/code_standards/ + + http://localhost:1313/main/getting_started/code_standards_details/ + + http://localhost:1313/main/dev_docs/logging/ + + http://localhost:1313/main/dev_docs/precommit/ + + http://localhost:1313/main/writing_tests/exception_tests/ + + http://localhost:1313/main/getting_started/setup_vs_code/ + + http://localhost:1313/main/getting_started/repository_overview/ + + http://localhost:1313/main/dev_docs/test_actions_locally/ + + http://localhost:1313/main/writing_tests/fork_methods/ + + http://localhost:1313/main/dev_docs/deps_and_packaging/ + + http://localhost:1313/main/getting_started/getting_help/ + + http://localhost:1313/main/writing_tests/reference_specification/ + + http://localhost:1313/main/writing_tests/eip_checklist/ + + http://localhost:1313/main/writing_tests/post_mortems/ + + http://localhost:1313/main/writing_tests/porting_legacy_tests/ + + http://localhost:1313/main/changelog/ + 2025-07-09T12:42:33+00:00 + + http://localhost:1313/main/writing_tests/checklist_templates/main/ + 2025-07-09T12:42:33+00:00 + + http://localhost:1313/main/running_tests/consume/main/ + 2025-07-09T12:42:33+00:00 + + http://localhost:1313/main/dev_docs/main/ + 2025-07-09T12:42:33+00:00 + + http://localhost:1313/ + 2025-07-09T12:42:33+00:00 + + http://localhost:1313/main/running_tests/execute/main/ + 2025-07-09T12:42:33+00:00 + + http://localhost:1313/main/main/ + 2025-07-09T12:42:33+00:00 + + http://localhost:1313/main/filling_tests/main/ + 2025-07-09T12:42:33+00:00 + + http://localhost:1313/main/running_tests/hive/main/ + 2025-07-09T12:42:33+00:00 + + http://localhost:1313/main/getting_started/main/ + 2025-07-09T12:42:33+00:00 + + http://localhost:1313/main/ + 2025-07-09T12:42:33+00:00 + + http://localhost:1313/main/running_tests/main/ + 2025-07-09T12:42:33+00:00 + + http://localhost:1313/main/running_tests/test_formats/main/ + 2025-07-09T12:42:33+00:00 + + http://localhost:1313/main/writing_tests/tutorials/main/ + 2025-07-09T12:42:33+00:00 + + http://localhost:1313/main/writing_tests/main/ + 2025-07-09T12:42:33+00:00 + + http://localhost:1313/main/running_tests/consume/cache/ + + http://localhost:1313/main/running_tests/consume/direct/ + + http://localhost:1313/main/running_tests/consume/exceptions/ + + http://localhost:1313/main/running_tests/consume/simulators/ + + http://localhost:1313/main/running_tests/execute/hive/ + + http://localhost:1313/main/running_tests/execute/remote/ + + http://localhost:1313/main/running_tests/hive/ci_integration/ + + http://localhost:1313/main/running_tests/hive/client_config/ + + http://localhost:1313/main/running_tests/hive/common_options/ + + http://localhost:1313/main/running_tests/hive/dev_mode/ + + http://localhost:1313/main/running_tests/hive/hiveview/ + + http://localhost:1313/main/running_tests/test_formats/blockchain_test/ + + http://localhost:1313/main/running_tests/test_formats/blockchain_test_engine/ + + http://localhost:1313/main/running_tests/test_formats/blockchain_test_engine_x/ + + http://localhost:1313/main/running_tests/test_formats/common_types/ + + http://localhost:1313/main/running_tests/test_formats/exceptions/ + + http://localhost:1313/main/running_tests/test_formats/state_test/ + + http://localhost:1313/main/running_tests/test_formats/transaction_test/ + + http://localhost:1313/main/writing_tests/checklist_templates/eip_testing_checklist_template/ + + http://localhost:1313/main/writing_tests/tutorials/blockchain/ + + http://localhost:1313/main/writing_tests/tutorials/state_transition/ + + http://localhost:1313/main/filling_tests/test_ids/ + + http://localhost:1313/categories/ + + http://localhost:1313/main/filling_tests/debugging_t8n_tools/ + + http://localhost:1313/main/filling_tests/filling_tests_command_line/ + + http://localhost:1313/main/filling_tests/filling_tests_dev_fork/ + + http://localhost:1313/main/filling_tests/filling_tests_vs_code/ + + http://localhost:1313/tags/ + + http://localhost:1313/main/filling_tests/transition_tool_support/ + + diff --git a/docs/public/tags/index.html b/docs/public/tags/index.html new file mode 100644 index 00000000000..9d716e6db0d --- /dev/null +++ b/docs/public/tags/index.html @@ -0,0 +1,129 @@ + + + + + + + + Tags + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +

Tags

+ + + +
+ + + +
+ +
+ + + + + + + + diff --git a/docs/public/tags/index.xml b/docs/public/tags/index.xml new file mode 100644 index 00000000000..d1a12bb5f3d --- /dev/null +++ b/docs/public/tags/index.xml @@ -0,0 +1,11 @@ + + + + Tags on EEST Docs + http://localhost:1313/tags/ + Recent content in Tags on EEST Docs + Hugo + en-us + + + diff --git a/docs/public/tags/page/1/index.html b/docs/public/tags/page/1/index.html new file mode 100644 index 00000000000..4a695e8bde2 --- /dev/null +++ b/docs/public/tags/page/1/index.html @@ -0,0 +1,10 @@ + + + + http://localhost:1313/tags/ + + + + + + diff --git a/docs/public/writing_tests/abc/index.html b/docs/public/writing_tests/abc/index.html new file mode 100644 index 00000000000..cad15b91a2a --- /dev/null +++ b/docs/public/writing_tests/abc/index.html @@ -0,0 +1,125 @@ + + + + + + + + Writing_tests + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

Writing_tests

+
+ + +
+ +

Writing Tests

+

The easiest way to get started is to use the interactive CLI:

+
uv run eest make test
+

and modify the generated test module to suit your needs.

+

For help deciding which test format to select, see Types of Tests, in particular Deciding on a Test Type

+

Key Resources

+ +

Please check that your code adheres to the repo’s coding standards and read the other pages in this section for more background and an explanation of how to implement state transition and blockchain tests.

+
+ +
+ +
+ +
+ + + + + + + + diff --git a/docs/public/writing_tests/adding_a_new_test/index.html b/docs/public/writing_tests/adding_a_new_test/index.html new file mode 100644 index 00000000000..b79830486ed --- /dev/null +++ b/docs/public/writing_tests/adding_a_new_test/index.html @@ -0,0 +1,139 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

+
+ + +
+ +

Adding a New Test

+

All test cases are located underneath the tests directory, which are then organized by fork. Each fork contains sub-directories containing test sub-categories.

+
πŸ“ execution-test-specs/
+β”œβ”€β•΄πŸ“ tests/
+|   β”œβ”€β”€ πŸ“„ __init__.py
+β”‚   β”œβ”€β”€ πŸ“ cancun/
+|   |    β”œβ”€β”€ πŸ“„ __init__.py
+β”‚   |    └── πŸ“ eip4844_blobs/
+|   |        β”œβ”€β”€ πŸ“„ __init__.py
+|   |        β”œβ”€β”€ πŸ“„ test_blobhash_opcode.py
+|   |        β”œβ”€β”€ πŸ“„ test_excess_blob_gas.py
+|   |        └── πŸ“„ ...
+|   β”œβ”€β”€ πŸ“ shanghai
+|   |    β”œβ”€β”€ πŸ“ eip3651_warm_coinbase
+|   |    |   β”œβ”€β”€ πŸ“„ __init__.py
+|   |    |   └── πŸ“„ test_warm_coinbase.py
+|   |    β”œβ”€β”€ πŸ“ eip3855_push0
+|   |    |   β”œβ”€β”€ πŸ“„ __init__.py
+|   |    |   └── πŸ“„ test_push0.py
+|   |    β”œβ”€β”€ πŸ“...
+|   |    ...
+β”‚   └── πŸ“ ...
+

Each category/sub-directory may have multiple Python test modules (*.py) which in turn may contain many test functions. The test functions themselves are always parametrized by fork (by the framework).

+

A new test can be added by either:

+
    +
  • Adding a new test_ python function to an existing file in any of the existing category subdirectories within tests.
  • +
  • Creating a new source file in an existing category, and populating it with the new test function(s).
  • +
  • Creating an entirely new category by adding a subdirectory in tests with the appropriate source files and test functions.
  • +
+
+ +
+ +
+ +
+ + + + + + + + diff --git a/docs/public/writing_tests/checklist_templates/index.html b/docs/public/writing_tests/checklist_templates/index.html new file mode 100644 index 00000000000..2c51a3322f6 --- /dev/null +++ b/docs/public/writing_tests/checklist_templates/index.html @@ -0,0 +1,112 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

+
+ + +
+ +

Testing Checklist Templates

+

This page includes checklist templates that must be followed to guarantee a minimum base testing coverage of new EIP feature.

+
+ +
+ +
+ +
+ + + + + + + + diff --git a/docs/public/writing_tests/code_standards/index.html b/docs/public/writing_tests/code_standards/index.html new file mode 100644 index 00000000000..0775fb84ee0 --- /dev/null +++ b/docs/public/writing_tests/code_standards/index.html @@ -0,0 +1,114 @@ + + + + + + + + Coding Standards + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

Coding Standards

+
+ + +
+ +

Code Standards

+

This documentation has been relocated.

+

yyyyyyyyyy

+

yeet

+
+ +
+ +
+ +
+ + + + + + + + diff --git a/docs/public/writing_tests/eip_checklist/index.html b/docs/public/writing_tests/eip_checklist/index.html new file mode 100644 index 00000000000..6418625c6dd --- /dev/null +++ b/docs/public/writing_tests/eip_checklist/index.html @@ -0,0 +1,295 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

+
+ + +
+ +

EIP Checklist Generation

+

The EIP checklist feature helps track test coverage for EIP implementations by automatically generating filled checklists based on test markers.

+

Overview

+

When implementing tests for an EIP, you can mark specific tests as covering checklist items from the EIP testing checklist template. The framework will then generate a filled checklist showing which items have been implemented.

+

Marking Tests as implementing EIP Checklist Items

+

To mark a test as implementing a specific checklist item, use the structured EIPChecklist class:

+

The EIPChecklist Class

+
import pytest
+from ethereum_test_tools import StateTestFiller
+from ethereum_test_checklists import EIPChecklist
+
+@EIPChecklist.TransactionType.Test.IntrinsicValidity.GasLimit.Exact()
+def test_exact_intrinsic_gas(state_test: StateTestFiller):
+    """Test transaction with exact intrinsic gas limit."""
+    # Test implementation
+    pass
+
+# You can also use the marker without parentheses
+@EIPChecklist.TransactionType.Test.IntrinsicValidity.GasLimit.Insufficient
+def test_insufficient_intrinsic_gas(state_test: StateTestFiller):
+    """Test transaction with insufficient intrinsic gas limit."""
+    # Test implementation
+    pass
+

The EIPChecklist class provides type safety and IDE autocompletion, making it easier to find and reference checklist items correctly.

+

Marker Parameters

+
    +
  • First positional parameter (required): The checklist item ID (EIPChecklist reference)
  • +
  • eip keyword parameter (optional): List of additional EIPs covered by the test
  • +
+

Example with multiple EIPs covered by the same test:

+
@EIPChecklist.TransactionType.Test.Signature.Invalid.V.Two(
+    eip=[7702, 2930]
+)
+def test_invalid_signature(state_test: StateTestFiller):
+    """Test invalid signature that affects multiple EIPs."""
+    pass
+

Partial ID Matching

+

You can use partial IDs that will match all checklist items starting with that prefix:

+
@EIPChecklist.TransactionType.Test.Signature.Invalid()
+def test_all_invalid_signatures(state_test: StateTestFiller):
+    """Test covering all invalid signature scenarios."""
+    pass
+

Generating Checklists

+

Using the Dedicated checklist Command

+

To generate only checklists without filling fixtures:

+
# Generate checklists for all EIPs
+uv run checklist
+
+# Generate checklist for specific EIP
+uv run checklist --eip 7702
+
+# Specify output directory
+uv run checklist --output ./my-checklists
+
+# Multiple EIPs
+uv run checklist --eip 7702 --eip 2930
+

Automatic Generation in Documentation

+

When building the documentation with mkdocs, checklists are automatically generated for all EIPs that have tests with checklist markers. The checklists appear in the test documentation alongside the test modules.

+

External Coverage and Not Applicable Items

+

External Coverage

+

For checklist items that are covered by external tests, procedures, or tools (e.g., EELS coverage), create a file named eip_checklist_external_coverage.txt in the EIP test directory:

+
# tests/prague/eip7702_set_code_tx/eip_checklist_external_coverage.txt
+general/code_coverage/eels = Covered by EELS test suite
+general/code_coverage/second_client = Covered by Nethermind tests
+

Format: checklist_item_id = reason

+

Not Applicable Items

+

For checklist items that are not applicable to a specific EIP, create a file named eip_checklist_not_applicable.txt in the EIP test directory:

+
# tests/prague/eip7702_set_code_tx/eip_checklist_not_applicable.txt
+system_contract = EIP-7702 does not introduce a system contract
+precompile = EIP-7702 does not introduce a precompile
+

Format: checklist_item_id = reason

+

Both files support partial ID matching, so you can mark entire sections as not applicable:

+

MyPy Type Checking Support

+

The EIPChecklist classes are made callable through a companion .pyi stub file that provides proper type hints for mypy. This allows you to use both decorator patterns without type checking errors:

+
# Both of these work with proper mypy support
+@EIPChecklist.Opcode.Test.StackComplexOperations()  # With parentheses
+@EIPChecklist.Opcode.Test.StackComplexOperations   # Without parentheses
+

Regenerating Type Stubs

+

If you modify the EIPChecklist class structure in src/ethereum_test_checklists/eip_checklist.py, you need to regenerate the type stub file:

+
# Generate the stub file (for maintainers):
+uv run generate_checklist_stubs
+
+# Preview what would be generated without writing the file
+uv run generate_checklist_stubs --dry-run
+
+# Generate to a custom location
+uv run generate_checklist_stubs --output path/to/custom/stubs.pyi
+

The generated stub file (eip_checklist.pyi) should be committed to the repository to ensure proper type checking for all developers.

+
# Mark all system contract items as not applicable
+system_contract/ = EIP does not introduce system contracts
+

Output Format

+

The generated checklist will show:

+
    +
  • βœ… for completed items (either by tests or external coverage)
  • +
  • N/A for not applicable items
  • +
  • Test names that implement each item
  • +
  • External coverage reasons where applicable
  • +
  • A percentage of covered checklist items (excluding N/A items)
  • +
  • Color-coded completion status: 🟒 (100%), 🟑 (>50%), πŸ”΄ (≀50%)
  • +
+

Example output snippet:

+
# EIP-7702 Test Checklist
+
+## Checklist Progress Tracker
+
+| Total Checklist Items | Covered Checklist Items | Percentage |
+| --------------------- | ----------------------- | ---------- |
+| 45 | 32 | 🟑 71.11% |
+
+## General
+
+#### Code coverage
+
+| ID | Description | Status | Tests |
+| -- | ----------- | ------ | ----- |
+| `general/code_coverage/eels` | Run produced tests against EELS... | βœ… | Covered by EELS test suite |
+| `general/code_coverage/test_coverage` | Run coverage on the test code itself... | βœ… | `tests/prague/eip7702_set_code_tx/test_set_code_txs.py::test_set_code_txs` |
+
+## Transaction Type
+
+| ID | Description | Status | Tests |
+| -- | ----------- | ------ | ----- |
+| `transaction_type/test/intrinsic_validity/gas_limit/exact` | Provide the exact intrinsic gas... | βœ… | `tests/prague/eip7702_set_code_tx/test_checklist_example.py::test_exact_intrinsic_gas` |
+| `transaction_type/test/intrinsic_validity/gas_limit/insufficient` | Provide the exact intrinsic gas minus one... |  |  |
+
+## System Contract
+
+| ID | Description | Status | Tests |
+| -- | ----------- | ------ | ----- |
+| `system_contract/test/deployment/missing` | Verify block execution behavior... | N/A | EIP-7702 does not introduce a system contract |
+

Best Practices

+
    +
  1. Start with the checklist: Review the checklist template before writing tests to ensure comprehensive coverage
  2. +
  3. Use the EIPChecklist class: Use EIPChecklist.Opcode.Test.GasUsage.Normal for type safety and IDE autocompletion
  4. +
  5. Use descriptive test names: The test name will appear in the checklist, so make it clear what the test covers
  6. +
  7. Mark items as you go: Add eip_checklist markers while writing tests, not as an afterthought
  8. +
  9. Document external coverage: If items are covered by external tools/tests, document this in eip_checklist_external_coverage.txt
  10. +
  11. Be explicit about N/A items: Document why items are not applicable in eip_checklist_not_applicable.txt
  12. +
  13. Use partial IDs wisely: When a test covers multiple related items, use partial IDs to mark them all
  14. +
  15. Verify IDs before using: Use str(EIPChecklist.Section.Subsection) to verify the exact string ID when needed
  16. +
+

Workflow Example

+
    +
  1. +

    Create test directory structure:

    +
    tests/prague/eip9999_new_feature/
    +β”œβ”€β”€ __init__.py
    +β”œβ”€β”€ spec.py
    +β”œβ”€β”€ test_basic.py
    +β”œβ”€β”€ eip_checklist_external_coverage.txt
    +└── eip_checklist_not_applicable.txt
    +
  2. +
  3. +

    Mark tests as you implement them:

    +
    from ethereum_test_checklists import EIPChecklist
    +
    +@EIPChecklist.Opcode.Test.GasUsage.Normal()
    +def test_opcode_gas_consumption(state_test: StateTestFiller):
    +   """Test normal gas consumption of the new opcode."""
    +   pass
    +
  4. +
  5. +

    Document external coverage:

    +
    # eip_checklist_external_coverage.txt
    +general/code_coverage/eels = Covered by ethereum/execution-specs PR #1234
    +

    You can verify the correct ID using:

    +
    # str(EIPChecklist.General.CodeCoverage.Eels) = "general/code_coverage/eels"
    +
  6. +
  7. +

    Mark non-applicable items:

    +
    # eip_checklist_not_applicable.txt
    +precompile/ = EIP-9999 introduces an opcode, not a precompile
    +

    You can verify the correct ID using:

    +
    # str(EIPChecklist.Precompile) = "precompile"
    +
  8. +
  9. +

    Generate and review checklist:

    +
    checklist --eip 9999
    +# Review the generated checklist for completeness
    +
  10. +
+

See Also

+ +
+ +
+ +
+ +
+ + + + + + + + diff --git a/docs/public/writing_tests/exception_tests/index.html b/docs/public/writing_tests/exception_tests/index.html new file mode 100644 index 00000000000..75d0d419577 --- /dev/null +++ b/docs/public/writing_tests/exception_tests/index.html @@ -0,0 +1,134 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

+
+ + +
+ +

Exception Tests

+

Exception tests are a special type of test which verify that an invalid transaction or an invalid block are correctly rejected with the expected error.

+

Creating an Exception Test

+

To test for an exception, the test can use either of the following types from ethereum_test_exceptions library:

+
    +
  1. +

    TransactionException: To be added to the error field of the Transaction object, and to the exception field of the Block object that includes the transaction; this exception type is used when a transaction is invalid, and therefore when included in a block, the block is expected to be invalid too. This is different from valid transactions where an exception during EVM execution is expected (e.g. a revert, or out-of-gas), which can be included in valid blocks.

    +

    For an example, see eip3860_initcode.test_initcode.test_contract_creating_tx which raises TransactionException.INITCODE_SIZE_EXCEEDED in the case that the initcode size exceeds the maximum allowed size.

    +
  2. +
  3. +

    BlockException: To be added to the exception field of the Block object; this exception type is used when a block is expected to be invalid, but the exception is related to a block property, e.g. an invalid value of the block header.

    +

    For an example, see eip4844_blobs.test_excess_blob_gas.test_invalid_static_excess_blob_gas which raises BlockException.INCORRECT_EXCESS_BLOB_GAS in the case that the excessBlobGas remains unchanged +but the parent blobs included are not TARGET_BLOBS_PER_BLOCK.

    +
  4. +
+

Although exceptions can be combined with the | operator to indicate that a test vector can throw either one of multiple exceptions, ideally the tester should aim to use only one exception per test vector, and only use multiple exceptions on the rare instance when it is not possible to know which exception will be thrown because it depends on client implementation.

+

Adding a new exception

+

If a test requires a new exception, because none of the existing ones is suitable for the test, a new exception can be added to either TransactionException or BlockException classes.

+

The new exception should be added as a new enum value, and the docstring of the attribute should be a string that describes the exception.

+

The name of the exception should be unique, and should not be used by any other exception.

+

Test runner behavior on exception tests

+

When an exception is added to a test vector, the test runner must check that the transaction or block is rejected with the expected exception.

+

The test runner must map the exception key to the corresponding error string that is expected to be returned by the client.

+

Exception mapping are particularly important in blockchain tests because the block can be invalid for multiple reasons, and the client returning a different error can mean that a verification in the client is faulty.

+
+ +
+ +
+ +
+ + + + + + + + diff --git a/docs/public/writing_tests/fork_methods/index.html b/docs/public/writing_tests/fork_methods/index.html new file mode 100644 index 00000000000..2f3c1e57e45 --- /dev/null +++ b/docs/public/writing_tests/fork_methods/index.html @@ -0,0 +1,306 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

+
+ + +
+ +

Using and Extending Fork Methods

+

This document describes the Fork class in the Ethereum execution spec tests framework, which provides a standardized way to define properties of Ethereum forks. Understanding how to use and extend these fork methods is essential for writing flexible tests that can automatically adapt to different forks.

+

Overview

+

The BaseFork class is an abstract base class that defines the interface for all Ethereum forks. Each implemented fork (like Frontier, Homestead, etc.) extends this class and implements its abstract methods to provide fork-specific behavior.

+

The fork system allows:

+
    +
  1. Defining fork-specific behaviors and parameters
  2. +
  3. Comparing forks chronologically (Paris < Shanghai)
  4. +
  5. Supporting automatic fork transitions
  6. +
  7. Writing tests that automatically adapt to different forks
  8. +
+

Using Fork Methods in Tests

+

Fork methods are powerful tools that allow your tests to adapt to different Ethereum forks automatically. Here are common patterns for using them:

+

1. Check Fork Support for Features

+
def test_some_feature(fork):
+    if fork.supports_blobs(block_number=0, timestamp=0):
+        # Test blob-related functionality
+        ...
+    else:
+        # Test alternative or skip
+        pytest.skip("Fork does not support blobs")
+

2. Get Fork-Specific Parameters

+
def test_transaction_gas(fork, state_test):
+    gas_cost = fork.gas_costs(block_number=0, timestamp=0).G_TRANSACTION
+    
+    # Create a transaction with the correct gas parameters for this fork
+    tx = Transaction(
+        gas_limit=gas_cost + 10000,
+        # ...
+    )
+    
+    state_test(
+        env=Environment(),
+        pre=pre,
+        tx=tx,
+        # ...
+    )
+

3. Determine Valid Transaction Types

+
def test_transaction_types(fork, state_test):
+    for tx_type in fork.tx_types(block_number=0, timestamp=0):
+        # Test each transaction type supported by this fork
+        # ...
+

4. Determine Valid Opcodes

+
def test_opcodes(fork, state_test):
+    # Create bytecode using only opcodes valid for this fork
+    valid_opcodes = fork.valid_opcodes()
+    
+    # Use these opcodes to create test bytecode
+    # ...
+

5. Test Fork Transitions

+
def test_fork_transition(transition_fork, blockchain_test):
+    # The transition_fork is a special fork type that changes behavior
+    # based on block number or timestamp
+    fork_before = transition_fork.fork_at(block_number=4, timestamp=0)
+    fork_after = transition_fork.fork_at(block_number=5, timestamp=0)
+    
+    # Test behavior before and after transition
+    # ...
+

Important Fork Methods

+

Header Information

+

These methods determine what fields are required in block headers for a given fork:

+
fork.header_base_fee_required(block_number=0, timestamp=0)  # Added in London
+fork.header_prev_randao_required(block_number=0, timestamp=0)  # Added in Paris
+fork.header_withdrawals_required(block_number=0, timestamp=0)  # Added in Shanghai
+fork.header_excess_blob_gas_required(block_number=0, timestamp=0)  # Added in Cancun
+fork.header_blob_gas_used_required(block_number=0, timestamp=0)  # Added in Cancun
+fork.header_beacon_root_required(block_number=0, timestamp=0)  # Added in Cancun
+fork.header_requests_required(block_number=0, timestamp=0)  # Added in Prague
+

Gas Parameters

+

Methods for determining gas costs and calculations:

+
fork.gas_costs(block_number=0, timestamp=0)  # Returns a GasCosts dataclass
+fork.memory_expansion_gas_calculator(block_number=0, timestamp=0)  # Returns a callable
+fork.transaction_intrinsic_cost_calculator(block_number=0, timestamp=0)  # Returns a callable
+

Transaction Types

+

Methods for determining valid transaction types:

+
fork.tx_types(block_number=0, timestamp=0)  # Returns list of supported transaction types
+fork.contract_creating_tx_types(block_number=0, timestamp=0)  # Returns list of tx types that can create contracts 
+fork.precompiles(block_number=0, timestamp=0)  # Returns list of precompile addresses
+fork.system_contracts(block_number=0, timestamp=0)  # Returns list of system contract addresses
+

EVM Features

+

Methods for determining EVM features and valid opcodes:

+
fork.evm_code_types(block_number=0, timestamp=0)  # Returns list of supported code types (e.g., Legacy, EOF)
+fork.valid_opcodes()  # Returns list of valid opcodes for this fork
+fork.call_opcodes(block_number=0, timestamp=0)  # Returns list of call opcodes with their code types
+fork.create_opcodes(block_number=0, timestamp=0)  # Returns list of create opcodes with their code types
+
+

Methods for blob transaction support:

+
fork.supports_blobs(block_number=0, timestamp=0)  # Returns whether blobs are supported
+fork.blob_gas_price_calculator(block_number=0, timestamp=0)  # Returns a callable
+fork.excess_blob_gas_calculator(block_number=0, timestamp=0)  # Returns a callable
+fork.min_base_fee_per_blob_gas(block_number=0, timestamp=0)  # Returns minimum base fee per blob gas
+fork.blob_gas_per_blob(block_number=0, timestamp=0)  # Returns blob gas per blob
+fork.target_blobs_per_block(block_number=0, timestamp=0)  # Returns target blobs per block
+fork.max_blobs_per_block(block_number=0, timestamp=0)  # Returns max blobs per block
+

Meta Information

+

Methods for fork identification and comparison:

+
fork.name()  # Returns the name of the fork
+fork.transition_tool_name(block_number=0, timestamp=0)  # Returns name for transition tools
+fork.is_deployed()  # Returns whether the fork is deployed to mainnet
+

Fork Transitions

+

The framework supports creating transition forks that change behavior at specific block numbers or timestamps:

+
@transition_fork(to_fork=Shanghai, at_timestamp=15_000)
+class ParisToShanghaiAtTime15k(Paris):
+    """Paris to Shanghai transition at Timestamp 15k."""
+    pass
+

With transition forks, you can test how behavior changes across fork boundaries:

+
# Behavior changes at block 5
+fork = BerlinToLondonAt5
+assert not fork.header_base_fee_required(block_number=4)  # Berlin doesn't require base fee
+assert fork.header_base_fee_required(block_number=5)      # London requires base fee
+

Adding New Fork Methods

+

When adding new fork methods, follow these guidelines:

+
    +
  1. Abstract Method Definition: Add the new abstract method to BaseFork in base_fork.py
  2. +
  3. Consistent Parameter Pattern: Use block_number and timestamp parameters with default values
  4. +
  5. Method Documentation: Add docstrings explaining the purpose and behavior
  6. +
  7. Implementation in Subsequent Forks: Implement the method in every subsequent fork class only if the fork updates the value from previous forks.
  8. +
+

Example of adding a new method:

+
@classmethod
+@abstractmethod
+def supports_new_feature(cls, block_number: int = 0, timestamp: int = 0) -> bool:
+    """Return whether the given fork supports the new feature."""
+    pass
+

Implementation in a fork class:

+
@classmethod
+def supports_new_feature(cls, block_number: int = 0, timestamp: int = 0) -> bool:
+    """Return whether the given fork supports the new feature."""
+    return False  # Frontier doesn't support this feature
+

Implementation in a newer fork class:

+
@classmethod
+def supports_new_feature(cls, block_number: int = 0, timestamp: int = 0) -> bool:
+    """Return whether the given fork supports the new feature."""
+    return True  # This fork does support the feature
+

When to Add a New Fork Method

+

Add a new fork method when:

+
    +
  1. A New EIP Introduces a Feature: Add methods describing the new feature’s behavior
  2. +
  3. Tests Need to Behave Differently: When tests need to adapt to different fork behaviors
  4. +
  5. Common Fork Information is Needed: When multiple tests need the same fork-specific information
  6. +
  7. Intrinsic Fork Properties Change: When gas costs, opcodes, or other intrinsic properties change
  8. +
+

Do not add a new fork method when:

+
    +
  1. The information is only needed for one specific test
  2. +
  3. The information is not directly related to fork behavior
  4. +
  5. The information can be calculated using existing methods
  6. +
+

Best Practices

+
    +
  1. Use Existing Methods: Check if there’s already a method that provides the information you need
  2. +
  3. Name Methods Clearly: Method names should clearly describe what they return
  4. +
  5. Document Behavior: Include clear docstrings explaining the method’s purpose and return value
  6. +
  7. Avoid Hard-coding: Use fork methods in tests instead of hard-coding fork-specific behavior
  8. +
  9. Test Transitions: Ensure your method works correctly with transition forks
  10. +
+

Example: Complete Test Using Fork Methods

+

Here’s an example of a test that fully utilizes fork methods to adapt its behavior:

+
def test_transaction_with_fork_adaptability(fork, state_test):
+    # Prepare pre-state
+    pre = Alloc()
+    sender = pre.fund_eoa()
+    
+    # Define transaction based on fork capabilities
+    tx_params = {
+        "gas_limit": 1_000_000,
+        "sender": sender,
+    }
+    
+    # Add appropriate transaction type based on fork
+    tx_types = fork.tx_types(block_number=0, timestamp=0)
+    if 3 in tx_types and fork.supports_blobs(block_number=0, timestamp=0):
+        # EIP-4844 blob transaction (type 3)
+        tx_params["blob_versioned_hashes"] = [Hash.generate_zero_hashes(1)[0]]
+    elif 2 in tx_types:
+        # EIP-1559 transaction (type 2)
+        tx_params["max_fee_per_gas"] = 10
+        tx_params["max_priority_fee_per_gas"] = 1
+    elif 1 in tx_types:
+        # EIP-2930 transaction (type 1)
+        tx_params["access_list"] = []
+        
+    # Create and run the test
+    tx = Transaction(**tx_params)
+    
+    state_test(
+        env=Environment(),
+        pre=pre,
+        tx=tx,
+        post={
+            sender: Account(nonce=1),
+        },
+    )
+

Conclusion

+

The Fork class is a powerful abstraction that allows tests to adapt to different Ethereum forks. By using fork methods consistently, you can write tests that automatically handle fork-specific behavior, making your tests more maintainable and future-proof.

+

When adding new fork methods, keep them focused, well-documented, and implement them across all forks. This will ensure that all tests can benefit from the information and that transitions between forks are handled correctly.

+
+ +
+ +
+ +
+ + + + + + + + diff --git a/docs/public/writing_tests/img/eest_make_test.mp4 b/docs/public/writing_tests/img/eest_make_test.mp4 new file mode 100644 index 00000000000..5694dc8de07 Binary files /dev/null and b/docs/public/writing_tests/img/eest_make_test.mp4 differ diff --git a/docs/public/writing_tests/img/eip_reference_spec_console_output.png b/docs/public/writing_tests/img/eip_reference_spec_console_output.png new file mode 100644 index 00000000000..f043ed2fef4 Binary files /dev/null and b/docs/public/writing_tests/img/eip_reference_spec_console_output.png differ diff --git a/docs/public/writing_tests/img/eip_reference_spec_console_output_fail.png b/docs/public/writing_tests/img/eip_reference_spec_console_output_fail.png new file mode 100644 index 00000000000..2c36f0dfbaf Binary files /dev/null and b/docs/public/writing_tests/img/eip_reference_spec_console_output_fail.png differ diff --git a/docs/public/writing_tests/index.html b/docs/public/writing_tests/index.html new file mode 100644 index 00000000000..ece92a2d6ca --- /dev/null +++ b/docs/public/writing_tests/index.html @@ -0,0 +1,199 @@ + + + + + + + + Writing_tests + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +

Writing_tests

+ +
+ + + + + + + + +

Coding Standards

+
July 9, 2025
+ + + +
+
+ + + + + + + + +

Writing Tests

+
July 9, 2025
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+ + +
+ + + +
+ + + + + + + +
+ + + +
+ +
+ + + + + + + + diff --git a/docs/public/writing_tests/index.xml b/docs/public/writing_tests/index.xml new file mode 100644 index 00000000000..173a8078dfe --- /dev/null +++ b/docs/public/writing_tests/index.xml @@ -0,0 +1,124 @@ + + + + Writing_tests on EEST Docs + http://localhost:1313/writing_tests/ + Recent content in Writing_tests on EEST Docs + Hugo + en-us + Wed, 09 Jul 2025 12:42:33 +0000 + + + Coding Standards + http://localhost:1313/writing_tests/code_standards/ + Wed, 09 Jul 2025 12:42:33 +0000 + http://localhost:1313/writing_tests/code_standards/ + <h1 id="code-standards"><a href="#test-abc">Code Standards</a></h1> <p>This documentation has been relocated.</p> <h2 id="yyyyyyyyyy">yyyyyyyyyy</h2> <p>yeet</p> + + + Writing Tests + http://localhost:1313/writing_tests/main/ + Wed, 09 Jul 2025 12:42:33 +0000 + http://localhost:1313/writing_tests/main/ + <p>The easiest way to get started is to use the interactive CLI:</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-console" data-lang="console"><span style="display:flex;"><span>uv run eest make test </span></span></code></pre></div><p>and modify the generated test module to suit your needs.</p> <p>For help deciding which test format to select, see <a href="types_of_tests.md">Types of Tests</a>, in particular <a href="types_of_tests.md#deciding-on-a-test-type">Deciding on a Test Type</a></p> <h2 id="key-resources">Key Resources</h2> <ul> <li><a href="http://localhost:1313/writing_tests/code_standards/#test-abc">Coding Standards</a> - Code style and standards for this repository</li> <li><a href="adding_a_new_test.md">Adding a New Test</a> - Step-by-step guide to adding new tests</li> <li><a href="writing_a_new_test.md">Writing a New Test</a> - Detailed guide on writing different test types</li> <li><a href="fork_methods.md">Using and Extending Fork Methods</a> - How to use fork methods to write fork-adaptive tests</li> <li><a href="porting_legacy_tests.md">Porting tests</a>: A guide to porting @ethereum/tests to EEST.</li> </ul> <p>Please check that your code adheres to the repo&rsquo;s coding standards and read the other pages in this section for more background and an explanation of how to implement state transition and blockchain tests.</p> + + + + http://localhost:1313/writing_tests/adding_a_new_test/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/writing_tests/adding_a_new_test/ + <h1 id="adding-a-new-test">Adding a New Test</h1> <p>All test cases are located underneath the <code>tests</code> directory, which are then organized by fork. Each fork contains sub-directories containing test sub-categories.</p> <div class="highlight"><pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><code class="language-text" data-lang="text"><span style="display:flex;"><span>πŸ“ execution-test-specs/ </span></span><span style="display:flex;"><span>β”œβ”€β•΄πŸ“ tests/ </span></span><span style="display:flex;"><span>| β”œβ”€β”€ πŸ“„ __init__.py </span></span><span style="display:flex;"><span>β”‚ β”œβ”€β”€ πŸ“ cancun/ </span></span><span style="display:flex;"><span>| | β”œβ”€β”€ πŸ“„ __init__.py </span></span><span style="display:flex;"><span>β”‚ | └── πŸ“ eip4844_blobs/ </span></span><span style="display:flex;"><span>| | β”œβ”€β”€ πŸ“„ __init__.py </span></span><span style="display:flex;"><span>| | β”œβ”€β”€ πŸ“„ test_blobhash_opcode.py </span></span><span style="display:flex;"><span>| | β”œβ”€β”€ πŸ“„ test_excess_blob_gas.py </span></span><span style="display:flex;"><span>| | └── πŸ“„ ... </span></span><span style="display:flex;"><span>| β”œβ”€β”€ πŸ“ shanghai </span></span><span style="display:flex;"><span>| | β”œβ”€β”€ πŸ“ eip3651_warm_coinbase </span></span><span style="display:flex;"><span>| | | β”œβ”€β”€ πŸ“„ __init__.py </span></span><span style="display:flex;"><span>| | | └── πŸ“„ test_warm_coinbase.py </span></span><span style="display:flex;"><span>| | β”œβ”€β”€ πŸ“ eip3855_push0 </span></span><span style="display:flex;"><span>| | | β”œβ”€β”€ πŸ“„ __init__.py </span></span><span style="display:flex;"><span>| | | └── πŸ“„ test_push0.py </span></span><span style="display:flex;"><span>| | β”œβ”€β”€ πŸ“... </span></span><span style="display:flex;"><span>| | ... </span></span><span style="display:flex;"><span>β”‚ └── πŸ“ ... </span></span></code></pre></div><p>Each category/sub-directory may have multiple Python test modules (<code>*.py</code>) which in turn may contain many test functions. The test functions themselves are always parametrized by fork (by the framework).</p> + + + + http://localhost:1313/writing_tests/checklist_templates/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/writing_tests/checklist_templates/ + <h1 id="testing-checklist-templates">Testing Checklist Templates</h1> <p>This page includes checklist templates that must be followed to guarantee a minimum base testing coverage of new EIP feature.</p> + + + + http://localhost:1313/writing_tests/eip_checklist/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/writing_tests/eip_checklist/ + <h1 id="eip-checklist-generation">EIP Checklist Generation</h1> <p>The EIP checklist feature helps track test coverage for EIP implementations by automatically generating filled checklists based on test markers.</p> <h2 id="overview">Overview</h2> <p>When implementing tests for an EIP, you can mark specific tests as covering checklist items from the <a href="../writing_tests/checklist_templates/eip_testing_checklist_template.md">EIP testing checklist template</a>. The framework will then generate a filled checklist showing which items have been implemented.</p> <h2 id="marking-tests-as-implementing-eip-checklist-items">Marking Tests as implementing EIP Checklist Items</h2> <p>To mark a test as implementing a specific checklist item, use the structured <code>EIPChecklist</code> class:</p> + + + + http://localhost:1313/writing_tests/exception_tests/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/writing_tests/exception_tests/ + <h1 id="exception-tests">Exception Tests</h1> <p>Exception tests are a special type of test which verify that an invalid transaction or an invalid block are correctly rejected with the expected error.</p> <h2 id="creating-an-exception-test">Creating an Exception Test</h2> <p>To test for an exception, the test can use either of the following types from <code>ethereum_test_exceptions</code> library:</p> <ol> <li> <p><a href="../library/ethereum_test_exceptions.md#ethereum_test_exceptions.TransactionException"><code>TransactionException</code></a>: To be added to the <code>error</code> field of the <code>Transaction</code> object, and to the <code>exception</code> field of the <code>Block</code> object that includes the transaction; this exception type is used when a transaction is invalid, and therefore when included in a block, the block is expected to be invalid too. This is different from valid transactions where an exception during EVM execution is expected (e.g. a revert, or out-of-gas), which can be included in valid blocks.</p> + + + + http://localhost:1313/writing_tests/fork_methods/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/writing_tests/fork_methods/ + <h1 id="using-and-extending-fork-methods">Using and Extending Fork Methods</h1> <p>This document describes the Fork class in the Ethereum execution spec tests framework, which provides a standardized way to define properties of Ethereum forks. Understanding how to use and extend these fork methods is essential for writing flexible tests that can automatically adapt to different forks.</p> <h2 id="overview">Overview</h2> <p>The <code>BaseFork</code> class is an abstract base class that defines the interface for all Ethereum forks. Each implemented fork (like Frontier, Homestead, etc.) extends this class and implements its abstract methods to provide fork-specific behavior.</p> + + + + http://localhost:1313/writing_tests/porting_legacy_tests/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/writing_tests/porting_legacy_tests/ + <h1 id="a-guide-to-porting-original-ethereum-tests-to-eest">A Guide to Porting Original Ethereum Tests to EEST</h1> <h2 id="background">Background</h2> <p>EEST is the successor to <a href="https://github.com/ethereum/tests">ethereum/tests</a> (aka &ldquo;original tests&rdquo;), a repository that defined EVM test cases from the <a href="https://ethereum.org/en/history/#frontier">Frontier</a> phase up to and including <a href="https://ethereum.org/en/history/#paris">The Merge</a>. These test cases are specified as YAML (and occasionally JSON) files in the <a href="https://github.com/ethereum/tests/tree/develop/src"><code>./src/</code></a> sub-directory. JSON test fixtures, which are fully-populated tests that can be executed against clients, are generated using <a href="https://github.com/ethereum/retesteth">ethereum/retesteth</a>. These JSON artifacts are regenerated when needed and added to the repository, typically in the <a href="https://github.com/ethereum/execution-spec-tests/tree/main/tests/static/state_tests"><code>tests/static/state_tests</code></a> sub-directory.</p> + + + + http://localhost:1313/writing_tests/post_mortems/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/writing_tests/post_mortems/ + <h1 id="post-mortems-of-missed-test-scenarios">Post-Mortems of Missed Test Scenarios</h1> <p>This page contains a collection of post-mortem analyses for test cases that were not initially identified by the testing process.</p> <p>The objective is to document and learn from missed scenarios β€” including those that were caught on the client side due to consensus issue, client developer raised issues, external reviewers, or external bug bounties β€” in order to improve test coverage and reduce the likelihood of similar omissions in the future.</p> + + + + http://localhost:1313/writing_tests/reference_specification/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/writing_tests/reference_specification/ + <h1 id="referencing-an-eip-spec-version">Referencing an EIP Spec Version</h1> <p>Tests that implement features from an Ethereum Improvement Proposal (<a href="https://github.com/ethereum/EIPs/tree/master/EIPS">ethereum/EIPs</a>) must define the EIP&rsquo;s markdown SHA digest within the test&rsquo;s Python module. This ensures our tests stay up-to-date with any changes to the EIP specifications.</p> <p>The <code>check_eip_versions</code> command-line utility automatically verifies that all EIP references in the codebase are current. It works by comparing the SHA specified in the test against the latest version in the ethereum/EIPs repository. This utility uses pytest to generate test cases for every module that includes &ldquo;eip&rdquo; in its path.</p> + + + + http://localhost:1313/writing_tests/test_markers/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/writing_tests/test_markers/ + <h1 id="test-markers">Test Markers</h1> <p>Test markers are used to categorize tests and to run specific subsets of tests. They are defined in the test files using the <code>pytest.mark</code> decorator.</p> <p>The examples below use <code>StateTestFiller</code> tests, but the same markers can also be applied to <code>BlockchainTestFiller</code> tests.</p> <h2 id="fork-markers">Fork Markers</h2> <p>These markers are used to specify the forks for which a test is valid.</p> <h3 id="pytestmarkvalid_fromfork_name"><code>@pytest.mark.valid_from(&quot;FORK_NAME&quot;)</code></h3> <p>:::pytest_plugins.forks.forks.ValidFrom</p> <h3 id="pytestmarkvalid_untilfork_name"><code>@pytest.mark.valid_until(&quot;FORK_NAME&quot;)</code></h3> <p>:::pytest_plugins.forks.forks.ValidUntil</p> <h3 id="pytestmarkvalid_atfork_name_1-fork_name_2-"><code>@pytest.mark.valid_at(&quot;FORK_NAME_1&quot;, &quot;FORK_NAME_2&quot;, ...)</code></h3> <p>:::pytest_plugins.forks.forks.ValidAt</p> <h3 id="pytestmarkvalid_at_transition_tofork_name"><code>@pytest.mark.valid_at_transition_to(&quot;FORK_NAME&quot;)</code></h3> <p>:::pytest_plugins.forks.forks.ValidAtTransitionTo</p> + + + + http://localhost:1313/writing_tests/tutorials/blockchain/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/writing_tests/tutorials/blockchain/ + <h1 id="blockchain-tests">Blockchain Tests</h1> <p>This tutorial teaches you to create a blockchain execution specification test. These tests verify that a blockchain, starting from a defined pre-state, will process given blocks and arrive at a defined post-state.</p> <h2 id="pre-requisites">Pre-requisites</h2> <p>Before proceeding with this tutorial, it is assumed that you have prior knowledge and experience with the following:</p> <ul> <li>Repository set-up, see <a href="../../getting_started/installation.md">installation</a>.and run an execution specification test as outlined in the .</li> <li>Able to run <code>fill</code>, see <a href="../../filling_tests/getting_started.md">Getting Started: Filling Tests</a>.</li> <li>Understand how to read a <a href="https://ethereum-tests.readthedocs.io/en/latest/test_filler/blockchain_filler.html">blockchain test</a>.</li> <li>Familiarity with <a href="https://docs.python.org/3/tutorial/">Python</a>.</li> <li>Understand how to write an execution spec <a href="./state_transition.md">state transition test</a>.</li> </ul> <h2 id="example-tests">Example Tests</h2> <p>In this tutorial we will go over [test_block_number] in <code>test_block_example.py</code>.</p> + + + + http://localhost:1313/writing_tests/tutorials/state_transition/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/writing_tests/tutorials/state_transition/ + <h1 id="state-transition-tests">State Transition Tests</h1> <p>This tutorial teaches you to create a state transition execution specification test using the Python Opcodes minilang for writing EVM bytecode. These tests verify that a starting pre-state will reach a specified post-state after executing a single transaction. In this example, we&rsquo;ll create a simple contract using bytecode and then interact with it through a transaction to verify the expected state changes.</p> <p>For an overview of different test types available, see <a href="../../writing_tests/types_of_tests.md">Types of Tests</a>.</p> + + + + http://localhost:1313/writing_tests/types_of_tests/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/writing_tests/types_of_tests/ + <h1 id="types-of-tests">Types of tests</h1> <p>There are currently three types of tests that can be produced by a test spec:</p> <ol> <li>State Tests</li> <li>Blockchain Tests</li> <li>Transaction Tests</li> </ol> <h2 id="state-tests">State Tests</h2> <h3 id="purpose">Purpose</h3> <p>Tests the effects of individual transactions (ideally a single one) that span a single block in a controlled environment.</p> <h3 id="use-cases">Use cases</h3> <ul> <li>Test a single opcode behavior.</li> <li>Verify opcode gas costs.</li> <li>Test interactions between multiple smart contracts.</li> <li>Test creation of smart contracts.</li> </ul> <p>!!! info</p> + + + + http://localhost:1313/writing_tests/verifying_changes/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/writing_tests/verifying_changes/ + <h1 id="verifying-changes">Verifying Changes</h1> <p>!!! warning &ldquo;Documentation Moved&rdquo; This documentation has been relocated to <a href="../getting_started/code_standards_details.md">Detailed Code Standards</a>. Please use the new location for the most up-to-date information.</p> + + + + http://localhost:1313/writing_tests/writing_a_new_test/ + Mon, 01 Jan 0001 00:00:00 +0000 + http://localhost:1313/writing_tests/writing_a_new_test/ + <h1 id="writing-a-new-test">Writing a New Test</h1> <h2 id="test-functions">Test Functions</h2> <p>Every test case is defined as a Python function that implements a single <code>StateTest</code> or <code>BlockchainTest</code> using the <code>state_test</code> or <code>blockchain_test</code> objects made available by the framework (<a href="./types_of_tests.md#deciding-on-a-test-type">learn how to decide on a test type</a>). Test cases, and the respective test modules, must fulfill the following requirements:</p> <table> <thead> <tr> <th>Requirement</th> <th>When</th> </tr> </thead> <tbody> <tr> <td>Be <a href="#specifying-which-forks-tests-are-valid-for">decorated with validity markers</a></td> <td>If the test case is not valid for all forks</td> </tr> <tr> <td>Use one of <code>state_test</code> or <code>blockchain_test</code> <a href="#the-state_test-and-blockchain_test-test-function-arguments">in its function arguments</a></td> <td>Always</td> </tr> <tr> <td>Call the <code>state_test</code> or <code>blockchain_test</code> in its test body</td> <td>Always</td> </tr> <tr> <td>Add a <a href="./reference_specification.md">reference version of the EIP spec</a> under test</td> <td>Test path contains <code>eip</code></td> </tr> </tbody> </table> <h3 id="specifying-which-forks-tests-are-valid-for">Specifying which Forks Tests are Valid For</h3> <p>Test cases can (and it most cases should) be decorated with one or more &ldquo;validity markers&rdquo; that define which the forks the test is valid for. This is achieved by applying:</p> + + + diff --git a/docs/public/writing_tests/main/index.html b/docs/public/writing_tests/main/index.html new file mode 100644 index 00000000000..e6f3d4c80d5 --- /dev/null +++ b/docs/public/writing_tests/main/index.html @@ -0,0 +1,123 @@ + + + + + + + + Writing Tests + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

Writing Tests

+
+ + +
+ +

The easiest way to get started is to use the interactive CLI:

+
uv run eest make test
+

and modify the generated test module to suit your needs.

+

For help deciding which test format to select, see Types of Tests, in particular Deciding on a Test Type

+

Key Resources

+ +

Please check that your code adheres to the repo’s coding standards and read the other pages in this section for more background and an explanation of how to implement state transition and blockchain tests.

+
+ +
+ +
+ +
+ + + + + + + + diff --git a/docs/public/writing_tests/page/1/index.html b/docs/public/writing_tests/page/1/index.html new file mode 100644 index 00000000000..87bcd24fcd0 --- /dev/null +++ b/docs/public/writing_tests/page/1/index.html @@ -0,0 +1,10 @@ + + + + http://localhost:1313/writing_tests/ + + + + + + diff --git a/docs/public/writing_tests/page/2/index.html b/docs/public/writing_tests/page/2/index.html new file mode 100644 index 00000000000..be1fd462deb --- /dev/null +++ b/docs/public/writing_tests/page/2/index.html @@ -0,0 +1,203 @@ + + + + + + + + Writing_tests + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +

Writing_tests

+ +
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+ + +
+ + + +
+ + + + + + + + + +
+ + + +
+ +
+ + + + + + + + diff --git a/docs/public/writing_tests/page/3/index.html b/docs/public/writing_tests/page/3/index.html new file mode 100644 index 00000000000..a89229f3184 --- /dev/null +++ b/docs/public/writing_tests/page/3/index.html @@ -0,0 +1,203 @@ + + + + + + + + Writing_tests + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +

Writing_tests

+ +
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+
+ + + + + + + + +

+
January 1, 0001
+ + + +
+ + +
+ + + +
+ + + + + + + + + +
+ + + +
+ +
+ + + + + + + + diff --git a/docs/public/writing_tests/page/4/index.html b/docs/public/writing_tests/page/4/index.html new file mode 100644 index 00000000000..04d2744c475 --- /dev/null +++ b/docs/public/writing_tests/page/4/index.html @@ -0,0 +1,139 @@ + + + + + + + + Writing_tests + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +

Writing_tests

+ +
+ + + + + + + + +

+
January 1, 0001
+ + + +
+ + +
+ + + +
+ + + + + + + +
+ + + +
+ +
+ + + + + + + + diff --git a/docs/public/writing_tests/porting_legacy_tests/index.html b/docs/public/writing_tests/porting_legacy_tests/index.html new file mode 100644 index 00000000000..2e6308cffaa --- /dev/null +++ b/docs/public/writing_tests/porting_legacy_tests/index.html @@ -0,0 +1,229 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

+
+ + +
+ +

A Guide to Porting Original Ethereum Tests to EEST

+

Background

+

EEST is the successor to ethereum/tests (aka “original tests”), a repository that defined EVM test cases from the Frontier phase up to and including The Merge. These test cases are specified as YAML (and occasionally JSON) files in the ./src/ sub-directory. JSON test fixtures, which are fully-populated tests that can be executed against clients, are generated using ethereum/retesteth. These JSON artifacts are regenerated when needed and added to the repository, typically in the tests/static/state_tests sub-directory.

+

From Shanghai onward, new test cases β€” especially for new features introduced in hard forksβ€”are defined in Python within EEST. While the existing test cases remain important for client testing, porting ethereum/tests to EEST will help maintain and generate tests for newer forks. This also ensures feature parity, as client teams will only need to obtain test fixture releases from one source.

+

While automating the conversion of the remaining YAML (or JSON) test cases to Python is possible, manually porting individual test cases offers several benefits:

+
    +
  • Reducing the number of test cases by combining multiple YAML (or JSON) cases into a single Python test function using parametrization.
  • +
  • Potentially improving coverage by parametrizing the Python version.
  • +
  • Producing higher quality code and documentation, which are typically clearer than an automated conversion.
  • +
  • Ensuring better organization of tests within the ./tests folder of execution-spec-tests by fork and EIP.
  • +
+

Porting an original test

+
    +
  1. +

    Select one or more test cases from ./tests/static/state_tests/ to port and create an issue in this repository AND comment on this tracker issue.

    +
  2. +
  3. +

    Add a new test in the appropriate fork folder, following the guidelines for choosing a test type.

    +
  4. +
  5. +

    Submit a PR with the ported tests:

    +
      +
    1. +

      Add the list of ported files using python marker to the head of your python test.

      +

      Example:

      +
       @pytest.mark.ported_from(
      +[
      +    "https://github.com/ethereum/tests/blob/v13.3/src/GeneralStateTestsFiller/stCreateTest/CREATE_ContractSuicideDuringInit_ThenStoreThenReturnFiller.json",
      +    "https://github.com/ethereum/tests/blob/v13.3/src/GeneralStateTestsFiller/stCreateTest/CREATE_ContractSuicideDuringInit_WithValueFiller.json",
      +],
      +pr=["https://github.com/ethereum/execution-spec-tests/pull/1871"],
      +# coverage_missed_reason="Converting solidity code result in following opcode not being used:",
      +

      Replace test names with your chosen tests and PR number.

      +

      Uncomment coverage_missed_reason when all the missed coverage lines are approved, usually some opcodes end up not used after translating test logic from lllc, yul.

      +

      But sometimes missed coverage line could hint that you forgot to account important test logic.

      +

      If no coverage is missed, you are good!

      +
    2. +
    3. +

      Remove the ported files from .tests/static/state_tests in your PR

      +
    4. +
    +
  6. +
+
+

See also: πŸ“„ Getting started with EEST.

+

Filling tests

+

EEST uses pytest to run tests against EELS (an EVM implementation for testing). This process is known as “filling” and verifies the assertions in your tests. You can use the fill CLI for this. For example, see how to fill the PUSH opcode.

+
uv run fill tests/frontier/opcodes/test_push.py
+

See also: πŸ“„ Documentation for the fill command.

+
+

If the tests can’t currently be filled, please explain the issue (feel free to also open a Discussion).

+

Debugging tests

+

By default, EVM logs are stored in the logs folder at the repository root. You can check the output folder to review transaction results. If needed, review a previous PR that ported tests (e.g., the PR porting the PUSH opcode, and other port PRs).

+

Test coverage

+

It’s crucial that ported tests maintain coverage parity with original tests. This ensures that no critical functions are left untested and prevents the introduction of bugs. A CI workflow automatically checks for coverage.

+

If coverage action fails (See: πŸ“„ An example of a failing test coverage), it’s recommended to run the coverage action locally (see: πŸ“„ How to run GitHub actions locally), which should generate a evmtest_coverage directory:

+
❯ tree evmtest_coverage  -L 2
+evmtest_coverage
+└── coverage
+    β”œβ”€β”€ BASE
+    β”œβ”€β”€ BASE_TESTS
+    β”œβ”€β”€ coverage_BASE.lcov
+    β”œβ”€β”€ coverage_PATCH.lcov
+    β”œβ”€β”€ DIFF
+    β”œβ”€β”€ difflog.txt
+    β”œβ”€β”€ PATCH
+    └── PATCH_TESTS
+

Here BASEis original tests, PATCH is the ported test, and DIFF is the coverage difference on EVMONE. Open evmtest_coverage/coverage/DIFF/index.html in browser:

+

Annotated coverage

+ + + + + + + + + + + + + + + + + + + + + + + + + +
LabelDescription
LBCLost base coverage: Code that was tested before, but is untested now.
UBCUncovered baseline code: Code that was untested before and untested now.
GBCGained baseline coverage: Code that was untested before, but is tested now.
CBCCovered baseline code: Code that was tested before and is tested now.
+

Follow the hyperlinks for lost base coverage (LBC) to address coverage gaps. Here is an example coverage loss:

+

Missing original coverage

+
+

Lost line coverage from a coverage report. In this case, caused by a missing invocation of CALLDATALOAD.

+

!!! note “Expected coverage loss”

+
EEST uses [pytest](https://docs.pytest.org/en/stable/), a popular Python testing framework, to help orchestrate testing Ethereum specifications, while _original tests_ relied on large, static contracts and the EVM to handle much of the execution. This difference can lead to coverage gaps. EEST favors dynamic contract creation for each test vector, while _original tests_ preferred a single static contract with multiple test vectors determined by transaction input data.
+
+It's important to note that coverage helps identify missing test paths. If you believe the coverage loss is due to differences in "setup" code between frameworks and doesn't impact the feature you're testing, explain this in your PR. A team member can help with the review.
+
+For example, review the [discussion in this PR] to see an example of why and how coverage loss can occur.(https://github.com/ethereum/execution-spec-tests/pull/975#issuecomment-2528792289)
+
+

Resolving Coverage Gaps from Yul Compilation

+

When porting tests from ethereum/tests, you may encounter coverage gaps that are false positives. This commonly occurs because:

+
    +
  • Original tests often used Yul to define smart contracts, and solc compilation introduces additional opcodes that aren’t specifically under test
  • +
  • EEST ports use the explicit EEST Opcode mini-language, which is more precise in opcode definition
  • +
+

If coverage analysis shows missing opcodes that were only present due to Yul compilation artifacts (not the actual feature being tested), this can be resolved during PR review by adding the coverage_missed_reason parameter:

+
@pytest.mark.ported_from(
+    ["path/to/original_test.json"],
+    coverage_missed_reason="Missing opcodes are Yul compilation artifacts, not part of tested feature"
+)
+

!!! note “Add coverage_missed_reason only after PR review” +Only add coverage_missed_reason after PR review determines the coverage gap is acceptable, never preemptively. This helps maintain test coverage integrity while accounting for legitimate differences between Yul-based and EEST opcode-based implementations.

+
+ +
+ +
+ +
+ + + + + + + + diff --git a/docs/public/writing_tests/post_mortems/index.html b/docs/public/writing_tests/post_mortems/index.html new file mode 100644 index 00000000000..536dfc20b2f --- /dev/null +++ b/docs/public/writing_tests/post_mortems/index.html @@ -0,0 +1,146 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

+
+ + +
+ +

Post-Mortems of Missed Test Scenarios

+

This page contains a collection of post-mortem analyses for test cases that were not initially identified by the testing process.

+

The objective is to document and learn from missed scenarios β€” including those that were caught on the client side due to consensus issue, client developer raised issues, external reviewers, or external bug bounties β€” in order to improve test coverage and reduce the likelihood of similar omissions in the future.

+

Each entry must include an explanation of why the test case was missed plus the changes that were implemented in documentation or framework to improve the testing process.

+

List

+

TEMPLATE

+

Date - Title - Fork

+

Description

+

Provide a concise summary of the issue, how it was discovered, emphasizing the how it relates to the specifications and testing.

+

Example:

+
+

A consensus-breaking issue was found during the bug-bounty phase of the Pectra fork specifically in the EIP-2537, which involved calling the BLS pairing precompile using two special points: the infinity point and a point that is outside of the BLS12-381 curve. +The specification correctly specified the behavior of the precompile when one of these inputs was used, but it did not specify the behavior of the combined input.

+

Root Cause Analysis

+

Explain why this scenario was not covered by the test suite. Consider whether it was due to ambiguous specification wording, gaps in test generation logic, overlooked edge cases, or incorrect assumptions about expected behavior.

+

Consider prompting questions:

+
    +
  • Was the behavior implied but not explicitly stated in the specification?
  • +
  • Was the area considered low-risk or assumed covered elsewhere?
  • +
  • Were there limitations in the current test generation tools or processes?
  • +
  • Was there any different type of testing that could have caught the issue at an earlier stage? (Fuzzing, property based testing)
  • +
+

Steps Taken To Avoid Recurrence

+

List the actions taken to reduce the chance of this type of miss happening again. E.g. procedure changes, checklist updates, review practices, framework improvements.

+

Implemented Test Case

+

IDs of the tests added that now cover the missed scenario and link to the documentation page where they are included.

+

Example:

+ +

Framework/Documentation Changes

+

Note any modifications that were introduced in the framework and/or documentation to prevent similar misses.

+

Example:

+
    +
  • Updated EIP checklist to include testing combinations of interesting points related to the elliptic-curve under test, and all combinations between them.
  • +
+
+ +
+ +
+ +
+ + + + + + + + diff --git a/docs/public/writing_tests/reference_specification/index.html b/docs/public/writing_tests/reference_specification/index.html new file mode 100644 index 00000000000..0f9933fc0da --- /dev/null +++ b/docs/public/writing_tests/reference_specification/index.html @@ -0,0 +1,175 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

+
+ + +
+ +

Referencing an EIP Spec Version

+

Tests that implement features from an Ethereum Improvement Proposal (ethereum/EIPs) must define the EIP’s markdown SHA digest within the test’s Python module. This ensures our tests stay up-to-date with any changes to the EIP specifications.

+

The check_eip_versions command-line utility automatically verifies that all EIP references in the codebase are current. It works by comparing the SHA specified in the test against the latest version in the ethereum/EIPs repository. This utility uses pytest to generate test cases for every module that includes “eip” in its path.

+
+ ![Test framework summary for a failing EIP spec version test](./img/eip_reference_spec_console_output.png){ width=auto align=center} +
+

!!! note “The SHA digest value is provided in the failure message of the corresponding test”

+
<figure markdown>  <!-- markdownlint-disable MD033 (MD033=no-inline-html) -->
+  ![EIP spec version test fail](./img/eip_reference_spec_console_output_fail.png){ width=auto align=center}
+</figure>
+
+

!!! info “Understanding and Retrieving the EIP Markdown’s SHA Digest”

+
The SHA value is the output from git's `hash-object` command, for example:
+
+```console
+git clone git@github.com:ethereum/EIPs
+git hash-object EIPS/EIPS/eip-3651.md
+# output: d94c694c6f12291bb6626669c3e8587eef3adff1
+```
+
+and can be retrieved from the remote repo via the Github API on the command-line as following:
+
+```console
+sudo apt install jq
+curl -s -H "Accept: application/vnd.github.v3+json" \
+https://api.github.com/repos/ethereum/EIPs/contents/EIPS/eip-3651.md |\
+jq -r '.sha'
+# output: d94c694c6f12291bb6626669c3e8587eef3adff1
+```
+
+

How to Add a Spec Version Check

+

This check accomplished by adding the following two global variables anywhere in the Python source file:

+ + + + + + + + + + + + + + + + + +
Variable NameExplanation
REFERENCE_SPEC_GIT_PATHThe relative path of the EIP markdown file in the ethereum/EIPs repository, e.g. “EIPS/eip-1234.md
REFERENCE_SPEC_VERSIONThe SHA hash of the latest version of the file retrieved from the Github API:
https://api.github.com/repos/ethereum/EIPs/contents/EIPS/eip-<EIP Number>.md
+

Running the check_eip_versions Command Locally

+

A Github Personal Access Token (PAT) is required to avoid rate-limiting issues when using the Github API. The token can be specified via an environment variable or via the command-line. For example, the Github CLI can be used to obtain a token:

+
uv run check_eip_versions --github-token=$(gh auth token)
+

or a PAT can be created at: https://github.com/settings/personal-access-tokens/new.

+

By default, only tests up to and including the current fork under development will be checked. This is controlled by the UNTIL_FORK setting in the src/config/check_eip_versions.py configuration file. You can also pass a specific test path to limit the scope:

+
uv run check_eip_versions --github-token=$(gh auth token) tests/shanghai/eip3651_warm_coinbase/
+

This would only check EIP versions for the EIP-3651 tests in the shanghai/eip3651_warm_coinbase sub-directory.

+

Automated Checks via GitHub Actions

+

The repository includes a GitHub Actions workflow that automatically runs check_eip_versions on a daily schedule. If any outdated EIP references are detected, the workflow creates an issue in the repository with details about which references need to be updated.

+

This workflow uses GitHub’s built-in token for authentication, so there’s no need to configure personal access tokens for the automated checks. The issue will include links to the relevant workflow run and details about which tests need updating.

+

Example

+

Here is an example from ./tests/shanghai/eip3651_warm_coinbase/test_warm_coinbase.py:

+
REFERENCE_SPEC_GIT_PATH = "EIPS/eip-3651.md"
+REFERENCE_SPEC_VERSION = "d94c694c6f12291bb6626669c3e8587eef3adff1"
+

The SHA digest was retrieved from here.

+
+ +
+ +
+ +
+ + + + + + + + diff --git a/docs/public/writing_tests/test_markers/index.html b/docs/public/writing_tests/test_markers/index.html new file mode 100644 index 00000000000..5e49edb06d2 --- /dev/null +++ b/docs/public/writing_tests/test_markers/index.html @@ -0,0 +1,362 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

+
+ + +
+ +

Test Markers

+

Test markers are used to categorize tests and to run specific subsets of tests. They are defined in the test files using the pytest.mark decorator.

+

The examples below use StateTestFiller tests, but the same markers can also be applied to BlockchainTestFiller tests.

+

Fork Markers

+

These markers are used to specify the forks for which a test is valid.

+

@pytest.mark.valid_from("FORK_NAME")

+

:::pytest_plugins.forks.forks.ValidFrom

+

@pytest.mark.valid_until("FORK_NAME")

+

:::pytest_plugins.forks.forks.ValidUntil

+

@pytest.mark.valid_at("FORK_NAME_1", "FORK_NAME_2", ...)

+

:::pytest_plugins.forks.forks.ValidAt

+

@pytest.mark.valid_at_transition_to("FORK_NAME")

+

:::pytest_plugins.forks.forks.ValidAtTransitionTo

+

Fork Covariant Markers

+

These markers are used in conjunction with the fork validity markers to automatically parameterize tests with values that are valid for the fork being tested.

+

@pytest.mark.with_all_tx_types

+

This marker is used to automatically parameterize a test with all transaction types that are valid for the fork being tested.

+
import pytest
+
+from ethereum_test_tools import Alloc, StateTestFiller
+
+@pytest.mark.with_all_tx_types
+@pytest.mark.valid_from("Berlin")
+def test_something_with_all_tx_types(
+    state_test: StateTestFiller, 
+    pre: Alloc,
+    tx_type: int
+):
+    pass
+

In this example, the test will be parameterized for parameter tx_type with values [0, 1] for fork Berlin, but with values [0, 1, 2] for fork London (because of EIP-1559).

+

@pytest.mark.with_all_contract_creating_tx_types

+

This marker is used to automatically parameterize a test with all contract creating transaction types that are valid for the fork being tested.

+

This marker only differs from pytest.mark.with_all_tx_types in that it does not include transaction type 3 (Blob Transaction type) on fork Cancun and after.

+

@pytest.mark.with_all_precompiles

+

This marker is used to automatically parameterize a test with all precompiles that are valid for the fork being tested.

+
import pytest
+
+from ethereum_test_tools import Alloc, StateTestFiller
+
+@pytest.mark.with_all_precompiles
+@pytest.mark.valid_from("Shanghai")
+def test_something_with_all_precompiles(
+    state_test: StateTestFiller, 
+    pre: Alloc,
+    precompile: int,
+):
+    pass
+

In this example, the test will be parameterized for parameter precompile with values [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] for fork Shanghai, but with values [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10] for fork Cancun which introduced the point evaluation precompile defined in EIP-4844.

+

@pytest.mark.with_all_evm_code_types

+

This marker is used to automatically parameterize a test with all EVM code types that are valid for the fork being tested.

+
import pytest
+
+from ethereum_test_tools import Alloc, StateTestFiller
+
+@pytest.mark.with_all_evm_code_types
+@pytest.mark.valid_from("Frontier")
+def test_something_with_all_evm_code_types(
+    state_test: StateTestFiller,     
+    pre: Alloc,
+):
+    pass
+

In this example, the test will be parameterized for parameter evm_code_type only with value [EVMCodeType.LEGACY] starting on fork Frontier, and eventually it will be parametrized with with values [EVMCodeType.LEGACY, EVMCodeType.EOF_V1] on the EOF activation fork.

+

In all calls to pre.deploy_contract, if the code parameter is Bytecode type, and evm_code_type==EVMCodeType.EOF_V1, the bytecode will be automatically wrapped in an EOF V1 container.

+

Code wrapping might fail in the following circumstances:

+
    +
  • The code contains invalid EOF V1 opcodes.
  • +
  • The code does not end with a valid EOF V1 terminating opcode (such as Op.STOP or Op.REVERT or Op.RETURN).
  • +
+

In the case where the code wrapping fails, evm_code_type can be added as a parameter to the test and the bytecode can be dynamically modified to be compatible with the EOF V1 container.

+

One thing to note is that evm_code_type is not necessary to be added as a parameter to the test because the pre: Alloc fixture automatically consumes this fixture, and therefore it only needs to be added to the test signature if the test’s logic needs it.

+
import pytest
+
+from ethereum_test_tools import Alloc, StateTestFiller
+from ethereum_test_vm import EVMCodeType
+from ethereum_test_vm import Opcodes as Op
+
+@pytest.mark.with_all_evm_code_types
+@pytest.mark.valid_from("Frontier")
+def test_something_with_all_evm_code_types(
+    state_test: StateTestFiller,
+    pre: Alloc,
+    evm_code_type: EVMCodeType
+):
+    code = Op.SSTORE(1, 1)
+    if evm_code_type == EVMCodeType.EOF_V1:
+        # Modify the bytecode to be compatible with EOF V1 container
+        code += Op.STOP
+    pre.deploy_contract(code)
+    ...
+

@pytest.mark.with_all_call_opcodes

+

This marker is used to automatically parameterize a test with all EVM call opcodes that are valid for the fork being tested.

+
import pytest
+
+from ethereum_test_tools import Alloc, StateTestFiller
+from ethereum_test_vm import Opcodes as Op
+
+@pytest.mark.with_all_call_opcodes
+@pytest.mark.valid_from("Frontier")
+def test_something_with_all_call_opcodes(
+    state_test: StateTestFiller,
+    pre: Alloc,
+    call_opcode: Op
+):
+    pass
+

In this example, the test will be parametrized for parameter call_opcode with values [Op.CALL, Op.CALLCODE] starting on fork Frontier, [Op.CALL, Op.CALLCODE, Op.DELEGATECALL] on fork Homestead, [Op.CALL, Op.CALLCODE, Op.DELEGATECALL, Op.STATICCALL] on fork Byzantium, and eventually it will be parametrized with with values [Op.CALL, Op.CALLCODE, Op.DELEGATECALL, Op.STATICCALL, Op.EXTCALL, Op.EXTSTATICCALL, Op.EXTDELEGATECALL] on the EOF activation fork.

+

Parameter evm_code_type will also be parametrized with the correct EVM code type for the opcode under test.

+

@pytest.mark.with_all_create_opcodes

+

This marker is used to automatically parameterize a test with all EVM create opcodes that are valid for the fork being tested.

+
import pytest
+
+from ethereum_test_tools import Alloc, StateTestFiller
+from ethereum_test_vm import Opcodes as Op
+
+@pytest.mark.with_all_create_opcodes
+@pytest.mark.valid_from("Frontier")
+def test_something_with_all_create_opcodes(
+    state_test: StateTestFiller,
+    pre: Alloc,
+    create_opcode: Op
+):
+    pass
+

In this example, the test will be parametrized for parameter create_opcode with values [Op.CREATE] starting on fork Frontier, [Op.CREATE, Op.CREATE2] starting on fork Constantinople, and eventually it will be parametrized with with values [Op.CREATE, Op.CREATE2, Op.EOFCREATE] on the EOF activation fork.

+

Parameter evm_code_type will also be parametrized with the correct EVM code type for the opcode under test.

+

@pytest.mark.with_all_system_contracts

+

This marker is used to automatically parameterize a test with all system contracts that are valid for the fork being tested.

+
import pytest
+
+from ethereum_test_tools import Alloc, StateTestFiller
+from ethereum_test_base_types import Address
+
+@pytest.mark.with_all_system_contracts
+@pytest.mark.valid_from("Cancun")
+def test_something_with_all_system_contracts(
+    state_test: StateTestFiller,
+    pre: Alloc,
+    system_contract: Address,
+):
+    pass
+

In this example, the test will be parameterized for parameter system_contract with value [0x000F3DF6D732807EF1319FB7B8BB8522D0BEAC02] for fork Cancun.

+

Covariant Marker Keyword Arguments

+

All fork covariant markers accept the following keyword arguments:

+

selector

+

A lambda function that can be used to filter the fork covariant values that are valid for this specific test.

+
import pytest
+
+from ethereum_test_tools import Alloc, StateTestFiller
+
+@pytest.mark.with_all_tx_types(selector=lambda tx_type: tx_type != 2)
+@pytest.mark.valid_from("London")
+def test_something_with_all_tx_types(
+    state_test: StateTestFiller, 
+    pre: Alloc,
+    tx_type: int
+):
+    pass
+

Ideally, the lambda function should be used to explicitly filter out values that are not compatible with the test (exclusive filter), rather than explicitly selecting values (inclusive filter), as the parametrized values might change with future forks.

+

marks

+

A marker, list of markers, or a lambda function that can be used to add additional markers to the test.

+
import pytest
+
+@pytest.mark.with_all_tx_types(
+    marks=lambda tx_type: pytest.mark.skip("incompatible") if tx_type == 1 else None,
+)
+@pytest.mark.valid_from("London")
+def test_something_with_all_tx_types_but_skip_type_1(state_test_only, tx_type):
+    assert tx_type != 1
+    ...
+

In this example, the test will be skipped if tx_type is equal to 1 by returning a pytest.mark.skip marker, and return None otherwise.

+

@pytest.mark.parametrize_by_fork

+

A test can be dynamically parametrized based on the fork using the parametrize_by_fork marker.

+

This marker takes two positional arguments:

+
    +
  • argnames: A list of parameter names that will be parametrized using the custom function.
  • +
  • fn: A function that takes the fork as parameter and returns a list of values that will be used to parametrize the test at that specific fork.
  • +
+

And one keyword argument:

+
    +
  • marks (optional): A marker, list of markers, or a lambda function that can be used to add additional markers to the generated tests.
  • +
+

The marked test function will be parametrized by the values returned by the fn function for each fork.

+

If the parameters that are being parametrized is only a single parameter, the return value of fn should be a list of values for that parameter.

+

If the parameters that are being parametrized are multiple, the return value of fn should be a list of tuples/lists, where each tuple contains the values for each parameter.

+
import pytest
+
+def covariant_function(fork):
+    return [[1, 2], [3, 4]] if fork.name() == "Paris" else [[4, 5], [5, 6], [6, 7]]
+
+@pytest.mark.parametrize_by_fork("test_parameter,test_parameter_2", covariant_function)
+@pytest.mark.valid_from("Paris")
+@pytest.mark.valid_until("Shanghai")
+def test_case(state_test_only, test_parameter, test_parameter_2):
+    pass
+

In this example, the test will be parametrized with the values [1, 2] and [3, 4] for the Paris fork, with values 1 and 3 being assigned to test_parameter and 2 and 4 being assigned to test_parameter_2. For the Shanghai fork, the test will be parametrized with the values [4, 5], [5, 6], and [6, 7]. Therefore, more test cases will be generated for the Shanghai fork.

+

If the parameters that are being parametrized is only a single parameter, the return value of fn should be a list of values for that parameter.

+

If the parameters that are being parametrized are multiple, the return value of fn should be a list of tuples/lists, where each tuple contains the values for each parameter.

+

The function can also return a list of pytest.param objects, which allows for additional markers and test IDs to be added to the test.

+

Fill/Execute Markers

+

These markers are used to apply different markers to a test depending on whether it is being filled or executed.

+

@pytest.mark.fill

+

This marker is used to apply markers to a test when it is being filled.

+
import pytest
+
+from ethereum_test_tools import Alloc, StateTestFiller
+
+@pytest.mark.fill(pytest.mark.skip(reason="Only for execution"))
+def test_something(
+    state_test: StateTestFiller, 
+    pre: Alloc
+):
+    pass
+

In this example, the test will be skipped when it is being filled.

+

@pytest.mark.execute

+

This marker is used to apply markers to a test when it is being executed.

+
import pytest
+
+from ethereum_test_tools import Alloc, StateTestFiller
+
+@pytest.mark.execute(pytest.mark.xfail(reason="Depends on block context"))
+def test_something(
+    state_test: StateTestFiller, 
+    pre: Alloc
+):
+    pass
+

In this example, the test will be marked as expected to fail when it is being executed, which is particularly useful so that the test is still executed but does not fail the test run.

+

Other Markers

+

@pytest.mark.slow

+

This marker is used to mark tests that are slow to run. These tests are not run during tox checks, and are only run when a release is being prepared.

+

@pytest.mark.pre_alloc_modify

+

This marker is used to mark tests that modify the pre-alloc in a way that would be impractical to reproduce in a real-world scenario.

+

Examples of this include:

+
    +
  • Modifying the pre-alloc to have a balance of 2^256 - 1.
  • +
  • Address collisions that would require hash collisions.
  • +
+

@pytest.mark.skip()

+

This marker can be used to skip a test.

+
import pytest
+
+from ethereum_test_tools import Alloc, StateTestFiller
+
+@pytest.mark.skip(reason="Not implemented")
+def test_something(state_test: StateTestFiller, pre: Alloc):
+    pass
+

@pytest.mark.xfail()

+

This marker can be used to mark a test as expected to fail.

+
import pytest
+
+from ethereum_test_tools import Alloc, StateTestFiller
+
+@pytest.mark.xfail(reason="EVM binary doesn't support this opcode")
+def test_something(state_test: StateTestFiller, pre: Alloc):
+    pass
+
+ +
+ +
+ +
+ + + + + + + + diff --git a/docs/public/writing_tests/tutorials/blockchain/index.html b/docs/public/writing_tests/tutorials/blockchain/index.html new file mode 100644 index 00000000000..fa6086729a1 --- /dev/null +++ b/docs/public/writing_tests/tutorials/blockchain/index.html @@ -0,0 +1,202 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

+
+ + +
+ +

Blockchain Tests

+

This tutorial teaches you to create a blockchain execution specification test. These tests verify that a blockchain, starting from a defined pre-state, will process given blocks and arrive at a defined post-state.

+

Pre-requisites

+

Before proceeding with this tutorial, it is assumed that you have prior knowledge and experience with the following:

+ +

Example Tests

+

In this tutorial we will go over [test_block_number] in test_block_example.py.

+

It is assumed you have already gone through the state transition test tutorial. Only new concepts will be discussed.

+

Smart Contract

+

A smart contract is defined that is called by each transaction in the test. It stores a pointer to storage at storage[0]. When it is called storage cell 0 gets the current block number, and the pointer is incremented to the next value.

+
contract_addr: Account(
+    balance=1000000000000000000000,
+    code=code,
+    storage={
+        0x00: 0x01,
+    },
+),
+

Transaction Generator

+

The transactions used in this test are nearly identical. Their only difference is the nonce value which needs to be incremented.

+
def tx_generator():
+    nonce = 0  # Initial value
+    while True:
+        tx = Transaction(
+            ty=0x0,
+            chain_id=0x0,
+            nonce=nonce,
+            to=contractAddr,
+            gas_limit=500000,
+            gas_price=10,
+        )
+        nonce = nonce + 1
+        yield tx
+
+tx_generator = tx_generator()
+

This looks like an infinite loop but it isn’t because this is a generator function. When generator encounters the yield keyword it returns the value and stops execution, keeping a copy of all the local variables, until it is called again. Hence infinite loops inside a generator are not a problem as long as they include yield. This code section is responsible for creating the Transaction object and incrementing the nonce.

+

Every time the function tx_generator() is called, it returns a new generator with a nonce of zero. To increment the nonce we need to use the same generator. We assign this generator to tx_generator.

+

Blocks

+

Each integer in the tx_per_block array is the number of transactions in a block. The genesis block is block 0 (no transactions). It follows that we have 2 transactions in block 1, 0 in block two, 4 in block 3, …, and 50 in block 9.

+
tx_per_block = [2, 0, 4, 8, 0, 0, 20, 1, 50]
+

The code section that creates the blocks is a bit complex in this test. For some simpler definitions of Block creation you can browse tests within test_withdrawals.py.

+
blocks = map(
+    lambda len: Block(
+        txs=list(map(lambda x: next(tx_generator), range(len)))
+    ),
+    tx_per_block,
+)
+

We use lambda notation to specify short functions. In this case, the function doesn’t actually care about its input, it just returns the next transaction from the generator.

+
lambda x: next(tx_generator)
+

Python uses range(n) to create a list of numbers from 0 to n-1. Among other things, it’s a simple way to create a list of n values.

+
range(len)
+

The map function runs the function (the first parameter) on every element of the list (the second parameter). Putting together what we know, it means that it runs next(tx_generator) len times, giving us len transactions. We then use list to turn the transactions into a list that we can provide as the txs parameter to the Block constructor.

+
list(map(lambda x: next(tx_generator), range(len)))
+

The outer lambda function takes an integer, len, and creates a Block object with len transactions. This function is then run on every value of tx_per_block to generate the blocks.

+
blocks = map(
+    lambda len: Block(
+        txs=list of len transactions
+    ),
+    tx_per_block,
+)
+

For example, if we had tx_per_block = [0,2,4], we’d get this result:

+
blocks = [
+    Blocks(txs=[]),
+    Blocks(txs=[next(tx_generator), next(tx_generator)]),
+    Blocks(txs=[next(tx_generator), next(tx_generator), next(tx_generator), next(tx_generator)])        
+]
+

Post State

+

Recall that storage slot 0 retains the value of the next slot that the block number is written into. It starts at one and is incremented after each transaction. Hence it’s the total number of transactions plus 1.

+
storage = {0: sum(tx_per_block) + 1}
+

For every block and transaction within the block, we write the block number and increment the next slot number in storage slot 0. As Python lists are 0 indexed, we must increment the block number by 1.

+
next_slot = 1
+for blocknum in range(len(tx_per_block)):
+    for _ in range(tx_per_block[blocknum]):
+        storage[next_slot] = blocknum + 1
+        next_slot = next_slot + 1
+

Now that the expected storage values are calculated, the post state can be defined and yielded within the BlockchainTest, synonymous to the state test example.

+
post = {contract_addr: Account(storage=storage)}
+
+yield BlockchainTest(
+    genesis_environment=env,
+    pre=pre,
+    blocks=blocks,
+    post=post,
+)
+

Note that because of the yield we could have multiple tests under the same name.

+

Conclusion

+

At this point you should be able to write blockchain tests.

+
+ +
+ +
+ +
+ + + + + + + + diff --git a/docs/public/writing_tests/tutorials/state_transition/index.html b/docs/public/writing_tests/tutorials/state_transition/index.html new file mode 100644 index 00000000000..a0b099c2fc2 --- /dev/null +++ b/docs/public/writing_tests/tutorials/state_transition/index.html @@ -0,0 +1,229 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

+
+ + +
+ +

State Transition Tests

+

This tutorial teaches you to create a state transition execution specification test using the Python Opcodes minilang for writing EVM bytecode. These tests verify that a starting pre-state will reach a specified post-state after executing a single transaction. In this example, we’ll create a simple contract using bytecode and then interact with it through a transaction to verify the expected state changes.

+

For an overview of different test types available, see Types of Tests.

+

Pre-requisites

+

This tutorial will require some prior knowledge and experience with the following:

+ +

Building a State Test

+

The most effective method of learning how to write tests is to study a straightforward example. In this tutorial we will build a simple state test that deploys a contract with bytecode and verifies its execution.

+

Complete Test Example

+

We’ll examine a simple test that uses the Python Opcodes minilang to write EVM bytecode. This example is based on the CHAINID opcode test from tests/istanbul/eip1344_chainid/test_chainid.py.

+

Let’s examine each section.

+
"""State test tutorial demonstrating contract deployment and interaction."""
+

In Python, multi-line strings are denoted using """. As a convention, a file’s purpose is often described in the opening string of the file.

+
import pytest
+
+from ethereum_test_tools import Account, Alloc, Environment, StateTestFiller, Transaction
+from ethereum_test_tools.vm.opcode import Opcodes as Op
+

In this snippet the required constants, types and helper functions are imported from ethereum_test_tools. The Opcodes class (aliased as Op) provides the Python minilang for writing EVM bytecode. We will go over these as we come across them.

+
@pytest.mark.valid_from("Istanbul")
+

In Python this kind of definition is called a decorator. +It modifies the action of the function after it. +In this case, the decorator is a custom pytest mark defined by the execution-specs-test framework that specifies that the test is valid for the Istanbul fork and all forks after it. The framework will then fill this test case for all forks in the fork range specified by the command-line arguments.

+

For more information about test markers and fork validity, see Test Markers.

+

!!! info “Filling the test” +To fill this test for all the specified forks, we can specify pytest’s -k flag that filters test cases by keyword expression:

+
```console
+fill -k test_state_test_example
+```
+
+and to fill it for a specific fork range, we can provide the `--from` and `--until` command-line arguments:
+
+```console
+fill -k test_state_test_example --from London --until Paris
+```
+
+
def test_state_test_example(state_test: StateTestFiller, pre: Alloc):
+    """Test state transition using Opcodes minilang bytecode."""
+

This is the format of a Python function. +It starts with def <function name>(<parameters>):, and then has indented code for the function. +The function definition ends when there is a line that is no longer indented. As with files, by convention functions start with a string that explains what the function does.

+

The function parameters (state_test and pre) are pytest fixtures provided by the execution-spec-tests framework. Pytest fixtures are a powerful dependency injection mechanism that automatically provide objects to your test functions.

+

The state_test fixture is a callable that you must include in state test function arguments. When called at the end of your test function with the environment, pre-state, transaction, and expected post-state, it generates the actual test fixtures. This callable is a wrapper around the StateTest class.

+

The pre fixture provides an Alloc object that manages the pre-state allocation for your test. It offers methods like fund_eoa() and deploy_contract() that automatically generate unique addresses and add accounts to the blockchain state that will exist before your transaction executes. The fixture handles address generation and ensures no conflicts occur.

+
    env = Environment(number=1)
+

This line specifies that env is an [Environment][ethereum_test_types.Environment] object. In this example, we only override the block number to 1, leaving all other values at their defaults. It’s recommended to use default values whenever possible and only specify custom values when required for your specific test scenario. (For all available fields, see the pydantic model fields in the source code of [Environment][ethereum_test_types.Environment] and EnvironmentGeneric from which Environment inherits.)

+

Pre State

+

For every test we need to define the pre-state requirements, so we are certain of what is on the “blockchain” before the transaction is executed. The pre fixture provides an Alloc object with methods to create accounts that are automatically added to the pre-state.

+

In this example we are using the deploy_contract method to deploy a contract to some address available in the pre-state.

+
    contract_address = pre.deploy_contract(
+        code=Op.PUSH1(0x03) + Op.PUSH1(0x00) + Op.SSTORE + Op.STOP
+    )
+

Specifically we deploy a contract written with Opcodes minilang code that stores the value 0x03 at storage slot 0x00. The code consists of:

+
    +
  • PUSH1(0x03): Push the value 3 onto the stack.
  • +
  • PUSH1(0x00): Push the storage key 0 onto the stack.
  • +
  • SSTORE: Store the value at the specified key.
  • +
  • STOP: End execution.
  • +
+

As the return value of the deploy_contract method, we get the address where the contract was deployed. This address is stored in the contract_address variable, which will later be used as the target of our transaction.

+

You can also specify additional parameters for the contract if needed:

+
    +
  • balance parameter to set the contract’s initial balance (though often not necessary for state test contracts)
  • +
  • storage parameter to set initial storage values (though in this example we don’t need initial storage since our contract will set it through the SSTORE opcode)
  • +
+

You can combine opcodes using the + operator to create more complex bytecode sequences.

+

Generally for execution spec tests the SSTORE instruction acts as a high-level assertion method to check pre to post-state changes. The test filler achieves this by verifying that the correct value is held within post-state storage, hence we can validate that the bytecode has run successfully.

+

Next, we need to create an account that will send the transaction to our contract:

+
    sender = pre.fund_eoa()
+

This line creates a single externally owned account (EOA) with a default balance. You can specify a custom amount with amount=0x0BA1A9CE0BA1A9CE if needed.

+

The returned object, which includes a private key, an address, and a nonce, is stored in the sender variable and will later be used as the sender of the transaction.

+

Transactions

+
    tx = Transaction(
+        ty=0x2,
+        sender=sender,
+        to=contract_address,
+        gas_limit=100_000,
+    )
+

With the pre-state built, we can now create the transaction that will call our contract. Let’s examine the key components of this [Transaction][ethereum_test_types.Transaction] (for all available fields, see the source code of [Transaction][ethereum_test_types.Transaction] and TransactionGeneric from which Transaction inherits).

+
    +
  • +

    sender=sender: We use the EOA we created earlier, which already has the necessary information to sign the transaction and contains the correct nonce. The nonce is a protection mechanism to prevent replay attacks - it must equal the number of transactions sent from the sender’s address, starting from zero. The framework automatically manages nonce incrementing for us.

    +
  • +
  • +

    to=contract_address: This specifies the address of the contract we want to call, which is the contract we deployed earlier.

    +
  • +
  • +

    gas_limit=100_000: This sets a high enough gas limit to ensure our simple contract execution doesn’t run out of gas.

    +
  • +
  • +

    ty=0x2: This specifies the transaction type (EIP-1559).

    +
  • +
+

Post State

+

Now we need to define what we expect the blockchain state to look like after our transaction executes:

+
    post = {
+        contract_address: Account(
+            storage={
+                0x00: 0x03,
+            },
+        ),
+    }
+

This is the post-state which is equivalent to expect in static tests, but without the indexes. It is similar to the pre-state, except that we do not need to specify everything, only those accounts and fields we wish to test.

+

In this case, we look at the storage of the contract we called and add to it what we expect to see. In this example storage cell 0x00 should be 0x03 as we stored this value using the SSTORE opcode in our contract bytecode.

+

Running the State Test

+

Finally, we execute the test by calling the state test wrapper with all our defined components:

+
    state_test(env=env, pre=pre, post=post, tx=tx)
+

This line calls the wrapper to the StateTest object that provides all the objects required in order to fill the test, generate the test fixtures and write them to file (by default, ./fixtures/<blockchain,state>_tests/example/state_test_example/test_state_test_example.json).

+

Note that even though we defined a StateTest, the fill command will also generate other derivative test fixtures: BlockchainTest, BlockchainTestEngine, and BlockchainTestEngineX. For more information about test types and when to use each, see Test Types: Prefer StateTest for Single Transactions.

+

Conclusion

+

At this point you should be able to write state transition tests within a single block.

+

Next Steps

+
    +
  • Learn about Adding a New Test to understand test organization and structure.
  • +
  • Explore Fork Methods for writing tests that adapt to different Ethereum forks.
  • +
+
+ +
+ +
+ +
+ + + + + + + + diff --git a/docs/public/writing_tests/types_of_tests/index.html b/docs/public/writing_tests/types_of_tests/index.html new file mode 100644 index 00000000000..6a26aa27572 --- /dev/null +++ b/docs/public/writing_tests/types_of_tests/index.html @@ -0,0 +1,167 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

+
+ + +
+ +

Types of tests

+

There are currently three types of tests that can be produced by a test spec:

+
    +
  1. State Tests
  2. +
  3. Blockchain Tests
  4. +
  5. Transaction Tests
  6. +
+

State Tests

+

Purpose

+

Tests the effects of individual transactions (ideally a single one) that span a single block in a controlled environment.

+

Use cases

+
    +
  • Test a single opcode behavior.
  • +
  • Verify opcode gas costs.
  • +
  • Test interactions between multiple smart contracts.
  • +
  • Test creation of smart contracts.
  • +
+

!!! info

+
The fill function will automatically generate a `blockchain_test` fixture from `state_tests`, consisting of one block and one transaction.
+
+

Blockchain Tests

+

Purpose

+

Blockchain tests span multiple blocks which may or may not contain transactions and mainly focus on the block to block effects to the Ethereum state.

+

Use cases

+
    +
  • Verify system-level operations such as coinbase balance updates or withdrawals.
  • +
  • Verify fork transitions.
  • +
  • Verify blocks with invalid transactions/properties are rejected.
  • +
+

Fork Transition Tests

+

There is a special type of blockchain test that is used to test a fork transition. It’s not executed for all possible forks, rather it targets exactly the blocks at the point of transition from one evm implementation to the next. This type of test must be marked with the valid_at_transition_to marker, for example:

+
@pytest.mark.valid_at_transition_to("Cancun")
+def test_blob_type_tx_pre_fork(
+    blockchain_test: BlockchainTestFiller,
+    pre: Dict,
+    env: Environment,
+    blocks: List[Block],
+):
+    """
+    Reject blocks with blobs before blobs fork
+    """
+

Transaction Tests

+

Purpose

+

Test correct transaction rejection/acceptance of a serialized transaction (currently RLP only).

+

Use cases

+
    +
  • Verify that a badly formatted transaction is correctly rejected by the client.
  • +
  • Verify that a transaction with an invalid value in one of its fields is correctly rejected by the client.
  • +
+

!!! info

+
Using the `execute` command, transaction tests can be sent to clients in a live network using the `eth_sendRawTransaction` endpoint.
+
+

Deciding on a test type

+

Prefer state_test for single transactions

+

Whenever possible, use state_test to examine individual transactions. This method is more straightforward and less prone to external influences that can occur during block building.

+

This provides more targeted testing since it does not invoke the client’s block-building machinery. This reduces the risk of encountering false positives, particularly in exception scenarios (e.g., see issue #343: “Zero max_fee_per_blob_gas test is ineffective”).

+

Moreover, the fill command automatically additionally generates a blockchain_test for every state_test by wrapping the state_test’s transaction in a block.

+
+ +
+ +
+ +
+ + + + + + + + diff --git a/docs/public/writing_tests/verifying_changes/index.html b/docs/public/writing_tests/verifying_changes/index.html new file mode 100644 index 00000000000..e99f4de2961 --- /dev/null +++ b/docs/public/writing_tests/verifying_changes/index.html @@ -0,0 +1,113 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

+
+ + +
+ +

Verifying Changes

+

!!! warning “Documentation Moved” +This documentation has been relocated to Detailed Code Standards. Please use the new location for the most up-to-date information.

+
+ +
+ +
+ +
+ + + + + + + + diff --git a/docs/public/writing_tests/writing_a_new_test/index.html b/docs/public/writing_tests/writing_a_new_test/index.html new file mode 100644 index 00000000000..5abcdc5a697 --- /dev/null +++ b/docs/public/writing_tests/writing_a_new_test/index.html @@ -0,0 +1,375 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+

+
+ + +
+ +

Writing a New Test

+

Test Functions

+

Every test case is defined as a Python function that implements a single StateTest or BlockchainTest using the state_test or blockchain_test objects made available by the framework (learn how to decide on a test type). Test cases, and the respective test modules, must fulfill the following requirements:

+ + + + + + + + + + + + + + + + + + + + + + + + + +
RequirementWhen
Be decorated with validity markersIf the test case is not valid for all forks
Use one of state_test or blockchain_test in its function argumentsAlways
Call the state_test or blockchain_test in its test bodyAlways
Add a reference version of the EIP spec under testTest path contains eip
+

Specifying which Forks Tests are Valid For

+

Test cases can (and it most cases should) be decorated with one or more “validity markers” that define which the forks the test is valid for. This is achieved by applying:

+
    +
  • pytest.mark.valid_from(FORK) and/or pytest.mark.valid_until(FORK)
  • +
+

or

+
    +
  • pytest.mark.valid_at_transition_to(FORK)
  • +
+

markers on either the test function, test class or test module level:

+

=== “Function”

+
```python
+import pytest
+
+@pytest.mark.valid_from("Berlin")
+@pytest.mark.valid_until("London")
+def test_access_list(state_test: StateTestFiller, fork: Fork):
+```
+
+

=== “Class”

+
```python
+import pytest
+
+
+@pytest.mark.valid_from("Shanghai")
+class TestMultipleWithdrawalsSameAddress:
+```
+
+

=== “Module”

+
```python
+import pytest
+
+pytestmark = pytest.mark.valid_from("Shanghai")
+```
+
+

The ethereum_test_forks package defines the available forks and provides the following helpers that return all forks within the specified range:

+ +

The state_test and blockchain_test Test Function Arguments

+

The test function’s signature must contain exactly one of either a state_test or blockchain_test argument.

+

For example, for state tests:

+
def test_access_list(state_test: StateTestFiller):
+

and for blockchain tests:

+
def test_contract_creating_tx(
+    blockchain_test: BlockchainTestFiller, fork: Fork, initcode: Initcode
+):
+

The state_test and blockchain_test objects are actually wrapper classes to the StateTest, respectively BlockchainTest objects, that once called actually instantiate a new instance of these objects and fill the test case using the evm tool according to the pre and post states and the transactions defined within the test.

+

If a blockchain-type test should only generate a test fixture in the Engine format (EngineFixture), the blockchain_test_engine object can be specified. This object is a wrapper for the BlockchainTestEngine class.

+

StateTest Object

+

The StateTest object represents a single test vector, and contains the +following attributes:

+
    +
  • env: Environment object which describes the global state of the blockchain +before the test starts.
  • +
  • pre: Pre-State containing the information of all Ethereum accounts that exist +before any transaction is executed.
  • +
  • post: Post-State containing the information of all Ethereum accounts that are +created or modified after all transactions are executed.
  • +
  • txs: All transactions to be executed during test execution.
  • +
+

BlockchainTest Object

+

The BlockchainTest object represents a single test vector that evaluates the +Ethereum VM by attempting to append multiple blocks to the chain:

+
    +
  • pre: Pre-State containing the information of all Ethereum accounts that exist +before any block is executed.
  • +
  • post: Post-State containing the information of all Ethereum accounts that are +created or modified after all blocks are executed.
  • +
  • blocks: All blocks to be appended to the blockchain during the test.
  • +
+

BlockchainTestEngine Object

+

The BlockchainTestEngine object has the same properties as the BlockchainTest but it’s used to only generate a blockchain test in the Engine format.

+

Pre/Post State of the Test

+

The pre and post states are elemental to setup and then verify the outcome +of the state test.

+

Both pre and post are mappings of account addresses to account structures (see more info).

+

A single test vector can contain as many accounts in the pre and post states +as required, and they can be also filled dynamically.

+

storage of an account is a key/value dictionary, and its values are +integers within range of [0, 2**256 - 1].

+

txs are the steps which transform the pre-state into the post-state and +must perform specific actions within the accounts (smart contracts) that result +in verifiable changes to the balance, nonce, and/or storage in each of them.

+

post is compared against the outcome of the client after the execution +of each transaction, and any differences are considered a failure

+

When designing a test, all the changes must be ideally saved into the contract’s +storage to be able to verify them in the post-state.

+

Test Transactions

+

Transactions can be crafted by sending them with specific data or to a +specific account, which contains the code to be executed.

+

Transactions can also create more accounts, by setting the to field to an +empty string.

+

Transactions can be designed to fail, and a verification must be made that the +transaction fails with the specific error that matches what is expected by the +test.

+

They can also contain a TransactionReceipt object in field expected_receipt +which allows checking for an exact gas_used value.

+

Writing code for the accounts in the test

+

Account bytecode can be “deployed” in a test’s pre-state using the pre pytest fixture. The @ethereum/execution-spec-tests Python [Opcodes][ethereum_test_vm.Opcodes] minilang can be used to help write the bytecode in a readable form.

+

Using the Python Opcode Minilang

+

EVM bytecode for tests should be written using the Python-based minilang provided by the [Opcodes][ethereum_test_vm.Opcodes] class. This allows you to construct bytecode using symbolic opcodes as Python objects.

+

Example: Simple Addition Contract

+
from ethereum_test_vm.opcode import Opcodes
+
+code = (
+    Opcodes.PUSH1(0x02)
+    + Opcodes.PUSH1(0x03)
+    + Opcodes.ADD()
+    + Opcodes.PUSH1(0x00)
+    + Opcodes.SSTORE()
+    + Opcodes.STOP()
+)
+
+# within a test function, using the "pre" fixture
+contract_address = pre.deploy_contract(code=code)
+

You add this contract to the test’s pre-state using the pre fixture or assign this code to the code field of an account in your test’s post state. See the state test tutorial for more help.

+

For a full list of available opcodes and their usage, see [Opcodes][ethereum_test_vm.Opcodes].

+

Higher-Level Constructs

+

For more complex control flow, you can use constructs like [Switch][ethereum_test_tools.code.generators.Switch] and [Case][ethereum_test_tools.code.generators.Case] from the ethereum_test_tools.code.generators module:

+
from ethereum_test_tools.code.generators import Switch, Case
+from ethereum_test_vm.opcode import Opcodes as Op
+
+code = Switch(
+    cases=[
+        Case(condition=Op.EQ(Op.CALLDATALOAD(0), 1), action=Op.PUSH1(0x01) + Op.STOP()),
+        Case(condition=Op.EQ(Op.CALLDATALOAD(0), 2), action=Op.PUSH1(0x02) + Op.STOP()),
+    ],
+    default_action=Op.PUSH1(0x00) + Op.STOP(),
+)
+

The ethereum_test_tools.code.generators module also defines other high-level constructs like [While][ethereum_test_tools.code.generators.While] and [Conditional][ethereum_test_tools.code.generators.Conditional].

+

Converting Bytecode to Minilang

+

If you have EVM bytecode (as hex or binary), you can use the evm_bytes CLI tool to convert it to the EEST Python opcode minilang automatically, for example:

+
uv run evm_bytes hex-string 0x604260005260206000F3
+# ->
+# Op.PUSH1[0x42] + Op.PUSH1[0x0] + Op.MSTORE + Op.PUSH1[0x20] + Op.PUSH1[0x0] + Op.RETURN
+

Restrictions: No Yul in Python Test Cases

+

As of PR #1779, the use of Yul source in Python test cases is forbidden. All new tests must use the Python opcode minilang as shown above.

+

Verifying the Accounts’ Post States

+

The state of the accounts after all blocks/transactions have been executed is +the way of verifying that the execution client actually behaves like the test +expects.

+

During their filling process, all tests automatically verify that the accounts +specified in their post property actually match what was returned by the +transition tool.

+

Within the post dictionary object, an account address can be:

+
    +
  • None: The account will not be checked for absence or existence in the +result returned by the transition tool.
  • +
  • Account object: The test expects that this account exists and also has +properties equal to the properties specified by the Account object.
  • +
  • Account.NONEXISTENT: The test expects that this account does not exist in +the result returned by the transition tool, and if the account exists, +it results in error. +E.g. when the transaction creating a contract is expected to fail and the +test wants to verify that the address where the contract was supposed to be +created is indeed empty.
  • +
+

The Account object

+

The Account object is used to specify the properties of an account to be +verified in the post state.

+

The python representation can be found in src/ethereum_test_types/account_types.py.

+

It can verify the following properties of an account:

+
    +
  • +

    nonce: the scalar value equal to a) the number of transactions sent by +an Externally Owned Account, b) the amount of contracts created by a contract.

    +
  • +
  • +

    balance: the amount of Wei (10-18 Eth) the account has.

    +
  • +
  • +

    code: Bytecode contained by the account. To verify that an account contains +no code, this property needs to be set to “0x” or “”.

    +
  • +
  • +

    storage: Storage within the account represented as a dict object. +All storage keys that are expected to be set must be specified, and if a +key is skipped, it is implied that its expected value is zero. +Setting this property to {} (empty dict), means that all the keys in the +account must be unset (equal to zero).

    +
  • +
+

All account’s properties are optional, and they can be skipped or set to None, +which means that no check will be performed on that specific account property.

+

Verifying correctness of the new test

+

A well written test performs a single verification output at a time.

+

A verification output can be a single storage slot, the balance of an account, +or a newly created contract.

+

It is not recommended to use balance changes to verify test correctness, as it +can be easily affected by gas cost changes in future EIPs.

+

The best way to verify a transaction/block execution outcome is to check its +storage.

+

A test can be written as a negative verification. E.g. a contract is not +created, or a transaction fails to execute or runs out of gas.

+

This kind of verification must be carefully crafted because it is possible to end up +having a false positive result, which means that the test passed but the +intended verification was never made.

+

To avoid these scenarios, it is important to have a separate verification to +check that test is effective. E.g. when a transaction is supposed to fail, it +is necessary to check that the failure error is actually the one expected by +the test.

+

Failing or invalid transactions

+

Transactions included in a StateTest are expected to be intrinsically valid, +i.e. the account sending the transaction must have enough funds to cover the +gas costs, the max fee of the transaction must be equal or higher than the +base fee of the block, etc.

+

An intrinsically valid transaction can still revert during its execution.

+

Blocks in a BlockchainTest can contain intrinsically invalid transactions but +in this case the block is expected to be completely rejected, along with all +transactions in it, including other valid transactions.

+

Parametrizing tests

+

Tests can be parametrized by using the @pytest.mark.parametrize decorator.

+

Example:

+
import pytest
+
+@pytest.mark.parametrize(
+    "tx_value,expected_balance",
+    [
+        pytest.param(0, 0, id="zero-value"),
+        pytest.param(100, 100, id="non-zero-value"),
+    ],
+)
+def test_contract_creating_tx(
+    blockchain_test: BlockchainTestFiller, fork: Fork, tx_value: int, expected_balance: int
+):
+

This will run the test twice, once with tx_value set to 0 and expected_balance +set to 0, and once with tx_value set to 100 and expected_balance set to 100.

+

The fork fixture is automatically provided by the framework and contains the +current fork under test, and does not need to be parametrized.

+

Tests can also be automatically parametrized with appropriate fork covariant +values using the with_all_* markers listed in the +Test Markers page.

+

The extend_with_defaults Utility

+

::: ethereum_test_tools.utility.pytest.extend_with_defaults

+
+ +
+ +
+ +
+ + + + + + + + diff --git a/docs/running_tests/execute/eth_config.md b/docs/running_tests/execute/eth_config.md deleted file mode 100644 index 3eb64dd5f43..00000000000 --- a/docs/running_tests/execute/eth_config.md +++ /dev/null @@ -1,109 +0,0 @@ -# Execute eth-config Command - -The `execute eth-config` command is a specialized testing tool that validates an Ethereum client's configuration against expected network parameters using the `eth_config` RPC endpoint as specified by [EIP-7910](https://eips.ethereum.org/EIPS/eip-7910). - -The goal is to test baked-in configurations primarily but it can be used to test that genesis and config files were successfully parsed, in devnets for example. - -## Overview - -This command verifies that a client is correctly configured for a specific network by checking: - -- Current fork configuration. -- Fork activation times. -- Chain ID. -- Precompile addresses. -- System contract addresses. -- Fork hashes and IDs. - -## Usage - -### Standalone, Direct Usage - -The `eth-config` sub-command can be ran directly, without cloning @ethereum/execution-spec-tests, by [installing uv](https://docs.astral.sh/uv/getting-started/installation/) and running: - -```bash -uv run --with git+https://github.com/ethereum/execution-spec-tests.git execute eth-config --network Mainnet --rpc-endpoint http:// -``` - -### From within the EEST Repository - -```bash -uv run execute eth-config --network --rpc-endpoint [OPTIONS] -``` - -### Required Arguments - -- `--network`: Name of the network to verify (e.g., `Mainnet`, `Sepolia`, `Holesky`, `Hoodi`) -- `--rpc-endpoint`: RPC endpoint URL of the execution client to test - -### Optional Arguments - -- `--network-config-file`: Path to a custom YAML file containing network configurations (defaults to `src/pytest_plugins/execute/eth_config/networks.yml`) - -## Examples - -### Testing a Mainnet Client - -```bash -uv run execute eth-config --network Mainnet --rpc-endpoint http://localhost:8545 -``` - -### Testing a Sepolia Client - -```bash -uv run execute eth-config --network Sepolia --rpc-endpoint http://localhost:8545 -``` - -### Using a Custom Network Configuration - -```bash -uv run execute eth-config --network MyCustomNet --rpc-endpoint http://localhost:8545 --network-config-file ./my-networks.yml -``` - -## Network Configuration File Format - -The network configuration file is a YAML file that defines the parameters for each network. Here's the structure: - -```yaml -MyCustomNet: - chainId: 0xabcd # Chain ID in hex - genesisHash: 0xd4e5674... # Genesis block hash - forkActivationTimes: # Fork activation block numbers/times - 0: Cancun # Genesis fork, it must be the latest fork activated in the genesis - 1742999832: Prague - 1742999833: Osaka - bpoForkActivationTimes: # Optional: Blob parameter only fork definitions - 1742999834: - target: 9 - max: 12 - base_fee_update_fraction: 5007716 - 1742999835: - target: 12 - max: 15 - base_fee_update_fraction: 5007716 - addressOverrides: # Optional: Override addresses for precompiles/contracts - 0x00000000219ab540...: 0x7f02c3e3c98b133... -``` - -### Supported Networks - -The default configuration file includes: - -- **Mainnet**: Ethereum mainnet. -- **Sepolia**: Public testnet. -- **Hoodi**: Public testnet. -- **Holesky**: Public testnet. - -## How It Works - -1. **Configuration Loading**: The command loads the network configuration from the YAML file. -2. **RPC Connection**: Connects to the specified client RPC endpoint. -3. **eth_config Call**: Calls the `eth_config` RPC method to get the client's current configuration. -4. **Validation**: Compares the client's response against the expected configuration based on: - - Current system timestamp. - - Fork activation schedule. - - Address overrides (if any). - -## `eth_config` Expected Response Details - -See [EIP-7910](https://eips.ethereum.org/EIPS/eip-7910) for the expected response description. diff --git a/docs/running_tests/index.md b/docs/running_tests/index.md deleted file mode 100644 index c5462021ae9..00000000000 --- a/docs/running_tests/index.md +++ /dev/null @@ -1,15 +0,0 @@ -# Running Tests - -This section documents how EL clients can run EEST tests to verify their implementations. The information is organized as follows: - -1. **[Methods of Running Tests](./running.md):** A detailed overview and comparison. - -2. **[EEST Fixture Releases](./releases.md):** The available release types; release versioning. - -3. **[Test Fixture Specifications](./test_formats/index.md)** and guides to implement direct consumer interfaces. - -4. **[Hive](./hive/index.md):** Help running EEST Hive simulators. - -5. **[Consume](./consume/index.md):** Commands that help clients run tests by consuming test fixtures. - -6. **[Execute](./execute/index.md):** Commands that help clients run tests by executing test source. diff --git a/docs/scripts/copy_repo_docs_to_mkdocs.py b/docs/scripts/copy_repo_docs_to_mkdocs.py deleted file mode 100644 index e77004cb140..00000000000 --- a/docs/scripts/copy_repo_docs_to_mkdocs.py +++ /dev/null @@ -1,64 +0,0 @@ -"""Include EEST's CONTRIBUTING.md and SECURITY.md in the HTML documentation.""" - -import logging -import re -from pathlib import Path - -import mkdocs_gen_files - -logger = logging.getLogger("mkdocs") - - -def copy_markdown_file(source_path, destination_path, fix_links=True): - """Copy a markdown file to the destination, fixing links if requested.""" - source_file = Path(source_path) - destination_file = Path(destination_path) - - if not source_file.is_file(): - raise FileNotFoundError( - f"Error: Source file '{source_file}' not found in current directory." - ) - - try: - with mkdocs_gen_files.open(destination_file, "w") as destination: - with open(source_file, "r") as f: - for line in f.readlines(): - if fix_links: - # Fix absolute website links to relative docs links - line = re.sub( - r"https://eest\.ethereum\.org/main/([^)\s]+)", r"../\1.md", line - ) - - # Fix SECURITY.md link - line = re.sub( - r"\[Security Policy\]\(SECURITY\.md\)", - r"[Security Policy](security.md)", - line, - ) - - # Fix EIP checklist template link - line = re.sub( - r"\[EIP checklist template\]\(./docs/writing_tests/checklist_templates/eip_testing_checklist_template.md\)", # noqa: E501 - r"[EIP checklist template](../writing_tests/checklist_templates/eip_testing_checklist_template.md)", # noqa: E501 - line, - ) - - destination.write(line) - except Exception as e: - raise Exception(f"Error copying file {source_file} to {destination_file}") from e - - logger.info(f"Copied {source_file} to {destination_file}.") - - -def include_contributing_in_docs(): - """Copy CONTRIBUTING.md to ./docs/ to include in HTML docs.""" - copy_markdown_file("CONTRIBUTING.md", "getting_started/contributing.md") - - -def include_security_in_docs(): - """Copy SECURITY.md to ./docs/getting_started/ to include in HTML docs.""" - copy_markdown_file("SECURITY.md", "getting_started/security.md") - - -include_contributing_in_docs() -include_security_in_docs() diff --git a/docs/scripts/gen_test_case_reference.py b/docs/scripts/gen_test_case_reference.py deleted file mode 100644 index d5579a850d2..00000000000 --- a/docs/scripts/gen_test_case_reference.py +++ /dev/null @@ -1,76 +0,0 @@ -""" -Script called during mkdocs build|serve to create the "Test Case Reference". - -Called via the mkdocs-gen-files plugin; it's specified in mkdocs.yaml and -can't take command-line arguments. The main logic is implemented in -src/pytest_plugins/filler/gen_test_doc.py. -""" - -import importlib -import logging -import sys -from os import getenv - -import pytest -from click.testing import CliRunner - -import pytest_plugins.filler.gen_test_doc.gen_test_doc as gen_test_doc -from cli.pytest_commands.fill import fill -from config import DocsConfig - -importlib.reload(gen_test_doc) # get changes in plugin to trigger an update for `mkdocs serve` - -TARGET_FORK = DocsConfig().TARGET_FORK -GENERATE_UNTIL_FORK = DocsConfig().GENERATE_UNTIL_FORK - -logger = logging.getLogger("mkdocs") - - -# if docs are generated while FAST_DOCS is true, then use "tests/frontier" otherwise use "tests" -# USAGE 1 (use fast mode): -# export FAST_DOCS=true && uv run mkdocs serve -# USAGE 2 (use fast mode + hide side-effect warnings): -# export FAST_DOCS=true && uv run mkdocs serve 2>&1 | sed '/is not found among documentation files/d' # noqa: E501 -test_arg = "tests" -fast_mode = getenv("FAST_DOCS") -if fast_mode is not None: - if fast_mode.lower() == "true": - print("-" * 40, "\nWill generate docs using FAST_DOCS mode.\n" + "-" * 40) - test_arg = "tests/frontier" - -args = [ - "--override-ini", - "filterwarnings=ignore::pytest.PytestAssertRewriteWarning", # suppress warnings due to reload - "-p", - "pytest_plugins.filler.gen_test_doc.gen_test_doc", - "-p", - "pytest_plugins.filler.eip_checklist", - "--gen-docs", - f"--gen-docs-target-fork={TARGET_FORK}", - f"--until={GENERATE_UNTIL_FORK}", - "--checklist-doc-gen", - "--skip-index", - "-m", - "not blockchain_test_engine", - "-s", - test_arg, -] - -runner = CliRunner() -logger.info( - f"Generating documentation for test cases until {GENERATE_UNTIL_FORK} as fill {' '.join(args)}" -) -result = runner.invoke(fill, args) -for line in result.output.split("\n"): - if "===" in line: - logger.info(line.replace("===", "==")) - continue - logger.info(line) -if result.exit_code in [pytest.ExitCode.OK, pytest.ExitCode.NO_TESTS_COLLECTED]: - logger.info("Documentation generation successful.") - sys.exit(0) -logger.error( - f"Documentation generation failed (exit: {pytest.ExitCode(result.exit_code)}, " - f"{pytest.ExitCode(result.exit_code).name})." -) -sys.exit(result.exit_code) diff --git a/docs/scripts/generate_fill_help.py b/docs/scripts/generate_fill_help.py deleted file mode 100644 index e7dda30f4e5..00000000000 --- a/docs/scripts/generate_fill_help.py +++ /dev/null @@ -1,108 +0,0 @@ -#!/usr/bin/env python3 -""" -Generate the fill command help output for documentation. - -This script captures the output of 'fill --help' and generates a complete -documentation page that includes both static content and the auto-generated -help output. The generated page replaces the manual help output with -current command-line options. -""" - -import logging -import subprocess -import sys -import textwrap - -import mkdocs_gen_files - -logger = logging.getLogger("mkdocs") - - -def get_fill_help_output() -> str: - """Run 'fill --help' and capture its output.""" - try: - result = subprocess.run( - ["uv", "run", "fill", "--help"], - capture_output=True, - text=True, - check=True, - ) - return result.stdout - except subprocess.CalledProcessError as e: - logger.error(f"Error running 'fill --help': {e}") - logger.error(f"stderr: {e.stderr}") - sys.exit(1) - - -def format_help_output(help_text: str, max_width: int = 88) -> str: - """ - Format the help output with proper line wrapping. - - Args: - help_text: The raw help output - max_width: Maximum line width (default 88 to match existing docs) - - Returns: - Formatted help text suitable for documentation - - """ - lines = help_text.splitlines() - formatted_lines = [] - - for line in lines: - # Don't wrap lines that are part of the usage section or are empty - if not line.strip() or line.startswith("usage:") or line.startswith(" ") and "--" in line: - formatted_lines.append(line) - else: - # Wrap long lines while preserving indentation - indent = len(line) - len(line.lstrip()) - if len(line) > max_width and indent == 0: - wrapped = textwrap.fill( - line, - width=max_width, - subsequent_indent=" ", - break_long_words=False, - break_on_hyphens=False, - ) - formatted_lines.append(wrapped) - else: - formatted_lines.append(line) - - return "\n".join(formatted_lines) - - -def generate_command_line_options_docs(): - """Generate a standalone page with just the fill command-line options.""" - # Get and format the help output - help_output = get_fill_help_output() - formatted_output = format_help_output(help_output) - - # Create the complete page content - page_content = f"""# Fill Command-Line Options - -Fill is a [pytest](https://docs.pytest.org/en/stable/)-based command. This page lists custom -options that the `fill` command provides. To see the full list of options that is available -to fill (including the standard pytest and plugin command-line options) use `fill --pytest-help`. - -*This page is automatically generated from the current `fill --help` output.* - -## Command Help Output - -```text -{formatted_output} -``` - ---- - -*This page was automatically generated from `fill --help` output.* -""" - - # Write the generated content to a virtual file - with mkdocs_gen_files.open("filling_tests/filling_tests_command_line_options.md", "w") as f: - f.write(page_content) - - logger.info("Generated filling_tests_command_line_options.md with current fill --help output") - - -# Run the generation -generate_command_line_options_docs() diff --git a/docs/static/css/callouts.css b/docs/static/css/callouts.css new file mode 100644 index 00000000000..3ba3aec9f06 --- /dev/null +++ b/docs/static/css/callouts.css @@ -0,0 +1,87 @@ +.callout { + margin: 1.5em 0; + padding: 0; + border-left: 4px solid; + border-radius: 4px; + background-color: #f7f7f7; + } + + .callout-title { + padding: 0.75em 1em; + font-weight: bold; + background-color: rgba(0,0,0,0.05); + } + + .callout-content { + padding: 1em; + } + + .callout-warning { + border-color: #ff9800; + background-color: #fff3e0; + } + + .callout-warning .callout-title { + color: #e65100; + background-color: #ffe0b2; + } + + .callout-info { + border-color: #2196f3; + background-color: #e3f2fd; + } + + .callout-info .callout-title { + color: #0d47a1; + background-color: #bbdefb; + } + + .callout-danger { + border-color: #f44336; + background-color: #ffebee; + } + + .callout-danger .callout-title { + color: #b71c1c; + background-color: #ffcdd2; + } + + .callout-success { + border-color: #4caf50; + background-color: #e8f5e9; + } + + .callout-success .callout-title { + color: #1b5e20; + background-color: #c8e6c9; + } + + +/* Dark mode support (optional) */ +@media (prefers-color-scheme: dark) { + .callout-info { + background-color: rgba(33, 150, 243, 0.1); + color: #90caf9; + } + + .callout-warning { + background-color: rgba(255, 152, 0, 0.1); + color: #ffb74d; + } + + .callout-danger, + .callout-error { + background-color: rgba(244, 67, 54, 0.1); + color: #ef5350; + } + + .callout-success { + background-color: rgba(76, 175, 80, 0.1); + color: #81c784; + } + + .callout-note { + background-color: rgba(158, 158, 158, 0.1); + color: #e0e0e0; + } +} diff --git a/docs/static/css/custom.css b/docs/static/css/custom.css new file mode 100644 index 00000000000..9ccc4d42d64 --- /dev/null +++ b/docs/static/css/custom.css @@ -0,0 +1,43 @@ +/* Better table styling */ +table { + border-collapse: collapse; + width: 100%; + margin: 1.5rem 0; + font-size: 0.95em; + } + + table th { + background-color: #f5f5f5; + border: 1px solid #ddd; + padding: 0.75rem; + text-align: left; + font-weight: 600; + } + + table td { + border: 1px solid #ddd; + padding: 0.75rem; + vertical-align: top; + } + + table tr:nth-child(even) { + background-color: #f9f9f9; + } + + table code { + background-color: #f4f4f4; + padding: 0.2rem 0.4rem; + border-radius: 3px; + font-size: 0.9em; + } + + /* Responsive tables */ + @media (max-width: 768px) { + table { + font-size: 0.85em; + } + + table td, table th { + padding: 0.5rem; + } + } \ No newline at end of file diff --git a/docs/static/css/sidebar.css b/docs/static/css/sidebar.css new file mode 100644 index 00000000000..6ce3f53b101 --- /dev/null +++ b/docs/static/css/sidebar.css @@ -0,0 +1,116 @@ +/* Sidebar layout */ +.content-with-sidebar { + display: flex; + gap: 2rem; + max-width: 1200px; + margin: 0 auto; + padding: 2rem; + } + + .sidebar { + flex: 0 0 250px; + min-height: 300px; + } + + .main-content { + flex: 1; + min-width: 0; /* Prevent overflow */ + } + + /* Sidebar styling */ + .sidebar-nav { + position: sticky; + top: 2rem; + background: #f5f5f5; + border-radius: 8px; + padding: 1.5rem; + border: 1px solid #e0e0e0; + } + + .sidebar-title { + margin: 0 0 1rem 0; + font-size: 1.1rem; + color: #333; + border-bottom: 2px solid #ddd; + padding-bottom: 0.5rem; + } + + .sidebar-subtitle { + margin: 1.5rem 0 0.5rem 0; + font-size: 0.9rem; + color: #666; + } + + .sidebar-menu { + list-style: none; + margin: 0; + padding: 0; + } + + .sidebar-item { + margin: 0.25rem 0; + } + + .sidebar-link { + display: block; + padding: 0.5rem 0.75rem; + color: #333; + text-decoration: none; + border-radius: 4px; + transition: all 0.2s ease; + } + + .sidebar-link:hover { + background-color: #e8e8e8; + color: #000; + } + + .sidebar-item.active .sidebar-link { + background-color: #007bff; + color: white; + font-weight: 500; + } + + /* Mobile responsive */ + @media (max-width: 768px) { + .content-with-sidebar { + flex-direction: column; + } + + .sidebar { + flex: 1; + margin-bottom: 2rem; + } + + .sidebar-nav { + position: static; + } + } + + /* enhanced */ + .breadcrumbs { + font-size: 0.85rem; + margin-bottom: 1rem; + color: #666; + } + + .breadcrumbs a { + color: #007bff; + text-decoration: none; + } + + .breadcrumbs a:hover { + text-decoration: underline; + } + + .sidebar-divider { + margin: 1rem 0; + border: none; + border-top: 1px solid #ddd; + } + + .sidebar-submenu { + list-style: none; + margin: 0; + padding: 0; + } \ No newline at end of file diff --git a/docs/static/images/filling_tests/evm_dump_dir_in_html_report.png b/docs/static/images/filling_tests/evm_dump_dir_in_html_report.png new file mode 100644 index 00000000000..1979b5dd40f Binary files /dev/null and b/docs/static/images/filling_tests/evm_dump_dir_in_html_report.png differ diff --git a/docs/static/images/filling_tests/pytest_collect_only.png b/docs/static/images/filling_tests/pytest_collect_only.png new file mode 100644 index 00000000000..a20e58c2c8c Binary files /dev/null and b/docs/static/images/filling_tests/pytest_collect_only.png differ diff --git a/docs/static/images/filling_tests/pytest_run_example.png b/docs/static/images/filling_tests/pytest_run_example.png new file mode 100644 index 00000000000..96df337a21f Binary files /dev/null and b/docs/static/images/filling_tests/pytest_run_example.png differ diff --git a/docs/static/images/filling_tests/vs_code_executing_tests.png b/docs/static/images/filling_tests/vs_code_executing_tests.png new file mode 100644 index 00000000000..7c46ae2849b Binary files /dev/null and b/docs/static/images/filling_tests/vs_code_executing_tests.png differ diff --git a/docs/static/images/filling_tests/vs_code_exploring_tests.png b/docs/static/images/filling_tests/vs_code_exploring_tests.png new file mode 100644 index 00000000000..3618a2249d6 Binary files /dev/null and b/docs/static/images/filling_tests/vs_code_exploring_tests.png differ diff --git a/docs/static/images/getting_started/testing_pandas.png b/docs/static/images/getting_started/testing_pandas.png new file mode 100644 index 00000000000..34d6d91ea13 Binary files /dev/null and b/docs/static/images/getting_started/testing_pandas.png differ diff --git a/docs/static/images/getting_started/vscode_extension_disable_for_workspace.png b/docs/static/images/getting_started/vscode_extension_disable_for_workspace.png new file mode 100644 index 00000000000..5ffb5a6c959 Binary files /dev/null and b/docs/static/images/getting_started/vscode_extension_disable_for_workspace.png differ diff --git a/docs/static/images/main/ETH-logo-icon.svg b/docs/static/images/main/ETH-logo-icon.svg new file mode 100644 index 00000000000..feffde6a690 --- /dev/null +++ b/docs/static/images/main/ETH-logo-icon.svg @@ -0,0 +1,19 @@ + + + + + + + + + + + diff --git a/docs/static/images/main/Ethereum-logo-600px.png b/docs/static/images/main/Ethereum-logo-600px.png new file mode 100644 index 00000000000..7f65db744b9 Binary files /dev/null and b/docs/static/images/main/Ethereum-logo-600px.png differ diff --git a/docs/static/images/main/annotated-coverage.jpg b/docs/static/images/main/annotated-coverage.jpg new file mode 100644 index 00000000000..ef4a403ec34 Binary files /dev/null and b/docs/static/images/main/annotated-coverage.jpg differ diff --git a/docs/static/images/main/execution_spec_tests.jpg b/docs/static/images/main/execution_spec_tests.jpg new file mode 100644 index 00000000000..51796da1036 Binary files /dev/null and b/docs/static/images/main/execution_spec_tests.jpg differ diff --git a/docs/static/images/main/favicon.ico b/docs/static/images/main/favicon.ico new file mode 100644 index 00000000000..feffde6a690 --- /dev/null +++ b/docs/static/images/main/favicon.ico @@ -0,0 +1,19 @@ + + + + + + + + + + + diff --git a/docs/static/images/main/fixture-gen-flowchart.png b/docs/static/images/main/fixture-gen-flowchart.png new file mode 100644 index 00000000000..3f5d820797f Binary files /dev/null and b/docs/static/images/main/fixture-gen-flowchart.png differ diff --git a/docs/static/images/main/original-coverage-loss.png b/docs/static/images/main/original-coverage-loss.png new file mode 100644 index 00000000000..5fead1bc1e2 Binary files /dev/null and b/docs/static/images/main/original-coverage-loss.png differ diff --git a/docs/static/images/writing_tests/eest_make_test.gif b/docs/static/images/writing_tests/eest_make_test.gif new file mode 100644 index 00000000000..e2842a9f6ba Binary files /dev/null and b/docs/static/images/writing_tests/eest_make_test.gif differ diff --git a/docs/static/images/writing_tests/eip_reference_spec_console_output.png b/docs/static/images/writing_tests/eip_reference_spec_console_output.png new file mode 100644 index 00000000000..f043ed2fef4 Binary files /dev/null and b/docs/static/images/writing_tests/eip_reference_spec_console_output.png differ diff --git a/docs/static/images/writing_tests/eip_reference_spec_console_output_fail.png b/docs/static/images/writing_tests/eip_reference_spec_console_output_fail.png new file mode 100644 index 00000000000..2c36f0dfbaf Binary files /dev/null and b/docs/static/images/writing_tests/eip_reference_spec_console_output_fail.png differ diff --git a/docs/stylesheets/custom.css b/docs/stylesheets/custom.css deleted file mode 100644 index dc6ccd48b1a..00000000000 --- a/docs/stylesheets/custom.css +++ /dev/null @@ -1,91 +0,0 @@ -.slide { - display: inline-block; - position: relative; - opacity: 0; - left: 20px; - transition: all 0.5s ease; -} - -.slide.show { - opacity: 1; - left: 0; -} - -.slide.hide { - opacity: 0; - left: 20px; -} - -/* Data table control panel */ -.control_panel .search_wrapper input { - border: 1px solid #9e9e9e; - border-radius: 4px; - padding: 8px 15px; - - font-size: 18px; - display: block; - width: 100%; -} -.control_panel .filters { - display: flex; -} - -.control_panel .filters .filter_wrapper { - margin-right: 15px; - padding: 8px 14px; - border-radius: 4px; - vertical-align: middle; - border: 1px solid #9e9e9e; - margin-bottom: 10px; -} - -.control_panel .filters .filter_wrapper label { - color: #8f8f8f; - font-weight: bold; - font-size: 14px; -} - -.control_panel .select2-container--default .select2-selection--single { - border: none; -} - -#test_table_wrapper .dt-search { - display: none; -} - -.twemoji { - --md-icon-size: 1.125em; - display: inline-flex; - height: var(--md-icon-size); - vertical-align: text-top; -} - -.twemoji svg { - fill: currentcolor; - max-height: 100%; - width: var(--md-icon-size); -} - -.stand_alone_container { - margin: 10px 15px; -} - -.control_panel .filters .buttons-collection, -.control_panel .filters .buttons-collection:hover { - background: transparent; - padding: 10px 15px; - vertical-align: middle; - border: 1px solid #9e9e9e; - margin-bottom: 10px; -} - -.control_panel div.dt-buttons > .dt-button:hover:not(.disabled), -div.dt-buttons > div.dt-button-split .dt-button:hover:not(.disabled) { - background: transparent; - border: 1px solid #9e9e9e; -} - -.buttons-collection .twemoji { - color: #8f8f8f; - margin-right: 4px; -} diff --git a/docs/templates/base.md.j2 b/docs/templates/base.md.j2 deleted file mode 100644 index 865f402178c..00000000000 --- a/docs/templates/base.md.j2 +++ /dev/null @@ -1,18 +0,0 @@ -{% block title %} -# {{ title }} -{# templates inheriting from this base template can re-define the title block #} -{% endblock %} - -Documentation for [`{{ pytest_node_id }}@{{ short_git_ref }}`]({{ source_code_url }}). - -{% if title != "Spec" %} -!!! example "Generate fixtures for these test cases for {{ target_or_valid_fork }} with:" - - ```console - fill -v {{ pytest_node_id }} --fork {{ target_or_valid_fork }} - ``` -{% endif %} - -{% block additional_content %} -{# templates that inherit from base can add an additional_content block here #} -{% endblock %} \ No newline at end of file diff --git a/docs/templates/directory.md.j2 b/docs/templates/directory.md.j2 deleted file mode 100644 index ee0cac93766..00000000000 --- a/docs/templates/directory.md.j2 +++ /dev/null @@ -1,9 +0,0 @@ -{% extends "base.md.j2" %} -{% block title %} -# {{ title }} -{% endblock %} -{% block additional_content %} -::: {{ package_name }} - options: - members: no -{% endblock %} \ No newline at end of file diff --git a/docs/templates/function.html.j2 b/docs/templates/function.html.j2 deleted file mode 100644 index ee620471f45..00000000000 --- a/docs/templates/function.html.j2 +++ /dev/null @@ -1,30 +0,0 @@ - - - - {{ title }}() - - - - - - - -
- {% block title %} -

Test Function: {{ title }}()

- {% endblock %} -

{{ docstring_one_liner }}

-

Back to {{ title }}().

- {% if cases %} -

Parametrized Test Cases

- {% include 'function_parameter_datatable.html.j2' %} - {% endif %} -
- - - - - - - - diff --git a/docs/templates/function.md.j2 b/docs/templates/function.md.j2 deleted file mode 100644 index 3b152fa3b00..00000000000 --- a/docs/templates/function.md.j2 +++ /dev/null @@ -1,31 +0,0 @@ -{% extends "base.md.j2" %} -{% block title %} ---- -search: - exclude: true ---- -{# - don't include function pages in the mkdocs-material site search index - see https://github.com/ethereum/execution-spec-tests/issues/1291 -#} - -# `{{ title }}()` -{% endblock %} -{% block additional_content %} - -::: {{ package_name }} - options: - filters: ["^[tT]est*|^Spec*"] - -## Parametrized Test Cases - -{% if test_case_count > 1 %} -The interactive table below is also available as a [standalone page]({{ html_static_page_target }}). -{% elif fixture_formats | length > 1 %} -This test case is only parametrized by fork and fixture format. -{% else %} -This test case is only parametrized by fork. -{% endif %} - -{% include 'function_parameter_datatable.html.j2' %} -{% endblock %} diff --git a/docs/templates/function_parameter_datatable.html.j2 b/docs/templates/function_parameter_datatable.html.j2 deleted file mode 100644 index 30878fd3ac5..00000000000 --- a/docs/templates/function_parameter_datatable.html.j2 +++ /dev/null @@ -1,68 +0,0 @@ -
-
-
- - -
-
- - -
-
- -
- - - - - {% for header in cases[0].params.keys() %} - - {% endfor %} - - - - {% for case in cases %} - - - {% for value in case.params.values() %} - - {% endfor %} - - {% endfor %} - -
Test ID (Abbreviated){{ header }}
- - - ...{{ case.abbreviated_id }} - - {{ value }}
diff --git a/docs/templates/markdown_header.md.j2 b/docs/templates/markdown_header.md.j2 deleted file mode 100644 index 532d42554fe..00000000000 --- a/docs/templates/markdown_header.md.j2 +++ /dev/null @@ -1,4 +0,0 @@ -!!! note "Markdown Content" - Below is the verbatim markdown content from [`{{ pytest_node_id }}@{{ short_git_ref }}`]({{ source_code_url }}). - -{# intentional additional newlines to force md file header/content to a newline #} diff --git a/docs/templates/module.md.j2 b/docs/templates/module.md.j2 deleted file mode 100644 index ef4ba1ae423..00000000000 --- a/docs/templates/module.md.j2 +++ /dev/null @@ -1,28 +0,0 @@ -{% extends "base.md.j2" %} - -{% block title %} -# {{ title }} -{% endblock %} - -{% block additional_content %} - -::: {{ package_name }} -{% if "Spec" in title %} - options: - filters: ["^Spec*"] -{% else %} - options: - members: no -{% endif %} - -{% if test_functions %} -## Test Functions Overview - -| Name | Type | Cases ({{ target_or_valid_fork }}) | Description | -|------|------|-------------------------------|-------------| -{% for test_function in test_functions %} -| [`{{ test_function.name }}`](./{{ test_function.name }}.md) | {{ test_function.test_type }} | {{ test_function.test_case_count }} | {{ test_function.docstring_one_liner }} | -{% endfor %} -{% endif %} - -{% endblock %} \ No newline at end of file diff --git a/docs/themes/minimal/LICENSE.md b/docs/themes/minimal/LICENSE.md new file mode 100644 index 00000000000..f43efa8d453 --- /dev/null +++ b/docs/themes/minimal/LICENSE.md @@ -0,0 +1,20 @@ +The MIT License (MIT) + +Copyright (c) 2017 Calin Tataru + +Permission is hereby granted, free of charge, to any person obtaining a copy of +this software and associated documentation files (the "Software"), to deal in +the Software without restriction, including without limitation the rights to +use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of +the Software, and to permit persons to whom the Software is furnished to do so, +subject to the following conditions: + +The above copyright notice and this permission notice shall be included in all +copies or substantial portions of the Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS +FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR +COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER +IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN +CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. diff --git a/docs/themes/minimal/README.md b/docs/themes/minimal/README.md new file mode 100644 index 00000000000..578bccc7760 --- /dev/null +++ b/docs/themes/minimal/README.md @@ -0,0 +1,85 @@ +# Minimal + +Personal blog theme powered by [Hugo](https://gohugo.io). +A live demo is available [here](https://themes.gohugo.io/theme/minimal/). + +## Installation + +You can install the theme either as a clone or submodule. + +I recommend the latter. From the root of your Hugo site, type the following: + +``` +$ git submodule add https://github.com/calintat/minimal.git themes/minimal +$ git submodule init +$ git submodule update +``` + +Now you can get updates to Minimal in the future by updating the submodule: + +``` +$ git submodule update --remote themes/minimal +``` + +## Configuration + +After installation, take a look at the `exampleSite` folder inside `themes/minimal`. + +To get started, copy the `config.toml` file inside `exampleSite` to the root of your Hugo site: + +``` +$ cp themes/minimal/exampleSite/config.toml . +``` + +Now edit this file and add your own information. Note that some fields can be omitted. + +I recommend you use the theme's archetypes so now delete your site's `archetypes/default.md`. + +## Features + +You can tweak the look of the theme to suit your needs in a number of ways: + +- The accent colour can be changed by using the `accent` field in `config.toml`. + +- You can also change the background colour by using `backgroundColor`. + +- Add colored 5px borders at the top and bottom of pages by setting `showBorder` to `true`. + +For best results, I recommend you use a dark accent colour with a light background, for example: + +```toml +[params] + accent = "red" + showBorder = true + backgroundColor = "white" +``` + +### Fonts + +The theme uses [Google Fonts](https://fonts.google.com) to load its font. To change the font: + +```toml +[params] + font = "Raleway" # should match the name on Google Fonts! +``` + +### Syntax highlighting + +The theme supports syntax highlighting thanks to [highlight.js](https://highlightjs.org). + +It's disabled by default, so you have to enable it by setting `highlight` to `true` in your config. + +You can change the style used for the highlighting by using the `highlightStyle` field. + +Only the "common" languages will be loaded by default. To load more, use `highlightLanguages`. + +A list of all the available styles and languages can be found [here](https://highlightjs.org/static/demo/). + +Please note the style and languages should be written in hyphen-separated lowercase, for example: + +```toml +[params] + highlight = true + highlightStyle = "solarized-dark" + highlightLanguages = ["go", "haskell", "kotlin", "scala", "swift"] +``` diff --git a/docs/themes/minimal/TODO.md b/docs/themes/minimal/TODO.md new file mode 100644 index 00000000000..676d2af08a2 --- /dev/null +++ b/docs/themes/minimal/TODO.md @@ -0,0 +1,10 @@ +# TODO + +- [ ] Dark theme support +- [ ] Custom background image +- [ ] Clickable tags +- [ ] Avatar picture on home page +- [ ] Port theme to Jekyll +- [ ] Custom icons in navigation bar +- [ ] Fix intro positioning on phones +- [ ] Use GitHub API to automatically retrieve projects diff --git a/docs/themes/minimal/archetypes/default.md b/docs/themes/minimal/archetypes/default.md new file mode 100644 index 00000000000..a628182c80d --- /dev/null +++ b/docs/themes/minimal/archetypes/default.md @@ -0,0 +1,5 @@ +--- +title: "{{ replace .TranslationBaseName "-" " " | title }}" +description: "" +draft: true +--- diff --git a/docs/themes/minimal/archetypes/post.md b/docs/themes/minimal/archetypes/post.md new file mode 100644 index 00000000000..e5d34ef15d8 --- /dev/null +++ b/docs/themes/minimal/archetypes/post.md @@ -0,0 +1,6 @@ +--- +title: "{{ replace .TranslationBaseName "-" " " | title }}" +date: {{ dateFormat "2006-01-02" .Date }} +tags: [] +draft: true +--- diff --git a/docs/themes/minimal/archetypes/project.md b/docs/themes/minimal/archetypes/project.md new file mode 100644 index 00000000000..af53acf6b64 --- /dev/null +++ b/docs/themes/minimal/archetypes/project.md @@ -0,0 +1,8 @@ +--- +title: "{{ replace .TranslationBaseName "-" " " | title }}" +description: "" +repo: "" +tags: [] +weight: 0 +draft: true +--- diff --git a/docs/themes/minimal/exampleSite/config.toml b/docs/themes/minimal/exampleSite/config.toml new file mode 100644 index 00000000000..c8d75c6b581 --- /dev/null +++ b/docs/themes/minimal/exampleSite/config.toml @@ -0,0 +1,67 @@ +baseURL = "http://example.com/" +languageCode = "en-us" +title = "Minimal" +theme = "minimal" +disqusShortname = "username" # delete this to disable disqus comments +googleAnalytics = "" + +[params] + author = "Calin Tataru" + description = "Personal blog theme powered by Hugo" + githubUsername = "#" + accent = "red" + showBorder = true + backgroundColor = "white" + font = "Raleway" # should match the name on Google Fonts! + highlight = true + highlightStyle = "default" + highlightLanguages = ["go", "haskell", "kotlin", "scala", "swift"] + +[[menu.main]] + url = "/" + name = "Home" + weight = 1 + +[[menu.main]] + url = "/about/" + name = "About" + weight = 2 + +[[menu.main]] + url = "/post/" + name = "Posts" + weight = 3 + +[[menu.main]] + url = "/project/" + name = "Projects" + weight = 4 + +# Social icons to be shown on the right-hand side of the navigation bar. +# The "name" field should match the name of the icon in Font Awesome. +# The list of available icons can be found at http://fontawesome.io/icons. + +[[menu.icon]] + url = "mailto:me@example.com" + name = "fas fa-envelope" + weight = 1 + +[[menu.icon]] + url = "https://github.com/username/" + name = "fab fa-github" + weight = 2 + +[[menu.icon]] + url = "https://twitter.com/username/" + name = "fab fa-twitter" + weight = 3 + +[[menu.icon]] + url = "https://www.linkedin.com/in/username/" + name = "fab fa-linkedin" + weight = 4 + +[[menu.icon]] + url = "https://www.stackoverflow.com/username/" + name = "fab fa-stack-overflow" + weight = 5 diff --git a/docs/themes/minimal/exampleSite/content/about.md b/docs/themes/minimal/exampleSite/content/about.md new file mode 100644 index 00000000000..4d4898bd437 --- /dev/null +++ b/docs/themes/minimal/exampleSite/content/about.md @@ -0,0 +1,11 @@ +--- +title: About +description: What is Hugo? +--- + +Hugo is a fast and modern static site generator written in Go, and designed to make website creation fun again. +Hugo is a general-purpose website framework. Technically speaking, Hugo is a static site generator. Unlike systems that dynamically build a page with each visitor request, Hugo builds pages when you create or update your content. Since websites are viewed far more often than they are edited, Hugo is designed to provide an optimal viewing experience for your website’s end users and an ideal writing experience for website authors. + +Websites built with Hugo are extremely fast and secure. Hugo sites can be hosted anywhere, including Netlify, Heroku, GoDaddy, DreamHost, GitHub Pages, GitLab Pages, Surge, Aerobatic, Firebase, Google Cloud Storage, Amazon S3, Rackspace, Azure, and CloudFront and work well with CDNs. Hugo sites run without the need for a database or dependencies on expensive runtimes like Ruby, Python, or PHP. + +We think of Hugo as the ideal website creation tool with nearly instant build times, able to rebuild whenever a change is made. diff --git a/docs/themes/minimal/exampleSite/content/post/creating-a-new-theme.md b/docs/themes/minimal/exampleSite/content/post/creating-a-new-theme.md new file mode 100644 index 00000000000..0a957f983fe --- /dev/null +++ b/docs/themes/minimal/exampleSite/content/post/creating-a-new-theme.md @@ -0,0 +1,1143 @@ +--- +title: "Creating a New Theme" +date: 2014-09-28 +tags: ["go", "golang", "hugo", "themes"] +draft: false +--- + +## Introduction + +This tutorial will show you how to create a simple theme in Hugo. I assume that you are familiar with HTML, the bash command line, and that you are comfortable using Markdown to format content. I'll explain how Hugo uses templates and how you can organize your templates to create a theme. I won't cover using CSS to style your theme. + +We'll start with creating a new site with a very basic template. Then we'll add in a few pages and posts. With small variations on that, you will be able to create many different types of web sites. + +In this tutorial, commands that you enter will start with the "$" prompt. The output will follow. Lines that start with "#" are comments that I've added to explain a point. When I show updates to a file, the ":wq" on the last line means to save the file. + +Here's an example: + +``` +## this is a comment +$ echo this is a command +this is a command + +## edit the file +$vi foo.md ++++ +date = "2014-09-28" +title = "creating a new theme" ++++ + +bah and humbug +:wq + +## show it +$ cat foo.md ++++ +date = "2014-09-28" +title = "creating a new theme" ++++ + +bah and humbug +$ +``` + + +## Some Definitions + +There are a few concepts that you need to understand before creating a theme. + +### Skins + +Skins are the files responsible for the look and feel of your site. It’s the CSS that controls colors and fonts, it’s the Javascript that determines actions and reactions. It’s also the rules that Hugo uses to transform your content into the HTML that the site will serve to visitors. + +You have two ways to create a skin. The simplest way is to create it in the ```layouts/``` directory. If you do, then you don’t have to worry about configuring Hugo to recognize it. The first place that Hugo will look for rules and files is in the ```layouts/``` directory so it will always find the skin. + +Your second choice is to create it in a sub-directory of the ```themes/``` directory. If you do, then you must always tell Hugo where to search for the skin. It’s extra work, though, so why bother with it? + +The difference between creating a skin in ```layouts/``` and creating it in ```themes/``` is very subtle. A skin in ```layouts/``` can’t be customized without updating the templates and static files that it is built from. A skin created in ```themes/```, on the other hand, can be and that makes it easier for other people to use it. + +The rest of this tutorial will call a skin created in the ```themes/``` directory a theme. + +Note that you can use this tutorial to create a skin in the ```layouts/``` directory if you wish to. The main difference will be that you won’t need to update the site’s configuration file to use a theme. + +### The Home Page + +The home page, or landing page, is the first page that many visitors to a site see. It is the index.html file in the root directory of the web site. Since Hugo writes files to the public/ directory, our home page is public/index.html. + +### Site Configuration File + +When Hugo runs, it looks for a configuration file that contains settings that override default values for the entire site. The file can use TOML, YAML, or JSON. I prefer to use TOML for my configuration files. If you prefer to use JSON or YAML, you’ll need to translate my examples. You’ll also need to change the name of the file since Hugo uses the extension to determine how to process it. + +Hugo translates Markdown files into HTML. By default, Hugo expects to find Markdown files in your ```content/``` directory and template files in your ```themes/``` directory. It will create HTML files in your ```public/``` directory. You can change this by specifying alternate locations in the configuration file. + +### Content + +Content is stored in text files that contain two sections. The first section is the β€œfront matter,” which is the meta-information on the content. The second section contains Markdown that will be converted to HTML. + +#### Front Matter + +The front matter is information about the content. Like the configuration file, it can be written in TOML, YAML, or JSON. Unlike the configuration file, Hugo doesn’t use the file’s extension to know the format. It looks for markers to signal the type. TOML is surrounded by β€œ`+++`”, YAML by β€œ`---`”, and JSON is enclosed in curly braces. I prefer to use TOML, so you’ll need to translate my examples if you prefer YAML or JSON. + +The information in the front matter is passed into the template before the content is rendered into HTML. + +#### Markdown + +Content is written in Markdown which makes it easier to create the content. Hugo runs the content through a Markdown engine to create the HTML which will be written to the output file. + +### Template Files + +Hugo uses template files to render content into HTML. Template files are a bridge between the content and presentation. Rules in the template define what content is published, where it's published to, and how it will rendered to the HTML file. The template guides the presentation by specifying the style to use. + +There are three types of templates: single, list, and partial. Each type takes a bit of content as input and transforms it based on the commands in the template. + +Hugo uses its knowledge of the content to find the template file used to render the content. If it can’t find a template that is an exact match for the content, it will shift up a level and search from there. It will continue to do so until it finds a matching template or runs out of templates to try. If it can’t find a template, it will use the default template for the site. + +Please note that you can use the front matter to influence Hugo’s choice of templates. + +#### Single Template + +A single template is used to render a single piece of content. For example, an article or post would be a single piece of content and use a single template. + +#### List Template + +A list template renders a group of related content. That could be a summary of recent postings or all articles in a category. List templates can contain multiple groups. + +The homepage template is a special type of list template. Hugo assumes that the home page of your site will act as the portal for the rest of the content in the site. + +#### Partial Template + +A partial template is a template that can be included in other templates. Partial templates must be called using the β€œpartial” template command. They are very handy for rolling up common behavior. For example, your site may have a banner that all pages use. Instead of copying the text of the banner into every single and list template, you could create a partial with the banner in it. That way if you decide to change the banner, you only have to change the partial template. + +## Create a New Site + +Let's use Hugo to create a new web site. I'm a Mac user, so I'll create mine in my home directory, in the Sites folder. If you're using Linux, you might have to create the folder first. + +The "new site" command will create a skeleton of a site. It will give you the basic directory structure and a useable configuration file. + +``` +$ hugo new site ~/Sites/zafta +$ cd ~/Sites/zafta +$ ls -l +total 8 +drwxr-xr-x 7 quoha staff 238 Sep 29 16:49 . +drwxr-xr-x 3 quoha staff 102 Sep 29 16:49 .. +drwxr-xr-x 2 quoha staff 68 Sep 29 16:49 archetypes +-rw-r--r-- 1 quoha staff 82 Sep 29 16:49 config.toml +drwxr-xr-x 2 quoha staff 68 Sep 29 16:49 content +drwxr-xr-x 2 quoha staff 68 Sep 29 16:49 layouts +drwxr-xr-x 2 quoha staff 68 Sep 29 16:49 static +$ +``` + +Take a look in the content/ directory to confirm that it is empty. + +The other directories (archetypes/, layouts/, and static/) are used when customizing a theme. That's a topic for a different tutorial, so please ignore them for now. + +### Generate the HTML For the New Site + +Running the `hugo` command with no options will read all the available content and generate the HTML files. It will also copy all static files (that's everything that's not content). Since we have an empty site, it won't do much, but it will do it very quickly. + +``` +$ hugo --verbose +INFO: 2014/09/29 Using config file: config.toml +INFO: 2014/09/29 syncing from /Users/quoha/Sites/zafta/static/ to /Users/quoha/Sites/zafta/public/ +WARN: 2014/09/29 Unable to locate layout: [index.html _default/list.html _default/single.html] +WARN: 2014/09/29 Unable to locate layout: [404.html] +0 draft content +0 future content +0 pages created +0 tags created +0 categories created +in 2 ms +$ +``` + +The "`--verbose`" flag gives extra information that will be helpful when we build the template. Every line of the output that starts with "INFO:" or "WARN:" is present because we used that flag. The lines that start with "WARN:" are warning messages. We'll go over them later. + +We can verify that the command worked by looking at the directory again. + +``` +$ ls -l +total 8 +drwxr-xr-x 2 quoha staff 68 Sep 29 16:49 archetypes +-rw-r--r-- 1 quoha staff 82 Sep 29 16:49 config.toml +drwxr-xr-x 2 quoha staff 68 Sep 29 16:49 content +drwxr-xr-x 2 quoha staff 68 Sep 29 16:49 layouts +drwxr-xr-x 4 quoha staff 136 Sep 29 17:02 public +drwxr-xr-x 2 quoha staff 68 Sep 29 16:49 static +$ +``` + +See that new public/ directory? Hugo placed all generated content there. When you're ready to publish your web site, that's the place to start. For now, though, let's just confirm that we have what we'd expect from a site with no content. + +``` +$ ls -l public +total 16 +-rw-r--r-- 1 quoha staff 416 Sep 29 17:02 index.xml +-rw-r--r-- 1 quoha staff 262 Sep 29 17:02 sitemap.xml +$ +``` + +Hugo created two XML files, which is standard, but there are no HTML files. + + + +### Test the New Site + +Verify that you can run the built-in web server. It will dramatically shorten your development cycle if you do. Start it by running the "server" command. If it is successful, you will see output similar to the following: + +``` +$ hugo server --verbose +INFO: 2014/09/29 Using config file: /Users/quoha/Sites/zafta/config.toml +INFO: 2014/09/29 syncing from /Users/quoha/Sites/zafta/static/ to /Users/quoha/Sites/zafta/public/ +WARN: 2014/09/29 Unable to locate layout: [index.html _default/list.html _default/single.html] +WARN: 2014/09/29 Unable to locate layout: [404.html] +0 draft content +0 future content +0 pages created +0 tags created +0 categories created +in 2 ms +Serving pages from /Users/quoha/Sites/zafta/public +Web Server is available at http://localhost:1313 +Press Ctrl+C to stop +``` + +Connect to the listed URL (it's on the line that starts with "Web Server"). If everything is working correctly, you should get a page that shows the following: + +``` +index.xml +sitemap.xml +``` + +That's a listing of your public/ directory. Hugo didn't create a home page because our site has no content. When there's no index.html file in a directory, the server lists the files in the directory, which is what you should see in your browser. + +Let’s go back and look at those warnings again. + +``` +WARN: 2014/09/29 Unable to locate layout: [index.html _default/list.html _default/single.html] +WARN: 2014/09/29 Unable to locate layout: [404.html] +``` + +That second warning is easier to explain. We haven’t created a template to be used to generate β€œpage not found errors.” The 404 message is a topic for a separate tutorial. + +Now for the first warning. It is for the home page. You can tell because the first layout that it looked for was β€œindex.html.” That’s only used by the home page. + +I like that the verbose flag causes Hugo to list the files that it's searching for. For the home page, they are index.html, _default/list.html, and _default/single.html. There are some rules that we'll cover later that explain the names and paths. For now, just remember that Hugo couldn't find a template for the home page and it told you so. + +At this point, you've got a working installation and site that we can build upon. All that’s left is to add some content and a theme to display it. + +## Create a New Theme + +Hugo doesn't ship with a default theme. There are a few available (I counted a dozen when I first installed Hugo) and Hugo comes with a command to create new themes. + +We're going to create a new theme called "zafta." Since the goal of this tutorial is to show you how to fill out the files to pull in your content, the theme will not contain any CSS. In other words, ugly but functional. + +All themes have opinions on content and layout. For example, Zafta uses "post" over "blog". Strong opinions make for simpler templates but differing opinions make it tougher to use themes. When you build a theme, consider using the terms that other themes do. + + +### Create a Skeleton + +Use the hugo "new" command to create the skeleton of a theme. This creates the directory structure and places empty files for you to fill out. + +``` +$ hugo new theme zafta + +$ ls -l +total 8 +drwxr-xr-x 2 quoha staff 68 Sep 29 16:49 archetypes +-rw-r--r-- 1 quoha staff 82 Sep 29 16:49 config.toml +drwxr-xr-x 2 quoha staff 68 Sep 29 16:49 content +drwxr-xr-x 2 quoha staff 68 Sep 29 16:49 layouts +drwxr-xr-x 4 quoha staff 136 Sep 29 17:02 public +drwxr-xr-x 2 quoha staff 68 Sep 29 16:49 static +drwxr-xr-x 3 quoha staff 102 Sep 29 17:31 themes + +$ find themes -type f | xargs ls -l +-rw-r--r-- 1 quoha staff 1081 Sep 29 17:31 themes/zafta/LICENSE.md +-rw-r--r-- 1 quoha staff 0 Sep 29 17:31 themes/zafta/archetypes/default.md +-rw-r--r-- 1 quoha staff 0 Sep 29 17:31 themes/zafta/layouts/_default/list.html +-rw-r--r-- 1 quoha staff 0 Sep 29 17:31 themes/zafta/layouts/_default/single.html +-rw-r--r-- 1 quoha staff 0 Sep 29 17:31 themes/zafta/layouts/index.html +-rw-r--r-- 1 quoha staff 0 Sep 29 17:31 themes/zafta/layouts/partials/footer.html +-rw-r--r-- 1 quoha staff 0 Sep 29 17:31 themes/zafta/layouts/partials/header.html +-rw-r--r-- 1 quoha staff 93 Sep 29 17:31 themes/zafta/theme.toml +$ +``` + +The skeleton includes templates (the files ending in .html), license file, a description of your theme (the theme.toml file), and an empty archetype. + +Please take a minute to fill out the theme.toml and LICENSE.md files. They're optional, but if you're going to be distributing your theme, it tells the world who to praise (or blame). It's also nice to declare the license so that people will know how they can use the theme. + +``` +$ vi themes/zafta/theme.toml +author = "michael d henderson" +description = "a minimal working template" +license = "MIT" +name = "zafta" +source_repo = "" +tags = ["tags", "categories"] +:wq + +## also edit themes/zafta/LICENSE.md and change +## the bit that says "YOUR_NAME_HERE" +``` + +Note that the the skeleton's template files are empty. Don't worry, we'll be changing that shortly. + +``` +$ find themes/zafta -name '*.html' | xargs ls -l +-rw-r--r-- 1 quoha staff 0 Sep 29 17:31 themes/zafta/layouts/_default/list.html +-rw-r--r-- 1 quoha staff 0 Sep 29 17:31 themes/zafta/layouts/_default/single.html +-rw-r--r-- 1 quoha staff 0 Sep 29 17:31 themes/zafta/layouts/index.html +-rw-r--r-- 1 quoha staff 0 Sep 29 17:31 themes/zafta/layouts/partials/footer.html +-rw-r--r-- 1 quoha staff 0 Sep 29 17:31 themes/zafta/layouts/partials/header.html +$ +``` + + + +### Update the Configuration File to Use the Theme + +Now that we've got a theme to work with, it's a good idea to add the theme name to the configuration file. This is optional, because you can always add "-t zafta" on all your commands. I like to put it the configuration file because I like shorter command lines. If you don't put it in the configuration file or specify it on the command line, you won't use the template that you're expecting to. + +Edit the file to add the theme, add a title for the site, and specify that all of our content will use the TOML format. + +``` +$ vi config.toml +theme = "zafta" +baseurl = "" +languageCode = "en-us" +title = "zafta - totally refreshing" +MetaDataFormat = "toml" +:wq + +$ +``` + +### Generate the Site + +Now that we have an empty theme, let's generate the site again. + +``` +$ hugo --verbose +INFO: 2014/09/29 Using config file: /Users/quoha/Sites/zafta/config.toml +INFO: 2014/09/29 syncing from /Users/quoha/Sites/zafta/themes/zafta/static/ to /Users/quoha/Sites/zafta/public/ +INFO: 2014/09/29 syncing from /Users/quoha/Sites/zafta/static/ to /Users/quoha/Sites/zafta/public/ +WARN: 2014/09/29 Unable to locate layout: [404.html theme/404.html] +0 draft content +0 future content +0 pages created +0 tags created +0 categories created +in 2 ms +$ +``` + +Did you notice that the output is different? The warning message for the home page has disappeared and we have an additional information line saying that Hugo is syncing from the theme's directory. + +Let's check the public/ directory to see what Hugo's created. + +``` +$ ls -l public +total 16 +drwxr-xr-x 2 quoha staff 68 Sep 29 17:56 css +-rw-r--r-- 1 quoha staff 0 Sep 29 17:56 index.html +-rw-r--r-- 1 quoha staff 407 Sep 29 17:56 index.xml +drwxr-xr-x 2 quoha staff 68 Sep 29 17:56 js +-rw-r--r-- 1 quoha staff 243 Sep 29 17:56 sitemap.xml +$ +``` + +Notice four things: + +1. Hugo created a home page. This is the file public/index.html. +2. Hugo created a css/ directory. +3. Hugo created a js/ directory. +4. Hugo claimed that it created 0 pages. It created a file and copied over static files, but didn't create any pages. That's because it considers a "page" to be a file created directly from a content file. It doesn't count things like the index.html files that it creates automatically. + +#### The Home Page + +Hugo supports many different types of templates. The home page is special because it gets its own type of template and its own template file. The file, layouts/index.html, is used to generate the HTML for the home page. The Hugo documentation says that this is the only required template, but that depends. Hugo's warning message shows that it looks for three different templates: + +``` +WARN: 2014/09/29 Unable to locate layout: [index.html _default/list.html _default/single.html] +``` + +If it can't find any of these, it completely skips creating the home page. We noticed that when we built the site without having a theme installed. + +When Hugo created our theme, it created an empty home page template. Now, when we build the site, Hugo finds the template and uses it to generate the HTML for the home page. Since the template file is empty, the HTML file is empty, too. If the template had any rules in it, then Hugo would have used them to generate the home page. + +``` +$ find . -name index.html | xargs ls -l +-rw-r--r-- 1 quoha staff 0 Sep 29 20:21 ./public/index.html +-rw-r--r-- 1 quoha staff 0 Sep 29 17:31 ./themes/zafta/layouts/index.html +$ +``` + +#### The Magic of Static + +Hugo does two things when generating the site. It uses templates to transform content into HTML and it copies static files into the site. Unlike content, static files are not transformed. They are copied exactly as they are. + +Hugo assumes that your site will use both CSS and JavaScript, so it creates directories in your theme to hold them. Remember opinions? Well, Hugo's opinion is that you'll store your CSS in a directory named css/ and your JavaScript in a directory named js/. If you don't like that, you can change the directory names in your theme directory or even delete them completely. Hugo's nice enough to offer its opinion, then behave nicely if you disagree. + +``` +$ find themes/zafta -type d | xargs ls -ld +drwxr-xr-x 7 quoha staff 238 Sep 29 17:38 themes/zafta +drwxr-xr-x 3 quoha staff 102 Sep 29 17:31 themes/zafta/archetypes +drwxr-xr-x 5 quoha staff 170 Sep 29 17:31 themes/zafta/layouts +drwxr-xr-x 4 quoha staff 136 Sep 29 17:31 themes/zafta/layouts/_default +drwxr-xr-x 4 quoha staff 136 Sep 29 17:31 themes/zafta/layouts/partials +drwxr-xr-x 4 quoha staff 136 Sep 29 17:31 themes/zafta/static +drwxr-xr-x 2 quoha staff 68 Sep 29 17:31 themes/zafta/static/css +drwxr-xr-x 2 quoha staff 68 Sep 29 17:31 themes/zafta/static/js +$ +``` + +## The Theme Development Cycle + +When you're working on a theme, you will make changes in the theme's directory, rebuild the site, and check your changes in the browser. Hugo makes this very easy: + +1. Purge the public/ directory. +2. Run the built in web server in watch mode. +3. Open your site in a browser. +4. Update the theme. +5. Glance at your browser window to see changes. +6. Return to step 4. + +I’ll throw in one more opinion: never work on a theme on a live site. Always work on a copy of your site. Make changes to your theme, test them, then copy them up to your site. For added safety, use a tool like Git to keep a revision history of your content and your theme. Believe me when I say that it is too easy to lose both your mind and your changes. + +Check the main Hugo site for information on using Git with Hugo. + +### Purge the public/ Directory + +When generating the site, Hugo will create new files and update existing ones in the ```public/``` directory. It will not delete files that are no longer used. For example, files that were created in the wrong directory or with the wrong title will remain. If you leave them, you might get confused by them later. I recommend cleaning out your site prior to generating it. + +Note: If you're building on an SSD, you should ignore this. Churning on a SSD can be costly. + +### Hugo's Watch Option + +Hugo's "`--watch`" option will monitor the content/ and your theme directories for changes and rebuild the site automatically. + +### Live Reload + +Hugo's built in web server supports live reload. As pages are saved on the server, the browser is told to refresh the page. Usually, this happens faster than you can say, "Wow, that's totally amazing." + +### Development Commands + +Use the following commands as the basis for your workflow. + +``` +## purge old files. hugo will recreate the public directory. +## +$ rm -rf public +## +## run hugo in watch mode +## +$ hugo server --watch --verbose +``` + +Here's sample output showing Hugo detecting a change to the template for the home page. Once generated, the web browser automatically reloaded the page. I've said this before, it's amazing. + + +``` +$ rm -rf public +$ hugo server --watch --verbose +INFO: 2014/09/29 Using config file: /Users/quoha/Sites/zafta/config.toml +INFO: 2014/09/29 syncing from /Users/quoha/Sites/zafta/themes/zafta/static/ to /Users/quoha/Sites/zafta/public/ +INFO: 2014/09/29 syncing from /Users/quoha/Sites/zafta/static/ to /Users/quoha/Sites/zafta/public/ +WARN: 2014/09/29 Unable to locate layout: [404.html theme/404.html] +0 draft content +0 future content +0 pages created +0 tags created +0 categories created +in 2 ms +Watching for changes in /Users/quoha/Sites/zafta/content +Serving pages from /Users/quoha/Sites/zafta/public +Web Server is available at http://localhost:1313 +Press Ctrl+C to stop +INFO: 2014/09/29 File System Event: ["/Users/quoha/Sites/zafta/themes/zafta/layouts/index.html": MODIFY|ATTRIB] +Change detected, rebuilding site + +WARN: 2014/09/29 Unable to locate layout: [404.html theme/404.html] +0 draft content +0 future content +0 pages created +0 tags created +0 categories created +in 1 ms +``` + +## Update the Home Page Template + +The home page is one of a few special pages that Hugo creates automatically. As mentioned earlier, it looks for one of three files in the theme's layout/ directory: + +1. index.html +2. _default/list.html +3. _default/single.html + +We could update one of the default templates, but a good design decision is to update the most specific template available. That's not a hard and fast rule (in fact, we'll break it a few times in this tutorial), but it is a good generalization. + +### Make a Static Home Page + +Right now, that page is empty because we don't have any content and we don't have any logic in the template. Let's change that by adding some text to the template. + +``` +$ vi themes/zafta/layouts/index.html + + + +

hugo says hello!

+ + +:wq + +$ +``` + +Build the web site and then verify the results. + +``` +$ hugo --verbose +INFO: 2014/09/29 Using config file: /Users/quoha/Sites/zafta/config.toml +INFO: 2014/09/29 syncing from /Users/quoha/Sites/zafta/themes/zafta/static/ to /Users/quoha/Sites/zafta/public/ +INFO: 2014/09/29 syncing from /Users/quoha/Sites/zafta/static/ to /Users/quoha/Sites/zafta/public/ +WARN: 2014/09/29 Unable to locate layout: [404.html theme/404.html] +0 draft content +0 future content +0 pages created +0 tags created +0 categories created +in 2 ms + +$ find public -type f -name '*.html' | xargs ls -l +-rw-r--r-- 1 quoha staff 78 Sep 29 21:26 public/index.html + +$ cat public/index.html + + + +

hugo says hello!

+ +``` + +#### Live Reload + +Note: If you're running the server with the `--watch` option, you'll see different content in the file: + +``` +$ cat public/index.html + + + +

hugo says hello!

+ + +``` + +When you use `--watch`, the Live Reload script is added by Hugo. Look for live reload in the documentation to see what it does and how to disable it. + +### Build a "Dynamic" Home Page + +"Dynamic home page?" Hugo's a static web site generator, so this seems an odd thing to say. I mean let's have the home page automatically reflect the content in the site every time Hugo builds it. We'll use iteration in the template to do that. + +#### Create New Posts + +Now that we have the home page generating static content, let's add some content to the site. We'll display these posts as a list on the home page and on their own page, too. + +Hugo has a command to generate a skeleton post, just like it does for sites and themes. + +``` +$ hugo --verbose new post/first.md +INFO: 2014/09/29 Using config file: /Users/quoha/Sites/zafta/config.toml +INFO: 2014/09/29 attempting to create post/first.md of post +INFO: 2014/09/29 curpath: /Users/quoha/Sites/zafta/themes/zafta/archetypes/default.md +ERROR: 2014/09/29 Unable to Cast to map[string]interface{} + +$ +``` + +That wasn't very nice, was it? + +The "new" command uses an archetype to create the post file. Hugo created an empty default archetype file, but that causes an error when there's a theme. For me, the workaround was to create an archetypes file specifically for the post type. + +``` +$ vi themes/zafta/archetypes/post.md ++++ +Description = "" +Tags = [] +Categories = [] ++++ +:wq + +$ find themes/zafta/archetypes -type f | xargs ls -l +-rw-r--r-- 1 quoha staff 0 Sep 29 21:53 themes/zafta/archetypes/default.md +-rw-r--r-- 1 quoha staff 51 Sep 29 21:54 themes/zafta/archetypes/post.md + +$ hugo --verbose new post/first.md +INFO: 2014/09/29 Using config file: /Users/quoha/Sites/zafta/config.toml +INFO: 2014/09/29 attempting to create post/first.md of post +INFO: 2014/09/29 curpath: /Users/quoha/Sites/zafta/themes/zafta/archetypes/post.md +INFO: 2014/09/29 creating /Users/quoha/Sites/zafta/content/post/first.md +/Users/quoha/Sites/zafta/content/post/first.md created + +$ hugo --verbose new post/second.md +INFO: 2014/09/29 Using config file: /Users/quoha/Sites/zafta/config.toml +INFO: 2014/09/29 attempting to create post/second.md of post +INFO: 2014/09/29 curpath: /Users/quoha/Sites/zafta/themes/zafta/archetypes/post.md +INFO: 2014/09/29 creating /Users/quoha/Sites/zafta/content/post/second.md +/Users/quoha/Sites/zafta/content/post/second.md created + +$ ls -l content/post +total 16 +-rw-r--r-- 1 quoha staff 104 Sep 29 21:54 first.md +-rw-r--r-- 1 quoha staff 105 Sep 29 21:57 second.md + +$ cat content/post/first.md ++++ +Categories = [] +Description = "" +Tags = [] +date = "2014-09-29T21:54:53-05:00" +title = "first" + ++++ +my first post + +$ cat content/post/second.md ++++ +Categories = [] +Description = "" +Tags = [] +date = "2014-09-29T21:57:09-05:00" +title = "second" + ++++ +my second post + +$ +``` + +Build the web site and then verify the results. + +``` +$ rm -rf public +$ hugo --verbose +INFO: 2014/09/29 Using config file: /Users/quoha/Sites/zafta/config.toml +INFO: 2014/09/29 syncing from /Users/quoha/Sites/zafta/themes/zafta/static/ to /Users/quoha/Sites/zafta/public/ +INFO: 2014/09/29 syncing from /Users/quoha/Sites/zafta/static/ to /Users/quoha/Sites/zafta/public/ +INFO: 2014/09/29 found taxonomies: map[string]string{"category":"categories", "tag":"tags"} +WARN: 2014/09/29 Unable to locate layout: [404.html theme/404.html] +0 draft content +0 future content +2 pages created +0 tags created +0 categories created +in 4 ms +$ +``` + +The output says that it created 2 pages. Those are our new posts: + +``` +$ find public -type f -name '*.html' | xargs ls -l +-rw-r--r-- 1 quoha staff 78 Sep 29 22:13 public/index.html +-rw-r--r-- 1 quoha staff 0 Sep 29 22:13 public/post/first/index.html +-rw-r--r-- 1 quoha staff 0 Sep 29 22:13 public/post/index.html +-rw-r--r-- 1 quoha staff 0 Sep 29 22:13 public/post/second/index.html +$ +``` + +The new files are empty because because the templates used to generate the content are empty. The homepage doesn't show the new content, either. We have to update the templates to add the posts. + +### List and Single Templates + +In Hugo, we have three major kinds of templates. There's the home page template that we updated previously. It is used only by the home page. We also have "single" templates which are used to generate output for a single content file. We also have "list" templates that are used to group multiple pieces of content before generating output. + +Generally speaking, list templates are named "list.html" and single templates are named "single.html." + +There are three other types of templates: partials, content views, and terms. We will not go into much detail on these. + +### Add Content to the Homepage + +The home page will contain a list of posts. Let's update its template to add the posts that we just created. The logic in the template will run every time we build the site. + +``` +$ vi themes/zafta/layouts/index.html + + + + {{ range first 10 .Data.Pages }} +

{{ .Title }}

+ {{ end }} + + +:wq + +$ +``` + +Hugo uses the Go template engine. That engine scans the template files for commands which are enclosed between "{{" and "}}". In our template, the commands are: + +1. range +2. .Title +3. end + +The "range" command is an iterator. We're going to use it to go through the first ten pages. Every HTML file that Hugo creates is treated as a page, so looping through the list of pages will look at every file that will be created. + +The ".Title" command prints the value of the "title" variable. Hugo pulls it from the front matter in the Markdown file. + +The "end" command signals the end of the range iterator. The engine loops back to the top of the iteration when it finds "end." Everything between the "range" and "end" is evaluated every time the engine goes through the iteration. In this file, that would cause the title from the first ten pages to be output as heading level one. + +It's helpful to remember that some variables, like .Data, are created before any output files. Hugo loads every content file into the variable and then gives the template a chance to process before creating the HTML files. + +Build the web site and then verify the results. + +``` +$ rm -rf public +$ hugo --verbose +INFO: 2014/09/29 Using config file: /Users/quoha/Sites/zafta/config.toml +INFO: 2014/09/29 syncing from /Users/quoha/Sites/zafta/themes/zafta/static/ to /Users/quoha/Sites/zafta/public/ +INFO: 2014/09/29 syncing from /Users/quoha/Sites/zafta/static/ to /Users/quoha/Sites/zafta/public/ +INFO: 2014/09/29 found taxonomies: map[string]string{"tag":"tags", "category":"categories"} +WARN: 2014/09/29 Unable to locate layout: [404.html theme/404.html] +0 draft content +0 future content +2 pages created +0 tags created +0 categories created +in 4 ms +$ find public -type f -name '*.html' | xargs ls -l +-rw-r--r-- 1 quoha staff 94 Sep 29 22:23 public/index.html +-rw-r--r-- 1 quoha staff 0 Sep 29 22:23 public/post/first/index.html +-rw-r--r-- 1 quoha staff 0 Sep 29 22:23 public/post/index.html +-rw-r--r-- 1 quoha staff 0 Sep 29 22:23 public/post/second/index.html +$ cat public/index.html + + + + +

second

+ +

first

+ + + +$ +``` + +Congratulations, the home page shows the title of the two posts. The posts themselves are still empty, but let's take a moment to appreciate what we've done. Your template now generates output dynamically. Believe it or not, by inserting the range command inside of those curly braces, you've learned everything you need to know to build a theme. All that's really left is understanding which template will be used to generate each content file and becoming familiar with the commands for the template engine. + +And, if that were entirely true, this tutorial would be much shorter. There are a few things to know that will make creating a new template much easier. Don't worry, though, that's all to come. + +### Add Content to the Posts + +We're working with posts, which are in the content/post/ directory. That means that their section is "post" (and if we don't do something weird, their type is also "post"). + +Hugo uses the section and type to find the template file for every piece of content. Hugo will first look for a template file that matches the section or type name. If it can't find one, then it will look in the _default/ directory. There are some twists that we'll cover when we get to categories and tags, but for now we can assume that Hugo will try post/single.html, then _default/single.html. + +Now that we know the search rule, let's see what we actually have available: + +``` +$ find themes/zafta -name single.html | xargs ls -l +-rw-r--r-- 1 quoha staff 132 Sep 29 17:31 themes/zafta/layouts/_default/single.html +``` + +We could create a new template, post/single.html, or change the default. Since we don't know of any other content types, let's start with updating the default. + +Remember, any content that we haven't created a template for will end up using this template. That can be good or bad. Bad because I know that we're going to be adding different types of content and we're going to end up undoing some of the changes we've made. It's good because we'll be able to see immediate results. It's also good to start here because we can start to build the basic layout for the site. As we add more content types, we'll refactor this file and move logic around. Hugo makes that fairly painless, so we'll accept the cost and proceed. + +Please see the Hugo documentation on template rendering for all the details on determining which template to use. And, as the docs mention, if you're building a single page application (SPA) web site, you can delete all of the other templates and work with just the default single page. That's a refreshing amount of joy right there. + +#### Update the Template File + +``` +$ vi themes/zafta/layouts/_default/single.html + + + + {{ .Title }} + + +

{{ .Title }}

+ {{ .Content }} + + +:wq + +$ +``` + +Build the web site and verify the results. + +``` +$ rm -rf public +$ hugo --verbose +INFO: 2014/09/29 Using config file: /Users/quoha/Sites/zafta/config.toml +INFO: 2014/09/29 syncing from /Users/quoha/Sites/zafta/themes/zafta/static/ to /Users/quoha/Sites/zafta/public/ +INFO: 2014/09/29 syncing from /Users/quoha/Sites/zafta/static/ to /Users/quoha/Sites/zafta/public/ +INFO: 2014/09/29 found taxonomies: map[string]string{"tag":"tags", "category":"categories"} +WARN: 2014/09/29 Unable to locate layout: [404.html theme/404.html] +0 draft content +0 future content +2 pages created +0 tags created +0 categories created +in 4 ms + +$ find public -type f -name '*.html' | xargs ls -l +-rw-r--r-- 1 quoha staff 94 Sep 29 22:40 public/index.html +-rw-r--r-- 1 quoha staff 125 Sep 29 22:40 public/post/first/index.html +-rw-r--r-- 1 quoha staff 0 Sep 29 22:40 public/post/index.html +-rw-r--r-- 1 quoha staff 128 Sep 29 22:40 public/post/second/index.html + +$ cat public/post/first/index.html + + + + first + + +

first

+

my first post

+ + + + +$ cat public/post/second/index.html + + + + second + + +

second

+

my second post

+ + + +$ +``` + +Notice that the posts now have content. You can go to localhost:1313/post/first to verify. + +### Linking to Content + +The posts are on the home page. Let's add a link from there to the post. Since this is the home page, we'll update its template. + +``` +$ vi themes/zafta/layouts/index.html + + + + {{ range first 10 .Data.Pages }} +

{{ .Title }}

+ {{ end }} + + +``` + +Build the web site and verify the results. + +``` +$ rm -rf public +$ hugo --verbose +INFO: 2014/09/29 Using config file: /Users/quoha/Sites/zafta/config.toml +INFO: 2014/09/29 syncing from /Users/quoha/Sites/zafta/themes/zafta/static/ to /Users/quoha/Sites/zafta/public/ +INFO: 2014/09/29 syncing from /Users/quoha/Sites/zafta/static/ to /Users/quoha/Sites/zafta/public/ +INFO: 2014/09/29 found taxonomies: map[string]string{"tag":"tags", "category":"categories"} +WARN: 2014/09/29 Unable to locate layout: [404.html theme/404.html] +0 draft content +0 future content +2 pages created +0 tags created +0 categories created +in 4 ms + +$ find public -type f -name '*.html' | xargs ls -l +-rw-r--r-- 1 quoha staff 149 Sep 29 22:44 public/index.html +-rw-r--r-- 1 quoha staff 125 Sep 29 22:44 public/post/first/index.html +-rw-r--r-- 1 quoha staff 0 Sep 29 22:44 public/post/index.html +-rw-r--r-- 1 quoha staff 128 Sep 29 22:44 public/post/second/index.html + +$ cat public/index.html + + + + +

second

+ +

first

+ + + + +$ +``` + +### Create a Post Listing + +We have the posts displaying on the home page and on their own page. We also have a file public/post/index.html that is empty. Let's make it show a list of all posts (not just the first ten). + +We need to decide which template to update. This will be a listing, so it should be a list template. Let's take a quick look and see which list templates are available. + +``` +$ find themes/zafta -name list.html | xargs ls -l +-rw-r--r-- 1 quoha staff 0 Sep 29 17:31 themes/zafta/layouts/_default/list.html +``` + +As with the single post, we have to decide to update _default/list.html or create post/list.html. We still don't have multiple content types, so let's stay consistent and update the default list template. + +## Creating Top Level Pages + +Let's add an "about" page and display it at the top level (as opposed to a sub-level like we did with posts). + +The default in Hugo is to use the directory structure of the content/ directory to guide the location of the generated html in the public/ directory. Let's verify that by creating an "about" page at the top level: + +``` +$ vi content/about.md ++++ +title = "about" +description = "about this site" +date = "2014-09-27" +slug = "about time" ++++ + +## about us + +i'm speechless +:wq +``` + +Generate the web site and verify the results. + +``` +$ find public -name '*.html' | xargs ls -l +-rw-rw-r-- 1 mdhender staff 334 Sep 27 15:08 public/about-time/index.html +-rw-rw-r-- 1 mdhender staff 527 Sep 27 15:08 public/index.html +-rw-rw-r-- 1 mdhender staff 358 Sep 27 15:08 public/post/first-post/index.html +-rw-rw-r-- 1 mdhender staff 0 Sep 27 15:08 public/post/index.html +-rw-rw-r-- 1 mdhender staff 342 Sep 27 15:08 public/post/second-post/index.html +``` + +Notice that the page wasn't created at the top level. It was created in a sub-directory named 'about-time/'. That name came from our slug. Hugo will use the slug to name the generated content. It's a reasonable default, by the way, but we can learn a few things by fighting it for this file. + +One other thing. Take a look at the home page. + +``` +$ cat public/index.html + + + +

creating a new theme

+

about

+

second

+

first

+ + +``` + +Notice that the "about" link is listed with the posts? That's not desirable, so let's change that first. + +``` +$ vi themes/zafta/layouts/index.html + + + +

posts

+ {{ range first 10 .Data.Pages }} + {{ if eq .Type "post"}} +

{{ .Title }}

+ {{ end }} + {{ end }} + +

pages

+ {{ range .Data.Pages }} + {{ if eq .Type "page" }} +

{{ .Title }}

+ {{ end }} + {{ end }} + + +:wq +``` + +Generate the web site and verify the results. The home page has two sections, posts and pages, and each section has the right set of headings and links in it. + +But, that about page still renders to about-time/index.html. + +``` +$ find public -name '*.html' | xargs ls -l +-rw-rw-r-- 1 mdhender staff 334 Sep 27 15:33 public/about-time/index.html +-rw-rw-r-- 1 mdhender staff 645 Sep 27 15:33 public/index.html +-rw-rw-r-- 1 mdhender staff 358 Sep 27 15:33 public/post/first-post/index.html +-rw-rw-r-- 1 mdhender staff 0 Sep 27 15:33 public/post/index.html +-rw-rw-r-- 1 mdhender staff 342 Sep 27 15:33 public/post/second-post/index.html +``` + +Knowing that hugo is using the slug to generate the file name, the simplest solution is to change the slug. Let's do it the hard way and change the permalink in the configuration file. + +``` +$ vi config.toml +[permalinks] + page = "/:title/" + about = "/:filename/" +``` + +Generate the web site and verify that this didn't work. Hugo lets "slug" or "URL" override the permalinks setting in the configuration file. Go ahead and comment out the slug in content/about.md, then generate the web site to get it to be created in the right place. + +## Sharing Templates + +If you've been following along, you probably noticed that posts have titles in the browser and the home page doesn't. That's because we didn't put the title in the home page's template (layouts/index.html). That's an easy thing to do, but let's look at a different option. + +We can put the common bits into a shared template that's stored in the themes/zafta/layouts/partials/ directory. + +### Create the Header and Footer Partials + +In Hugo, a partial is a sugar-coated template. Normally a template reference has a path specified. Partials are different. Hugo searches for them along a TODO defined search path. This makes it easier for end-users to override the theme's presentation. + +``` +$ vi themes/zafta/layouts/partials/header.html + + + + {{ .Title }} + + +:wq + +$ vi themes/zafta/layouts/partials/footer.html + + +:wq +``` + +### Update the Home Page Template to Use the Partials + +The most noticeable difference between a template call and a partials call is the lack of path: + +``` +{{ template "theme/partials/header.html" . }} +``` +versus +``` +{{ partial "header.html" . }} +``` +Both pass in the context. + +Let's change the home page template to use these new partials. + +``` +$ vi themes/zafta/layouts/index.html +{{ partial "header.html" . }} + +

posts

+ {{ range first 10 .Data.Pages }} + {{ if eq .Type "post"}} +

{{ .Title }}

+ {{ end }} + {{ end }} + +

pages

+ {{ range .Data.Pages }} + {{ if or (eq .Type "page") (eq .Type "about") }} +

{{ .Type }} - {{ .Title }} - {{ .RelPermalink }}

+ {{ end }} + {{ end }} + +{{ partial "footer.html" . }} +:wq +``` + +Generate the web site and verify the results. The title on the home page is now "your title here", which comes from the "title" variable in the config.toml file. + +### Update the Default Single Template to Use the Partials + +``` +$ vi themes/zafta/layouts/_default/single.html +{{ partial "header.html" . }} + +

{{ .Title }}

+ {{ .Content }} + +{{ partial "footer.html" . }} +:wq +``` + +Generate the web site and verify the results. The title on the posts and the about page should both reflect the value in the markdown file. + +## Add β€œDate Published” to Posts + +It's common to have posts display the date that they were written or published, so let's add that. The front matter of our posts has a variable named "date." It's usually the date the content was created, but let's pretend that's the value we want to display. + +### Add β€œDate Published” to the Template + +We'll start by updating the template used to render the posts. The template code will look like: + +``` +{{ .Date.Format "Mon, Jan 2, 2006" }} +``` + +Posts use the default single template, so we'll change that file. + +``` +$ vi themes/zafta/layouts/_default/single.html +{{ partial "header.html" . }} + +

{{ .Title }}

+

{{ .Date.Format "Mon, Jan 2, 2006" }}

+ {{ .Content }} + +{{ partial "footer.html" . }} +:wq +``` + +Generate the web site and verify the results. The posts now have the date displayed in them. There's a problem, though. The "about" page also has the date displayed. + +As usual, there are a couple of ways to make the date display only on posts. We could do an "if" statement like we did on the home page. Another way would be to create a separate template for posts. + +The "if" solution works for sites that have just a couple of content types. It aligns with the principle of "code for today," too. + +Let's assume, though, that we've made our site so complex that we feel we have to create a new template type. In Hugo-speak, we're going to create a section template. + +Let's restore the default single template before we forget. + +``` +$ mkdir themes/zafta/layouts/post +$ vi themes/zafta/layouts/_default/single.html +{{ partial "header.html" . }} + +

{{ .Title }}

+ {{ .Content }} + +{{ partial "footer.html" . }} +:wq +``` + +Now we'll update the post's version of the single template. If you remember Hugo's rules, the template engine will use this version over the default. + +``` +$ vi themes/zafta/layouts/post/single.html +{{ partial "header.html" . }} + +

{{ .Title }}

+

{{ .Date.Format "Mon, Jan 2, 2006" }}

+ {{ .Content }} + +{{ partial "footer.html" . }} +:wq + +``` + +Note that we removed the date logic from the default template and put it in the post template. Generate the web site and verify the results. Posts have dates and the about page doesn't. + +### Don't Repeat Yourself + +DRY is a good design goal and Hugo does a great job supporting it. Part of the art of a good template is knowing when to add a new template and when to update an existing one. While you're figuring that out, accept that you'll be doing some refactoring. Hugo makes that easy and fast, so it's okay to delay splitting up a template. diff --git a/docs/themes/minimal/exampleSite/content/post/goisforlovers.md b/docs/themes/minimal/exampleSite/content/post/goisforlovers.md new file mode 100644 index 00000000000..5e8a5836dee --- /dev/null +++ b/docs/themes/minimal/exampleSite/content/post/goisforlovers.md @@ -0,0 +1,333 @@ +--- +title: "(Hu)go Template Primer" +date: 2014-04-02 +tags: [ "go", "golang", "template", "themes", "development"] +draft: false +--- + +Hugo uses the excellent [go][] [html/template][gohtmltemplate] library for +its template engine. It is an extremely lightweight engine that provides a very +small amount of logic. In our experience that it is just the right amount of +logic to be able to create a good static website. If you have used other +template systems from different languages or frameworks you will find a lot of +similarities in go templates. + +This document is a brief primer on using go templates. The [go docs][gohtmltemplate] +provide more details. + +## Introduction to Go Templates + +Go templates provide an extremely simple template language. It adheres to the +belief that only the most basic of logic belongs in the template or view layer. +One consequence of this simplicity is that go templates parse very quickly. + +A unique characteristic of go templates is they are content aware. Variables and +content will be sanitized depending on the context of where they are used. More +details can be found in the [go docs][gohtmltemplate]. + +## Basic Syntax + +Go lang templates are html files with the addition of variables and +functions. + +**Go variables and functions are accessible within {{ }}** + +Accessing a predefined variable "foo": + + {{ foo }} + +**Parameters are separated using spaces** + +Calling the add function with input of 1, 2: + + {{ add 1 2 }} + +**Methods and fields are accessed via dot notation** + +Accessing the Page Parameter "bar" + + {{ .Params.bar }} + +**Parentheses can be used to group items together** + + {{ if or (isset .Params "alt") (isset .Params "caption") }} Caption {{ end }} + + +## Variables + +Each go template has a struct (object) made available to it. In hugo each +template is passed either a page or a node struct depending on which type of +page you are rendering. More details are available on the +[variables](/layout/variables) page. + +A variable is accessed by referencing the variable name. + + {{ .Title }} + +Variables can also be defined and referenced. + + {{ $address := "123 Main St."}} + {{ $address }} + + +## Functions + +Go template ship with a few functions which provide basic functionality. The go +template system also provides a mechanism for applications to extend the +available functions with their own. [Hugo template +functions](/layout/functions) provide some additional functionality we believe +are useful for building websites. Functions are called by using their name +followed by the required parameters separated by spaces. Template +functions cannot be added without recompiling hugo. + +**Example:** + + {{ add 1 2 }} + +## Includes + +When including another template you will pass to it the data it will be +able to access. To pass along the current context please remember to +include a trailing dot. The templates location will always be starting at +the /layout/ directory within Hugo. + +**Example:** + + {{ template "chrome/header.html" . }} + + +## Logic + +Go templates provide the most basic iteration and conditional logic. + +### Iteration + +Just like in go, the go templates make heavy use of range to iterate over +a map, array or slice. The following are different examples of how to use +range. + +**Example 1: Using Context** + + {{ range array }} + {{ . }} + {{ end }} + +**Example 2: Declaring value variable name** + + {{range $element := array}} + {{ $element }} + {{ end }} + +**Example 2: Declaring key and value variable name** + + {{range $index, $element := array}} + {{ $index }} + {{ $element }} + {{ end }} + +### Conditionals + +If, else, with, or, & and provide the framework for handling conditional +logic in Go Templates. Like range, each statement is closed with `end`. + + +Go Templates treat the following values as false: + +* false +* 0 +* any array, slice, map, or string of length zero + +**Example 1: If** + + {{ if isset .Params "title" }}

{{ index .Params "title" }}

{{ end }} + +**Example 2: If -> Else** + + {{ if isset .Params "alt" }} + {{ index .Params "alt" }} + {{else}} + {{ index .Params "caption" }} + {{ end }} + +**Example 3: And & Or** + + {{ if and (or (isset .Params "title") (isset .Params "caption")) (isset .Params "attr")}} + +**Example 4: With** + +An alternative way of writing "if" and then referencing the same value +is to use "with" instead. With rebinds the context `.` within its scope, +and skips the block if the variable is absent. + +The first example above could be simplified as: + + {{ with .Params.title }}

{{ . }}

{{ end }} + +**Example 5: If -> Else If** + + {{ if isset .Params "alt" }} + {{ index .Params "alt" }} + {{ else if isset .Params "caption" }} + {{ index .Params "caption" }} + {{ end }} + +## Pipes + +One of the most powerful components of go templates is the ability to +stack actions one after another. This is done by using pipes. Borrowed +from unix pipes, the concept is simple, each pipeline's output becomes the +input of the following pipe. + +Because of the very simple syntax of go templates, the pipe is essential +to being able to chain together function calls. One limitation of the +pipes is that they only can work with a single value and that value +becomes the last parameter of the next pipeline. + +A few simple examples should help convey how to use the pipe. + +**Example 1 :** + + {{ if eq 1 1 }} Same {{ end }} + +is the same as + + {{ eq 1 1 | if }} Same {{ end }} + +It does look odd to place the if at the end, but it does provide a good +illustration of how to use the pipes. + +**Example 2 :** + + {{ index .Params "disqus_url" | html }} + +Access the page parameter called "disqus_url" and escape the HTML. + +**Example 3 :** + + {{ if or (or (isset .Params "title") (isset .Params "caption")) (isset .Params "attr")}} + Stuff Here + {{ end }} + +Could be rewritten as + + {{ isset .Params "caption" | or isset .Params "title" | or isset .Params "attr" | if }} + Stuff Here + {{ end }} + + +## Context (aka. the dot) + +The most easily overlooked concept to understand about go templates is that {{ . }} +always refers to the current context. In the top level of your template this +will be the data set made available to it. Inside of a iteration it will have +the value of the current item. When inside of a loop the context has changed. . +will no longer refer to the data available to the entire page. If you need to +access this from within the loop you will likely want to set it to a variable +instead of depending on the context. + +**Example:** + + {{ $title := .Site.Title }} + {{ range .Params.tags }} +
  • {{ . }} - {{ $title }}
  • + {{ end }} + +Notice how once we have entered the loop the value of {{ . }} has changed. We +have defined a variable outside of the loop so we have access to it from within +the loop. + +# Hugo Parameters + +Hugo provides the option of passing values to the template language +through the site configuration (for sitewide values), or through the meta +data of each specific piece of content. You can define any values of any +type (supported by your front matter/config format) and use them however +you want to inside of your templates. + + +## Using Content (page) Parameters + +In each piece of content you can provide variables to be used by the +templates. This happens in the [front matter](/content/front-matter). + +An example of this is used in this documentation site. Most of the pages +benefit from having the table of contents provided. Sometimes the TOC just +doesn't make a lot of sense. We've defined a variable in our front matter +of some pages to turn off the TOC from being displayed. + +Here is the example front matter: + +``` +--- +title: "Permalinks" +date: "2013-11-18" +aliases: + - "/doc/permalinks/" +groups: ["extras"] +groups_weight: 30 +notoc: true +--- +``` + +Here is the corresponding code inside of the template: + + {{ if not .Params.notoc }} +
    + {{ .TableOfContents }} +
    + {{ end }} + + + +## Using Site (config) Parameters +In your top-level configuration file (eg, `config.yaml`) you can define site +parameters, which are values which will be available to you in chrome. + +For instance, you might declare: + +```yaml +params: + CopyrightHTML: "Copyright © 2013 John Doe. All Rights Reserved." + TwitterUser: "spf13" + SidebarRecentLimit: 5 +``` + +Within a footer layout, you might then declare a `