fix markdownlint

Author: Carsons-Eels

CONTRIBUTING.md

@@ -13,7 +13,6 @@ In particular, we appreciate support in the following areas:
 
 For details about EELS usage and building, please refer the [README](https://github.com/ethereum/execution-specs/blob/master/README.md#usage)
 
-
 ## Contribution Guidelines
 
 This specification aims to be:
@@ -26,7 +25,7 @@ This specification aims to be:
 
 - Attempt to use descriptive English words (or _very common_ abbreviations) in documentation and identifiers.
 - Avoid using EIP numbers in identifiers.
-- If necessary, there is a custom dictionary `whitelist.txt`. 
+- If necessary, there is a custom dictionary `whitelist.txt`.
 
 ### Changes across various Forks
 
@@ -43,39 +42,39 @@ This saves you having to apply code review feedback repeatedly for each fork.
 
 Running the tests necessary to merge into the repository requires:
 
- * Python 3.11.x, and
- * [PyPy](https://www.pypy.org/) [7.3.19](https://downloads.python.org/pypy/) or later.
- * `geth` installed and present in `$PATH`
-
+- Python 3.11.x, and
+- [PyPy](https://www.pypy.org/) [7.3.19](https://downloads.python.org/pypy/) or later.
+- `geth` installed and present in `$PATH`
 
 `execution-specs` depends on a submodule that contains common tests that are run across all clients, so we need to clone the repo with the --recursive flag. Example:
+
 ```bash
-$ git clone --recursive https://github.com/ethereum/execution-specs.git
+git clone --recursive https://github.com/ethereum/execution-specs.git
 ```
 
 Or, if you've already cloned the repository, you can fetch the submodules with:
 
 ```bash
-$ git submodule update --init --recursive
+git submodule update --init --recursive
 ```
 
 The tests can be run with:
+
 ```bash
-$ tox
+tox
 ```
 
 The development tools can also be run outside of `tox`, and can automatically reformat the code:
 
 ```bash
-$ uv run --extra lint ruff check                # Detects code issues and produces a report to STDOUT
-$ uv run --extra lint ruff check --fix          # Fixes minor code issues (like unsorted imports).
-$ uv run --extra lint ruff format               # Formats code.
-$ uv run --extra lint mypy src packages tests   # Verifies type annotations.
+uv run --extra lint ruff check                # Detects code issues and produces a report to STDOUT
+uv run --extra lint ruff check --fix          # Fixes minor code issues (like unsorted imports).
+uv run --extra lint ruff format               # Formats code.
+uv run --extra lint mypy src packages tests   # Verifies type annotations.
 ```
 
 It is recommended to use a [virtual environment](https://packaging.python.org/guides/installing-using-pip-and-virtual-environments/#creating-a-virtual-environment) to keep your system Python installation clean.
 
-
 A trace of the EVM execution for any test case can be obtained by providing the `--evm-trace` argument to pytest.
 Note: Make sure to run the EVM trace on a small number of tests at a time. The log might otherwise get very big.
 Below is an example.
@@ -86,20 +85,20 @@ uv run --extra test \
         --evm_trace
 ```
 
-
 ## CLI Utilities `ethereum_spec_tools`
 
 The EELS repository has various CLI utilities that can help in the development process.
 
 ### New Fork Tool
------------------
+
 This tool can be used to create the base code for a new fork by using the existing code from a given fork.
 
 The command takes 4 arguments, 2 of which are optional
- * from_fork: The fork name from which the code is to be duplicated. Eg. - "Tangerine Whistle"
- * to_fork: The fork name of the new fork Eg - "Spurious Dragon"
- * from_test (Optional): Name of the from fork within the test fixtures in case it is different from fork name. Eg. - "EIP150"
- * to_test (Optional): Name of the to fork within the test fixtures in case it is different from fork name Eg - "EIP158"
+
+- from_fork: The fork name from which the code is to be duplicated. Eg. - "Tangerine Whistle"
+- to_fork: The fork name of the new fork Eg - "Spurious Dragon"
+- from_test (Optional): Name of the from fork within the test fixtures in case it is different from fork name. Eg. - "EIP150"
+- to_test (Optional): Name of the to fork within the test fixtures in case it is different from fork name Eg - "EIP158"
 
 As an example, if one wants to create baseline code for the `Spurious Dragon` fork from the `Tangerine Whistle` one
 
@@ -108,46 +107,45 @@ ethereum-spec-new-fork --from_fork="Tangerine Whistle" --to_fork="Spurious Drago
 ```
 
 The following will have to however, be updated manually
- 1. The fork number and `MAINNET_FORK_BLOCK` in `__init__.py`. If you are proposing a new EIP, please set `MAINNET_FORK_BLOCK` to `None`.
- 2. Any absolute package imports from other forks eg. in `trie.py`
- 3. Package names under `setup.cfg`
- 4. Add the new fork to the `monkey_patch()` function in `src/ethereum_optimized/__init__.py`
- 5. Adjust the underline in `fork/__init__.py`
 
+1. The fork number and `MAINNET_FORK_BLOCK` in `__init__.py`. If you are proposing a new EIP, please set `MAINNET_FORK_BLOCK` to `None`.
+2. Any absolute package imports from other forks eg. in `trie.py`
+3. Package names under `setup.cfg`
+4. Add the new fork to the `monkey_patch()` function in `src/ethereum_optimized/__init__.py`
+5. Adjust the underline in `fork/__init__.py`
 
 ### Sync Tool
--------------
+
 The sync tool allows one to use an RPC provider to fetch and validate blocks against EELS.
 The state can also be stored in a local DB after validation. Since syncing directly with the specs can be
 very slow, one can also leverage the optimized module. This contains alternative implementations of routines
 in EELS that have been optimized for speed rather than clarity/readability.
 
-
 The tool can be called using the `ethereum-spec-sync` command which takes the following arguments
- * rpc-url: Endpoint providing the Ethereum RPC API. Defaults to `http://localhost:8545/`
- * unoptimized: Don't use the optimized state/ethash (this can be extremely slow)
- * persist: Store the state in a db in this file
- * geth: Use geth specific RPC endpoints while fetching blocks
- * reset: Delete the db and start from scratch
- * gas-per-commit: Commit to db each time this much gas is consumed. Defaults to 1_000_000_000
- * initial-state: Start from the state in this db, rather than genesis
- * stop-at: After syncing this block, exit successfully
+
+- rpc-url: Endpoint providing the Ethereum RPC API. Defaults to `http://localhost:8545/`
+- unoptimized: Don't use the optimized state/ethash (this can be extremely slow)
+- persist: Store the state in a db in this file
+- geth: Use geth specific RPC endpoints while fetching blocks
+- reset: Delete the db and start from scratch
+- gas-per-commit: Commit to db each time this much gas is consumed. Defaults to 1_000_000_000
+- initial-state: Start from the state in this db, rather than genesis
+- stop-at: After syncing this block, exit successfully
 
 - The following options are not supported WITH `--unoptimized` -> `--persist`, `--initial-state`, `--reset`
 - The following options are not supported WITHOUT `--persist` -> `--initial_state`, `--reset`
 
-
 ### Patch Tool
---------------
+
 This tool can be used to apply the unstaged changes in `SOURCE_FORK` to each of the `TARGET_FORKS`. If some
 of the change didn't apply, '.rej' files listing the unapplied changes will be left in the `TARGET_FORK`.
 
-
 The tool takes the following command line arguments
- * The fork name where the changes have been made. Eg:- `frontier` (only a single fork name)
- * The fork names where the changes have to be applied. Eg:- `homestead` (multiple values can be provided separated by space)
- * optimized: Patch the optimized code instead
- * tests: Patch the tests instead
+
+- The fork name where the changes have been made. Eg:- `frontier` (only a single fork name)
+- The fork names where the changes have to be applied. Eg:- `homestead` (multiple values can be provided separated by space)
+- optimized: Patch the optimized code instead
+- tests: Patch the tests instead
 
 As an example, if one wants to apply changes made in `Frontier` fork to `Homestead` and `Tangerine Whistle`
 
@@ -156,11 +154,12 @@ python src/ethereum_spec_tools/patch_tool.py frontier homestead tangerine_whistl
 ```
 
 ### Lint Tool
--------------
+
 This tool checks for style and formatting issues specific to EELS and emits diagnostics
 when issues are found
 
 The tool currently performs the following checks
+
 - The order of the identifiers between each hardfork is consistent.
 - Import statements follow the relevant import rules in modules.
 

EIP_AUTHORS_MANUAL.md

@@ -1,12 +1,14 @@
-# Introduction
+# EIP AUTHOR MANUAL
+
+## Introduction
 
 This document outlines the process of specifying and testing EIPs for the Ethereum execution layer. It is intended for EIP authors, researchers and implementers. An EIP will typically go through the following stages:
 
 | Stage              | Activities  | Outputs |
 | ------------------ | ----------- | ------- |
 | _Pre‑Draft_        | Prospective EIP author conceives of an idea for an improvement to Ethereum, and discusses with the community. | <ul><li>Vague Consensus on [Ethereum Magicians][0]</li></ul> |
 | **Draft**          | <p>EIP author writes a technical human-language document describing the improvement, initially in broad strokes and becoming more specific over time.</p><p>Concurrently, they develop a Python reference implementation to make the EIP executable and identify any immediate/obvious implementation issues. For example, the EIP may not be compatible with some detail of the current Ethereum Virtual Machine.</p><p>Finally for this stage, the author begins to write test schemes for the EIP. Having the reference implementation should help identify the various logical flows to test and thus feed into more robust testing. Once the test schemes are written, the reference implementation can then be used to fill the tests and generate the test vectors.</p> | <ul><li>Complete (but not final) document in [EIPs Repository][1]</li><li>Reference Implementation in [EELS][2]</li><li>Initial Tests in [EEST][3]</li></ul> |
-| **Review**         | <p>The broader Ethereum community discusses and provides input on the proposal.</p><p>Although the feedback from the community can be sought at all lifecycle stages, having a reference implementation and tests act as a good bridge between research and client implementation. It also helps core developers (who have limited time and resources) to understand the EIP better and provide more informed feedback.</p> | <ul><li>Complete &amp; final document in the [EIPs Repository][1]</li><li>Comprehensive tests in [EEST][3]</li></ul>
+| **Review**         | <p>The broader Ethereum community discusses and provides input on the proposal.</p><p>Although the feedback from the community can be sought at all lifecycle stages, having a reference implementation and tests act as a good bridge between research and client implementation. It also helps core developers (who have limited time and resources) to understand the EIP better and provide more informed feedback.</p> | <ul><li>Complete &amp; final document in the [EIPs Repository][1]</li><li>Comprehensive tests in [EEST][3]</li></ul> |
 | **Last&nbsp;Call** | Usually after being nominated for inclusion in a fork, the EIP author signals that the proposal is effectively done and begins the last period for comments/discussion. | <ul><li>Complete reference implementation in [EELS][2]</li><li>Complete tests in [EEST][3]</li><li>Immutable proposal in [EIPs Repository][1]</li></ul> |
 | **Final**          | The proposal is now immutable (cannot be changed) and exists for reference. | <ul><li>Mainnet client implementations</li></ul> |
 
@@ -17,37 +19,36 @@ This document outlines the process of specifying and testing EIPs for the Ethere
 
 This document will focus on stages 3 and 4 of the above lifecycle.
 
-
-# Executable Specifications
+## Executable Specifications
 
 This repository contains the executable specifications for the Ethereum execution layer.
 
-## Folder Structure
+### Folder Structure
 
-### Forks live on mainnet
+#### Forks live on mainnet
 
 The folder `src/ethereum` contains the specifications for the different execution layer forks. Each fork has its own folder. For example, the folder `src/ethereum/frontier` contains the specifications for the Frontier hardfork. The `state_transition` function which is available in the `src/ethereum/<FORK NAME>/fork.py` is the transition function for each fork.
 
-### Fork under development
+#### Fork under development
 
-At any given time, there is a single fork under development. Any new EIP has to be implemented in the folder that is meant for that fork (`src/ethereum/<FORK_NAME>` folder). 
+At any given time, there is a single fork under development. Any new EIP has to be implemented in the folder that is meant for that fork (`src/ethereum/<FORK_NAME>` folder).
 
 For example, at the time of writing, the Prague Fork is still under development and the previous fork is Cancun, which is live on Mainnet. So the prague folder under `src/ethereum` is essentially just the Cancun fork with the values of variables updated to reflect Prague and its under-development status. This folder (`src/ethereum/prague`) serves as the baseline for further development and all new EIPs are to be implemented in this folder.
 
-## Branch Structure
+### Branch Structure
 
-### Forks live on mainnet
+#### Forks live on mainnet
 
 The final stable specification for all forks that are currently live on mainnet are in the `master` branch.
 
-### Fork under development
+#### Fork under development
 
 At any given time, there can only be one fork under active development. The branch structure for the fork under development is as follows:
 
-- `forks/<FORK_NAME>`: The main branch for the fork under development. For example, `forks/prague` is the branch for the Prague fork. This branch will  be merged into `master` after the fork has gone live on mainnet. 
+- `forks/<FORK_NAME>`: The main branch for the fork under development. For example, `forks/prague` is the branch for the Prague fork. This branch will  be merged into `master` after the fork has gone live on mainnet.
 - `eips/<FORK_NAME>/<EIP_NUMBER>`: Branches for each EIP within the fork under development. For example, `eips/prague/eip-7702` is the branch for EIP-7702 for the Prague fork. This branch will be merged into `forks/prague` after the EIP has been confirmed for release in the fork.
 
-# Writing New EIPS
+## Writing New EIPS
 
 Implementing a new EIP in the `execution-specs` repository involves the following steps:
 
@@ -61,7 +62,7 @@ An EIP can only be CFI'd (Considered For Inclusion) if it has a reference `execu
 Please refer the following tutorial for writing new EIP. It takes you through a sample EIP for adding a new opcode to the specs.
 [Tutorial](https://www.youtube.com/watch?v=QIcw_DGSy3s&t)
 
-# Writing Tests with `execution-spec-tests`
+## Writing Tests with `execution-spec-tests`
 
 In addition to having a reference implementation, it is also very useful for the community and core development if the EIP author concieves and writes test vectors for the EIP. There is a very user friendly framework for writing ethereum tests in the `execution-spec-tests` repository. Please refer to the following guide for writing tests to your EIP.
 

LICENSE.md

@@ -32,4 +32,3 @@ For these and/or other purposes and motivations, and without any expectation of
    2. Affirmer offers the Work as-is and makes no representations or warranties of any kind concerning the Work, express, implied, statutory or otherwise, including without limitation warranties of title, merchantability, fitness for a particular purpose, non infringement, or the absence of latent or other defects, accuracy, or the present or absence of errors, whether or not discoverable, all to the greatest extent permissible under applicable law.
    3. Affirmer disclaims responsibility for clearing rights of other persons that may apply to the Work or any use thereof, including without limitation any person's Copyright and Related Rights in the Work. Further, Affirmer disclaims responsibility for obtaining any necessary consents, permissions or other rights required for any use of the Work.
    4. Affirmer understands and acknowledges that Creative Commons is not a party to this document and has no duty or obligation with respect to this CC0 or use of the Work.
-