Bug Description
We have launched version 1.9.0 of Optimism along with beta.2 of our smart contracts using the useCustomToken feature. Everything is functioning correctly on our servers, and blocks are being created as expected.
To enhance fault tolerance, we decided to deploy additional nodes, using the example from this guide.
However, after launching a second node (op-geth + op-node), it started syncing but eventually created a fork and got stuck. This was unexpected because the setup should have maintained synchronization across nodes without forking
Thats why we have some questions
How the optimism is protected from L1 forks as far we use some L1 rpc which can be unstable
Can we make so optimism can roll back some block and try to resolve itself automatically
How is fork possible in case when we have 1 block proposer?
Steps to Reproduce
There is not steps to reproduce but we have some questions
Expected behavior
It's should working perfectly without forks and we need to have possibility to switch from one node to another is something happened with a disk
Environment Information:
Ubuntu 20.04
optimism 1.9.0 + beta.2 smart contracts
Configurations:
We do not use the super chain registry all vars are following the documentation.
Bug Description We have launched version 1.9.0 of Optimism along with beta.2 of our smart contracts using the useCustomToken feature. Everything is functioning correctly on our servers, and blocks are being created as expected.
To enhance fault tolerance, we decided to deploy additional nodes, using the example from this guide.
However, after launching a second node (op-geth + op-node), it started syncing but eventually created a fork and got stuck. This was unexpected because the setup should have maintained synchronization across nodes without forking
Thats why we have some questions
Steps to Reproduce
Expected behavior It's should working perfectly without forks and we need to have possibility to switch from one node to another is something happened with a disk
Environment Information:
Configurations: We do not use the super chain registry all vars are following the documentation.
Logs: 7|op-node | t=2024-09-02T15:11:11+0000 lvl=info msg="Scheduled sequencer action" delta=1.999644808s 7|op-node | t=2024-09-02T15:11:12+0000 lvl=warn msg="unexpected block author" topic=blocksV3 err= peer=16Uiu2HAmLPbSkxyYGYiqaBHyCP1SdFwpVcLhqtTDnj64gEzq1Kmn addr=0x99d508fAd3d9aeE9eA4f206191c6dB915221cE12 expected=0x7b04384c0a67E27E95c508c8B8D79afA9080f5f5
Info about first block where is different state
Additional context We can provide more information per request
⚠️ Notice: Issues that do not include the following sections will be subject to closure:
Please ensure all required sections are filled out accurately to expedite the debugging process and improve issue resolution efficiency.