[Node Operator Question] Process exiting intermittently

[angusscott]

Are you running the most up to date node software?

• Yes

Did you check the documentation?

• Yes

Did you check for duplicate questions?

• Yes

Issue Description

upgraded my node (op-node to v1.71. and op-geth to op-geth-1.101308.2), but getting below errors and process exiting. My L1 chain is the latest version of erigon

Mar 12 17:21:37 HCAD6 haruko_app.sh[2947256]: t=2024-03-12T17:21:37+0000 lvl=info msg="loaded new runtime config values!"      p2p_seq_address=0xAAAA45d9549EDA09E70937013520214382Ffc4A2
Mar 12 17:21:37 HCAD6 haruko_app.sh[2947256]: t=2024-03-12T17:21:37+0000 lvl=eror msg="Outdated with major recommended protocol change" node=engine
Mar 12 17:21:37 HCAD6 haruko_app.sh[2947256]: t=2024-03-12T17:21:37+0000 lvl=eror msg="Outdated with major required protocol change" node=engine
Mar 12 17:21:37 HCAD6 haruko_app.sh[2947256]: t=2024-03-12T17:21:37+0000 lvl=eror msg="Opted to halt, unprepared for protocol change" required=v6.0.0 local=v6.0.0-2```

followed by the process exiting


### Protocol Description

op-node to v1.7.1 
op-geth-1.101308.2
Optimism

### Node Logs

```Mar 12 17:21:37 HCAD6 haruko_app.sh[2947256]: t=2024-03-12T17:21:37+0000 lvl=info msg="Optimistically queueing unsafe L2 execution payload" id=0x982110767029615a46366ac6bf34419247f9a9b3bd00bd4caebfc4c46ff55368:117332660
Mar 12 17:21:37 HCAD6 haruko_app.sh[2947256]: t=2024-03-12T17:21:37+0000 lvl=info msg="loaded new runtime config values!"      p2p_seq_address=0xAAAA45d9549EDA09E70937013520214382Ffc4A2
Mar 12 17:21:37 HCAD6 haruko_app.sh[2947256]: t=2024-03-12T17:21:37+0000 lvl=eror msg="Outdated with major recommended protocol change" node=engine
Mar 12 17:21:37 HCAD6 haruko_app.sh[2947256]: t=2024-03-12T17:21:37+0000 lvl=eror msg="Outdated with major required protocol change" node=engine
Mar 12 17:21:37 HCAD6 haruko_app.sh[2947256]: t=2024-03-12T17:21:37+0000 lvl=eror msg="Opted to halt, unprepared for protocol change" required=v6.0.0 local=v6.0.0-2```


### Additional Information

_No response_

### Feedback

_No response_

[sbvegan]

Request

• Can you provide your op-node and op-geth configurations?
• Can you provide your startup logs? That'll give us the version/commit you're running. It looks like you're running outdated software because v6.0.0-2 was set in op-node v1.5.1

My thoughts

Opted to halt, unprepared for protocol change suggests its halting because:

• --rollup.load-protocol-versions is set to true
• --rollup.halt is configured to major

Whats odd to me is that required=v6.0.0 local=v6.0.0-2 doesn't appear to be a major change.

Additional Information

Protocol Versions

Here's the specs with the details on the ProtocolVersion

The Protocol Version documents the progression of the total set of canonical OP-Stack specifications. Components of the OP-Stack implement the subset of their respective protocol component domain, up to a given Protocol Version of the OP-Stack.

OP-Stack mods, i.e. non-canonical extensions to the OP-Stack, are not included in the versioning of the Protocol. Instead, mods must specify which upstream Protocol Version they are based on and where breaking changes are made. This ensures tooling of the OP-Stack can be shared and collaborated on with OP-Stack mods.

The Protocol Version is NOT a hardfork identifier, but rather indicates software-support for a well-defined set of features introduced in past and future hardforks, not the activation of said hardforks.

Changes that can be included in prospective Protocol Versions may be included in the specifications as proposals, with explicit notice of the Protocol Version they are based on. This enables an iterative integration process into the canonical set of specifications, but does not guarantee the proposed specifications become canonical.

Note that the Protocol Version only applies to the Protocol specifications with the Superchain Targets specified within. This versioning is independent of the Semver versioning used in OP Stack smart-contracts, and the Semver-versioned reference software of the OP-Stack.

Erigon L1

I've seen an issue with Erigon as an L1 node before where you have to enable --l1.trustrpc

If you're running an Erigon Ethereum execution client for your L1 provider you will need to include --l1.trustrpc. At the time of writing, Erigon doesn't support the eth_getProof that we prefer to use to load L1 data for some processing in op-node. The trustrpc flag makes it use something else that erigon supports, but the op-node can't verify for correctness.

source: https://docs.optimism.io/builders/node-operators/management/configuration#l1trustrpc

[angusscott]

@sbvegan Thanks, this was ultimately the solution