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

feat(c-bindings): rln relay #2544

Merged
merged 1 commit into from
Mar 27, 2024
Merged

feat(c-bindings): rln relay #2544

merged 1 commit into from
Mar 27, 2024

Conversation

richard-ramos
Copy link
Member

@richard-ramos richard-ramos commented Mar 20, 2024

Description

Exposes the rln relay configuration to the bindings.

Issue

closes #2454

Copy link

github-actions bot commented Mar 20, 2024

You can find the image built from this PR at

quay.io/wakuorg/nwaku-pr:2544-rln-v2-false

Built from 9afbf17

@richard-ramos richard-ramos force-pushed the bindings/rln branch 2 times, most recently from 444a599 to 2a06e55 Compare March 21, 2024 15:25
@richard-ramos
Copy link
Member Author

richard-ramos commented Mar 21, 2024

Oops! I forgot to append the proof to the RLN message. Will add that in a separate commit

EDIT: added in 964d7ab

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.

It looks great indeed!

Nevertheless, I wonder if we could split the PR in two:

  • refactor node initialization
  • addition of rln config

cheers!

@richard-ramos
Copy link
Member Author

refactor node initialization

Done in #2547

addition of rln config

I'll use this PR for this once I rebase it against #2547

@richard-ramos
Copy link
Member Author

Done! PR rebased!

@richard-ramos richard-ramos marked this pull request as ready for review March 25, 2024 03:36
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.

LGTM! Thanks!
I just added some nitpick comments ;P
Cheers


if jsonNode.contains("clusterId"):
if jsonNode["clusterId"].kind != JsonNodeKind.JInt:
errorResp = "The clusterId config param should be a int"
Copy link
Collaborator

Choose a reason for hiding this comment

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

Tiny typo :)

Suggested change
errorResp = "The clusterId config param should be a int"
errorResp = "The clusterId config param should be an int"

@@ -149,6 +165,29 @@ proc parseTopics(jsonNode: JsonNode, conf: var WakuNodeConf) =
else:
conf.topics = @["/waku/2/default-waku/proto"]

proc parseRLNRelay(jsonNode: JsonNode, conf: var WakuNodeConf, errorResp: var string): bool =
if not jsonNode.contains("rlnRelay"):
Copy link
Collaborator

Choose a reason for hiding this comment

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

I wonder if we should use the same style as the wakunode has. Hyphen-separated terms.

Suggested change
if not jsonNode.contains("rlnRelay"):
if not jsonNode.contains("rln-relay"):

Comment on lines 178 to 187
conf.rlnRelayCredPath = jsonNode{"credentialPassword"}.getStr()
conf.rlnRelayEthClientAddress = EthRpcUrl.parseCmdArg(jsonNode{"ethClientAddress"}.getStr("http://localhost:8540"))
conf.rlnRelayEthContractAddress = jsonNode{"contractAddress"}.getStr()
conf.rlnRelayCredPassword = jsonNode{"credentialPassword"}.getStr()
conf.rlnRelayUserMessageLimit = uint64(jsonNode{"userMessageLimit"}.getInt(1))
conf.rlnEpochSizeSec = uint64(jsonNode{"epochSizeSec"}.getInt(1))
conf.rlnRelayCredIndex = some(uint(jsonNode{"membershipIndex"}.getInt()))
conf.rlnRelayDynamic = jsonNode{"dynamic"}.getBool()
conf.rlnRelayTreePath = jsonNode{"treePath"}.getStr()
conf.rlnRelayBandwidthThreshold = jsonNode{"bandwidthThreshold"}.getInt()
Copy link
Collaborator

Choose a reason for hiding this comment

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

Analogue to my previous comment, I suggest using the same names as in wakunode app:

