mirror of
https://github.com/paradigmxyz/reth.git
synced 2026-01-10 07:48:19 -05:00
fix(docs): redo system reqs, fix links, rebrand to docs (#17071)
This commit is contained in:
Yash Atreya
39
README.md
39
README.md
@@ -10,7 +10,7 @@
|
||||
|
||||
|
||||
**[Install](https://paradigmxyz.github.io/reth/installation/installation.html)**
|
||||
| [User Book](https://reth.rs)
|
||||
| [User Docs](https://reth.rs)
|
||||
| [Developer Docs](./docs)
|
||||
| [Crate Docs](https://reth.rs/docs)
|
||||
|
||||
@@ -40,13 +40,14 @@ More concretely, our goals are:
|
||||
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.
|
||||
|
||||
More historical context below:
|
||||
* We released 1.0 "production-ready" stable Reth in June 2024.
|
||||
* Reth completed an audit with [Sigma Prime](https://sigmaprime.io/), the developers of [Lighthouse](https://github.com/sigp/lighthouse), the Rust Consensus Layer implementation. Find it [here](./audit/sigma_prime_audit_v2.pdf).
|
||||
* 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)). We will publish the results soon.
|
||||
* We released multiple iterative beta versions, up to [beta.9](https://github.com/paradigmxyz/reth/releases/tag/v0.2.0-beta.9) on Monday June 3rd 2024 the last beta release.
|
||||
* We released [beta](https://github.com/paradigmxyz/reth/releases/tag/v0.2.0-beta.1) on Monday March 4th 2024, our first breaking change to the database model, providing faster query speed, smaller database footprint, and allowing "history" to be mounted on separate drives.
|
||||
* We shipped iterative improvements until the last alpha release on February 28th 2024, [0.1.0-alpha.21](https://github.com/paradigmxyz/reth/releases/tag/v0.1.0-alpha.21).
|
||||
* We [initially announced](https://www.paradigm.xyz/2023/06/reth-alpha) [0.1.0-alpha.1](https://github.com/paradigmxyz/reth/releases/tag/v0.1.0-alpha.1) in June 20th 2023.
|
||||
|
||||
- We released 1.0 "production-ready" stable Reth in June 2024.
|
||||
- Reth completed an audit with [Sigma Prime](https://sigmaprime.io/), the developers of [Lighthouse](https://github.com/sigp/lighthouse), the Rust Consensus Layer implementation. Find it [here](./audit/sigma_prime_audit_v2.pdf).
|
||||
- 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)). We will publish the results soon.
|
||||
- We released multiple iterative beta versions, up to [beta.9](https://github.com/paradigmxyz/reth/releases/tag/v0.2.0-beta.9) on Monday June 3rd 2024 the last beta release.
|
||||
- We released [beta](https://github.com/paradigmxyz/reth/releases/tag/v0.2.0-beta.1) on Monday March 4th 2024, our first breaking change to the database model, providing faster query speed, smaller database footprint, and allowing "history" to be mounted on separate drives.
|
||||
- We shipped iterative improvements until the last alpha release on February 28th 2024, [0.1.0-alpha.21](https://github.com/paradigmxyz/reth/releases/tag/v0.1.0-alpha.21).
|
||||
- We [initially announced](https://www.paradigm.xyz/2023/06/reth-alpha) [0.1.0-alpha.1](https://github.com/paradigmxyz/reth/releases/tag/v0.1.0-alpha.1) in June 20th 2023.
|
||||
|
||||
### Database compatibility
|
||||
|
||||
@@ -60,7 +61,7 @@ If you had a database produced by alpha versions of Reth, you need to drop it wi
|
||||
|
||||
## For Users
|
||||
|
||||
See the [Reth Book](https://paradigmxyz.github.io/reth) for instructions on how to install and run Reth.
|
||||
See the [Reth documentation](https://paradigmxyz.github.io/reth) for instructions on how to install and run Reth.
|
||||
|
||||
## For Developers
|
||||
|
||||
@@ -76,8 +77,8 @@ For a general overview of the crates, see [Project Layout](./docs/repo/layout.md
|
||||
|
||||
If you want to contribute, or follow along with contributor discussion, you can use our [main telegram](https://t.me/paradigm_reth) to chat with us about the development of Reth!
|
||||
|
||||
- Our contributor guidelines can be found in [`CONTRIBUTING.md`](./CONTRIBUTING.md).
|
||||
- See our [contributor docs](./docs) for more information on the project. A good starting point is [Project Layout](./docs/repo/layout.md).
|
||||
- Our contributor guidelines can be found in [`CONTRIBUTING.md`](./CONTRIBUTING.md).
|
||||
- See our [contributor docs](./docs) for more information on the project. A good starting point is [Project Layout](./docs/repo/layout.md).
|
||||
|
||||
### Building and testing
|
||||
|
||||
@@ -90,7 +91,7 @@ When updating this, also update:
|
||||
|
||||
The Minimum Supported Rust Version (MSRV) of this project is [1.86.0](https://blog.rust-lang.org/2025/04/03/Rust-1.86.0/).
|
||||
|
||||
See the book for detailed instructions on how to [build from source](https://paradigmxyz.github.io/reth/installation/source.html).
|
||||
See the docs for detailed instructions on how to [build from source](https://paradigmxyz.github.io/reth/installation/source).
|
||||
|
||||
To fully test Reth, you will need to have [Geth installed](https://geth.ethereum.org/docs/getting-started/installing-geth), but it is possible to run a subset of tests without Geth.
|
||||
|
||||
@@ -119,13 +120,13 @@ Using `cargo test` to run tests may work fine, but this is not tested and does n
|
||||
|
||||
## Getting Help
|
||||
|
||||
If you have any questions, first see if the answer to your question can be found in the [book][book].
|
||||
If you have any questions, first see if the answer to your question can be found in the [docs][book].
|
||||
|
||||
If the answer is not there:
|
||||
|
||||
- Join the [Telegram][tg-url] to get help, or
|
||||
- Open a [discussion](https://github.com/paradigmxyz/reth/discussions/new) with your question, or
|
||||
- Open an issue with [the bug](https://github.com/paradigmxyz/reth/issues/new?assignees=&labels=C-bug%2CS-needs-triage&projects=&template=bug.yml)
|
||||
- Join the [Telegram][tg-url] to get help, or
|
||||
- Open a [discussion](https://github.com/paradigmxyz/reth/discussions/new) with your question, or
|
||||
- Open an issue with [the bug](https://github.com/paradigmxyz/reth/issues/new?assignees=&labels=C-bug%2CS-needs-triage&projects=&template=bug.yml)
|
||||
|
||||
## Security
|
||||
|
||||
@@ -137,9 +138,9 @@ Reth is a new implementation of the Ethereum protocol. In the process of develop
|
||||
|
||||
None of this would have been possible without them, so big shoutout to the teams below:
|
||||
|
||||
- [Geth](https://github.com/ethereum/go-ethereum/): We would like to express our heartfelt gratitude to the go-ethereum team for their outstanding contributions to Ethereum over the years. Their tireless efforts and dedication have helped to shape the Ethereum ecosystem and make it the vibrant and innovative community it is today. Thank you for your hard work and commitment to the project.
|
||||
- [Erigon](https://github.com/ledgerwatch/erigon) (fka Turbo-Geth): Erigon pioneered the ["Staged Sync" architecture](https://erigon.substack.com/p/erigon-stage-sync-and-control-flows) that Reth is using, as well as [introduced MDBX](https://github.com/ledgerwatch/erigon/wiki/Choice-of-storage-engine) as the database of choice. We thank Erigon for pushing the state of the art research on the performance limits of Ethereum nodes.
|
||||
- [Akula](https://github.com/akula-bft/akula/): Reth uses forks of the Apache versions of Akula's [MDBX Bindings](https://github.com/paradigmxyz/reth/pull/132), [FastRLP](https://github.com/paradigmxyz/reth/pull/63) and [ECIES](https://github.com/paradigmxyz/reth/pull/80) . Given that these packages were already released under the Apache License, and they implement standardized solutions, we decided not to reimplement them to iterate faster. We thank the Akula team for their contributions to the Rust Ethereum ecosystem and for publishing these packages.
|
||||
- [Geth](https://github.com/ethereum/go-ethereum/): We would like to express our heartfelt gratitude to the go-ethereum team for their outstanding contributions to Ethereum over the years. Their tireless efforts and dedication have helped to shape the Ethereum ecosystem and make it the vibrant and innovative community it is today. Thank you for your hard work and commitment to the project.
|
||||
- [Erigon](https://github.com/ledgerwatch/erigon) (fka Turbo-Geth): Erigon pioneered the ["Staged Sync" architecture](https://erigon.substack.com/p/erigon-stage-sync-and-control-flows) that Reth is using, as well as [introduced MDBX](https://github.com/ledgerwatch/erigon/wiki/Choice-of-storage-engine) as the database of choice. We thank Erigon for pushing the state of the art research on the performance limits of Ethereum nodes.
|
||||
- [Akula](https://github.com/akula-bft/akula/): Reth uses forks of the Apache versions of Akula's [MDBX Bindings](https://github.com/paradigmxyz/reth/pull/132), [FastRLP](https://github.com/paradigmxyz/reth/pull/63) and [ECIES](https://github.com/paradigmxyz/reth/pull/80) . Given that these packages were already released under the Apache License, and they implement standardized solutions, we decided not to reimplement them to iterate faster. We thank the Akula team for their contributions to the Rust Ethereum ecosystem and for publishing these packages.
|
||||
|
||||
## Warning
|
||||
|
||||
|
||||
@@ -92,4 +92,4 @@ What we've arrived at is the [minimal ExEx example](https://github.com/paradigmx
|
||||
|
||||
## What's next?
|
||||
|
||||
Let's do something a bit more interesting, and see how you can [keep track of some state](./tracking-state) inside your ExEx.
|
||||
Let's do something a bit more interesting, and see how you can [keep track of some state](/exex/tracking-state) inside your ExEx.
|
||||
|
||||
@@ -26,7 +26,7 @@ $ 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](./hello-world) chapter,
|
||||
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
|
||||
|
||||
@@ -6,7 +6,7 @@ description: How to track state in a custom ExEx.
|
||||
|
||||
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](./hello-world).
|
||||
Let's continue with our Hello World example from the [previous chapter](/exex/hello-world).
|
||||
|
||||
### Turning ExEx into a struct
|
||||
|
||||
|
||||
@@ -131,7 +131,7 @@ 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](#TODO) to interact with Reth once inside the Reth container.
|
||||
Refer to the [CLI docs](/cli/reth) to interact with Reth once inside the Reth container.
|
||||
|
||||
## Run only Grafana in Docker
|
||||
|
||||
|
||||
@@ -8,11 +8,11 @@ Reth runs on Linux and macOS (Windows tracked).
|
||||
|
||||
There are three core methods to obtain Reth:
|
||||
|
||||
- [Pre-built binaries](./binaries)
|
||||
- [Docker images](./docker)
|
||||
- [Building from source.](./source)
|
||||
- [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](./docker#using-docker-compose) configuration
|
||||
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.
|
||||
:::
|
||||
|
||||
@@ -65,7 +65,7 @@ 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](#TODO).
|
||||
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).
|
||||
|
||||
|
||||
@@ -18,14 +18,14 @@ The methods are grouped into namespaces, which are listed below:
|
||||
|
||||
| Namespace | Description | Sensitive |
|
||||
| -------------------- | ------------------------------------------------------------------------------------------------------ | --------- |
|
||||
| [`eth`](./eth) | The `eth` API allows you to interact with Ethereum. | Maybe |
|
||||
| [`web3`](./web3) | The `web3` API provides utility functions for the web3 client. | No |
|
||||
| [`net`](./net) | The `net` API provides access to network information of the node. | No |
|
||||
| [`txpool`](./txpool) | The `txpool` API allows you to inspect the transaction pool. | No |
|
||||
| [`debug`](./debug) | The `debug` API provides several methods to inspect the Ethereum state, including Geth-style traces. | No |
|
||||
| [`trace`](./trace) | The `trace` API provides several methods to inspect the Ethereum state, including Parity-style traces. | No |
|
||||
| [`admin`](./admin) | The `admin` API allows you to configure your node. | **Yes** |
|
||||
| [`rpc`](./rpc) | The `rpc` API provides information about the RPC server and its modules. | No |
|
||||
| [`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 |
|
||||
|
||||
Note that some APIs are sensitive, since they can be used to configure your node (`admin`), or access accounts stored on the node (`eth`).
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@ description: Trace API for inspecting Ethereum state and transactions.
|
||||
|
||||
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`](./debug)).
|
||||
A similar module exists (with other debug functions) with Geth-style traces ([`debug`](/jsonrpc/debug)).
|
||||
|
||||
The `trace` API gives deeper insight into transaction processing.
|
||||
|
||||
|
||||
@@ -105,10 +105,10 @@ Here are some useful sections to jump to:
|
||||
- Set up your [development environment and contribute](/introduction/contributing)!
|
||||
|
||||
:::note
|
||||
The book is continuously rendered [here](https://reth.rs)!
|
||||
You can contribute to the docs on [GitHub][gh-book].
|
||||
The documentation is continuously rendered [here](https://reth.rs)!
|
||||
You can contribute to the docs on [GitHub][gh-docs].
|
||||
:::
|
||||
|
||||
[tg-badge]: https://img.shields.io/endpoint?color=neon&logo=telegram&label=chat&url=https%3A%2F%2Ftg.sumanjay.workers.dev%2Fparadigm%5Freth
|
||||
[tg-url]: https://t.me/paradigm_reth
|
||||
[gh-book]: https://github.com/paradigmxyz/reth/tree/main/book
|
||||
[gh-docs]: https://github.com/paradigmxyz/reth/tree/main/book
|
||||
|
||||
@@ -84,7 +84,7 @@ Your Reth node should start receiving "fork choice updated" messages, and begin
|
||||
## 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).
|
||||
In the meantime, consider setting up [observability](/run/monitoring) to monitor your node's health or [test the JSON RPC API](/jsonrpc/intro).
|
||||
|
||||
{/* TODO: Add more logs to help node operators debug any weird CL to EL messages! */}
|
||||
|
||||
|
||||
@@ -95,7 +95,7 @@ equal to the [freshly synced node](/installation/overview#hardware-requirements)
|
||||
It will take the same time as initial sync.
|
||||
|
||||
1. Stop Reth
|
||||
2. Drop the database using [`reth db drop`](#TODO)
|
||||
2. Drop the database using [`reth db drop`](/cli/reth/db/drop)
|
||||
3. Start reth
|
||||
|
||||
### Database write error
|
||||
|
||||
@@ -4,36 +4,46 @@ The hardware requirements for running Reth depend on the node configuration and
|
||||
|
||||
The most important requirement is by far the disk, whereas CPU and RAM requirements are relatively flexible.
|
||||
|
||||
## Ethereum Mainnet Requirements
|
||||
## Chain Specific Requirements
|
||||
|
||||
Below are the requirements for Ethereum Mainnet:
|
||||
### 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.8TB (TLC NVMe recommended) |
|
||||
| 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 System Requirements
|
||||
### Base Mainnet
|
||||
|
||||
Below are the minimum system requirements for running a Base node as of 2025-06-23, block number 31.9M:
|
||||
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+ |
|
||||
| | 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+ |
|
||||
| Bandwidth | Stable 24Mbps+ | Stable 24Mbps+ |
|
||||
|
||||
:::note
|
||||
**On CPU clock speeds**: We've seen >1s payload latency on EPYC GENOA 9254 (2.9 GHz/3.9 GHz), best performance we see on AMD EPYC™ 4004.
|
||||
**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
|
||||
|
||||
#### QLC and TLC
|
||||
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.
|
||||
|
||||
@@ -41,39 +51,21 @@ QLC (Quad-Level Cell) NVMe drives utilize four bits of data per cell, allowing f
|
||||
|
||||
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.
|
||||
|
||||
Prior to purchasing an NVMe drive, it is advisable to research and determine whether the disk will be based on QLC or TLC technology. An overview of recommended and not-so-recommended NVMe boards can be found at [here](https://gist.github.com/yorickdowne/f3a3e79a573bf35767cd002cc977b038).
|
||||
|
||||
### Disk
|
||||
|
||||
There are multiple types of disks to sync Reth, with varying size requirements, depending on the syncing mode.
|
||||
As of April 2025 at block number 22.1M:
|
||||
|
||||
- Archive Node: At least 2.8TB is required
|
||||
- Full Node: At least 1.8TB is required
|
||||
|
||||
NVMe based SSD drives are recommended for the best performance, with SATA SSDs being a cheaper alternative. HDDs are the cheapest option, but they will take the longest to sync, and are not recommended.
|
||||
|
||||
As of February 2024, syncing an Ethereum mainnet node to block 19.3M on NVMe drives takes about 50 hours, while on a GCP "Persistent SSD" it takes around 5 days.
|
||||
|
||||
:::tip
|
||||
It is highly recommended to choose a TLC drive when using an NVMe drive, and not a QLC drive. See [the note](#qlc-and-tlc) above. A list of recommended drives can be found [here](https://gist.github.com/yorickdowne/f3a3e79a573bf35767cd002cc977b038).
|
||||
:::
|
||||
|
||||
### CPU
|
||||
## 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) (like sender recovery or bodies downloading), but these stages are not the primary bottleneck for syncing.
|
||||
|
||||
### Memory
|
||||
## Memory
|
||||
|
||||
It is recommended to use at least 8GB of RAM.
|
||||
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
|
||||
## 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.
|
||||
|
||||
@@ -83,6 +75,13 @@ Once you're synced to the tip you will need a reliable connection, especially if
|
||||
|
||||
## What hardware can I get?
|
||||
|
||||
If you are buying your own NVMe SSD, please consult [this hardware comparison](https://gist.github.com/yorickdowne/f3a3e79a573bf35767cd002cc977b038) which is being actively maintained. We recommend against buying DRAM-less or QLC devices as these are noticeably slower.
|
||||
### Build your own
|
||||
|
||||
All our benchmarks have been produced on [Latitude.sh](https://www.latitude.sh/), a bare metal provider. We use `c3.large.x86` boxes, and also recommend trying the `c3.small.x86` box for pruned/full nodes. So far our experience has been smooth with some users reporting that the NVMEs there outperform AWS NVMEs by 3x or more. We're excited for more Reth nodes on Latitude.sh, so for a limited time you can use `RETH400` for a $250 discount. [Run a node now!](https://metal.new/reth)
|
||||
- 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 NVMEe 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
|
||||
|
||||
@@ -1,7 +1,10 @@
|
||||
export const redirects: Record<string, string> = {
|
||||
'/intro': '/overview',
|
||||
// Installation redirects
|
||||
'/installation/installation': '/installation/binaries',
|
||||
'/installation/installation': '/installation/overview',
|
||||
'/binaries': '/installation/binaries',
|
||||
'/docker': '/installation/docker',
|
||||
'/source': '/installation/source',
|
||||
// Run a node redirects
|
||||
'/run/run-a-node': '/run/overview',
|
||||
'/run/mainnet': '/run/ethereum',
|
||||
|
||||
Reference in New Issue
Block a user