optimism: Can not start new node with `./bin/op-node` command

Describe the bug I’m following the offical docs. but I’m stucking at this step

To Reproduce I used command following:

./bin/op-node \                                                                                                                   ✔  ⬢ 16.19.1   1.20.2  16:07:49 
    --l2=http://localhost:8551 \
    --l2.jwt-secret=./jwt.txt \
    --sequencer.enabled \
    --sequencer.l1-confs=3 \
    --verifier.l1-confs=3 \
    --rollup.config=./rollup.json \
    --rpc.addr=0.0.0.0 \
    --rpc.port=8547 \
    --p2p.listen.ip=0.0.0.0 \
    --p2p.listen.tcp=9003 \
    --p2p.listen.udp=9003 \
    --rpc.enable-admin \
    --p2p.sequencer.key="my_sequencer_key" \
    --l1="https://endpoints.omniatech.io/v1/eth/goerli/public" \
    --l1.rpckind="alchemy"

Then I get the following errors:

  ERROR[03-09|16:07:56.953] failed to fetch runtime config data      err="failed to fetch unsafe block signing address from system config: failed to verify retrieved proof against state root: value 0 in storage proof does not match proven value at key 0x65a7ed542fb37fe237fdfbdd70b31598523fe5b32879e307bae27a0bd9581c08 (path 31a88f3936348d602f3078126bdcd162c575cb17fb9bbfe2dab00b167bd295c3)"

Screenshots If applicable, add screenshots to help explain your problem. Screenshot 2023-03-09 at 16 17 38

System Specs:

OS: MacOS 13.2.1
Chip M1

Additional Context I found 0x65a7ed542fb37fe237fdfbdd70b31598523fe5b32879e307bae27a0bd9581c08 and 31a88f3936348d602f3078126bdcd162c575cb17fb9bbfe2dab00b167bd295c3 from the ERROR above are hardcoded in the source code, so am I making a mistake at some step?

About this issue

Original URL
State: closed
Created a year ago
Comments: 18 (6 by maintainers)

Most upvoted comments

The header-fetch error happens when running old op-node software that didn’t support the L1 ethereum Shanghai/Capella upgrade yet, and thus fails to verify the blocks past that upgrade (upgrade was March 14 for Goerli L1).

The signing-address fetch error (with the “failed to verify retrieved proof”) is unrelated, and happens when the L1 RPC does not fully support eth_getProof (common, happens with Erigon and node providers that use Erigon), or if the SystemConfig is not present on the L1 (if you are trying to run an alt op-chain this may be the case). A work-around is to use the --l1.trustrpc flag, to fallback to direct retrieval of the system configuration data, and not verify with a proof. If you trust the RPC you use for L1, that’s a valid way to load system configuration. If you do not trust the L1 RPC, and they do not provide support for eth_getProof, you should switch to a different RPC provider.

protolambda on May 16, 2023

@protolambda I’m getting the same error as reported by OP (no pun intended) in the issue.

The contracts are successfully deployed to Polygon (although I went into that timeout issue and had to do manual txs using MetaMask rather than “cast”), as expected for an EVM-native chain. Deployer/Admin: https://polygonscan.com/address/0x53d44EbC95990fF2bDd2Fd427C4E9AEE8e76CB0c

So, L1’s network ID is 137 and L2’s ID is 133.

I don’t know if I can call it a “custom L2” as I didn’t change - beyond the necessary customizations guided by the OP Stack Docs - the codebase , available here and here.

danimesq on May 16, 2023

@danimesq and where/how is the L2 deployed? Is it a custom L2? Optimism Bedrock does not officially support Polygon as L1. You may have to change the block-header and/or state-proof verification to be compatible with Polygon.

protolambda on May 16, 2023