You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: public/content/developers/docs/nodes-and-clients/index.md
+17-9Lines changed: 17 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -133,14 +133,14 @@ The Ethereum community maintains multiple open-source execution clients (previou
133
133
134
134
This table summarizes the different clients. All of them pass [client tests](https://github.com/ethereum/tests) and are actively maintained to stay updated with network upgrades.
135
135
136
-
| Client | Language | Operating systems | Networks | Sync strategies | State pruning |
For more on supported networks, read up on [Ethereum networks](/developers/docs/networks/).
146
146
@@ -172,6 +172,14 @@ Nethermind is an Ethereum implementation created with the C# .NET tech stack, li
172
172
173
173
Nethermind also has [detailed documentation](https://docs.nethermind.io), strong dev support, an online community and 24/7 support available for premium users.
174
174
175
+
### Reth {#reth}
176
+
177
+
Reth (short for Rust Ethereum) is an Ethereum full node implementation that is focused on being user-friendly, highly modular, fast and efficient. Reth was originally built and driven forward by Paradigm, and is licensed under the Apache and MIT licenses.
178
+
179
+
Reth is production ready, and suitable for usage in mission-critical environments such as staking or high-uptime services. Performs well in use cases where high performance with great margins is required such as RPC, MEV, indexing, simulations, and P2P activities.
180
+
181
+
Learn more by checking out the [Reth Book](https://reth.rs/), or the [Reth GitHub repo](https://github.com/paradigmxyz/reth?tab=readme-ov-file#reth).
182
+
175
183
### In development {#execution-in-development}
176
184
177
185
These clients are still in earlier stages of development and are not yet recommended for production use.
@@ -238,7 +246,7 @@ The execution layer may be run in different modes to suit different use cases, f
238
246
239
247
#### Full sync {#full-sync}
240
248
241
-
A full sync downloads all blocks (including headers and block bodies) and regenerates the state of the blockchain incrementally by executing every block from genesis.
249
+
A full sync downloads all blocks (including headers and block bodies) and regenerates the state of the blockchain incrementally by executing every block from genesis.
242
250
243
251
- Minimizes trust and offers the highest security by verifying every transaction.
244
252
- With an increasing number of transactions, it can take days to weeks to process all transactions.
@@ -247,7 +255,7 @@ A full sync downloads all blocks (including headers and block bodies) and regene
247
255
248
256
#### Fast sync {#fast-sync}
249
257
250
-
Like a full sync, a fast sync downloads all blocks (including headers, transactions, and receipts). However, instead of re-processing the historical transactions, a fast sync relies on the receipts until it reaches a recent head, when it switches to importing and processing blocks to provide a full node.
258
+
Like a full sync, a fast sync downloads all blocks (including headers, transactions, and receipts). However, instead of re-processing the historical transactions, a fast sync relies on the receipts until it reaches a recent head, when it switches to importing and processing blocks to provide a full node.
251
259
252
260
- Fast sync strategy.
253
261
- Reduces processing demand in favor of bandwidth usage.
Copy file name to clipboardExpand all lines: public/content/developers/docs/nodes-and-clients/run-a-node/index.md
+16-1Lines changed: 16 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -97,8 +97,9 @@ The sync mode and client you choose will affect space requirements, but we've es
97
97
| Nethermind | 500GB+ | 12TB+ |
98
98
| Besu | 800GB+ | 12TB+ |
99
99
| Erigon | N/A | 2.5TB+ |
100
+
| Reth | N/A | 2.2TB+ |
100
101
101
-
- Note: Erigon does not offer snap sync, but Full Pruning is possible (~500GB)
102
+
- Note: Erigon and Reth do not offer snap sync, but Full Pruning is possible (~2TB for Erigon, ~1.2TB for Reth)
102
103
103
104
For consensus clients, space requirement also depends on client implementation and enabled features (e.g. validator slasher) but generally count with another 200GB needed for beacon data. With a large number of validators, the bandwidth load grows as well. You can find [details on consensus client requirements in this analysis](https://mirror.xyz/0x934e6B4D7eee305F8C9C42b46D6EEA09CcFd5EDc/b69LBy8p5UhcGJqUAmT22dpvdkU-Pulg2inrhoS9Mbc).
104
105
@@ -155,6 +156,7 @@ Here are the release pages of clients where you can find their pre-built binarie
It is also worth noting that client diversity is an [issue on the execution layer](/developers/docs/nodes-and-clients/client-diversity/#execution-layer). It is recommended that readers consider running a minority execution client.
160
162
@@ -299,6 +301,19 @@ Nethermind docs offer a [complete guide](https://docs.nethermind.io/nethermind/f
299
301
300
302
An execution client will initiate its core functions, chosen endpoints, and start looking for peers. After successfully discovering peers, the client starts synchronization. The execution client will await a connection from consensus client. Current blockchain data will be available once the client is successfully synced to the current state.
301
303
304
+
##### Running Reth
305
+
306
+
This example starts Reth on Mainnet, using default data location. Enables JSON-RPC and Engine RPC authentication for connecting the consensus client which is defined by the `jwtsecret` path, with only calls from `localhost` are allowed.
307
+
308
+
```sh
309
+
reth node \
310
+
--authrpc.jwtsecret /path/to/jwtsecret \
311
+
--authrpc.addr 127.0.0.1 \
312
+
--authrpc.port 8551
313
+
```
314
+
315
+
See [Configuring Reth](https://reth.rs/run/config.html?highlight=data%20directory#configuring-reth) to learn more about data default data directories. [Reth's documentation](https://reth.rs/run/mainnet.html) contains additional options and configuration details.
316
+
302
317
#### Starting the consensus client {#starting-the-consensus-client}
303
318
304
319
The consensus client must be started with the right port configuration to establish a local RPC connection to the execution client. The consensus clients have to be run with the exposed execution client port as configuration argument.
Copy file name to clipboardExpand all lines: public/content/governance/index.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -48,7 +48,7 @@ There are various stakeholders in the [Ethereum community](/community/), each pl
48
48
-**Node Operators**: these people run nodes that propagate blocks and transactions, rejecting any invalid transaction or block that they come across. [More on nodes](/developers/docs/nodes-and-clients/).
49
49
-**EIP Authors**: these people propose changes to the Ethereum protocol, in the form of Ethereum Improvement Proposals (EIPs). [More on EIPs](/eips/).
50
50
-**Validators**: these people run nodes that can add new blocks to the Ethereum blockchain.
51
-
-**Protocol Developers** (a.k.a. "Core Developers" ): these people maintain the various Ethereum implementations (e.g. go-ethereum, Nethermind, Besu, Erigon at the execution layer or Prysm, Lighthouse, Nimbus, Teku, Lodestar at the consensus layer). [More on Ethereum clients](/developers/docs/nodes-and-clients/).
51
+
-**Protocol Developers** (a.k.a. "Core Developers" ): these people maintain the various Ethereum implementations (e.g. go-ethereum, Nethermind, Besu, Erigon, Reth at the execution layer or Prysm, Lighthouse, Nimbus, Teku, Lodestar at the consensus layer). [More on Ethereum clients](/developers/docs/nodes-and-clients/).
52
52
53
53
_Note: any individual can be part of multiple of these groups (e.g. a protocol developer could champion an EIP, and run a beacon chain validator, and use DeFi applications). For conceptual clarity, it is easiest to distinguish between them, though._
0 commit comments