Operators
Nodes
Node management
Using Snap Sync

Using snap sync for node operators

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 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.

  • For OP Mainnet, node operators will be able to sync without having to download the bedrock datadir.
  • This also enables nodes to join the network after Ecotone activates without requiring a blob archiver.
  • Archive nodes are also fully supported.

Enable snap sync for your node

⚠️

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, then you must open the port specified for UDP.
  • If you set --port, then you must open the port specified for TCP.
  • The only exception is for sequencers and transaction ingress nodes.

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.
--syncmode=execution-layer (not default)
  • Option 2: Archive sync with required datadir 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.
--syncmode=execution-layer (not default)
  • 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.
--syncmode=consensus-layer (default)

Enabling execution layer sync for alternative clients

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 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 is required. For other OP Stack networks, no datadir is required.

To enable execution layer sync for these clients, set the following flags on op-node:

# for reth
--syncmode=execution-layer (not default)
--l2.enginekind=reth (not default)
 
# for erigon
--syncmode=execution-layer (not default)
--l2.enginekind=erigon (not default)

Next steps