-
Notifications
You must be signed in to change notification settings - Fork 31
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
Overhaul of ENR implementation - part I #707
Conversation
kdeme
commented
Jun 21, 2024
- Rework adding and updating of fields by having an insert call that gets used everywhere. Avoiding also duplicate keys. One side-effect of this is that ENR sequence number will always get updated on an update call, even if nothing changes.
- Deprecate initRecord as it is only used in tests and is flawed
- Assert when predefined keys go into the extra custom pairs. Any of the predefined keys are only to be passed now via specific parameters to make sure that the correct types are stored in ENR.
- Clearify the Opt.none behaviour for Record.update
- When setting ipv6, allow for tcp/udp port fields to be used default
- General clean-up
- Rework/clean-up completely the ENR tests.
- Rework adding and updating of fields by having an insert call that gets used everywhere. Avoiding also duplicate keys. One side-effect of this is that ENR sequence number will always get updated on an update call, even if nothing changes. - Deprecate initRecord as it is only used in tests and is flawed - Assert when predefined keys go into the extra custom pairs. Any of the predefined keys are only to be passed now via specific parameters to make sure that the correct types are stored in ENR. - Clearify the Opt.none behaviour for Record.update - When setting ipv6, allow for tcp/udp port fields to be used default - General clean-up - Rework/clean-up completely the ENR tests.
## If none of the k:v pairs are changed, the sequence number of the `Record` | ||
## will still be incremented and a new signature will be applied. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've checked and allthe usages through discv5 updateRecord
call in nimbus-eth2 will only call this if the provided extraField actually changes, avoiding a seqNum update on same update with same data. Nevertheless, perhaps this is still something to re-add...
func find(pairs: openArray[FieldPair], key: string): Opt[int] = | ||
## Search for key in key:value pairs. | ||
## | ||
## Returns some(index of key) if key is found. Else returns none. | ||
for i, (k, v) in pairs: | ||
if k == key: | ||
return Opt.some(i) | ||
Opt.none(int) | ||
|
||
func insert(pairs: var seq[FieldPair], item: FieldPair) = | ||
## Insert item in key:value pairs. | ||
## | ||
## If a FieldPair with key is already present, the value is updated, otherwise | ||
## the pair is inserted in the correct position to keep the pairs sorted. | ||
let index = find(pairs, item[0]) | ||
if index.isSome(): | ||
pairs[index.get()] = item | ||
else: | ||
pairs.insert(item, pairs.lowerBound(item, cmp)) | ||
|
||
func insert(pairs: var seq[FieldPair], b: openArray[FieldPair]) = | ||
## Insert all items in key:value pairs. | ||
for item in b: | ||
pairs.insert(item) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could use some other structure than a sequence (e.g. btree , table, etc.) but that seemed (?) kind of overkill considering an ENR will hold typically hold 8 k:v pairs in beacon, or perhaps 11 when we add ipv6, and can be max. 300 bytes.