Skip to content
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

chore: discv5 re-org setup #1815

Merged
merged 4 commits into from
Jun 22, 2023
Merged

chore: discv5 re-org setup #1815

merged 4 commits into from
Jun 22, 2023

Conversation

SionoiS
Copy link
Contributor

@SionoiS SionoiS commented Jun 21, 2023

Description

Setting the code for the move of discv5 out of node. Note that some changes might look weird without context, feel free to ask.

Changes

  • keys, netconfig and ENR are created when the app initialize
  • modified node builder

tracking #1812

@SionoiS SionoiS marked this pull request as ready for review June 21, 2023 17:10
Copy link
Collaborator

@Ivansete-status Ivansete-status left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR! However, I see that are a few points that I'd adapt a bit more, IMHO.

I hope that helps :)

@@ -94,8 +97,137 @@ func version*(app: App): string =

## Initialisation

proc networkConfiguration(conf: WakuNodeConf): NetConfigResult =
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think is better to have these two WakuNodeConf-procs in https://github.com/waku-org/nwaku/blob/master/apps/wakunode2/config.nim

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not entirely sure I agree. These procs are concerned with translating the already-initialised config to interpreted config types that are specific to the app. In contrast, config.nim is only interested in parsing and initialising external config and is already complex enough as is without more app constructs. I'd be happy if we move these two functions to a new network_config.nim module to keep app.nim cleaner, but happy to go with majority opinion here. :)

Copy link
Contributor Author

@SionoiS SionoiS Jun 22, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lets rename config.nim to ext-config.nim then? or user-config.nim

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, the best place I think is the next file, where the NetConfig is declared:
https://github.com/waku-org/nwaku/blob/master/waku/v2/node/config.nim

rng: ref HmacDrbgContext
nodeKey: crypto.PrivateKey
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO, the App shouldn't know anything about nodekey. I believe we need to keep the App as simple and generic as possible. The only one interested in the nodekey is the node instance, which is already part of the App.

The same applies to netConf. Both the nodeKey and netConf are derived/created from the information in conf. And I think it should be the WakuNodeConf (config.nim module) the one in charge of translating the information from the outer world (the user params) into the wakunode space.

Copy link
Contributor Author

@SionoiS SionoiS Jun 22, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with the principle but both discv5 and node require keys for setup that why it's higher in the call chain.

Would calling it appkey helps :P

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We indeed have an appKey if it's used to setup both the discovery and the node. The appKey is then used to initialise the (logically distinct) keys for the node and discv5 with the same value.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok understood :)

However, given that discv5 should act as a separate service, a good place to start it would be in the next proc:

proc setupMonitoringAndExternalInterfaces*(app: var App): AppResult[void] =

The key could be generated there from the 'key' info in the config.

@@ -467,7 +531,7 @@ proc initNode(conf: WakuNodeConf,

proc setupWakuNode*(app: var App): AppResult[void] =
## Waku node
let initNodeRes = initNode(app.conf, app.rng, app.peerStore, app.dynamicBootstrapNodes)
let initNodeRes = initNode(app.conf, app.netConf, app.rng, app.nodeKey, app.record, app.peerStore, app.dynamicBootstrapNodes)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment doesn't add nothing new from what I already mentioned :)
However, I believe we could generate the netConf, nodeKey and record inside the initNode with the information provided by the app.conf param.

Copy link
Contributor Author

@SionoiS SionoiS Jun 22, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't do that because discv5 will not be in initNode but in setupWakuNode <- could be renamed to Waku app?

BTW the term app and node are not super defined IMO. The binary is a Waku node but internally it's called app and has a node inside it's confusing.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay got it! What if we try to do something similar that is done with the rest server?
I mean, start the discv5 service in

let startRestServerRes = startRestServer(app, app.conf.restAddress, Port(app.conf.restPort + app.conf.portsShift), app.conf)

I don't have strong opinion about renaming the setupWakuNode. Both cases can be correct :)

@SionoiS
Copy link
Contributor Author

SionoiS commented Jun 22, 2023

For more context check out d19d192

Copy link
Contributor

@jm-clius jm-clius left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally happy with this direction. Agree that we can start clarifying terms between "app" and "node" (e.g. appKey). I know this is WIP to prepare for next step in refactoring, so feel free to address suggestions in this or next PR.

rng: ref HmacDrbgContext
nodeKey: crypto.PrivateKey
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We indeed have an appKey if it's used to setup both the discovery and the node. The appKey is then used to initialise the (logically distinct) keys for the node and discv5 with the same value.

@@ -94,8 +97,137 @@ func version*(app: App): string =

## Initialisation

proc networkConfiguration(conf: WakuNodeConf): NetConfigResult =
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not entirely sure I agree. These procs are concerned with translating the already-initialised config to interpreted config types that are specific to the app. In contrast, config.nim is only interested in parsing and initialising external config and is already complex enough as is without more app constructs. I'd be happy if we move these two functions to a new network_config.nim module to keep app.nim cleaner, but happy to go with majority opinion here. :)

var node: WakuNode

let pStorage = if peerStore.isNone(): nil
else: peerStore.get()

let rng = crypto.newRng()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mmm. Wait, was this rng generation redundant before as it's also an argument for this function?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes that's what I concluded.

@SionoiS
Copy link
Contributor Author

SionoiS commented Jun 22, 2023

Github is not showing latest commit for this branch here, weird...

https://github.com/waku-org/nwaku/tree/chore-discv5-reorg 4 commits but only 3 here?

Copy link
Collaborator

@Ivansete-status Ivansete-status left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey! I approve now so that I don't block the upcoming PR. I think it will get much clearer by then :)
Thanks for this!

@SionoiS SionoiS merged commit 44f9d8d into master Jun 22, 2023
9 of 13 checks passed
@SionoiS SionoiS deleted the chore-discv5-reorg branch June 22, 2023 20:58
@SionoiS SionoiS mentioned this pull request Jun 28, 2023
1 task
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants