removed solc dependency (#1759)

Author: felix314159

CLAUDE.md

@@ -32,7 +32,6 @@ All commands use `uv run` prefix.
 
 ```bash
 uv sync --all-extras
-uv run solc-select use 0.8.24 --always-install
 uvx pre-commit install
 ```
 

CONTRIBUTING.md

@@ -85,7 +85,6 @@ We welcome contributions via pull requests! This section will guide you through
     uv python install 3.12
     uv python pin 3.12
     uv sync --all-extras
-    uv run solc-select use 0.8.24 --always-install
     ```
 
     See [installation troubleshooting](https://eest.ethereum.org/main/getting_started/installation_troubleshooting) if you encounter issues.

README.md

@@ -109,7 +109,6 @@ cd execution-spec-tests
 uv python install 3.11
 uv python pin 3.11
 uv sync --all-extras
-uv run solc-select use 0.8.24 --always-install
 ```
 
 See [Installation Troubleshooting](https://eest.ethereum.org/main/getting_started/installation_troubleshooting/) in the online docs if you encounter issues.

docs/CHANGELOG.md

@@ -10,6 +10,11 @@ Test fixtures for use by clients are available for each release on the [Github r
 
 - Python 3.10 support was removed in this release ([#1808](https://github.com/ethereum/execution-spec-tests/pull/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](https://github.com/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](https://github.com/ethereum/execution-spec-tests/pull/1608)):
@@ -27,6 +32,12 @@ Users can select any of the artifacts depending on their testing needs for their
 
 ### 🛠️ 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](https://github.com/ethereum/tests) repository ([#1590](https://github.com/ethereum/execution-spec-tests/pull/1590)).

docs/dev/porting_legacy_tests.md

@@ -85,16 +85,14 @@ Follow the hyperlinks for lost base coverage (`LBC`) to address coverage gaps. H
 
     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.
 
-    Also note that yul tests and possibly other tests used `CALLDATALOAD` that might no longer needed when designing a test with python. But we must always investigate if an opcode is not covered anymore to see if its okay.
-
-    For example, review the [discussion in this PR.](https://github.com/ethereum/execution-spec-tests/pull/975#issuecomment-2528792289)
+    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** typically use the explicit EEST Opcode mini-language, which is more precise in opcode definition
+- **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:
 

docs/getting_started/installation.md

@@ -26,27 +26,17 @@ 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 x86-64 platforms and ARM64 macOS"
+=== "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
-    uv run solc-select use 0.8.24 --always-install
     ```
 
-=== "ARM64 Linux"
-
-    ```console
-    git clone https://github.com/ethereum/execution-spec-tests
-    uv python install 3.12
-    uv python pin 3.12
-    cd execution-spec-tests
-    uv sync --all-extras
-    ```
-    Then follow [this guide](./installation_troubleshooting.md#problem-exception-failed-to-compile-yul-source) to build the `solc` binary from source and copy it to the expected location.
+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).
 
 ## Installation Troubleshooting
 

docs/getting_started/installation_troubleshooting.md

@@ -38,11 +38,11 @@ This page provides guidance on how to troubleshoot common issues that may arise
 
 ### Problem: `CERTIFICATE_VERIFY_FAILED`
 
-!!! danger "Problem: `Failed to install solc ... CERTIFICATE_VERIFY_FAILED`"
-    When running either `uv run solc-select use 0.8.24 --always-install` or `fill` you encounter the following error:
+!!! danger "Problem: `Failed to ... CERTIFICATE_VERIFY_FAILED`"
+    When running `fill` you might encounter the following error:
 
     ```bash
-    Exit: Failed to install solc version 0.8.24: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:992)>
+    Exit: Failed to ...: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:992)>
     ```
 
 === "Ubuntu"
@@ -66,15 +66,8 @@ This page provides guidance on how to troubleshoot common issues that may arise
 
 ### Problem: `Exception: failed to compile yul source`
 
-!!! danger "Problem: `Running fill fails with tests that contain yul source code` on ARM platforms"
-    If you're using `x86_64`, try to manually run `solc-select` to install the required version of the `solc` binary:
-
-    ```shell
-    uv run solc-select use 0.8.24 --always-install
-    ```
-
-    Otherwise, this can happen when you're using an ARM64 OS but followed the x86-64 installation guide.
-    To resolve the issue you must build solidity from source (avoid 0.8.24 as it might require building z3 from source as well).
+!!! 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:
@@ -88,7 +81,7 @@ This page provides guidance on how to troubleshoot common issues that may arise
     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. Verify that `fill` works by running `uv run fill -m yul_test` in the execution-spec-tests root folder.
+    Running `uv run solc --version` should now return the expected version.
 
 ## Problem: `ValueError: unsupported hash type ripemd160`
 

docs/writing_tests/fork_methods.md

@@ -151,8 +151,6 @@ Methods for fork identification and comparison:
 ```python
 fork.name()  # Returns the name of the fork
 fork.transition_tool_name(block_number=0, timestamp=0)  # Returns name for transition tools
-fork.solc_name()  # Returns name for the solc compiler
-fork.solc_min_version()  # Returns minimum solc version supporting this fork
 fork.is_deployed()  # Returns whether the fork is deployed to mainnet
 ```
 

docs/writing_tests/tutorials/blockchain.md

@@ -9,7 +9,6 @@ Before proceeding with this tutorial, it is assumed that you have prior knowledg
 - Repository set-up, see [installation](../../getting_started/installation.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).
-- Know the basics of [Yul](https://docs.soliditylang.org/en/latest/yul.html), which is an EVM assembly language.
 - Familiarity with [Python](https://docs.python.org/3/tutorial/).
 - Understand how to write an execution spec [state transition test](./state_transition.md).
 
@@ -26,15 +25,7 @@ A smart contract is defined that is called by each transaction in the test. It s
 ```python
 contract_addr: Account(
     balance=1000000000000000000000,
-    code=Yul(
-        """
-        {
-            let next_slot := sload(0)
-            sstore(next_slot, number())
-            sstore(0, add(next_slot, 1))
-        }
-        """
-    ),
+    code=code,
     storage={
         0x00: 0x01,
     },

docs/writing_tests/tutorials/state_transition.md

@@ -9,27 +9,12 @@ Before proceeding with this tutorial, it is assumed that you have prior knowledg
 - Repository set-up, see [installation](../../getting_started/installation.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 [static state transition test](https://ethereum-tests.readthedocs.io/en/latest/state-transition-tutorial.html#the-source-code).
-- Know the basics of [Yul](https://docs.soliditylang.org/en/latest/yul.html), which is an EVM assembly language.
+- Know the basics of the [EVM](https://www.evm.codes/).
 - Familiarity with [Python](https://docs.python.org/3/tutorial/).
 
-## Example Tests
+## Example Test
 
-The most effective method of learning how to write tests is to study a couple of straightforward examples. In this tutorial we will go over the [Yul](https://github.com/ethereum/execution-spec-tests/blob/main/tests/homestead/yul/test_yul_example.py#L19) state test.
-
-### Yul Test
-
-You can find the source code for the Yul test in [tests/homestead/yul/test_yul_example.py](../../tests/homestead/yul/test_yul_example/index.md).
-It is the spec test equivalent of this [static test](https://github.com/ethereum/tests/blob/develop/src/GeneralStateTestsFiller/stExample/yulExampleFiller.yml).
-
-Lets examine each section.
-
-```python
-"""
-Test Yul Source Code Examples
-"""
-```
-
-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.
+The most effective method of learning how to write tests is to study a straightforward example. In this tutorial we will go over a simple state test that adds two numbers and stores them in the storage.
 
 ```python
 from ethereum_test_forks import Fork, Frontier, Homestead
@@ -39,7 +24,6 @@ from ethereum_test_tools import (
     Environment,
     StateTestFiller,
     Transaction,
-    YulCompiler,
 )
 ```
 
@@ -57,19 +41,19 @@ In this case, the decorator is a custom [pytest fixture](https://docs.pytest.org
     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_yul
+    fill -k 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_yul --from London --until Paris
+    fill -k test_example --from London --until Paris
     ```
 
 ```python
-def test_yul(state_test: StateTestFiller, pre: Alloc, yul: YulCompiler, fork: Fork):
+def test_example(state_test: StateTestFiller, pre: Alloc, fork: Fork):
     """
-    Test YUL compiled bytecode.
+    Test that adds two numbers and stores the result in storage at key 0.
     """
 ```
 
@@ -93,7 +77,7 @@ In most tests the defaults are good enough.
 
 For more information, [see the static test documentation](../../running_tests/test_formats/state_test.md).
 
-#### Pre State
+### 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.
 It can be used as a [dictionary](https://docs.python.org/3/tutorial/datastructures.html#dictionaries), which is the Python term for an associative array, but the appropriate way to populate it is by using the methods `fund_eoa`, `deploy_contract` or `fund_address` from the `Alloc` object.
@@ -102,23 +86,18 @@ In this example we are using the `deploy_contract` method to deploy a contract t
 
 ```python
     contract_address = pre.deploy_contract(
-        code=yul(
-            """
-            {
-                function f(a, b) -> c {
-                    c := add(a, b)
-                }
-
-                sstore(0, f(1, 2))
-                return(0, 32)
-            }
-            """
-        ),
+        code = Op.PUSH1(0)
+                + Op.PUSH1(2)
+                + Op.PUSH1(1)
+                + Op.ADD
+                + Op.SSTORE
+                + Op.STOP
+        ,
         balance=0x0BA1A9CE0BA1A9CE,
     )
 ```
 
-Specifically we deploy a contract with yul code that adds two numbers and stores the result in storage.
+Specifically we deploy a contract with EVM bytecode that adds two numbers and stores the result in storage.
 
 ```python
             balance=0x0BA1A9CE0BA1A9CE,
@@ -134,38 +113,13 @@ As return value of the `deploy_contract` method we get the address where the con
 
 ```python
         storage={
-            0x00: 0x00,
+            0x00: 0x03,
         },
 ```
 
 We could also specify a starting storage for the contract, which is done by adding a `storage` parameter to the `deploy_contract` method.
 
-```python
-            code=yul(
-```
-
-Here we define the [Yul](https://docs.soliditylang.org/en/v0.8.17/yul.html) code for the contract. It is defined as a multi-line string and starts and ends with curly braces (`{ <yul> }`).
-
-When running the test filler `fill`, the solidity compiler `solc` will automatically translate the Yul to EVM opcode at runtime.
-
-!!! note
-    Currently Yul and direct EVM opcode are supported in execution spec tests.
-
-```python
-                """
-                {
-                    function f(a, b) -> c {
-                        c := add(a, b)
-                    }
-                    sstore(0, f(1, 2))
-                    return(0, 32)
-                }
-                """
-```
-
-Within this example test Yul code we have a function definition, and inside it we are using the Yul `add` instruction. When compiled with `solc` it translates the instruction directly to the `ADD` opcode. For further Yul instructions [see here](https://docs.soliditylang.org/en/latest/yul.html#evm-dialect). Notice that function is utilized with the Yul `sstore` instruction, which stores the result of `add(1, 2)` to the storage address `0x00`.
-
-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 Yul code has run successfully.
+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 code has run successfully.
 
 ```python
     sender = pre.fund_eoa(amount=0x0BA1A9CE0BA1A9CE)
@@ -223,15 +177,15 @@ For more information, [see the static test documentation](../../running_tests/te
 
 This is the post-state which is equivalent to [`expect`](https://ethereum-tests.readthedocs.io/en/latest/test_filler/state_filler.html#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 in the pre-state we essentially stored the result of the Yul instruction `add(1, 2)`.
+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 in the pre-state we essentially stored the result of the instruction `add(1, 2)`.
 
 #### State Test
 
 ```python
     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 (for example, the fork parameter) in order to fill the test, generate the test fixtures and write them to file (by default, `./fixtures/<blockchain,state>_tests/example/yul_example/test_yul.json`).
+This line calls the wrapper to the `StateTest` object that provides all the objects required (for example, the fork parameter) in order to fill the test, generate the test fixtures and write them to file (by default, `./fixtures/<blockchain,state>_tests/example/test_example.json`).
 
 ## Conclusion