optimism
optimism copied to clipboard
ethereum-optimism
Local rpc node is always 6-20 blocks behind compared to the optimism official rpc node.
Describe the bug Local rpc node is always 6-20 blocks behind compared to the optimism official rpc node.
This is the configuration for docker-compose `COMPOSE_PROJECT_NAME=op-replica COMPOSE_FILE=replica.yml:replica-shared.yml:replica-toml.yml ETH_NETWORK=mainnet DATA_TRANSPORT_LAYER__L1_RPC_ENDPOINT=<Local L1 RPC NODE> DATA_TRANSPORT_LAYER__L2_RPC_ENDPOINT=https://mainnet.optimism.io SEQUENCER_CLIENT_HTTP=https://mainnet.optimism.io SHARED_ENV_PATH=../envs/mainnet GCMODE=archive L2GETH_IMAGE_TAG=0.5.24 DTL_IMAGE_TAG=0.5.47 HC_IMAGE_TAG= L2GETH_HTTP_PORT=9991 L2GETH_WS_PORT=9992 DTL_PORT=7878 GETH_INIT_SCRIPT=check-for-chaindata-berlin.sh HEALTHCHECK__REFERENCE_RPC_PROVIDER=https://mainnet.optimism.io HEALTHCHECK__TARGET_RPC_PROVIDER=http://l2geth-replica:8545 RESTART=unless-stopped ROLLUP_BACKEND=l2
DATA_TRANSPORT_LAYER__DEFAULT_BACKEND=l2 DATA_TRANSPORT_LAYER__L1_GAS_PRICE_BACKEND=l2 DATA_TRANSPORT_LAYER__SYNC_FROM_L1=false DATA_TRANSPORT_LAYER__SYNC_FROM_L2=true`
It takes some time for blocks to propagate throughout the network
Would you be able to elaborate? I tried running an Optimism node, and noticed it was always behind my reference alchemy node, and would process a batch of blocks every few seconds. It seems like when you run your own Optimism node, it depends on the L2 DTL to keep your node up to date, and doesn't communicate at all with other nodes? Is this how it is supposed to work? For reference, I am running arbitrum, avax, polygon, aurora nodes, and they are all able to stay in sync perfectly. What's the point of running an optimism node if its always so far behind.
Would you be able to elaborate?
It depends on how you're running the node. In the current ("legacy") version of the system, there are two operating modes, L1 sync and L2 sync. L1 sync is always behind the Sequencer because it only looks at L1 data. L2 sync should be much faster but has a trust assumption on the L2 node you're syncing from. So if you want fast sync, first make sure that you're using L2 sync.
The reason for this L1/L2 sync split is a bunch of legacy code from a long time ago. Bedrock improves on this significantly by removing the distinction between L1/L2 sync and by propagating "unsafe" blocks over a p2p network and marking them "safe" when those same blocks can be derived purely based on L1 data. This means Bedrock nodes should stay in sync almost perfectly, with some minor delay as blocks get propagated over the p2p network. You can run a Bedrock Goerli node to see this in action today. Bedrock is coming to mainnet soon(tm).
Would you be able to elaborate?
It depends on how you're running the node. In the current ("legacy") version of the system, there are two operating modes, L1 sync and L2 sync. L1 sync is always behind the Sequencer because it only looks at L1 data. L2 sync should be much faster but has a trust assumption on the L2 node you're syncing from. So if you want fast sync, first make sure that you're using L2 sync.
The reason for this L1/L2 sync split is a bunch of legacy code from a long time ago. Bedrock improves on this significantly by removing the distinction between L1/L2 sync and by propagating "unsafe" blocks over a p2p network and marking them "safe" when those same blocks can be derived purely based on L1 data. This means Bedrock nodes should stay in sync almost perfectly, with some minor delay as blocks get propagated over the p2p network. You can run a Bedrock Goerli node to see this in action today. Bedrock is coming to mainnet soon(tm).
So you are saying that the p2p aspect would also improve the ability to stay synced from L2 is that correct? Because the delayed blocks we mentioned are even when syncing from L2 currently.
Yes, that's correct, p2p should be much faster and you avoid the extra overhead of the DTL