diff --git a/components/calculator/ChainParametersForm.tsx b/components/calculator/ChainParametersForm.tsx
index 12c794ecc..7454867b1 100644
--- a/components/calculator/ChainParametersForm.tsx
+++ b/components/calculator/ChainParametersForm.tsx
@@ -276,4 +276,4 @@ export function ChainParametersForm(): ReactElement {
{!isLoading && showResult && }
);
-}
+}
\ No newline at end of file
diff --git a/pages/operators/node-operators/architecture.mdx b/pages/operators/node-operators/architecture.mdx
index 64d943929..8a7603011 100644
--- a/pages/operators/node-operators/architecture.mdx
+++ b/pages/operators/node-operators/architecture.mdx
@@ -20,12 +20,12 @@ is_imported_content: 'false'
# Node architecture
-This page reviews node architecture for all nodes running on the Superchain network. All OP Mainnet nodes are composed of two core software services, the Rollup Node and the Execution Client.
+This page reviews node architecture for all nodes running on the Superchain network. All OP Mainnet nodes are composed of two core software services, the Rollup Node and the Execution Client.
OP Mainnet also optionally supports a third component, Legacy Geth, that can serve stateful queries for blocks and transactions created before the [Bedrock Upgrade](https://web.archive.org/web/20230608050602/https://blog.oplabs.co/introducing-optimism-bedrock/).
## Node flow diagram
The following diagram shows how the Rollup Node, Execution Client, and Legacy Geth components work together to form a complete node running on the Superchain network.
-This diagram uses the `op-node` and `op-geth` implementations of the Rollup Node and Execution Client respectively, but the same architecture generally applies to other implementations as well.
+This diagram uses the `op-node` implementation of the Rollup Node and shows the general architecture that applies to all execution client implementations.
@@ -39,6 +39,16 @@ The Execution Client is responsible for executing the block payloads it receives
The Execution Client exposes the standard JSON-RPC API that Ethereum developers are familiar with, and can be used to query blockchain data and submit transactions to the network.
The Execution Client is largely analogous to an [execution client](https://ethereum.org/en/developers/docs/nodes-and-clients/#what-are-nodes-and-clients) in Ethereum.
+The OP Stack supports multiple execution client implementations:
+
+### op-geth
+
+`op-geth` is the original execution client for the OP Stack, based on the Go Ethereum (Geth) implementation. It has been modified to support the specific requirements of OP Stack chains.
+
+### Nethermind
+
+Nethermind is a high-performance execution client implementation written in C#. The `Nethermind` client has been adapted to support OP Stack chains, providing an alternative execution client option for node operators.
+
## Legacy Geth
OP Mainnet underwent a large database migration as part of the [Bedrock Upgrade](https://web.archive.org/web/20230608050602/https://blog.oplabs.co/introducing-optimism-bedrock/) in 2023.
@@ -51,6 +61,6 @@ Legacy Geth is **not** required and is typically only necessary if you want to m
## Next steps
-* To get your node up and running, start with the [run a node from docker](/operators/node-operators/tutorials/node-from-docker) or [build a node from source](/operators/node-operators/tutorials/node-from-source) tutorial.
+* To get your node up and running, start with the [run a node from docker](/operators/node-operators/tutorials/node-from-docker) or [build a node from source](/operators/node-operators/tutorials/node-from-source) tutorial. These guides include instructions for both `op-geth` and `Nethermind` execution clients.
* If you've already got your node up and running, check out the [Node Metrics and Monitoring Guide](./management/metrics) to learn how to keep tabs on your node and make sure it keeps running smoothly.
* If you run into any problems, please visit the [Node Troubleshooting Guide](./management/troubleshooting) for help.
diff --git a/pages/operators/node-operators/configuration.mdx b/pages/operators/node-operators/configuration.mdx
index ae6236992..90dcae18b 100644
--- a/pages/operators/node-operators/configuration.mdx
+++ b/pages/operators/node-operators/configuration.mdx
@@ -31,5 +31,5 @@ This section provides information on node base configuration, consensus layer co
-
+
diff --git a/pages/operators/node-operators/configuration/base-config.mdx b/pages/operators/node-operators/configuration/base-config.mdx
index d953c5619..1554db55d 100644
--- a/pages/operators/node-operators/configuration/base-config.mdx
+++ b/pages/operators/node-operators/configuration/base-config.mdx
@@ -1,7 +1,7 @@
---
title: Node base configuration
lang: en-US
-description: Learn the node base configuration and recommended flags for op-node, op-geth, and legacy geth.
+description: Learn the node base configuration and recommended flags for `op-node`, `op-geth`, and legacy geth.
content_type: guide
topic: node-base-configuration
personas:
@@ -16,22 +16,26 @@ categories:
is_imported_content: 'false'
---
-import { Callout } from 'nextra/components'
+import { Callout, Tabs } from 'nextra/components'
# Node base configuration
- Always run `op-node` and `op-geth` in a one-to-one configuration. Don't run multiple `op-geth` instances behind one `op-node`, or vice versa.
+ Always run `op-node` and your execution client (`op-geth` or `nethermind`) in a one-to-one configuration. Don't run multiple execution client instances behind one `op-node`, or vice versa.
To configure your node, you will need to do the following:
-1. Configure `op-node` to point to the correct L1, `op-geth`, and L2 network.
-2. Initialize `op-geth` with the correct network parameters.
-3. Configure `op-geth` to properly communicate with the Rollup Node.
+1. Configure `op-node` to point to the correct L1, execution client, and L2 network.
+2. Initialize your execution client (`op-geth` or `nethermind`) with the correct network parameters.
+3. Configure your execution client to properly communicate with the Rollup Node.
4. Optionally, configure Legacy Geth.
-## Configuring `op-geth`
+## Configuring Your execution client
+
+You can choose between two execution clients for your OP Stack rollup node: `op-geth` or `nethermind`. Each has its own configuration requirements and recommended settings.
+
+### Configuring `op-geth`
Although the Docker image for the Execution Engine is called `op-geth`, the actual binary is still called `geth` in order to minimize differences between `op-geth` and `go-ethereum`. You can see the difference [here](https://op-geth.optimism.io/?utm_source=op-docs&utm_medium=docs).
@@ -146,6 +150,22 @@ geth \
Consult [Geth's documentation](https://geth.ethereum.org/docs/) for more information on customizing `op-geth`'s behavior.
+### Configuring `nethermind`
+
+Nethermind is an alternative execution client for OP Stack rollup nodes. It provides high performance and reliability while maintaining compatibility with the OP Stack protocol.
+
+#### Working base configuration for Nethermind
+
+To run `Nethermind` on the OP Mainnet, use the following command:
+
+```bash
+nethermind \
+ -c op-mainnet \
+ --data-dir path/to/data/dir \
+ --jsonrpc-jwtsecretfile path/to/jwt.hex
+```
+Consult [`Nethermind`'s documentation](https://docs.nethermind.io/fundamentals/configuration) for more detailed configuration options.
+
## Configuring `op-node`
`op-node` is a standalone, statically linked binary. It stores no state, and requires no initialization. It consumes configuration parameters either via the command line or environment variables. For some networks, the Rollup Node also requires a configuration file (called `rollup.json` or the "rollup config") that configures network-specific genesis parameters. For official networks like OP Sepolia and OP Mainnet, the genesis config is hardcoded in the `op-node` software and can be specified via a `--network` flag.
@@ -163,6 +183,8 @@ from a Beacon node.
A minimal valid configuration that runs `op-node` looks like:
+
+
```bash
op-node --l1= \
--l2= \
@@ -174,6 +196,21 @@ op-node --l1= \
--syncmode=execution-layer \
--l2.enginekind=geth
```
+
+
+```bash
+op-node --l1= \
+ --l2= \
+ --network=op-mainnet \
+ --rpc.addr=127.0.0.1 \
+ --rpc.port=9545 \
+ --l2.jwt-secret= \
+ --l1.beacon= \
+ --syncmode=execution-layer \
+ --l2.enginekind=nethermind
+```
+
+
You can manually specify a path to a rollup config with the `--rollup.config` flag. This is used for testnets or internal deployments that are not migrated from a legacy network.
@@ -229,6 +266,6 @@ The term *historical execution* refers to RPC methods that need to execute trans
If you do not need these RPC methods for historical data, then you do not need to run Legacy Geth at all.
## Next steps
-* See the [op-node configuration](/operators/node-operators/configuration/consensus-config) guide for additional configuration options for `op-node` and the Consensus-Layer.
-* Similarly, visit the [op-geth configuration](/operators/node-operators/configuration/execution-config) guide for additional configuration options for `op-geth` and Execution-Layer.
+* See the [`op-node` configuration](/operators/node-operators/configuration/consensus-config) guide for additional configuration options for `op-node` and the Consensus-Layer.
+* For execution client configuration, visit [execution client configuration](/operators/node-operators/configuration/execution-config) for additional options when using `op-geth` or `nethermind`
* If you run into any problems, please reach out to our [developer support forum](https://github.com/ethereum-optimism/developers/discussions) for help.
diff --git a/pages/operators/node-operators/configuration/consensus-config.mdx b/pages/operators/node-operators/configuration/consensus-config.mdx
index 58f4f1dae..db2ddc044 100644
--- a/pages/operators/node-operators/configuration/consensus-config.mdx
+++ b/pages/operators/node-operators/configuration/consensus-config.mdx
@@ -1,7 +1,7 @@
---
title: Consensus layer configuration options (op-node)
lang: en-US
-description: Learn additional configuration and command line options for op-node and the Consensus-Layer.
+description: Learn additional configuration and command line options for `op-node` and the Consensus-Layer.
content_type: reference
topic: consensus-layer-configuration
personas:
@@ -20,7 +20,7 @@ is_imported_content: 'false'
import { Callout } from 'nextra/components'
import { Tabs } from 'nextra/components'
-# Consensus layer configuration options (op-node)
+# Consensus layer configuration options (`op-node`)
You can configure your node using the command line options below (also called flags).
@@ -94,7 +94,7 @@ If true, all sidecars are fetched and filtered locally. Workaround for buggy Bea
### l1.beacon.ignore
-When false, halts op-node startup if the healthcheck to the Beacon-node endpoint fails. The default value is `false`.
+When false, halts `op-node` startup if the healthcheck to the Beacon-node endpoint fails. The default value is `false`.
`--l1.beacon.ignore=`
@@ -154,7 +154,7 @@ Optional self-imposed global rate-limit on L1 RPC requests, specified in request
### l1.rpckind
-The kind of RPC provider, used to inform optimal transactions receipts fetching, and thus reduce costs. Valid options: alchemy, quicknode, infura, parity, nethermind, debug\_geth, erigon, basic, any, standard. The default value is `standard`.
+The kind of RPC provider, used to inform optimal transactions receipts fetching, and thus reduce costs. Valid options: alchemy, quicknode, infura, parity, `nethermind`, debug\_geth, erigon, basic, any, standard. The default value is `standard`.
`--l1.rpckind=`
@@ -277,7 +277,7 @@ are as follows:
low-level system operations. This level generates a large amount of log data and is
typically used only for in-depth troubleshooting.
-To set the log level, use the `--log.level` flag when running the op-node command. For
+To set the log level, use the `--log.level` flag when running the `op-node` command. For
example, to set the log level to debug:
```bash
diff --git a/pages/operators/node-operators/json-rpc.mdx b/pages/operators/node-operators/json-rpc.mdx
index 556e69099..70f40bf30 100644
--- a/pages/operators/node-operators/json-rpc.mdx
+++ b/pages/operators/node-operators/json-rpc.mdx
@@ -1004,10 +1004,24 @@ Sample success output:
todo: add Sample success output
```
-## op-geth
+## Execution clients
+The OP Stack supports multiple execution client implementations. Each client implements the execution layer with minimal changes for a secure Ethereum-equivalent application environment.
-`op-geth` implements the Execution-Layer, with minimal changes for a secure Ethereum-equivalent application environment.
+
+
+ ### op-geth
+
+ `op-geth` is the original execution client for the OP Stack, based on the Go Ethereum (Geth) implementation.
+
+ The execution engine's RPC interface is identical to [the upstream Geth RPC interface](https://geth.ethereum.org/docs/interacting-with-geth/rpc). The responses are nearly identical too, except we also include the L1 gas usage and price information.
+
+
+ ### Nethermind
-The execution engine's RPC interface is identical to [the upstream Geth RPC interface](https://geth.ethereum.org/docs/interacting-with-geth/rpc). The responses are nearly identical too, except we also include the L1 gas usage and price information.
+ `Nethermind` is a high-performance execution client implementation written in C#. The `Nethermind` client has been adapted to support OP Stack chains, providing an alternative execution client option for node operators.
+
+ The execution engine's RPC interface is identical to [the upstream `Nethermind` RPC interface](https://docs.nethermind.io/interacting/json-rpc-server/). The responses are nearly identical too, except we also include the L1 gas usage and price information.
+
+
diff --git a/pages/operators/node-operators/management/blobs.mdx b/pages/operators/node-operators/management/blobs.mdx
index 42cfd532a..7205f1d37 100644
--- a/pages/operators/node-operators/management/blobs.mdx
+++ b/pages/operators/node-operators/management/blobs.mdx
@@ -41,16 +41,31 @@ See the [Software Releases](/operators/node-operators/releases) page for the min
### Configure the Ecotone activation date
* If you are operating a node for an OP Chain that has an entry in the [`superchain-registry`](https://github.com/ethereum-optimism/superchain-registry/blob/main/chainList.json),
-the Ecotone activation date is part of the `op-node` and `op-geth` nodes. So,
-no action is needed for the sequencer after upgrading to the latest release.
-* For node operators of custom chains not included in the [`superchain-registry`](https://github.com/ethereum-optimism/superchain-registry/blob/main/chainList.json),
-the activation dates can be set in the `rollup.json` (set `ecotone_time`) or
-set the activation time via overrides (CLI) in both `op-node` and `op-geth`.
-These will need to be set on `op-node` and `op-geth` for the sequencer and all other nodes.
+the Ecotone activation date is handled automatically by both execution clients:
+
+
+
+ The activation date is part of the node configuration. No action needed after upgrading to the latest release.
+
+
+ The activation date is included in the built-in chain configuration. No action needed after upgrading to the latest release.
+
+
+
+* For node operators of custom chains not included in the [`superchain-registry`](https://github.com/ethereum-optimism/superchain-registry/blob/main/chainList.json):
+
+
+
+ Set the activation time in `rollup.json` (`ecotone_time`) and via CLI overrides
+
+
+ Use the chain configuration examples in `src/Nethermind/Chains` as templates for your custom chain configuration
+
+
- Even if the ecotone activation is configured via the `rollup.json`, it still
- needs to be configured separately on `op-geth` via command line flag.
+ When using `op-geth`, even if the ecotone activation is configured via the `rollup.json`, it still
+ needs to be configured separately via command line flag.
diff --git a/pages/operators/node-operators/management/snap-sync.mdx b/pages/operators/node-operators/management/snap-sync.mdx
index 05c6a954b..fe73d1688 100644
--- a/pages/operators/node-operators/management/snap-sync.mdx
+++ b/pages/operators/node-operators/management/snap-sync.mdx
@@ -25,7 +25,7 @@ import { Tabs } from 'nextra/components'
This guide reviews the optional feature of Snap Sync for node operators, including benefits and how to enable the feature.
-Snap Sync significantly improves the experience of syncing an OP Stack node. Snap Sync is a native feature of go-ethereum that is now optionally enabled on `op-node` & `op-geth`.
+Snap Sync significantly improves the experience of syncing an OP Stack node. Snap Sync is a native feature of the execution clients. Both `op-geth` and `nethermind` support Snap Sync, which can be optionally enabled on `op-node` with `op-geth` or `nethermind`.
Snap Sync works by downloading a snapshot of the state from other nodes on the network and is then able to start executing blocks from the completed state rather than having to re-execute every single block.
This means that performing a Snap Sync is significantly faster than performing a full sync.
@@ -36,7 +36,7 @@ This means that performing a Snap Sync is significantly faster than performing a
## Enable snap sync for your node
-For snap sync, all `op-geth` nodes should expose port `30303` TCP and `30303` UDP to easily find other op-geth nodes to sync from.
+For snap sync, nodes should expose port `30303` TCP and `30303` UDP to easily find other nodes to sync from.
* If you set the port with [`--discovery.port`](/operators/node-operators/configuration/execution-config#discoveryport), then you must open the port specified for UDP.
* If you set [`--port`](/operators/node-operators/configuration/execution-config#port), then you must open the port specified for TCP.
* The only exception is for sequencers and transaction ingress nodes.
@@ -46,7 +46,7 @@ Choose one of the following options to enable snap sync:
* **Option 1:** Snap sync, no required datadir on OP Mainnet. This is the recommended option because `op-node` tells `op-geth` to snap sync and then `op-geth` downloads the state at tip and once complete switches to inserting blocks one by one.
-
+
```shell
--syncmode=execution-layer (not default)
@@ -58,12 +58,23 @@ Choose one of the following options to enable snap sync:
--syncmode=snap (default)
```
+
+
+ ```shell
+ --config op-mainnet
+ --Sync.SnapSync=true
+ ```
+
+
+ A single restart of `Nethermind` during Snap Sync may extend the sync time by up to 2 hours because `Nethermind` has to rebuild the caches by reading millions of values from the database.
+
+
* **Option 2:** Archive sync with required [datadir](snapshots) for OP Mainnet, but no required datadir for other OP Stack networks.
This option is faster for archive nodes than other options because `--syncmode=full` means `op-geth` executes every block in the chain.
-
+
```shell
--syncmode=execution-layer (not default)
@@ -76,12 +87,19 @@ Choose one of the following options to enable snap sync:
--gcmode=archive (not default)
```
+
+
+ Archive sync can be enabled by using the archive configuration for your network (configurations with `_archive` suffix):
+ ```shell
+ --config op-mainnet_archive
+ ```
+
-* **Option 3:** Continue using current sync approach (before Ecotone) where `op-node` reads from L1 and inserts blocks into `op-geth`.
+* **Option 3:** Continue using current sync approach (before Ecotone) where `op-node` reads from L1 and inserts blocks into the execution client.
This option might be preferred for decentralized developer groups who need to confirm everything on the chain.
-
+
```shell
--syncmode=consensus-layer (default)
@@ -93,12 +111,20 @@ Choose one of the following options to enable snap sync:
--syncmode=full (not default)
```
+
+
+ ```shell
+ --config op-mainnet
+ --Sync.SnapSync=false
+ --Sync.FastSync=false
+ ```
+
## Enabling execution layer sync for alternative clients
-In addition to op-geth, you can enable execution-layer syncing with alternative execution clients such as `reth` and `op-erigon`.
+In addition to `op-geth` and `Nethermind`, you can enable execution-layer syncing with alternative execution clients such as `reth` and `op-erigon`.
-Unlike `op-geth`, `reth` and `op-erigon` are designed as archive nodes, which means they require the complete history of the chain.
+Unlike `op-geth` and `Nethermind`, `reth` and `op-erigon` are designed as archive nodes, which means they require the complete history of the chain.
However, these clients can still retrieve block headers and data through the P2P network instead of deriving each individual block, resulting in a faster initial sync.
For OP Mainnet, the [bedrock datadir](snapshots) is required. For other OP Stack networks, no datadir is required.
diff --git a/pages/operators/node-operators/management/snapshots.mdx b/pages/operators/node-operators/management/snapshots.mdx
index 0bb8d7730..9927d780f 100644
--- a/pages/operators/node-operators/management/snapshots.mdx
+++ b/pages/operators/node-operators/management/snapshots.mdx
@@ -26,16 +26,52 @@ This page contains download links for data directories and node snapshots that c
Data directories and node snapshots are not required but can significantly simplify the node operation process.
- Data directories and node snapshots are **not required** for nodes using [snap sync](snap-sync) but are still required for archive nodes and in instances when you need to trace the entire chain.
+ Data directories and node snapshots are **not required** in the following cases:
+
+ * When using [snap sync](snap-sync) with op-geth
+ * When using `Nethermind` (automatically handles snapshots)
+
+ They are still required for archive nodes and in instances when you need to trace the entire chain with `op-geth`.
-## About the Bedrock migration
+## About snapshots and execution clients
+
+### op-geth
OP Mainnet underwent a large [database migration](https://web.archive.org/web/20240110231645/https://blog.oplabs.co/reproduce-bedrock-migration/) as part of the [Bedrock Upgrade](https://web.archive.org/web/20230608050602/https://blog.oplabs.co/introducing-optimism-bedrock/) in 2023.
-Node operators must have a migrated OP Mainnet database to run a node.
-Migrated OP Mainnet databases can be generated manually or pre-migrated databases can be downloaded from the links on this page.
+Node operators using `op-geth` must have a migrated OP Mainnet database to run a node.
+Migrated OP Mainnet databases can be generated manually or pre-migrated databases can be downloaded from the links below.
+
+### Nethermind
+
+Nethermind automatically handles downloading and applying the necessary snapshots when you start the node. No manual snapshot download is required. The node will:
+
+1. Start with an empty database
+2. Automatically download the required ancient data
+3. Apply the data and continue syncing
+
+This process is fully automated and requires no additional configuration.
+When you run `Nethermind` with the `-c op-mainnet` flag, it uses this configuration automatically.
+
+## Available Snapshots
+
+### Nethermind
-## Snapshots
+Nethermind provides an official snapshot through their snapshot service:
+
+| Network | Size | Download Link | Checksum |
+| ---------- | ----- | ---------------------------------------------------------------------------- | -------------------------------------------------------------------- |
+| OP Mainnet | \~2GB | [Download](http://optimism-snapshot.nethermind.io/op-mainnet-genesis-v1.zip) | `0xd7e15b26175c4c924acf75c5790e75d5eaa044977ca8e1904dc62d5d0769eba3` |
+
+
+ When using Nethermind, you don't need to manually download these snapshots. They are automatically downloaded when you start the node with `-c op-mainnet`.
+
+
+### op-geth
+
+
+ The following snapshots are required for op-geth nodes. Unlike Nethermind, op-geth requires manual snapshot management.
+
Always verify snapshots by comparing the sha256sum of the downloaded file to the sha256sum listed on this page.
diff --git a/pages/operators/node-operators/management/troubleshooting.mdx b/pages/operators/node-operators/management/troubleshooting.mdx
index 559f508fa..359190096 100644
--- a/pages/operators/node-operators/management/troubleshooting.mdx
+++ b/pages/operators/node-operators/management/troubleshooting.mdx
@@ -18,7 +18,7 @@ categories:
is_imported_content: 'false'
---
-import {Callout} from 'nextra/components'
+import {Callout, Tabs} from 'nextra/components'
# Node Troubleshooting
@@ -32,12 +32,12 @@ If you see a log that looks like this in `op-node`:
WARN [12-13|15:53:20.263] Derivation process temporary error attempts=80 err="stage 0 failed resetting: temp: failed to find the L2 Heads to start from: failed to fetch current L2 forkchoice state: failed to find the finalized L2 block: failed to determine L2BlockRef of finalized, could not get payload: 401 Unauthorized: signature is invalid
```
-It means that the `op-node` is unable to authenticate with `op-geth`'s authenticated RPC using the JWT secret.
+It means that the `op-node` is unable to authenticate with `execution client`'s authenticated RPC using the JWT secret.
### Solution
1. Check that the JWT secret is correct in both services.
-2. Check that `op-geth`'s authenticated RPC is enabled, and that the URL is correct.
+2. Check that `execution client`'s authenticated RPC is enabled, and that the URL is correct.
## 403 Forbidden: Invalid Host Specified
@@ -47,12 +47,12 @@ If you see a log that looks like this in `op-node`:
{"err":"403 Forbidden: invalid host specified\n","lvl":"error","msg":"error getting latest header","t":"2022-12-13T22:29:18.932833159Z"}
```
-It means that you have not whitelisted `op-node`'s host with `op-geth`.
+It means that you have not whitelisted `op-node`'s host with `execution client`.
### Solution
-1. Make sure that the `--authrpc.vhosts` parameter in `op-geth` is either set to the correct host, or `*`.
-2. Check that `op-geth`'s authenticated RPC is enabled, and that the URL is correct.
+1. Make sure that the `--authrpc.vhosts` parameter in `execution client` is either set to the correct host, or `*`.
+2. Check that `execution client`'s authenticated RPC is enabled, and that the URL is correct.
## Failed to Load P2P Config
@@ -62,7 +62,7 @@ If you see a log that looks like this in `op-node`:
CRIT [12-13|13:46:21.386] Application failed message="failed to load p2p config: failed to load p2p discovery options: failed to open discovery db: mkdir /p2p: permission denied"
```
-It means that the `op-node` lacks write access to the P2P discovery or peerstore directories.
+It means that the `op-node` lacks write access to the P2P discovery or peerstore directories.
### Solution
@@ -78,40 +78,75 @@ If you see a log that looks like this in `op-node`:
{"attempts":183,"err":"stage 0 failed resetting: temp: failed to find the L2 Heads to start from: wrong chain L1: genesis: 0x4104895a540d87127ff11eef0d51d8f63ce00a6fc211db751a45a4b3a61a9c83:8106656, got 0x12e2c18a3ac50f74d3dd3c0ed7cb751cc924c2985de3dfed44080e683954f1dd:8106656","lvl":"warn","msg":"Derivation process temporary error","t":"2022-12-13T23:31:37.855253213Z"}
```
-It means that the `op-node` is pointing to the wrong chain.
+It means that the `op-node` is pointing to the wrong chain.
### Solution
1. Verify that the `op-node`'s L1 URL is pointing to the correct L1 for the given network.
2. Verify that the `op-node`'s rollup config/`--network` parameter is set to the correct network.
-3. Verify that the `op-node`'s L2 URL is pointing to the correct instance of `op-geth`, and that `op-geth` is properly initialized for the given network.
+3. Verify that the `op-node`'s L2 URL is pointing to the correct instance of `execution client`, and that `execution client` is properly initialized for the given network.
## Unclean Shutdowns
-If you see a log that looks like this in `op-geth`:
+If you see a log that looks like this in `execution client`:
```
WARN [03-05|16:18:11.238] Unclean shutdown detected booted=2023-03-05T11:09:26+0000 age=5h8m45s
```
-It means `op-geth` has experienced an unclean shutdown. The [geth docs](https://geth.ethereum.org/docs/fundamentals/databases#unclean-shutdowns)
-say if Geth stops unexpectedly, the database can be corrupted. This is known as an
-"unclean shutdown" and it can lead to a variety of problems for the node when
-it is restarted.
-
-It is always best to shut down Geth gracefully, i.e. using a
-shutdown command such as `ctrl-c`, `docker stop -t 300 ` or
-`systemctl stop` (although please note that `systemctl stop` has a default timeout
-of 90s - if Geth takes longer than this to gracefully shut down it will quit
-forcefully. Update the `TimeoutSecs` variable in `systemd.service` to override this
-value to something larger, at least 300s).
-
-This way, Geth knows to write all relevant information into the database to
-allow the node to restart properly later. This can involve >1GB of information
-being written to the LevelDB database which can take several minutes.
-
-### Solution
-
-If an unexpected shutdown does occur, the `removedb` subcommand can be used to
-delete the state database and resync it from the ancient database. This should
-get the database back up and running.
+It means `execution client` has experienced an unclean shutdown. The [geth docs](https://geth.ethereum.org/docs/fundamentals/databases#unclean-shutdowns)
+say if Geth stops unexpectedly, the database can be corrupted. This is known as an
+"unclean shutdown" and it can lead to a variety of problems for the node when
+it is restarted.
+
+
+
+ It is always best to shut down Geth gracefully, i.e. using a
+ shutdown command such as `ctrl-c`, `docker stop -t 300 ` or
+ `systemctl stop` (although please note that `systemctl stop` has a default timeout
+ of 90s - if Geth takes longer than this to gracefully shut down it will quit
+ forcefully. Update the `TimeoutSecs` variable in `systemd.service` to override this
+ value to something larger, at least 300s).
+
+ This way, Geth knows to write all relevant information into the database to
+ allow the node to restart properly later. This can involve >1GB of information
+ being written to the LevelDB database which can take several minutes.
+
+ ### Solution
+
+ If an unexpected shutdown does occur, the `removedb` subcommand can be used to
+ delete the state database and resync it from the ancient database. This should
+ get the database back up and running.
+
+
+
+ Unclean shutdowns in `Nethermind` can lead to database corruption. This typically happens when:
+
+ * The node experiences hardware failures (disk failures, memory errors, overheating)
+ * Power cuts cause abrupt shutdowns
+ * The process is terminated without proper cleanup
+
+ ### Solutions
+
+ 1. **Lock File Issues**
+ If `Nethermind` complains about lock files after an unclean shutdown, run:
+ ```bash
+ find /path/to/nethermind_db -type f -name 'LOCK' -delete
+ ```
+
+ 2. **Block Checksum Mismatch**
+ If you encounter block checksum mismatch errors, you can enable direct I/O:
+ ```bash
+ --Db.UseDirectIoForFlushAndCompactions true
+ ```
+ Note: This may impact performance.
+
+ 3. **Complete Resync**
+ In cases of severe corruption, a full resync is recommended:
+ ```bash
+ sudo systemctl stop nethermind
+ sudo rm -rf /path/to/nethermind_db/mainnet
+ sudo systemctl start nethermind
+ ```
+
+
diff --git a/pages/operators/node-operators/rollup-node.mdx b/pages/operators/node-operators/rollup-node.mdx
index 9bc58e2be..2a5f68828 100644
--- a/pages/operators/node-operators/rollup-node.mdx
+++ b/pages/operators/node-operators/rollup-node.mdx
@@ -55,8 +55,9 @@ OP Stack rollup nodes can be configured for individual needs. The following step
{
Setup Your Working Base Configs
}
- * Configure `op-geth` using the [base configuration](/operators/node-operators/configuration/base-config#working-base-configuration).
- * Set the [recommended flags for `op-geth`](/operators/node-operators/configuration/base-config#recommended-flags-for-op-geth-configuration) to follow best practices for configuring OP Stack rollup nodes.
+ * Configure your execution client:
+ * For `op-geth`: Use the [base configuration](/operators/node-operators/configuration/base-config#working-base-configuration) and set the [recommended flags](/operators/node-operators/configuration/base-config#recommended-flags-for-op-geth-configuration)
+ * For `nethermind`: Use the [base configuration](/operators/node-operators/configuration/base-config#working-base-configuration-nethermind) and set the [recommended flags](/operators/node-operators/configuration/base-config#recommended-flags-for-nethermind-configuration)
* Configure `op-node` using the [base configuration](/operators/node-operators/configuration/base-config#working-base-configuration-1).
{
Enable Snap Sync
}
@@ -65,7 +66,7 @@ OP Stack rollup nodes can be configured for individual needs. The following step
This is an **optional** feature but highly recommended for node providers.
- Additional configuration options exist for [`op-geth`](/operators/node-operators/configuration/execution-config) and [`op-node`](/operators/node-operators/configuration/consensus-config), respectively.
+ Additional configuration options exist for execution clients and `op-node`. See the [Execution Client Configuration](/operators/node-operators/configuration/execution-config) and [`op-node`](/operators/node-operators/configuration/consensus-config), respectively.
@@ -94,7 +95,7 @@ Now, you will run your node and set your node debugging log level for more granu
## Monitor your node
-It is important to regularly monitor your node, and you can optionally configure prometheus and grafana dashboard to make this process easier for you.
+It is important to regularly monitor your node, and you can optionally configure Prometheus and Grafana dashboard to make this process easier for you.
{
Enable the Metrics Port
}
@@ -102,15 +103,20 @@ It is important to regularly monitor your node, and you can optionally configure
* Enable the [metrics port](/operators/node-operators/management/metrics) for your node by passing the `--metrics.enabled` flag to `op-node`.
* Optionally, you can customize the metrics port and address via the `--metrics.port` and `--metrics.addr` flags, respectively.
- {
Setup Prometheus & Grafana
}
+ {
Set up Prometheus & Grafana
}
- The following steps are intended for `go-ethereum`, so it must be tweaked to work for rollup nodes running within the Superchain.
+ The following steps vary depending on your execution client.
- * Setup [influxdb](https://geth.ethereum.org/docs/monitoring/dashboards#setting-up-influxdb) to hold metrics data.
- * Setup [prometheus](https://geth.ethereum.org/docs/monitoring/dashboards#setting-up-prometheus) to read your endpoint.
- * Setup your [grafana dashboard](https://geth.ethereum.org/docs/monitoring/dashboards#setting-up-grafana) to provide UI for metrics.
+ For `op-geth`:
+ * Set up [InfluxDB](https://geth.ethereum.org/docs/monitoring/dashboards#setting-up-influxdb) to hold metrics data
+ * Set up [Prometheus](https://geth.ethereum.org/docs/monitoring/dashboards#setting-up-prometheus) to read your endpoint
+ * Set up your [Grafana dashboard](https://geth.ethereum.org/docs/monitoring/dashboards#setting-up-grafana) to provide a UI for metrics
+
+ For `Nethermind`:
+ * Set up [Grafana and Prometheus](https://docs.nethermind.io/monitoring/metrics/grafana-and-prometheus/#step-1-set-up-grafana-and-prometheus)
+ * Follow the [metrics documentation](https://docs.nethermind.io/monitoring/metrics/) for detailed monitoring setup
## Follow node updates
diff --git a/pages/operators/node-operators/tutorials/node-from-docker.mdx b/pages/operators/node-operators/tutorials/node-from-docker.mdx
index b17efcac6..2f23aba05 100644
--- a/pages/operators/node-operators/tutorials/node-from-docker.mdx
+++ b/pages/operators/node-operators/tutorials/node-from-docker.mdx
@@ -27,6 +27,10 @@ This tutorial will walk you through the process of using [`simple-optimism-node`
`simple-optimism-node` also provides useful tools like a monitoring dashboard and health checking software.
Although less flexible than [running a node from source](/operators/node-operators/tutorials/node-from-source) or building your own Docker setup, this is a great way to quickly get started with OP Mainnet.
+
+ By default, `simple-optimism-node` uses `op-geth` as the execution client. Support for `Nethermind` as an alternative execution client is also available.
+
+
## What's included
`simple-optimism-node` includes all the basic components to run an OP Mainnet or OP Sepolia node.
@@ -76,6 +80,11 @@ Configuration for `simple-optimism-node` is handled through environment variable
* `full` (Full node) - A Full node contains a few recent blocks without historical states.
* `archive` (Archive node) - An Archive node stores the complete history of the blockchain, including historical states.
+ **EXECUTION_CLIENT** - Choose which execution client to use:
+
+ * `op-geth` - The original execution client for OP Stack (default if not specified)
+ * `nethermind` - Alternative high-performance execution client written in C#
+
**OP_NODE__RPC_ENDPOINT** - Specify the endpoint for the RPC of Layer 1 (e.g., Ethereum mainnet). For instance, you can use the free plan of Alchemy for the Ethereum mainnet.
**OP_NODE__L1_BEACON** - Specify the beacon endpoint of Layer 1. You can use [QuickNode for the beacon endpoint](https://www.quicknode.com). For example: `https://xxx-xxx-xxx.quiknode.pro/db55a3908ba7e4e5756319ffd71ec270b09a7dce`.
@@ -104,6 +113,8 @@ The following command will start the node in the background.
docker compose up -d --build
```
+The node will start with the execution client you specified in your `.env` file. If you didn't specify an execution client, `op-geth` will be used by default.
+
## Upgrade the node
Pull the latest updates from GitHub, Docker Hub and rebuild the container.
diff --git a/pages/operators/node-operators/tutorials/node-from-source.mdx b/pages/operators/node-operators/tutorials/node-from-source.mdx
index 0caf296f6..bfbf2611a 100644
--- a/pages/operators/node-operators/tutorials/node-from-source.mdx
+++ b/pages/operators/node-operators/tutorials/node-from-source.mdx
@@ -15,7 +15,7 @@ categories:
is_imported_content: 'false'
---
-import { Callout, Steps } from 'nextra/components'
+import { Callout, Steps, Tabs } from 'nextra/components'
# Building a Superchain node from source
@@ -39,7 +39,56 @@ The Execution Client is responsible for executing the block payloads it receives
The Execution Client exposes the standard JSON-RPC API that Ethereum developers are familiar with, and can be used to query blockchain data and submit transactions to the network.
The Execution Client is largely analogous to an [execution client](https://ethereum.org/en/developers/docs/nodes-and-clients/#what-are-nodes-and-clients) in Ethereum.
-In this tutorial you will build the `op-geth` implementation of the Execution Client as found in the [`op-geth` repository](https://github.com/ethereum-optimism/op-geth).
+
+
+ The `op-geth` implementation of the Execution Client can be found in the [`op-geth` repository](https://github.com/ethereum-optimism/op-geth).
+
+ #### Prerequisites
+
+ * Go 1.21 or later
+ * Make
+
+ #### Building
+
+ Follow the instructions in the `op-geth` repository to build from source.
+
+
+
+ `Nethermind` is an alternative execution client implementation written in .NET.
+
+ #### Prerequisites
+
+ * [.NET SDK](https://aka.ms/dotnet/download) 9 or later
+
+ #### Building
+
+
+ 1. Clone the repository:
+ The `Nethermind`'s source code can be obtained from [`nethermind` repository](https://github.com/NethermindEth/nethermind)
+
+ ```bash
+ git clone --recursive https://github.com/nethermindeth/nethermind.git
+ ```
+
+ 2. Build the source:
+
+ ```bash
+ dotnet build src/Nethermind/Nethermind.sln -c release
+ ```
+
+ 3. Run `Nethermind` (this will build it first if needed):
+
+ ```bash
+ cd src/Nethermind/Nethermind.Runner
+ dotnet run -c release -- -c mainnet
+ ```
+
+ The build artifacts will be located in `src/Nethermind/artifacts/bin/Nethermind.Runner/release`.
+
+
+ For more details about running a `Nethermind` node, see the [`Nethermind` documentation](https://docs.nethermind.io/get-started/running-node/).
+
+
### Legacy Geth (optional)
@@ -58,81 +107,75 @@ Our build environment is managed through a tool called [mise](https://mise.jdx.d
First you're going to build the `op-node` implementation of the Rollup Node as found in the [Optimism Monorepo](https://github.com/ethereum-optimism/optimism).
-
+ {
Clone the Optimism Monorepo
}
-{
Clone the Optimism Monorepo
}
-
-The Optimism Monorepo contains the source code for the `op-node`.
+ The Optimism Monorepo contains the source code for the `op-node`.
-```bash
-git clone https://github.com/ethereum-optimism/optimism.git
-cd optimism
-```
+ ```bash
+ git clone https://github.com/ethereum-optimism/optimism.git
+ cd optimism
+ ```
-{
Check out the required release branch
}
+ {
Check out the required release branch
}
-Release branches are created when new versions of the `op-node` are created.
-Read through the [Releases page](https://github.com/ethereum-optimism/optimism/releases) to determine the correct branch to check out.
+ Release branches are created when new versions of the `op-node` are created.
+ Read through the [Releases page](https://github.com/ethereum-optimism/optimism/releases) to determine the correct branch to check out.
-```bash
-git checkout
-```
+ ```bash
+ git checkout
+ ```
-
-Make sure to read the Releases page carefully to determine the correct branch to check out.
-Some releases may only be required for the OP Sepolia testnet.
-
+
+ Make sure to read the Releases page carefully to determine the correct branch to check out.
+ Some releases may only be required for the OP Sepolia testnet.
+
-{
Build op-node
}
+ {
Build `op-node`
}
-Build the `op-node` implementation of the Rollup Node.
-
-```bash
-cd op-node
-just
-```
+ Build the `op-node` implementation of the Rollup Node.
+ ```bash
+ cd op-node
+ just
+ ```
## Build the execution client
-Next you're going to build the `op-geth` implementation of the Execution Client as found in the [op-geth repository](https://github.com/ethereum-optimism/op-geth).
+Next you're going to build the `op-geth` implementation of the Execution Client as found in the [`op-geth` repository](https://github.com/ethereum-optimism/op-geth).
+ {
Clone `op-geth`
}
-{
Clone op-geth
}
-
-The [`op-geth` repository](https://github.com/ethereum-optimism/op-geth) contains the source code for the `op-geth` implementation of the Execution Client.
-
-```bash
-git clone https://github.com/ethereum-optimism/op-geth.git
-cd op-geth
-```
+ The [`op-geth` repository](https://github.com/ethereum-optimism/op-geth) contains the source code for the `op-geth` implementation of the Execution Client.
-{
}
-Release branches are created when new versions of the `op-geth` are created.
-Read through the [Releases page](https://github.com/ethereum-optimism/op-geth/releases) to determine the correct branch to check out.
+ Release branches are created when new versions of the `op-geth` are created.
+ Read through the [Releases page](https://github.com/ethereum-optimism/op-geth/releases) to determine the correct branch to check out.
-```bash
-git checkout
-```
+ ```bash
+ git checkout
+ ```
-
-Make sure to read the Releases page carefully to determine the correct branch to check out.
-Some releases may only be required for the OP Sepolia testnet.
-
+
+ Make sure to read the Releases page carefully to determine the correct branch to check out.
+ Some releases may only be required for the OP Sepolia testnet.
+
-{
Build op-geth
}
+ {
Build `op-geth`
}
-Build the `op-geth` implementation of the Execution Client.
-
-```bash
-make geth
-```
+ Build the `op-geth` implementation of the Execution Client.
+ ```bash
+ make geth
+ ```
## Build legacy Geth (optional)
@@ -142,23 +185,21 @@ Legacy Geth allows you to execute stateful queries like `eth_call` against block
Legacy Geth is only relevant to OP Mainnet archive nodes and is not required for full nodes or OP Sepolia nodes.
+ {
Clone the OP Legacy Repository
}
-{
Clone the OP Legacy Repository
}
-
-The OP Legacy repository contains the source code for the `l2geth` implementation of Legacy Geth.
-
-```bash
-git clone https://github.com/ethereum-optimism/optimism-legacy.git
-cd optimism-legacy
-```
+ The OP Legacy repository contains the source code for the `l2geth` implementation of Legacy Geth.
-{
}
+ ```bash
+ cd l2geth
+ make
+ ```
## Next steps
diff --git a/pages/operators/node-operators/tutorials/run-node-from-source.mdx b/pages/operators/node-operators/tutorials/run-node-from-source.mdx
index 07e9f9def..e088156ac 100644
--- a/pages/operators/node-operators/tutorials/run-node-from-source.mdx
+++ b/pages/operators/node-operators/tutorials/run-node-from-source.mdx
@@ -18,7 +18,7 @@ categories:
is_imported_content: 'false'
---
-import { Callout, Steps } from 'nextra/components'
+import { Callout, Steps, Tabs } from 'nextra/components'
# Running a Superchain node from source
@@ -27,7 +27,7 @@ Running an OP Stack node from source code is a flexible alternative to using pre
## Building the source code
-You'll need to build `op-node` and `op-geth` from their respective source repositories before you can run a node.
+You'll need to build `op-node` and execution client (`op-geth` or `Nethermind`) from their respective source repositories before you can run a node.
Make sure to follow the instructions on [Building a Node from Source](./node-from-source) before continuing.
## Hardware requirements
@@ -55,7 +55,7 @@ Based on these trends, node operators should plan for future storage needs and c
## Superchain nodes
-All nodes in the Superchain ecosystem can be run from `op-node` and `op-geth` binaries if they're included in the [Superchain Registry](/superchain/superchain-registry). You can specify the type of node you want to run by configuring the `--network` flag on `op-node` and the `--op-network` flag on `op-geth`.
+All nodes in the Superchain ecosystem can be run from `op-node` and an execution client (`op-geth` or `Nethermind`) if they're included in the [Superchain Registry](/superchain/superchain-registry). You can specify the type of node you want to run by configuring the `--network` flag on `op-node` and the corresponding network flag on your execution client (`--op-network` for `op-geth` or `-c` for `Nethermind`).
### Assess blob archiver
@@ -63,9 +63,9 @@ Assess if you need to configure a blob archiver service by reading the [Configur
### Create a JWT secret
-`op-geth` and `op-node` communicate over the engine API authrpc.
+The execution client and `op-node` communicate over the engine API authrpc.
This communication is secured using a shared secret.
-You will need to generate a shared secret and provide it to both `op-geth` and `op-node` when you start them.
+You will need to generate a shared secret and provide it to both your execution client and `op-node` when you start them.
In this case, the secret takes the form of a 32 byte hex string.
Run the following command to generate a random 32 byte hex string:
@@ -74,69 +74,114 @@ Run the following command to generate a random 32 byte hex string:
openssl rand -hex 32 > jwt.txt
```
-### Start `op-geth`
+### Start the execution client
-It's generally easier to start `op-geth` before starting `op-node`.
-You can still start `op-geth` without yet running `op-node`, but the `op-geth` instance will simply not receive any blocks until `op-node` is started.
+It's generally easier to start the execution client before starting `op-node`.
+You can still start the execution client without yet running `op-node`, but it will simply not receive any blocks until `op-node` is started.
-
- {
Navigate to your op-geth directory
}
+
+
+
+ {
Navigate to your `op-geth` directory
}
- Find the directory where you built the `op-geth` binary.
+ Find the directory where you built the `op-geth` binary.
- {
Copy in the JWT secret
}
+ {
Copy in the JWT secret
}
- Copy the JWT secret you generated in a previous step into the `op-geth` directory.
+ Copy the JWT secret you generated in a previous step into the `op-geth` directory.
- ```bash
- cp /path/to/jwt.txt .
- ```
+ ```bash
+ cp /path/to/jwt.txt .
+ ```
- {
Set environment variables
}
+ {
Set environment variables
}
- Set the following environment variables:
+ Set the following environment variables:
- ```bash
- export DATADIR_PATH=... # Path to the desired data directory for op-geth
- ```
+ ```bash
+ export DATADIR_PATH=... # Path to the desired data directory for op-geth
+ ```
- {
Start op-geth
}
+ {
Start `op-geth`
}
-
- If you want to run an archive node, you will need to set `--gcmode=archive`. If you want to run an OP Mainnet archive node, please refer to the [OP Mainnet archive nodes](#op-mainnet-archive-nodes) section.
-
- Use the following command to start `op-geth` in a default configuration.
- The JSON-RPC API will become available on port 8545.
- Refer to the `op-geth` [configuration documentation](/operators/node-operators/configuration/execution-config) for more detailed information about available options.
+
+ If you want to run an archive node, you will need to set `--gcmode=archive`. If you want to run an OP Mainnet archive node, please refer to the [OP Mainnet archive nodes](#op-mainnet-archive-nodes) section.
+
- ```bash
- ./build/bin/geth \
- --http \
- --http.port=8545 \
- --http.addr=localhost \
- --authrpc.addr=localhost \
- --authrpc.jwtsecret=./jwt.txt \
- --verbosity=3 \
- --rollup.sequencerhttp=https://mainnet-sequencer.optimism.io/ \
- --op-network=op-sepolia \
- --datadir=$DATADIR_PATH
- ```
-
+ Use the following command to start `op-geth` in a default configuration.
+ The JSON-RPC API will become available on port 8545.
+ Refer to the `op-geth` [configuration documentation](/operators/node-operators/configuration/execution-config) for more detailed information about available options.
+
+ ```bash
+ ./build/bin/geth \
+ --http \
+ --http.port=8545 \
+ --http.addr=localhost \
+ --authrpc.addr=localhost \
+ --authrpc.jwtsecret=./jwt.txt \
+ --verbosity=3 \
+ --rollup.sequencerhttp=https://mainnet-sequencer.optimism.io/ \
+ --op-network=op-sepolia \
+ --datadir=$DATADIR_PATH
+ ```
+
+
+
+
+
+ {
Navigate to your `Nethermind` directory
}
+
+ Find the directory where you built the `Nethermind` binary.
+
+ {
Copy in the JWT secret
}
+
+ Copy the JWT secret you generated in a previous step into the `Nethermind` directory.
+
+ ```bash
+ cp /path/to/jwt.txt .
+ ```
+
+ {
Start `Nethermind`
}
+
+
+ If you want to run an archive node, use the `op-sepolia_archive` configuration instead of `op-sepolia`. For OP Mainnet, use `op-mainnet` or `op-mainnet_archive` configurations respectively.
+
+
+ Use the following command to start `Nethermind` in a default configuration.
+ The JSON-RPC API will become available on port 8545.
+ Refer to the `Nethermind` [configuration documentation](/operators/node-operators/configuration/execution-config#nethermind) for more detailed information about available options.
+
+ ```bash
+ ./Nethermind.Runner \
+ -c op-sepolia \
+ --data-dir path/to/data/dir \
+ --JsonRpc.JwtSecretFile=./jwt.txt
+ ```
+
+ This command uses the built-in `op-sepolia` configuration which already includes the correct settings for:
+
+ * JSON-RPC endpoints
+ * Network ports
+ * Sequencer URL
+ * Other OP Stack specific settings
+
+
+
### Start `op-node`
-Once you've started `op-geth`, you can start `op-node`.
-`op-node` will connect to `op-geth` and begin synchronizing the OP Mainnet state.
-`op-node` will begin sending block payloads to `op-geth` when it derives enough blocks from Ethereum.
+Once you've started your execution client, you can start `op-node`.
+`op-node` will connect to the execution client and begin synchronizing the OP Mainnet state.
+`op-node` will begin sending block payloads to the execution client when it derives enough blocks from Ethereum.
- {
Navigate to your op-node directory
}
+ {
Navigate to your `op-node` directory
}
Find the directory where you built the `op-node` binary.
{
Copy in the JWT secret
}
- Both `op-geth` and `op-node` need to use the same JWT secret.
+ Both the execution client and `op-node` need to use the same JWT secret.
Copy the JWT secret you generated in a previous step into the `op-node` directory.
```bash
@@ -153,7 +198,7 @@ Once you've started `op-geth`, you can start `op-node`.
export L1_BEACON_URL=... # URL address for the L1 Beacon-node HTTP endpoint to use. If your L1 Beacon is a local node, the most common URL is http://127.0.0.1:3500
```
- {
Start op-node
}
+ {
Start `op-node`
}
Use the following command to start `op-node` in a default configuration.
Refer to the `op-node` [configuration documentation](/operators/node-operators/configuration/consensus-config) for more detailed information about available options.
@@ -164,8 +209,8 @@ Once you've started `op-geth`, you can start `op-node`.
- Sync mode is set to `--syncmode=execution-layer` to enable [snap sync](/operators/node-operators/management/snap-sync)
- and remove the need to initialize the node with a data directory.
+ Sync mode is set to `--syncmode=execution-layer` to enable [snap sync](/operators/node-operators/management/snap-sync)
+ for both `op-geth` and `Nethermind`, removing the need to initialize the node with a data directory.
```bash
@@ -189,75 +234,109 @@ Once you've started `op-geth`, you can start `op-node`.
### Synchronization verification
-Once you've started `op-geth` and `op-node` you should see the two begin to
-communicate with each other and synchronize the OP Mainnet chain.
+Once you've started your execution client and `op-node` you should see them begin to communicate with each other and synchronize the OP Mainnet chain.
#### Snap sync (default)
-Initial synchronization can take several hours to complete. You will see these
-`op-node` logs at the start of snap sync:
+
+
+ Initial synchronization can take several hours to complete. You will see these
+ `op-node` logs at the start of snap sync:
-```text
-INFO [03-06|10:56:55.602] Starting EL sync
-INFO [03-06|10:56:55.615] Sync progress reason="unsafe payload from sequencer while in EL sync" l2_finalized=000000..000000:0 l2_safe=000000..000000:0 l2_pending_safe=000000..000000:0 l2_unsafe=4284ab..7e7e84:117076319 l2_time=1,709,751,415 l1_derived=000000..000000:0
-INFO [03-06|10:56:57.567] Optimistically inserting unsafe L2 execution payload to drive EL sync id=4ac160..df4d12:117076320
-```
+ ```text
+ INFO [03-06|10:56:55.602] Starting EL sync
+ INFO [03-06|10:56:55.615] Sync progress reason="unsafe payload from sequencer while in EL sync" l2_finalized=000000..000000:0 l2_safe=000000..000000:0 l2_pending_safe=000000..000000:0 l2_unsafe=4284ab..7e7e84:117076319 l2_time=1,709,751,415 l1_derived=000000..000000:0
+ INFO [03-06|10:56:57.567] Optimistically inserting unsafe L2 execution payload to drive EL sync id=4ac160..df4d12:117076320
+ ```
-`Starting EL sync` is shown once and the **sync progress / inserting logs** should be repeated until done.
+ `Starting EL sync` is shown once and the **sync progress / inserting logs** should be repeated until done.
-`op-node` will log the following when done:
+ `op-node` will log the following when done:
-```text
-lvl=info msg="Finished EL sync" sync_duration=23h25m0.370558429s finalized_block=0x4f69e83ff1407f2e2882f2526ee8a154ac326590799889cede3af04a7742f18d:116817417
-```
+ ```text
+ lvl=info msg="Finished EL sync" sync_duration=23h25m0.370558429s finalized_block=0x4f69e83ff1407f2e2882f2526ee8a154ac326590799889cede3af04a7742f18d:116817417
+ ```
-There are two stages on `op-geth` for snap sync:
+ There are two stages on `op-geth` for snap sync:
-
- {
Downloading the headers
}
- `op-geth` log something like this as it is downloading the headers:
+
+ {
Downloading the headers
}
- ```text
- lvl=info msg="Syncing beacon headers" downloaded=116775778 left=1162878 eta=53.182s
- ```
+ `op-geth` log something like this as it is downloading the headers:
- {
Sync progress
}
+ ```text
+ lvl=info msg="Syncing beacon headers" downloaded=116775778 left=1162878 eta=53.182s
+ ```
- For the second stage, `op-geth` will log the following:
+ {
Sync progress
}
- ```text
- lvl=info msg="Syncing: state download in progress" synced=99.75% state="191.33 GiB" accounts=124,983,227@25.62GiB slots=806,829,266@165.16GiB codes=78965@566.74MiB eta=-2m7.602s
- ```
+ For the second stage, `op-geth` will log the following:
- ```text
- msg="Syncing: chain download in progress" synced=100.00% chain="176.01 GiB" headers=116,817,399@45.82GiB bodies=116,817,286@52.87GiB receipts=116,817,286@77.32GiB eta=77.430ms
- ```
-
- All the while, `op-geth` will also log the forkchoice update:
+ ```text
+ lvl=info msg="Syncing: state download in progress" synced=99.75% state="191.33 GiB" accounts=124,983,227@25.62GiB slots=806,829,266@165.16GiB codes=78965@566.74MiB eta=-2m7.602s
+ ```
- ```text
- Forkchoice requested sync to new head number=117,076,468 hash=e3884c..bf4e2b
- ```
+ ```text
+ msg="Syncing: chain download in progress" synced=100.00% chain="176.01 GiB" headers=116,817,399@45.82GiB bodies=116,817,286@52.87GiB receipts=116,817,286@77.32GiB eta=77.430ms
+ ```
-
+ All the while, `op-geth` will also log the forkchoice update:
+
+ ```text
+ Forkchoice requested sync to new head number=117,076,468 hash=e3884c..bf4e2b
+ ```
+
+
+
+
+ Initial synchronization can take several hours to complete.
+
+ Snap sync in `Nethermind` works by:
+
+ 1. Downloading only the leaf nodes of the state tree
+ 2. Generating intermediate nodes locally
+ 3. Verifying the state root matches
+
+ This approach is up to 10 times faster than traditional full sync.
+
+
#### Full sync
-For OP Mainnet you will need access to the migrated database to run a full node with full sync.
-You can [migrate your own data directory](https://web.archive.org/web/20240110231645/https://blog.oplabs.co/reproduce-bedrock-migration/) or follow the options available for [archive nodes](#get-the-migrated-data-directory).
+ For OP Mainnet you will need access to the migrated database to run a full node with full sync.
+ You can [migrate your own data directory](https://web.archive.org/web/20240110231645/https://blog.oplabs.co/reproduce-bedrock-migration/) or follow the options available for [archive nodes](#get-the-migrated-data-directory).
-Initial full synchronization can take several days or weeks to complete. During this time, you will initially observe `op-node` deriving blocks from Ethereum without sending these blocks to `op-geth`.
-This means that `op-node` is requesting blocks from Ethereum one-by-one and determining the corresponding OP Mainnet blocks that were published to Ethereum.
+
+
+ Initial full synchronization can take several days or weeks to complete. During this time, you will initially observe `op-node` deriving blocks from Ethereum without sending these blocks to your execution client.
+
+
+
+ To use full sync with `Nethermind`, set the following configuration:
+
+ ```bash
+ ./Nethermind.Runner \
+ -c op-sepolia \
+ --Sync.SnapSync=false \
+ --Sync.FastSync=false \
+ --data-dir path/to/data/dir \
+ --JsonRpc.JwtSecretFile=./jwt.txt
+ ```
+
+ Full sync will download and verify every block from genesis, which takes significantly longer than snap sync but provides the strongest security guarantees.
+
+
+
+Both execution clients will receive blocks from `op-node` as it requests them from Ethereum one-by-one and determines the corresponding OP Mainnet blocks that were published.
You should see logs like the following from `op-node`:
```text
INFO [06-26|13:31:20.389] Advancing bq origin origin=17171d..1bc69b:8300332 originBehind=false
```
-Once the `op-node` has derived enough blocks from Ethereum, it will begin sending these blocks to `op-geth`.
-You should see logs like the following from `op-node`:
+Once the initial sync is complete, you'll see sync progress logs:
```text
INFO [06-26|14:00:59.460] Sync progress reason="processed safe block derived from L1" l2_finalized=ef93e6..e0f367:4067805 l2_safe=7fe3f6..900127:4068014 l2_unsafe=7fe3f6..900127:4068014 l2_time=1,673,564,096 l1_derived=6079cd..be4231:8301091
@@ -266,13 +345,24 @@ INFO [06-26|14:00:59.461] generated attributes in payload queue txs=1 timest
INFO [06-26|14:00:59.463] inserted block hash=e80dc4..72a759 number=4,068,015 state_root=660ced..043025 timestamp=1,673,564,098 parent=7fe3f6..900127 prev_randao=78e43d..36f07a fee_recipient=0x4200000000000000000000000000000000000011 txs=1 update_safe=true
```
-You should then also begin to see logs like the following from `op-geth`:
-
-```text
-INFO [06-26|14:02:12.974] Imported new potential chain segment number=4,068,194 hash=a334a0..609a83 blocks=1 txs=1 mgas=0.000 elapsed=1.482ms mgasps=0.000 age=5mo2w20h dirty=2.31MiB
-INFO [06-26|14:02:12.976] Chain head was updated number=4,068,194 hash=a334a0..609a83 root=e80f5e..dd06f9 elapsed="188.373µs" age=5mo2w20h
-INFO [06-26|14:02:12.982] Starting work on payload id=0x5542117d680dbd4e
-```
+You should then also begin to see logs from your execution client:
+
+
+
+ ```text
+ INFO [06-26|14:02:12.974] Imported new potential chain segment number=4,068,194 hash=a334a0..609a83 blocks=1 txs=1 mgas=0.000 elapsed=1.482ms mgasps=0.000 age=5mo2w20h dirty=2.31MiB
+ INFO [06-26|14:02:12.976] Chain head was updated number=4,068,194 hash=a334a0..609a83 root=e80f5e..dd06f9 elapsed="188.373µs" age=5mo2w20h
+ INFO [06-26|14:02:12.982] Starting work on payload id=0x5542117d680dbd4e
+ ```
+
+
+
+ * **Received New Block**: Block received with number, hash and extra data `21288296 (0xb61f74...cbfbe7), Extra Data: Titan (titanbuilder.xyz)`
+ * **Processed**: Block or block range processed, e.g., or `x4 21288291 .. 21288295` or `21288296`
+ * **Received ForkChoice**: Updates on the blockchain's canonical chain; with safe and finalized block, e.g., `21288296 (0xb61f74...cbfbe7), Safe: 21288252 (0x46906d...7777b8), Finalized: 21288221 (0x22a7d2...ebeae9)`
+ * **Synced Chain Head**: Latest synced block number and hash on the chain, e.g., `21288296 (0xb61f74...cbfbe7)`
+
+
## OP Mainnet archive nodes
@@ -335,7 +425,7 @@ In this section, you'll learn how to download and verify the pre-migrated databa
tar xvf mainnet-bedrock.tar.zst
```
- {
Configure op-geth for archive mode
}
+ {
Configure `op-geth` for archive mode
}
Set `--syncmode=full` and `--gcmode=archive` on `op-geth`.
diff --git a/pages/superchain/superchain-upgrades.mdx b/pages/superchain/superchain-upgrades.mdx
index ce78f9b4b..eeead0514 100644
--- a/pages/superchain/superchain-upgrades.mdx
+++ b/pages/superchain/superchain-upgrades.mdx
@@ -59,8 +59,8 @@ Networks that have opted into the [hard fork inheritance behavior](/superchain/s
The [`rollup.halt`](/operators/node-operators/configuration/execution-config#rolluphalt) flag is an opt-in configuration option available in both the execution and consensus layer node binaries.
Its primary function is to temporarily halt node activities, during the transition phase of an upgrade, if or when it encounters an incompatible or unsupported protocol version requirement.
-* Execution layer configuration: In the execution layer *(op-geth)*, the [`--rollup.halt`](/operators/node-operators/configuration/execution-config#rolluphalt) flag can be set to specify the level of incompatibility (major, minor, patch, none) that will trigger a halt. This ensures that nodes do not process transactions under unsupported protocol versions.
-* Consensus layer configuration: Similarly, in the consensus layer *(op-node)*, the [`--rollup.halt`](/operators/node-operators/configuration/consensus-config#rolluphalt) flag serves the same purpose, allowing nodes to halt when encountering incompatible protocol versions.
+* Execution layer configuration: In the execution layer *(`op-geth`)*, the [`--rollup.halt`](/operators/node-operators/configuration/execution-config#rolluphalt) flag can be set to specify the level of incompatibility (major, minor, patch, none) that will trigger a halt. This ensures that nodes do not process transactions under unsupported protocol versions.
+* Consensus layer configuration: Similarly, in the consensus layer *(`op-node`)*, the [`--rollup.halt`](/operators/node-operators/configuration/consensus-config#rolluphalt) flag serves the same purpose, allowing nodes to halt when encountering incompatible protocol versions.
Failing to upgrade your node with new hardfork rules will trigger the use of the `rollup.halt` flag on the Superchain signaling and your node will halt.
diff --git a/public/img/guides/node-operators/node-arch.svg b/public/img/guides/node-operators/node-arch.svg
index fbf8acd96..056ad4a0f 100644
--- a/public/img/guides/node-operators/node-arch.svg
+++ b/public/img/guides/node-operators/node-arch.svg
@@ -1 +1,4 @@
-
\ No newline at end of file
+
+
+
+
\ No newline at end of file
diff --git a/utils/calculator-helpers.ts b/utils/calculator-helpers.ts
index c2c9fcb26..1f9c39f58 100644
--- a/utils/calculator-helpers.ts
+++ b/utils/calculator-helpers.ts
@@ -55,7 +55,7 @@ export function resultsFeeScalarsAssumed(
transactionsPerDay: number, // e14
dataAvailabilityType: string, // E16
targetDataMargin: number, // E18
- isStateEnabled: string, // E24
+ sStateEnabled: string, // E24
maxChannelDuration: number // E22
): string {
const n25: number = calculateBlobLevelImpliedBlobFullness(
@@ -75,7 +75,7 @@ export function resultsFeeScalarsAssumed(
: `${Math.round(n25 * 100)}% Blob Fullness and ${
Math.round(n26 * 10) / 10
} Blobs per L1 Tx (Avg), `;
- const state = isStateEnabled === "Yes" ? " & State" : "";
+ const state = isStateEnabled === true ? " & State" : "";
return `Fee Scalars Assume: ${mode}Target a ${Math.round(
targetDataMargin
)}% Margin on DA${state}, ${
@@ -1080,4 +1080,4 @@ export const Avg_Total_Gas_Used_Per_L1_State_Proposal = 86847.5; // N12
export const FastLZ_Intercept = -42585600; // N13
export const FastLZ_Coefficient = 836500; // N14
export const FatLZ_Min_Transaction_Size = 100; // N15
-export const Avg_Total_Gas_Used_Per_L1_Fault_Proof_State_Proposal = 420926.0; // N16
\ No newline at end of file
+export const Avg_Total_Gas_Used_Per_L1_Fault_Proof_State_Proposal = 420926.0; // N16
diff --git a/words.txt b/words.txt
index 19a182f51..1950ed86b 100644
--- a/words.txt
+++ b/words.txt
@@ -236,7 +236,7 @@ multichain
multiclient
multisigs
MULTU
-nethermind
+Nethermind
NETRESTRICT
netrestrict
NETWORKID