[Node Operator Question] Syncing questions and switching from full to archival

[Marketen]

Are you running the most up to date node software?

• Yes

Did you check the documentation?

• Yes

Did you check for duplicate questions?

• Yes

Issue Description

Hey! Im new to the OP stack and I want to run my own node. I have been reading documentation (specially node operators section) but there are a few questions I still have:

Im using snap sync in my op-geth & op-node (pretty much the default configuration on both of them). Things are looking okay. My op-node is serving payloads for my op-geth to sync. (op-node logsOptimistically inserting unsafe L2 execution payload to drive EL sync) && op-geth logs INFO [05-09|14:51:10.925] Syncing beacon headers downloaded=90,162,176 left=29,670,747 eta=14m38.479s

Few questions:

• Why is my snap sync downloading all headers? From my op-geth logs, it seems it is downloading headers for all the +119.833.350 blocks available. Shouldnt it only download a chunk of the most recent headers?
• Once snap sync finishes, for how long will my node store information about new tx and blocks? What blocks will I be able to query? Im running a fullnode.
• If I want to switch to an archival node (l2geth legacy included), what would the best course of action be? Im guessing I'd have to delete all my op-geth data and sync from bedrock datadir. Besides syncing op-geth from datadir and setting flag --gcmode="archive" is there anything else I should do?
• I need help understanding the output of op-node call optimism_syncStatus. There are some camps initialized to 0x000..000. When do these become available?

{"jsonrpc":"2.0","id":1,"result":{"current_l1":{"hash":"0x0000000000000000000000000000000000000000000000000000000000000000","number":0,"parentHash":"0x0000000000000000000000000000000000000000000000000000000000000000","timestamp":0},"current_l1_finalized":{"hash":"0xd9a661cbf16860a7a2b0cc0750f92067420118a491a22e17e6e5ced00b012126","number":19833051,"parentHash":"0xd5a994268ad79925ecdc32c60ff19dd0381f3b056c02daacb89dbe741135095b","timestamp":1715264471},"head_l1":{"hash":"0x9daf97d044d3daa868922f775fa467ecaca119410c3b34b9f430f5c716b91f86","number":19833133,"parentHash":"0xc944713155e263c7e1263a1ad0a9997013d38e08fc3817ba94e28c87ec19e0f3","timestamp":1715265467},"safe_l1":{"hash":"0xb2f795ce17c3045e5efb159e641d797f30ab22378b3ace0a587cd46bdf3e3d3c","number":19833083,"parentHash":"0x7aa3228b8d52d71d00d2410e55b7efe021409610cb3434e64e4e2d5f3ce572a6","timestamp":1715264855},"finalized_l1":{"hash":"0xd9a661cbf16860a7a2b0cc0750f92067420118a491a22e17e6e5ced00b012126","number":19833051,"parentHash":"0xd5a994268ad79925ecdc32c60ff19dd0381f3b056c02daacb89dbe741135095b","timestamp":1715264471},"unsafe_l2":{"hash":"0x9ca576ed9adbf0edcb138f9fc55cee6a217a1c714d7050476031f6547c03c828","number":119833350,"parentHash":"0x3fb9239b1e6dcf58da93a309472331acc644fcd482d9e09ab6bd1ad76a08b144","timestamp":1715265477,"l1origin":{"hash":"0xfa28a258ef1330f8fa67f1689828c8269cde297ffc12bc63dee4bba5c73fceb0","number":19833127},"sequenceNumber":4},"safe_l2":{"hash":"0x0000000000000000000000000000000000000000000000000000000000000000","number":0,"parentHash":"0x0000000000000000000000000000000000000000000000000000000000000000","timestamp":0,"l1origin":{"hash":"0x0000000000000000000000000000000000000000000000000000000000000000","number":0},"sequenceNumber":0},"finalized_l2":{"hash":"0x0000000000000000000000000000000000000000000000000000000000000000","number":0,"parentHash":"0x0000000000000000000000000000000000000000000000000000000000000000","timestamp":0,"l1origin":{"hash":"0x0000000000000000000000000000000000000000000000000000000000000000","number":0},"sequenceNumber":0},"pending_safe_l2":{"hash":"0x0000000000000000000000000000000000000000000000000000000000000000","number":0,"parentHash":"0x0000000000000000000000000000000000000000000000000000000000000000","timestamp":0,"l1origin":{"hash":"0x0000000000000000000000000000000000000000000000000000000000000000","number":0},"sequenceNumber":0}}}

