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(api): validate rln message before sending (rest + rpc) #1968

Merged
merged 5 commits into from
Sep 1, 2023

Conversation

alrevuelta
Copy link
Contributor

@alrevuelta alrevuelta commented Aug 30, 2023

Description:

  • Adds validation to rest+rpc api so that an rln message proof is verified before sending the message. If the proof is wrong or the message is considered spam, the message won't be sent and it will error out so that the user is aware that the message didn't made it.
  • Adds validation to rest+rpc api so that it errors out when trying to publish to a topic that the node is not subcribed, since it risks that there are no connected peers "listening" in that topic.
  • Update tests so that they work with rln enabled/disabled.

How to test it:

./build/wakunode2 \
--rln-relay=true \
--rpc-address=0.0.0.0 \
--rpc-admin=true \
--rest=true \
--rest-admin=true \
--rest-private=true \
--rest-address=0.0.0.0 \
--rln-relay-dynamic=true \
--rln-relay-cred-password=password \
--rln-relay-cred-path=rlnKeystore_420.json \
--rln-relay-membership-index=420 \
--rln-relay-tree-path=rln_tree_1.db \
--rln-relay-eth-contract-address=0x8e1F3742B987d8BA376c0CBbD7357fE1F003ED71  \
--rln-relay-eth-client-address=wss://you_endpoint \
--log-level=debug

Rest API

curl -X 'POST'   'localhost:8645/relay/v1/messages/%2Fwaku%2F2%2Fdefault-waku%2Fproto'   -H 'accept: */*'   -H 'Content-Type: application/json'   -d '{
  "payload": "string",
  "contentTopic": "string",
  "version": 0,
  "timestamp": 0
}'

RPC API

curl http://localhost:8545 -d '{"jsonrpc":"2.0","method":"post_waku_v2_relay_v1_message","params":["/waku/2/default-waku/proto", {"payload": "SGkgdGhlcmUgZXRoY2M=", "timestamp": 1, "contentTopic": "some-topic", "ephemeral": false}],"id":1}' -H 'Content-Type: application/json'

raise newException(ValueError, "Failed to publish: error appending RLN proof to message")

# validate the message before sending it
let result = node.wakuRlnRelay.validateMessage(message)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

unsure if its ok to use validateMessage here, since inside it updates a bunch of metrics and call updateLog. Any opinion @rymnc

Copy link
Contributor

@rymnc rymnc Aug 30, 2023

Choose a reason for hiding this comment

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

yeah I don't think we should use validateMessage, because if you try publishing the same message it would get stuck since the proofMetadata would exist in the nullifierLog afaik. should probably split the function into the check, and then the state update

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Something like this 74d38f5 ?

Copy link
Contributor

Choose a reason for hiding this comment

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

yes!

@github-actions
Copy link

You can find the image built from this PR at

quay.io/wakuorg/nwaku-pr:1968

@alrevuelta alrevuelta marked this pull request as ready for review August 31, 2023 10:45
Copy link
Member

@vpavlin vpavlin left a comment

Choose a reason for hiding this comment

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

lgtm

let rootIndex = rlnPeer.groupManager.indexOfRoot(proof.merkleRoot)
waku_rln_valid_messages_total.observe(rootIndex.toFloat())
return MessageValidationResult.Valid

proc validateMessageAndUpdateLog*(
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@rymnc created this function, which is like the old validateMessage but now we have:

  • validateMessage
  • validateMessageAndUpdateLog

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 for it! I just added a question to learn sth :)

Comment on lines +194 to +195
proc subscribedTopics*(w: WakuRelay): seq[PubsubTopic] =
return toSeq(GossipSub(w).topics.keys())
Copy link
Collaborator

Choose a reason for hiding this comment

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

Morning! Is this directly related to the purpose of the PR?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

nope, but imho there is no need to use generators for this. the amount of topics is not enough to justify it. also using poorly documented features such as lent lent is a bad idea, unless strictly needed.

Copy link
Contributor

@rymnc rymnc left a comment

Choose a reason for hiding this comment

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

LGTM, minor comment

Comment on lines 113 to 133
if result == MessageValidationResult.Invalid:
raise newException(ValueError, "Failed to publish: invalid RLN proof")
elif result == MessageValidationResult.Spam:
raise newException(ValueError, "Failed to publish: limit exceeded, try again later")
elif result == MessageValidationResult.Valid:
debug "Publishing message WITH RLN proof", pubSubTopic=pubSubTopic
let publishFut = node.publish(pubsubTopic, message)
if not await publishFut.withTimeout(futTimeout):
raise newException(ValueError, "Failed to publish: timed out")
else:
raise newException(ValueError, "Failed to publish: unknown RLN proof validation result")
else:
raise newException(ValueError, "Failed to publish: RLN enabled but not mounted")

# if RLN is not mounted, publish the message as is
else:
debug "Publishing message WITHOUT RLN proof", pubSubTopic=pubSubTopic
let publishFut = node.publish(pubsubTopic, message)

if not await publishFut.withTimeout(futTimeout):
raise newException(ValueError, "Failed to publish: timed out")
Copy link
Contributor

Choose a reason for hiding this comment

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

I think these ValueError's can be CatchableError's

Copy link
Contributor

Choose a reason for hiding this comment

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

also, maybe we can operate on the same message in both cases? i.e rln is enabled, rln is disabled?
then we can save some loc by having just one

let publishFut = node.publish(pubsubTopic, message)
if not await publishFut.withTimeout(futTimeout):
    raise newException(ValueError, "Failed to publish: timed out")

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ow indeed, that was a bit spageti.
c964916

@alrevuelta alrevuelta merged commit 05c9886 into master Sep 1, 2023
13 checks passed
@alrevuelta alrevuelta deleted the simulate-tx-before-sending branch September 1, 2023 13:04
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

4 participants