p2p/enode: use unix timestamp as base ENR sequence number #19903
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
karalabe
force-pushed
the
enr-timestamp-seq
branch
from
e1615fb
to
5e64cc0
Compare
|
The general issue with timestamp as sequence number is that we cannot sign new records faster than once per second. Otherwise the sequence number may advance too fast and the original problem is not solved at all. One idea we had in the triage today was to increase the granularity to millisecond. Another approach would be keeping the sequence number in two parts, with a timestamp part + update counter. |
This changes the local ENR update mechanism to block for up to 1ms in LocalNode.Node when the previous update was less than 1ms ago. To make this work, the granularity of sequence numbers is increased to millisecond.
fjl
force-pushed
the
enr-timestamp-seq
branch
from
e252e2a
to
018c8af
Compare
|
We did it! Merged after > 2 years. 😁 |
This was referenced Sep 23, 2022
yongjun925
pushed a commit
to DODOEX/go-ethereum
that referenced
this pull request
Dec 3, 2022
…9903) This PR ensures that wiping all data associated with a node (apart from its nodekey) will not generate already used sequence number for the ENRs, since all remote nodes would reject them until they out-number the previously published largest one. The big complication with this scheme is that every local update to the ENR can potentially bump the sequence number by one. In order to ensure that local updates do not outrun the clock, the sequence number is a millisecond-precision timestamp, and updates are throttled to occur at most once per millisecond. Co-authored-by: Felix Lange <fjl@twurst.com>
nibty
pushed a commit
to FairCrypto/go-ethereum
that referenced
this pull request
Apr 10, 2024
…9903) This PR ensures that wiping all data associated with a node (apart from its nodekey) will not generate already used sequence number for the ENRs, since all remote nodes would reject them until they out-number the previously published largest one. The big complication with this scheme is that every local update to the ENR can potentially bump the sequence number by one. In order to ensure that local updates do not outrun the clock, the sequence number is a millisecond-precision timestamp, and updates are throttled to occur at most once per millisecond. Co-authored-by: Felix Lange <fjl@twurst.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR ensures that wiping all data associated with a node (apart from its key) will not generate already used sequence number for the ENRs, since all remote nodes would reject them until they out-number the previously published largest one.