$ ./build/wakunode2 --help | grep rln
 --rln-relay-cred-path     The path for peristing rln-relay credential.
 --rln-relay-eth-client-address  HTTP address of an Ethereum testnet client e.g., http://localhost:8540/
 --rln-relay-eth-contract-address  Address of membership contract on an Ethereum testnet.
 --rln-relay-cred-password  Password for encrypting RLN credentials.
 --rln-relay-eth-private-key  Private key for broadcasting transactions.
 --rln-relay-user-message-limit  Set a user message limit for the rln membership registration. Must be a positive
 --rln-relay-epoch-sec     Epoch size in seconds used to rate limit RLN memberships. Default is 1 second.
 --rln-relay               Enable spam protection through rln-relay: true|false [=false].
 --rln-relay-membership-index  the index of the onchain commitment to use.
 --rln-relay-dynamic       Enable  waku-rln-relay with on-chain dynamic group management: true|false
 --rln-relay-id-key        Rln relay identity secret key as a Hex string.
 --rln-relay-id-commitment-key  Rln relay identity commitment key as a Hex string.
 --rln-relay-tree-path     Path to the RLN merkle tree sled db (https://github.com/spacejam/sled).
 --rln-relay-bandwidth-threshold  Message rate in bytes/sec after which verification of proofs should happen [=0].
 --rln-relay-tree-path     Path to the RLN merkle tree sled db (https://github.com/spacejam/sled).
warning: could not open directory 'postgres-data/': Permission denied

Copy link
Member Author

Choose a reason for hiding this comment

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

I can use the hyphens to separate the words but adding the rln prefix I'm not sure, because it currently looks like this:

{
   "port": 123,
   "host": "0.0.0.0",
   "relay": true,
   "rlnRelay": {
          "enabled": "true",
         "ethClientAddress": "http://localhost:8545",
         "membershipIndex": 2,
         ...
    }
}

And seems to me that adding the rln prefix would be redundant, as the values are already part of a rlnRelay section. A possibility could be to put everything a single level deep (i.e., move all the items from rlnRelay into the root json, but seems to me that it's not benefiting from the possibilities of json allowing more logical groups.

Would something like this work? (i.e. having the rln-relay prefix be instead the key that holds all the rln related configs):

{
   "port": 123,
   "host": "0.0.0.0",
   "relay": true,
   "rln-relay": {
          "enabled": "true",
         "eth-client-address": "http://localhost:8545",
         "membership-index": 2,
         "bandwidth-threshold": 1,
         ...
    }
}

Copy link
Collaborator

Choose a reason for hiding this comment

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

Yes, I think this is the best balanced option (simplicity vs consistency)
image

Comment on lines +71 to +89
if conf.clusterId == 1:
let twnClusterConf = ClusterConf.TheWakuNetworkConf()
if len(conf.shards) != 0:
conf.pubsubTopics = conf.shards.mapIt(twnClusterConf.pubsubTopics[it.uint16])
else:
conf.pubsubTopics = twnClusterConf.pubsubTopics

# Override configuration
conf.maxMessageSize = twnClusterConf.maxMessageSize
conf.clusterId = twnClusterConf.clusterId
conf.rlnRelay = twnClusterConf.rlnRelay
conf.rlnRelayEthContractAddress = twnClusterConf.rlnRelayEthContractAddress
conf.rlnRelayDynamic = twnClusterConf.rlnRelayDynamic
conf.rlnRelayBandwidthThreshold = twnClusterConf.rlnRelayBandwidthThreshold
conf.discv5Discovery = twnClusterConf.discv5Discovery
conf.discv5BootstrapNodes =
conf.discv5BootstrapNodes & twnClusterConf.discv5BootstrapNodes
conf.rlnEpochSizeSec = twnClusterConf.rlnEpochSizeSec
conf.rlnRelayUserMessageLimit = twnClusterConf.rlnRelayUserMessageLimit
Copy link
Collaborator

Choose a reason for hiding this comment

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

We have a similar structure in

if conf.clusterId == 1:
let twnClusterConf = ClusterConf.TheWakuNetworkConf()
if len(conf.shards) != 0:
conf.pubsubTopics = conf.shards.mapIt(twnClusterConf.pubsubTopics[it.uint16])
else:
conf.pubsubTopics = twnClusterConf.pubsubTopics
# Override configuration
conf.maxMessageSize = twnClusterConf.maxMessageSize
conf.clusterId = twnClusterConf.clusterId
conf.rlnRelay = twnClusterConf.rlnRelay
conf.rlnRelayEthContractAddress = twnClusterConf.rlnRelayEthContractAddress
conf.rlnRelayDynamic = twnClusterConf.rlnRelayDynamic
conf.rlnRelayBandwidthThreshold = twnClusterConf.rlnRelayBandwidthThreshold
conf.discv5Discovery = twnClusterConf.discv5Discovery
conf.discv5BootstrapNodes =
conf.discv5BootstrapNodes & twnClusterConf.discv5BootstrapNodes
conf.rlnEpochSizeSec = twnClusterConf.rlnEpochSizeSec
conf.rlnRelayUserMessageLimit = twnClusterConf.rlnRelayUserMessageLimit

I wonder if we could encapsulate that somehow. Maybe in a separate PR

Base automatically changed from node-init to master March 26, 2024 13:10
Copy link
Contributor

@SionoiS SionoiS left a comment

Choose a reason for hiding this comment

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

I got a feeling of deja vu...

LGTM

@richard-ramos
Copy link
Member Author

I got a feeling of deja vu...

LGTM

deja vu

@richard-ramos richard-ramos merged commit 2aa835e into master Mar 27, 2024
13 of 15 checks passed
@richard-ramos richard-ramos deleted the bindings/rln branch March 27, 2024 14:08
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.

chore: support RLN-relay in libwaku
3 participants