# Reth Reth is a secure, performant, and modular Ethereum execution client built in Rust. # Reth \[Documentation for Reth users and developers] Reth (short for Rust Ethereum, [pronunciation](https://twitter.com/kelvinfichter/status/1597653609411268608)) is an **Ethereum full node implementation that is focused on being user-friendly, highly modular, as well as being fast and efficient.** Reth is production ready, and suitable for usage in mission-critical environments such as staking or high-uptime services. We also actively recommend professional node operators to switch to Reth in production for performance and cost reasons in use cases where high performance with great margins is required such as RPC, MEV, Indexing, Simulations, and P2P activities. ![Reth](https://raw.githubusercontent.com/paradigmxyz/reth/main/assets/reth-prod.png) ## What is Reth? [Reth](https://github.com/paradigmxyz/reth/) is an execution layer (EL) implementation that is compatible with all Ethereum consensus layer (CL) implementations that support the [Engine API](https://github.com/ethereum/execution-apis/tree/main/src/engine). It is originally built and driven forward by [Paradigm](https://paradigm.xyz/), and is licensed under the Apache and MIT licenses. As a full Ethereum node, Reth allows users to connect to the Ethereum network and interact with the Ethereum blockchain. This includes sending and receiving transactions, querying logs and traces, as well as accessing and interacting with smart contracts. ## Goals Building a successful Ethereum node requires creating a high-quality implementation that is both secure and efficient, as well as being easy to use on consumer hardware. It also requires building a strong community of contributors who can help support and improve the software. ### Modularity Every component of Reth is built to be used as a library: well-tested, heavily documented and benchmarked. We envision that developers will import the node's crates, mix and match, and innovate on top of them. Examples of such usage include, but are not limited to, spinning up standalone P2P networks, talking directly to a node's database, or "unbundling" the node into the components you need. To achieve that, we are licensing Reth under the Apache/MIT permissive license. ### Performance Reth aims to be fast, so we used Rust and the [Erigon staged-sync](https://erigon.substack.com/p/erigon-stage-sync-and-control-flows) node architecture. We also use our Ethereum libraries (including [Alloy](https://github.com/alloy-rs/alloy/) and [revm](https://github.com/bluealloy/revm/)) which we've battle-tested and optimized via [Foundry](https://github.com/foundry-rs/foundry/). ### Free for anyone to use any way they want Reth is free open-source software, built for the community, by the community. By licensing the software under the Apache/MIT license, we want developers to use it without being bound by business licenses, or having to think about the implications of GPL-like licenses. ### Client Diversity The Ethereum protocol becomes more antifragile when no node implementation dominates. This ensures that if there's a software bug, the network does not finalize a bad block. By building a new client, we hope to contribute to Ethereum's antifragility. ### Used by a wide demographic We want to solve for node operators that care about fast historical queries, but also for hobbyists who cannot operate on large hardware. We also want to support teams and individuals who want both sync from genesis and via "fast sync". We envision that Reth will be configurable enough for the tradeoffs that each team faces. ## Who is this for? Reth is a new Ethereum full node that allows users to sync and interact with the entire blockchain, including its historical state if in archive mode. * **Full node**: Stores and processes the entire blockchain, validates blocks and transactions, and participates in the consensus process. * **Archive node**: Stores the entire history of the blockchain and is useful for applications that need access to historical data. As a data engineer/analyst, or as a data indexer, you'll want to use Archive mode. For all other use cases where historical access is not needed, you can use Full mode. ## Is this secure? Reth implements the specification of Ethereum as defined in the [ethereum/execution-specs](https://github.com/ethereum/execution-specs/) repository. To make sure the node is built securely, we run the following tests: 1. EVM state tests are run on every [Revm Pull Request](https://github.com/bluealloy/revm/blob/main/.github/workflows/ethereum-tests.yml) 2. Hive tests are [run every 24 hours](https://github.com/paradigmxyz/reth/blob/main/.github/workflows/hive.yml) in the main Reth repository. 3. We regularly resync multiple nodes from scratch. 4. We operate multiple nodes at the tip of the Ethereum mainnet and various testnets. 5. We extensively unit test, fuzz test and document all our code, while also restricting PRs with aggressive lint rules. We have completed an audit of the [Reth v1.0.0-rc.2](https://github.com/paradigmxyz/reth/releases/tag/v1.0.0-rc.2) with [Sigma Prime](https://sigmaprime.io/), the developers of [Lighthouse](https://github.com/sigp/lighthouse), the Rust Consensus Layer implementation. Find it [here](https://github.com/paradigmxyz/reth/blob/main/audit/sigma_prime_audit_v2.pdf). [Revm](https://github.com/bluealloy/revm) (the EVM used in Reth) underwent an audit with [Guido Vranken](https://twitter.com/guidovranken) (#1 [Ethereum Bug Bounty](https://ethereum.org/en/bug-bounty)). ## Reth Metrics We operate several public Reth nodes across different networks. You can monitor their performance metrics through our public Grafana dashboards: | Name | Chain ID | Type | Grafana | | -------- | -------- | ------- | ---------------------------------------------------------------------------------- | | Ethereum | 1 | Full | [View](https://reth.ithaca.xyz/public-dashboards/23ceb3bd26594e349aaaf2bcf336d0d4) | | Ethereum | 1 | Archive | [View](https://reth.ithaca.xyz/public-dashboards/a49fa110dc9149298fa6763d5c89c8c0) | | Base | 8453 | Archive | [View](https://reth.ithaca.xyz/public-dashboards/b3e9f2e668ee4b86960b7fac691b5e64) | | OP | 10 | Full | [View](https://reth.ithaca.xyz/public-dashboards/aa32f6c39a664f9aa371399b59622527) | :::tip Want to set up metrics for your own Reth node? Check out our [monitoring guide](/run/monitoring) to learn how to configure Prometheus metrics and build your own dashboards. ::: ## Get started * [Install Reth](/installation/overview) and get up and running. * [Run a node](/run/overview) on any official network. * [Monitor your node](/run/monitoring) with statistics and metrics. * [Query the JSON-RPC](/jsonrpc/intro) using Foundry's `cast` or `curl`. * [Explore the SDK](/sdk) to build custom blockchain infrastructure. * [Set up your development environment and contribute](/introduction/contributing)! :::note The documentation is continuously rendered [here](https://reth.rs)! You can contribute to the docs on [GitHub][gh-docs]. ::: [gh-docs]: https://github.com/paradigmxyz/reth/tree/main/docs # Why Reth? Reth is more than just another Ethereum client—it's the foundation upon which the next generation of blockchain infrastructure is being built. From powering production staking environments at institutions like Coinbase to enabling cutting-edge L2 sequencers and ZK applications, Reth represents the convergence of security, performance, and extensibility that the ecosystem demands. Every piece of crypto infrastructure will be touching Reth one way or another. Here's why the world's leading developers and institutions are choosing Reth as their node of choice. ## Institutional-Grade Security Reth secures real value on Ethereum mainnet today, trusted by institutions like [Coinbase](https://x.com/CoinbasePltfrm/status/1933546893742579890) for production staking infrastructure. It powers RPC providers such as Alchemy. ## Future Proof Performance Reth pushes the performance frontier across every dimension, from L2 sequencers to MEV block building. * **L2 Sequencer Performance**: Used by [Base](https://www.base.org/), other production L2s and also rollup-as-a-service providers such as [Conduit](https://conduit.xyz) which require high throughput and fast block times. * **MEV & Block Building**: [rbuilder](https://github.com/flashbots/rbuilder) is an open-source implementation of a block builder built on Reth due to developer friendliness and blazing fast performance. ## Infinitely Customizable Reth's modular architecture means you are not locked into someone else's design decisions—build exactly the chain you need. * **Component-Based Design**: Swap out consensus, execution, mempool, or networking modules independently * **Custom Transaction Types**: Build specialized DeFi chains, and unique economic models * **Rapid Development**: Reth SDK accelerates custom blockchain development with pre-built components ## ZK & Stateless Ready Reth is designed from the ground up to excel in the zero-knowledge future with stateless execution and modular architecture. [SP1](https://github.com/succinctlabs/sp1), a zkVM for proving arbitrary Rust programs, and [Ress](https://www.paradigm.xyz/2025/03/stateless-reth-nodes), an experimental stateless node, demonstrate how Reth enables scalable zero-knowledge applications for Ethereum. ## Thriving Open Source Ecosystem The most important factor in Reth's success is our vibrant open source community building the future together. 500+ geo-distributed developers from leading companies and academia have played a role to build Reth into what it is today. ## Join the community Reth isn't just a tool—it's a movement toward better blockchain infrastructure. Whether you're running a validator, building the next generation of L2s, or creating cutting-edge ZK applications, Reth provides the foundation you need to succeed. **Ready to build the future?** * [Get Started](/run/ethereum) with running your first Reth node * [Explore the SDK](/sdk) to build custom blockchain infrastructure * [Join the Community](https://github.com/paradigmxyz/reth) and contribute to the future of Ethereum # Contributing to Reth Reth has docs specifically geared for developers and contributors, including documentation on the structure and architecture of reth, the general workflow we employ, and other useful tips. ## Getting Help Need support or have questions? Open a github issue and/or join the TG chat: * **GitHub Issues**: [Open an issue](https://github.com/paradigmxyz/reth/issues/new) for bugs or feature requests * **Telegram Chat**: [Join our Telegram](https://t.me/paradigm_reth) for real-time support and discussions ## Repository and Project Structure Reth is organized as a modular codebase with clear separation and a contributor friendly architecture, you can read about it in detail [here](https://github.com/paradigmxyz/reth/tree/main/docs). Here's the TL;DR: ### Design Reth follows a modular architecture where each component can be used independently: * **Consensus**: Block validation and consensus rules * **Storage**: Hybrid database with MDBX + static files * **Networking**: P2P networking stack * **RPC**: JSON-RPC server implementation * **Engine**: Consensus layer integration * **EVM**: Transaction execution * **Node Builder**: High-level orchestration ### Crates The repository is organized into focused crates under `/crates/`: ``` crates/ ├── consensus/ # Consensus and validation logic ├── storage/ # Database and storage implementations ├── net/ # Networking components ├── rpc/ # JSON-RPC server and APIs ├── engine/ # Engine API and consensus integration ├── evm/ # EVM execution ├── node/ # Node building and orchestration ├── ethereum/ # Ethereum-specific implementations └── ... ``` ## Workflow: The Lifecycle of PRs ### 1. Before You Start * Check existing issues to avoid duplicate work * For large features, open an issue first to discuss the approach * Fork the repository and create a feature branch ### 2. Development Process #### Setting Up Your Environment ```bash # Clone your fork git clone https://github.com/YOUR_USERNAME/reth.git cd reth # Install dependencies and tools # Use nightly Rust for formatting rustup install nightly rustup component add rustfmt --toolchain nightly # Run the validation suite make pr ``` #### Code Style and Standards * **Formatting**: Use nightly rustfmt (`cargo +nightly fmt`) * **Linting**: All clippy warnings must be addressed * **Documentation**: Add doc comments for public APIs * **Testing**: Include appropriate tests for your changes #### Recommended VS Code Settings Install the `rust-analyzer` extension and use these settings for the best development experience: ```json { "rust-analyzer.rustfmt.overrideCommand": ["rustfmt", "+nightly"], "rust-analyzer.check.overrideCommand": [ "cargo", "clippy", "--workspace", "--message-format=json", "--all-targets", "--all-features" ] } ``` ### 3. Testing Your Changes Reth uses comprehensive testing at multiple levels: #### Unit Tests Test specific functions and components: ```bash cargo test --package reth-ethereum-consensus ``` #### Integration Tests Test component interactions: ```bash cargo test --test integration_tests ``` #### Full Test Suite Run all tests including Ethereum Foundation tests: ```bash make test ``` #### Validation Suite Before submitting, always run: ```bash make pr ``` This runs: * Code formatting checks * Clippy linting * Documentation generation * Full test suite ### 4. Submitting Your PR #### Draft PRs for Large Features For substantial changes, open a draft PR early to get feedback on the approach. #### PR Requirements * \[ ] Clear, descriptive title and description * \[ ] Tests for new functionality * \[ ] Documentation updates if needed * \[ ] All CI checks passing * \[ ] Commit messages follow conventional format #### Commit Message Format ``` type: brief description More detailed explanation if needed. - feat: new feature - fix: bug fix - docs: documentation changes - refactor: code refactoring - test: adding tests - chore: maintenance tasks ``` ### 5. Review Process #### Who Can Review Any community member can review PRs. We encourage participation from all skill levels. #### What Reviewers Look For * **Does the change improve Reth?** * **Are there clear bugs or issues?** * **Are commit messages clear and descriptive?** * **Is the code well-tested?** * **Is documentation updated appropriately?** #### Review Guidelines * Be constructive and respectful * Provide specific, actionable feedback * Focus on significant issues first * Acknowledge good work and improvements ## Releases: How Reth is Released ### Release Schedule * **Regular releases**: Following semantic versioning * **Security releases**: As needed for critical vulnerabilities * **Pre-releases**: For testing major changes ### Release Process 1. **Version bump**: Update version numbers across crates 2. **Changelog**: Update `CHANGELOG.md` with notable changes 3. **Testing**: Final validation on testnet and mainnet 4. **Tagging**: Create release tags and GitHub releases 5. **Distribution**: Update package registries and Docker images ### Release Criteria * All CI checks passing * No known critical bugs * Documentation up to date * Backwards compatibility considerations addressed ## Ways to Contribute ### 💡 Feature Requests For feature requests, please include: * **Detailed explanation**: What should the feature do? * **Context and motivation**: Why is this feature needed? * **Examples**: How would it be used? * **Similar tools**: References to similar functionality elsewhere ### 📝 Documentation Documentation improvements are always welcome: * Add missing documentation * Improve code examples * Create tutorials or guides ### 🔧 Code Contributions Contributing code changes: * Fix bugs identified in issues * Implement requested features * Improve performance * Refactor for better maintainability ## Code of Conduct Reth follows the [Rust Code of Conduct](https://www.rust-lang.org/conduct.html). We are committed to providing a welcoming and inclusive environment for all contributors. ### Our Standards * Be respectful and constructive * Focus on what's best for the community * Show empathy towards other contributors * Accept constructive criticism gracefully ### Reporting Issues If you experience or witness behavior that violates our code of conduct, please report it to [georgios@paradigm.xyz](mailto:georgios@paradigm.xyz). :::note Also read [CONTRIBUTING.md](https://github.com/paradigmxyz/reth/blob/main/CONTRIBUTING.md) for in-depth guidelines. ::: # System Requirements The hardware requirements for running Reth depend on the node configuration and can change over time as the network grows or new features are implemented. The most important requirement is by far the disk, whereas CPU and RAM requirements are relatively flexible. ## Chain Specific Requirements ### Ethereum Mainnet Below are the requirements for running an Ethereum Mainnet node as of 2025-06-23 block number `22700000`: | | Archive Node | Full Node | | --------- | ------------------------------------- | ------------------------------------- | | Disk | At least 2.8TB (TLC NVMe recommended) | At least 1.2TB (TLC NVMe recommended) | | Memory | 16GB+ | 8GB+ | | CPU | Higher clock speed over core count | Higher clock speeds over core count | | Bandwidth | Stable 24Mbps+ | Stable 24Mbps+ | ### Base Mainnet Below are the minimum system requirements for running a Base Mainnet node as of 2025-06-23, block number `31900000`: | | Archive Node | Full Node | | --------- | -------------------------------------------- | -------------------------------------------- | | Disk | At least 4.1TB (TLC NVMe recommended) | At least 2TB (TLC NVMe recommended) | | Memory | 128GB+ | 128GB+ | | CPU | 6 cores+, Higher clock speed over core count | 6 cores+, Higher clock speed over core count | | Bandwidth | Stable 24Mbps+ | Stable 24Mbps+ | :::note **On CPU clock speeds**: The AMD EPYC 4005/4004 series is a cost-effective high-clock speed option with support for up to 192GB memory. **On CPU cores for Base**: 5+ cores are needed because the state root task splits work into separate threads that run in parallel with each other. The state root task is generally more performant and can scale with the number of CPU cores, while regular state root always uses only one core. This is not a requirement for Mainnet, but for Base you may encounter block processing latencies of more than 2s, which can lead to lagging behind the head of the chain. ::: ## Disk Simplest approach: Use a [good TLC NVMe](https://gist.github.com/yorickdowne/f3a3e79a573bf35767cd002cc977b038) drive for everything. Advanced Storage Optimization (Optional): * TLC NVMe: All application data except static files (`--datadir`) * SATA SSD/HDD: Static files can be stored on slower & cheaper storage (`--datadir.static-files`) ### QLC and TLC It is crucial to understand the difference between QLC and TLC NVMe drives when considering the disk requirement. QLC (Quad-Level Cell) NVMe drives utilize four bits of data per cell, allowing for higher storage density and lower manufacturing costs. However, this increased density comes at the expense of performance. QLC drives have slower read and write speeds compared to TLC drives. They also have a lower endurance, meaning they may have a shorter lifespan and be less suitable for heavy workloads or constant data rewriting. TLC (Triple-Level Cell) NVMe drives, on the other hand, use three bits of data per cell. While they have a slightly lower storage density compared to QLC drives, TLC drives offer faster performance. They typically have higher read and write speeds, making them more suitable for demanding tasks such as data-intensive applications, gaming, and multimedia editing. TLC drives also tend to have a higher endurance, making them more durable and longer-lasting. ## CPU Most of the time during syncing is spent executing transactions, which is a single-threaded operation due to potential state dependencies of a transaction on previous ones. As a result, the number of cores matters less, but in general higher clock speeds are better. More cores are better for parallelizable [stages](https://github.com/paradigmxyz/reth/blob/main/docs/crates/stages.md) (like sender recovery or bodies downloading), but these stages are not the primary bottleneck for syncing. ## Memory It is recommended to use at least 16GB of RAM. Most of Reth's components tend to consume a low amount of memory, unless you are under heavy RPC load, so this should matter less than the other requirements. Higher memory is generally better as it allows for better caching, resulting in less stress on the disk. ## Bandwidth A stable and dependable internet connection is crucial for both syncing a node from genesis and for keeping up with the chain's tip. Note that due to Reth's staged sync, you only need an internet connection for the Headers and Bodies stages. This means that the first 1-3 hours (depending on your internet connection) will be online, downloading all necessary data, and the rest will be done offline and does not require an internet connection. Once you're synced to the tip you will need a reliable connection, especially if you're operating a validator. A 24Mbps connection is recommended, but you can probably get away with less. Make sure your ISP does not cap your bandwidth. ## What hardware can I get? ### Build your own * Storage: Consult the [Great and less great SSDs for Ethereum nodes](https://gist.github.com/yorickdowne/f3a3e79a573bf35767cd002cc977b038) gist. The Seagate Firecuda 530 and WD Black SN850(X) are popular TLC NVMe options. Ensure proper cooling via heatsinks or active fans. * CPU: AMD Ryzen 5000/7000/9000 series, AMD EPYC 4004/4005 or Intel Core i5/i7 (11th gen or newer) with at least 6 cores. The AMD Ryzen 9000 series and the AMD EPYC 4005 series offer good value. * Memory: 32GB DDR4 or DDR5 (ECC if your motherboard & CPU supports it). ### Hosted * [Latitude.sh](https://www.latitude.sh): `f4.metal.small`, `c3.large.x86` or better * [OVH](https://www.ovhcloud.com/en/bare-metal/advance/): `Advance-1` or better # Installation Reth runs on Linux and macOS (Windows tracked). There are three core methods to obtain Reth: * [Pre-built binaries](/installation/binaries) * [Docker images](/installation/docker) * [Building from source.](/installation/source) :::note If you have Docker installed, we recommend using the [Docker Compose](/installation/docker#using-docker-compose) configuration that will get you Reth, Lighthouse (Consensus Client), Prometheus and Grafana running and syncing with just one command. ::: # Binaries [**Archives of precompiled binaries of reth are available for Windows, macOS and Linux.**](https://github.com/paradigmxyz/reth/releases) They are static executables. Users of platforms not explicitly listed below should download one of these archives. If you use **macOS Homebrew** or **Linuxbrew**, you can install Reth from Paradigm's homebrew tap: ```text brew install paradigmxyz/brew/reth ``` If you use **Arch Linux** you can install stable Reth from the AUR using an [AUR helper](https://wiki.archlinux.org/title/AUR_helpers) ([paru][paru] as an example here): ```text paru -S reth # Stable paru -S reth-git # Unstable (git) ``` [paru]: https://github.com/Morganamilo/paru ## Signature Verification You can verify the integrity of a Reth release by checking the signature using GPG. The release signing key can be fetched from the Ubuntu keyserver using the following command: ```bash gpg --keyserver keyserver.ubuntu.com --recv-keys 50FB7CC55B2E8AFA59FE03B7AA5ED56A7FBF253E ``` A copy of the key is also included [below](#release-signing-key). Once you have imported the key you can verify a release signature (`.asc` file) using a command like this: ```bash gpg --verify reth-v0.2.0-beta.9-x86_64-unknown-linux-gnu.tar.gz.asc reth-v0.1.0-beta.9-x86_64-unknown-linux-gnu.tar.gz ``` Replace the filenames by those corresponding to the downloaded Reth release. ### Release Signing Key Releases are signed using the key with ID [`50FB7CC55B2E8AFA59FE03B7AA5ED56A7FBF253E`](https://keyserver.ubuntu.com/pks/lookup?search=50FB7CC55B2E8AFA59FE03B7AA5ED56A7FBF253E\&fingerprint=on\&op=index). ```text -----BEGIN PGP PUBLIC KEY BLOCK----- mDMEZl4GjhYJKwYBBAHaRw8BAQdAU5gnINBAfIgF9S9GzZ1zHDwZtv/WcJRIQI+h wwSJCDS0U0dlb3JnaW9zIEtvbnN0YW50b3BvdWxvcyAoUmV0aCBzaWduaW5nIGtl eSBmb3IgMjAyNCBhbmQgb24pIDxnZW9yZ2lvc0BwYXJhZGlnbS54eXo+iJMEExYK ADsWIQRQ+3zFWy6K+ln+A7eqXtVqf78lPgUCZl4GjgIbAwULCQgHAgIiAgYVCgkI CwIEFgIDAQIeBwIXgAAKCRCqXtVqf78lPtg6APwJXCdEG3OCrYTbOIWtLs5cdFlu UqqUy9J/6Frn7Ss/lwD+PtqDy6AbpX83IcdlSU2cDQQkZWOHG1JPsK33l1lieQy4 OARmXgaOEgorBgEEAZdVAQUBAQdApFaGkJqDMd9RMuAlQVbqWy23w3TxSTHS4Oy8 dD7tvUIDAQgHiHgEGBYKACAWIQRQ+3zFWy6K+ln+A7eqXtVqf78lPgUCZl4GjgIb DAAKCRCqXtVqf78lPlR7AP42Qr+RGsdneH73y2yd26sJpUvRoQ/IcbNMXmxAU3YZ zwEA/K0/Im6d1n9d7fjE9fHh4gjNwZufzVTMJhX6byOo/wM= =zczG -----END PGP PUBLIC KEY BLOCK----- ``` # Docker There are two ways to obtain a Reth Docker image: 1. [GitHub](#github) 2. [Building it from source](#building-the-docker-image) Once you have obtained the Docker image, proceed to [Using the Docker image](#using-the-docker-image). :::note Reth requires Docker Engine version 20.10.10 or higher due to [missing support](https://docs.docker.com/engine/release-notes/20.10/#201010) for the `clone3` syscall in previous versions. ::: ## GitHub Reth docker images for both x86\_64 and ARM64 machines are published with every release of reth on GitHub Container Registry. You can obtain the latest image with: ```bash docker pull ghcr.io/paradigmxyz/reth ``` Or a specific version (e.g. v0.0.1) with: ```bash docker pull ghcr.io/paradigmxyz/reth:v0.0.1 ``` You can test the image with: ```bash docker run --rm ghcr.io/paradigmxyz/reth --version ``` If you can see the latest [Reth release](https://github.com/paradigmxyz/reth/releases) version, then you've successfully installed Reth via Docker. ## Building the Docker image To build the image from source, navigate to the root of the repository and run: ```bash docker build . -t reth:local ``` The build will likely take several minutes. Once it's built, test it with: ```bash docker run reth:local --version ``` ## Using the Docker image There are two ways to use the Docker image: 1. [Using Docker](#using-plain-docker) 2. [Using Docker Compose](#using-docker-compose) ### Using Plain Docker To run Reth with Docker, run: ```bash docker run \ -v rethdata:/root/.local/share/reth/mainnet \ -d \ -p 9001:9001 \ -p 30303:30303 \ -p 30303:30303/udp \ --name reth \ reth:local \ node \ --metrics 0.0.0.0:9001 ``` The above command will create a container named `reth` and a named volume called `rethdata` for data persistence. It will also expose the `30303` port (TCP and UDP) for peering with other nodes and the `9001` port for metrics. It will use the local image `reth:local`. If you want to use the GitHub Container Registry remote image, use `ghcr.io/paradigmxyz/reth` with your preferred tag. ### Using Docker Compose To run Reth with Docker Compose, run the following command from a shell inside the root directory of this repository: ```bash ./etc/generate-jwt.sh docker compose -f etc/docker-compose.yml -f etc/lighthouse.yml up -d ``` :::note If you want to run Reth with a CL that is not Lighthouse: * The JWT for the consensus client can be found at `etc/jwttoken/jwt.hex` in this repository, after the `etc/generate-jwt.sh` script is run * The Reth Engine API is accessible on `localhost:8551` ::: To check if Reth is running correctly, run: ```bash docker compose -f etc/docker-compose.yml -f etc/lighthouse.yml logs -f reth ``` The default `docker-compose.yml` file will create three containers: * Reth * Prometheus * Grafana The optional `lighthouse.yml` file will create two containers: * Lighthouse * [`ethereum-metrics-exporter`](https://github.com/ethpandaops/ethereum-metrics-exporter) Grafana will be exposed on `localhost:3000` and accessible via default credentials (username and password is `admin`), with two available dashboards: * reth * Ethereum Metrics Exporter (works only if Lighthouse is also running) ## Interacting with Reth inside Docker To interact with Reth you must first open a shell inside the Reth container by running: ```bash docker exec -it reth bash ``` **If Reth is running with Docker Compose, replace `reth` with `reth-reth-1` in the above command** Refer to the [CLI docs](/cli/reth) to interact with Reth once inside the Reth container. ## Run only Grafana in Docker This allows importing existing Grafana dashboards, without running Reth in Docker. ```bash docker compose -f etc/docker-compose.yml up -d --no-deps grafana ``` After login with `admin:admin` credentials, Prometheus should be listed under [`Grafana datasources`](http://localhost:3000/connections/datasources). Replace its `Prometheus server URL` so it points to locally running one. On Mac or Windows, use `http://host.docker.internal:9090`. On Linux, try `http://172.17.0.1:9090`. # Build from Source You can build Reth on Linux, macOS, Windows, and Windows WSL2. :::note Reth does **not** work on Windows WSL1. ::: ## Dependencies First, **install Rust** using [rustup](https://rustup.rs/)： ```bash curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh ``` The rustup installer provides an easy way to update the Rust compiler, and works on all platforms. :::tip * During installation, when prompted, enter `1` for the default installation. * After Rust installation completes, try running `cargo version` . If it cannot be found, run `source $HOME/.cargo/env`. After that, running `cargo version` should return the version, for example `cargo 1.68.2`. * It's generally advisable to append `source $HOME/.cargo/env` to `~/.bashrc`. ::: With Rust installed, follow the instructions below to install dependencies relevant to your operating system: * **Ubuntu**: `apt-get install libclang-dev pkg-config build-essential` * **macOS**: `brew install llvm pkg-config` * **Windows**: `choco install llvm` or `winget install LLVM.LLVM` These are needed to build bindings for Reth's database. The Minimum Supported Rust Version (MSRV) of this project is 1.88.0. If you already have a version of Rust installed, you can check your version by running `rustc --version`. To update your version of Rust, run `rustup update`. ## Build Reth With Rust and the dependencies installed, you're ready to build Reth. First, clone the repository: ```bash git clone https://github.com/paradigmxyz/reth cd reth ``` Then, install Reth into your `PATH` directly via: ```bash cargo install --locked --path bin/reth --bin reth ``` The binary will now be accessible as `reth` via the command line, and exist under your default `.cargo/bin` folder. Alternatively, you can build yourself with: ```bash cargo build --release ``` This will place the reth binary under `./target/release/reth`, and you can copy it to your directory of preference after that. Compilation may take around 10 minutes. Installation was successful if `reth --help` displays the [command-line documentation](/cli/reth). If you run into any issues, please check the [Troubleshooting](#troubleshooting) section, or reach out to us on [Telegram](https://t.me/paradigm_reth). ## Update Reth You can update Reth to a specific version by running the commands below. The `reth` directory will be the location you cloned reth to during the installation process. `${VERSION}` will be the version you wish to build in the format `vX.X.X`. ```bash cd reth git fetch git checkout ${VERSION} cargo build --release ``` ## Optimizations **Profiles** You can customise the compiler settings used to compile Reth via [Cargo profiles](https://doc.rust-lang.org/cargo/reference/profiles.html). Reth includes several profiles which can be selected via the Cargo flag `--profile`. * `release`: default for source builds, enables most optimisations while not taking too long to compile. * `maxperf`: default for binary releases, enables aggressive optimisations including full LTO. Although compiling with this profile improves some benchmarks by around 20% compared to `release`, it imposes a *significant* cost at compile time and is only recommended if you have a fast CPU. **Rust compiler flags** You can also use `RUSTFLAGS="-C target-cpu=native"` to enable CPU-specific optimisations. In order to get the highest performance out of your build: ```bash RUSTFLAGS="-C target-cpu=native" cargo build --profile maxperf ``` **Features** The following performance features are enabled by default: `jemalloc` (except on Windows), `asm-keccak`, and `min-trace-logs`. Some additional optional features are available: * `min-LEVEL-logs`, where `LEVEL` is one of `error`, `warn`, `info`, `debug`, `trace`: disables compilation of logs of lower level than the given one; `min-trace-logs` is enabled by default You can build with maximum performance optimizations using: ```bash RUSTFLAGS="-C target-cpu=native" cargo build --profile maxperf ``` ## Troubleshooting ### Command is not found Reth will be installed to `CARGO_HOME` or `$HOME/.cargo`. This directory needs to be on your `PATH` before you can run `$ reth`. See ["Configuring the `PATH` environment variable"](https://www.rust-lang.org/tools/install) for more information. ### Compilation error Make sure you are running the latest version of Rust. If you have installed Rust using rustup, simply run `rustup update`. If you can't install the latest version of Rust you can instead compile using the Minimum Supported Rust Version (MSRV) which is listed under the `rust-version` key in Reth's [Cargo.toml](https://github.com/paradigmxyz/reth/blob/main/Cargo.toml). If compilation fails with `(signal: 9, SIGKILL: kill)`, this could mean your machine ran out of memory during compilation. If you are on Docker, consider increasing the memory of the container, or use a [pre-built binary](/installation/binaries). If compilation fails in either the `keccak-asm` or `sha3-asm` crates, it is likely that your current system configuration is not supported. See the [`keccak-asm` target table](https://github.com/DaniPopes/keccak-asm?tab=readme-ov-file#support) for supported targets. If compilation fails with `error: linking with cc failed: exit code: 1`, try running `cargo clean`. *(Thanks to Sigma Prime for this section from [their Lighthouse book](https://lighthouse-book.sigmaprime.io/installation.html)!)* ### Bus error (WSL2) In WSL 2 on Windows, the default virtual disk size is set to 1TB. You must increase the allocated disk size for your WSL2 instance before syncing reth. You can follow the instructions here: [how to expand the size of your WSL2 virtual hard disk.](https://learn.microsoft.com/en-us/windows/wsl/disk-space#how-to-expand-the-size-of-your-wsl-2-virtual-hard-disk) # Building for ARM devices Reth can be built for and run on ARM devices, but there are a few things to take into consideration before. ## CPU Architecture First, you must have a 64-bit CPU and Operating System, otherwise some of the project dependencies will not be able to compile or be executed. ## Memory Layout on AArch64 Then, you must set up the virtual memory layout in such that the user space is sufficiently large. From [the Linux Kernel documentation](https://www.kernel.org/doc/html/v5.3/arm64/memory.html#:~:text=AArch64%20Linux%20uses%20either%203,for%20both%20user%20and%20kernel.), you can see that the memory layout with 4KB pages and a level-3 translation table limits the user space to 512GB, which is too low for Reth to sync on Ethereum mainnet. ## ARM Board Virtual Memory Limitation ### Issue Description Some ARM boards are equipped with only 3-level paging, which imposes a virtual memory limitation of 256GB for user space on Linux. This limitation can be a challenge for running applications like "reth", as the MDBX (Memory-mapped Database eXtreme) library requires a larger virtual memory allocation by design. ### Understanding the Limitation To determine if a specific ARM board is affected by this virtual memory limitation: 1. **Check Specifications:** When considering an ARM board, review its specifications for information on paging levels. Boards with 3-level paging may have a 256GB virtual memory limit. 2. **Manufacturer Documentation:** Consult the official ARM board documentation for details on supported paging levels. 3. **Community Discussions:** Search online ARM and Linux forums for insights into virtual memory limitations of specific boards. ### Additional Context According to MDBX documentation, changing this upper bound, which dictates the maximum size the database can reach, is a costly operation. Therefore, a reasonably large value was chosen. Given that the upper bound is currently set to 4TB, the assumption was that growth to 3TB might occur relatively soon. If the upper bound size is set to only 342GB, then "reth" cannot store more than 342GB of data, which is insufficient for a full sync. It's worth noting that on x86\_64 architecture, there is a 48-bit address space divided in half between user space and the kernel, providing each with 128TB of address space. In contrast, AArch64 architecture features a user space address space of 512GB and a kernel address space of 256TB. Some newer versions of ARM architecture offer support for Large Virtual Address space, but enabling this requires running with a 64KB page size. The specifics of how to enable this functionality might vary. ### Additional Resources * [ARM developer documentation](https://developer.arm.com/documentation/ddi0406/cb/Appendixes/ARMv4-and-ARMv5-Differences/System-level-memory-model/Virtual-memory-support) * [ARM Community Forums](https://community.arm.com) ## Build Reth If both your CPU architecture and the memory layout are valid, the instructions for building Reth will not differ from [the standard process](https://reth.rs/installation/source/). ## Troubleshooting > If you ever need to recompile the Linux Kernel because the official OS images for your ARM board don't have the right memory layout configuration, you can use [the Armbian build framework](https://github.com/armbian/build). ### Failed to open database > This error is documented [here](https://github.com/paradigmxyz/reth/issues/2211). This error is raised whenever MDBX can not open a database due to the limitations imposed by the memory layout of your kernel. If the user space is limited to 512GB, the database will not be able to grow below this size. You will need to recompile the Linux Kernel to fix the issue. A simple and safe approach to achieve this is to use the Armbian build framework to create a new image of the OS that will be flashed to a storage device of your choice - an SD card for example - with the following kernel feature values: * **Page Size**: 64 KB * **Virtual Address Space Size**: 48 Bits To be able to build an Armbian image and set those values, you will need to: * Clone the Armbian build framework repository ```bash git clone https://github.com/armbian/build cd build ``` * Run the compile script with the following parameters: ```bash ./compile.sh \ BUILD_MINIMAL=yes \ BUILD_DESKTOP=no \ KERNEL_CONFIGURE=yes \ CARD_DEVICE="/dev/sdX" # Replace sdX with your own storage device ``` * From there, you will be able to select the target board, the OS release and branch. Then, once you get in the **Kernel Configuration** screen, select the **Kernel Features options** and set the previous values accordingly. * Wait for the process to finish, plug your storage device into your board and start it. You can now download or install Reth and it should work properly. # Update Priorities When publishing releases, reth will include an "Update Priority" section in the release notes, in the same manner Lighthouse does. The "Update Priority" section will include a table which may appear like so: | User Class | Priority | | -------------------- | --------------- | | Payload Builders | Medium Priority | | Non-Payload Builders | Low Priority | To understand this table, the following terms are important: * *Payload builders* are those who use reth to build and validate payloads. * *Non-payload builders* are those who run reth for other purposes (e.g., data analysis, RPC or applications). * *High priority* updates should be completed as soon as possible (e.g., hours or days). * *Medium priority* updates should be completed at the next convenience (e.g., days or a week). * *Low priority* updates should be completed in the next routine update cycle (e.g., two weeks). # Run a Node Congratulations, now that you have installed Reth, it's time to run it! In this section, we'll guide you through running a Reth node on various networks and configurations. ## Networks Choose the network you want to run your node on: * **[Ethereum](/run/ethereum)** - Run a node on Ethereum mainnet or testnets * **[Private testnets](/run/private-testnets)** - Set up and run private test networks ## Configuration & Monitoring Learn how to configure and monitor your node: * **[Configuration](/run/configuration)** - Configure your node using reth.toml * **[Storage V2](/run/storage)** - Understand the default storage layout * **[Snapshots](/run/storage/snapshots)** - Start from public modular snapshots * **[Minimal Storage Mode](/run/storage/minimal)** - Run Reth with the smallest built-in storage profile * **[Pruning & Node Modes](/run/storage/pruning)** - Choose archive, full, minimal, or custom-pruned storage * **[Monitoring](/run/monitoring)** - Set up logs, metrics, and observability ## Frequently Asked Questions Find answers to common questions and troubleshooting tips: * **[Transaction Types](/run/faq/transactions)** - Understanding different transaction types * **[Ports](/run/faq/ports)** - Network port configuration * **[Profiling](/run/faq/profiling)** - Performance profiling and optimization ## List of Supported Networks | Network | Chain ID | RPC URL | | --------------- | -------- | ------------------------------------ | | Ethereum | 1 | https://ethereum.reth.rs/rpc | | Sepolia Testnet | 11155111 | https://sepolia.drpc.org | :::tip Want to add more networks to this table? Feel free to [contribute](https://github.com/paradigmxyz/reth/edit/main/docs/vocs/docs/pages/run/overview.mdx) by submitting a PR with additional networks that Reth supports! ::: # Running Reth on Ethereum Mainnet or testnets Reth is an [*execution client*](https://ethereum.org/en/developers/docs/nodes-and-clients/#execution-clients). After Ethereum's transition to Proof of Stake (aka the Merge) it became required to run a [*consensus client*](https://ethereum.org/en/developers/docs/nodes-and-clients/#consensus-clients) along with your execution client in order to sync into any "post-Merge" network. This is because the Ethereum execution layer now outsources consensus to a separate component, known as the consensus client. Consensus clients decide what blocks are part of the chain, while execution clients only validate that transactions and blocks are valid in themselves and with respect to the world state. In other words, execution clients execute blocks and transactions and check their validity, while consensus clients determine which valid blocks should be part of the chain. Therefore, running a consensus client in parallel with the execution client is necessary to ensure synchronization and participation in the network. By running both an execution client like Reth and a consensus client, such as Lighthouse 🦀 (which we will assume for this guide), you can effectively contribute to the Ethereum network and participate in the consensus process, even if you don't intend to run validators. | Client | Role | | --------- | --------------------------------------------- | | Execution | Validates transactions and blocks | | | (checks their validity and global state) | | Consensus | Determines which blocks are part of the chain | | | (makes consensus decisions) | ## Running the Reth Node First, ensure that you have Reth installed by following the [installation instructions][installation]. Now, to start the archive node, run: ```bash reth node ``` And to start the full node, run: ```bash reth node --full ``` On differences between archive and full nodes, see [Pruning & Node Modes](/run/storage/pruning#basic-concepts). :::note These commands will not open any HTTP/WS ports by default. You can change this by adding the `--http`, `--ws` flags, respectively and using the `--http.api` and `--ws.api` flags to enable various [JSON-RPC APIs](/jsonrpc/intro). For more commands, see the [`reth node` CLI reference](/cli/cli). ::: The EL \<> CL communication happens over the [Engine API](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md), which is by default exposed at `http://localhost:8551`. The connection is authenticated over JWT using a JWT secret which is auto-generated by Reth and placed in a file called `jwt.hex` in the data directory, which on Linux by default is `$HOME/.local/share/reth/` (`/Users//Library/Application Support/reth/mainnet/jwt.hex` in Mac). You can override this path using the `--authrpc.jwtsecret` option. You MUST use the same JWT secret in BOTH Reth and the chosen Consensus Layer. If you want to override the address or port, you can use the `--authrpc.addr` and `--authrpc.port` options, respectively. So one might do: ```bash reth node \ --authrpc.jwtsecret /path/to/secret \ --authrpc.addr 127.0.0.1 \ --authrpc.port 8551 ``` At this point, our Reth node has started discovery, and even discovered some new peers. But it will not start syncing until you spin up the consensus layer! ## Running the Consensus Layer First, make sure you have Lighthouse installed. Sigma Prime provides excellent [installation](https://lighthouse-book.sigmaprime.io/installation.html) and [node operation](https://lighthouse-book.sigmaprime.io/run_a_node.html) instructions. Assuming you have done that, run: ```bash lighthouse bn \ --checkpoint-sync-url https://mainnet.checkpoint.sigp.io \ --execution-endpoint http://localhost:8551 \ --execution-jwt /path/to/secret ``` The `--checkpoint-sync-url` argument value can be replaced with any checkpoint sync endpoint from a [community-maintained list](https://eth-clients.github.io/checkpoint-sync-endpoints/#mainnet). Your Reth node should start receiving "fork choice updated" messages, and begin syncing the chain. ## Verify the chain is growing You can easily verify that by inspecting the logs, and seeing that headers are arriving in Reth. Sit back now and wait for the stages to run! In the meantime, consider setting up [observability](/run/monitoring) to monitor your node's health or [test the JSON RPC API](/jsonrpc/intro). [installation]: ../installation/overview [docs]: https://github.com/paradigmxyz/reth/tree/main/docs [metrics]: https://github.com/paradigmxyz/reth/blob/main/docs/design/metrics.md#metrics ## Running without a Consensus Layer We provide several methods for running Reth without a Consensus Layer for testing and debugging purposes: ### Manual Chain Tip Setting Use the `--debug.tip ` parameter to set the chain tip manually. If you provide this to your node, it will simulate sending an `engine_forkchoiceUpdated` message *once* and will trigger syncing to the provided block hash. This is useful for testing and debugging purposes, but in order to have a node that can keep up with the tip you'll need to run a CL alongside with it. Example, sync up to block https://etherscan.io/block/23450000: ```bash reth node --debug.tip 0x9ba680d8479f936f84065ce94f58c5f0cc1adb128945167e0875ba41a36cd93b ``` Note: This is a temporary flag for testing purposes. At the moment we have no plans of including a Consensus Layer implementation in Reth, and we are open to including light clients and other methods of syncing like importing Lighthouse as a library. ### Running with Etherscan as Block Source You can use `--debug.etherscan` to run Reth with a fake consensus client that advances the chain using recent blocks on Etherscan. This requires an Etherscan API key (set via `ETHERSCAN_API_KEY` environment variable). Optionally, specify a custom API URL with `--debug.etherscan `. Example: ```bash export ETHERSCAN_API_KEY=your_api_key_here reth node --debug.etherscan ``` Or with a custom Etherscan API URL: ```bash export ETHERSCAN_API_KEY=your_api_key_here reth node --debug.etherscan https://api.etherscan.io/api ``` ### Running with RPC Consensus Use `--debug.rpc-consensus-url` to run Reth with a fake consensus client that fetches blocks from an existing RPC endpoint. This supports both HTTP and WebSocket endpoints: * **WebSocket endpoints**: Will use subscriptions for real-time block updates * **HTTP endpoints**: Will poll for new blocks periodically Example with HTTP RPC: ```bash reth node --debug.rpc-consensus-url https://eth-mainnet.g.alchemy.com/v2/your-api-key ``` Example with WebSocket RPC: ```bash reth node --debug.rpc-consensus-url wss://eth-mainnet.g.alchemy.com/v2/your-api-key ``` Note: The `--debug.tip`, `--debug.etherscan`, and `--debug.rpc-consensus-url` flags are mutually exclusive and cannot be used together. # Run Reth in a private testnet using Kurtosis For those who need a private testnet to validate functionality or scale with Reth. ## Using Docker locally This guide uses [Kurtosis' ethereum-package](https://github.com/ethpandaops/ethereum-package) and assumes you have Kurtosis and Docker installed and have Docker already running on your machine. * Go [here](https://docs.kurtosis.com/install/) to install Kurtosis * Go [here](https://docs.docker.com/get-docker/) to install Docker The [`ethereum-package`](https://github.com/ethpandaops/ethereum-package) is a [package](https://docs.kurtosis.com/advanced-concepts/packages) for a general purpose Ethereum testnet definition used for instantiating private testnets at any scale over Docker or Kubernetes, locally or in the cloud. This guide will go through how to spin up a local private testnet with Reth and various CL clients locally. Specifically, you will instantiate a 2-node network over Docker with Reth/Lighthouse and Reth/Teku client combinations. To see all possible configurations and flags you can use, including metrics and observability tools (e.g. Grafana, Prometheus, etc), go [here](https://github.com/ethpandaops/ethereum-package#configuration). Genesis data will be generated using this [genesis-generator](https://github.com/ethpandaops/ethereum-genesis-generator) to be used to bootstrap the EL and CL clients for each node. The end result will be a private testnet with nodes deployed as Docker containers in an ephemeral, isolated environment on your machine called an [enclave](https://docs.kurtosis.com/advanced-concepts/enclaves/). Read more about how the `ethereum-package` works by going [here](https://github.com/ethpandaops/ethereum-package/). ### Step 1: Define the parameters and shape of your private network First, in your home directory, create a file with the name `network_params.yaml` with the following contents: ```yaml participants: - el_type: reth el_image: ghcr.io/paradigmxyz/reth cl_type: lighthouse cl_image: sigp/lighthouse:latest - el_type: reth el_image: ghcr.io/paradigmxyz/reth cl_type: teku cl_image: consensys/teku:latest ``` > \[!TIP] > If you would like to use a modified reth node, you can build an image locally with a custom tag. The tag can then be used in the `el_image` field in the `network_params.yaml` file. ### Step 2: Spin up your network Next, run the following command from your command line: ```bash kurtosis run github.com/ethpandaops/ethereum-package --args-file ~/network_params.yaml --image-download always ``` Kurtosis will spin up an [enclave](https://docs.kurtosis.com/advanced-concepts/enclaves/) (i.e an ephemeral, isolated environment) and begin to configure and instantiate the nodes in your network. In the end, Kurtosis will print the services running in your enclave that form your private testnet alongside all the container ports and files that were generated & used to start up the private testnet. Here is a sample output: ```console INFO[2024-07-09T12:01:35+02:00] ======================================================== INFO[2024-07-09T12:01:35+02:00] || Created enclave: silent-mountain || INFO[2024-07-09T12:01:35+02:00] ======================================================== Name: silent-mountain UUID: cb5d0a7d0e7c Status: RUNNING Creation Time: Tue, 09 Jul 2024 12:00:03 CEST Flags: ========================================= Files Artifacts ========================================= UUID Name 414a075a37aa 1-lighthouse-reth-0-63-0 34d0b9ff906b 2-teku-reth-64-127-0 dffa1bcd1da1 el_cl_genesis_data fdb202429b26 final-genesis-timestamp da0d9d24b340 genesis-el-cl-env-file 55c46a6555ad genesis_validators_root ba79dbd109dd jwt_file 04948fd8b1e3 keymanager_file 538211b6b7d7 prysm-password ed75fe7d5293 validator-ranges ========================================== User Services ========================================== UUID Name Ports Status 0853f809c300 cl-1-lighthouse-reth http: 4000/tcp -> http://127.0.0.1:32811 RUNNING metrics: 5054/tcp -> http://127.0.0.1:32812 tcp-discovery: 9000/tcp -> 127.0.0.1:32813 udp-discovery: 9000/udp -> 127.0.0.1:32776 f81cd467efe3 cl-2-teku-reth http: 4000/tcp -> http://127.0.0.1:32814 RUNNING metrics: 8008/tcp -> http://127.0.0.1:32815 tcp-discovery: 9000/tcp -> 127.0.0.1:32816 udp-discovery: 9000/udp -> 127.0.0.1:32777 f21d5ca3061f el-1-reth-lighthouse engine-rpc: 8551/tcp -> 127.0.0.1:32803 RUNNING metrics: 9001/tcp -> http://127.0.0.1:32804 rpc: 8545/tcp -> 127.0.0.1:32801 tcp-discovery: 30303/tcp -> 127.0.0.1:32805 udp-discovery: 30303/udp -> 127.0.0.1:32774 ws: 8546/tcp -> 127.0.0.1:32802 e234b3b4a440 el-2-reth-teku engine-rpc: 8551/tcp -> 127.0.0.1:32808 RUNNING metrics: 9001/tcp -> http://127.0.0.1:32809 rpc: 8545/tcp -> 127.0.0.1:32806 tcp-discovery: 30303/tcp -> 127.0.0.1:32810 udp-discovery: 30303/udp -> 127.0.0.1:32775 ws: 8546/tcp -> 127.0.0.1:32807 92dd5a0599dc validator-key-generation-cl-validator-keystore RUNNING f0a7d5343346 vc-1-reth-lighthouse metrics: 8080/tcp -> http://127.0.0.1:32817 RUNNING ``` Great! You now have a private network with 2 full Ethereum nodes on your local machine over Docker - one that is a Reth/Lighthouse pair and another that is Reth/Teku. Check out the [Kurtosis docs](https://docs.kurtosis.com/cli) to learn about the various ways you can interact with and inspect your network. ## Using Kurtosis on Kubernetes Kurtosis packages are portable and reproducible, meaning they will work the same way over Docker or Kubernetes, locally or on remote infrastructure. For use cases that require a larger scale, Kurtosis can be deployed on Kubernetes by following these docs [here](https://docs.kurtosis.com/k8s/). ## Running the network with additional services The [`ethereum-package`](https://github.com/ethpandaops/ethereum-package) comes with many optional flags and arguments you can enable for your private network. Some include: * A Grafana + Prometheus instance * A transaction spammer called [`tx-fuzz`](https://github.com/MariusVanDerWijden/tx-fuzz) * [A network metrics collector](https://github.com/dapplion/beacon-metrics-gazer) * Flashbot's `mev-boost` implementation of PBS (to test/simulate MEV workflows) ### Questions? Please reach out to the [Kurtosis discord](https://discord.com/invite/6Jjp9c89z9) should you have any questions about how to use the `ethereum-package` for your private testnet needs. Thanks! # Storage V2 Reth uses the V2 hot/cold storage layout by default for new databases. This layout routes history indices and transaction hash lookups to RocksDB, writes account and storage changesets to static files, and avoids the legacy plain state tables. For normal node operation, you do not need to pass `--storage.v2`; the default is already `true`. ## Defaults * New databases initialize with storage V2 by default. * Existing databases keep the storage mode persisted in their metadata. The `--storage.v2` flag does not rewrite an initialized data directory. * Legacy V1 storage can still be requested for a new database with `--storage.v2=false`. * Existing V1 databases can be migrated with [`reth db migrate-v2`](/cli/reth/db/migrate-v2), restored from a V2 snapshot, or resynced from scratch. ## Disk savings Measured on disk at block `24,396,823` on Ethereum mainnet: | Node Type | Legacy V1 storage | V2 storage | Savings | | --------- | ----------------- | ---------- | ------- | | Full | 1.46 TB | 1.02 TB | **-30%** | | Minimal | 449 GB | 224 GB | **-50%** | | Archive | 2.99 TB | 2.31 TB | **-23%** | Snapshot download sizes are compressed and change with each published snapshot. For current download sizes, use [snapshots.reth.rs](https://snapshots.reth.rs) or `reth download --list`. ## Quick start ### Fresh sync Start Reth normally. A new data directory uses storage V2 automatically: ```bash reth node \ --authrpc.jwtsecret /path/to/secret ``` Combine storage V2 with node modes and RPC flags as usual: ```bash reth node \ --full \ --http --http.api eth,trace \ --authrpc.jwtsecret /path/to/secret ``` Use [`--minimal`](/run/storage/minimal) when disk usage matters more than retaining older historical RPC data: ```bash reth node \ --minimal \ --authrpc.jwtsecret /path/to/secret ``` ### Using snapshots To avoid syncing from genesis, download a pre-built snapshot from [snapshots.reth.rs](https://snapshots.reth.rs) or the [`reth download`](/cli/reth/download) command: ```bash reth download -y reth node \ --authrpc.jwtsecret /path/to/secret ``` ## Operational notes * Storage mode is selected when a database is initialized. After that, Reth reads the mode from database metadata. * If you need to opt out for a new database, pass `--storage.v2=false` before the first run. * Storage V2 and pruning are separate controls: storage V2 changes where data is stored, while pruning decides how much historical data is retained. ## Further reading * [Snapshots](/run/storage/snapshots) - start from public modular snapshots * [Minimal Storage Mode](/run/storage/minimal) - run Reth with the smallest built-in storage profile * [Pruning & Node Modes](/run/storage/pruning) - choose archive, full, minimal, or custom pruning * [Configuration](/run/configuration) - general node configuration reference * [`reth node` CLI reference](/cli/reth/node) - current storage and pruning flags # Snapshots Reth publishes modular node snapshots at [snapshots.reth.rs](https://snapshots.reth.rs). The snapshot UI lets you choose minimal, full, or archive components and gives you the matching `reth download` command. Use snapshots when you want to avoid syncing from genesis. `reth download` extracts the selected components into your Reth data directory. It also writes `reth.toml` for the selected components if the file does not already exist; after extraction, start `reth node` normally. ## Latest minimal snapshot For the default minimal component set: ```bash reth download -y reth node ``` ## Snapshot sizes Snapshot download sizes are compressed and change with the selected profile, selected components, and latest published block. The [snapshots.reth.rs](https://snapshots.reth.rs) UI shows the estimated download size for the current selection. You can also list snapshot sizes from the CLI: ```bash reth download --list ``` ## Choose a profile ```bash # Smallest built-in profile reth download --minimal # Full-node profile reth download --full # Archive profile reth download --archive ``` ## Custom components Use the website or `reth download` flags to include specific components, such as transaction files, receipts, state history, senders, or RocksDB indices: ```bash reth download \ --with-txs-distance 100000 \ --with-receipts-distance 100000 \ -y ``` ## Further reading * [Storage V2](/run/storage) - understand the default storage layout * [Minimal Storage Mode](/run/storage/minimal) - run the smallest built-in profile * [`reth download` CLI reference](/cli/reth/download) - all snapshot download flags # Minimal Storage Mode Minimal storage mode is Reth's smallest built-in node profile. It uses the default [storage V2 layout](/run/storage) with the most aggressive built-in pruning settings and smaller static file segments. Use `--minimal` when disk usage matters more than serving old historical RPC data. ## Size Measured on disk at block `24,396,823` on Ethereum mainnet, minimal mode with storage V2 used `224 GB`, compared to `449 GB` with legacy V1 storage. The latest snapshot download size is compressed and changes as new snapshots are published. Check [snapshots.reth.rs](https://snapshots.reth.rs) or run `reth download --list` for the current compressed size. ## Run a minimal node ```bash reth node \ --minimal \ --authrpc.jwtsecret /path/to/secret \ --authrpc.addr 127.0.0.1 \ --authrpc.port 8551 ``` ## Retention profile | Data segment | Minimal mode behavior | | ------------ | --------------------- | | Sender recovery | Fully pruned | | Transaction lookup | Fully pruned | | Receipts | Retains the last 64 blocks | | Account history | Retains the last 10,064 blocks | | Storage history | Retains the last 10,064 blocks | | Block bodies | Retains the last 10,064 blocks | | Static files | Uses 10,000 blocks per file segment | ## Trade-offs Minimal mode is suitable for nodes that need to follow the chain, serve recent state, and keep disk usage low. It is not suitable for workloads that require older transaction lookup, receipts, logs, traces, or historical state. For more detail on which RPC methods are affected by pruning, see [Pruning & Node Modes](/run/storage/pruning#rpc-support). ## Snapshots To start from a [snapshot](/run/storage/snapshots) with the minimal component set: ```bash reth download --chain mainnet --minimal reth node \ --authrpc.jwtsecret /path/to/secret ``` # Pruning & Node Modes Reth supports archive, full, minimal, and custom-pruned nodes. Archive mode is the default when no pruning profile or pruning configuration is set. For new databases, these modes run on the default [storage V2 layout](/run/storage). Storage V2 controls where data is stored; pruning controls how much historical data is retained. ## Basic concepts * Archive node - retains all historical data from genesis. * Full node - keeps current state and a 10,064-block historical state window, while pruning selected historical data. * Minimal node - uses the most aggressive built-in pruning profile for small disk usage. * Custom-pruned node - uses [custom pruning configuration](/run/configuration#the-prune-section) or individual `--prune.*` flags. Pruning is destructive. Once historical data has been pruned, Reth cannot serve that data again unless you restore it from a snapshot or resync with a mode that retains it. ## Modes ### Archive Node Archive mode is the default. Follow the steps from [Running Reth on Ethereum Mainnet or testnets](/run/ethereum) and start Reth without a pruning profile: ```bash reth node ``` ### Full Node Use `--full` to run the default full-node pruning profile: ```bash reth node \ --full \ --authrpc.jwtsecret /path/to/secret \ --authrpc.addr 127.0.0.1 \ --authrpc.port 8551 ``` Full mode configures: * sender recovery pruning: full * transaction lookup pruning: disabled * receipts pruning: retain the last 10,064 blocks * account history pruning: retain the last 10,064 blocks * storage history pruning: retain the last 10,064 blocks * bodies pruning: prune pre-Merge bodies on chains with a Paris activation ### Minimal Storage Mode Use [`--minimal`](/run/storage/minimal) to run the most aggressive built-in pruning profile: ```bash reth node \ --minimal \ --authrpc.jwtsecret /path/to/secret \ --authrpc.addr 127.0.0.1 \ --authrpc.port 8551 ``` Minimal mode configures: * sender recovery pruning: full * transaction lookup pruning: full * receipts pruning: retain the last 64 blocks * account history pruning: retain the last 10,064 blocks * storage history pruning: retain the last 10,064 blocks * bodies pruning: retain the last 10,064 blocks * static file segments: 10,000 blocks per file ### Custom Pruned Node Use `reth.toml` or individual `--prune.*` flags to configure each pruning segment yourself. See the [pruning configuration](/run/configuration#the-prune-section) reference for the TOML format. ## Disk usage Disk usage changes as networks grow and depends on the selected node mode. For current storage V2 measurements, see [Storage V2](/run/storage#disk-savings). ## RPC support The [pruning configuration](/run/configuration#the-prune-section) can prune several independent data segments: * Sender Recovery * Transaction Lookup * Receipts * Account History * Storage History Pruning a segment limits RPC methods that need the removed historical data or lookup indexes. ### Full Node The following tables describe RPC methods available in the full node. #### `debug` namespace | RPC | Note | | ----------------------------------- | ---------------------------------------------------------- | | `debug_accountAt` | Only for the last 10064 blocks | | `debug_accountInfoAt` | Only for the last 10064 blocks | | `debug_chainConfig` | | | `debug_codeByHash` | Only for the last 10064 blocks | | `debug_dbGet` | | | `debug_executionWitness` | Only for the last 10064 blocks | | `debug_executionWitnessByBlockHash` | Only for the last 10064 blocks | | `debug_getBadBlocks` | | | `debug_getRawBlock` | | | `debug_getRawHeader` | | | `debug_getRawReceipts` | Only for the last 10064 blocks | | `debug_getRawTransaction` | | | `debug_getRawTransactions` | | | `debug_stateRootWithUpdates` | Only for the last 10064 blocks | | `debug_traceBlock` | Only for the last 10064 blocks | | `debug_traceBlockByHash` | Only for the last 10064 blocks | | `debug_traceBlockByNumber` | Only for the last 10064 blocks | | `debug_traceCall` | Only for the last 10064 blocks | | `debug_traceCallMany` | Only for the last 10064 blocks | | `debug_traceTransaction` | Only for the last 10064 blocks | #### `eth` namespace | RPC / Segment | Note | | ----------------------------------------- | ---------------------------------------------------------- | | `eth_accounts` | | | `eth_blockNumber` | | | `eth_call` | Only for the last 10064 blocks | | `eth_chainId` | | | `eth_createAccessList` | Only for the last 10064 blocks | | `eth_estimateGas` | Only for the last 10064 blocks | | `eth_feeHistory` | | | `eth_gasPrice` | | | `eth_getBalance` | Only for the last 10064 blocks | | `eth_getBlockByHash` | | | `eth_getBlockByNumber` | | | `eth_getBlockReceipts` | Only for the last 10064 blocks | | `eth_getBlockTransactionCountByHash` | | | `eth_getBlockTransactionCountByNumber` | | | `eth_getCode` | | | `eth_getFilterChanges` | | | `eth_getFilterLogs` | Only for the last 10064 blocks | | `eth_getLogs` | Only for the last 10064 blocks | | `eth_getStorageAt` | Only for the last 10064 blocks | | `eth_getTransactionByBlockHashAndIndex` | | | `eth_getTransactionByBlockNumberAndIndex` | | | `eth_getTransactionByHash` | | | `eth_getTransactionCount` | Only for the last 10064 blocks | | `eth_getTransactionReceipt` | Only for the last 10064 blocks | | `eth_getUncleByBlockHashAndIndex` | | | `eth_getUncleByBlockNumberAndIndex` | | | `eth_getUncleCountByBlockHash` | | | `eth_getUncleCountByBlockNumber` | | | `eth_maxPriorityFeePerGas` | | | `eth_mining` | | | `eth_newBlockFilter` | | | `eth_newFilter` | | | `eth_newPendingTransactionFilter` | | | `eth_protocolVersion` | | | `eth_sendRawTransaction` | | | `eth_sendTransaction` | | | `eth_sign` | | | `eth_signTransaction` | | | `eth_signTypedData` | | | `eth_subscribe` | | | `eth_syncing` | | | `eth_uninstallFilter` | | | `eth_unsubscribe` | | #### `net` namespace | RPC / Segment | | --------------- | | `net_listening` | | `net_peerCount` | | `net_version` | #### `trace` namespace | RPC / Segment | Note | | ------------------------------- | ------------------------------ | | `trace_block` | Only for the last 10064 blocks | | `trace_blockOpcodeGas` | Only for the last 10064 blocks | | `trace_call` | Only for the last 10064 blocks | | `trace_callMany` | Only for the last 10064 blocks | | `trace_filter` | Only for the last 10064 blocks | | `trace_get` | Only for the last 10064 blocks | | `trace_rawTransaction` | Only for the last 10064 blocks | | `trace_replayBlockTransactions` | Only for the last 10064 blocks | | `trace_replayTransaction` | Only for the last 10064 blocks | | `trace_transaction` | Only for the last 10064 blocks | | `trace_transactionOpcodeGas` | Only for the last 10064 blocks | #### `txpool` namespace | RPC / Segment | | -------------------- | | `txpool_content` | | `txpool_contentFrom` | | `txpool_inspect` | | `txpool_status` | ### Pruned Node The following tables describe the requirements for prune segments, per RPC method: * ✅ – if the segment is pruned, the RPC method still works * ❌ - if the segment is pruned, the RPC method doesn't work anymore #### `debug` namespace | RPC / Segment | Sender Recovery | Transaction Lookup | Receipts | Account History | Storage History | | ----------------------------------- | --------------- | ------------------ | -------- | --------------- | --------------- | | `debug_accountAt` | ✅ | ✅ | ✅ | ❌ | ❌ | | `debug_accountInfoAt` | ✅ | ✅ | ✅ | ❌ | ❌ | | `debug_chainConfig` | ✅ | ✅ | ✅ | ✅ | ✅ | | `debug_codeByHash` | ✅ | ✅ | ✅ | ❌ | ✅ | | `debug_dbGet` | ✅ | ✅ | ✅ | ✅ | ✅ | | `debug_executionWitness` | ✅ | ✅ | ✅ | ❌ | ❌ | | `debug_executionWitnessByBlockHash` | ✅ | ✅ | ✅ | ❌ | ❌ | | `debug_getBadBlocks` | ✅ | ✅ | ✅ | ✅ | ✅ | | `debug_getRawBlock` | ✅ | ✅ | ✅ | ✅ | ✅ | | `debug_getRawHeader` | ✅ | ✅ | ✅ | ✅ | ✅ | | `debug_getRawReceipts` | ✅ | ✅ | ❌ | ✅ | ✅ | | `debug_getRawTransaction` | ✅ | ❌ | ✅ | ✅ | ✅ | | `debug_getRawTransactions` | ✅ | ✅ | ✅ | ✅ | ✅ | | `debug_stateRootWithUpdates` | ✅ | ✅ | ✅ | ❌ | ❌ | | `debug_traceBlock` | ✅ | ✅ | ✅ | ❌ | ❌ | | `debug_traceBlockByHash` | ✅ | ✅ | ✅ | ❌ | ❌ | | `debug_traceBlockByNumber` | ✅ | ✅ | ✅ | ❌ | ❌ | | `debug_traceCall` | ✅ | ✅ | ✅ | ❌ | ❌ | | `debug_traceCallMany` | ✅ | ✅ | ✅ | ❌ | ❌ | | `debug_traceTransaction` | ✅ | ✅ | ✅ | ❌ | ❌ | #### `eth` namespace | RPC / Segment | Sender Recovery | Transaction Lookup | Receipts | Account History | Storage History | | ----------------------------------------- | --------------- | ------------------ | -------- | --------------- | --------------- | | `eth_accounts` | ✅ | ✅ | ✅ | ✅ | ✅ | | `eth_blockNumber` | ✅ | ✅ | ✅ | ✅ | ✅ | | `eth_call` | ✅ | ✅ | ✅ | ❌ | ❌ | | `eth_chainId` | ✅ | ✅ | ✅ | ✅ | ✅ | | `eth_createAccessList` | ✅ | ✅ | ✅ | ❌ | ❌ | | `eth_estimateGas` | ✅ | ✅ | ✅ | ❌ | ❌ | | `eth_feeHistory` | ✅ | ✅ | ✅ | ✅ | ✅ | | `eth_gasPrice` | ✅ | ✅ | ✅ | ✅ | ✅ | | `eth_getBalance` | ✅ | ✅ | ✅ | ❌ | ✅ | | `eth_getBlockByHash` | ✅ | ✅ | ✅ | ✅ | ✅ | | `eth_getBlockByNumber` | ✅ | ✅ | ✅ | ✅ | ✅ | | `eth_getBlockReceipts` | ✅ | ✅ | ❌ | ✅ | ✅ | | `eth_getBlockTransactionCountByHash` | ✅ | ✅ | ✅ | ✅ | ✅ | | `eth_getBlockTransactionCountByNumber` | ✅ | ✅ | ✅ | ✅ | ✅ | | `eth_getCode` | ✅ | ✅ | ✅ | ✅ | ✅ | | `eth_getFilterChanges` | ✅ | ✅ | ✅ | ✅ | ✅ | | `eth_getFilterLogs` | ✅ | ✅ | ❌ | ✅ | ✅ | | `eth_getLogs` | ✅ | ✅ | ❌ | ✅ | ✅ | | `eth_getStorageAt` | ✅ | ✅ | ✅ | ✅ | ❌ | | `eth_getTransactionByBlockHashAndIndex` | ✅ | ✅ | ✅ | ✅ | ✅ | | `eth_getTransactionByBlockNumberAndIndex` | ✅ | ✅ | ✅ | ✅ | ✅ | | `eth_getTransactionByHash` | ✅ | ❌ | ✅ | ✅ | ✅ | | `eth_getTransactionCount` | ✅ | ✅ | ✅ | ❌ | ✅ | | `eth_getTransactionReceipt` | ✅ | ❌ | ❌ | ✅ | ✅ | | `eth_getUncleByBlockHashAndIndex` | ✅ | ✅ | ✅ | ✅ | ✅ | | `eth_getUncleByBlockNumberAndIndex` | ✅ | ✅ | ✅ | ✅ | ✅ | | `eth_getUncleCountByBlockHash` | ✅ | ✅ | ✅ | ✅ | ✅ | | `eth_getUncleCountByBlockNumber` | ✅ | ✅ | ✅ | ✅ | ✅ | | `eth_maxPriorityFeePerGas` | ✅ | ✅ | ✅ | ✅ | ✅ | | `eth_mining` | ✅ | ✅ | ✅ | ✅ | ✅ | | `eth_newBlockFilter` | ✅ | ✅ | ✅ | ✅ | ✅ | | `eth_newFilter` | ✅ | ✅ | ✅ | ✅ | ✅ | | `eth_newPendingTransactionFilter` | ✅ | ✅ | ✅ | ✅ | ✅ | | `eth_protocolVersion` | ✅ | ✅ | ✅ | ✅ | ✅ | | `eth_sendRawTransaction` | ✅ | ✅ | ✅ | ✅ | ✅ | | `eth_sendTransaction` | ✅ | ✅ | ✅ | ✅ | ✅ | | `eth_sign` | ✅ | ✅ | ✅ | ✅ | ✅ | | `eth_signTransaction` | ✅ | ✅ | ✅ | ✅ | ✅ | | `eth_signTypedData` | ✅ | ✅ | ✅ | ✅ | ✅ | | `eth_subscribe` | ✅ | ✅ | ✅ | ✅ | ✅ | | `eth_syncing` | ✅ | ✅ | ✅ | ✅ | ✅ | | `eth_uninstallFilter` | ✅ | ✅ | ✅ | ✅ | ✅ | | `eth_unsubscribe` | ✅ | ✅ | ✅ | ✅ | ✅ | #### `net` namespace | RPC / Segment | Sender Recovery | Transaction Lookup | Receipts | Account History | Storage History | | --------------- | --------------- | ------------------ | -------- | --------------- | --------------- | | `net_listening` | ✅ | ✅ | ✅ | ✅ | ✅ | | `net_peerCount` | ✅ | ✅ | ✅ | ✅ | ✅ | | `net_version` | ✅ | ✅ | ✅ | ✅ | ✅ | #### `trace` namespace | RPC / Segment | Sender Recovery | Transaction Lookup | Receipts | Account History | Storage History | | ------------------------------- | --------------- | ------------------ | -------- | --------------- | --------------- | | `trace_block` | ✅ | ✅ | ✅ | ❌ | ❌ | | `trace_blockOpcodeGas` | ✅ | ✅ | ✅ | ❌ | ❌ | | `trace_call` | ✅ | ✅ | ✅ | ❌ | ❌ | | `trace_callMany` | ✅ | ✅ | ✅ | ❌ | ❌ | | `trace_filter` | ✅ | ✅ | ✅ | ❌ | ❌ | | `trace_get` | ✅ | ❌ | ✅ | ❌ | ❌ | | `trace_rawTransaction` | ✅ | ✅ | ✅ | ❌ | ❌ | | `trace_replayBlockTransactions` | ✅ | ✅ | ✅ | ❌ | ❌ | | `trace_replayTransaction` | ✅ | ❌ | ✅ | ❌ | ❌ | | `trace_transaction` | ✅ | ❌ | ✅ | ❌ | ❌ | | `trace_transactionOpcodeGas` | ✅ | ❌ | ✅ | ❌ | ❌ | #### `txpool` namespace | RPC / Segment | Sender Recovery | Transaction Lookup | Receipts | Account History | Storage History | | -------------------- | --------------- | ------------------ | -------- | --------------- | --------------- | | `txpool_content` | ✅ | ✅ | ✅ | ✅ | ✅ | | `txpool_contentFrom` | ✅ | ✅ | ✅ | ✅ | ✅ | | `txpool_inspect` | ✅ | ✅ | ✅ | ✅ | ✅ | | `txpool_status` | ✅ | ✅ | ✅ | ✅ | ✅ | # Configuring Reth Reth places a configuration file named `reth.toml` in the data directory specified when starting the node. It is written in the [TOML] format. The default data directory is platform dependent: * Linux: `$XDG_DATA_HOME/reth/` or `$HOME/.local/share/reth/` * Windows: `{FOLDERID_RoamingAppData}/reth/` * macOS: `$HOME/Library/Application Support/reth/` The configuration file contains the following sections: * [`bootnodes`](#the-bootnodes-key) -- Nodes to bootstrap P2P discovery with * [`[stages]`](#the-stages-section) -- Configuration of the individual sync stages * [`era`](#era) * [`headers`](#headers) * [`bodies`](#bodies) * [`sender_recovery`](#sender_recovery) * [`execution`](#execution) * [`account_hashing`](#account_hashing) * [`storage_hashing`](#storage_hashing) * [`merkle`](#merkle) * [`transaction_lookup`](#transaction_lookup) * [`index_account_history`](#index_account_history) * [`index_storage_history`](#index_storage_history) * [`etl`](#etl) * [`prune`](#prune) * [`[peers]`](#the-peers-section) * [`connection_info`](#connection_info) * [`reputation_weights`](#reputation_weights) * [`backoff_durations`](#backoff_durations) * [`[sessions]`](#the-sessions-section) * [`[prune]`](#the-prune-section) * [`[static_files]`](#the-static_files-section) ## The `bootnodes` key The nodes reth bootstraps P2P discovery with, as `enode://` URLs or `enr:` records. Entries may use a domain name instead of an IP address, which is resolved on startup. This takes precedence over the bootnodes of the chain being run, and is overridden by `--bootnodes`. ```toml bootnodes = [ "enode://d860a01f9722d78051619d1e2351aba3f43f943f6f00718d1b9baa4101932a1f5011f16bb2b1bb35db20d6fe28fa0bf09636d26a87d31de9ec6203eeedb1f666@18.138.108.67:30303", "enr:-IS4QHCYrYZbAKWCBRlAy5zzaDZXJBGkcnh4MHcBFZntXNFrdvJjX04jRzjzCBOonrkTfj499SZuOh8R33Ls8RRcy5wBgmlkgnY0gmlwhH8AAAGJc2VjcDI1NmsxoQPKY0yuDUmstAHYpMa2_oxVtw0RW_QAdpzBQA8yWM0xOIN1ZHCCdl8", ] ``` ## The `[stages]` section The stages section is used to configure how individual stages in reth behave, which has a direct impact on resource utilization and sync speed. The defaults shipped with Reth try to be relatively reasonable, but may not be optimal for your specific set of hardware. ### `era` The ERA stage configures pre-synced ERA1 data ingestion, either from a local directory or a remote host. ```toml [stages.era] # Use a local directory containing ERA1 files (conflicts with `url`) path = "/path/to/era1" # Or download ERA1 files from a host (conflicts with `path`) # url = "https://example.com/era1/" # When using `url`, specify a temporary download folder # folder = "/path/to/reth/era" ``` ### `headers` The headers section controls both the behavior of the header stage, which downloads historical headers, as well as the primary downloader that fetches headers over P2P. ```toml [stages.headers] # The minimum and maximum number of concurrent requests to have in flight at a time. # # The downloader uses these as best effort targets, which means that the number # of requests may be outside of these thresholds within a reasonable degree. # # Increase these for faster sync speeds at the cost of additional bandwidth and memory downloader_max_concurrent_requests = 100 downloader_min_concurrent_requests = 5 # The maximum number of responses to buffer in the downloader at any one time. # # If the buffer is full, no more requests will be sent until room opens up. # # Increase the value for a larger buffer at the cost of additional memory consumption downloader_max_buffered_responses = 100 # The maximum number of headers to request from a peer at a time. downloader_request_limit = 1000 # The amount of headers to persist to disk at a time. # # Lower thresholds correspond to more frequent disk I/O (writes), # but lowers memory usage commit_threshold = 10000 ``` ### `bodies` The bodies section controls both the behavior of the bodies stage, which downloads historical block bodies, as well as the primary downloader that fetches block bodies over P2P. ```toml [stages.bodies] # The maximum number of bodies to request from a peer at a time. downloader_request_limit = 200 # The maximum amount of bodies to download before writing them to disk. # # A lower value means more frequent disk I/O (writes), but also # lowers memory usage. downloader_stream_batch_size = 1000 # The size of the internal block buffer in bytes. # # A bigger buffer means that bandwidth can be saturated for longer periods, # but also increases memory consumption. # # If the buffer is full, no more requests will be made to peers until # space is made for new blocks in the buffer. # # Defaults to around 2GB. downloader_max_buffered_blocks_size_bytes = 2147483648 # The minimum and maximum number of concurrent requests to have in flight at a time. # # The downloader uses these as best effort targets, which means that the number # of requests may be outside of these thresholds within a reasonable degree. # # Increase these for faster sync speeds at the cost of additional bandwidth and memory downloader_min_concurrent_requests = 5 downloader_max_concurrent_requests = 100 ``` ### `sender_recovery` The sender recovery stage recovers the address of transaction senders using transaction signatures. ```toml [stages.sender_recovery] # The number of transactions to recover senders for before # writing the results to disk. # # Lower thresholds correspond to more frequent disk I/O (writes), # but lowers memory usage commit_threshold = 5000000 ``` ### `execution` The execution stage executes historical transactions. This stage is generally very I/O and memory intensive, since executing transactions involves reading block headers, transactions, accounts and account storage. Each executed transaction also generates a number of changesets, and mutates the current state of accounts and storage. For this reason, there are several ways to control how much work to perform before the results are written to disk. ```toml [stages.execution] # The maximum number of blocks to process before the execution stage commits. max_blocks = 500000 # The maximum number of state changes to keep in memory before the execution stage commits. max_changes = 5000000 # The maximum cumulative amount of gas to process before the execution stage commits. max_cumulative_gas = 1500000000 # 30_000_000 * 50_000 # The maximum time spent on blocks processing before the execution stage commits. max_duration = '10m' ``` For all thresholds specified, the first to be hit will determine when the results are written to disk. Lower values correspond to more frequent disk writes, but also lower memory consumption. A lower value also negatively impacts sync speed, since reth keeps a cache around for the entire duration of blocks executed in the same range. ### `prune` Controls how frequently the prune stage commits its progress. ```toml [stages.prune] # The maximum number of entries to prune before committing progress to the database. commit_threshold = 1_000_000 ``` ### `account_hashing` The account hashing stage builds a secondary table of accounts, where the key is the hash of the address instead of the raw address. This is used to later compute the state root. ```toml [stages.account_hashing] # The threshold in number of blocks before the stage starts from scratch # and re-hashes all accounts as opposed to just the accounts that changed. clean_threshold = 500000 # The amount of accounts to process before writing the results to disk. # # Lower thresholds correspond to more frequent disk I/O (writes), # but lowers memory usage commit_threshold = 100000 ``` ### `storage_hashing` The storage hashing stage builds a secondary table of account storages, where the key is the hash of the address and the slot, instead of the raw address and slot. This is used to later compute the state root. ```toml [stages.storage_hashing] # The threshold in number of blocks before the stage starts from scratch # and re-hashes all storages as opposed to just the storages that changed. clean_threshold = 500000 # The amount of storage slots to process before writing the results to disk. # # Lower thresholds correspond to more frequent disk I/O (writes), # but lowers memory usage commit_threshold = 100000 ``` ### `merkle` The merkle stage uses the indexes built in the hashing stages (storage and account hashing) to compute the state root of the latest block. ```toml [stages.merkle] # The number of blocks to run the incremental root method for when catching up. # When syncing a large number of blocks, incremental root building is limited # to prevent memory issues. incremental_threshold = 7000 # The threshold in number of blocks before the stage starts from scratch # and rebuilds the entire trie, discarding the existing trie. rebuild_threshold = 100000 ``` ### `transaction_lookup` The transaction lookup stage builds an index of transaction hashes to their sequential transaction ID. ```toml [stages.transaction_lookup] # The maximum number of transactions to process before writing the results to disk. # # Lower thresholds correspond to more frequent disk I/O (writes), # but lowers memory usage chunk_size = 5000000 ``` ### `index_account_history` The account history indexing stage builds an index of what blocks a particular account changed. ```toml [stages.index_account_history] # The maximum amount of blocks to process before writing the results to disk. # # Lower thresholds correspond to more frequent disk I/O (writes), # but lowers memory usage commit_threshold = 100000 ``` ### `index_storage_history` The storage history indexing stage builds an index of what blocks a particular storage slot changed. ```toml [stages.index_storage_history] # The maximum amount of blocks to process before writing the results to disk. # # Lower thresholds correspond to more frequent disk I/O (writes), # but lowers memory usage commit_threshold = 100000 ``` ### `etl` An ETL (extract, transform, load) data collector. Used mainly to insert data into `MDBX` in a sorted manner. ```toml [stages.etl] # Optional directory for temporary files used by ETL. Defaults to `datadir/etl-tmp` when unset. # dir = "/path/to/reth/etl-tmp" # The maximum size in bytes of data held in memory before being flushed to disk as a file. # # Lower threshold corresponds to more frequent flushes, # but lowers temporary storage usage file_size = 524_288_000 # 500 * 1024 * 1024 ``` ## The `[peers]` section The peers section is used to configure how the networking component of reth establishes and maintains connections to peers. In the top level of the section you can configure trusted nodes, and how often reth will try to connect to new peers. ```toml [peers] # How often reth will attempt to make outgoing connections, # if there is room for more peers refill_slots_interval = '5s' # A list of ENRs for trusted peers, which are peers reth will always try to connect to. trusted_nodes = [] # Whether reth will only attempt to connect to the peers specified above, # or if it will connect to other peers in the network connect_trusted_nodes_only = false # Maximum number of backoff attempts before we drop a non-trusted peer max_backoff_count = 5 # DNS resolution refresh interval for trusted nodes trusted_nodes_resolution_interval = '1h' # The duration for which a badly behaving peer is banned ban_duration = '12h' # Temporary per-IP throttle for inbound connection attempts incoming_ip_throttle_duration = '30s' ``` ### `connection_info` This section configures how many peers reth will connect to. ```toml [peers.connection_info] # The maximum number of outbound peers (peers we connect to) max_outbound = 100 # The maximum number of inbound peers (peers that connect to us) max_inbound = 30 # The maximum number of concurrent outbound dials performed at once max_concurrent_outbound_dials = 15 ``` ### `reputation_weights` This section configures the penalty for various offences peers can commit. All peers start out with a reputation of 0, which increases over time as the peer stays connected to us. If the peer misbehaves, various penalties are exacted to their reputation, and if it falls below a certain threshold (currently `50 * -1024`), reth will disconnect and ban the peer temporarily (except for protocol violations which constitute a permanent ban). ```toml [peers.reputation_weights] bad_message = -16384 bad_block = -16384 bad_transactions = -16384 already_seen_transactions = 0 timeout = -4096 bad_protocol = -2147483648 failed_to_connect = -25600 dropped = -4096 bad_announcement = -1024 ``` ### `backoff_durations` If reth fails to establish a connection to a peer, it will not re-attempt for some amount of time, depending on the reason the connection failed. ```toml [peers.backoff_durations] low = '30s' medium = '3m' high = '15m' max = '1h' ``` ## The `[sessions]` section The sessions section configures the internal behavior of a single peer-to-peer connection. You can configure the session buffer sizes, which limits the amount of pending events (incoming messages) and commands (outgoing messages) each session can hold before it will start to ignore messages. > **Note** > > These buffers are allocated *per peer*, which means that increasing the buffer sizes can have large impact on memory consumption. ```toml [sessions] session_command_buffer = 32 session_event_buffer = 260 ``` You can also configure request timeouts: ```toml [sessions.initial_internal_request_timeout] secs = 20 nanos = 0 # The amount of time before the peer will be penalized for # being in violation of the protocol. This exacts a permaban on the peer. [sessions.protocol_breach_request_timeout] secs = 120 nanos = 0 ``` Additionally, you can configure when pending sessions time out, and enforce optional per-state limits. ```toml # Timeout after which a pending session attempt is considered failed [sessions.pending_session_timeout] secs = 20 nanos = 0 # Optional limits (no limits are enforced by default when unset) [sessions.limits] max_pending_inbound = 100 max_pending_outbound = 50 max_established_inbound = 100 max_established_outbound = 50 ``` ## The `[prune]` section The prune section configures the pruning configuration. You can configure the pruning of different segments of the data independently of others. For any unspecified segments, the default setting is no pruning. ### Default config No pruning, run as archive node. ### Example of the custom pruning configuration This configuration will: * Run pruning every 5 blocks * Continuously prune all transaction senders, account history, storage history and bodies history before the block `head-100_000`, i.e. keep the data for the last `100_000` blocks * Prune all receipts before the block 1920000, i.e. keep receipts from the block 1920000 * Keep the last 128 blocks of merkle changesets (default behavior) ```toml [prune] # Minimum pruning interval measured in blocks block_interval = 5 [prune.segments] # Sender Recovery pruning configuration sender_recovery = { distance = 100_000 } # Prune all transaction senders before the block `head-100000`, i.e. keep transaction senders for the last 100001 blocks # Transaction Lookup pruning configuration transaction_lookup = "full" # Prune all TxNumber => TxHash mappings # Receipts pruning configuration. This setting overrides `receipts_log_filter`. receipts = { before = 1920000 } # Prune all receipts from transactions before the block 1920000, i.e. keep receipts from the block 1920000 # Account History pruning configuration account_history = { distance = 100_000 } # Prune all historical account states before the block `head-100000` # Storage History pruning configuration storage_history = { distance = 100_000 } # Prune all historical storage states before the block `head-100000` # Bodies History pruning configuration bodies_history = { distance = 100_000 } # Prune all historical block bodies before the block `head-100000` ``` We can also prune receipts more granular, using the logs filtering: ```toml # Receipts pruning configuration by retaining only those receipts that contain logs emitted # by the specified addresses, discarding all others. This setting is overridden by `receipts`. [prune.segments.receipts_log_filter] # Prune all receipts, leaving only those which: # - Contain logs from address `0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48`, starting from the block 17000000 # - Contain logs from address `0xdac17f958d2ee523a2206206994597c13d831ec7` in the last 1001 blocks "0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48" = { before = 17000000 } "0xdac17f958d2ee523a2206206994597c13d831ec7" = { distance = 1000 } ``` ## The `[static_files]` section Configure static file segmentation. ```toml [static_files.blocks_per_file] # Number of blocks per file for each segment (optional) # Values must be greater than 0 if set headers = 8192 transactions = 8192 receipts = 8192 transaction_senders = 8192 account_change_sets = 8192 ``` [TOML]: https://toml.io/ # Observability with Prometheus & Grafana Reth exposes a number of metrics which can be enabled by adding the `--metrics` flag: ```bash reth node --metrics 127.0.0.1:9001 ``` Additionally, you can export spans to an OpenTelemetry collector using `--tracing-otlp`: ```bash reth node --tracing-otlp=http://localhost:4318/v1/traces ``` Now, as the node is running, you can `curl` the endpoint you provided to the `--metrics` flag to get a text dump of the metrics at that time: ```bash curl 127.0.0.1:9001 ``` The response from this is quite descriptive, but it can be a bit verbose. Plus, it's just a static file of the metrics at the time that you `curl`ed the endpoint. You can run the following command in a separate terminal to periodically poll the endpoint, and just print the values (without the header text) to the terminal: ```bash while true; do date; curl -s localhost:9001 | grep -Ev '^(#|$)' | sort; echo; sleep 10; done ``` We're finally getting somewhere! As a final step, though, wouldn't it be great to see how these metrics progress over time (and generally, in a GUI)? ## Prometheus & Grafana We're going to use Prometheus to scrape the metrics from our node, and use Grafana to on a dashboard. Let's begin by installing both Prometheus and Grafana: ### macOS Using Homebrew: ```bash brew update brew install prometheus brew install grafana ``` ### Linux #### Debian/Ubuntu ```bash # Install Prometheus # Visit https://prometheus.io/download/ for the latest version PROM_VERSION=$(curl -s https://api.github.com/repos/prometheus/prometheus/releases/latest | grep tag_name | cut -d '"' -f 4 | cut -c 2-) wget https://github.com/prometheus/prometheus/releases/download/v${PROM_VERSION}/prometheus-${PROM_VERSION}.linux-amd64.tar.gz tar xvfz prometheus-*.tar.gz cd prometheus-* # Install Grafana sudo apt-get install -y apt-transport-https software-properties-common wget -q -O - https://packages.grafana.com/gpg.key | sudo apt-key add - echo "deb https://packages.grafana.com stable main" | sudo tee -a /etc/apt/sources.list.d/grafana.list sudo apt-get update sudo apt-get install grafana ``` #### Fedora/RHEL/CentOS ```bash # Install Prometheus # Visit https://prometheus.io/download/ for the latest version PROM_VERSION=$(curl -s https://api.github.com/repos/prometheus/prometheus/releases/latest | grep tag_name | cut -d '"' -f 4 | cut -c 2-) wget https://github.com/prometheus/prometheus/releases/download/v${PROM_VERSION}/prometheus-${PROM_VERSION}.linux-amd64.tar.gz tar xvfz prometheus-*.tar.gz cd prometheus-* # Install Grafana # Visit https://grafana.com/grafana/download for the latest version sudo dnf install -y https://dl.grafana.com/oss/release/grafana-latest-1.x86_64.rpm ``` ### Windows #### Using Chocolatey ```powershell choco install prometheus choco install grafana ``` #### Manual installation 1. Download the latest Prometheus from [prometheus.io/download](https://prometheus.io/download/) * Select the Windows binary (.zip) for your architecture (typically windows-amd64) 2. Download the latest Grafana from [grafana.com/grafana/download](https://grafana.com/grafana/download) * Choose the Windows installer (.msi) or standalone version 3. Extract Prometheus to a location of your choice (e.g., `C:\prometheus`) 4. Install Grafana by running the installer or extracting the standalone version 5. Configure Prometheus and Grafana to run as services if needed Then, kick off the Prometheus and Grafana services: ```bash # For macOS brew services start prometheus brew services start grafana # For Linux (syst-based distributions) sudo systemctl start prometheus sudo systemctl start grafana-server # For Windows (if installed as services) Start-Service prometheus Start-Service grafana ``` This will start a Prometheus service which [by default scrapes itself about the current instance](https://prometheus.io/docs/introduction/first_steps/#:~:text=The%20job%20contains%20a%20single,%3A%2F%2Flocalhost%3A9090%2Fmetrics.). So you'll need to change its config to hit your Reth node’s metrics endpoint at `localhost:9001` which you set using the `--metrics` flag. You can find an example config for the Prometheus service in the repo here: [`etc/prometheus/prometheus.yml`](https://github.com/paradigmxyz/reth/blob/main/etc/prometheus/prometheus.yml) Depending on your installation you may find the config for your Prometheus service at: * OSX: `/opt/homebrew/etc/prometheus.yml` * Linuxbrew: `/home/linuxbrew/.linuxbrew/etc/prometheus.yml` * Others: `/usr/local/etc/prometheus/prometheus.yml` Next, open up "localhost:3000" in your browser, which is the default URL for Grafana. Here, "admin" is the default for both the username and password. Once you've logged in, click on "Connections" in the left side panel and select "Data Sources". Click on "Add data source", and select "Prometheus" as the type. In the HTTP URL field, enter http://localhost:9090. Finally, click "Save & Test". As this might be a point of confusion, `localhost:9001`, which we supplied to `--metrics`, is the endpoint that Reth exposes, from which Prometheus collects metrics. Prometheus then exposes `localhost:9090` (by default) for other services (such as Grafana) to consume Prometheus metrics. To configure the dashboard in Grafana, click on the squares icon in the upper left, and click on "New", then "Import". From there, click on "Upload JSON file", and select the example file in [`reth/etc/grafana/dashboards/overview.json`](https://github.com/paradigmxyz/reth/blob/main/etc/grafana/dashboards/overview.json). Finally, select the Prometheus data source you just created, and click "Import". And voilà, you should see your dashboard! If you're not yet connected to any peers, the dashboard will look like it's in an empty state, but once you are, you should see it start populating with data. ## Observability with OTLP Reth supports OTLP via the `tracing` crate, meaning logs and traces can be exported to OpenTelemetry backends. For example, [Grafana Tempo](https://grafana.com/oss/tempo/) and [Jaeger Tracing](https://www.jaegertracing.io/) can be used to query and explore traces and logs from reth. If you already have a backend set up on your infrastructure, you can point reth to export its traces by providing the `--tracing-otlp` argument. To run Jaeger locally, you can read the [Jaeger setup docs](https://www.jaegertracing.io/docs/2.11/getting-started/). This should run Jaeger with the otlp port `4318` and the dashboard port `16686`: ```bash docker run --rm --name jaeger \ -p 16686:16686 \ -p 4317:4317 \ -p 4318:4318 \ -p 5778:5778 \ -p 9411:9411 \ cr.jaegertracing.io/jaegertracing/jaeger:2.11.0 ``` Now we can provide the `--tracing-otlp` argument with reth: ```bash reth node --tracing-otlp=http://localhost:4317 --tracing-otlp-protocol grpc ``` The traces reth exported should now be searchable and viewable on http://localhost:16686. For environments where reth is processing a high number of transactions or blocks, it may be a good idea to bump `OTEL_BLRP_MAX_QUEUE_SIZE`, which has a default of `2048`. This controls how many log records can be recorded before batching and exporting. If this is set to too low of a value, spans and events may be dropped by the exporter. ## Conclusion In this runbook, we took you through starting the node, exposing different log levels, exporting metrics, and finally viewing those metrics in a Grafana dashboard. This will all be very useful to you, whether you're simply running a home node and want to keep an eye on its performance, or if you're a contributor and want to see the effect that your (or others') changes have on Reth's operations. [installation]: ../installation/overview [release-profile]: https://doc.rust-lang.org/cargo/reference/profiles.html#release [docs]: https://github.com/paradigmxyz/reth/tree/main/docs [metrics]: https://reth.rs/run/observability.html # FAQ Storage layout, snapshots, minimal mode, and pruning now live in the [Storage](/run/storage) section. 1. [Transaction Types](/run/faq/transactions) - Learn about the transaction types supported by Reth. 2. [Ports](/run/faq/ports) - Information about the network ports used by Reth for P2P communication, JSON-RPC APIs, and the Engine API for consensus layer communication. 3. [Profiling](/run/faq/profiling) - Performance profiling techniques and tools for analyzing Reth node performance, including CPU profiling, memory analysis, and bottleneck identification. # Transaction types Over time, the Ethereum network has undergone various upgrades and improvements to enhance transaction efficiency, security, and user experience. Five significant transaction types that have evolved are: * Legacy Transactions, * EIP-2930 Transactions, * EIP-1559 Transactions, * EIP-4844 Transactions, * EIP-7702 Transactions Each of these transaction types brings unique features and improvements to the Ethereum network. ## Legacy Transactions Legacy Transactions (type `0x0`), the traditional Ethereum transactions in use since the network's inception, include the following parameters: * `nonce`, * `gasPrice`, * `gasLimit`, * `to`, * `value`, * `data`, * `v`, * `r`, * `s`. These transactions do not utilize access lists, which specify the addresses and storage keys to be accessed, nor do they incorporate EIP-1559 fee market changes. ## EIP-2930 Transactions Introduced in [EIP-2930](https://eips.ethereum.org/EIPS/eip-2930), transactions with type `0x1` incorporate an `accessList` parameter alongside legacy parameters. This `accessList` specifies an array of addresses and storage keys that the transaction plans to access, enabling gas savings on cross-contract calls by pre-declaring the accessed contract and storage slots. They do not include EIP-1559 fee market changes. ## EIP-1559 Transactions [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) transactions (type `0x2`) were introduced in Ethereum's London fork to address network congestion and transaction fee overpricing caused by the historical fee market. Unlike traditional transactions, EIP-1559 transactions don't specify a gas price (`gasPrice`). Instead, they use an in-protocol, dynamically changing base fee per gas, adjusted at each block to manage network congestion. Alongside the `accessList` parameter and legacy parameters (except `gasPrice`), EIP-1559 transactions include: * `maxPriorityFeePerGas`, specifying the maximum fee above the base fee the sender is willing to pay, * `maxFeePerGas`, setting the maximum total fee the sender is willing to pay. The base fee is burned, while the priority fee is paid to the miner who includes the transaction, incentivizing miners to include transactions with higher priority fees per gas. ## EIP-4844 Transactions [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) transactions (type `0x3`) were introduced in Ethereum's Dencun fork. This provides a temporary but significant scaling relief for rollups by allowing them to initially scale to 0.375 MB per slot, with a separate fee market allowing fees to be very low while usage of this system is limited. Alongside the legacy parameters & parameters from EIP-1559, the EIP-4844 transactions include: * `max_fee_per_blob_gas`, The maximum total fee per gas the sender is willing to pay for blob gas in wei * `blob_versioned_hashes`, List of versioned blob hashes associated with the transaction's EIP-4844 data blobs. The actual blob fee is deducted from the sender balance before transaction execution and burned, and is not refunded in case of transaction failure. ## EIP-7702 Transactions [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) transactions (type `0x4`) were introduced in Ethereum's Pectra fork. This provides the ability for a wallet to delegate its execution to an authorized smart contract. Alongside the fields present from the EIP-1559 transaction type, EIP-7702 transactions include: * `authorization_list` * `signature_y_parity` * `signature_r` * `signature_s` where `authorization_list` is a list of authorizations, which are tuples containing the following fields: * `chain_id` * `address` * `nonce` * `y_parity` * `r` * `s` # Ports This section provides essential information about the ports used by the system, their primary purposes, and recommendations for exposure settings. ## Peering Ports * **Port:** `30303` * **Protocol:** TCP and UDP * **Purpose:** Peering with other nodes for synchronization of blockchain data. Nodes communicate through this port to maintain network consensus and share updated information. * **Exposure Recommendation:** This port should be exposed to enable seamless interaction and synchronization with other nodes in the network. ## Discovery v5 Port * **Port:** `9200` * **Protocol:** UDP * **Purpose:** Used for discv5 peer discovery protocol. This is enabled by default and can be disabled with `--disable-discv5-discovery`. It operates independently from the legacy discv4 discovery on port 30303. * **Exposure Recommendation:** This port should be exposed to allow peer discovery. ## Metrics Port * **Port:** `9001` * **Protocol:** TCP * **Purpose:** This port is designated for serving metrics related to the system's performance and operation. It allows internal monitoring and data collection for analysis. * **Exposure Recommendation:** By default, this port should not be exposed to the public. It is intended for internal monitoring and analysis purposes. ## HTTP RPC Port * **Port:** `8545` * **Protocol:** TCP * **Purpose:** Port 8545 provides an HTTP-based Remote Procedure Call (RPC) interface. It enables external applications to interact with the blockchain by sending requests over HTTP. * **Exposure Recommendation:** Similar to the metrics port, exposing this port to the public is not recommended by default due to security considerations. ## WS RPC Port * **Port:** `8546` * **Protocol:** TCP * **Purpose:** Port 8546 offers a WebSocket-based Remote Procedure Call (RPC) interface. It allows real-time communication between external applications and the blockchain. * **Exposure Recommendation:** As with the HTTP RPC port, the WS RPC port should not be exposed by default for security reasons. ## Engine API Port * **Port:** `8551` * **Protocol:** TCP * **Purpose:** Port 8551 facilitates communication between specific components, such as "reth" and "CL" (assuming their definitions are understood within the context of the system). It enables essential internal processes. * **Exposure Recommendation:** This port is not meant to be exposed to the public by default. It should be reserved for internal communication between vital components of the system. # Profiling Reth ## Memory profiling When a program consumes all of the system's available memory (and swap, if any), the OOM killer starts killing processes that are taking up the most memory, until the system has memory available again. [See kernel.org for a great (although outdated) introduction to out-of-memory management.](https://www.kernel.org/doc/gorman/html/understand/understand016.html). Reth distributes to many different hardware targets, some with less memory than others. As a result, sometimes bugs can cause memory leaks or out-of-memory crashes for *some* users, but not others. Reth is also a complex program, with many moving pieces, and it can be difficult to know where to start when debugging an OOM or other memory leak. Understanding how to profile memory usage is an extremely valuable skill when faced with this type of problem, and can quickly help shed light on the root cause of a memory leak. In this tutorial, we will be reviewing: * How to monitor reth's memory usage, * How to emulate a low-memory environment to lab-reproduce OOM crashes, * How to enable `jemalloc` and its built-in memory profiling, and * How to use `jeprof` to interpret heap profiles and identify potential root causes for a memory leak. ### Jemalloc [Jemalloc](https://jemalloc.net/) is a general-purpose allocator that is used [across the industry in production](https://engineering.fb.com/2011/01/03/core-data/scalable-memory-allocation-using-jemalloc/), well known for its performance benefits, predictability, and profiling capabilities. We've seen significant performance benefits in reth when using jemalloc, but will be primarily focusing on its profiling capabilities. Jemalloc also provides tools for analyzing and visualizing its allocation profiles it generates, notably `jeprof`. #### Enabling jemalloc in reth Reth includes a `jemalloc` feature to explicitly use jemalloc instead of the system allocator: ``` cargo build --features jemalloc ``` While the `jemalloc` feature does enable jemalloc, reth has an additional feature, `jemalloc-prof`, that must be used to enable heap profiling. This feature implicitly enables the `jemalloc` feature as well: ``` cargo build --features jemalloc-prof ``` When performing a longer-running or performance-sensitive task with reth, such as a sync test or load benchmark, it's usually recommended to use the `maxperf` profile. However, the `maxperf` profile does not enable debug symbols, which are required for tools like `perf` and `jemalloc` to produce results that a human can interpret. Reth includes a performance profile with debug symbols called `profiling`. To compile reth with debug symbols, jemalloc, profiling, and a performance profile: ``` cargo build --features jemalloc-prof --profile profiling # May improve performance even more RUSTFLAGS="-C target-cpu=native" cargo build --features jemalloc-prof --profile profiling ``` ### Monitoring memory usage Reth's dashboard has a few metrics that are important when monitoring memory usage. The **Jemalloc memory** graph shows reth's memory usage. The *allocated* label shows the memory used by the reth process which cannot be reclaimed unless reth frees that memory. This metric exceeding the available system memory would cause reth to be killed by the OOM killer. Jemalloc memory Some of reth's internal components also have metrics for the memory usage of certain data structures, usually data structures that are likely to contain many elements or may consume a lot of memory at peak load. **The bodies downloader buffer**: The bodies downloader buffer graph **The blockchain tree block buffer**: The blockchain tree block buffer graph **The transaction pool subpools**: The transaction pool subpool size graph One of these metrics growing beyond, 2GB for example, is likely a bug and could lead to an OOM on a low memory machine. It isn't likely for that to happen frequently, so in the best case these metrics can be used to rule out these components from having a leak, if an OOM is occurring. ### Limiting process memory Memory leaks that cause OOMs can be difficult to trigger sometimes, and highly depend on the testing hardware. A testing machine with 128GB of RAM is not going to encounter OOMs caused by memory spikes or leaks as often as a machine with only 8GB of RAM. Development machines are powerful for a reason, so artificially limiting memory usage is often the best way to replicate a user's hardware. This can help developers debug issues that only occur on devices with limited hardware. `cgroups` is a tool that allows developers to limit the memory usage of a process, making it extremely useful to developers in understanding how their application performs in low-memory environments. See the [canonical documentation for cgroups](https://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git/tree/Documentation/admin-guide/cgroup-v2.rst) for more information. ### How to use cgroups to limit process memory In order to use cgroups to limit process memory, sometimes it must be explicitly enabled as a kernel parameter. For example, the following line is sometimes necessary to enable cgroup memory limits on Ubuntu machines that use GRUB: ``` GRUB_CMDLINE_LINUX_DEFAULT="cgroup_enable=memory" ``` Then, create a named cgroup: ``` sudo cgcreate -t $USER:$USER -a $USER:$USER -g memory:rethMemory ``` The memory limit for the named cgroup can be set in `sys/fs/cgroup/memory`. This for example sets an 8 gigabyte memory limit: ``` echo 8G > /sys/fs/cgroup/memory/rethMemory/memory.limit_in_bytes ``` If the intention of setting up the cgroup is to strictly limit memory and simulate OOMs, a high amount of swap may prevent those OOMs from happening. To check swap, use `free -m`: ``` ubuntu@bench-box:~/reth$ free -m total used free shared buff/cache available Mem: 257668 10695 218760 12 28213 244761 Swap: 8191 159 8032 ``` If this is a problem, it may be worth either adjusting the system swappiness or disabling swap overall. Finally, `cgexec` can be used to run reth under the cgroup: ``` cgexec -g memory:rethMemory reth node ``` ### Understanding allocation with jeprof When reth is built with the `jemalloc-prof` feature, profiling is already enabled at compile time — the binary embeds `prof:true,prof_active:true,lg_prof_sample:19` via a `malloc_conf` static. No environment variable is needed to turn on profiling. To configure additional options like `lg_prof_interval` at runtime, use the `MALLOC_CONF` environment variable: ``` MALLOC_CONF=lg_prof_interval:32 reth node ``` If you see errors like this: ``` : Invalid conf pair: prof:true ``` It means reth was not built with the `jemalloc-prof` feature, so jemalloc does not have profiling support compiled in. Rebuild with: ``` cargo build --features jemalloc-prof ``` If everything is working, this will output `jeprof.*.heap` files while reth is running. [The jemalloc website](https://jemalloc.net/jemalloc.3.html#opt.abort) has a helpful overview of the options available, for example `lg_prof_interval`, `lg_prof_sample`, `prof_leak`, and `prof_final`. Now that we have the heap snapshots, we can analyze them using `jeprof`. An example of jeprof usage and output can be seen on the jemalloc github repository: https://github.com/jemalloc/jemalloc/wiki/Use-Case:-Leak-Checking ### HTTP pprof endpoint When built with the `jemalloc-prof` feature, reth exposes a heap profiling endpoint on the metrics server (default port 9001) at `/debug/pprof/heap`. This endpoint returns heap profiles in [pprof format](https://github.com/google/pprof), which is compatible with the standard `pprof` toolchain. By default, the pprof output contains raw addresses that require external symbolization. You need either `addr2line` or `llvm-addr2line` in your PATH for `pprof` to resolve function names. For pre-symbolized profiles (useful on macOS or when external tools are unavailable), build with the `jemalloc-symbols` feature: ``` cargo build --features jemalloc-prof,jemalloc-symbols --profile profiling ``` # Reth for Developers Reth can be used as a library to build custom Ethereum nodes, interact with blockchain data, or create specialized tools for blockchain analysis and indexing. ## What is the Reth SDK? The Reth SDK allows developers to: * Use components of the Reth node as libraries * Build custom Ethereum execution nodes with modified behavior (e.g. payload building) * Access blockchain data directly from the database * Create high-performance indexing solutions * Extend a new with new RPC endpoints and functionality * Implement custom consensus mechanisms * Build specialized tools for blockchain analysis ## Quick Start Add Reth to your project ### Ethereum ```toml [dependencies] # Ethereum meta crate reth-ethereum = { git = "https://github.com/paradigmxyz/reth" } ``` ## Key Concepts ### Node Architecture Reth is built with modularity in mind. The main components include: * **Primitives**: Core data type abstractions like `Block` * **Node Builder**: Constructs and configures node instances * **Database**: Efficient storage using MDBX and static files * **Network**: P2P communication and block synchronization * **Consensus**: Block validation and chain management * **EVM**: Transaction execution and state transitions * **RPC**: JSON-RPC server for external communication * **Transaction Pool**: Pending transaction management ### Dependency Management Reth is primarily built on top of the [alloy](https://github.com/alloy-rs/alloy) ecosystem, which provides the necessary abstractions and implementations for core ethereum blockchain data types, transaction handling, and EVM execution. ### Type System Reth uses its own type system to handle different representations of blockchain data: * **Primitives**: Core types like `B256`, `Address`, `U256` * **Transactions**: Multiple representations for different contexts (pooled, consensus, RPC) * **Blocks**: Headers, bodies, and sealed blocks with proven properties * **State**: Accounts, storage, and state transitions ### Building Custom Nodes The node builder pattern allows you to customize every aspect of node behavior: ```rust use reth_ethereum::node::{EthereumNode, NodeBuilder}; // Build a custom node with modified components let node = NodeBuilder::new(config) // install the ethereum specific node primitives .with_types::() .with_components(|components| { // Customize components here components }) .build() .await?; ``` ## Architecture Overview ```mermaid graph TD A[Node Builder] --> B[Database] A --> C[Network] A --> D[Consensus] A --> E[EVM] A --> F[RPC Server] A --> G[Transaction Pool] B --> H[DB Storage] B --> I[Static Files] C --> J[Discovery] C --> K[ETH Protocol] E --> L[State Provider] E --> M[Block Executor] ``` ## Nodes Built with Reth Several production networks have been built using Reth's node builder pattern: | Node | Company | Description | Lines of Code | |------|---------|-------------|---------------| | [Base Node](https://github.com/base/node-reth) | Coinbase | Coinbase's L2 scaling solution node implementation | ~3K | | [Bera Reth](https://github.com/berachain/bera-reth) | Berachain | Berachain's high-performance EVM node with custom features | ~1K | | [Reth Gnosis](https://github.com/gnosischain/reth_gnosis) | Gnosis | Gnosis Chain's xDai-compatible execution client | ~5K | | [Reth BSC](https://github.com/loocapro/reth-bsc) | Binance Smart Chain | BNB Smart Chain execution client implementation | ~6K | ## Next Steps * **[Node Components](/sdk/node-components)**: Deep dive into each component * **[Type System](/sdk/typesystem/block)**: Understanding Reth's type system ## Resources * [API Documentation](https://docs.rs/reth/latest/reth/) * [GitHub Repository](https://github.com/paradigmxyz/reth) # Block Types The Reth type system provides a flexible abstraction for blocks through traits, allowing different implementations while maintaining type safety and consistency. ## Type Relationships ```mermaid graph TD Block[Block Trait] --> Header[BlockHeader Trait] Block --> Body[BlockBody Trait] SealedBlock -.-> Block SealedBlock --> SealedHeader RecoveredBlock --> SealedBlock SealedHeader --> Header Body --> Transaction[Transactions] Body --> Withdrawals[Withdrawals] ``` ## Next Steps * Learn about [Transaction Types](/sdk/typesystem/transaction-types) * Understand [Consensus](/sdk/node-components/consensus) validation * Explore [EVM](/sdk/node-components/evm) execution # Transaction Types and Representations Reth provides multiple transaction representations optimized for different stages of the transaction lifecycle. Understanding these types is crucial for working with the node's transaction handling pipeline. ## Transaction Lifecycle Transactions go through several stages, each with its own optimized representation: ```mermaid graph LR RPC[RPC Transaction] --> Pool[Pooled Transaction] Pool --> Consensus[Consensus Transaction] Consensus --> Executed[Executed Transaction] Pool -.-> RPC Consensus -.-> Pool ``` ## Transaction Representations ### RPC Transaction The RPC representation is designed for JSON-RPC communication with external clients. It uses JSON-compatible types and includes all information clients need to understand transaction status. Key characteristics: * **JSON-compatible types**: Uses U256 for numbers, hex strings for binary data * **Optional fields**: Supports both legacy and EIP-1559 transactions with appropriate fields * **Block context**: Includes block hash, number, and index when transaction is mined * **Human-readable**: Optimized for external consumption and debugging * **Complete information**: Contains all transaction details including signature components Use cases: * Sending transactions via `eth_sendTransaction` * Querying transaction details via `eth_getTransactionByHash` * Transaction receipts and history * Block explorer displays ### Pooled Transaction The pooled representation is optimized for mempool storage and validation. It pre-computes expensive values and includes additional data needed for pool management. Key characteristics: * **Cached values**: Pre-computed sender address and transaction cost to avoid repeated calculations * **Validation ready**: Includes all data needed for quick pool validation * **Blob support**: Handles EIP-4844 blob sidecars separately from the core transaction * **Memory efficient**: Optimized structure for storing thousands of pending transactions * **Priority ordering**: Structured for efficient sorting by gas price/priority fee Use cases: * Transaction pool storage and management * Gas price ordering and replacement logic * Validation against account state * Broadcasting to peers ### Consensus Transaction The consensus representation is the canonical format used in blocks and for network propagation. It's the most compact representation and follows Ethereum's wire protocol. Key characteristics: * **Type safety**: Enum variants for different transaction types (Legacy, EIP-2930, EIP-1559, EIP-4844) * **Compact encoding**: For storage on disk * **No redundancy**: Minimal data, with values like sender recovered from signature when needed Use cases: * Block construction and validation * Network propagation between nodes * Persistent storage in the database * State transition execution ## Representation Conversions ### RPC → Pooled When transactions arrive via RPC: 1. Validate JSON format and fields 2. Convert to consensus format 3. Recover sender from signature 4. Create pooled representation ### Pooled → Consensus When including in a block: 1. Extract core transaction consensus data 2. Remove cached values (sender, cost) ### Consensus → RPC When serving RPC requests: 1. Add block context (hash, number, index) ## Next Steps * Learn about [Block Types](/sdk/typesystem/block) and how transactions fit in blocks * Understand [Transaction Pool](/sdk/node-components/pool) management * Explore [EVM](/sdk/node-components/evm) transaction execution # Network Component The network component handles all peer-to-peer communication in Reth, including peer discovery, connection management, and protocol message handling. ## Overview The network stack implements the Ethereum Wire Protocol (ETH) and provides: * Peer discovery via discv4 and discv5 * Connection management with configurable peer limits * Transaction propagation * State synchronization * Request/response protocols (e.g. GetBlockHeaders, GetBodies) ## Architecture ```mermaid graph TD NetworkManager[Network Manager] --> Discovery[Discovery] NetworkManager --> Sessions[Session Manager] NetworkManager --> Swarm[Swarm] Discovery --> discv4[discv4] Discovery --> discv5[discv5] Discovery --> DNS[DNS Discovery] Sessions --> ETH[ETH Protocol] ``` ## Key Concepts ### Peer Discovery The network uses multiple discovery mechanisms to find and connect to peers: * **discv4**: UDP-based discovery protocol for finding peers * **discv5**: Improved discovery protocol with better security * **DNS Discovery**: Peer lists published via DNS for bootstrap ### Connection Management * Maintains separate limits for inbound and outbound connections * Implements peer scoring and reputation tracking * Handles connection lifecycle and graceful disconnections ### Protocol Support * **ETH Protocol**: Core Ethereum wire protocol for blocks and transactions ### Network Mode * **PoS networks**: Block broadcasting is disabled and considered a protocol violation. New blocks are obtained from the consensus layer and requested over devp2p. * **PoW networks**: Block announcements are enabled to help propagate new blocks quickly. ### Message Broadcasting The network efficiently propagates new blocks and transactions to peers using: * Transaction pooling and deduplication * Block announcement strategies * Bandwidth management Note: In PoS networks, block broadcasting is disabled and considered a protocol violation. New blocks are obtained via the consensus layer (CL) and requested over devp2p. In PoW mode, block announcements are enabled. ### Transaction Gossip Control * A `tx_gossip_disabled` flag can be used to disable transaction gossip end-to-end. * This is useful for private nodes, bandwidth-constrained deployments, or setups that rely on out-of-band transaction ingestion. ### NAT and External IP Resolution * Optional NAT resolver support helps determine and advertise the correct external IP and port for discovery and inbound connectivity. ## Next Steps * Learn about the [Transaction Pool](/sdk/node-components/pool) * Understand [Consensus](/sdk/node-components/consensus) integration * Explore [RPC](/sdk/node-components/rpc) server setup # Transaction Pool Component The transaction pool (mempool) manages pending transactions before they are included in blocks. It handles validation, ordering, replacement, and eviction of transactions. ## Overview The transaction pool is responsible for: * Validating incoming transactions * Maintaining transaction ordering (e.g. by fees) * Handling transaction replacement * Managing pool size limits * Broadcasting transactions to peers * Providing transactions for block building ## Architecture ```mermaid graph TD API[Pool API] --> Validator[Transaction Validator] API --> Pool[Transaction Pool] Pool --> SubPools[Sub-Pools] SubPools --> Pending[Pending Pool] SubPools --> Queued[Queued Pool] SubPools --> Base[Base Fee Pool] SubPools --> Blob[Blob Pool] Pool --> Ordering[Transaction Ordering] Pool --> Listeners[Event Listeners] Validator --> Checks[Validation Checks] Checks --> Nonce[Nonce Check] Checks --> Balance[Balance Check] ``` ## Key Concepts ### Transaction Validation The pool validates transactions before accepting them, checking: * Sender has sufficient balance for gas and value * Nonce is correct (either next expected or future) * Gas price meets minimum requirements * Transaction size is within limits * Signature is valid ### Transaction Ordering Transactions are ordered by their effective tip per gas to maximize block rewards. Custom ordering strategies can prioritize certain addresses or implement MEV protection. ### Sub-Pools * **Pending**: Transactions ready for inclusion (correct nonce) * **Queued**: Future transactions (nonce gap exists) * **Base Fee**: Transactions priced below current base fee * **Blob**: Blob transactions that currently do not meet base fee and/or blob fee requirements ### Pool Maintenance The pool requires periodic maintenance to: * Remove stale transactions * Revalidate after chain reorganizations * Update base fee thresholds * Enforce size limits ## Advanced Features ### Blob Transaction Support EIP-4844 introduces blob transactions with separate blob storage and special validation rules. ### Transaction Filters Custom filters can block specific addresses, limit gas prices, or implement custom acceptance criteria. ### Event System The pool supports an event system that allows other components to listen for transaction lifecycle events such as: * Transaction added * Transaction removed * Transaction replaced * Transaction promoted to pending state ## Next Steps * Learn about [Consensus](/sdk/node-components/consensus) validation * Explore [EVM](/sdk/node-components/evm) execution * Understand [RPC](/sdk/node-components/rpc) server integration # Consensus Component The consensus component validates blocks according to Ethereum protocol rules, handles chain reorganizations, and manages the canonical chain state. ## Overview The consensus component is responsible for: * Validating block headers and bodies * Verifying state transitions * Managing fork choice rules * Handling chain reorganizations * Tracking finalized and safe blocks * Validating blob transactions (EIP-4844) ## Key Concepts ### Block Validation The consensus component performs multiple validation steps: 1. **Pre-execution validation**: Header and body checks before running transactions 2. **Post-execution validation**: State root and receipts verification after execution ### Header Validation Headers must pass several checks: * **Timestamp**: Must be greater than parent's timestamp * **Gas limit**: Changes must be within protocol limits (1/1024 of parent) * **Extra data**: Size restrictions based on network rules * **Difficulty/PoS**: Appropriate validation for pre/post-merge ### Body Validation Block bodies are validated against headers: * **Transaction root**: Merkle root must match header * **Withdrawals root**: For post-Shanghai blocks * **Blob validation**: For EIP-4844 transactions ### Fork Choice The consensus engine determines the canonical chain: * Tracks multiple chain branches * Applies fork choice rules (longest chain, most work, etc.) * Handles reorganizations when better chains are found ## Next Steps * Explore [EVM](/sdk/node-components/evm) execution * Learn about [RPC](/sdk/node-components/rpc) server integration * Understand [Transaction Pool](/sdk/node-components/pool) interaction # EVM Component The EVM (Ethereum Virtual Machine) component handles transaction execution and state transitions. It's responsible for processing transactions and updating the blockchain state. ## Overview The EVM component manages: * Transaction execution * State transitions and updates * Gas calculation and metering * Custom precompiles and opcodes * Block execution and validation * State management and caching ## Architecture ```mermaid graph TD Config[EVM Configuration] --> Env[EVM Environment] Config --> Executor[Block Executor] Config --> Builder[Block Builder] Executor --> State[(State Database)] Builder --> State Builder --> Assembler[Block Assembler] Assembler --> State ``` ## Key Concepts ### Transaction Execution The EVM executes transactions in a deterministic way: 1. **Environment Setup**: Configure block and transaction context 2. **State Access**: Load accounts and storage from the database 3. **Execution**: Run EVM bytecode with gas metering 4. **State Updates**: Apply changes to accounts and storage 5. **Receipt Generation**: Create execution receipts with logs ### Block Execution Block executors process all transactions in a block: * Validate pre-state conditions * Execute transactions sequentially * Apply block rewards * Verify post-state (state root, receipts root) ### Block Building Block builders construct new blocks for proposal: * Select transactions (e.g. mempool) * Order and execute transactions * Seal the block with a header (state root) ## Next Steps * Learn about [RPC](/sdk/node-components/rpc) server integration * Explore [Transaction Pool](/sdk/node-components/pool) interaction * Review [Consensus](/sdk/node-components/consensus) validation # RPC Component The RPC component provides external API access to the node, implementing the Ethereum JSON-RPC specification and allowing custom extensions. ## Overview The RPC component provides: * Standard Ethereum JSON-RPC methods * WebSocket subscriptions * Custom method extensions * Rate limiting and access control * Request batching support * Multiple transport protocols (HTTP, WebSocket, IPC) ## Next Steps * Explore [Network](/sdk/node-components/network) component integration * Learn about [Transaction Pool](/sdk/node-components/pool) * Understand [EVM](/sdk/node-components/evm) execution context # Execution Extensions (ExEx) ## What are Execution Extensions? Execution Extensions (or ExExes, for short) allow developers to build their own infrastructure that relies on Reth as a base for driving the chain forward. An Execution Extension is a task that derives its state from changes in Reth's state. Some examples of such state derivations are rollups, bridges, and indexers. They are called Execution Extensions because the main trigger for them is the execution of new blocks (or reorgs of old blocks) initiated by Reth. Read more about things you can build with Execution Extensions in the [Paradigm blog](https://www.paradigm.xyz/2024/05/reth-exex). ## Architecture ```mermaid graph LR subgraph "Reth Process" Reth[Reth Core] Reth -->|Notifications| ExEx1[ExEx 1] Reth -->|Notifications| ExEx2[ExEx 2] Reth -->|Notifications| ExEx3[ExEx N] ExEx1 -->|Events| Reth ExEx2 -->|Events| Reth ExEx3 -->|Events| Reth end ExEx1 --> External1[External System 1] ExEx2 --> External2[External System 2] ExEx3 --> External3[External System N] ``` ## What Execution Extensions are not Execution Extensions are not separate processes that connect to the main Reth node process. Instead, ExExes are compiled into the same binary as Reth, and run alongside it, using shared memory for communication. If you want to build an Execution Extension that sends data into a separate process, check out the [Remote](/exex/remote) chapter. ## How do I build an Execution Extension? Let's dive into how to build our own ExEx from scratch, add tests for it, and run it on the Holesky testnet. 1. [How do ExExes work?](/exex/how-it-works) 2. [Hello World](/exex/hello-world) 3. [Tracking State](/exex/tracking-state) 4. [Remote](/exex/remote) :::tip For more practical examples and ready-to-use ExEx implementations, check out the [reth-exex-examples](https://github.com/paradigmxyz/reth-exex-examples) repository which contains various ExEx examples including indexers, bridges, and other state derivation patterns. ::: # How do ExExes work? ## Architecture ```mermaid sequenceDiagram participant Reth participant ExEx Note over Reth,ExEx: Normal Flow Reth->>ExEx: ChainCommit Notification activate ExEx ExEx->>ExEx: Process Block Data ExEx->>Reth: FinishedHeight Event deactivate ExEx Note over Reth,ExEx: Reorg Flow Reth->>ExEx: ChainReorg Notification activate ExEx ExEx->>ExEx: Rollback & Re-process ExEx->>Reth: New FinishedHeight Event deactivate ExEx Note over Reth,ExEx: Revert Flow Reth->>ExEx: ChainRevert Notification activate ExEx ExEx->>ExEx: Rollback & Re-process ExEx->>Reth: New FinishedHeight Event deactivate ExEx ``` ExExes are just [Futures](https://doc.rust-lang.org/std/future/trait.Future.html) that run indefinitely alongside Reth – as simple as that. An ExEx is usually driven by and acts on new notifications about chain commits, reverts, and reorgs, but it can span beyond that. They are installed into the node by using the [node builder](https://reth.rs/docs/reth/builder/struct.NodeBuilder.html). Reth manages the lifecycle of all ExExes, including: * Polling ExEx futures * Sending [notifications](https://reth.rs/docs/reth_exex/enum.ExExNotification.html) about new chain, reverts, and reorgs from historical and live sync * Processing [events](https://reth.rs/docs/reth_exex/enum.ExExEvent.html) emitted by ExExes * Pruning (in case of a full or pruned node) only the data that has been processed by all ExExes * Shutting ExExes down when the node is shut down ## Pruning Pruning deserves a special mention here. ExExes **SHOULD** emit an [`ExExEvent::FinishedHeight`](https://reth.rs/docs/reth_exex/enum.ExExEvent.html#variant.FinishedHeight) event to signify what blocks have been processed. This event is used by Reth to determine what state can be pruned. An ExEx will only receive notifications for block numbers greater than the block in the most recently emitted `FinishedHeight` event. To clarify: if an ExEx emits `ExExEvent::FinishedHeight` for `block #0` it will receive notifications for any `block_number > 0`. # Hello World Let's write a simple "Hello World" ExEx that emits a log every time a new chain of blocks is committed, reverted, or reorged. ### Create a project First, let's create a new project for our ExEx ```console cargo new --bin my-exex cd my-exex ``` And add Reth as a dependency in `Cargo.toml` ```toml // [!include ~/snippets/sources/exex/hello-world/Cargo.toml] ``` ### Default Reth node Now, let's jump to our `main.rs` and start by initializing and launching a default Reth node ```rust // [!include ~/snippets/sources/exex/hello-world/src/bin/1.rs] ``` You can already test that it works by running the binary and initializing the Holesky node in a custom datadir (to not interfere with any instances of Reth you already have on your machine): ```console $ cargo run -- init --chain holesky --datadir data 2024-06-12T16:48:06.420296Z INFO reth init starting 2024-06-12T16:48:06.422380Z INFO Opening storage db_path="data/db" sf_path="data/static_files" 2024-06-12T16:48:06.432939Z INFO Verifying storage consistency. 2024-06-12T16:48:06.577673Z INFO Genesis block written hash=0xb5f7f912443c940f21fd611f12828d75b53 4364ed9e95ca4e307729a4661bde4 ``` ### Simplest ExEx The simplest ExEx is just an async function that never returns. We need to install it into our node ```rust // [!include ~/snippets/sources/exex/hello-world/src/bin/2.rs] ``` See that unused `_ctx`? That's the context that we'll use to listen to new notifications coming from the main node, and send events back to it. It also contains all components that the node exposes to the ExEx. Currently, our ExEx does absolutely nothing by running an infinite loop in an async function that never returns.
It's important that the future returned by the ExEx (`my_exex`) never resolves. If you try running a node with an ExEx that exits, the node will exit as well.
### Hello World ExEx Now, let's extend our simplest ExEx and start actually listening to new notifications, log them, and send events back to the main node ```rust // [!include ~/snippets/sources/exex/hello-world/src/bin/3.rs] ``` Woah, there's a lot of new stuff here! Let's go through it step by step: * First, we've added a `while let Some(notification) = ctx.notifications.try_next().await?` loop that waits for new notifications to come in. * The main node is responsible for sending notifications to the ExEx, so we're waiting for them to come in. * Next, we've added a `match ¬ification { ... }` block that matches on the type of the notification. * In each case, we're logging the notification and the corresponding block range, be it a chain commit, revert, or reorg. * Finally, we're checking if the notification contains a committed chain, and if it does, we're sending a `ExExEvent::FinishedHeight` event back to the main node using the `ctx.events.send` method.
Sending an `ExExEvent::FinishedHeight` event is a very important part of every ExEx. It's the only way to communicate to the main node that the ExEx has finished processing the specified height and it's safe to prune the associated data.
What we've arrived at is the [minimal ExEx example](https://github.com/paradigmxyz/reth-exex-examples/blob/4f3498f0cc00e038d6d8c32cd94fe82788862f49/minimal/src/main.rs) that we provide in the [reth-exex-examples](https://github.com/paradigmxyz/reth-exex-examples) repository. ## What's next? Let's do something a bit more interesting, and see how you can [keep track of some state](/exex/tracking-state) inside your ExEx. # Tracking State In this chapter, we'll learn how to keep track of some state inside our ExEx. Let's continue with our Hello World example from the [previous chapter](/exex/hello-world). ### Turning ExEx into a struct First, we need to turn our ExEx into a stateful struct. Before, we had just an async function, but now we'll need to implement the [`Future`](https://doc.rust-lang.org/std/future/trait.Future.html) trait manually.
Having a stateful async function is also possible, but it makes testing harder, because you can't access variables inside the function to assert the state of your ExEx.
```rust // [!include ~/snippets/sources/exex/tracking-state/src/bin/1.rs] ``` For those who are not familiar with how async Rust works on a lower level, that may seem scary, but let's unpack what's going on here: 1. Our ExEx is now a `struct` that contains the context and implements the `Future` trait. It's now pollable (hence `await`-able). 2. We can't use `self` directly inside our `poll` method, and instead need to acquire a mutable reference to the data inside of the `Pin`. Read more about pinning in [the book](https://rust-lang.github.io/async-book/part-reference/pinning.html). 3. We also can't use `await` directly inside `poll`, and instead need to poll futures manually. We wrap the call to `poll_recv(cx)` into a [`ready!`](https://doc.rust-lang.org/std/task/macro.ready.html) macro, so that if the channel of notifications has no value ready, we will instantly return `Poll::Pending` from our Future. 4. We initialize and return the `MyExEx` struct directly in the `install_exex` method, because it's a Future. With all that done, we're now free to add more fields to our `MyExEx` struct, and track some state in them. ### Adding state Our ExEx will count the number of transactions in each block and log it to the console. ```rust // [!include ~/snippets/sources/exex/tracking-state/src/bin/2.rs] ``` As you can see, we added two fields to our ExEx struct: * `first_block` to keep track of the first block that was committed since the start of the ExEx. * `transactions` to keep track of the total number of transactions committed, accounting for reorgs and reverts. We also changed our `match` block to two `if` clauses: * First one checks if there's a reverted chain using `notification.reverted_chain()`. If there is: * We subtract the number of transactions in the reverted chain from the total number of transactions. * It's important to do the `saturating_sub` here, because if we just started our node and instantly received a reorg, our `transactions` field will still be zero. * Second one checks if there's a committed chain using `notification.committed_chain()`. If there is: * We update the `first_block` field to the first block of the committed chain. * We add the number of transactions in the committed chain to the total number of transactions. * We send a `FinishedHeight` event back to the main node. Finally, on every notification, we log the total number of transactions and the first block that was committed since the start of the ExEx. # Remote Execution Extensions In this chapter, we will learn how to create an ExEx that emits all notifications to an external process. We will use [Tonic](https://github.com/hyperium/tonic) to create a gRPC server and a client. * The server binary will have the Reth client, our ExEx and the gRPC server. * The client binary will have the gRPC client that connects to the server. ## Prerequisites See [section](https://github.com/hyperium/tonic?tab=readme-ov-file#dependencies) of the Tonic documentation to install the required dependencies. ## Create a new project Let's create a new project. Don't forget to provide the `--lib` flag to `cargo new`, because we will have two custom binaries in this project that we will create manually. ```console $ cargo new --lib exex-remote $ cd exex-remote ``` We will also need a bunch of dependencies. Some of them you know from the [Hello World](/exex/hello-world) chapter, but some of specific to what we need now. ```toml // [!include ~/snippets/sources/exex/remote/Cargo.toml] ``` We also added a build dependency for Tonic. We will use it to generate the Rust code for our Protobuf definitions at compile time. Read more about using Tonic in the [introductory tutorial](https://github.com/hyperium/tonic/blob/6a213e9485965db0628591e30577ed81cdaeaf2b/examples/helloworld-tutorial.md). Also, we now have two separate binaries: * `exex` is the server binary that will run the ExEx and the gRPC server. * `consumer` is the client binary that will connect to the server and receive notifications. ### Create the Protobuf definitions In the root directory of your project (not `src`), create a new directory called `proto` and a file called `exex.proto`. We define a service called `RemoteExEx` that exposes a single method called `Subscribe`. This method streams notifications to the client.
A proper way to represent the notification would be to define all fields in the schema, but it goes beyond the scope of this chapter. For an example of a full schema, see the [Remote ExEx](https://github.com/paradigmxyz/reth-exex-examples/blob/1f74410740ac996276a84ee72003f4f9cf041491/remote/proto/exex.proto) example.
```protobuf // [!include ~/snippets/sources/exex/remote/proto/exex.proto] ``` To instruct Tonic to generate the Rust code using this `.proto`, add the following lines to your `lib.rs` file: ```rust // [!include ~/snippets/sources/exex/remote/src/lib.rs] ``` ## ExEx and gRPC server We will now create the ExEx and the gRPC server in our `src/exex.rs` file. ### gRPC server Let's create a minimal gRPC server that listens on the port `:10000`, and spawn it using the [NodeBuilder](https://reth.rs/docs/reth/builder/struct.NodeBuilder.html)'s [task executor](https://reth.rs/docs/reth/tasks/type.TaskExecutor.html). ```rust // [!include ~/snippets/sources/exex/remote/src/exex_1.rs] ``` Currently, it does not send anything on the stream. We need to create a communication channel between our future ExEx and this gRPC server to send new `ExExNotification` on it. Let's create this channel in the `main` function where we will have both gRPC server and ExEx initiated, and save the sender part (that way we will be able to create new receivers) of this channel in our gRPC server. ```rust // [!include ~/snippets/sources/exex/remote/src/exex_2.rs] ``` And with that, we're ready to handle incoming notifications, serialize them with [bincode](https://docs.rs/bincode/) and send back to the client. For each incoming request, we spawn a separate tokio task that will run in the background, and then return the stream receiver to the client. ```rust // [!include ~/snippets/sources/exex/remote/src/exex_3.rs] ``` That's it for the gRPC server part! It doesn't receive anything on the `notifications` channel yet, but we will fix it with our ExEx. ### ExEx Now, let's define the ExEx part of our binary. Our ExEx accepts a `notifications` channel and redirects all incoming `ExExNotification`s to it.
Don't forget to emit `ExExEvent::FinishedHeight`
```rust // [!include ~/snippets/sources/exex/remote/src/exex_4.rs] ``` All that's left is to connect all pieces together: install our ExEx in the node and pass the sender part of communication channel to it. ```rust // [!include ~/snippets/sources/exex/remote/src/exex.rs] ``` ### Full `exex.rs` code
Click to expand ```rust // [!include ~/snippets/sources/exex/remote/src/exex.rs] ```
## Consumer Consumer will be a much simpler binary that just connects to our gRPC server and prints out all the notifications it receives.
We need to increase maximum message encoding and decoding sizes to `usize::MAX`, because notifications can get very heavy
```rust // [!include ~/snippets/sources/exex/remote/src/consumer.rs] ``` ## Running In one terminal window, we will run our ExEx and gRPC server. It will start syncing Reth on the Holesky chain and use Etherscan in place of a real Consensus Client. Make sure to have `ETHERSCAN_API_KEY` on your env. ```console export ETHERSCAN_API_KEY={YOUR_API_KEY} && cargo run --bin exex --release -- node --chain holesky --debug.etherscan ``` And in the other, we will run our consumer: ```console cargo run --bin consumer --release ``` ![remote\_exex](/remote_exex.png) # JSON-RPC You can interact with Reth over JSON-RPC. Reth supports all standard Ethereum JSON-RPC API methods. JSON-RPC is provided on multiple transports. Reth supports HTTP, WebSocket and IPC (both UNIX sockets and Windows named pipes). Transports must be enabled through command-line flags. The JSON-RPC APIs are grouped into namespaces, depending on their purpose. All method names are composed of their namespace and their name, separated by an underscore. Each namespace must be explicitly enabled. ## Namespaces The methods are grouped into namespaces, which are listed below: | Namespace | Description | Sensitive | | -------------------- | ------------------------------------------------------------------------------------------------------ | --------- | | [`eth`](/jsonrpc/eth) | The `eth` API allows you to interact with Ethereum. | Maybe | | [`web3`](/jsonrpc/web3) | The `web3` API provides utility functions for the web3 client. | No | | [`net`](/jsonrpc/net) | The `net` API provides access to network information of the node. | No | | [`txpool`](/jsonrpc/txpool) | The `txpool` API allows you to inspect the transaction pool. | No | | [`debug`](/jsonrpc/debug) | The `debug` API provides several methods to inspect the Ethereum state, including Geth-style traces. | No | | [`trace`](/jsonrpc/trace) | The `trace` API provides several methods to inspect the Ethereum state, including Parity-style traces. | No | | [`admin`](/jsonrpc/admin) | The `admin` API allows you to configure your node. | **Yes** | | [`rpc`](/jsonrpc/rpc) | The `rpc` API provides information about the RPC server and its modules. | No | | [`reth`](/jsonrpc/reth) | The `reth` API provides reth-specific methods like balance changes and chain notifications. | No | | `ots` | The `ots` API provides Otterscan-compatible methods for block exploration. | No | | `flashbots` | The `flashbots` API provides block submission validation methods for builders. | No | | `miner` | The `miner` API allows you to configure miner/builder settings like extra data and gas limits. | **Yes** | | `mev` | The `mev` API provides MEV bundle submission and simulation methods. | No | | `testing` | The `testing` API provides methods for building blocks in a single call (testing only). | **Yes** | Note that some APIs are sensitive, since they can be used to configure your node (`admin`, `miner`), access accounts stored on the node (`eth`), or perform testing operations (`testing`). Generally, it is advisable to not expose any JSONRPC namespace publicly, unless you know what you are doing. ## Transports Reth supports HTTP, WebSockets and IPC. ### HTTP Using the HTTP transport, clients send a request to the server and immediately get a response back. The connection is closed after the response for a given request is sent. Because HTTP is unidirectional, subscriptions are not supported. To start an HTTP server, pass `--http` to `reth node`: ```bash reth node --http ``` The default port is `8545`, and the default listen address is localhost. You can configure the listen address and port using `--http.addr` and `--http.port` respectively: ```bash reth node --http --http.addr 127.0.0.1 --http.port 12345 ``` To enable JSON-RPC namespaces on the HTTP server, pass each namespace separated by a comma to `--http.api`: ```bash reth node --http --http.api eth,net,trace ``` You can pass the `all` option, which is a convenient wrapper for all the JSON-RPC namespaces `admin,debug,eth,net,trace,txpool,web3,rpc,reth,ots,flashbots,miner,mev,testing` on the HTTP server: ```bash reth node --http --http.api all ``` ```bash reth node --http --http.api All ``` Similarly, you can pass the `none` option (also case-insensitive) to start the HTTP server without exposing any JSON-RPC namespaces on that transport: ```bash reth node --http --http.api none ``` The same options (`all` and `none`) are supported for the WebSocket transport via `--ws.api`. You can also restrict who can access the HTTP server by specifying a domain for Cross-Origin requests. This is important, since any application local to your node will be able to access the RPC server: ```bash reth node --http --http.corsdomain https://mycoolapp.rs ``` Alternatively, if you want to allow any domain, you can pass `*`: ```bash reth node --http --http.corsdomain "*" ``` ### WebSockets WebSockets is a bidirectional transport protocol. Most modern browsers support WebSockets. A WebSocket connection is maintained until it is explicitly terminated by either the client or the node. Because WebSockets are bidirectional, nodes can push events to clients, which enables clients to subscribe to specific events, such as new transactions in the transaction pool, and new logs for smart contracts. The configuration of the WebSocket server follows the same pattern as the HTTP server: * Enable it using `--ws` * Configure the server address by passing `--ws.addr` and `--ws.port` (default `8546`) * Configure cross-origin requests using `--ws.origins` * Enable APIs using `--ws.api` ### IPC IPC is a simpler transport protocol for use in local environments where the node and the client exist on the same machine. The IPC transport is enabled by default and has access to all namespaces, unless explicitly disabled with `--ipcdisable`. Reth creates a UNIX socket on Linux and macOS at `/tmp/reth.ipc`. On Windows, IPC is provided using named pipes at `\\.\pipe\reth.ipc`. You can configure the IPC path using `--ipcpath`. ## Interacting with the RPC One can easily interact with these APIs just like they would with any Ethereum client. You can use `curl`, a programming language with a low-level library, or a tool like Foundry to interact with the chain at the exposed HTTP or WS port. As a reminder, you need to run the command below to enable all of these APIs using an HTTP transport: ```bash reth node --http --http.api "admin,debug,eth,net,trace,txpool,web3,rpc,reth,ots,flashbots,miner,mev,testing" ``` This allows you to then call: ```bash cast block-number cast rpc admin_nodeInfo cast rpc debug_traceTransaction cast rpc trace_replayBlockTransactions ``` # `eth` Namespace Documentation for the API methods in the `eth` namespace can be found on [ethereum.org](https://ethereum.org/en/developers/docs/apis/json-rpc/). # `web3` Namespace The `web3` API provides utility functions for the web3 client. ## `web3_clientVersion` Get the web3 client version. | Client | Method invocation | | ------ | ---------------------------------- | | RPC | `{"method": "web3_clientVersion"}` | ### Example ```js // > {"jsonrpc":"2.0","id":1,"method":"web3_clientVersion","params":[]} {"jsonrpc":"2.0","id":1,"result":"reth/v0.0.1/x86_64-unknown-linux-gnu"} ``` ## `web3_sha3` Get the Keccak-256 hash of the given data. | Client | Method invocation | | ------ | -------------------------------------------- | | RPC | `{"method": "web3_sha3", "params": [bytes]}` | ### Example ```text // > echo -n "rust is awesome" | xxd -p 7275737420697320617765736f6d65 ``` ```js // > {"jsonrpc":"2.0","id":1,"method":"web3_sha3","params":["0x7275737420697320617765736f6d65"]} {"jsonrpc":"2.0","id":1,"result":"0xe421b3428564a5c509ac118bad93a3b84485ec3f927e214b0c4c23076d4bc4e0"} ``` # `net` Namespace The `net` API provides information about the networking component of the node. ## `net_listening` Returns a `bool` indicating whether or not the node is listening for network connections. Currently, Reth always returns `true`. | Client | Method invocation | | ------ | ------------------------------------------- | | RPC | `{"method": "net_listening", "params": []}` | ### Example ```js // > {"jsonrpc":"2.0","id":1,"method":"net_listening","params":[]} {"jsonrpc":"2.0","id":1,"result":true} ``` ## `net_peerCount` Returns the number of peers connected to the node as a hex-encoded quantity. Only established connections are counted. | Client | Method invocation | | ------ | ------------------------------------------- | | RPC | `{"method": "net_peerCount", "params": []}` | ### Example ```js // > {"jsonrpc":"2.0","id":1,"method":"net_peerCount","params":[]} {"jsonrpc":"2.0","id":1,"result":"0xa"} ``` ## `net_version` Returns the network ID (e.g. "1" for mainnet) as a string corresponding to the chain ID. | Client | Method invocation | | ------ | ----------------------------------------- | | RPC | `{"method": "net_version", "params": []}` | ### Example ```js // > {"jsonrpc":"2.0","id":1,"method":"net_version","params":[]} {"jsonrpc":"2.0","id":1,"result":"1"} ``` # `txpool` Namespace The `txpool` API allows you to inspect the transaction pool. ## `txpool_content` Returns the details of all transactions currently pending for inclusion in the next block(s), as well as the ones that are being scheduled for future execution only. See [here](https://geth.ethereum.org/docs/rpc/ns-txpool#txpool-content) for more details | Client | Method invocation | | ------ | -------------------------------------------- | | RPC | `{"method": "txpool_content", "params": []}` | ## `txpool_contentFrom` Retrieves the transactions contained within the txpool, returning pending as well as queued transactions of this address, grouped by nonce. See [here](https://geth.ethereum.org/docs/rpc/ns-txpool#txpool-contentfrom) for more details | Client | Method invocation | | ------ | ------------------------------------------------------- | | RPC | `{"method": "txpool_contentFrom", "params": [address]}` | ## `txpool_inspect` Returns a summary of all the transactions currently pending for inclusion in the next block(s), as well as the ones that are being scheduled for future execution only. See [here](https://geth.ethereum.org/docs/rpc/ns-txpool#txpool-inspect) for more details | Client | Method invocation | | ------ | -------------------------------------------- | | RPC | `{"method": "txpool_inspect", "params": []}` | ## `txpool_status` Returns the number of transactions currently pending for inclusion in the next block(s), as well as the ones that are being scheduled for future execution only. See [here](https://geth.ethereum.org/docs/rpc/ns-txpool#txpool-status) for more details | Client | Method invocation | | ------ | ------------------------------------------- | | RPC | `{"method": "txpool_status", "params": []}` | # `debug` Namespace The `debug` API provides several methods to inspect the Ethereum state, including Geth-style traces. ## `debug_getRawHeader` Returns an RLP-encoded header. | Client | Method invocation | | ------ | ----------------------------------------------------- | | RPC | `{"method": "debug_getRawHeader", "params": [block]}` | ## `debug_getRawBlock` Retrieves and returns the RLP encoded block by number, hash or tag. | Client | Method invocation | | ------ | ---------------------------------------------------- | | RPC | `{"method": "debug_getRawBlock", "params": [block]}` | ## `debug_getRawTransaction` Returns an EIP-2718 binary-encoded transaction. | Client | Method invocation | | ------ | ------------------------------------------------------------ | | RPC | `{"method": "debug_getRawTransaction", "params": [tx_hash]}` | ## `debug_getRawTransactions` Returns an array of EIP-2718 binary-encoded transactions for the given block. | Client | Method invocation | | ------ | -------------------------------------------------------------- | | RPC | `{"method": "debug_getRawTransactions", "params": [block]}` | ## `debug_getRawReceipts` Returns an array of EIP-2718 binary-encoded receipts. | Client | Method invocation | | ------ | ------------------------------------------------------- | | RPC | `{"method": "debug_getRawReceipts", "params": [block]}` | ## `debug_getBadBlocks` Returns an array of recent bad blocks that the client has seen on the network. | Client | Method invocation | | ------ | ------------------------------------------------ | | RPC | `{"method": "debug_getBadBlocks", "params": []}` | ## `debug_subscribe`, `debug_unsubscribe` Subscribes to structured logs created during EVM execution between two blocks. The start block is excluded and the end block is included. Pass `"traceChain"` as the subscription type and optionally provide tracing options. The subscription returns an ID and emits `debug_subscription` notifications containing the block number and its transaction traces. Empty intermediate blocks are omitted, but the end block is always emitted. Pass the subscription ID to `debug_unsubscribe` to stop receiving notifications. | Client | Method invocation | | ------ | ------------------------------------------------------------------------------------------------- | | RPC | `{"method": "debug_subscribe", "params": ["traceChain", start_block, end_block, opts]}` | | RPC | `{"method": "debug_unsubscribe", "params": [subscription_id]}` | :::note Subscriptions are only available over WebSocket and IPC transports, as HTTP does not support server-initiated messages. ::: ## `debug_traceBlock` The `debug_traceBlock` method will return a full stack trace of all invoked opcodes of all transactions that were included in this block. This expects an RLP-encoded block. > **Note** > > The parent of this block must be present, or it will fail. | Client | Method invocation | | ------ | ------------------------------------------------------- | | RPC | `{"method": "debug_traceBlock", "params": [rlp, opts]}` | ## `debug_traceBlockByHash` Similar to [`debug_traceBlock`](#debug_traceblock), `debug_traceBlockByHash` accepts a block hash and will replay the block that is already present in the database. | Client | Method invocation | | ------ | -------------------------------------------------------------------- | | RPC | `{"method": "debug_traceBlockByHash", "params": [block_hash, opts]}` | ## `debug_traceBlockByNumber` Similar to [`debug_traceBlockByHash`](#debug_traceblockbyhash), `debug_traceBlockByNumber` accepts a block number and will replay the block that is already present in the database. | Client | Method invocation | | ------ | ------------------------------------------------------------------------ | | RPC | `{"method": "debug_traceBlockByNumber", "params": [block_number, opts]}` | ## `debug_traceTransaction` The `debug_traceTransaction` debugging method will attempt to run the transaction in the exact same manner as it was executed on the network. It will replay any transaction that may have been executed prior to this one before it will finally attempt to execute the transaction that corresponds to the given hash. | Client | Method invocation | | ------ | ----------------------------------------------------------------- | | RPC | `{"method": "debug_traceTransaction", "params": [tx_hash, opts]}` | ## `debug_traceCall` The `debug_traceCall` method lets you run an `eth_call` within the context of the given block execution using the final state of the parent block as the base. The first argument (just as in `eth_call`) is a transaction request. The block can optionally be specified either by hash or by number as the second argument. | Client | Method invocation | | ------ | --------------------------------------------------------------------- | | RPC | `{"method": "debug_traceCall", "params": [call, block_number, opts]}` | ## `debug_traceCallMany` The `debug_traceCallMany` method lets you run multiple `eth_call`s within the context of the given block execution using the final state of the parent block as the base, followed by n transactions. The first argument is a list of bundles. Each bundle can overwrite the block headers, which will affect all transactions in that bundle. The trace can be configured similar to `debug_traceTransaction`. This method returns nested lists of traces, where the outer list length is the number of bundles and the inner list length is the number of transactions in each bundle. | Client | Method invocation | | ------ | ---------------------------------------------------------------------------------- | | RPC | `{"method": "debug_traceCallMany", "params": [bundles, state_context, opts]}` | ## `debug_executionWitness` Allows for re-execution of a block with the purpose of generating an execution witness. The witness comprises a map of all hashed trie nodes to their preimages that were required during the execution of the block, including during state root recomputation. The `block` parameter accepts a block number, tag, hash, or EIP-1898 block object. An optional second parameter selects the witness generation mode. | Client | Method invocation | | ------ | ------------------------------------------------------------ | | RPC | `{"method": "debug_executionWitness", "params": [block]}` | ## `debug_executionWitnessByBlockHash` Similar to [`debug_executionWitness`](#debug_executionwitness), but accepts a block hash and retains its dedicated method for compatibility. | Client | Method invocation | | ------ | ---------------------------------------------------------------------- | | RPC | `{"method": "debug_executionWitnessByBlockHash", "params": [hash]}` | ## `debug_intermediateRoots` Executes a block and returns a list of intermediate state roots: the state root after each transaction within the block. Accepts both canonical and non-canonical (bad or side) blocks by hash. | Client | Method invocation | | ------ | ------------------------------------------------------------------- | | RPC | `{"method": "debug_intermediateRoots", "params": [block_hash]}` | ## `debug_accountAt` Returns account information, including the storage root, after replaying a block through the transaction at the given index. | Client | Method invocation | | ------ | ------------------------------------------------------------------- | | RPC | `{"method": "debug_accountAt", "params": [block_id, tx_index, address]}` | ## `debug_accountInfoAt` Returns account information, including balance, nonce, and code, after replaying a block through the transaction at the given index. Unlike `debug_accountAt`, the response does not include the storage root. | Client | Method invocation | | ------ | ----------------------------------------------------------------------- | | RPC | `{"method": "debug_accountInfoAt", "params": [block_id, tx_index, address]}` | ## `debug_dbGet` Retrieves a raw value from the database. | Client | Method invocation | | ------ | -------------------------------------------------- | | RPC | `{"method": "debug_dbGet", "params": [key]}` | ## `debug_storageRangeAt` Returns the storage at the given block height and transaction index. The result can be paged by providing a `maxResult` to cap the number of storage slots returned as well as specifying the offset via `keyStart`. | Client | Method invocation | | ------ | ------------------------------------------------------------------------------------------------- | | RPC | `{"method": "debug_storageRangeAt", "params": [block_hash, tx_index, address, key_start, limit]}` | ## `debug_chainConfig` Returns the chain's genesis configuration as a `ChainConfig` object. Useful for confirming the active network parameters (chain ID, hard fork block numbers and timestamps, consensus settings) without parsing the genesis file manually. | Client | Method invocation | | ------ | ---------------------------------------------------- | | RPC | `{"method": "debug_chainConfig", "params": []}` | ## `debug_codeByHash` Returns the contract bytecode associated with the given code hash at the specified block. If no block identifier is provided it defaults to `latest`. Returns `null` when no bytecode is found for the hash. | Client | Method invocation | | ------ | ------------------------------------------------------------------------ | | RPC | `{"method": "debug_codeByHash", "params": [code_hash, block]}` | # `trace` Namespace The `trace` API provides several methods to inspect the Ethereum state, including Parity-style traces. A similar module exists (with other debug functions) with Geth-style traces ([`debug`](https://github.com/paradigmxyz/reth/blob/main/docs/vocs/docs/pages/jsonrpc/debug.mdx)). The `trace` API gives deeper insight into transaction processing. There are two types of methods in this API: * **Ad-hoc tracing APIs** for performing diagnostics on calls or transactions (historical or hypothetical). * **Transaction-trace filtering APIs** for getting full externality traces on any transaction executed by reth. ## Trace Format Specification The trace API returns different types of trace data depending on the requested trace types. Understanding these formats is crucial for interpreting the results. ### TraceResults The `TraceResults` object is returned by ad-hoc tracing methods (`trace_call`, `trace_callMany`, `trace_rawTransaction`, `trace_replayTransaction`, `trace_replayBlockTransactions`). It contains the following fields: | Field | Type | Description | |-------|------|-------------| | `output` | `string` | The return value of the traced call, encoded as hex | | `stateDiff` | `object \| null` | State changes caused by the transaction (only if `stateDiff` trace type requested) | | `trace` | `array \| null` | Array of transaction traces (only if `trace` trace type requested) | | `vmTrace` | `object \| null` | Virtual machine execution trace (only if `vmTrace` trace type requested) | ### LocalizedTransactionTrace Individual transaction traces in `trace_block`, `trace_filter`, `trace_get`, and `trace_transaction` methods return `LocalizedTransactionTrace` objects: | Field | Type | Description | |-------|------|-------------| | `action` | `object` | The action performed by this trace | | `result` | `object \| null` | The result of the trace execution | | `error` | `string \| null` | Error message if the trace failed | | `blockHash` | `string \| null` | Hash of the block containing this trace | | `blockNumber` | `number \| null` | Number of the block containing this trace | | `transactionHash` | `string \| null` | Hash of the transaction containing this trace | | `transactionPosition` | `number \| null` | Position of the transaction in the block | | `subtraces` | `number` | Number of child traces | | `traceAddress` | `array` | Position of this trace in the call tree | | `type` | `string` | Type of action: `"call"`, `"create"`, `"suicide"`, or `"reward"` | ### Action Types #### Call Action (`type: "call"`) | Field | Type | Description | |-------|------|-------------| | `callType` | `string` | Type of call: `"call"`, `"callcode"`, `"delegatecall"`, or `"staticcall"` | | `from` | `string` | Address of the caller | | `to` | `string` | Address of the callee | | `gas` | `string` | Gas provided for the call | | `input` | `string` | Input data for the call | | `value` | `string` | Value transferred in the call | #### Create Action (`type: "create"`) | Field | Type | Description | |-------|------|-------------| | `from` | `string` | Address of the creator | | `gas` | `string` | Gas provided for contract creation | | `init` | `string` | Contract initialization code | | `value` | `string` | Value sent to the new contract | #### Suicide Action (`type: "suicide"`) | Field | Type | Description | |-------|------|-------------| | `address` | `string` | Address of the contract being destroyed | | `refundAddress` | `string` | Address receiving the remaining balance | | `balance` | `string` | Balance transferred to refund address | #### Reward Action (`type: "reward"`) | Field | Type | Description | |-------|------|-------------| | `author` | `string` | Address receiving the reward | | `value` | `string` | Amount of the reward | | `rewardType` | `string` | Type of reward: `"block"` or `"uncle"` | ### Result Format When a trace executes successfully, the `result` field contains: | Field | Type | Description | |-------|------|-------------| | `gasUsed` | `string` | Amount of gas consumed by this trace | | `output` | `string` | Return data from the trace execution | | `address` | `string` | Created contract address (for create actions only) | | `code` | `string` | Deployed contract code (for create actions only) | ### State Diff Format When `stateDiff` trace type is requested, the `stateDiff` field contains an object mapping addresses to their state changes: ```json { "0x123...": { "balance": { "*": { "from": "0x0", "to": "0x1000" } }, "nonce": { "*": { "from": "0x0", "to": "0x1" } }, "code": { "*": { "from": "0x", "to": "0x608060405234801561001057600080fd5b50..." } }, "storage": { "0x290decd9548b62a8d60345a988386fc84ba6bc95484008f6362f93160ef3e563": { "*": { "from": "0x0", "to": "0x1" } } } } } ``` ### VM Trace Format When `vmTrace` trace type is requested, the `vmTrace` field contains detailed virtual machine execution information including opcodes, stack, memory, and storage changes at each step. The exact format depends on the specific VM tracer implementation. ## Ad-hoc tracing APIs Ad-hoc tracing APIs allow you to perform diagnostics on calls or transactions (historical or hypothetical), including: * Transaction traces (`trace`) * VM traces (`vmTrace`) * State difference traces (`stateDiff`) The ad-hoc tracing APIs are: * [`trace_call`](#trace_call) * [`trace_callMany`](#trace_callmany) * [`trace_rawTransaction`](#trace_rawtransaction) * [`trace_replayBlockTransactions`](#trace_replayblocktransactions) * [`trace_replayTransaction`](#trace_replaytransaction) ## Transaction-trace filtering APIs Transaction trace filtering APIs are similar to log filtering APIs in the `eth` namespace, except these allow you to search and filter based only upon address information. Information returned includes the execution of all contract creations, destructions, and calls, together with their input data, output data, gas usage, transfer amounts and success statuses. The transaction trace filtering APIs are: * [`trace_block`](#trace_block) * [`trace_filter`](#trace_filter) * [`trace_get`](#trace_get) * [`trace_transaction`](#trace_transaction) ## `trace_call` Executes the given call and returns a number of possible traces for it. The first parameter is a transaction object where the `from` field is optional and the `nonce` field is omitted. The second parameter is an array of one or more trace types (`vmTrace`, `trace`, `stateDiff`). The third and optional parameter is a block number, block hash, or a block tag (`latest`, `finalized`, `safe`, `earliest`, `pending`). The fourth and optional parameter is a `stateOverrides` object that temporarily overrides account state used for the trace (balances, nonces, code, storage). The fifth and optional parameter is a `blockOverrides` object that temporarily overrides block fields used for the trace (for example `timestamp`, `baseFee`, `number`). | Client | Method invocation | | ------ | ------------------------------------------------------------------------------------ | | RPC | `{"method": "trace_call", "params": [tx, trace[], block, stateOverrides, blockOverrides]}` | ### Example ```js // > {"jsonrpc":"2.0","id":1,"method":"trace_call","params":[{},["trace"]]} { "id": 1, "jsonrpc": "2.0", "result": { "output": "0x", "stateDiff": null, "trace": [{ "action": { "callType": "call", "from": "0x0000000000000000000000000000000000000000", "to": "0x0000000000000000000000000000000000000000", "gas": "0x76c0", "input": "0x", "value": "0x0" }, "result": { "gasUsed": "0x0", "output": "0x" }, "subtraces": 0, "traceAddress": [], "type": "call" }], "vmTrace": null } } ``` ## `trace_callMany` Performs multiple call traces on top of the same block, that is, transaction `n` will be executed on top of a pending block with all `n - 1` transaction applied (and traced) first. The first parameter is a list of call traces, where each call trace is of the form `[tx, type[]]` (see [`trace_call`](#trace_call)). The second and optional parameter is a block number, block hash, or a block tag (`latest`, `finalized`, `safe`, `earliest`, `pending`). | Client | Method invocation | | ------ | ---------------------------------------------------------- | | RPC | `{"method": "trace_callMany", "params": [[[tx, type[]], ...], block]}` | ### Example ```js // > {"jsonrpc":"2.0","id":1,"method":"trace_callMany","params":[[[{"from":"0x407d73d8a49eeb85d32cf465507dd71d507100c1","to":"0xa94f5374fce5edbc8e2a8697c15331677e6ebf0b","value":"0x186a0"},["trace"]],[{"from":"0x407d73d8a49eeb85d32cf465507dd71d507100c1","to":"0xa94f5374fce5edbc8e2a8697c15331677e6ebf0b","value":"0x186a0"},["trace"]]],"latest"]} { "id": 1, "jsonrpc": "2.0", "result": [ { "output": "0x", "stateDiff": null, "trace": [{ "action": { "callType": "call", "from": "0x407d73d8a49eeb85d32cf465507dd71d507100c1", "gas": "0x1dcd12f8", "input": "0x", "to": "0xa94f5374fce5edbc8e2a8697c15331677e6ebf0b", "value": "0x186a0" }, "result": { "gasUsed": "0x0", "output": "0x" }, "subtraces": 0, "traceAddress": [], "type": "call" }], "vmTrace": null }, { "output": "0x", "stateDiff": null, "trace": [{ "action": { "callType": "call", "from": "0x407d73d8a49eeb85d32cf465507dd71d507100c1", "gas": "0x1dcd12f8", "input": "0x", "to": "0xa94f5374fce5edbc8e2a8697c15331677e6ebf0b", "value": "0x186a0" }, "result": { "gasUsed": "0x0", "output": "0x" }, "subtraces": 0, "traceAddress": [], "type": "call" }], "vmTrace": null } ] } ``` ## `trace_rawTransaction` Traces a call to `eth_sendRawTransaction` without making the call, returning the traces. | Client | Method invocation | | ------ | -------------------------------------------------------------------------------- | | RPC | `{"method": "trace_rawTransaction", "params": [raw_tx, type[], block]}` | ### Example The example below can be reproduced with `reth node --dev --http --http.api eth,trace`. The signed EIP-1559 transaction is from the first prefunded dev account, and the explicit `0x0` block parameter pins the trace state to genesis. ```js // > {"jsonrpc":"2.0","id":1,"method":"trace_rawTransaction","params":["0x02f86e82053980843b9aca008502540be400830186a094000000000000000000000000000000000000dead8080c080a0db09ddf33a2ded1d2f9255abf3d1e7cab03df637fa204c7f777aaa518a375237a01e7948bacb7bb5e12292f7f4c44464deb001ab5f85d486d7738cd6b634193ec8",["trace"],"0x0"]} { "jsonrpc": "2.0", "id": 1, "result": { "output": "0x", "stateDiff": null, "trace": [{ "type": "call", "action": { "from": "0xf39fd6e51aad88f6f4ce6ab8827279cfffb92266", "callType": "call", "gas": "0x13498", "input": "0x", "to": "0x000000000000000000000000000000000000dead", "value": "0x0" }, "result": { "gasUsed": "0x0", "output": "0x" }, "subtraces": 0, "traceAddress": [] }], "vmTrace": null } } ``` ## `trace_replayBlockTransactions` Replays all transactions in a block returning the requested traces for each transaction. | Client | Method invocation | | ------ | ------------------------------------------------------------------------ | | RPC | `{"method": "trace_replayBlockTransactions", "params": [block, type[]]}` | ### Example ```js // > {"jsonrpc":"2.0","id":1,"method":"trace_replayBlockTransactions","params":["0x2ed119",["trace"]]} { "id": 1, "jsonrpc": "2.0", "result": [ { "output": "0x", "stateDiff": null, "trace": [{ "action": { "callType": "call", "from": "0xa94f5374fce5edbc8e2a8697c15331677e6ebf0b", "to": "0x6295ee1b4f6dd65047762f924ecd367c17eabf8f", "gas": "0x186a0", "input": "0x", "value": "0x0" }, "result": { "gasUsed": "0x0", "output": "0x" }, "subtraces": 0, "traceAddress": [], "type": "call" }], "transactionHash": "0x4e70b5d8d5dc43e0e61e4a8f1e6e4e6e4e6e4e6e4e6e4e6e4e6e4e6e4e6e4e6e4", "vmTrace": null } ] } ``` ## `trace_replayTransaction` Replays a transaction, returning the traces. | Client | Method invocation | | ------ | -------------------------------------------------------------------- | | RPC | `{"method": "trace_replayTransaction", "params": [tx_hash, type[]]}` | ### Example ```js // > {"jsonrpc":"2.0","id":1,"method":"trace_replayTransaction","params":["0x02d4a872e096445e80d05276ee756cefef7f3b376bcec14246469c0cd97dad8f",["trace"]]} { "id": 1, "jsonrpc": "2.0", "result": { "output": "0x", "stateDiff": null, "trace": [{ "action": { "callType": "call", "from": "0x1c39ba39e4735cb65978d4db400ddd70a72dc750", "to": "0x2bd2326c993dfaef84f696526064ff22eba5b362", "gas": "0x13e99", "input": "0x16c72721", "value": "0x0" }, "result": { "gasUsed": "0x183", "output": "0x0000000000000000000000000000000000000000000000000000000000000001" }, "subtraces": 0, "traceAddress": [], "type": "call" }], "vmTrace": null } } ``` ## `trace_block` Returns traces created at given block. | Client | Method invocation | | ------ | ---------------------------------------------- | | RPC | `{"method": "trace_block", "params": [block]}` | ### Example ```js // > {"jsonrpc":"2.0","id":1,"method":"trace_block","params":["0x2ed119"]} { "id": 1, "jsonrpc": "2.0", "result": [ { "action": { "callType": "call", "from": "0xaa7b131dc60b80d3cf5e59b5a21a666aa039c951", "gas": "0x0", "input": "0x", "to": "0xd40aba8166a212d6892125f079c33e6f5ca19814", "value": "0x4768d7effc3fbe" }, "blockHash": "0x7eb25504e4c202cf3d62fd585d3e238f592c780cca82dacb2ed3cb5b38883add", "blockNumber": 3068185, "result": { "gasUsed": "0x0", "output": "0x" }, "subtraces": 0, "traceAddress": [], "transactionHash": "0x07da28d752aba3b9dd7060005e554719c6205c8a3aea358599fc9b245c52f1f6", "transactionPosition": 0, "type": "call" } ] } ``` ## `trace_filter` Returns traces matching given filter. Filters are objects with the following properties: * `fromBlock`: Returns traces from the given block (a number, hash, or a tag like `latest`). * `toBlock`: Returns traces to the given block. * `fromAddress`: Sent from these addresses * `toAddress`: Sent to these addresses * `after`: The offset trace number * `count`: The number of traces to display in a batch All properties are optional. | Client | Method invocation | | ------ | ------------------------------------------------ | | RPC | `{"method": "trace_filter", "params": [filter]}` | ### Example ```js // > {"jsonrpc":"2.0","id":1,"method":"trace_filter","params":[{"fromBlock":"0x2ed0c4","toBlock":"0x2ed128","toAddress":["0x8bbB73BCB5d553B5A556358d27625323Fd781D37"],"after":1000,"count":100}]} { "id": 1, "jsonrpc": "2.0", "result": [ { "action": { "callType": "call", "from": "0x32be343b94f860124dc4fee278fdcbd38c102d88", "gas": "0x4c40d", "input": "0x", "to": "0x8bbb73bcb5d553b5a556358d27625323fd781d37", "value": "0x3f0650ec47fd240000" }, "blockHash": "0x86df301bcdd8248d982dbf039f09faf792684e1aeee99d5b58b77d620008b80f", "blockNumber": 3068183, "result": { "gasUsed": "0x0", "output": "0x" }, "subtraces": 0, "traceAddress": [], "transactionHash": "0x3321a7708b1083130bd78da0d62ead9f6683033231617c9d268e2c7e3fa6c104", "transactionPosition": 3, "type": "call" } ] } ``` ## `trace_get` Returns trace at given position. | Client | Method invocation | | ------ | -------------------------------------------------------- | | RPC | `{"method": "trace_get", "params": [tx_hash, indices[]]}` | ### Example ```js // > {"jsonrpc":"2.0","id":1,"method":"trace_get","params":["0x17104ac9d3312d8c136b7f44d4b8b47852618065ebfa534bd2d3b5ef218ca1f3",["0x0"]]} { "id": 1, "jsonrpc": "2.0", "result": { "action": { "callType": "call", "from": "0x1c39ba39e4735cb65978d4db400ddd70a72dc750", "gas": "0x13e99", "input": "0x16c72721", "to": "0x2bd2326c993dfaef84f696526064ff22eba5b362", "value": "0x0" }, "blockHash": "0x7eb25504e4c202cf3d62fd585d3e238f592c780cca82dacb2ed3cb5b38883add", "blockNumber": 3068185, "result": { "gasUsed": "0x183", "output": "0x0000000000000000000000000000000000000000000000000000000000000001" }, "subtraces": 0, "traceAddress": [ 0 ], "transactionHash": "0x17104ac9d3312d8c136b7f44d4b8b47852618065ebfa534bd2d3b5ef218ca1f3", "transactionPosition": 2, "type": "call" } } ``` ## `trace_transaction` Returns all traces of given transaction | Client | Method invocation | | ------ | ------------------------------------------------------ | | RPC | `{"method": "trace_transaction", "params": [tx_hash]}` | ### Example ```js // > {"jsonrpc":"2.0","id":1,"method":"trace_transaction","params":["0x17104ac9d3312d8c136b7f44d4b8b47852618065ebfa534bd2d3b5ef218ca1f3"]} { "id": 1, "jsonrpc": "2.0", "result": [ { "action": { "callType": "call", "from": "0x1c39ba39e4735cb65978d4db400ddd70a72dc750", "gas": "0x13e99", "input": "0x16c72721", "to": "0x2bd2326c993dfaef84f696526064ff22eba5b362", "value": "0x0" }, "blockHash": "0x7eb25504e4c202cf3d62fd585d3e238f592c780cca82dacb2ed3cb5b38883add", "blockNumber": 3068185, "result": { "gasUsed": "0x183", "output": "0x0000000000000000000000000000000000000000000000000000000000000001" }, "subtraces": 0, "traceAddress": [ 0 ], "transactionHash": "0x17104ac9d3312d8c136b7f44d4b8b47852618065ebfa534bd2d3b5ef218ca1f3", "transactionPosition": 2, "type": "call" } ] } ``` ## `trace_transactionOpcodeGas` Returns opcode gas usage aggregated per opcode for a single transaction in no particular order. | Client | Method invocation | | ------ | --------------------------------------------------------------------- | | RPC | `{"method": "trace_transactionOpcodeGas", "params": [tx_hash]}` | ### Example ```js // > {"jsonrpc":"2.0","id":1,"method":"trace_transactionOpcodeGas","params":["0x17104ac9d3312d8c136b7f44d4b8b47852618065ebfa534bd2d3b5ef218ca1f3"]} { "id": 1, "jsonrpc": "2.0", "result": { "transactionHash": "0x17104ac9d3312d8c136b7f44d4b8b47852618065ebfa534bd2d3b5ef218ca1f3", "opcodeGas": [ { "opcode": "PUSH1", "count": 10, "gasUsed": 30 }, { "opcode": "CALL", "count": 1, "gasUsed": 700 } ] } } ``` ## `trace_blockOpcodeGas` Returns opcode gas usage aggregated per opcode for every transaction in a block. | Client | Method invocation | | ------ | ---------------------------------------------------------------- | | RPC | `{"method": "trace_blockOpcodeGas", "params": [block]}` | ### Example ```js // > {"jsonrpc":"2.0","id":1,"method":"trace_blockOpcodeGas","params":["latest"]} { "id": 1, "jsonrpc": "2.0", "result": { "blockHash": "0x7eb25504e4c202cf3d62fd585d3e238f592c780cca82dacb2ed3cb5b38883add", "blockNumber": 3068185, "transactions": [ { "transactionHash": "0x17104ac9d3312d8c136b7f44d4b8b47852618065ebfa534bd2d3b5ef218ca1f3", "opcodeGas": [ { "opcode": "PUSH1", "count": 10, "gasUsed": 30 } ] } ] } } ``` # `admin` Namespace The `admin` API allows you to configure your node, including adding and removing peers. :::note As this namespace can configure your node at runtime, it is generally **not advised** to expose it publicly. ::: ## `admin_addPeer` Add the given peer to the current peer set of the node. The method accepts a single argument, the [`enode`][enode] URL of the remote peer to connect to, and returns a `bool` indicating whether the peer was accepted or not. | Client | Method invocation | | ------ | ---------------------------------------------- | | RPC | `{"method": "admin_addPeer", "params": [url]}` | ### Example ```js // > {"jsonrpc":"2.0","id":1,"method":"admin_addPeer","params":["enode://a979fb575495b8d6db44f750317d0f4622bf4c2aa3365d6af7c284339968eef29b69ad0dce72a4d8db5ebb4968de0e3bec910127f134779fbcb0cb6d3331163c@52.16.188.185:30303"]} {"jsonrpc":"2.0","id":1,"result":true} ``` ## `admin_removePeer` Disconnects from a peer if the connection exists. Returns a `bool` indicating whether the peer was successfully removed or not. | Client | Method invocation | | ------ | ------------------------------------------------- | | RPC | `{"method": "admin_removePeer", "params": [url]}` | ### Example ```js // > {"jsonrpc":"2.0","id":1,"method":"admin_removePeer","params":["enode://a979fb575495b8d6db44f750317d0f4622bf4c2aa3365d6af7c284339968eef29b69ad0dce72a4d8db5ebb4968de0e3bec910127f134779fbcb0cb6d3331163c@52.16.188.185:30303"]} {"jsonrpc":"2.0","id":1,"result":true} ``` ## `admin_addTrustedPeer` Adds the given peer to a list of trusted peers, which allows the peer to always connect, even if there is no room for it otherwise. It returns a `bool` indicating whether the peer was added to the list or not. | Client | Method invocation | | ------ | ----------------------------------------------------- | | RPC | `{"method": "admin_addTrustedPeer", "params": [url]}` | ### Example ```js // > {"jsonrpc":"2.0","id":1,"method":"admin_addTrustedPeer","params":["enode://a979fb575495b8d6db44f750317d0f4622bf4c2aa3365d6af7c284339968eef29b69ad0dce72a4d8db5ebb4968de0e3bec910127f134779fbcb0cb6d3331163c@52.16.188.185:30303"]} {"jsonrpc":"2.0","id":1,"result":true} ``` ## `admin_removeTrustedPeer` Removes a remote node from the trusted peer set, but it does not disconnect it automatically. Returns true if the peer was successfully removed. | Client | Method invocation | | ------ | -------------------------------------------------------- | | RPC | `{"method": "admin_removeTrustedPeer", "params": [url]}` | ### Example ```js // > {"jsonrpc":"2.0","id":1,"method":"admin_removeTrustedPeer","params":["enode://a979fb575495b8d6db44f750317d0f4622bf4c2aa3365d6af7c284339968eef29b69ad0dce72a4d8db5ebb4968de0e3bec910127f134779fbcb0cb6d3331163c@52.16.188.185:30303"]} {"jsonrpc":"2.0","id":1,"result":true} ``` ## `admin_banPeer` Bans a remote peer from future connections. For non-trusted peers, this also removes the peer from the peer set and disconnects any active session. Trusted peers must be removed from the trusted set before they can be banned. Returns `true` once the request has been accepted. | Client | Method invocation | | ------ | ------------------------------------------------ | | RPC | `{"method": "admin_banPeer", "params": [url]}` | ### Example ```js // > {"jsonrpc":"2.0","id":1,"method":"admin_banPeer","params":["enode://a979fb575495b8d6db44f750317d0f4622bf4c2aa3365d6af7c284339968eef29b69ad0dce72a4d8db5ebb4968de0e3bec910127f134779fbcb0cb6d3331163c@52.16.188.185:30303"]} {"jsonrpc":"2.0","id":1,"result":true} ``` ## `admin_unbanPeer` Removes a remote peer from the ban list and resets its reputation so it can reconnect. Returns `true` once the request has been accepted. | Client | Method invocation | | ------ | -------------------------------------------------- | | RPC | `{"method": "admin_unbanPeer", "params": [url]}` | ### Example ```js // > {"jsonrpc":"2.0","id":1,"method":"admin_unbanPeer","params":["enode://a979fb575495b8d6db44f750317d0f4622bf4c2aa3365d6af7c284339968eef29b69ad0dce72a4d8db5ebb4968de0e3bec910127f134779fbcb0cb6d3331163c@52.16.188.185:30303"]} {"jsonrpc":"2.0","id":1,"result":true} ``` ## `admin_nodeInfo` Returns all information known about the running node. These include general information about the node itself, as well as what protocols it participates in, its IP and ports. The `id` field is the keccak256 hash of the node's `enode` public key, encoded as 64 lowercase hex characters without a `0x` prefix. | Client | Method invocation | | ------ | ------------------------------ | | RPC | `{"method": "admin_nodeInfo"}` | ### Example ```js // > {"jsonrpc":"2.0","id":1,"method":"admin_nodeInfo","params":[]} { "jsonrpc": "2.0", "id": 1, "result": { "enode": "enode://44826a5d6a55f88a18298bca4773fca5749cdc3a5c9f308aa7d810e9b31123f3e7c5fba0b1d70aac5308426f47df2a128a6747040a3815cc7dd7167d03be320d@[::]:30303", "id": "8915d6ec2f53ede650d5b9bea77d7756f177092171648ee1d8cbc550d334fa7a", "ip": "::", "listenAddr": "[::]:30303", "name": "reth/v0.0.1/x86_64-unknown-linux-gnu", "ports": { "discovery": 30303, "listener": 30303 }, "protocols": { "eth": { "difficulty": 17334254859343145000, "genesis": "0xd4e56740f876aef8c010b86a40d5f56745a118d0906a34e69aec8c0db1cb8fa3", "head": "0xb83f73fbe6220c111136aefd27b160bf4a34085c65ba89f24246b3162257c36a", "network": 1 } } } } ``` ## `admin_peers` Returns information about peers currently known to the node. For each peer, `id` is the keccak256 hash of the peer `enode` public key, encoded as 64 lowercase hex characters without a `0x` prefix. | Client | Method invocation | | ------ | ------------------------------ | | RPC | `{"method": "admin_peers", "params": []}` | ### Example ```js // > {"jsonrpc":"2.0","id":1,"method":"admin_peers","params":[]} {"jsonrpc":"2.0","id":1,"result":[ { "id":"8915d6ec2f53ede650d5b9bea77d7756f177092171648ee1d8cbc550d334fa7a", "name":"reth/v0.0.1/x86_64-unknown-linux-gnu", "enode":"enode://44826a5d6a55f88a18298bca4773fca5749cdc3a5c9f308aa7d810e9b31123f3e7c5fba0b1d70aac5308426f47df2a128a6747040a3815cc7dd7167d03be320d@192.168.1.1:30303", "enr":"enr:-IS4QHCYr...", "caps":["eth/67"], "network":{ "remoteAddress":"192.168.1.1:30303", "localAddress":"127.0.0.1:30303", "inbound":false, "trusted":false, "staticNode":false }, "protocols":{ "eth":{"version":67} } } ]} ``` ## `admin_clearTxpool` Clears all transactions from the transaction pool. Returns the number of removed transactions. | Client | Method invocation | | ------ | ----------------------------------------- | | RPC | `{"method": "admin_clearTxpool", "params": []}` | ### Example ```js // > {"jsonrpc":"2.0","id":1,"method":"admin_clearTxpool","params":[]} {"jsonrpc":"2.0","id":1,"result":42} ``` ## `admin_peerEvents`, `admin_peerEvents_unsubscribe` Subscribe to events received by peers over the network. This creates a subscription that emits notifications about peer connections and disconnections. The events provide information about peer activities such as when peers connect, disconnect, or experience errors. Each event contains details about the affected peer, including its enode URL, IP address, and the reason for the event. Like other subscription methods, this returns the ID of the subscription, which is then used in all events subsequently. To unsubscribe from peer events, call `admin_peerEvents_unsubscribe` with the subscription ID. | Client | Method invocation | | ------ | ------------------------------------------------------------ | | RPC | `{"method": "admin_peerEvents", "params": []}` | | RPC | `{"method": "admin_peerEvents_unsubscribe", "params": [id]}` | ### Event Types The subscription emits events with the following structure: ```json { "jsonrpc": "2.0", "method": "admin_subscription", "params": { "subscription": "0xcd0c3e8af590364c09d0fa6a1210faf5", "result": { "type": "add", // or "drop", "error" "peer": { "id": "8915d6ec2f53ede650d5b9bea77d7756f177092171648ee1d8cbc550d334fa7a", "enode": "enode://44826a5d6a55f88a18298bca4773fca5749cdc3a5c9f308aa7d810e9b31123f3e7c5fba0b1d70aac5308426f47df2a128a6747040a3815cc7dd7167d03be320d@192.168.1.1:30303", "addr": "192.168.1.1:30303" }, "error": "reason for disconnect or error" // only present for "drop" and "error" events } } } ``` ### Example ```js // > {"jsonrpc":"2.0","id":1,"method":"admin_peerEvents","params":[]} // responds with subscription ID {"jsonrpc": "2.0", "id": 1, "result": "0xcd0c3e8af590364c09d0fa6a1210faf5"} // Example event when a peer connects {"jsonrpc":"2.0","method":"admin_subscription","params":{"subscription":"0xcd0c3e8af590364c09d0fa6a1210faf5","result":{"type":"add","peer":{"id":"8915d6ec2f53ede650d5b9bea77d7756f177092171648ee1d8cbc550d334fa7a","enode":"enode://44826a5d6a55f88a18298bca4773fca5749cdc3a5c9f308aa7d810e9b31123f3e7c5fba0b1d70aac5308426f47df2a128a6747040a3815cc7dd7167d03be320d@192.168.1.1:30303","addr":"192.168.1.1:30303"}}}} // Unsubscribe // > {"jsonrpc":"2.0","id":2,"method":"admin_peerEvents_unsubscribe","params":["0xcd0c3e8af590364c09d0fa6a1210faf5"]} {"jsonrpc":"2.0","id":2,"result":true} ``` [enode]: https://ethereum.org/en/developers/docs/networking-layer/network-addresses/#enode # `rpc` Namespace The `rpc` API provides methods to get information about the RPC server itself, such as the enabled namespaces. ## `rpc_modules` Lists the enabled RPC namespaces and the versions of each. | Client | Method invocation | | ------ | ----------------------------------------- | | RPC | `{"method": "rpc_modules", "params": []}` | ### Example ```js // > {"jsonrpc":"2.0","id":1,"method":"rpc_modules","params":[]} {"jsonrpc":"2.0","id":1,"result":{"txpool":"1.0","eth":"1.0","rpc":"1.0"}} ``` ## Handling Responses During Syncing When interacting with the RPC server while it is still syncing, some RPC requests may return an empty or null response, while others return the expected results. This behavior can be observed due to the asynchronous nature of the syncing process and the availability of required data. Notably, endpoints that rely on specific stages of the syncing process, such as the execution stage, might not be available until those stages are complete. It's important to understand that during pipeline sync, some endpoints may not be accessible until the necessary data is fully synchronized. For instance, the `eth_getBlockReceipts` endpoint is only expected to return valid data after the execution stage, where receipts are generated, has completed. As a result, certain RPC requests may return empty or null responses until the respective stages are finished. This behavior is intrinsic to how the syncing mechanism works and is not indicative of an issue or bug. If you encounter such responses while the node is still syncing, it's recommended to wait until the sync process is complete to ensure accurate and expected RPC responses. # CLI Reference The Reth node is operated via the CLI by running the `reth node` command. To stop it, press `ctrl-c`. You may need to wait a bit as Reth tears down existing p2p connections or performs other cleanup tasks. However, Reth has more commands: # reth Reth ```bash $ reth --help ``` ```txt Usage: reth [OPTIONS] Commands: node Start the node init Initialize the database from a genesis file init-state Initialize the database from a state dump file import This syncs RLP encoded blocks from a file or files import-era This syncs ERA encoded blocks from a directory export-era Exports block to era1 files in a specified directory dump-genesis Dumps genesis block JSON configuration to stdout db Database debugging utilities download Download public node snapshots snapshot-manifest Generate a snapshot manifest from local archive files stage Manipulate individual stages p2p P2P Debugging utilities config Write config to stdout prune Prune according to the configuration without any limits re-execute Re-execute blocks in parallel to verify historical sync correctness help Print this message or the help of the given subcommand(s) Options: -h, --help Print help (see a summary with '-h') -V, --version Print version Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth node Start the node ```bash $ reth node --help ``` ```txt Usage: reth node [OPTIONS] Options: --config The path to the configuration file to use. --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] --instance Add a new instance of a node. Configures the ports of the node to avoid conflicts with the defaults. This is useful for running multiple nodes on the same machine. Max number of instances is 200. It is chosen in a way so that it's not possible to have port numbers that conflict with each other. Changes to the following port numbers: - `DISCOVERY_PORT`: default + `instance` - 1 - `AUTH_PORT`: default + `instance` * 100 - 100 - `HTTP_RPC_PORT`: default - `instance` + 1 - `WS_RPC_PORT`: default + `instance` * 2 - 2 - `IPC_PATH`: default + `-instance` --with-unused-ports Sets all ports to unused, allowing the OS to choose random unused ports when sockets are bound. Mutually exclusive with `--instance`. -h, --help Print help (see a summary with '-h') Metrics: --metrics Enable Prometheus metrics. The metrics will be served at the given interface and port. --metrics.prometheus.push.url URL for pushing Prometheus metrics to a push gateway. If set, the node will periodically push metrics to the specified push gateway URL. --metrics.prometheus.push.interval Interval in seconds for pushing metrics to push gateway. Default: 5 seconds [default: 5] Datadir: --datadir The path to the data dir for all reth files and subdirectories. Defaults to the OS-specific data directory: - Linux: `$XDG_DATA_HOME/reth/` or `$HOME/.local/share/reth/` - Windows: `{FOLDERID_RoamingAppData}/reth/` - macOS: `$HOME/Library/Application Support/reth/` [default: default] --datadir.static-files The absolute path to store static files in. --datadir.rocksdb The absolute path to store `RocksDB` database in. --datadir.pprof-dumps The absolute path to store pprof dumps in. Networking: -d, --disable-discovery Disable the discovery service --disable-dns-discovery Disable the DNS discovery --disable-discv4-discovery Disable Discv4 discovery --disable-discv5-discovery Disable Discv5 discovery --disable-nat Disable Nat discovery --discovery.addr The UDP address to use for devp2p peer discovery version 4. If unset and `--net-if.experimental` is used, discv4 binds to the resolved interface address. [default: 0.0.0.0] --discovery.port The UDP port to use for devp2p peer discovery version 4 [default: 30303] --discovery.v5.addr The UDP IPv4 address to use for devp2p peer discovery version 5. Overwritten by `RLPx` address, if it's also IPv4 --discovery.v5.addr.ipv6 The UDP IPv6 address to use for devp2p peer discovery version 5. Overwritten by `RLPx` address, if it's also IPv6 --discovery.v5.port The UDP IPv4 port to use for devp2p peer discovery version 5. Not used unless `--addr` is IPv4, or `--discovery.v5.addr` is set [default: 9200] --discovery.v5.port.ipv6 The UDP IPv6 port to use for devp2p peer discovery version 5. Not used unless `--addr` is IPv6, or `--discovery.addr.ipv6` is set. If not provided, discovery V5 defaults to same port as discovery V4 (--discovery.port). [default: 9200] --discovery.v5.lookup-interval The interval in seconds at which to carry out periodic lookup queries, for the whole run of the program [default: 20] --discovery.v5.bootstrap.lookup-interval The interval in seconds at which to carry out boost lookup queries, for a fixed number of times, at bootstrap [default: 5] --discovery.v5.bootstrap.lookup-countdown The number of times to carry out boost lookup queries at bootstrap [default: 200] --trusted-peers Comma separated enode URLs or ENRs of trusted peers for P2P connections. --trusted-peers enode://abcd@192.168.0.1:30303 --trusted-only Connect to or accept from trusted peers only --bootnodes Comma separated enode URLs or ENRs for P2P discovery bootstrap. Will fall back to a network-specific default if not specified. --dns-retries Amount of DNS resolution requests retries to perform when peering [default: 0] --peers-file The path to the known peers file. Connected peers are dumped to this file on nodes shutdown, and read on startup. Cannot be used with `--no-persist-peers`. --identity Custom node identity [default: reth/-/] --p2p-secret-key Secret key to use for this node. This will also deterministically set the peer ID. If not specified, it will be set in the data dir for the chain being used. --p2p-secret-key-hex Hex encoded secret key to use for this node. This will also deterministically set the peer ID. Cannot be used together with `--p2p-secret-key`. --no-persist-peers Do not persist peers. --nat NAT resolution method (any|none|upnp|publicip|extip:\) [default: any] --addr Network listening address [default: 0.0.0.0] --port Network listening port [default: 30303] --max-outbound-peers Maximum number of outbound peers. default: 100 --max-inbound-peers Maximum number of inbound peers. default: 30 --max-peers Maximum number of total peers (inbound + outbound). Splits peers using approximately 2:1 inbound:outbound ratio. Cannot be used together with `--max-outbound-peers` or `--max-inbound-peers`. --max-tx-reqs Max concurrent `GetPooledTransactions` requests. [default: 130] --max-tx-reqs-peer Max concurrent `GetPooledTransactions` requests per peer. [default: 1] --max-seen-tx-history Max number of seen transactions to remember per peer. Default is 320 transaction hashes. [default: 320] --max-pending-imports Max number of transactions to import concurrently. [default: 4096] --pooled-tx-response-soft-limit Experimental, for usage in research. Sets the max accumulated byte size of transactions to pack in one response. Spec'd at 2MiB. [default: 2097152] --pooled-tx-pack-soft-limit Experimental, for usage in research. Sets the max accumulated byte size of transactions to request in one request. Since `RLPx` protocol version 68, the byte size of a transaction is shared as metadata in a transaction announcement (see `RLPx` specs). This allows a node to request a specific size response. By default, nodes request only 128 KiB worth of transactions, but should a peer request more, up to 2 MiB, a node will answer with more than 128 KiB. Default is 128 KiB. [default: 131072] --max-tx-pending-fetch Maximum number of announced transaction hashes to track, including inflight requests. [default: 25600] --tx-channel-memory-limit Memory limit (in bytes) for the channel that buffers transaction events flowing from the network manager to the transactions manager. When the budget is exhausted, new events are dropped (see metric `total_dropped_tx_events_at_full_capacity`). Acts as a backstop against unbounded memory growth under sustained P2P transaction flooding. [default: 1073741824] --net-if.experimental Name of network interface used to communicate with peers. If flag is set, but no value is passed, the default interface for docker `eth0` is tried. If `--discovery.addr` is left at its default, discv4 will also bind to the resolved interface address. --tx-propagation-policy Transaction Propagation Policy The policy determines which peers transactions are gossiped to. [default: All] --tx-ingress-policy Transaction ingress policy Determines which peers' transactions are accepted over P2P. [default: All] --disable-tx-gossip Disable transaction pool gossip Disables gossiping of transactions in the mempool to peers. This can be omitted for personal nodes, though providers should always opt to enable this flag. --tx-propagation-mode Sets the transaction propagation mode by determining how new pending transactions are propagated to other peers in full. Examples: sqrt, all, max:10 [default: sqrt] --required-block-hashes Comma separated list of required block hashes or block number=hash pairs. Peers that don't have these blocks will be filtered out. Format: hash or `block_number=hash` (e.g., 23115201=0x1234...) --network-id Optional network ID to override the chain specification's network ID for P2P connections --eth-max-message-size Maximum allowed ETH message size in bytes. Default is 10 MiB --netrestrict Restrict network communication to the given IP networks (CIDR masks). Comma separated list of CIDR network specifications. Only peers with IP addresses within these ranges will be allowed to connect. Example: --netrestrict "192.168.0.0/16,10.0.0.0/8" --enforce-enr-fork-id Enforce EIP-868 ENR fork ID validation for discovered peers. When enabled, peers discovered without a confirmed fork ID are not added to the peer set until their fork ID is verified via EIP-868 ENR request. This filters out peers from other networks that pollute the discovery table. RPC: --http Enable the HTTP-RPC server --http.addr Http server address to listen on [default: 127.0.0.1] --http.port Http server port to listen on [default: 8545] --http.disable-compression Disable compression for HTTP responses --http.compression Comma-separated list of allowed compression algorithms for HTTP responses. If not specified, all supported algorithms are enabled. Client `Accept-Encoding` quality values select among allowed algorithms; ties prefer zstd > br > gzip > deflate. Omitted quality values default to 1; without an acceptable allowed algorithm, the response is uncompressed. List order is ignored. [possible values: zstd, gzip, deflate, br] --http.decompression Comma-separated list of allowed decompression algorithms for HTTP requests. Request decompression is disabled when not specified. [possible values: zstd, gzip, deflate, br] --http.api Rpc Modules to be configured for the HTTP server [possible values: admin, debug, eth, net, trace, txpool, web3, rpc, reth, ots, flashbots, miner, mev, testing] --http.corsdomain Http Corsdomain to allow request from --ws Enable the WS-RPC server --ws.addr Ws server address to listen on [default: 127.0.0.1] --ws.port Ws server port to listen on [default: 8546] --ws.origins Origins from which to accept `WebSocket` requests --ws.api Rpc Modules to be configured for the WS server [possible values: admin, debug, eth, net, trace, txpool, web3, rpc, reth, ots, flashbots, miner, mev, testing] --ipcdisable Disable the IPC-RPC server --ipcpath Filename for IPC socket/pipe within the datadir [default: .ipc] --ipc.permissions Set the permissions for the IPC socket file, in octal format. If not specified, the permissions will be set by the system's umask. --authrpc.addr Auth server address to listen on [default: 127.0.0.1] --authrpc.port Auth server port to listen on [default: 8551] --authrpc.jwtsecret Path to a JWT secret to use for the authenticated engine-API RPC server. This will enforce JWT authentication for all requests coming from the consensus layer. If no path is provided, a secret will be generated and stored in the datadir under `//jwt.hex`. For mainnet this would be `~/.local/share/reth/mainnet/jwt.hex` by default. --authrpc.jwtsecret-hex Hex encoded JWT secret to use for the authenticated engine-API RPC server. This will enforce JWT authentication for all requests coming from the consensus layer. Cannot be used together with `--authrpc.jwtsecret`. --auth-ipc Enable auth engine API over IPC --auth-ipc.path Filename for auth IPC socket/pipe within the datadir [default: _engine_api.ipc] --disable-auth-server Disable the auth/engine API server. This will prevent the authenticated engine-API server from starting. Use this if you're running a node that doesn't need to serve engine API requests. --rpc.jwtsecret Hex encoded JWT secret to authenticate the regular RPC server(s), see `--http.api` and `--ws.api`. This is __not__ used for the authenticated engine-API RPC server, see `--authrpc.jwtsecret`. --rpc.disable-metrics Disable built-in RPC request metrics --rpc.max-request-size Set the maximum RPC request payload size for both HTTP and WS in megabytes. For compressed HTTP requests, this limit applies to both the compressed and decompressed payloads. [default: 15] --rpc.max-response-size Set the maximum RPC response payload size for both HTTP and WS in megabytes [default: 160] [alias: --rpc.returndata.limit] --rpc.max-subscriptions-per-connection Set the maximum concurrent subscriptions per connection [default: 1024] --rpc.max-connections Maximum number of RPC server connections [default: 500] --rpc.max-tracing-requests Maximum number of concurrent tracing requests. By default this chooses a sensible value based on the number of available cores. Tracing requests are generally CPU bound. Choosing a value that is higher than the available CPU cores can have a negative impact on the performance of the node and affect the node's ability to maintain sync. [default: ] --rpc.max-blocking-io-requests Maximum number of concurrent blocking IO requests. Blocking IO requests include `eth_call`, `eth_estimateGas`, and similar methods that require EVM execution. These are spawned as blocking tasks to avoid blocking the async runtime. [default: 256] --rpc.max-trace-filter-blocks Maximum number of blocks for `trace_filter` requests [default: 100] --rpc.max-blocks-per-filter Maximum number of blocks that could be scanned per filter request. (0 = entire chain) [default: 100000] --rpc.max-logs-per-response Maximum number of logs that can be returned in a single response. (0 = no limit) [default: 20000] --rpc.gascap Maximum gas limit for `eth_call` and call tracing RPC methods [default: 50000000] --rpc.evm-memory-limit Maximum memory the EVM can allocate per RPC request [default: 4294967295] --rpc.txfeecap Maximum eth transaction fee (in ether) that can be sent via the RPC APIs (0 = no cap) [default: 1.0] --rpc.max-simulate-blocks Maximum number of blocks for `eth_simulateV1` call [default: 256] --rpc.compute-state-root-for-eth-simulate Compute state roots for `eth_simulateV1` responses [env: RETH_RPC_COMPUTE_STATE_ROOT_FOR_ETH_SIMULATE=] --rpc.eth-proof-window The maximum proof window for historical proof generation. This value allows for generating historical proofs up to configured number of blocks from current tip (up to `tip - window`) [default: 0] --rpc.proof-permits Maximum number of concurrent getproof requests [default: 25] --rpc.pending-block Configures the pending block behavior for RPC responses. Options: full (include all transactions), empty (header only), none (disable pending blocks). [default: full] --rpc.forwarder Endpoint to forward transactions to --builder.disallow Path to file containing disallowed addresses, json-encoded list of strings. Block validation API will reject blocks containing transactions from these addresses RPC State Cache: --rpc-cache.max-blocks Max number of blocks in cache [default: 5000] --rpc-cache.max-receipts Max number receipts in cache [default: 2000] --rpc-cache.max-bals Max number of block access lists in cache [default: 1000] --rpc-cache.max-concurrent-db-requests Max number of concurrent database requests [default: 512] --rpc-cache.max-cached-tx-hashes Maximum number of transaction hashes to cache for transaction lookups [default: 100000] Gas Price Oracle: --gpo.blocks Number of recent blocks to check for gas price [default: 20] --gpo.ignoreprice Gas Price below which gpo will ignore transactions [default: 0] --gpo.maxprice Maximum transaction priority fee(or gasprice before London Fork) to be recommended by gpo [default: 500000000000] --gpo.percentile The percentile of gas prices to use for the estimate [default: 60] --gpo.default-suggested-fee The default gas price to use if there are no blocks to use --rpc.send-raw-transaction-sync-timeout Timeout for `send_raw_transaction_sync` RPC method [default: 30s] --testing.skip-invalid-transactions Skip invalid transactions in `testing_buildBlockV1` instead of failing. When enabled, transactions that fail execution will be skipped, and all subsequent transactions from the same sender will also be skipped. --rpc.force-blob-sidecar-upcasting Force upcasting EIP-4844 blob sidecars to EIP-7594 format when Osaka is active. When enabled, blob transactions submitted via `eth_sendRawTransaction` with EIP-4844 sidecars will be automatically converted to EIP-7594 format if the next block is Osaka. By default this is disabled, meaning transactions are submitted as-is. TxPool: --txpool.pending-max-count Max number of transactions in the pending sub-pool [default: 10000] --txpool.pending-max-size Max size of the pending sub-pool in megabytes [default: 20] --txpool.basefee-max-count Max number of transactions in the basefee sub-pool [default: 10000] --txpool.basefee-max-size Max size of the basefee sub-pool in megabytes [default: 20] --txpool.queued-max-count Max number of transactions in the queued sub-pool [default: 10000] --txpool.queued-max-size Max size of the queued sub-pool in megabytes [default: 20] --txpool.blobpool-max-count Max number of transactions in the blobpool [default: 10000] --txpool.blobpool-max-size Max size of the blobpool in megabytes [default: 20] --txpool.blob-cache-size Max number of entries for the in memory cache of the blob store --txpool.disable-blobs-support Disable EIP-4844 blob transaction support --txpool.max-account-slots Max number of executable transaction slots guaranteed per account [default: 16] --txpool.pricebump Price bump (in %) for the transaction pool underpriced check [default: 10] --txpool.minimal-protocol-fee Minimum base fee required by the protocol [default: 7] --txpool.minimum-priority-fee Minimum priority fee required for transaction acceptance into the pool. Transactions with priority fee below this value will be rejected --txpool.gas-limit The default enforced gas limit for transactions entering the pool [default: 30000000] --txpool.max-tx-gas Maximum gas limit for individual transactions. Transactions exceeding this limit will be rejected by the transaction pool --blobpool.pricebump Price bump percentage to replace an already existing blob transaction [default: 100] --txpool.max-tx-input-bytes Max size in bytes of a single transaction allowed to enter the pool [default: 131072] --txpool.max-cached-entries The maximum number of blobs to keep in the in memory blob cache [default: 100] --txpool.nolocals Flag to disable local transaction exemptions --txpool.locals Flag to allow certain addresses as local --txpool.no-local-transactions-propagation Flag to toggle local transaction propagation --txpool.additional-validation-tasks Number of additional transaction validation tasks to spawn [default: 1] --txpool.max-pending-txns Maximum number of pending transactions from the network to buffer [default: 2048] --txpool.max-new-txns Maximum number of new transactions to buffer [default: 1024] --txpool.max-new-pending-txs-notifications How many new pending transactions to buffer and send to in progress pending transaction iterators [default: 200] --txpool.lifetime Maximum amount of time non-executable transaction are queued [default: 10800] --txpool.transactions-backup Path to store the local transaction backup at, to survive node restarts --txpool.disable-transactions-backup Disables transaction backup to disk on node shutdown --txpool.max-batch-size Max batch size for transaction pool insertions [default: 1] Builder: --builder.extradata Block extra data set by the payload builder. If the value is a `0x`-prefixed hex string, it is decoded into raw bytes. Otherwise, the raw UTF-8 bytes of the string are used. [default: reth//] --builder.gaslimit Target gas limit for built blocks --builder.interval The interval at which the job should build a new payload after the last. Interval is specified in seconds or in milliseconds if the value ends with `ms`: * `50ms` -> 50 milliseconds * `1` -> 1 second [default: 1] --builder.deadline The deadline for when the payload builder job should resolve [default: 12] --builder.max-tasks Maximum number of tasks to spawn for building a payload [default: 3] --builder.max-blobs Maximum number of blobs to include per block Debug: --debug.terminate Flag indicating whether the node should be terminated after the pipeline sync --debug.tip Set the chain tip manually for testing purposes. NOTE: This is a temporary flag --debug.max-block Runs the sync only up to the specified block --debug.etherscan [] Runs a fake consensus client that advances the chain using recent block hashes on Etherscan. If specified, requires an `ETHERSCAN_API_KEY` environment variable --debug.rpc-consensus-url Runs a fake consensus client using blocks fetched from an RPC endpoint. Supports both HTTP and `WebSocket` endpoints - `WebSocket` endpoints will use subscriptions, while HTTP endpoints will poll for new blocks --debug.skip-fcu If provided, the engine will skip `n` consecutive FCUs --debug.skip-new-payload If provided, the engine will skip `n` consecutive new payloads --debug.skip-genesis-validation If set, bypasses genesis hash validation during init. Intended for tools that direct-write the database (e.g. snapshot importers, state-actor) and want reth to trust the DB-resident genesis state instead of recomputing it from the chainspec's alloc. When the bypass fires, a structured `tracing::warn!` is emitted so the divergence stays observable in operator logs --debug.reorg-frequency If provided, the chain will be reorged at specified frequency --debug.reorg-depth The reorg depth for chain reorgs --debug.engine-api-store The path to store engine API messages at. If specified, all of the intercepted engine API messages will be written to specified location --debug.invalid-block-hook Determines which type of invalid block hook to install Example: `witness,prestate` [default: witness] [possible values: witness, pre-state, opcode] --debug.healthy-node-rpc-url The RPC URL of a healthy node to use for comparing invalid block hook results against. Debug setting that enables execution witness comparison for troubleshooting bad blocks. When enabled, the node will collect execution witnesses from the specified source and compare them against local execution when a bad block is encountered, helping identify discrepancies in state execution. --ethstats The URL of the ethstats server to connect to. Example: `nodename:secret@host:port` --debug.startup-sync-state-idle Set the node to idle state when the backfill is not running. This makes the `eth_syncing` RPC return "Idle" when the node has just started or finished the backfill, but did not yet receive any new blocks. Database: --db.log-level Database logging level. Levels higher than "notice" require a debug build Possible values: - fatal: Enables logging for critical conditions, i.e. assertion failures - error: Enables logging for error conditions - warn: Enables logging for warning conditions - notice: Enables logging for normal but significant condition - verbose: Enables logging for verbose informational - debug: Enables logging for debug-level messages - trace: Enables logging for trace debug-level messages - extra: Enables logging for extra debug-level messages --db.exclusive Open environment in exclusive/monopolistic mode. Makes it possible to open a database on an NFS volume [possible values: true, false] --db.max-size Maximum database size (e.g., 4TB, 8TB). This sets the "map size" of the database. If the database grows beyond this limit, the node will stop with an "environment map size limit reached" error. The default value is 8TB. --db.page-size Database page size (e.g., 4KB, 8KB, 16KB). Specifies the page size used by the MDBX database. The page size determines the maximum database size. MDBX supports up to 2^31 pages, so with the default 4KB page size, the maximum database size is 8TB. To allow larger databases, increase this value to 8KB or higher. WARNING: This setting is only configurable at database creation; changing it later requires re-syncing. --db.growth-step Database growth step (e.g., 4GB, 4KB) --db.read-transaction-timeout Read transaction timeout in seconds, 0 means no timeout --db.max-readers Maximum number of readers allowed to access the database concurrently --db.sync-mode Controls how aggressively the database synchronizes data to disk --db.rocksdb-block-cache-size `RocksDB` block cache size (e.g., 512MB, 4GB). Controls the size of the in-memory LRU cache for decompressed `RocksDB` blocks. A larger cache reduces repeated decompression of hot blocks, improving read performance for history lookups. --db.balstore-cache-size Number of recent blocks to keep in the in-memory BAL store cache --db.disable-metrics Disable built-in database metrics Dev testnet: --dev Start the node in dev mode This mode uses a local proof-of-authority consensus engine with either fixed block times or automatically mined blocks. Disables network discovery and enables local http server. Prefunds 20 accounts derived by mnemonic "test test test test test test test test test test test junk" with 10 000 ETH each. --dev.block-max-transactions How many transactions to mine per block --dev.block-time Interval between blocks. Parses strings using [`humantime::parse_duration`] --dev.block-time 12s --dev.finality-depth Number of confirmations required before a block is finalized. A depth of `1` finalizes the canonical head immediately. [default: 64] --dev.payload-wait-time Time to wait after initiating payload building before resolving. Introduces a sleep between `fork_choice_updated` and `resolve_kind` in the local miner, giving the payload job time for multiple rebuild attempts with new transactions from the pool. Parses strings using [`humantime::parse_duration`] --dev.payload-wait-time 450ms --dev.mnemonic Derive dev accounts from a fixed mnemonic instead of random ones. [default: "test test test test test test test test test test test junk"] Pruning: --full Run full node. Only the most recent [`MINIMUM_UNWIND_SAFE_DISTANCE`] block states are stored --minimal Run minimal storage mode with maximum pruning and smaller static files. This mode configures the node to use minimal disk space by: - Fully pruning sender recovery, transaction lookup, receipts - Leaving 10,064 blocks for account, storage history and block bodies - Using 10,000 blocks per static file segment --prune.block-interval Minimum pruning interval measured in blocks --prune.sender-recovery.full Prunes all sender recovery data --prune.sender-recovery.distance Prune sender recovery data before the `head-N` block number. In other words, keep last N + 1 blocks --prune.sender-recovery.before Prune sender recovery data before the specified block number. The specified block number is not pruned --prune.transaction-lookup.full Prunes all transaction lookup data --prune.transaction-lookup.distance Prune transaction lookup data before the `head-N` block number. In other words, keep last N + 1 blocks --prune.transaction-lookup.before Prune transaction lookup data before the specified block number. The specified block number is not pruned --prune.receipts.full Prunes all receipt data --prune.receipts.pre-merge Prune receipts before the merge block --prune.receipts.distance Prune receipts before the `head-N` block number. In other words, keep last N + 1 blocks --prune.receipts.before Prune receipts before the specified block number. The specified block number is not pruned --prune.receiptslogfilter Configure receipts log filter. Format: <`address`>:<`prune_mode`>... where <`prune_mode`> can be 'full', 'distance:<`blocks`>', or 'before:<`block_number`>' --prune.account-history.full Prunes all account history --prune.account-history.distance Prune account before the `head-N` block number. In other words, keep last N + 1 blocks --prune.account-history.before Prune account history before the specified block number. The specified block number is not pruned --prune.storage-history.full Prunes all storage history data --prune.storage-history.distance Prune storage history before the `head-N` block number. In other words, keep last N + 1 blocks --prune.storage-history.before Prune storage history before the specified block number. The specified block number is not pruned --prune.bodies.pre-merge Prune bodies before the merge block --prune.bodies.distance Prune bodies before the `head-N` block number. In other words, keep last N + 1 blocks --prune.bodies.before Prune storage history before the specified block number. The specified block number is not pruned --prune.minimum-distance Minimum pruning distance from the tip. This controls the safety margin for reorgs and manual unwinds Engine: --engine.persistence-threshold Configure persistence threshold for the engine. This determines how many canonical blocks must be in-memory, ahead of the last persisted block, before flushing canonical blocks to disk again. To persist blocks as fast as the node receives them, set this value to zero. This will cause more frequent DB writes. [env: RETH_ENGINE_PERSISTENCE_THRESHOLD=] [default: 7] --engine.persistence-backpressure-threshold Configure the maximum number of blocks beyond the in-memory buffer target that may await persistence before engine API processing stalls. If omitted, this defaults to the larger of the default backpressure threshold and twice `--engine.persistence-threshold`. This value must be greater than `--engine.persistence-threshold`. --engine.num-state-masking-blocks EXPERIMENTAL: Configure how many of the blocks being persisted should only mask state/trie writes instead of durably persisting their state/trie updates in the current cycle [env: RETH_ENGINE_NUM_STATE_MASKING_BLOCKS=] [default: 0] --engine.memory-block-buffer-target Configure the target number of blocks to keep in memory. If omitted, this defaults to the lesser of `--engine.persistence-threshold` and the configured default memory block buffer target. --engine.invalid-header-cache-hit-eviction-threshold Configure how many cache hits an invalid header can accumulate before it is evicted and reprocessed. Set to `0` to effectively disable the cache because entries are evicted on the first lookup. [default: 128] --engine.disable-state-cache Disable state cache --engine.disable-prewarming Disable parallel prewarming --engine.txpool-prewarming Enable best-effort txpool transaction prewarming between payloads [env: RETH_ENGINE_TXPOOL_PREWARMING=] --engine.sender-recovery-cache Enable caching recovered transaction senders across transaction ingress and payload execution [env: RETH_ENGINE_SENDER_RECOVERY_CACHE=] --engine.state-provider-metrics Enable state provider latency metrics. This allows the engine to collect and report stats about how long state provider calls took during execution, but this does introduce slight overhead to state provider calls --engine.cross-block-cache-size Configure the size of cross-block cache in megabytes [default: 4096] --engine.state-root-task-compare-updates Enable comparing trie updates from the state root task to the trie updates from the regular state root calculation --engine.accept-execution-requests-hash Enables accepting requests hash instead of an array of requests in `engine_newPayloadV4` --engine.multiproof-chunk-size Multiproof task chunk size for proof targets [default: 5] --engine.reserved-cpu-cores Configure the number of reserved CPU cores for non-reth processes [default: 1] --engine.disable-precompile-cache Disable precompile cache --engine.state-root-fallback Enable state root fallback, useful for testing --engine.always-process-payload-attributes-on-canonical-head Always process payload attributes and begin a payload build process even if `forkchoiceState.headBlockHash` is already the canonical head or an ancestor. See `TreeConfig::always_process_payload_attributes_on_canonical_head` for more details. Note: This is a no-op on OP Stack. --engine.allow-unwind-canonical-header Allow unwinding canonical header to ancestor during forkchoice updates. See `TreeConfig::unwind_canonical_header` for more details --engine.storage-worker-count Configure the number of storage proof workers in the Tokio blocking pool. If not specified, defaults to 2x available parallelism --engine.account-worker-count Configure the number of account proof workers in the Tokio blocking pool. If not specified, defaults to the same count as storage workers --engine.prewarming-threads Configure the number of prewarming threads. If not specified, defaults to available parallelism --engine.disable-cache-metrics Disable cache metrics recording, which can take up to 50ms with large cached state --engine.slow-block-threshold Configure the slow block logging threshold in milliseconds. When set, blocks that take longer than this threshold to execute will be logged with detailed metrics including timing, state operations, and cache statistics. Set to 0 to log all blocks (useful for debugging/profiling). When not set, slow block logging is disabled (default). --engine.disable-sparse-trie-cache-pruning Fully disable sparse trie cache pruning. When set, the cached sparse trie is preserved without any node pruning or storage trie eviction between blocks. Useful for benchmarking the effects of retaining the full trie cache --engine.state-root-task-timeout Configure the timeout for the state root task before spawning a sequential fallback. If the state root task takes longer than this, a sequential computation starts in parallel and whichever finishes first is used. --engine.state-root-task-timeout 4s --engine.state-root-task-timeout 400ms Set to 0s to disable. [default: 4s] --engine.share-execution-cache-with-payload-builder Whether to share execution cache with the payload builder. When enabled, each payload job will get an instance of cross-block execution cache from the engine. Note: this should only be enabled if node would not be requested to process any payloads in parallel with payload building. --engine.share-sparse-trie-with-payload-builder Whether to share the sparse trie with the payload builder. Replaces the payload builder's blocking `state_root_with_updates()` call with the sparse trie, computing the state root concurrently with transaction execution. The engine and payload builder contend for the same trie — if a builder task is still running when `newPayload` arrives, the engine will block until the trie is stored back. The builder also anchors the trie at the built block's state root, so if the next `newPayload` is not on top of that block, the trie cache is invalidated and cleared. --engine.suppress-persistence-during-build Suppress persistence while building a payload. When enabled, persistence cycles are deferred while a payload build is active. Useful on chains with short block times where persistence I/O can interfere with block building latency. --engine.disable-bal-parallel-execution Disable BAL (Block Access List, EIP-7928) based parallel execution --engine.disable-bal-parallel-state-root Disable BAL-driven parallel state root computation. This is only valid together with `--engine.disable-bal-parallel-execution` --engine.disable-bal-batch-io Disable BAL (Block Access List) storage prefetch IO during prewarming. When set, BAL storage slots are not read into the execution cache ERA: --era.enable Enable import from ERA1 files --era.path The path to a directory for import. The ERA1 files are read from the local directory parsing headers and bodies. --era.url The URL to a remote host where the ERA1 files are hosted. The ERA1 files are read from the remote host using HTTP GET requests parsing headers and bodies. Static Files: --static-files.blocks-per-file.headers Number of blocks per file for the headers segment --static-files.blocks-per-file.transactions Number of blocks per file for the transactions segment --static-files.blocks-per-file.receipts Number of blocks per file for the receipts segment --static-files.blocks-per-file.transaction-senders Number of blocks per file for the transaction senders segment --static-files.blocks-per-file.account-change-sets Number of blocks per file for the account changesets segment --static-files.blocks-per-file.storage-change-sets Number of blocks per file for the storage changesets segment Storage: --storage.v2 [] Enable V2 (hot/cold) storage layout for new databases. When set, new databases will be initialized with the V2 storage layout that separates hot and cold data. Existing databases always use the settings persisted in their metadata regardless of this flag. [default: true] [possible values: true, false] JIT: --jit Enable JIT compilation of EVM bytecode --jit.hot-threshold Number of observed misses before a bytecode is promoted to JIT compilation [default: 8] --jit.worker-count Number of JIT compilation worker threads --jit.channel-capacity Capacity of the lookup-observed event channel. Events are silently dropped when the channel is full [default: 4096] --jit.max-pending-jobs Maximum number of pending JIT compilation jobs [default: 2048] --jit.max-bytecode-len Maximum bytecode length eligible for JIT compilation. Contracts with bytecode larger than this are never promoted to JIT. 0 means no limit [default: 0] --jit.code-cache-bytes Maximum total resident compiled code size in bytes. When exceeded, the backend evicts least-recently-used entries. 0 means no limit [default: 1073741824] --jit.idle-evict-duration Duration after which a compiled program with no lookup hits is evicted [default: 1h] --jit.debug Enable compiler debug dumps. IR, assembly, and bytecode are written to `/jit///` for each compiled contract. Note that this is not ever cleaned up, and has a non negligible performance overhead. Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth init Initialize the database from a genesis file ```bash $ reth init --help ``` ```txt Usage: reth init [OPTIONS] Options: -h, --help Print help (see a summary with '-h') Datadir: --datadir The path to the data dir for all reth files and subdirectories. Defaults to the OS-specific data directory: - Linux: `$XDG_DATA_HOME/reth/` or `$HOME/.local/share/reth/` - Windows: `{FOLDERID_RoamingAppData}/reth/` - macOS: `$HOME/Library/Application Support/reth/` [default: default] --datadir.static-files The absolute path to store static files in. --datadir.rocksdb The absolute path to store `RocksDB` database in. --datadir.pprof-dumps The absolute path to store pprof dumps in. --config The path to the configuration file to use --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Database: --db.log-level Database logging level. Levels higher than "notice" require a debug build Possible values: - fatal: Enables logging for critical conditions, i.e. assertion failures - error: Enables logging for error conditions - warn: Enables logging for warning conditions - notice: Enables logging for normal but significant condition - verbose: Enables logging for verbose informational - debug: Enables logging for debug-level messages - trace: Enables logging for trace debug-level messages - extra: Enables logging for extra debug-level messages --db.exclusive Open environment in exclusive/monopolistic mode. Makes it possible to open a database on an NFS volume [possible values: true, false] --db.max-size Maximum database size (e.g., 4TB, 8TB). This sets the "map size" of the database. If the database grows beyond this limit, the node will stop with an "environment map size limit reached" error. The default value is 8TB. --db.page-size Database page size (e.g., 4KB, 8KB, 16KB). Specifies the page size used by the MDBX database. The page size determines the maximum database size. MDBX supports up to 2^31 pages, so with the default 4KB page size, the maximum database size is 8TB. To allow larger databases, increase this value to 8KB or higher. WARNING: This setting is only configurable at database creation; changing it later requires re-syncing. --db.growth-step Database growth step (e.g., 4GB, 4KB) --db.read-transaction-timeout Read transaction timeout in seconds, 0 means no timeout --db.max-readers Maximum number of readers allowed to access the database concurrently --db.sync-mode Controls how aggressively the database synchronizes data to disk --db.rocksdb-block-cache-size `RocksDB` block cache size (e.g., 512MB, 4GB). Controls the size of the in-memory LRU cache for decompressed `RocksDB` blocks. A larger cache reduces repeated decompression of hot blocks, improving read performance for history lookups. --db.balstore-cache-size Number of recent blocks to keep in the in-memory BAL store cache --db.disable-metrics Disable built-in database metrics Static Files: --static-files.blocks-per-file.headers Number of blocks per file for the headers segment --static-files.blocks-per-file.transactions Number of blocks per file for the transactions segment --static-files.blocks-per-file.receipts Number of blocks per file for the receipts segment --static-files.blocks-per-file.transaction-senders Number of blocks per file for the transaction senders segment --static-files.blocks-per-file.account-change-sets Number of blocks per file for the account changesets segment --static-files.blocks-per-file.storage-change-sets Number of blocks per file for the storage changesets segment Storage: --storage.v2 [] Enable V2 (hot/cold) storage layout for new databases. When set, new databases will be initialized with the V2 storage layout that separates hot and cold data. Existing databases always use the settings persisted in their metadata regardless of this flag. [default: true] [possible values: true, false] Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth init-state Initialize the database from a state dump file ```bash $ reth init-state --help ``` ```txt Usage: reth init-state [OPTIONS] Options: -h, --help Print help (see a summary with '-h') Datadir: --datadir The path to the data dir for all reth files and subdirectories. Defaults to the OS-specific data directory: - Linux: `$XDG_DATA_HOME/reth/` or `$HOME/.local/share/reth/` - Windows: `{FOLDERID_RoamingAppData}/reth/` - macOS: `$HOME/Library/Application Support/reth/` [default: default] --datadir.static-files The absolute path to store static files in. --datadir.rocksdb The absolute path to store `RocksDB` database in. --datadir.pprof-dumps The absolute path to store pprof dumps in. --config The path to the configuration file to use --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Database: --db.log-level Database logging level. Levels higher than "notice" require a debug build Possible values: - fatal: Enables logging for critical conditions, i.e. assertion failures - error: Enables logging for error conditions - warn: Enables logging for warning conditions - notice: Enables logging for normal but significant condition - verbose: Enables logging for verbose informational - debug: Enables logging for debug-level messages - trace: Enables logging for trace debug-level messages - extra: Enables logging for extra debug-level messages --db.exclusive Open environment in exclusive/monopolistic mode. Makes it possible to open a database on an NFS volume [possible values: true, false] --db.max-size Maximum database size (e.g., 4TB, 8TB). This sets the "map size" of the database. If the database grows beyond this limit, the node will stop with an "environment map size limit reached" error. The default value is 8TB. --db.page-size Database page size (e.g., 4KB, 8KB, 16KB). Specifies the page size used by the MDBX database. The page size determines the maximum database size. MDBX supports up to 2^31 pages, so with the default 4KB page size, the maximum database size is 8TB. To allow larger databases, increase this value to 8KB or higher. WARNING: This setting is only configurable at database creation; changing it later requires re-syncing. --db.growth-step Database growth step (e.g., 4GB, 4KB) --db.read-transaction-timeout Read transaction timeout in seconds, 0 means no timeout --db.max-readers Maximum number of readers allowed to access the database concurrently --db.sync-mode Controls how aggressively the database synchronizes data to disk --db.rocksdb-block-cache-size `RocksDB` block cache size (e.g., 512MB, 4GB). Controls the size of the in-memory LRU cache for decompressed `RocksDB` blocks. A larger cache reduces repeated decompression of hot blocks, improving read performance for history lookups. --db.balstore-cache-size Number of recent blocks to keep in the in-memory BAL store cache --db.disable-metrics Disable built-in database metrics Static Files: --static-files.blocks-per-file.headers Number of blocks per file for the headers segment --static-files.blocks-per-file.transactions Number of blocks per file for the transactions segment --static-files.blocks-per-file.receipts Number of blocks per file for the receipts segment --static-files.blocks-per-file.transaction-senders Number of blocks per file for the transaction senders segment --static-files.blocks-per-file.account-change-sets Number of blocks per file for the account changesets segment --static-files.blocks-per-file.storage-change-sets Number of blocks per file for the storage changesets segment Storage: --storage.v2 [] Enable V2 (hot/cold) storage layout for new databases. When set, new databases will be initialized with the V2 storage layout that separates hot and cold data. Existing databases always use the settings persisted in their metadata regardless of this flag. [default: true] [possible values: true, false] --without-evm Specifies whether to initialize the state without relying on EVM historical data. When enabled, and before inserting the state, it creates a dummy chain up to the last EVM block specified. It then appends the first provided block. - **Note**: **Do not** import receipts and blocks beforehand, or this will fail or be ignored. --header Header file containing the header in an RLP encoded format. --header-hash Hash of the header. JSONL file with state dump. Must contain accounts in following format, additional account fields are ignored. Must also contain { "root": \ } as first line. { "balance": "\", "nonce": \, "code": "\", "storage": { "\": "\", .. }, "address": "\", } Allows init at a non-genesis block. Caution! Blocks must be manually imported up until and including the non-genesis block to init chain at. See 'import' command. Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth import This syncs RLP encoded blocks from a file or files ```bash $ reth import --help ``` ```txt Usage: reth import [OPTIONS] ... Options: -h, --help Print help (see a summary with '-h') Datadir: --datadir The path to the data dir for all reth files and subdirectories. Defaults to the OS-specific data directory: - Linux: `$XDG_DATA_HOME/reth/` or `$HOME/.local/share/reth/` - Windows: `{FOLDERID_RoamingAppData}/reth/` - macOS: `$HOME/Library/Application Support/reth/` [default: default] --datadir.static-files The absolute path to store static files in. --datadir.rocksdb The absolute path to store `RocksDB` database in. --datadir.pprof-dumps The absolute path to store pprof dumps in. --config The path to the configuration file to use --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Database: --db.log-level Database logging level. Levels higher than "notice" require a debug build Possible values: - fatal: Enables logging for critical conditions, i.e. assertion failures - error: Enables logging for error conditions - warn: Enables logging for warning conditions - notice: Enables logging for normal but significant condition - verbose: Enables logging for verbose informational - debug: Enables logging for debug-level messages - trace: Enables logging for trace debug-level messages - extra: Enables logging for extra debug-level messages --db.exclusive Open environment in exclusive/monopolistic mode. Makes it possible to open a database on an NFS volume [possible values: true, false] --db.max-size Maximum database size (e.g., 4TB, 8TB). This sets the "map size" of the database. If the database grows beyond this limit, the node will stop with an "environment map size limit reached" error. The default value is 8TB. --db.page-size Database page size (e.g., 4KB, 8KB, 16KB). Specifies the page size used by the MDBX database. The page size determines the maximum database size. MDBX supports up to 2^31 pages, so with the default 4KB page size, the maximum database size is 8TB. To allow larger databases, increase this value to 8KB or higher. WARNING: This setting is only configurable at database creation; changing it later requires re-syncing. --db.growth-step Database growth step (e.g., 4GB, 4KB) --db.read-transaction-timeout Read transaction timeout in seconds, 0 means no timeout --db.max-readers Maximum number of readers allowed to access the database concurrently --db.sync-mode Controls how aggressively the database synchronizes data to disk --db.rocksdb-block-cache-size `RocksDB` block cache size (e.g., 512MB, 4GB). Controls the size of the in-memory LRU cache for decompressed `RocksDB` blocks. A larger cache reduces repeated decompression of hot blocks, improving read performance for history lookups. --db.balstore-cache-size Number of recent blocks to keep in the in-memory BAL store cache --db.disable-metrics Disable built-in database metrics Static Files: --static-files.blocks-per-file.headers Number of blocks per file for the headers segment --static-files.blocks-per-file.transactions Number of blocks per file for the transactions segment --static-files.blocks-per-file.receipts Number of blocks per file for the receipts segment --static-files.blocks-per-file.transaction-senders Number of blocks per file for the transaction senders segment --static-files.blocks-per-file.account-change-sets Number of blocks per file for the account changesets segment --static-files.blocks-per-file.storage-change-sets Number of blocks per file for the storage changesets segment Storage: --storage.v2 [] Enable V2 (hot/cold) storage layout for new databases. When set, new databases will be initialized with the V2 storage layout that separates hot and cold data. Existing databases always use the settings persisted in their metadata regardless of this flag. [default: true] [possible values: true, false] --no-state Disables stages that require state. --chunk-len Chunk byte length to read from file. --fail-on-invalid-block Fail immediately when an invalid block is encountered. By default, the import will stop at the last valid block if an invalid block is encountered during execution or validation, leaving the database at the last valid block state. When this flag is set, the import will instead fail with an error. ... The path(s) to block file(s) for import. The online stages (headers and bodies) are replaced by a file import, after which the remaining stages are executed. Multiple files will be imported sequentially. Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth import-era This syncs ERA encoded blocks from a directory ```bash $ reth import-era --help ``` ```txt Usage: reth import-era [OPTIONS] Options: -h, --help Print help (see a summary with '-h') Datadir: --datadir The path to the data dir for all reth files and subdirectories. Defaults to the OS-specific data directory: - Linux: `$XDG_DATA_HOME/reth/` or `$HOME/.local/share/reth/` - Windows: `{FOLDERID_RoamingAppData}/reth/` - macOS: `$HOME/Library/Application Support/reth/` [default: default] --datadir.static-files The absolute path to store static files in. --datadir.rocksdb The absolute path to store `RocksDB` database in. --datadir.pprof-dumps The absolute path to store pprof dumps in. --config The path to the configuration file to use --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Database: --db.log-level Database logging level. Levels higher than "notice" require a debug build Possible values: - fatal: Enables logging for critical conditions, i.e. assertion failures - error: Enables logging for error conditions - warn: Enables logging for warning conditions - notice: Enables logging for normal but significant condition - verbose: Enables logging for verbose informational - debug: Enables logging for debug-level messages - trace: Enables logging for trace debug-level messages - extra: Enables logging for extra debug-level messages --db.exclusive Open environment in exclusive/monopolistic mode. Makes it possible to open a database on an NFS volume [possible values: true, false] --db.max-size Maximum database size (e.g., 4TB, 8TB). This sets the "map size" of the database. If the database grows beyond this limit, the node will stop with an "environment map size limit reached" error. The default value is 8TB. --db.page-size Database page size (e.g., 4KB, 8KB, 16KB). Specifies the page size used by the MDBX database. The page size determines the maximum database size. MDBX supports up to 2^31 pages, so with the default 4KB page size, the maximum database size is 8TB. To allow larger databases, increase this value to 8KB or higher. WARNING: This setting is only configurable at database creation; changing it later requires re-syncing. --db.growth-step Database growth step (e.g., 4GB, 4KB) --db.read-transaction-timeout Read transaction timeout in seconds, 0 means no timeout --db.max-readers Maximum number of readers allowed to access the database concurrently --db.sync-mode Controls how aggressively the database synchronizes data to disk --db.rocksdb-block-cache-size `RocksDB` block cache size (e.g., 512MB, 4GB). Controls the size of the in-memory LRU cache for decompressed `RocksDB` blocks. A larger cache reduces repeated decompression of hot blocks, improving read performance for history lookups. --db.balstore-cache-size Number of recent blocks to keep in the in-memory BAL store cache --db.disable-metrics Disable built-in database metrics Static Files: --static-files.blocks-per-file.headers Number of blocks per file for the headers segment --static-files.blocks-per-file.transactions Number of blocks per file for the transactions segment --static-files.blocks-per-file.receipts Number of blocks per file for the receipts segment --static-files.blocks-per-file.transaction-senders Number of blocks per file for the transaction senders segment --static-files.blocks-per-file.account-change-sets Number of blocks per file for the account changesets segment --static-files.blocks-per-file.storage-change-sets Number of blocks per file for the storage changesets segment Storage: --storage.v2 [] Enable V2 (hot/cold) storage layout for new databases. When set, new databases will be initialized with the V2 storage layout that separates hot and cold data. Existing databases always use the settings persisted in their metadata regardless of this flag. [default: true] [possible values: true, false] --path The path to a directory for import. The ERA1 files are read from the local directory parsing headers and bodies. --url The URL to a remote host where the ERA1 files are hosted. The ERA1 files are read from the remote host using HTTP GET requests parsing headers and bodies. --to-block Stop the import after this block height has been reached. The file containing the block is imported up to and including this height, then the import ends. By default all available blocks are imported. --with-receipts Backfill the `Receipts` static file segment from its tip up to the Execution checkpoint. Only a missing tail is detected and repaired, never a gap inside the existing segment. The backfill must reach the checkpoint exactly, so this cannot bootstrap a fresh database: above the checkpoint receipts are pruned on the next node start, below it the node cannot start. Byzantium onwards only, from `.era1` or `.ere` files that carry receipts. Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth export-era Exports block to era1 files in a specified directory ```bash $ reth export-era --help ``` ```txt Usage: reth export-era [OPTIONS] Options: -h, --help Print help (see a summary with '-h') Datadir: --datadir The path to the data dir for all reth files and subdirectories. Defaults to the OS-specific data directory: - Linux: `$XDG_DATA_HOME/reth/` or `$HOME/.local/share/reth/` - Windows: `{FOLDERID_RoamingAppData}/reth/` - macOS: `$HOME/Library/Application Support/reth/` [default: default] --datadir.static-files The absolute path to store static files in. --datadir.rocksdb The absolute path to store `RocksDB` database in. --datadir.pprof-dumps The absolute path to store pprof dumps in. --config The path to the configuration file to use --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Database: --db.log-level Database logging level. Levels higher than "notice" require a debug build Possible values: - fatal: Enables logging for critical conditions, i.e. assertion failures - error: Enables logging for error conditions - warn: Enables logging for warning conditions - notice: Enables logging for normal but significant condition - verbose: Enables logging for verbose informational - debug: Enables logging for debug-level messages - trace: Enables logging for trace debug-level messages - extra: Enables logging for extra debug-level messages --db.exclusive Open environment in exclusive/monopolistic mode. Makes it possible to open a database on an NFS volume [possible values: true, false] --db.max-size Maximum database size (e.g., 4TB, 8TB). This sets the "map size" of the database. If the database grows beyond this limit, the node will stop with an "environment map size limit reached" error. The default value is 8TB. --db.page-size Database page size (e.g., 4KB, 8KB, 16KB). Specifies the page size used by the MDBX database. The page size determines the maximum database size. MDBX supports up to 2^31 pages, so with the default 4KB page size, the maximum database size is 8TB. To allow larger databases, increase this value to 8KB or higher. WARNING: This setting is only configurable at database creation; changing it later requires re-syncing. --db.growth-step Database growth step (e.g., 4GB, 4KB) --db.read-transaction-timeout Read transaction timeout in seconds, 0 means no timeout --db.max-readers Maximum number of readers allowed to access the database concurrently --db.sync-mode Controls how aggressively the database synchronizes data to disk --db.rocksdb-block-cache-size `RocksDB` block cache size (e.g., 512MB, 4GB). Controls the size of the in-memory LRU cache for decompressed `RocksDB` blocks. A larger cache reduces repeated decompression of hot blocks, improving read performance for history lookups. --db.balstore-cache-size Number of recent blocks to keep in the in-memory BAL store cache --db.disable-metrics Disable built-in database metrics Static Files: --static-files.blocks-per-file.headers Number of blocks per file for the headers segment --static-files.blocks-per-file.transactions Number of blocks per file for the transactions segment --static-files.blocks-per-file.receipts Number of blocks per file for the receipts segment --static-files.blocks-per-file.transaction-senders Number of blocks per file for the transaction senders segment --static-files.blocks-per-file.account-change-sets Number of blocks per file for the account changesets segment --static-files.blocks-per-file.storage-change-sets Number of blocks per file for the storage changesets segment Storage: --storage.v2 [] Enable V2 (hot/cold) storage layout for new databases. When set, new databases will be initialized with the V2 storage layout that separates hot and cold data. Existing databases always use the settings persisted in their metadata regardless of this flag. [default: true] [possible values: true, false] --file-type The ERA file format to export: `era1` writes `.era1` files, `ere` writes `.ere` files. Possible values: - era1: Execution blocks written in the `.era1` format - ere: Execution blocks written in the `.ere` format - era: Consensus-layer `.era` format. Not exportable from an execution client; selecting it is an error [default: era1] --first-block-number Optional first block number to export from the db. It is by default 0. --last-block-number Optional last block number to export from the db. It is by default 8191. --max-blocks-per-file The maximum number of blocks per file, it can help you to decrease the size of the files. Must be less than or equal to 8192. --path The directory where the exported ERA files are written. Defaults to `//-export/`, where `` is `era1` or `ere`. Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth dump-genesis Dumps genesis block JSON configuration to stdout ```bash $ reth dump-genesis --help ``` ```txt Usage: reth dump-genesis [OPTIONS] Options: --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] -h, --help Print help (see a summary with '-h') Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth db Database debugging utilities ```bash $ reth db --help ``` ```txt Usage: reth db [OPTIONS] Commands: stats Lists all the tables, their entry count and their size list Lists the contents of a table checksum Calculates the content checksum of a table or static file segment copy Copies the MDBX database to a new location (bundled mdbx_copy) diff Create a diff between two database tables or two entire databases get Gets the content of a table for the given key drop Deletes all database entries clear Deletes all table entries repair-trie Verifies trie consistency and outputs any inconsistencies static-file-header Reads and displays the static file segment header version Lists current and local database versions path Returns the full database path settings Manage storage settings prune-checkpoints View or set prune checkpoints stage-checkpoints `reth db stage-checkpoints` subcommand account-storage Gets storage size information for an account state Gets account state and storage at a specific block migrate-v2 Migrate storage layout from v1 (MDBX-only) to v2 (static files + RocksDB) help Print this message or the help of the given subcommand(s) Options: -h, --help Print help (see a summary with '-h') Datadir: --datadir The path to the data dir for all reth files and subdirectories. Defaults to the OS-specific data directory: - Linux: `$XDG_DATA_HOME/reth/` or `$HOME/.local/share/reth/` - Windows: `{FOLDERID_RoamingAppData}/reth/` - macOS: `$HOME/Library/Application Support/reth/` [default: default] --datadir.static-files The absolute path to store static files in. --datadir.rocksdb The absolute path to store `RocksDB` database in. --datadir.pprof-dumps The absolute path to store pprof dumps in. --config The path to the configuration file to use --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Database: --db.log-level Database logging level. Levels higher than "notice" require a debug build Possible values: - fatal: Enables logging for critical conditions, i.e. assertion failures - error: Enables logging for error conditions - warn: Enables logging for warning conditions - notice: Enables logging for normal but significant condition - verbose: Enables logging for verbose informational - debug: Enables logging for debug-level messages - trace: Enables logging for trace debug-level messages - extra: Enables logging for extra debug-level messages --db.exclusive Open environment in exclusive/monopolistic mode. Makes it possible to open a database on an NFS volume [possible values: true, false] --db.max-size Maximum database size (e.g., 4TB, 8TB). This sets the "map size" of the database. If the database grows beyond this limit, the node will stop with an "environment map size limit reached" error. The default value is 8TB. --db.page-size Database page size (e.g., 4KB, 8KB, 16KB). Specifies the page size used by the MDBX database. The page size determines the maximum database size. MDBX supports up to 2^31 pages, so with the default 4KB page size, the maximum database size is 8TB. To allow larger databases, increase this value to 8KB or higher. WARNING: This setting is only configurable at database creation; changing it later requires re-syncing. --db.growth-step Database growth step (e.g., 4GB, 4KB) --db.read-transaction-timeout Read transaction timeout in seconds, 0 means no timeout --db.max-readers Maximum number of readers allowed to access the database concurrently --db.sync-mode Controls how aggressively the database synchronizes data to disk --db.rocksdb-block-cache-size `RocksDB` block cache size (e.g., 512MB, 4GB). Controls the size of the in-memory LRU cache for decompressed `RocksDB` blocks. A larger cache reduces repeated decompression of hot blocks, improving read performance for history lookups. --db.balstore-cache-size Number of recent blocks to keep in the in-memory BAL store cache --db.disable-metrics Disable built-in database metrics Static Files: --static-files.blocks-per-file.headers Number of blocks per file for the headers segment --static-files.blocks-per-file.transactions Number of blocks per file for the transactions segment --static-files.blocks-per-file.receipts Number of blocks per file for the receipts segment --static-files.blocks-per-file.transaction-senders Number of blocks per file for the transaction senders segment --static-files.blocks-per-file.account-change-sets Number of blocks per file for the account changesets segment --static-files.blocks-per-file.storage-change-sets Number of blocks per file for the storage changesets segment Storage: --storage.v2 [] Enable V2 (hot/cold) storage layout for new databases. When set, new databases will be initialized with the V2 storage layout that separates hot and cold data. Existing databases always use the settings persisted in their metadata regardless of this flag. [default: true] [possible values: true, false] Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth db stats Lists all the tables, their entry count and their size ```bash $ reth db stats --help ``` ```txt Usage: reth db stats [OPTIONS] Options: --skip-consistency-checks Skip consistency checks for static files --detailed-sizes Show only the total size for static files --detailed-segments Show detailed information per static file segment --checksum Show a checksum of each table in the database. WARNING: this option will take a long time to run, as it needs to traverse and hash the entire database. For individual table checksums, use the `reth db checksum` command. -h, --help Print help (see a summary with '-h') Datadir: --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth db list Lists the contents of a table ```bash $ reth db list --help ``` ```txt Usage: reth db list [OPTIONS] Arguments:
The table name Options: -s, --skip Skip first N entries [default: 0] -r, --reverse Reverse the order of the entries. If enabled last table entries are read -l, --len How many items to take from the walker [default: 5] --search Search parameter for both keys and values. Prefix it with `0x` to search for binary data, and text otherwise. ATTENTION! For compressed tables (`Transactions` and `Receipts`), there might be missing results since the search uses the raw uncompressed value from the database. --min-row-size Minimum size of row in bytes [default: 0] --min-key-size Minimum size of key in bytes [default: 0] --min-value-size Minimum size of value in bytes [default: 0] -c, --count Returns the number of rows found -j, --json Dump as JSON instead of using TUI --raw Output bytes instead of human-readable decoded value -h, --help Print help (see a summary with '-h') Datadir: --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth db checksum Calculates the content checksum of a table or static file segment ```bash $ reth db checksum --help ``` ```txt Usage: reth db checksum [OPTIONS] Commands: mdbx Calculates the checksum of a database table static-file Calculates the checksum of a static file segment rocksdb Calculates the checksum of a RocksDB table help Print this message or the help of the given subcommand(s) Options: -h, --help Print help (see a summary with '-h') Datadir: --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth db checksum mdbx Calculates the checksum of a database table ```bash $ reth db checksum mdbx --help ``` ```txt Usage: reth db checksum mdbx [OPTIONS]
Arguments:
The table name Options: --start-key The start of the range to checksum --end-key The end of the range to checksum --limit The maximum number of records that are queried and used to compute the checksum -h, --help Print help (see a summary with '-h') Datadir: --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth db checksum static-file Calculates the checksum of a static file segment ```bash $ reth db checksum static-file --help ``` ```txt Usage: reth db checksum static-file [OPTIONS] Arguments: The static file segment Possible values: - headers: Static File segment responsible for the `CanonicalHeaders`, `Headers`, `HeaderTerminalDifficulties` tables - transactions: Static File segment responsible for the `Transactions` table - receipts: Static File segment responsible for the `Receipts` table - transaction-senders: Static File segment responsible for the `TransactionSenders` table - account-change-sets: Static File segment responsible for the `AccountChangeSets` table - storage-change-sets: Static File segment responsible for the `StorageChangeSets` table Options: --start-block The block number to start from (inclusive) --end-block The block number to end at (inclusive) --limit The maximum number of rows to checksum -h, --help Print help (see a summary with '-h') Datadir: --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth db checksum rocksdb Calculates the checksum of a RocksDB table ```bash $ reth db checksum rocksdb --help ``` ```txt Usage: reth db checksum rocksdb [OPTIONS]
Arguments:
The RocksDB table Possible values: - transaction-hash-numbers: Transaction hash to transaction number mapping - accounts-history: Account history indices - storages-history: Storage history indices Options: --limit The maximum number of records to checksum -h, --help Print help (see a summary with '-h') Datadir: --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth db copy Copies the MDBX database to a new location (bundled mdbx\_copy) ```bash $ reth db copy --help ``` ```txt Usage: reth db copy [OPTIONS] Arguments: Destination path for the database copy Options: -c, --compact Compact the database while copying (reclaims free space) -d, --force-dynamic-size Force dynamic size for the destination database -p, --throttle-mvcc Throttle to avoid MVCC pressure on writers -h, --help Print help (see a summary with '-h') Datadir: --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth db diff Create a diff between two database tables or two entire databases ```bash $ reth db diff --help ``` ```txt Usage: reth db diff [OPTIONS] --secondary-datadir --output Options: --secondary-datadir The path to the data dir for all reth files and subdirectories. -h, --help Print help (see a summary with '-h') Database: --db.log-level Database logging level. Levels higher than "notice" require a debug build Possible values: - fatal: Enables logging for critical conditions, i.e. assertion failures - error: Enables logging for error conditions - warn: Enables logging for warning conditions - notice: Enables logging for normal but significant condition - verbose: Enables logging for verbose informational - debug: Enables logging for debug-level messages - trace: Enables logging for trace debug-level messages - extra: Enables logging for extra debug-level messages --db.exclusive Open environment in exclusive/monopolistic mode. Makes it possible to open a database on an NFS volume [possible values: true, false] --db.max-size Maximum database size (e.g., 4TB, 8TB). This sets the "map size" of the database. If the database grows beyond this limit, the node will stop with an "environment map size limit reached" error. The default value is 8TB. --db.page-size Database page size (e.g., 4KB, 8KB, 16KB). Specifies the page size used by the MDBX database. The page size determines the maximum database size. MDBX supports up to 2^31 pages, so with the default 4KB page size, the maximum database size is 8TB. To allow larger databases, increase this value to 8KB or higher. WARNING: This setting is only configurable at database creation; changing it later requires re-syncing. --db.growth-step Database growth step (e.g., 4GB, 4KB) --db.read-transaction-timeout Read transaction timeout in seconds, 0 means no timeout --db.max-readers Maximum number of readers allowed to access the database concurrently --db.sync-mode Controls how aggressively the database synchronizes data to disk --db.rocksdb-block-cache-size `RocksDB` block cache size (e.g., 512MB, 4GB). Controls the size of the in-memory LRU cache for decompressed `RocksDB` blocks. A larger cache reduces repeated decompression of hot blocks, improving read performance for history lookups. --db.balstore-cache-size Number of recent blocks to keep in the in-memory BAL store cache --db.disable-metrics Disable built-in database metrics --table
The table name to diff. If not specified, all tables are diffed. --output The output directory for the diff report. Datadir: --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth db get Gets the content of a table for the given key ```bash $ reth db get --help ``` ```txt Usage: reth db get [OPTIONS] Commands: mdbx Gets the content of a database table for the given key static-file Gets the content of a static file segment for the given key rocksdb Gets the content of a RocksDB table for the given key help Print this message or the help of the given subcommand(s) Options: -h, --help Print help (see a summary with '-h') Datadir: --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth db get mdbx Gets the content of a database table for the given key ```bash $ reth db get mdbx --help ``` ```txt Usage: reth db get mdbx [OPTIONS]
[SUBKEY] [END_KEY] [END_SUBKEY] Arguments:
The key to get content for [SUBKEY] The subkey to get content for [END_KEY] Optional end key for range query (exclusive upper bound) [END_SUBKEY] Optional end subkey for range query (exclusive upper bound) Options: --raw Output bytes instead of human-readable decoded value -h, --help Print help (see a summary with '-h') Datadir: --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth db get static-file Gets the content of a static file segment for the given key ```bash $ reth db get static-file --help ``` ```txt Usage: reth db get static-file [OPTIONS] [SUBKEY] Arguments: Possible values: - headers: Static File segment responsible for the `CanonicalHeaders`, `Headers`, `HeaderTerminalDifficulties` tables - transactions: Static File segment responsible for the `Transactions` table - receipts: Static File segment responsible for the `Receipts` table - transaction-senders: Static File segment responsible for the `TransactionSenders` table - account-change-sets: Static File segment responsible for the `AccountChangeSets` table - storage-change-sets: Static File segment responsible for the `StorageChangeSets` table The key to get content for [SUBKEY] The subkey to get content for, for example address in changeset Options: --raw Output bytes instead of human-readable decoded value -h, --help Print help (see a summary with '-h') Datadir: --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth db get rocksdb Gets the content of a RocksDB table for the given key ```bash $ reth db get rocksdb --help ``` ```txt Usage: reth db get rocksdb [OPTIONS]
Arguments:
The RocksDB table Possible values: - transaction-hash-numbers: Transaction hash to transaction number mapping - accounts-history: Account history indices - storages-history: Storage history indices The key to get content for. For history tables, this can be a plain address Options: --block Target block number for history tables. Seeks to the shard containing this block. Defaults to the latest shard if not specified --storage-key Storage key for storages-history table lookups --all-shards List all shards for the given key (history tables only) --raw Output bytes instead of human-readable decoded value -h, --help Print help (see a summary with '-h') Datadir: --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth db drop Deletes all database entries ```bash $ reth db drop --help ``` ```txt Usage: reth db drop [OPTIONS] Options: -f, --force Bypasses the interactive confirmation and drops the database directly -h, --help Print help (see a summary with '-h') Datadir: --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth db clear Deletes all table entries ```bash $ reth db clear --help ``` ```txt Usage: reth db clear [OPTIONS] Commands: mdbx Deletes all database table entries static-file Deletes all static file segment entries help Print this message or the help of the given subcommand(s) Options: -h, --help Print help (see a summary with '-h') Datadir: --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth db clear mdbx Deletes all database table entries ```bash $ reth db clear mdbx --help ``` ```txt Usage: reth db clear mdbx [OPTIONS]
Arguments:
Options: -h, --help Print help (see a summary with '-h') Datadir: --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth db clear static-file Deletes all static file segment entries ```bash $ reth db clear static-file --help ``` ```txt Usage: reth db clear static-file [OPTIONS] Arguments: Possible values: - headers: Static File segment responsible for the `CanonicalHeaders`, `Headers`, `HeaderTerminalDifficulties` tables - transactions: Static File segment responsible for the `Transactions` table - receipts: Static File segment responsible for the `Receipts` table - transaction-senders: Static File segment responsible for the `TransactionSenders` table - account-change-sets: Static File segment responsible for the `AccountChangeSets` table - storage-change-sets: Static File segment responsible for the `StorageChangeSets` table Options: -h, --help Print help (see a summary with '-h') Datadir: --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth db repair-trie Verifies trie consistency and outputs any inconsistencies ```bash $ reth db repair-trie --help ``` ```txt Usage: reth db repair-trie [OPTIONS] Options: --dry-run Only show inconsistencies without making any repairs --metrics Enable Prometheus metrics. The metrics will be served at the given interface and port. -h, --help Print help (see a summary with '-h') Datadir: --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth db static-file-header Reads and displays the static file segment header ```bash $ reth db static-file-header --help ``` ```txt Usage: reth db static-file-header [OPTIONS] Commands: block Query by segment and block number path Query by path to static file help Print this message or the help of the given subcommand(s) Options: -h, --help Print help (see a summary with '-h') Datadir: --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth db static-file-header block Query by segment and block number ```bash $ reth db static-file-header block --help ``` ```txt Usage: reth db static-file-header block [OPTIONS] Arguments: Static file segment Possible values: - headers: Static File segment responsible for the `CanonicalHeaders`, `Headers`, `HeaderTerminalDifficulties` tables - transactions: Static File segment responsible for the `Transactions` table - receipts: Static File segment responsible for the `Receipts` table - transaction-senders: Static File segment responsible for the `TransactionSenders` table - account-change-sets: Static File segment responsible for the `AccountChangeSets` table - storage-change-sets: Static File segment responsible for the `StorageChangeSets` table Block number to query Options: -h, --help Print help (see a summary with '-h') Datadir: --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth db static-file-header path Query by path to static file ```bash $ reth db static-file-header path --help ``` ```txt Usage: reth db static-file-header path [OPTIONS] Arguments: Path to the static file Options: -h, --help Print help (see a summary with '-h') Datadir: --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth db version Lists current and local database versions ```bash $ reth db version --help ``` ```txt Usage: reth db version [OPTIONS] Options: -h, --help Print help (see a summary with '-h') Datadir: --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth db path Returns the full database path ```bash $ reth db path --help ``` ```txt Usage: reth db path [OPTIONS] Options: -h, --help Print help (see a summary with '-h') Datadir: --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth db settings Manage storage settings ```bash $ reth db settings --help ``` ```txt Usage: reth db settings [OPTIONS] Commands: get Get current storage settings from database set Set storage settings in database help Print this message or the help of the given subcommand(s) Options: -h, --help Print help (see a summary with '-h') Datadir: --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth db settings get Get current storage settings from database ```bash $ reth db settings get --help ``` ```txt Usage: reth db settings get [OPTIONS] Options: -h, --help Print help (see a summary with '-h') Datadir: --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth db settings set Set storage settings in database ```bash $ reth db settings set --help ``` ```txt Usage: reth db settings set [OPTIONS] Commands: v2 Enable or disable v2 storage layout help Print this message or the help of the given subcommand(s) Options: -h, --help Print help (see a summary with '-h') Datadir: --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth db settings set v2 Enable or disable v2 storage layout ```bash $ reth db settings set v2 --help ``` ```txt Usage: reth db settings set v2 [OPTIONS] Arguments: [possible values: true, false] Options: -h, --help Print help (see a summary with '-h') Datadir: --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth db prune-checkpoints View or set prune checkpoints ```bash $ reth db prune-checkpoints --help ``` ```txt Usage: reth db prune-checkpoints [OPTIONS] Commands: get Get prune checkpoint(s) from database set Set a prune checkpoint for a segment help Print this message or the help of the given subcommand(s) Options: -h, --help Print help (see a summary with '-h') Datadir: --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth db prune-checkpoints get Get prune checkpoint(s) from database. ```bash $ reth db prune-checkpoints get --help ``` ```txt Usage: reth db prune-checkpoints get [OPTIONS] Options: --segment Specific segment to query. If omitted, shows all segments [possible values: sender-recovery, transaction-lookup, receipts, contract-logs, account-history, storage-history, bodies] -h, --help Print help (see a summary with '-h') Datadir: --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth db prune-checkpoints set Set a prune checkpoint for a segment. ```bash $ reth db prune-checkpoints set --help ``` ```txt Usage: reth db prune-checkpoints set [OPTIONS] --segment --mode Options: --segment The prune segment to update [possible values: sender-recovery, transaction-lookup, receipts, contract-logs, account-history, storage-history, bodies] --block-number Highest pruned block number --tx-number Highest pruned transaction number --mode Prune mode to write: full, distance, or before Possible values: - full: Prune all blocks - distance: Keep the last N blocks (requires --mode-value) - before: Prune blocks before a specific block number (requires --mode-value) --mode-value Value for distance or before mode (required unless mode is full) -h, --help Print help (see a summary with '-h') Datadir: --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth db stage-checkpoints `reth db stage-checkpoints` subcommand ```bash $ reth db stage-checkpoints --help ``` ```txt Usage: reth db stage-checkpoints [OPTIONS] Commands: get Get stage checkpoint(s) from database set Set a stage checkpoint help Print this message or the help of the given subcommand(s) Options: -h, --help Print help (see a summary with '-h') Datadir: --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth db stage-checkpoints get Get stage checkpoint(s) from database ```bash $ reth db stage-checkpoints get --help ``` ```txt Usage: reth db stage-checkpoints get [OPTIONS] Options: --stage Specific stage to query. If omitted, shows all stages [possible values: era, headers, bodies, sender-recovery, execution, prune-sender-recovery, merkle-unwind, account-hashing, storage-hashing, merkle-execute, transaction-lookup, index-storage-history, index-account-history, prune, finish] -h, --help Print help (see a summary with '-h') Datadir: --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth db stage-checkpoints set Set a stage checkpoint ```bash $ reth db stage-checkpoints set --help ``` ```txt Usage: reth db stage-checkpoints set [OPTIONS] --stage --block-number Options: --stage Stage to update [possible values: era, headers, bodies, sender-recovery, execution, prune-sender-recovery, merkle-unwind, account-hashing, storage-hashing, merkle-execute, transaction-lookup, index-storage-history, index-account-history, prune, finish] --block-number Block number to set as stage checkpoint --clear-stage-unit Clear stage-specific unit checkpoint payload -h, --help Print help (see a summary with '-h') Datadir: --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth db account-storage Gets storage size information for an account ```bash $ reth db account-storage --help ``` ```txt Usage: reth db account-storage [OPTIONS]
Arguments:
The account address to check storage for Options: -h, --help Print help (see a summary with '-h') Datadir: --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth db state Gets account state and storage at a specific block ```bash $ reth db state --help ``` ```txt Usage: reth db state [OPTIONS]
Arguments:
The account address to get state for Options: -b, --block Block number to query state at (uses current state if not provided) -l, --limit Maximum number of storage slots to display [default: 100] -f, --format Output format (table, json, csv) [default: table] [possible values: table, json, csv] -h, --help Print help (see a summary with '-h') Datadir: --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth db migrate-v2 Migrate storage layout from v1 (MDBX-only) to v2 (static files + RocksDB) ```bash $ reth db migrate-v2 --help ``` ```txt Usage: reth db migrate-v2 [OPTIONS] Options: -h, --help Print help (see a summary with '-h') Datadir: --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth download Download public node snapshots ```bash $ reth download --help ``` ```txt Usage: reth download [OPTIONS] Options: -h, --help Print help (see a summary with '-h') Datadir: --datadir The path to the data dir for all reth files and subdirectories. Defaults to the OS-specific data directory: - Linux: `$XDG_DATA_HOME/reth/` or `$HOME/.local/share/reth/` - Windows: `{FOLDERID_RoamingAppData}/reth/` - macOS: `$HOME/Library/Application Support/reth/` [default: default] --datadir.static-files The absolute path to store static files in. --datadir.rocksdb The absolute path to store `RocksDB` database in. --datadir.pprof-dumps The absolute path to store pprof dumps in. --config The path to the configuration file to use --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Database: --db.log-level Database logging level. Levels higher than "notice" require a debug build Possible values: - fatal: Enables logging for critical conditions, i.e. assertion failures - error: Enables logging for error conditions - warn: Enables logging for warning conditions - notice: Enables logging for normal but significant condition - verbose: Enables logging for verbose informational - debug: Enables logging for debug-level messages - trace: Enables logging for trace debug-level messages - extra: Enables logging for extra debug-level messages --db.exclusive Open environment in exclusive/monopolistic mode. Makes it possible to open a database on an NFS volume [possible values: true, false] --db.max-size Maximum database size (e.g., 4TB, 8TB). This sets the "map size" of the database. If the database grows beyond this limit, the node will stop with an "environment map size limit reached" error. The default value is 8TB. --db.page-size Database page size (e.g., 4KB, 8KB, 16KB). Specifies the page size used by the MDBX database. The page size determines the maximum database size. MDBX supports up to 2^31 pages, so with the default 4KB page size, the maximum database size is 8TB. To allow larger databases, increase this value to 8KB or higher. WARNING: This setting is only configurable at database creation; changing it later requires re-syncing. --db.growth-step Database growth step (e.g., 4GB, 4KB) --db.read-transaction-timeout Read transaction timeout in seconds, 0 means no timeout --db.max-readers Maximum number of readers allowed to access the database concurrently --db.sync-mode Controls how aggressively the database synchronizes data to disk --db.rocksdb-block-cache-size `RocksDB` block cache size (e.g., 512MB, 4GB). Controls the size of the in-memory LRU cache for decompressed `RocksDB` blocks. A larger cache reduces repeated decompression of hot blocks, improving read performance for history lookups. --db.balstore-cache-size Number of recent blocks to keep in the in-memory BAL store cache --db.disable-metrics Disable built-in database metrics Static Files: --static-files.blocks-per-file.headers Number of blocks per file for the headers segment --static-files.blocks-per-file.transactions Number of blocks per file for the transactions segment --static-files.blocks-per-file.receipts Number of blocks per file for the receipts segment --static-files.blocks-per-file.transaction-senders Number of blocks per file for the transaction senders segment --static-files.blocks-per-file.account-change-sets Number of blocks per file for the account changesets segment --static-files.blocks-per-file.storage-change-sets Number of blocks per file for the storage changesets segment Storage: --storage.v2 [] Enable V2 (hot/cold) storage layout for new databases. When set, new databases will be initialized with the V2 storage layout that separates hot and cold data. Existing databases always use the settings persisted in their metadata regardless of this flag. [default: true] [possible values: true, false] -u, --url Specify a snapshot URL or let the command propose a default one. Browse available snapshots at https://snapshots.reth.rs or use --list-snapshots to see them from the CLI. Available snapshot sources: - https://snapshots.reth.rs (default) - https://publicnode.com/snapshots (full nodes & testnets) If no URL is provided, the latest archive snapshot will only be proposed for Ethereum mainnet. For other chains, provide --manifest-url, --manifest-path, or -u explicitly. Local file:// URLs are also supported for extracting snapshots from disk. --manifest-url URL to a snapshot manifest.json for modular component downloads. When provided, fetches this manifest instead of discovering it from the default base URL. Useful for testing with custom or local manifests. --manifest-path Local path to a snapshot manifest.json for modular component downloads --with-txs Include all transaction static files --with-txs-since Include transaction static files starting at the specified block --with-txs-distance Include transaction static files covering the last N blocks --with-receipts Include all receipt static files --with-receipts-since Include receipt static files starting at the specified block --with-receipts-distance Include receipt static files covering the last N blocks --with-state-history Include all account and storage history static files --with-state-history-since Include account and storage history static files starting at the specified block --with-state-history-distance Include account and storage history static files covering the last N blocks --with-senders Include transaction sender static files. Requires `--with-txs` --with-rocksdb Include RocksDB index files --archive Download all available components (archive node, no pruning) --minimal Download the minimal component set (same default as --non-interactive) --full Download the full node component set (matches default full prune settings) --without-rocksdb Skip optional RocksDB indices even when archive components are selected. This affects `--archive`/`--all` and TUI archive preset (`a`). -y, --non-interactive Skip interactive component selection. Downloads the minimal set (state + headers + transactions + changesets) unless explicit --with-* flags narrow it --force Overwrite existing snapshot data by removing db, rocksdb, static_files, and reth.toml --resumable [] Enable resumable two-phase downloads (download to disk first, then extract). Archives are downloaded to a `.part` file with HTTP Range resume support before extraction. This is enabled by default because it tolerates network interruptions without restarting. Pass `--resumable=false` to stream archives directly into the extractor instead. [default: true] [possible values: true, false] --download-concurrency Maximum number of simultaneous HTTP downloads. Applies across the entire snapshot download. Small files use one slot, while large files may use multiple slots by splitting into fixed-size pieces. [default: 8] --retry-backoff Override the delay between retry attempts (for example, 500ms or 5s). Applies to requests, extraction, output verification, and segmented downloads. By default, retries wait five seconds; segmented requests use adaptive backoff. This does not change the number of attempts. --list List available snapshots and exit. Queries the snapshots API and prints all available snapshots for the selected chain, including block number, size, and manifest URL. --print-plan-json Print the selected modular archive plan as JSON and exit without downloading Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth snapshot-manifest Generate a snapshot manifest from local archive files ```bash $ reth snapshot-manifest --help ``` ```txt Usage: reth snapshot-manifest [OPTIONS] --source-datadir --output-dir Options: -d, --source-datadir Source datadir containing static files --base-url Optional base URL where archives will be hosted -o, --output-dir Output directory where chunk archives and manifest.json are written --block Block number this snapshot was taken at. If omitted, this is inferred from the source datadir's `Finish` stage checkpoint. --chain-id Chain ID [default: 1] --blocks-per-file Blocks per archive file for chunked components. If omitted, this is inferred from header static file ranges in the source datadir. -h, --help Print help (see a summary with '-h') Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth stage Manipulate individual stages ```bash $ reth stage --help ``` ```txt Usage: reth stage [OPTIONS] Commands: run Run a single stage drop Drop a stage's tables from the database dump Dumps a stage from a range into a new database unwind Unwinds a certain block range, deleting it from the database help Print this message or the help of the given subcommand(s) Options: -h, --help Print help (see a summary with '-h') Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth stage run Run a single stage. ```bash $ reth stage run --help ``` ```txt Usage: reth stage run [OPTIONS] --from --to Options: -h, --help Print help (see a summary with '-h') Datadir: --datadir The path to the data dir for all reth files and subdirectories. Defaults to the OS-specific data directory: - Linux: `$XDG_DATA_HOME/reth/` or `$HOME/.local/share/reth/` - Windows: `{FOLDERID_RoamingAppData}/reth/` - macOS: `$HOME/Library/Application Support/reth/` [default: default] --datadir.static-files The absolute path to store static files in. --datadir.rocksdb The absolute path to store `RocksDB` database in. --datadir.pprof-dumps The absolute path to store pprof dumps in. --config The path to the configuration file to use --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Database: --db.log-level Database logging level. Levels higher than "notice" require a debug build Possible values: - fatal: Enables logging for critical conditions, i.e. assertion failures - error: Enables logging for error conditions - warn: Enables logging for warning conditions - notice: Enables logging for normal but significant condition - verbose: Enables logging for verbose informational - debug: Enables logging for debug-level messages - trace: Enables logging for trace debug-level messages - extra: Enables logging for extra debug-level messages --db.exclusive Open environment in exclusive/monopolistic mode. Makes it possible to open a database on an NFS volume [possible values: true, false] --db.max-size Maximum database size (e.g., 4TB, 8TB). This sets the "map size" of the database. If the database grows beyond this limit, the node will stop with an "environment map size limit reached" error. The default value is 8TB. --db.page-size Database page size (e.g., 4KB, 8KB, 16KB). Specifies the page size used by the MDBX database. The page size determines the maximum database size. MDBX supports up to 2^31 pages, so with the default 4KB page size, the maximum database size is 8TB. To allow larger databases, increase this value to 8KB or higher. WARNING: This setting is only configurable at database creation; changing it later requires re-syncing. --db.growth-step Database growth step (e.g., 4GB, 4KB) --db.read-transaction-timeout Read transaction timeout in seconds, 0 means no timeout --db.max-readers Maximum number of readers allowed to access the database concurrently --db.sync-mode Controls how aggressively the database synchronizes data to disk --db.rocksdb-block-cache-size `RocksDB` block cache size (e.g., 512MB, 4GB). Controls the size of the in-memory LRU cache for decompressed `RocksDB` blocks. A larger cache reduces repeated decompression of hot blocks, improving read performance for history lookups. --db.balstore-cache-size Number of recent blocks to keep in the in-memory BAL store cache --db.disable-metrics Disable built-in database metrics Static Files: --static-files.blocks-per-file.headers Number of blocks per file for the headers segment --static-files.blocks-per-file.transactions Number of blocks per file for the transactions segment --static-files.blocks-per-file.receipts Number of blocks per file for the receipts segment --static-files.blocks-per-file.transaction-senders Number of blocks per file for the transaction senders segment --static-files.blocks-per-file.account-change-sets Number of blocks per file for the account changesets segment --static-files.blocks-per-file.storage-change-sets Number of blocks per file for the storage changesets segment Storage: --storage.v2 [] Enable V2 (hot/cold) storage layout for new databases. When set, new databases will be initialized with the V2 storage layout that separates hot and cold data. Existing databases always use the settings persisted in their metadata regardless of this flag. [default: true] [possible values: true, false] --metrics Enable Prometheus metrics. The metrics will be served at the given interface and port. --from The height to start at -t, --to The end of the stage --batch-size Batch size for stage execution and unwind -s, --skip-unwind Normally, running the stage requires unwinding for stages that already have been run, in order to not rewrite to the same database slots. You can optionally skip the unwinding phase if you're syncing a block range that has not been synced before. -c, --commit Commits the changes in the database. WARNING: potentially destructive. Useful when you want to run diagnostics on the database. NOTE: This flag is currently required for the headers, bodies, and execution stages because they use static files and must commit to properly unwind and run. --checkpoints Save stage checkpoints The name of the stage to run Possible values: - headers: The headers stage within the pipeline - bodies: The bodies stage within the pipeline - senders: The senders stage within the pipeline - execution: The execution stage within the pipeline - account-hashing: The account hashing stage within the pipeline - storage-hashing: The storage hashing stage within the pipeline - hashing: The account and storage hashing stages within the pipeline - merkle: The merkle stage within the pipeline - tx-lookup: The transaction lookup stage within the pipeline - account-history: The account history stage within the pipeline - storage-history: The storage history stage within the pipeline Networking: -d, --disable-discovery Disable the discovery service --disable-dns-discovery Disable the DNS discovery --disable-discv4-discovery Disable Discv4 discovery --disable-discv5-discovery Disable Discv5 discovery --disable-nat Disable Nat discovery --discovery.addr The UDP address to use for devp2p peer discovery version 4. If unset and `--net-if.experimental` is used, discv4 binds to the resolved interface address. [default: 0.0.0.0] --discovery.port The UDP port to use for devp2p peer discovery version 4 [default: 30303] --discovery.v5.addr The UDP IPv4 address to use for devp2p peer discovery version 5. Overwritten by `RLPx` address, if it's also IPv4 --discovery.v5.addr.ipv6 The UDP IPv6 address to use for devp2p peer discovery version 5. Overwritten by `RLPx` address, if it's also IPv6 --discovery.v5.port The UDP IPv4 port to use for devp2p peer discovery version 5. Not used unless `--addr` is IPv4, or `--discovery.v5.addr` is set [default: 9200] --discovery.v5.port.ipv6 The UDP IPv6 port to use for devp2p peer discovery version 5. Not used unless `--addr` is IPv6, or `--discovery.addr.ipv6` is set. If not provided, discovery V5 defaults to same port as discovery V4 (--discovery.port). [default: 9200] --discovery.v5.lookup-interval The interval in seconds at which to carry out periodic lookup queries, for the whole run of the program [default: 20] --discovery.v5.bootstrap.lookup-interval The interval in seconds at which to carry out boost lookup queries, for a fixed number of times, at bootstrap [default: 5] --discovery.v5.bootstrap.lookup-countdown The number of times to carry out boost lookup queries at bootstrap [default: 200] --trusted-peers Comma separated enode URLs or ENRs of trusted peers for P2P connections. --trusted-peers enode://abcd@192.168.0.1:30303 --trusted-only Connect to or accept from trusted peers only --bootnodes Comma separated enode URLs or ENRs for P2P discovery bootstrap. Will fall back to a network-specific default if not specified. --dns-retries Amount of DNS resolution requests retries to perform when peering [default: 0] --peers-file The path to the known peers file. Connected peers are dumped to this file on nodes shutdown, and read on startup. Cannot be used with `--no-persist-peers`. --identity Custom node identity [default: reth/-/] --p2p-secret-key Secret key to use for this node. This will also deterministically set the peer ID. If not specified, it will be set in the data dir for the chain being used. --p2p-secret-key-hex Hex encoded secret key to use for this node. This will also deterministically set the peer ID. Cannot be used together with `--p2p-secret-key`. --no-persist-peers Do not persist peers. --nat NAT resolution method (any|none|upnp|publicip|extip:\) [default: any] --addr Network listening address [default: 0.0.0.0] --port Network listening port [default: 30303] --max-outbound-peers Maximum number of outbound peers. default: 100 --max-inbound-peers Maximum number of inbound peers. default: 30 --max-peers Maximum number of total peers (inbound + outbound). Splits peers using approximately 2:1 inbound:outbound ratio. Cannot be used together with `--max-outbound-peers` or `--max-inbound-peers`. --max-tx-reqs Max concurrent `GetPooledTransactions` requests. [default: 130] --max-tx-reqs-peer Max concurrent `GetPooledTransactions` requests per peer. [default: 1] --max-seen-tx-history Max number of seen transactions to remember per peer. Default is 320 transaction hashes. [default: 320] --max-pending-imports Max number of transactions to import concurrently. [default: 4096] --pooled-tx-response-soft-limit Experimental, for usage in research. Sets the max accumulated byte size of transactions to pack in one response. Spec'd at 2MiB. [default: 2097152] --pooled-tx-pack-soft-limit Experimental, for usage in research. Sets the max accumulated byte size of transactions to request in one request. Since `RLPx` protocol version 68, the byte size of a transaction is shared as metadata in a transaction announcement (see `RLPx` specs). This allows a node to request a specific size response. By default, nodes request only 128 KiB worth of transactions, but should a peer request more, up to 2 MiB, a node will answer with more than 128 KiB. Default is 128 KiB. [default: 131072] --max-tx-pending-fetch Maximum number of announced transaction hashes to track, including inflight requests. [default: 25600] --tx-channel-memory-limit Memory limit (in bytes) for the channel that buffers transaction events flowing from the network manager to the transactions manager. When the budget is exhausted, new events are dropped (see metric `total_dropped_tx_events_at_full_capacity`). Acts as a backstop against unbounded memory growth under sustained P2P transaction flooding. [default: 1073741824] --net-if.experimental Name of network interface used to communicate with peers. If flag is set, but no value is passed, the default interface for docker `eth0` is tried. If `--discovery.addr` is left at its default, discv4 will also bind to the resolved interface address. --tx-propagation-policy Transaction Propagation Policy The policy determines which peers transactions are gossiped to. [default: All] --tx-ingress-policy Transaction ingress policy Determines which peers' transactions are accepted over P2P. [default: All] --disable-tx-gossip Disable transaction pool gossip Disables gossiping of transactions in the mempool to peers. This can be omitted for personal nodes, though providers should always opt to enable this flag. --tx-propagation-mode Sets the transaction propagation mode by determining how new pending transactions are propagated to other peers in full. Examples: sqrt, all, max:10 [default: sqrt] --required-block-hashes Comma separated list of required block hashes or block number=hash pairs. Peers that don't have these blocks will be filtered out. Format: hash or `block_number=hash` (e.g., 23115201=0x1234...) --network-id Optional network ID to override the chain specification's network ID for P2P connections --eth-max-message-size Maximum allowed ETH message size in bytes. Default is 10 MiB --netrestrict Restrict network communication to the given IP networks (CIDR masks). Comma separated list of CIDR network specifications. Only peers with IP addresses within these ranges will be allowed to connect. Example: --netrestrict "192.168.0.0/16,10.0.0.0/8" --enforce-enr-fork-id Enforce EIP-868 ENR fork ID validation for discovered peers. When enabled, peers discovered without a confirmed fork ID are not added to the peer set until their fork ID is verified via EIP-868 ENR request. This filters out peers from other networks that pollute the discovery table. Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth stage drop Drop a stage's tables from the database ```bash $ reth stage drop --help ``` ```txt Usage: reth stage drop [OPTIONS] Options: -h, --help Print help (see a summary with '-h') Datadir: --datadir The path to the data dir for all reth files and subdirectories. Defaults to the OS-specific data directory: - Linux: `$XDG_DATA_HOME/reth/` or `$HOME/.local/share/reth/` - Windows: `{FOLDERID_RoamingAppData}/reth/` - macOS: `$HOME/Library/Application Support/reth/` [default: default] --datadir.static-files The absolute path to store static files in. --datadir.rocksdb The absolute path to store `RocksDB` database in. --datadir.pprof-dumps The absolute path to store pprof dumps in. --config The path to the configuration file to use --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Database: --db.log-level Database logging level. Levels higher than "notice" require a debug build Possible values: - fatal: Enables logging for critical conditions, i.e. assertion failures - error: Enables logging for error conditions - warn: Enables logging for warning conditions - notice: Enables logging for normal but significant condition - verbose: Enables logging for verbose informational - debug: Enables logging for debug-level messages - trace: Enables logging for trace debug-level messages - extra: Enables logging for extra debug-level messages --db.exclusive Open environment in exclusive/monopolistic mode. Makes it possible to open a database on an NFS volume [possible values: true, false] --db.max-size Maximum database size (e.g., 4TB, 8TB). This sets the "map size" of the database. If the database grows beyond this limit, the node will stop with an "environment map size limit reached" error. The default value is 8TB. --db.page-size Database page size (e.g., 4KB, 8KB, 16KB). Specifies the page size used by the MDBX database. The page size determines the maximum database size. MDBX supports up to 2^31 pages, so with the default 4KB page size, the maximum database size is 8TB. To allow larger databases, increase this value to 8KB or higher. WARNING: This setting is only configurable at database creation; changing it later requires re-syncing. --db.growth-step Database growth step (e.g., 4GB, 4KB) --db.read-transaction-timeout Read transaction timeout in seconds, 0 means no timeout --db.max-readers Maximum number of readers allowed to access the database concurrently --db.sync-mode Controls how aggressively the database synchronizes data to disk --db.rocksdb-block-cache-size `RocksDB` block cache size (e.g., 512MB, 4GB). Controls the size of the in-memory LRU cache for decompressed `RocksDB` blocks. A larger cache reduces repeated decompression of hot blocks, improving read performance for history lookups. --db.balstore-cache-size Number of recent blocks to keep in the in-memory BAL store cache --db.disable-metrics Disable built-in database metrics Static Files: --static-files.blocks-per-file.headers Number of blocks per file for the headers segment --static-files.blocks-per-file.transactions Number of blocks per file for the transactions segment --static-files.blocks-per-file.receipts Number of blocks per file for the receipts segment --static-files.blocks-per-file.transaction-senders Number of blocks per file for the transaction senders segment --static-files.blocks-per-file.account-change-sets Number of blocks per file for the account changesets segment --static-files.blocks-per-file.storage-change-sets Number of blocks per file for the storage changesets segment Storage: --storage.v2 [] Enable V2 (hot/cold) storage layout for new databases. When set, new databases will be initialized with the V2 storage layout that separates hot and cold data. Existing databases always use the settings persisted in their metadata regardless of this flag. [default: true] [possible values: true, false] Possible values: - headers: The headers stage within the pipeline - bodies: The bodies stage within the pipeline - senders: The senders stage within the pipeline - execution: The execution stage within the pipeline - account-hashing: The account hashing stage within the pipeline - storage-hashing: The storage hashing stage within the pipeline - hashing: The account and storage hashing stages within the pipeline - merkle: The merkle stage within the pipeline - tx-lookup: The transaction lookup stage within the pipeline - account-history: The account history stage within the pipeline - storage-history: The storage history stage within the pipeline Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth stage dump Dumps a stage from a range into a new database ```bash $ reth stage dump --help ``` ```txt Usage: reth stage dump [OPTIONS] Commands: execution Execution stage storage-hashing `StorageHashing` stage account-hashing `AccountHashing` stage merkle Merkle stage help Print this message or the help of the given subcommand(s) Options: -h, --help Print help (see a summary with '-h') Datadir: --datadir The path to the data dir for all reth files and subdirectories. Defaults to the OS-specific data directory: - Linux: `$XDG_DATA_HOME/reth/` or `$HOME/.local/share/reth/` - Windows: `{FOLDERID_RoamingAppData}/reth/` - macOS: `$HOME/Library/Application Support/reth/` [default: default] --datadir.static-files The absolute path to store static files in. --datadir.rocksdb The absolute path to store `RocksDB` database in. --datadir.pprof-dumps The absolute path to store pprof dumps in. --config The path to the configuration file to use --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Database: --db.log-level Database logging level. Levels higher than "notice" require a debug build Possible values: - fatal: Enables logging for critical conditions, i.e. assertion failures - error: Enables logging for error conditions - warn: Enables logging for warning conditions - notice: Enables logging for normal but significant condition - verbose: Enables logging for verbose informational - debug: Enables logging for debug-level messages - trace: Enables logging for trace debug-level messages - extra: Enables logging for extra debug-level messages --db.exclusive Open environment in exclusive/monopolistic mode. Makes it possible to open a database on an NFS volume [possible values: true, false] --db.max-size Maximum database size (e.g., 4TB, 8TB). This sets the "map size" of the database. If the database grows beyond this limit, the node will stop with an "environment map size limit reached" error. The default value is 8TB. --db.page-size Database page size (e.g., 4KB, 8KB, 16KB). Specifies the page size used by the MDBX database. The page size determines the maximum database size. MDBX supports up to 2^31 pages, so with the default 4KB page size, the maximum database size is 8TB. To allow larger databases, increase this value to 8KB or higher. WARNING: This setting is only configurable at database creation; changing it later requires re-syncing. --db.growth-step Database growth step (e.g., 4GB, 4KB) --db.read-transaction-timeout Read transaction timeout in seconds, 0 means no timeout --db.max-readers Maximum number of readers allowed to access the database concurrently --db.sync-mode Controls how aggressively the database synchronizes data to disk --db.rocksdb-block-cache-size `RocksDB` block cache size (e.g., 512MB, 4GB). Controls the size of the in-memory LRU cache for decompressed `RocksDB` blocks. A larger cache reduces repeated decompression of hot blocks, improving read performance for history lookups. --db.balstore-cache-size Number of recent blocks to keep in the in-memory BAL store cache --db.disable-metrics Disable built-in database metrics Static Files: --static-files.blocks-per-file.headers Number of blocks per file for the headers segment --static-files.blocks-per-file.transactions Number of blocks per file for the transactions segment --static-files.blocks-per-file.receipts Number of blocks per file for the receipts segment --static-files.blocks-per-file.transaction-senders Number of blocks per file for the transaction senders segment --static-files.blocks-per-file.account-change-sets Number of blocks per file for the account changesets segment --static-files.blocks-per-file.storage-change-sets Number of blocks per file for the storage changesets segment Storage: --storage.v2 [] Enable V2 (hot/cold) storage layout for new databases. When set, new databases will be initialized with the V2 storage layout that separates hot and cold data. Existing databases always use the settings persisted in their metadata regardless of this flag. [default: true] [possible values: true, false] Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth stage dump execution Execution stage ```bash $ reth stage dump execution --help ``` ```txt Usage: reth stage dump execution [OPTIONS] --output-datadir --from --to Options: --output-datadir The path to the new datadir folder. -f, --from From which block -t, --to To which block -d, --dry-run If passed, it will dry-run a stage execution from the newly created database right after dumping -h, --help Print help (see a summary with '-h') Datadir: --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth stage dump storage-hashing `StorageHashing` stage ```bash $ reth stage dump storage-hashing --help ``` ```txt Usage: reth stage dump storage-hashing [OPTIONS] --output-datadir --from --to Options: --output-datadir The path to the new datadir folder. -f, --from From which block -t, --to To which block -d, --dry-run If passed, it will dry-run a stage execution from the newly created database right after dumping -h, --help Print help (see a summary with '-h') Datadir: --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth stage dump account-hashing `AccountHashing` stage ```bash $ reth stage dump account-hashing --help ``` ```txt Usage: reth stage dump account-hashing [OPTIONS] --output-datadir --from --to Options: --output-datadir The path to the new datadir folder. -f, --from From which block -t, --to To which block -d, --dry-run If passed, it will dry-run a stage execution from the newly created database right after dumping -h, --help Print help (see a summary with '-h') Datadir: --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth stage dump merkle Merkle stage ```bash $ reth stage dump merkle --help ``` ```txt Usage: reth stage dump merkle [OPTIONS] --output-datadir --from --to Options: --output-datadir The path to the new datadir folder. -f, --from From which block -t, --to To which block -d, --dry-run If passed, it will dry-run a stage execution from the newly created database right after dumping -h, --help Print help (see a summary with '-h') Datadir: --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth stage unwind Unwinds a certain block range, deleting it from the database ```bash $ reth stage unwind --help ``` ```txt Usage: reth stage unwind [OPTIONS] Commands: to-block Unwinds the database from the latest block, until the given block number or hash has been reached, that block is not included num-blocks Unwinds the database from the latest block, until the given number of blocks have been reached help Print this message or the help of the given subcommand(s) Options: -h, --help Print help (see a summary with '-h') Datadir: --datadir The path to the data dir for all reth files and subdirectories. Defaults to the OS-specific data directory: - Linux: `$XDG_DATA_HOME/reth/` or `$HOME/.local/share/reth/` - Windows: `{FOLDERID_RoamingAppData}/reth/` - macOS: `$HOME/Library/Application Support/reth/` [default: default] --datadir.static-files The absolute path to store static files in. --datadir.rocksdb The absolute path to store `RocksDB` database in. --datadir.pprof-dumps The absolute path to store pprof dumps in. --config The path to the configuration file to use --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Database: --db.log-level Database logging level. Levels higher than "notice" require a debug build Possible values: - fatal: Enables logging for critical conditions, i.e. assertion failures - error: Enables logging for error conditions - warn: Enables logging for warning conditions - notice: Enables logging for normal but significant condition - verbose: Enables logging for verbose informational - debug: Enables logging for debug-level messages - trace: Enables logging for trace debug-level messages - extra: Enables logging for extra debug-level messages --db.exclusive Open environment in exclusive/monopolistic mode. Makes it possible to open a database on an NFS volume [possible values: true, false] --db.max-size Maximum database size (e.g., 4TB, 8TB). This sets the "map size" of the database. If the database grows beyond this limit, the node will stop with an "environment map size limit reached" error. The default value is 8TB. --db.page-size Database page size (e.g., 4KB, 8KB, 16KB). Specifies the page size used by the MDBX database. The page size determines the maximum database size. MDBX supports up to 2^31 pages, so with the default 4KB page size, the maximum database size is 8TB. To allow larger databases, increase this value to 8KB or higher. WARNING: This setting is only configurable at database creation; changing it later requires re-syncing. --db.growth-step Database growth step (e.g., 4GB, 4KB) --db.read-transaction-timeout Read transaction timeout in seconds, 0 means no timeout --db.max-readers Maximum number of readers allowed to access the database concurrently --db.sync-mode Controls how aggressively the database synchronizes data to disk --db.rocksdb-block-cache-size `RocksDB` block cache size (e.g., 512MB, 4GB). Controls the size of the in-memory LRU cache for decompressed `RocksDB` blocks. A larger cache reduces repeated decompression of hot blocks, improving read performance for history lookups. --db.balstore-cache-size Number of recent blocks to keep in the in-memory BAL store cache --db.disable-metrics Disable built-in database metrics Static Files: --static-files.blocks-per-file.headers Number of blocks per file for the headers segment --static-files.blocks-per-file.transactions Number of blocks per file for the transactions segment --static-files.blocks-per-file.receipts Number of blocks per file for the receipts segment --static-files.blocks-per-file.transaction-senders Number of blocks per file for the transaction senders segment --static-files.blocks-per-file.account-change-sets Number of blocks per file for the account changesets segment --static-files.blocks-per-file.storage-change-sets Number of blocks per file for the storage changesets segment Storage: --storage.v2 [] Enable V2 (hot/cold) storage layout for new databases. When set, new databases will be initialized with the V2 storage layout that separates hot and cold data. Existing databases always use the settings persisted in their metadata regardless of this flag. [default: true] [possible values: true, false] --offline If this is enabled, then all stages except headers, bodies, and sender recovery will be unwound Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth stage unwind to-block Unwinds the database from the latest block, until the given block number or hash has been reached, that block is not included ```bash $ reth stage unwind to-block --help ``` ```txt Usage: reth stage unwind to-block [OPTIONS] Arguments: Options: -h, --help Print help (see a summary with '-h') Datadir: --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth stage unwind num-blocks Unwinds the database from the latest block, until the given number of blocks have been reached ```bash $ reth stage unwind num-blocks --help ``` ```txt Usage: reth stage unwind num-blocks [OPTIONS] Arguments: Options: -h, --help Print help (see a summary with '-h') Datadir: --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth p2p P2P Debugging utilities ```bash $ reth p2p --help ``` ```txt Usage: reth p2p [OPTIONS] Commands: header Download block header body Download block body rlpx RLPx commands bootnode Bootnode command enode Print enode identifier help Print this message or the help of the given subcommand(s) Options: -h, --help Print help (see a summary with '-h') Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth p2p header Download block header ```bash $ reth p2p header --help ``` ```txt Usage: reth p2p header [OPTIONS] Options: --retries The number of retries per request [default: 5] -h, --help Print help (see a summary with '-h') Networking: -d, --disable-discovery Disable the discovery service --disable-dns-discovery Disable the DNS discovery --disable-discv4-discovery Disable Discv4 discovery --disable-discv5-discovery Disable Discv5 discovery --disable-nat Disable Nat discovery --discovery.addr The UDP address to use for devp2p peer discovery version 4. If unset and `--net-if.experimental` is used, discv4 binds to the resolved interface address. [default: 0.0.0.0] --discovery.port The UDP port to use for devp2p peer discovery version 4 [default: 30303] --discovery.v5.addr The UDP IPv4 address to use for devp2p peer discovery version 5. Overwritten by `RLPx` address, if it's also IPv4 --discovery.v5.addr.ipv6 The UDP IPv6 address to use for devp2p peer discovery version 5. Overwritten by `RLPx` address, if it's also IPv6 --discovery.v5.port The UDP IPv4 port to use for devp2p peer discovery version 5. Not used unless `--addr` is IPv4, or `--discovery.v5.addr` is set [default: 9200] --discovery.v5.port.ipv6 The UDP IPv6 port to use for devp2p peer discovery version 5. Not used unless `--addr` is IPv6, or `--discovery.addr.ipv6` is set. If not provided, discovery V5 defaults to same port as discovery V4 (--discovery.port). [default: 9200] --discovery.v5.lookup-interval The interval in seconds at which to carry out periodic lookup queries, for the whole run of the program [default: 20] --discovery.v5.bootstrap.lookup-interval The interval in seconds at which to carry out boost lookup queries, for a fixed number of times, at bootstrap [default: 5] --discovery.v5.bootstrap.lookup-countdown The number of times to carry out boost lookup queries at bootstrap [default: 200] --trusted-peers Comma separated enode URLs or ENRs of trusted peers for P2P connections. --trusted-peers enode://abcd@192.168.0.1:30303 --trusted-only Connect to or accept from trusted peers only --bootnodes Comma separated enode URLs or ENRs for P2P discovery bootstrap. Will fall back to a network-specific default if not specified. --dns-retries Amount of DNS resolution requests retries to perform when peering [default: 0] --peers-file The path to the known peers file. Connected peers are dumped to this file on nodes shutdown, and read on startup. Cannot be used with `--no-persist-peers`. --identity Custom node identity [default: reth/-/] --p2p-secret-key Secret key to use for this node. This will also deterministically set the peer ID. If not specified, it will be set in the data dir for the chain being used. --p2p-secret-key-hex Hex encoded secret key to use for this node. This will also deterministically set the peer ID. Cannot be used together with `--p2p-secret-key`. --no-persist-peers Do not persist peers. --nat NAT resolution method (any|none|upnp|publicip|extip:\) [default: any] --addr Network listening address [default: 0.0.0.0] --port Network listening port [default: 30303] --max-outbound-peers Maximum number of outbound peers. default: 100 --max-inbound-peers Maximum number of inbound peers. default: 30 --max-peers Maximum number of total peers (inbound + outbound). Splits peers using approximately 2:1 inbound:outbound ratio. Cannot be used together with `--max-outbound-peers` or `--max-inbound-peers`. --max-tx-reqs Max concurrent `GetPooledTransactions` requests. [default: 130] --max-tx-reqs-peer Max concurrent `GetPooledTransactions` requests per peer. [default: 1] --max-seen-tx-history Max number of seen transactions to remember per peer. Default is 320 transaction hashes. [default: 320] --max-pending-imports Max number of transactions to import concurrently. [default: 4096] --pooled-tx-response-soft-limit Experimental, for usage in research. Sets the max accumulated byte size of transactions to pack in one response. Spec'd at 2MiB. [default: 2097152] --pooled-tx-pack-soft-limit Experimental, for usage in research. Sets the max accumulated byte size of transactions to request in one request. Since `RLPx` protocol version 68, the byte size of a transaction is shared as metadata in a transaction announcement (see `RLPx` specs). This allows a node to request a specific size response. By default, nodes request only 128 KiB worth of transactions, but should a peer request more, up to 2 MiB, a node will answer with more than 128 KiB. Default is 128 KiB. [default: 131072] --max-tx-pending-fetch Maximum number of announced transaction hashes to track, including inflight requests. [default: 25600] --tx-channel-memory-limit Memory limit (in bytes) for the channel that buffers transaction events flowing from the network manager to the transactions manager. When the budget is exhausted, new events are dropped (see metric `total_dropped_tx_events_at_full_capacity`). Acts as a backstop against unbounded memory growth under sustained P2P transaction flooding. [default: 1073741824] --net-if.experimental Name of network interface used to communicate with peers. If flag is set, but no value is passed, the default interface for docker `eth0` is tried. If `--discovery.addr` is left at its default, discv4 will also bind to the resolved interface address. --tx-propagation-policy Transaction Propagation Policy The policy determines which peers transactions are gossiped to. [default: All] --tx-ingress-policy Transaction ingress policy Determines which peers' transactions are accepted over P2P. [default: All] --disable-tx-gossip Disable transaction pool gossip Disables gossiping of transactions in the mempool to peers. This can be omitted for personal nodes, though providers should always opt to enable this flag. --tx-propagation-mode Sets the transaction propagation mode by determining how new pending transactions are propagated to other peers in full. Examples: sqrt, all, max:10 [default: sqrt] --required-block-hashes Comma separated list of required block hashes or block number=hash pairs. Peers that don't have these blocks will be filtered out. Format: hash or `block_number=hash` (e.g., 23115201=0x1234...) --network-id Optional network ID to override the chain specification's network ID for P2P connections --eth-max-message-size Maximum allowed ETH message size in bytes. Default is 10 MiB --netrestrict Restrict network communication to the given IP networks (CIDR masks). Comma separated list of CIDR network specifications. Only peers with IP addresses within these ranges will be allowed to connect. Example: --netrestrict "192.168.0.0/16,10.0.0.0/8" --enforce-enr-fork-id Enforce EIP-868 ENR fork ID validation for discovered peers. When enabled, peers discovered without a confirmed fork ID are not added to the peer set until their fork ID is verified via EIP-868 ENR request. This filters out peers from other networks that pollute the discovery table. Datadir: --datadir The path to the data dir for all reth files and subdirectories. Defaults to the OS-specific data directory: - Linux: `$XDG_DATA_HOME/reth/` or `$HOME/.local/share/reth/` - Windows: `{FOLDERID_RoamingAppData}/reth/` - macOS: `$HOME/Library/Application Support/reth/` [default: default] --datadir.static-files The absolute path to store static files in. --datadir.rocksdb The absolute path to store `RocksDB` database in. --datadir.pprof-dumps The absolute path to store pprof dumps in. --config The path to the configuration file to use. --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] The header number or hash Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth p2p body Download block body ```bash $ reth p2p body --help ``` ```txt Usage: reth p2p body [OPTIONS] Options: --retries The number of retries per request [default: 5] -h, --help Print help (see a summary with '-h') Networking: -d, --disable-discovery Disable the discovery service --disable-dns-discovery Disable the DNS discovery --disable-discv4-discovery Disable Discv4 discovery --disable-discv5-discovery Disable Discv5 discovery --disable-nat Disable Nat discovery --discovery.addr The UDP address to use for devp2p peer discovery version 4. If unset and `--net-if.experimental` is used, discv4 binds to the resolved interface address. [default: 0.0.0.0] --discovery.port The UDP port to use for devp2p peer discovery version 4 [default: 30303] --discovery.v5.addr The UDP IPv4 address to use for devp2p peer discovery version 5. Overwritten by `RLPx` address, if it's also IPv4 --discovery.v5.addr.ipv6 The UDP IPv6 address to use for devp2p peer discovery version 5. Overwritten by `RLPx` address, if it's also IPv6 --discovery.v5.port The UDP IPv4 port to use for devp2p peer discovery version 5. Not used unless `--addr` is IPv4, or `--discovery.v5.addr` is set [default: 9200] --discovery.v5.port.ipv6 The UDP IPv6 port to use for devp2p peer discovery version 5. Not used unless `--addr` is IPv6, or `--discovery.addr.ipv6` is set. If not provided, discovery V5 defaults to same port as discovery V4 (--discovery.port). [default: 9200] --discovery.v5.lookup-interval The interval in seconds at which to carry out periodic lookup queries, for the whole run of the program [default: 20] --discovery.v5.bootstrap.lookup-interval The interval in seconds at which to carry out boost lookup queries, for a fixed number of times, at bootstrap [default: 5] --discovery.v5.bootstrap.lookup-countdown The number of times to carry out boost lookup queries at bootstrap [default: 200] --trusted-peers Comma separated enode URLs or ENRs of trusted peers for P2P connections. --trusted-peers enode://abcd@192.168.0.1:30303 --trusted-only Connect to or accept from trusted peers only --bootnodes Comma separated enode URLs or ENRs for P2P discovery bootstrap. Will fall back to a network-specific default if not specified. --dns-retries Amount of DNS resolution requests retries to perform when peering [default: 0] --peers-file The path to the known peers file. Connected peers are dumped to this file on nodes shutdown, and read on startup. Cannot be used with `--no-persist-peers`. --identity Custom node identity [default: reth/-/] --p2p-secret-key Secret key to use for this node. This will also deterministically set the peer ID. If not specified, it will be set in the data dir for the chain being used. --p2p-secret-key-hex Hex encoded secret key to use for this node. This will also deterministically set the peer ID. Cannot be used together with `--p2p-secret-key`. --no-persist-peers Do not persist peers. --nat NAT resolution method (any|none|upnp|publicip|extip:\) [default: any] --addr Network listening address [default: 0.0.0.0] --port Network listening port [default: 30303] --max-outbound-peers Maximum number of outbound peers. default: 100 --max-inbound-peers Maximum number of inbound peers. default: 30 --max-peers Maximum number of total peers (inbound + outbound). Splits peers using approximately 2:1 inbound:outbound ratio. Cannot be used together with `--max-outbound-peers` or `--max-inbound-peers`. --max-tx-reqs Max concurrent `GetPooledTransactions` requests. [default: 130] --max-tx-reqs-peer Max concurrent `GetPooledTransactions` requests per peer. [default: 1] --max-seen-tx-history Max number of seen transactions to remember per peer. Default is 320 transaction hashes. [default: 320] --max-pending-imports Max number of transactions to import concurrently. [default: 4096] --pooled-tx-response-soft-limit Experimental, for usage in research. Sets the max accumulated byte size of transactions to pack in one response. Spec'd at 2MiB. [default: 2097152] --pooled-tx-pack-soft-limit Experimental, for usage in research. Sets the max accumulated byte size of transactions to request in one request. Since `RLPx` protocol version 68, the byte size of a transaction is shared as metadata in a transaction announcement (see `RLPx` specs). This allows a node to request a specific size response. By default, nodes request only 128 KiB worth of transactions, but should a peer request more, up to 2 MiB, a node will answer with more than 128 KiB. Default is 128 KiB. [default: 131072] --max-tx-pending-fetch Maximum number of announced transaction hashes to track, including inflight requests. [default: 25600] --tx-channel-memory-limit Memory limit (in bytes) for the channel that buffers transaction events flowing from the network manager to the transactions manager. When the budget is exhausted, new events are dropped (see metric `total_dropped_tx_events_at_full_capacity`). Acts as a backstop against unbounded memory growth under sustained P2P transaction flooding. [default: 1073741824] --net-if.experimental Name of network interface used to communicate with peers. If flag is set, but no value is passed, the default interface for docker `eth0` is tried. If `--discovery.addr` is left at its default, discv4 will also bind to the resolved interface address. --tx-propagation-policy Transaction Propagation Policy The policy determines which peers transactions are gossiped to. [default: All] --tx-ingress-policy Transaction ingress policy Determines which peers' transactions are accepted over P2P. [default: All] --disable-tx-gossip Disable transaction pool gossip Disables gossiping of transactions in the mempool to peers. This can be omitted for personal nodes, though providers should always opt to enable this flag. --tx-propagation-mode Sets the transaction propagation mode by determining how new pending transactions are propagated to other peers in full. Examples: sqrt, all, max:10 [default: sqrt] --required-block-hashes Comma separated list of required block hashes or block number=hash pairs. Peers that don't have these blocks will be filtered out. Format: hash or `block_number=hash` (e.g., 23115201=0x1234...) --network-id Optional network ID to override the chain specification's network ID for P2P connections --eth-max-message-size Maximum allowed ETH message size in bytes. Default is 10 MiB --netrestrict Restrict network communication to the given IP networks (CIDR masks). Comma separated list of CIDR network specifications. Only peers with IP addresses within these ranges will be allowed to connect. Example: --netrestrict "192.168.0.0/16,10.0.0.0/8" --enforce-enr-fork-id Enforce EIP-868 ENR fork ID validation for discovered peers. When enabled, peers discovered without a confirmed fork ID are not added to the peer set until their fork ID is verified via EIP-868 ENR request. This filters out peers from other networks that pollute the discovery table. Datadir: --datadir The path to the data dir for all reth files and subdirectories. Defaults to the OS-specific data directory: - Linux: `$XDG_DATA_HOME/reth/` or `$HOME/.local/share/reth/` - Windows: `{FOLDERID_RoamingAppData}/reth/` - macOS: `$HOME/Library/Application Support/reth/` [default: default] --datadir.static-files The absolute path to store static files in. --datadir.rocksdb The absolute path to store `RocksDB` database in. --datadir.pprof-dumps The absolute path to store pprof dumps in. --config The path to the configuration file to use. --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] The block number or hash Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth p2p rlpx RLPx commands ```bash $ reth p2p rlpx --help ``` ```txt Usage: reth p2p rlpx [OPTIONS] Commands: ping ping node help Print this message or the help of the given subcommand(s) Options: -h, --help Print help (see a summary with '-h') Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth p2p rlpx ping ping node ```bash $ reth p2p rlpx ping --help ``` ```txt Usage: reth p2p rlpx ping [OPTIONS] Arguments: The node to ping Options: -h, --help Print help (see a summary with '-h') Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth p2p bootnode Bootnode command ```bash $ reth p2p bootnode --help ``` ```txt Usage: reth p2p bootnode [OPTIONS] Options: --addr Listen address for the bootnode (default: "0.0.0.0:30301") [default: 0.0.0.0:30301] --p2p-secret-key Secret key to use for the bootnode. This will also deterministically set the peer ID. If a path is provided but no key exists at that path, a new random secret will be generated and stored there. If no path is specified, a new ephemeral random secret will be used. --nat NAT resolution method (any|none|upnp|publicip|extip:\). Can be repeated with one IPv4 and one IPv6 `extip:` to advertise a dual-stack discv5 ENR (discv4 binds a single socket and always advertises only the `--addr` family). [default: any] --v5 Also run discv5, sharing the discv4 UDP port (`--addr`) -h, --help Print help (see a summary with '-h') Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth p2p enode Print enode identifier ```bash $ reth p2p enode --help ``` ```txt Usage: reth p2p enode [OPTIONS] Arguments: Path to the secret key file for discovery Options: --ip Optional IP address to include in the enode URL. If not provided, defaults to 0.0.0.0. -h, --help Print help (see a summary with '-h') Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth config Write config to stdout ```bash $ reth config --help ``` ```txt Usage: reth config [OPTIONS] Options: --config The path to the configuration file to use. --default Show the default config -h, --help Print help (see a summary with '-h') Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth prune Prune according to the configuration without any limits ```bash $ reth prune --help ``` ```txt Usage: reth prune [OPTIONS] Options: -h, --help Print help (see a summary with '-h') Datadir: --datadir The path to the data dir for all reth files and subdirectories. Defaults to the OS-specific data directory: - Linux: `$XDG_DATA_HOME/reth/` or `$HOME/.local/share/reth/` - Windows: `{FOLDERID_RoamingAppData}/reth/` - macOS: `$HOME/Library/Application Support/reth/` [default: default] --datadir.static-files The absolute path to store static files in. --datadir.rocksdb The absolute path to store `RocksDB` database in. --datadir.pprof-dumps The absolute path to store pprof dumps in. --config The path to the configuration file to use --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Database: --db.log-level Database logging level. Levels higher than "notice" require a debug build Possible values: - fatal: Enables logging for critical conditions, i.e. assertion failures - error: Enables logging for error conditions - warn: Enables logging for warning conditions - notice: Enables logging for normal but significant condition - verbose: Enables logging for verbose informational - debug: Enables logging for debug-level messages - trace: Enables logging for trace debug-level messages - extra: Enables logging for extra debug-level messages --db.exclusive Open environment in exclusive/monopolistic mode. Makes it possible to open a database on an NFS volume [possible values: true, false] --db.max-size Maximum database size (e.g., 4TB, 8TB). This sets the "map size" of the database. If the database grows beyond this limit, the node will stop with an "environment map size limit reached" error. The default value is 8TB. --db.page-size Database page size (e.g., 4KB, 8KB, 16KB). Specifies the page size used by the MDBX database. The page size determines the maximum database size. MDBX supports up to 2^31 pages, so with the default 4KB page size, the maximum database size is 8TB. To allow larger databases, increase this value to 8KB or higher. WARNING: This setting is only configurable at database creation; changing it later requires re-syncing. --db.growth-step Database growth step (e.g., 4GB, 4KB) --db.read-transaction-timeout Read transaction timeout in seconds, 0 means no timeout --db.max-readers Maximum number of readers allowed to access the database concurrently --db.sync-mode Controls how aggressively the database synchronizes data to disk --db.rocksdb-block-cache-size `RocksDB` block cache size (e.g., 512MB, 4GB). Controls the size of the in-memory LRU cache for decompressed `RocksDB` blocks. A larger cache reduces repeated decompression of hot blocks, improving read performance for history lookups. --db.balstore-cache-size Number of recent blocks to keep in the in-memory BAL store cache --db.disable-metrics Disable built-in database metrics Static Files: --static-files.blocks-per-file.headers Number of blocks per file for the headers segment --static-files.blocks-per-file.transactions Number of blocks per file for the transactions segment --static-files.blocks-per-file.receipts Number of blocks per file for the receipts segment --static-files.blocks-per-file.transaction-senders Number of blocks per file for the transaction senders segment --static-files.blocks-per-file.account-change-sets Number of blocks per file for the account changesets segment --static-files.blocks-per-file.storage-change-sets Number of blocks per file for the storage changesets segment Storage: --storage.v2 [] Enable V2 (hot/cold) storage layout for new databases. When set, new databases will be initialized with the V2 storage layout that separates hot and cold data. Existing databases always use the settings persisted in their metadata regardless of this flag. [default: true] [possible values: true, false] Metrics: --metrics Enable Prometheus metrics. The metrics will be served at the given interface and port. --metrics.prometheus.push.url URL for pushing Prometheus metrics to a push gateway. If set, the node will periodically push metrics to the specified push gateway URL. --metrics.prometheus.push.interval Interval in seconds for pushing metrics to push gateway. Default: 5 seconds [default: 5] Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ``` # reth re-execute Re-execute blocks in parallel to verify historical sync correctness ```bash $ reth re-execute --help ``` ```txt Usage: reth re-execute [OPTIONS] Options: -h, --help Print help (see a summary with '-h') Datadir: --datadir The path to the data dir for all reth files and subdirectories. Defaults to the OS-specific data directory: - Linux: `$XDG_DATA_HOME/reth/` or `$HOME/.local/share/reth/` - Windows: `{FOLDERID_RoamingAppData}/reth/` - macOS: `$HOME/Library/Application Support/reth/` [default: default] --datadir.static-files The absolute path to store static files in. --datadir.rocksdb The absolute path to store `RocksDB` database in. --datadir.pprof-dumps The absolute path to store pprof dumps in. --config The path to the configuration file to use --chain The chain this node is running. Possible values are either a built-in chain or the path to a chain specification file. Built-in chains: mainnet, sepolia, holesky, hoodi, dev [default: mainnet] Database: --db.log-level Database logging level. Levels higher than "notice" require a debug build Possible values: - fatal: Enables logging for critical conditions, i.e. assertion failures - error: Enables logging for error conditions - warn: Enables logging for warning conditions - notice: Enables logging for normal but significant condition - verbose: Enables logging for verbose informational - debug: Enables logging for debug-level messages - trace: Enables logging for trace debug-level messages - extra: Enables logging for extra debug-level messages --db.exclusive Open environment in exclusive/monopolistic mode. Makes it possible to open a database on an NFS volume [possible values: true, false] --db.max-size Maximum database size (e.g., 4TB, 8TB). This sets the "map size" of the database. If the database grows beyond this limit, the node will stop with an "environment map size limit reached" error. The default value is 8TB. --db.page-size Database page size (e.g., 4KB, 8KB, 16KB). Specifies the page size used by the MDBX database. The page size determines the maximum database size. MDBX supports up to 2^31 pages, so with the default 4KB page size, the maximum database size is 8TB. To allow larger databases, increase this value to 8KB or higher. WARNING: This setting is only configurable at database creation; changing it later requires re-syncing. --db.growth-step Database growth step (e.g., 4GB, 4KB) --db.read-transaction-timeout Read transaction timeout in seconds, 0 means no timeout --db.max-readers Maximum number of readers allowed to access the database concurrently --db.sync-mode Controls how aggressively the database synchronizes data to disk --db.rocksdb-block-cache-size `RocksDB` block cache size (e.g., 512MB, 4GB). Controls the size of the in-memory LRU cache for decompressed `RocksDB` blocks. A larger cache reduces repeated decompression of hot blocks, improving read performance for history lookups. --db.balstore-cache-size Number of recent blocks to keep in the in-memory BAL store cache --db.disable-metrics Disable built-in database metrics Static Files: --static-files.blocks-per-file.headers Number of blocks per file for the headers segment --static-files.blocks-per-file.transactions Number of blocks per file for the transactions segment --static-files.blocks-per-file.receipts Number of blocks per file for the receipts segment --static-files.blocks-per-file.transaction-senders Number of blocks per file for the transaction senders segment --static-files.blocks-per-file.account-change-sets Number of blocks per file for the account changesets segment --static-files.blocks-per-file.storage-change-sets Number of blocks per file for the storage changesets segment Storage: --storage.v2 [] Enable V2 (hot/cold) storage layout for new databases. When set, new databases will be initialized with the V2 storage layout that separates hot and cold data. Existing databases always use the settings persisted in their metadata regardless of this flag. [default: true] [possible values: true, false] --from The height to start at [default: 1] --to The height to end at. Defaults to the latest block --num-tasks Number of tasks to run in parallel. Defaults to the number of available CPUs --blocks-per-chunk Number of blocks each worker processes before grabbing the next chunk [default: 5000] --skip-invalid-blocks Continues with execution when an invalid block is encountered and collects these blocks JIT: --jit Enable JIT compilation of EVM bytecode --jit.hot-threshold Number of observed misses before a bytecode is promoted to JIT compilation [default: 8] --jit.worker-count Number of JIT compilation worker threads --jit.channel-capacity Capacity of the lookup-observed event channel. Events are silently dropped when the channel is full [default: 4096] --jit.max-pending-jobs Maximum number of pending JIT compilation jobs [default: 2048] --jit.max-bytecode-len Maximum bytecode length eligible for JIT compilation. Contracts with bytecode larger than this are never promoted to JIT. 0 means no limit [default: 0] --jit.code-cache-bytes Maximum total resident compiled code size in bytes. When exceeded, the backend evicts least-recently-used entries. 0 means no limit [default: 1073741824] --jit.idle-evict-duration Duration after which a compiled program with no lookup hits is evicted [default: 1h] --jit.debug Enable compiler debug dumps. IR, assembly, and bytecode are written to `/jit///` for each compiled contract. Note that this is not ever cleaned up, and has a non negligible performance overhead. Logging: --log.stdout.format The format to use for logs written to stdout Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.stdout.filter The filter to use for logs written to stdout [default: ""] --log.file.format The format to use for logs written to the log file Possible values: - json: Represents JSON formatting for logs. This format outputs log records as JSON objects, making it suitable for structured logging - log-fmt: Represents logfmt (key=value) formatting for logs. This format is concise and human-readable, typically used in command-line applications - terminal: Represents terminal-friendly formatting for logs [default: terminal] --log.file.filter The filter to use for logs written to the log file [default: debug] --log.file.directory The path to put log files in [default: /logs] --log.file.name The prefix name of the log files [default: reth.log] --log.file.max-size The maximum size (in MB) of one log file [default: 200] --log.file.max-files The maximum amount of log files that will be stored. If set to 0, background file logging is disabled. Default: 5 for `node` command, 0 for non-node utility subcommands. --log.journald Write logs to journald --log.journald.filter The filter to use for logs written to journald [default: error] --color Sets whether or not the formatter emits ANSI terminal escape codes for colors and other text formatting Possible values: - always: Colors on - auto: Auto-detect - never: Colors off [default: always] --logs-otlp[=] Enable `Opentelemetry` logs export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/logs` - gRPC: `http://localhost:4317` Example: --logs-otlp=http://collector:4318/v1/logs [env: OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=] --logs-otlp.filter Set a filter directive for the OTLP logs exporter. This controls the verbosity of logs sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --logs-otlp.filter=info,reth=debug Defaults to INFO if not specified. [default: info] Display: -v, --verbosity... Set the minimum log level. -v Errors -vv Warnings -vvv Info -vvvv Debug -vvvvv Traces (warning: very verbose!) -q, --quiet Silence all log output Tracing: --tracing-otlp[=] Enable `Opentelemetry` tracing export to an OTLP endpoint. If no value provided, defaults based on protocol: - HTTP: `http://localhost:4318/v1/traces` - gRPC: `http://localhost:4317` Example: --tracing-otlp=http://collector:4318/v1/traces [env: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=] --tracing-otlp-protocol OTLP transport protocol to use for exporting traces and logs. - `http`: expects endpoint path to end with `/v1/traces` or `/v1/logs` - `grpc`: expects endpoint without a path Defaults to HTTP if not specified. Possible values: - http: HTTP/Protobuf transport, port 4318, requires `/v1/traces` path - grpc: gRPC transport, port 4317 [env: OTEL_EXPORTER_OTLP_PROTOCOL=] [default: http] --tracing-otlp.filter Set a filter directive for the OTLP tracer. This controls the verbosity of spans and events sent to the OTLP endpoint. It follows the same syntax as the `RUST_LOG` environment variable. Example: --tracing-otlp.filter=info,reth=debug,hyper_util=off Defaults to TRACE if not specified. [default: debug] --tracing-otlp.sample-ratio Trace sampling ratio to control the percentage of traces to export. Valid range: 0.0 to 1.0 - 1.0, default: Sample all traces - 0.01: Sample 1% of traces - 0.0: Disable sampling Example: --tracing-otlp.sample-ratio=0.0. [env: OTEL_TRACES_SAMPLER_ARG=] ```
Ethereum execution client and node SDK

Reth

Reth chip on a dark circuit grid
Secure, performant, and modular blockchain SDK and node.
Production-grade Rust infrastructure for running nodes, building chains, and extending Ethereum.
Quickstart

Run or build with Reth

Start with the production binary, or use the same modular components to assemble your own Ethereum-compatible node.
:::code-group ```bash [Run a Node] # Install the binary brew install paradigmxyz/brew/reth # Run the node with JSON-RPC enabled reth node --http --http.api eth,trace ``` ```rust [Build a Node] // .. snip .. let handle = node_builder .with_types::() .with_components(EthereumNode::components()) .with_add_ons(EthereumAddOns::default()) .launch() .await?; ``` :::
Institutional SecurityRun reliable staking nodes trusted by Coinbase Staking. PerformanceSync faster with optimized transaction processing and storage. CustomizableBuild custom nodes with tailored transaction handling. ExtensibleBuild indexers and offchain services with ExExs.
Operators and infra teams

Trusted by the Best

Leading infra companies use Reth for MEV applications, staking, RPC services, and zero-knowledge proofs.
Built with Reth SDK

Built with Reth SDK

Teams use Reth's modular architecture to build nodes from existing components while keeping maintenance overhead low.
Supporters

Supporters

# History Expiry In this chapter, we will learn how to use tools for dealing with historical data, it's import, export and removal. We will use [reth cli](/cli/cli) to import and export historical data. ## Enabling Pre-merge history expiry Opting in into pre-merge history expiry will remove all pre-merge transaction/receipt data (static files) for mainnet and sepolia. For new and existing nodes: Use the flags `--prune.bodies.pre-merge` `--prune.receipts.pre-merge` See also [Partial history expiry announcement](https://blog.ethereum.org/2025/07/08/partial-history-exp) ## File format The historical data is packaged and distributed in files of special formats with different names, all of which are based on [e2store](https://github.com/status-im/nimbus-eth2/blob/613f4a9a50c9c4bd8568844eaffb3ac15d067e56/docs/e2store.md#introduction). The most important ones are the **ERA1**, which deals with block range from genesis until the last pre-merge block, and **ERA**, which deals with block range from the merge onwards. See the following specifications for more details : * [E2store specification](https://github.com/eth-clients/e2store-format-specs) * [ERA1 specification](https://github.com/eth-clients/e2store-format-specs/blob/main/formats/era1.md) * [ERA specification](https://github.com/eth-clients/e2store-format-specs/blob/main/formats/era.md) The contents of these archives is an ordered sequence of blocks. We're mostly concerned with headers and transactions. For ERA1, there is 8192 blocks per file except for the last one, i.e. the one containing pre-merge block, which can be less than that. ## Import In this section we discuss how to get blocks from ERA1 files. ### Automatic sync If enabled, importing blocks from ERA1 files can be done automatically with no manual steps required. #### Enabling the ERA stage The import from ERA1 files within the pre-merge block range is included in the [reth node](/cli/reth/node) synchronization pipeline. It is disabled by default. To enable it, pass the `--era.enable` flag when running the [`node`](/cli/reth/node) command. The benefit of using this option is significant increase in the synchronization speed for the headers and mainly bodies stage of the pipeline within the ERA1 block range. We encourage you to use it! Eventually, it will become enabled by default. #### Using the ERA stage When enabled, the import from ERA1 files runs as its own separate stage before all others. It is an optional stage that is doing the work of headers and bodies stage at a significantly higher speed. The checkpoints of these stages are shifted by the ERA stage. ### Manual import If you want to import block headers and transactions from ERA1 files without running the synchronization pipeline, you may use the [`import-era`](/cli/reth/import-era) command. ### Options Both ways of importing the ERA1 files have the same options because they use the same underlying subsystems. No options are mandatory. #### Sources There are two kinds of data sources for the ERA1 import. * Remote from an HTTP URL. Use the option `--era.url` with an ERA1 hosting provider URL. * Local from a file-system directory. Use the option `--era.path` with a directory containing ERA1 files. Both options cannot be used at the same time. If no option is specified, the remote source is used with a URL derived from the chain ID. Only Mainnet and Sepolia have ERA1 files. If the node is running on a different chain, no source is provided and nothing is imported. ## Export In this section we discuss how to export blocks data into ERA1 files. ### Manual export You can manually export block data from your database to ERA1 files using the [`export-era`](/cli/reth/export-era) command. The CLI reads block headers, bodies, and receipts from your local database and packages them into the standardized ERA1 format with up to 8,192 blocks per file. #### Set up The export command allows you to specify: * Block ranges with `--first-block-number` and `--last-block-number` * Output directory with `--path` for the export destination * File size limits with `--max-blocks-per-file` with a maximum of 8,192 blocks per ERA1 file # `reth` Namespace The `reth` API provides reth-specific methods that are not part of the standard Ethereum JSON-RPC specification. These methods offer additional functionality for monitoring balance changes and subscribing to chain state notifications. ## `reth_getBalanceChangesInBlock` Returns all ETH balance changes that occurred in a specific block. This method is useful for tracking value transfers, mining rewards, and other balance modifications without having to trace every transaction in a block. The method accepts a block identifier (number, hash, or tag like `latest`) and returns a map of addresses to their new balances. | Client | Method invocation | | ------ | -------------------------------------------------------------- | | RPC | `{"method": "reth_getBalanceChangesInBlock", "params": [block]}` | ### Example ```js // > {"jsonrpc":"2.0","id":1,"method":"reth_getBalanceChangesInBlock","params":["latest"]} {"jsonrpc":"2.0","id":1,"result":{"0x95222290dd7278aa3ddd389cc1e1d165cc4bafe5":"0x1bc16d674ec80000","0x388c818ca8b9251b393131c08a736a67ccb19297":"0x0"}} ``` The result is a mapping of addresses to their new balance after the block was executed. Only addresses whose balance changed during block execution are included. ## `reth_subscribeChainNotifications`, `reth_unsubscribeChainNotifications` Subscribe to canonical chain state notifications. This creates a subscription that emits notifications whenever the canonical chain state changes. Like other subscription methods, this returns the ID of the subscription, which is then used in all events subsequently. To unsubscribe from chain notifications, call `reth_unsubscribeChainNotifications` with the subscription ID. | Client | Method invocation | | ------ | -------------------------------------------------------------------------- | | RPC | `{"method": "reth_subscribeChainNotifications", "params": []}` | | RPC | `{"method": "reth_unsubscribeChainNotifications", "params": [subscription_id]}` | ### Event Types The subscription emits events with the following structure: ```json { "jsonrpc": "2.0", "method": "reth_subscription", "params": { "subscription": "0xcd0c3e8af590364c09d0fa6a1210faf5", "result": { "Commit": { // or "Reorg" "new": { // Chain segment with blocks, receipts, etc. }, "old": { // Only present for "Reorg": chain segment that was reverted } } } } } ``` * **Commit**: New blocks are added to the canonical chain. Contains only `new` with the committed chain segment. * **Reorg**: Chain reorganization occurred. Contains both `old` (reverted blocks) and `new` (replacement blocks). This is particularly useful for applications that need to react immediately to chain state changes, such as indexers, monitoring tools, or ExEx (Execution Extensions). ### Example ```js // > {"jsonrpc":"2.0","id":1,"method":"reth_subscribeChainNotifications","params":[]} // responds with subscription ID {"jsonrpc":"2.0","id":1,"result":"0xcd0c3e8af590364c09d0fa6a1210faf5"} // Example notification when new blocks are committed {"jsonrpc":"2.0","method":"reth_subscription","params":{"subscription":"0xcd0c3e8af590364c09d0fa6a1210faf5","result":{"Commit":{"new":{"blocks":[...],"receipts":[...],"first_block":1000,"last_block":1000}}}}} // Unsubscribe // > {"jsonrpc":"2.0","id":2,"method":"reth_unsubscribeChainNotifications","params":["0xcd0c3e8af590364c09d0fa6a1210faf5"]} {"jsonrpc":"2.0","id":2,"result":true} ``` :::note This subscription is only available over WebSocket and IPC transports, as HTTP does not support server-initiated messages. ::: ## `reth_subscribePersistedBlock`, `reth_unsubscribePersistedBlock` Subscribe to persisted block notifications. This creates a subscription that emits a notification with the block number and hash when a new block is persisted to disk. Like other subscription methods, this returns the ID of the subscription, which is then used in all events subsequently. To unsubscribe from persisted block notifications, call `reth_unsubscribePersistedBlock` with the subscription ID. | Client | Method invocation | | ------ | -------------------------------------------------------------------------- | | RPC | `{"method": "reth_subscribePersistedBlock", "params": []}` | | RPC | `{"method": "reth_unsubscribePersistedBlock", "params": [subscription_id]}` | ### Example ```js // > {"jsonrpc":"2.0","id":1,"method":"reth_subscribePersistedBlock","params":[]} // responds with subscription ID {"jsonrpc":"2.0","id":1,"result":"0xab1c2d3e4f590364c09d0fa6a1210faf5"} // Example notification when a block is persisted {"jsonrpc":"2.0","method":"reth_subscription","params":{"subscription":"0xab1c2d3e4f590364c09d0fa6a1210faf5","result":{"number":"0x1a2b3c","hash":"0x1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef"}}} // Unsubscribe // > {"jsonrpc":"2.0","id":2,"method":"reth_unsubscribePersistedBlock","params":["0xab1c2d3e4f590364c09d0fa6a1210faf5"]} {"jsonrpc":"2.0","id":2,"result":true} ``` :::note This subscription is only available over WebSocket and IPC transports, as HTTP does not support server-initiated messages. ::: # Networks # Node Components Reth's modular architecture allows developers to customize and extend individual components of the node. Each component serves a specific purpose and can be replaced or modified to suit your needs. ## Architecture Overview A Reth node consists of several key components that work together and can interact with each other: ```mermaid graph LR Network[Network] --> Pool[Transaction Pool] Network --> Consensus[Consensus] Pool --> DB[(Database)] Consensus --> EVM EVM --> DB[(Database)] RPC[RPC Server] --> Pool RPC --> DB RPC --> EVM ``` ## Core Components ### [Network](/sdk/node-components/network) Handles P2P communication, peer discovery, and block/transaction propagation. The network component is responsible for: * Peer discovery and management * Transaction gossip * State synchronization (downloading blocks) * Protocol message handling ### [Transaction Pool](/sdk/node-components/pool) Manages pending transactions before they're included in blocks: * Transaction validation * Ordering and prioritization * Transaction replacement logic * Pool size management and eviction ### [Consensus](/sdk/node-components/consensus) Validates blocks according to protocol rules: * Header validation (e.g. gas limit, base fee) * Block body validation (e.g. transaction root) ### [EVM](/sdk/node-components/evm) Executes transactions and manages state transitions: * Block execution * Transaction execution * Block building ### [RPC](/sdk/node-components/rpc) Provides external API access to the node: * Standard Ethereum JSON-RPC methods * Custom endpoints * WebSocket subscriptions ## Component Customization Each component can be customized through Reth's builder pattern. You can replace individual components while keeping the defaults for others using `EthereumNode::components()`: ```rust use reth_ethereum::{ cli::interface::Cli, node::{ node::EthereumAddOns, EthereumNode, }, }; fn main() { Cli::parse_args() .run(|builder, _| async move { let handle = builder // Use the default ethereum node types .with_types::() // Configure the components of the node // Use default ethereum components but replace specific ones .with_components( EthereumNode::components() // Custom transaction pool .pool(CustomPoolBuilder::default()) // Other customizable components: // .network(CustomNetworkBuilder::default()) // .executor(CustomExecutorBuilder::default()) // .consensus(CustomConsensusBuilder::default()) // .payload(CustomPayloadBuilder::default()) ) .with_add_ons(EthereumAddOns::default()) .launch() .await?; handle.wait_for_node_exit().await }) .unwrap(); } ``` Custom component builders must implement their respective traits (`PoolBuilder`, `NetworkBuilder`, `ExecutorBuilder`, `ConsensusBuilder`, `PayloadServiceBuilder`). Each trait requires implementing an async `build_*` method that receives a `BuilderContext` with access to node configuration, providers, and task executors. For complete working examples with full trait implementations, see: * [custom-node-components](https://github.com/paradigmxyz/reth/tree/main/examples/custom-node-components) - Custom transaction pool * [custom-payload-builder](https://github.com/paradigmxyz/reth/tree/main/examples/custom-payload-builder) - Custom payload builder * [custom-evm](https://github.com/paradigmxyz/reth/tree/main/examples/custom-evm) - Custom EVM configuration ## Component Lifecycle Components follow a specific lifecycle starting from node builder initialization to shutdown: 1. **Initialization**: Components are created with their dependencies 2. **Configuration**: Settings and parameters are applied 3. **Startup**: Components begin their main operations 4. **Runtime**: Components process requests and events 5. **Shutdown**: Graceful cleanup and resource release ## Next Steps Explore each component in detail: * [Network Component](/sdk/node-components/network) - P2P and synchronization * [Transaction Pool](/sdk/node-components/pool) - Mempool management * [Consensus](/sdk/node-components/consensus) - Block validation * [EVM](/sdk/node-components/evm) - Transaction execution * [RPC](/sdk/node-components/rpc) - External APIs # Troubleshooting This page tries to answer how to deal with the most popular issues. * [Troubleshooting](#troubleshooting) * [Database](#database) * [Docker](#docker) * [Error code 13](#error-code-13) * [Slow database inserts and updates](#slow-database-inserts-and-updates) * [Compact the database](#compact-the-database) * [Re-sync from scratch](#re-sync-from-scratch) * [Database write error](#database-write-error) * [Concurrent database access error (using containers/Docker)](#concurrent-database-access-error-using-containersdocker) * [Hardware Performance Testing](#hardware-performance-testing) * [Disk Speed Testing with IOzone](#disk-speed-testing-with-iozone) ## Database ### Docker Externally accessing a `datadir` inside a named docker volume will usually come with folder/file ownership/permissions issues. **It is not recommended** to use the path to the named volume as it will trigger an error code 13. For example, `RETH_DATADIR=/var/lib/docker/volumes/named_volume/_data/eth cargo run -p db-access` is **DISCOURAGED** and a mounted volume with the right permissions should be used instead. ### Error code 13 `the environment opened in read-only code: 13` Externally accessing a database in a read-only folder is not supported, **UNLESS** there's no `mdbx.lck` present, and it's called with `exclusive` on calling `open_db_read_only`. Meaning that there's no node syncing concurrently. If the error persists, ensure that you have the right `rx` permissions on the `datadir` **and its parent** folders. Eg. the following command should succeed: ```bash,ignore stat /full/path/datadir ``` ### Slow database inserts and updates If you're: 1. Running behind the tip 2. Have slow canonical commit time according to the `Canonical Commit Latency Time` chart on [Grafana dashboard](/run/monitoring#prometheus--grafana) (more than 2-3 seconds) 3. Seeing warnings in your logs such as ```console 2023-11-08T15:17:24.789731Z WARN providers::db: Transaction insertion took too long block_number=18528075 tx_num=2150227643 hash=0xb7de1d6620efbdd3aa8547c47a0ff09a7fd3e48ba3fd2c53ce94c6683ed66e7c elapsed=6.793759034s ``` then most likely you're experiencing issues with the [database freelist](https://github.com/paradigmxyz/reth/issues/5228). To confirm it, check if the values on the `Freelist` chart on [Grafana dashboard](/run/monitoring#prometheus--grafana) is greater than 10M. Currently, there are two main ways to fix this issue. #### Compact the database It will take around 5-6 hours and require **additional** disk space located on the same or different drive equal to the [freshly synced node](/run/system-requirements). 1. Clone Reth ```bash git clone https://github.com/paradigmxyz/reth cd reth ``` 2. Build database debug tools ```bash make db-tools ``` 3. Run compaction (this step will take 5-6 hours, depending on the I/O speed) ```bash ./db-tools/mdbx_copy -c $(reth db path) reth_compact.dat ``` 4. Stop Reth 5. Backup original database ```bash mv $(reth db path)/mdbx.dat reth_old.dat ``` 6. Move compacted database in place of the original database ```bash mv reth_compact.dat $(reth db path)/mdbx.dat ``` 7. Start Reth 8. Confirm that the values on the `Freelist` chart are near zero and the values on the `Canonical Commit Latency Time` chart is less than 1 second. 9. Delete original database ```bash rm reth_old.dat ``` #### Re-sync from scratch It will take the same time as initial sync. 1. Stop Reth 2. Drop the database using [`reth db drop`](/cli/reth/db/drop) 3. Start reth ### Database write error If you encounter irrecoverable database-related errors, in most cases it's related to the RAM/NVMe/SSD you use. For example: ```console Error: A stage encountered an irrecoverable error. Caused by: 0: An internal database error occurred: Database write error code: -30796 1: Database write error code: -30796 ``` or ```console Error: A stage encountered an irrecoverable error. Caused by: 0: An internal database error occurred: Database read error code: -30797 1: Database read error code: -30797 ``` 1. Check your memory health: use [memtest86+](https://www.memtest.org/) or [memtester](https://linux.die.net/man/8/memtester). If your memory is faulty, it's better to resync the node on different hardware. 2. Check database integrity: ```bash git clone https://github.com/paradigmxyz/reth cd reth make db-tools ./db-tools/mdbx_chk $(reth db path)/mdbx.dat | tee mdbx_chk.log ``` If `mdbx_chk` has detected any errors, please [open an issue](https://github.com/paradigmxyz/reth/issues) and post the output from the `mdbx_chk.log` file. ### Concurrent database access error (using containers/Docker) If you encounter an error while accessing the database from multiple processes and you are using multiple containers or a mix of host and container(s), it is possible the error is related to `PID` namespaces. You might see one of the following error messages. ```console mdbx:0: panic: Assertion `osal_rdt_unlock() failed: err 1' failed. ``` or ```console pthread_mutex_lock.c:438: __pthread_mutex_lock_full: Assertion `e != ESRCH || !robust' failed ``` If you are using Docker, a possible solution is to run all database-accessing containers with `--pid=host` flag. For more information, check out the `Containers` section in the [libmdbx README](https://github.com/erthink/libmdbx#containers). ## Hardware Performance Testing If you're experiencing degraded performance, it may be related to hardware issues. Below are some tools and tests you can run to evaluate your hardware performance. If your hardware performance is significantly lower than these reference numbers, it may explain degraded node performance. Consider upgrading your hardware or investigating potential issues with your current setup. ### Disk Speed Testing with [IOzone](https://linux.die.net/man/1/iozone) 1. Test disk speed: ```bash iozone -e -t1 -i0 -i2 -r1k -s1g /tmp ``` Reference numbers (on Latitude c3.large.x86): ```console Children see throughput for 1 initial writers = 907733.81 kB/sec Parent sees throughput for 1 initial writers = 907239.68 kB/sec Children see throughput for 1 rewriters = 1765222.62 kB/sec Parent sees throughput for 1 rewriters = 1763433.35 kB/sec Children see throughput for 1 random readers = 1557497.38 kB/sec Parent sees throughput for 1 random readers = 1554846.58 kB/sec Children see throughput for 1 random writers = 984428.69 kB/sec Parent sees throughput for 1 random writers = 983476.67 kB/sec ``` 2. Test disk speed with memory-mapped files: ```bash iozone -B -G -e -t1 -i0 -i2 -r1k -s1g /tmp ``` Reference numbers (on Latitude c3.large.x86): ```console Children see throughput for 1 initial writers = 56471.06 kB/sec Parent sees throughput for 1 initial writers = 56365.14 kB/sec Children see throughput for 1 rewriters = 241650.69 kB/sec Parent sees throughput for 1 rewriters = 239067.96 kB/sec Children see throughput for 1 random readers = 6833161.00 kB/sec Parent sees throughput for 1 random readers = 5597659.65 kB/sec Children see throughput for 1 random writers = 220248.53 kB/sec Parent sees throughput for 1 random writers = 219112.26 kB/sec ``` ### RAM Speed and Health Testing 1. Check RAM speed with [lshw](https://linux.die.net/man/1/lshw): ```bash sudo lshw -short -C memory ``` Look for the frequency in the output. Reference output: ```console H/W path Device Class Description ================================================================ /0/24/0 memory 64GiB DIMM DDR4 Synchronous Registered (Buffered) 3200 MHz (0.3 ns) /0/24/1 memory 64GiB DIMM DDR4 Synchronous Registered (Buffered) 3200 MHz (0.3 ns) ... ``` 2. Test RAM health with [memtester](https://linux.die.net/man/8/memtester): ```bash sudo memtester 10G ``` This will take a while. You can test with a smaller amount first: ```bash sudo memtester 1G 1 ``` All checks should report "ok". # Caveats OP-Mainnet # How to Modify an Existing Node This guide demonstrates how to extend a Reth node with custom functionality, including adding RPC endpoints, modifying transaction validation, and implementing custom services. ## Adding Custom RPC Endpoints One of the most common modifications is adding custom RPC methods to expose additional functionality. This allows you to extend the standard Ethereum RPC API with your own methods while maintaining compatibility with existing tools and clients. ### Basic Custom RPC Module The following example shows how to add a custom RPC namespace called `txpoolExt` that provides additional transaction pool functionality. This example is based on the `node-custom-rpc` example in the Reth repository. #### Project Structure First, create a new binary crate with the following dependencies in your `Cargo.toml`: ```toml [package] name = "node-custom-rpc" version = "0.1.0" edition = "2021" [[bin]] name = "node-custom-rpc" path = "src/main.rs" [dependencies] clap = { version = "4.0", features = ["derive"] } jsonrpsee = { version = "0.22", features = ["macros", "server", "http-server", "ws-server"] } reth-ethereum = { path = "../../crates/ethereum" } tokio = { version = "1.0", features = ["full"] } ``` #### Implementation The complete implementation can be found in the [node-custom-rpc example](https://github.com/paradigmxyz/reth/tree/main/examples/node-custom-rpc). Here's a summary of the key components: 1. **RPC Interface**: Define your custom RPC methods using `jsonrpsee` proc macros with a custom namespace 2. **RPC Handler**: Implement the trait with access to node components like the transaction pool 3. **CLI Extension**: Add custom CLI arguments to control your extensions 4. **Node Integration**: Use `extend_rpc_modules` to integrate your custom functionality #### Running the Custom Node Build and run your custom node with the extension enabled: ```bash cargo run -p node-custom-rpc -- node --http --ws --enable-ext ``` This will start a Reth node with your custom RPC methods available on both HTTP and WebSocket transports. #### Testing the Custom RPC Methods You can test your custom RPC methods using tools like `cast` from the Foundry suite: ```bash # Get transaction count cast rpc txpoolExt_transactionCount # Clear the transaction pool cast rpc txpoolExt_clearTxpool # Subscribe to transaction count updates (WebSocket only) cast rpc txpoolExt_subscribeTransactionCount ``` ### Key Concepts 1. **RPC Namespaces**: Use the `namespace` parameter in the `rpc` macro to create a custom namespace for your methods. 2. **Node Context**: Access node components like the transaction pool through the `ctx` parameter in `extend_rpc_modules`. 3. **Transport Integration**: Your custom RPC methods are automatically available on all configured transports (HTTP, WebSocket, IPC). 4. **CLI Integration**: Extend the default Reth CLI with your own arguments to control custom functionality. 5. **Error Handling**: Use `RpcResult` for methods that can fail and handle errors appropriately. ## Next Steps * Explore [Standalone Components](/sdk/examples/standalone-components) for direct blockchain interaction * Review [Type System](/sdk/typesystem/block) for working with blockchain data * Check out the [node-custom-rpc example](https://github.com/paradigmxyz/reth/tree/main/examples/node-custom-rpc) for the complete implementation # Using Standalone Components This guide demonstrates how to use Reth components independently without running a full node. This is useful for building tools, analyzers, indexers, or any application that needs direct access to blockchain data. ## Direct Database Access Reth uses MDBX as its primary database backend, storing blockchain data in a structured format. You can access this database directly from external processes for read-only operations, which is useful for analytics, indexing, or building custom tools. ### Understanding the Database Architecture Reth's storage architecture consists of two main components: 1. **MDBX Database**: Primary storage for blockchain state, headers, bodies, receipts, and indices 2. **Static Files**: Immutable historical data (headers, bodies, receipts, transactions) stored in compressed files for better performance Both components must be accessed together for complete data access. ### Database Location The database is stored in the node's data directory: * **Default location**: `$HOME/.local/share/reth/mainnet/db` (Linux/macOS) or `%APPDATA%\reth\mainnet\db` (Windows) * **Custom location**: Set with `--datadir` flag when running reth * **Static files**: Located in `/static_files` subdirectory ### Opening the Database from External Processes When accessing the database while a node is running, you **must** open it in read-only mode to prevent corruption and conflicts. #### Using the High-Level API The safest way to access the database is through Reth's provider factory: ```rust use reth_ethereum::node::EthereumNode; use reth_ethereum::chainspec::MAINNET; // Open with automatic configuration (requires a Runtime for task spawning) let factory = EthereumNode::provider_factory_builder() .open_read_only(MAINNET.clone(), "path/to/datadir", runtime)?; // Get a provider for queries let provider = factory.provider()?; let latest_block = provider.last_block_number()?; ``` ### Performance Implications External reads while the node is syncing or processing blocks: * **I/O Competition**: May compete with the node for disk I/O * **Cache Pollution**: Can evict hot data from OS page cache * **CPU Impact**: Complex queries can impact node performance ### Important Considerations 1. **Read-Only Access Only**: Never open the database in write mode while the regular reth process is running. 2. **Consistency**: When reading from an external process: * Data may be slightly behind the latest processed block (if it hasn't been written to disk yet) * Use transactions for consistent views across multiple reads * Be aware of potential reorgs affecting recent blocks 3. **Performance**: * MDBX uses memory-mapped files for efficient access * Multiple readers don't block each other * Consider caching frequently accessed data ### Disabling long-lived read transactions: By default long lived read transactions are terminated after a few minutes, this is because long read transaction can cause the free list to grow if changes to the database are made (reth node is running). To opt out of this, this safety mechanism can be disabled: ```rust let factory = EthereumNode::provider_factory_builder() .open_read_only(MAINNET.clone(), ReadOnlyConfig::from_datadir("datadir").disable_long_read_transaction_safety(), runtime)?; ``` ### Real-time Block Access Configuration Reth buffers new blocks in memory before persisting them to disk for performance optimization. If your external process needs immediate access to the latest blocks, configure the node to persist blocks immediately: * `--engine.persistence-threshold 0` - Persists new canonical blocks to disk immediately Using this flag ensures external processes can read new blocks without delay. As soon as the reth process has persisted the block data, the external reader can read it from the database. ## Next Steps * Learn about [Modifying Nodes](/sdk/examples/modify-node) to add functionality * Explore the [Type System](/sdk/typesystem/block) for working with data