Protocol Description

opgeth version: v1.101311.0
opnode version: v1.7.1
network name: op mainnet
chainid: 10
l1chain: 1

Node Logs

op-node:

t=2024-05-09T15:01:17+0000 lvl=info msg="Received signed execution payload from p2p" id=0x90cf9babbbcf86d134468ef84ffac454d1364506b47e7915c08d0248949e7d0e:119834050 peer=16Uiu2HAm6h61WPbW7tySjVqJsF1ArvQ5G2HWSGicNTh31TBdHcVB
t=2024-05-09T15:01:17+0000 lvl=info msg="Optimistically inserting unsafe L2 execution payload to drive EL sync" id=0x90cf9babbbcf86d134468ef84ffac454d1364506b47e7915c08d0248949e7d0e:119834050
t=2024-05-09T15:01:17+0000 lvl=info msg="Sync progress" reason="unsafe payload from sequencer while in EL sync" l2_finalized=0x0000000000000000000000000000000000000000000000000000000000000000:0 l2_safe=0x0000000000000000000000000000000000000000000000000000000000000000:0 l2_pending_safe=0x0000000000000000000000000000000000000000000000000000000000000000:0 l2_unsafe=0x90cf9babbbcf86d134468ef84ffac454d1364506b47e7915c08d0248949e7d0e:119834050 l2_time=1715266877 l1_derived=0x0000000000000000000000000000000000000000000000000000000000000000:0

op-geth:

INFO [05-09|14:58:32.163] Syncing beacon headers                   downloaded=115,419,136 left=4,413,787   eta=1m58.958s
INFO [05-09|14:58:33.419] Forkchoice requested sync to new head    number=119,833,968 hash=728f4f..870560
INFO [05-09|14:58:35.517] Forkchoice requested sync to new head    number=119,833,969 hash=938cff..d4689d
INFO [05-09|14:58:37.498] Forkchoice requested sync to new head    number=119,833,970 hash=1525fe..3a135d
INFO [05-09|14:58:39.561] Forkchoice requested sync to new head    number=119,833,971 hash=ad8cf7..8aa7be
INFO [05-09|14:58:40.290] Syncing beacon headers                   downloaded=115,886,080 left=3,946,843   eta=1m46.221s

Additional Information

No response

Feedback

No response

[sbvegan]

Why is my snap sync downloading all headers? From my op-geth logs, it seems it is downloading headers for all the +119.833.350 blocks available. Shouldnt it only download a chunk of the most recent headers?

I'm not sure about this, but it seems like this is the normal behavior. The go-ethereum snap sync docs say:

To summarize, snap sync progresses in the following sequence:

• download and verify headers
• download block bodies and receipts. In parallel, download raw state data and build state trie
• heal state trie to account for newly arriving data

source: https://geth.ethereum.org/docs/fundamentals/sync-modes#snap-sync

Once snap sync finishes, for how long will my node store information about new tx and blocks? What blocks will I be able to query? Im running a fullnode.

Full nodes keep all the block data of the most recent 128 blocks. Historical execution rpc requests beyond that need to go to an archive node.

If I want to switch to an archival node (l2geth legacy included), what would the best course of action be? Im guessing I'd have to delete all my op-geth data and sync from bedrock datadir. Besides syncing op-geth from datadir and setting flag --gcmode="archive" is there anything else I should do?

This is right, you need to spin up a new archive node. There isn't a migration process, just a new sync.

I need help understanding the output of op-node call optimism_syncStatus. There are some camps initialized to 0x000..000. When do these become available?

Can you provide output so we can see? Is your node fully synced?

General note

You'll want to run the latest software versions, you can find them here.

[Marketen]

Can you provide output so we can see? Is your node fully synced?

Everything alright! Once my op-geth finished downloading block bodies and receipts, the optimism_syncStatus call is returning camps as expected

Thanks for your help!