Some questions that not clarify in the official OpStack Docs

[0xtrou]

Issue Description

1/ How to obtain peer id for p2p.static options? Can't find it
2/ Does the p2p sync make the nodes more stable? AFAIK, adding more nodes won't affect the stability of block production process since only one sequencer works at the genesis node?
3/ What is the process to upgrade the node software?
4/ Is it required to run geth node as archive mode?

Additional Information

No response

[opfocus]

(1) --p2p.static=/ip4/127.0.0.1/tcp/9003/p2p/16Uiu2HAkvoMNi6xLk32UFQLpVXDuXzT76AkeRVh7kder5RzewFx4 This is an example; for you, this peerID (16Uiu2HAkvoMNi6xLk32UFQLpVXDuXzT76AkeRVh7kder5RzewFx4) is incorrect. However, it can be used directly, enabling the op-node to run successfully without errors. At this point, we can check the op-node's logs, which will display its own peerID.

(2) I agree with your point of view: P2P synchronization merely speeds up the synchronization process for unsynchronized nodes, and replica nodes can obtain the unsafeL2block.

(3) Perhaps when upgrading node software, we only need to be mindful of backing up the 'geth' folder within the 'datadir' files.

(4) For a sequencer mode node, archive mode is required, but replica nodes do not need it.

[opfocus]

Is this the configuration of your replica node? If so, these configurations may be inappropriate and we will try to adjust it

[yohanelly95]

thats right, these are the configs of a replica node! what should be changed here? followed these steps here https://docs.optimism.io/builders/chain-operators/management/operations#adding-nodes

[opfocus]

My intuition tells me that we should follow the tutorial on running nodes more closely to run our replica nodes, but use the same rollup.json configuration op-node. I've tried adding it, but I didn't check it as carefully as you did

[yohanelly95]

am I missing any flags? Yes using the same rollup.json (op-node) and the same genesis.json (op-geth, op-node). What have I missed here?

[opfocus]

#17 (comment) This is my sharing, a bit hasty, if you find any problems, please tell me

[sbvegan]

1. op-node p2p has some subcommands that let you obtain peer IDs.
2. P2P sync is unrelated to stability.
3. I'm not sure what you mean by this. You can stop your node, upgrade the node software, and then restart the node. Note: when starting your node, op-geth should be started before op-node. When stopping your node, op-node should be stopped before op-geth. You also want to give op-geth ample time to shutdown, unclean shutdowns can result in corrupted databases.
4. No this is not a requirement.

[0xtrou]

Hi @opfocus @sbvegan, thank you for your responses.

Regarding the 3, it's important to upgrade/patch node software with zero downtime. I tried to upgrade the masternode (sequencer node) yesterday within my private OpStack chain, resulting the whole chain slow down for a couple of hours. There must be some recommendations for maintaining the chain's high availability.

My assumption would be to run at least two sequencer nodes (using the same private key), and make them two become the static nodes, the application nodes aka replica nodes availability will be maintained during the process of upgrading software.

How do you think? @opfocus @sbvegan

[0xtrou]

I will try to keep 2 master nodes running for a couple of days and then see.

[0xtrou]

btw thanks for both your help ;)

[0xtrou]

zero downtime upgrade, finally

[sbvegan]

This is somewhat similar to what we do in production. Our infrastructure runs on Kubernetes and our developer infrastructure team has implemented a Zero Downtime Deployment process by utilizing blue green deployment strategy.

This is the high level process, there are two sequencers (A: older software and B: new version):

• Wait for A and B to be in sync
• Stop A
• Start B with the latest block hash from A
• B continues to build the network

[luleigreat]

@0xtrou I also tried to run two sequencers , they can keey in sync with no user transactions. But when I send a transaction to the first sequencer, the blocks of the two sequencers forked, the second sequencer does not contain the tx sent to the first.

Did you run into this problem ? Can you share your configuration if not ? I would appreciate.

[0xtrou]

@sbvegan I tried op-node p2p <sequencer address> but it got stuck forever, don't know why

[opfocus]

If you're interested in exploring other avenues, I'd be happy to share my progress with you . I've halted for now as there's a viable way, but it's quite apparent there are other ways, just lacking exploration.

[0xtrou]

yeah ofc lmao

[opfocus]

Adding node shared form soyboy I got some high level instructions from an engineer. To add a peer:

1. create op-geth node, with geth init, and same genesis json file
2. create op-node, by starting with same rollup config json file
3. get the p2p address of one of the op-nodes
   4a. you can use the p2p RPC to get the two connected
   4b. or alternatively, add the multiaddress to the static-peers cli flag
   4c. advanced: rely on discovery process to discover the node of the same network. Need to run your own bootnode, or have public-facing nodes (with UDP port-forwarded)

My perspective is: 1. We've already implemented the 4b plan. 2. I find the 4C plan might be a bit challenging. 3. The 4a plan only mentions the addresses of the nodes, which seems quite appealing. https://geth.ethereum.org/docs/interacting-with-geth/rpc/ns-admin What are your thoughts?

[0xtrou]

hmm, from my perspective, and my case, are building a set of boot nodes (different from application nodes that their availability is not guaranteed), so I will highly rate the 4b plan

4a I didn't try yet, but it could be the same philosophy as 4b

4c, nope, maintaining high available bootnodes is critical IMO, so don't rely on the random nodes out there

[sbvegan]

Agreed, as work for snapsync support continues, I'd expect high available and trusted boot nodes to emerge. The conversation on that is on going.

[opfocus]

If you're willing to share your findings, you can share them here: #17