feat: add debug.setSyncTarget console command (#31375)

[demoncoder-crypto]

No description provided.

[MariusVanDerWijden]

Have you even tried this once?
It's not working like this...
I will push an update to this which makes it work

[MariusVanDerWijden]

Not a big fan of this tbh, open for suggestions here

[demoncoder-crypto]

Do you need the complete change here, please do let me know I am more than happy to work on it, Thanks for the reply .

[demoncoder-crypto]

Have you even tried this once?
It's not working like this...
I will push an update to this which makes it work, @MariusVanDerWijden I have not tested it at all I just wanted to see if my given direction is correct, so I can iteratively fix and work upon the solution. I am sorry for the mess but thought rather than making a faulty implementation right I should ask for general guidance first and then proceed to make it work as this is my first time working with Ethereum.

[demoncoder-crypto]

So any suggestions on how to proceed with this, if my track is right should I proceed to improve this implementation?

[MariusVanDerWijden]

I'm currently assigned to this, but I rewrote it, so someone else should also take a look, maybe @jwasinger
It does change something fundamental: now we try to request a head from the network during the forkchoice. If we get that, we will try to sync to it. This makes it possible for us to start a sync even if we have never seen a newPayload. Its something that CLs wanted for a long time

[jwasinger]

Sure, I'll take a look.

[jwasinger]

This makes it possible for us to start a sync even if we have never seen a newPayload. Its something that CLs wanted for a long time.

What's the rationale behind this? Presumably this is so that the CL can initiate the EL sync while they are syncing. But if they already know the sync target, what's stopping them from send us a payload (before they are synced, to kick-off the sync on our end).

we can better react to scenarios of long non-finality where we have to pick a chain to sync to

Same question. This ought to be a feature on the CL given the leader-follower relationship between the CL and EL.

I'm guessing the answer is that we don't control the development on various CLs, and so it's convenient to have this feature on Geth to save some sync time.

[MariusVanDerWijden]

Split into two, try all peers in downloader

[fjl]

@MariusVanDerWijden please push your changes

[MariusVanDerWijden]

I have created a different PR here that implements this in a cleaner way: #31928

[MariusVanDerWijden]

#31928 was merged, please rebase and clean this up so we can also merge this feature @demoncoder-crypto

[jwasinger]

We already have the FullSyncTester which already performs the desired functionality of this PR (except the sync target is supplied with a flag, meaning geth has to be restarted to change it). We should reuse that code path as much as possible for this new feature.

the Geth team will be the users of this method, and it's intended use is to allow Geth to track a chosen chain in the case of an adverse beacon chain network event (like what we saw on holesky).

My assumption is that users of setSyncTarget will disconnect the CL pair when actively using the new method, as otherwise FCU invocations from the CL will redirect the sync (cc @MariusVanDerWijden if this assumption is wrong)

[jwasinger]

I've added an alternative PR here.