[Node Operator Question] Snapsync feature is not working well

[kangsorang]

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

I realize that snapsync is not supported in Optimism. yet :)
However, based on recent PRs (ethereum-optimism/optimism#6243), it looks like snapsync is close to being supported and the behavior has been verified.
It looks like it was a feature test internally, and snapsync is such a cool feature that I decided tried to synchronize using snapsync(on the Sepolia-Base network), and while the behavior is confirmed, some test cases seem to have issues.

I'd like to know if there's something wrong with the behavioral environment variables, configuration, or something else I'm not aware of for some of the problem cases.

Here's what I tested.

I've configured two sets as shown below.

• Geth 1 (full sync completed)

• Node (pair with Geth 1)

• Geth 2 (run with config --syncmode=snap)

• Node (pair with Geth 2, run with config --syncmode=execution-layer, --l2.skip-sync-start-check=true)

And Geth 2 is connected to Geth 1 as static peer.

On geth(Geth 2), the following snapsync synchronization steps are confirmed by logs to proceed normally.

• Syncing: beacon headers download
• Syncing: chain download
• Syncing: state download
• Syncing: state healing

Finally, I can see the statement "Snap sync complete, auto disabling".
In a normal case, I could see the log below.

INFO [01-08|16:35:29.770] Imported new potential chain segment     number=4,465,520 hash=2c1803..e91fe7 blocks=1    txs=2    mgas=0.068  elapsed=5.730ms    mgasps=11.941 snapdiffs=12.83KiB triedirty=1.66MiB
INFO [01-08|16:35:29.776] Chain head was updated                   number=4,465,520 hash=2c1803..e91fe7 root=e6a03a..06fef6 elapsed=4.861417ms
INFO [01-08|16:35:31.046] Imported new potential chain segment     number=4,465,521 hash=2f9f5f..cc9b45 blocks=1    txs=2    mgas=0.068  elapsed=5.201ms    mgasps=13.155 snapdiffs=13.37KiB triedirty=1.67MiB
INFO [01-08|16:35:31.051] Chain head was updated                   number=4,465,521 hash=2f9f5f..cc9b45 root=d847c3..c83c19 elapsed=4.272042ms

However, sometimes it happens that only the following log persists and no more blocks are generated.

INFO [01-08|16:57:31.231] Forkchoice requested sync to new head    number=4,466,181 hash=f3947e..553ade finalized=unknown
INFO [01-08|16:57:33.085] Forkchoice requested sync to new head    number=4,466,182 hash=221aee..cd496e finalized=unknown
INFO [01-08|16:57:35.086] Forkchoice requested sync to new head    number=4,466,183 hash=8196fb..2d05c8 finalized=unknown
INFO [01-08|16:57:37.092] Forkchoice requested sync to new head    number=4,466,184 hash=0834c2..b23690 finalized=unknown

In the case of the problem, I can see that the "reconciled with L1" process is not progressing at the op-node and is stuck, so the L2 SYNC STATUS is stuck at block 0, unable to go any further.(SAFE, FINALIZE = 0)
Could you possibly know the cause?

Protocol Description

op-geth v1.101304.2
op-node v1.4.0
chainId: 84532
network: 84532

Node Logs

fail-geth.log
fail-node.log
success-geth.log
success-node.log

Additional Information

Feedback

No response

[opfocus]

I haven't received any confirmation that op-geth currently supports snap mode. As far as I know, it is not supported in snap mode. I hope others can verify this information. CC @sbvegan

[sbvegan]

The short answer is that snap sync is not fully supported yet. You need to set --syncmode=full and resync.

[kangsorang]

Thank you for your response. I've updated the text a bit more. Could you please check it out?

[sbvegan]

Hey @kangsorang I read over the new description. Unfortunately I don't have the capacity to support features that haven't been fully implemented. There is likely something under the hood that needs to be implemented and thats probably the source of the issue. Snap sync should be coming soon because it is necessary for us to support a post 4844 world. If you're still getting trouble after its officially supported, please open another thread and we can get to the bottom of it.

[0xHansLee]

Hello @sbvegan, I'm Hans from Kroma, a layer 2 being developed with Op Stack codebase.

Kroma utilizes zk tree instead of Merkle Patricia Trie (MPT), which required us to enable snap sync with this zk tree. We are also planning to provide the snap sync with 4844 supporting. During the implementation process, however, we encountered this issue and conducted testing on the Op Stack chain (as described above) and we confirmed that the same problem occurred. Is there a way we can contribute to resolving this issue? If it's already a known issue being worked on, please let us know. Thank you!

[github-actions[bot]]

Hey @kangsorang, We hope your recent question was resolved to your satisfaction. Your feedback is invaluable and helps us improve our support services. Could you spare a moment to fill out a short feedback survey. Thank you for helping us improve our developer community.