[OP Stack Deployment] Running a Full Node for a deployed OP Stack Chain

[yohanelly95]

Did you check the documentation?

• Yes

Did you check for duplicate questions?

• Yes

Issue Description

After successfully running a sequencer node with p2p enabled. Adding a full node to the network seems to be failing. The opp2p_peers shows that both nodes have connected with each other after adding --p2p.static flag with the archival nodes p2p id to the full node.
Running only op-node and op-geth for the full node. The full node attempts connections with random p2p addresses that show in the op-node logs.

Logs

op-geth command:

./build/bin/geth   --datadir ./datadir   --http   --http.corsdomain="*"   --http.vhosts="*"   --http.addr=0.0.0.0   --http.api=web3,debug,eth,txpool,net,engine   --ws   --ws.addr=0.0.0.0   --ws.port=8546   --ws.origins="*"   --ws.api=debug,eth,txpool,net,engine   --syncmode=snap --networkid=11106812  --authrpc.vhosts="*"   --authrpc.addr=0.0.0.0   --authrpc.port=8551   --authrpc.jwtsecret=./jwt.txt   --rollup.disabletxpoolgossip=true  --verbosity=3 --gcmode=full

logs:

op-node command:

./bin/op-node --l2=http://localhost:8551 --l2.jwt-secret=./jwt.txt --sequencer.l1-confs=5 --verifier.l1-confs=4 --rollup.config=./rollup.json --rpc.addr=0.0.0.0 --rpc.port=8547 --rpc.enable-admin --p2p.sequencer.key=${p2p_key} --metrics.enabled --l1=${L1_RPC} --l1.rpckind=alchemy --l1.http-poll-interval=2s --l1.epoch-poll-interval=2s --syncmode=execution-layer --p2p.static=/ip4/${EXTERNAL_IP}/tcp/9222/p2p/16Uiu2HAmLDD8sBhVfM5sJ962Y1u8th23PahkcieLAKsrpTWxmR2q --safedb.path=./safedb --l2.skip-sync-start-check=true

logs:

Additional Information

Ran this set up for 3 days but the results were the same, the full node never synced and always returns block number as 0 for the eth_getBlockByNumber RPC call. All appropriate ports are enabled (tcp/udp) so this could not be a firewall issue causing this.

Feedback

The default port for P2P is 9222 and not 9003 as mentioned in the docs.

[yohanelly95]

Followed the steps mentioned here: #17 (comment)

This is what op-node looks like:

This will take many days to sync it seems since its too many blocks behind the safe L1 block in this case which is an Base Sepolia (2s block time).

We really do need L3 configs from the OP team, or some insights on how to make it run better/best practices! @sbvegan

[yohanelly95]

logs of the sequencer's op-node:

It attempts to connect to seemingly random nodes and then fails to do so. It fails to publish newly created block with error: node has no p2p signer

[opfocus]

• L3 is relatively unknown territory for me and I haven't tried it yet.
• I think it's some other mistake. Enable p2p on an op-node will try to connect to any node found, most of which will be invalid (this shouldn't be a problem).
• Regarding that error, I tend to think that enable p2p of sequencer's op-node will not cause such an error.
• Full mode is significantly slower than sync, but there may not be much difference for the newly established op stack chain testnet
• Use full mode instead of sync mode to avoid the problem of eth_getBlockByNumber return 0
• The last thing I want to mention is that the purpose of this troubleshooting is to add replica nodes, so I think it should not cause errors in the sequencer node.
• I only tested the troubleshooting example. So that's just one way of adding replica nodes

My understanding of adding replica nodes is that they are on different hosts to facilitate different users to process transactions and query status. Apart from this function, there seems to be no other reason to add a replica node. Just one sequencer node is enough.

The above is just my personal opinion

[yohanelly95]

I have removed the --p2p.disabled flag from the sequencer's op-node. And opp2p_peers true rpc call returns the correct replica nodes p2p address since I used the sequencer's op-node p2p address in the replicas --p2p.static= flag. Both are showing each other as peers.

For syncing an L3 it does take a significant amount of time since we Advancing bq origin from the L3 genesis timestamp when it was deployed on the L2. So even a 1 day is 43,200 blocks or so and the op-node takes around 600ms to index a single block.

[yohanelly95]

Yes this is the main reason we need replica nodes, so that validators in our protocol can use their own chain rpc to fetch block numbers/hashes etc.

[opfocus]

If your goal is to deploy L3 in a production environment in the short term, I recommend you contact the op-team https://optimism.io/build