Skip to main content
The proposed Ecotone upgrade impacts node operators because of the new Beacon endpoint for op-node. Soon after the Ecotone activation, batch transactions will be sent as 4844 blobs, and blobs can only be retrieved from Beacon nodes. This means node operators will need access to a beacon node/consensus client (i.e. Lighthouse, Lodestar, Nimbus, Prysm, Teku, etc.).

​
Preparing your node

These steps are necessary for EVERY node operator:
1

Update to the latest release

See the Software Releases page for the minimum release version.
2

Configure the Ecotone activation date

  • If you are operating a node for an OP Chain that has an entry in the superchain-registry, the Ecotone activation date is handled automatically by both execution clients:
      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.
        3

        Prepare for activation

        • All node operators must set an L1 beacon value in your op-node as soon as you update to the latest release.
        --l1.beacon value                                                      ($OP_NODE_L1_BEACON)
          HTTP endpoint Address of L1 Beacon-node.
        • Either run your own L1 beacon node like Lighthouse or use a third-party beacon node RPC service, like Quicknode.

        ​
        Configure a blob archiver

        There is a configurable beacon-archiver that will allow nodes to sync blob data that is older than 18 days - after blobs are 18 days old, normal beacon nodes will “prune” or remove them. If your node is already in sync with the head of the chain, you won’t need to use a beacon-archiver.
        • If you’re spinning up a new node, if you load it from a snapshot that’s within 18 days (the amount of time until blobs are pruned) you will not need to use a beacon-archiver at all as long as your node does not fall offline for more than 18 days.
        • If you’re running a new node that is syncing more than 18 days (the amount of time until blobs are pruned) after Ecotone launch, then you will need to configure a beacon-archiver on the op-node.
        --l1.beacon-archiver value                                                      ($OP_NODE_L1_BEACON)
          HTTP Endpoint of a Blob Archiver or an L1 Beacon-node that does not prune blobs
        Choose one of the following options to access a beacon archiver endpoint:
        • Option 1: Run a beacon node with blobs pruning disabled. For example, you can run your own L1 beacon node like Lighthouse and configure it to retain all blobs and use that endpoint here.
        # lighthouse
--prune-blobs=false
        • Option 2: Run a blob-archiver and configure op-node to use the blob-archiver API service with --l1.beacon-archiver. Running a blob-archiver is lighter weight than running a beacon node that does not prune blobs: https://github.com/base-org/blob-archiver. There is a configurable beacon-archiver that will allow nodes to sync blob data that is older than 18 days - after blobs are 18 days old, normal beacon nodes will “prune” or remove them. If your node is already in sync with the head of the chain, you won’t need to use a beacon-archiver.
          • If you’re spinning up a new node, if you load it from a snapshot that’s within 18 days (the amount of time until blobs are pruned) you will not need to use a beacon-archiver at all as long as your node does not fall offline for more than 18 days.
          • If you’re running a new node that is syncing more than 18 days (the amount of time until blobs are pruned) after Ecotone launch, then you will need to configure a beacon-archiver on the op-node.
        --l1.beacon-archiver value                                                      ($OP_NODE_L1_BEACON)
          HTTP Endpoint of a Blob Archiver or an L1 Beacon-node that does not prune blobs
        • Option 3: If you don’t want to operate any Beacon infrastructure, you can use an external service that provides access to pruned Blobs.