-
Notifications
You must be signed in to change notification settings - Fork 19.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rpc: Add isSynced method. #23099
Comments
As this is a problem touching all clients and not just geth - I think the best place to raise this is: https://ethereum-magicians.org Also if we want to add a new method to RPC we need to add it to the spec - so it would really be good to run it at magicians first - we cannot just add it to geth. And depending on your use-case maybe it is also an idea to check the timestamp of the last block to get an idea if you are synced. But it's not a trivial problem. Maybe elaborate a bit more on your use-case: so for what do you need the information? |
When connecting to a node, we know if we should expect this node to be synced. We're adding ethereum to https://github.com/decred/dcrdex and we are currently discussing this around decred/dcrdex#1082 (comment) When a dex's server's operator starts the dex, we want to know if the chains it is running are synced. The reasons for this should be obvious? Any recommendation for time's to check? When's that ice age happening again, need to watch for that? ;P |
We can not unilaterally implement this feature, I would suggest raising this issue here: https://github.com/ethereum/execution-apis I would check if the block was within the last minute, even with ice age we should only see blocks on average every 30 seconds. |
System sync must be done from scratch to work properly |
Rationale
Why should this feature exist?
When contacting a node for data about the state of the chain, we want to know if the node thinks it is synced. That is, has blocks up to the highest known header of a peer(s).
Currently, all we can know is if the node is currently syncing. syncProgress will return nil before and after syncing has started, so connecting to a node, if progress is nil, we don't know which.
We have explored several options to try and determine whether syncing has started at all. One is waiting for a block to come in, and then checking syncProgress. This is sub optimal because we need to wait for some time if the chain was already synced. Another is to check for peers, and then check syncProgress if peers > 0, but there is a window between finding a peer and sync starting, or it could drop the peer before syncing, so this is racy.
What are the use-cases?
When connecting to a node, we know if we should expect this node to be synced. I realize there could be blocks the node doesn't know about, but its best guess is better than mine.
Implementation
Do you have ideas regarding the implementation of this feature?
Check if we have any peers. Check if peer's best block matches ours. Possibly check the best block's age isn't under some time that would suggest we aren't just connected to another peer that is not synced.
Are you willing to implement this feature?
Uhhhh. Maybe?
The text was updated successfully, but these errors were encountered: