17/WAKU-RLN-RELAY: Revise spec for its draft version #484

staheri14 · 2022-02-08T21:52:44Z

It is the spec counterpart of waku-org/nwaku#714
Closes waku-org/nwaku#714

jm-clius · 2022-02-09T10:16:23Z

content/docs/rfcs/17/README.md

+The value of `T` is application-dependent.
+See section [Recommended System Parameters](#recommended-system-parameters) for some recommended ways to set a sensible `T` value.
+Peers subscribed to a spam-protected `pubsubTopic` are only allowed to send one message per `epoch`
+(messaging rate MAY be enforced for `WakuMessages` with a specific `contetTopic` published on a `pubsubTopic`, but that is an implementation choice).


Suggested change

(messaging rate MAY be enforced for `WakuMessages` with a specific `contetTopic` published on a `pubsubTopic`, but that is an implementation choice).

(messaging rate MAY be enforced for `WakuMessages` with a specific `contentTopic` published on a `pubsubTopic`, but that is an implementation choice).

thanks, done in e8095c5

jm-clius

A good read!

oskarth

Nice to see this come together!

oskarth · 2022-02-10T04:20:39Z

content/docs/rfcs/17/README.md



 # Flow
+The messaging rate is set to 1 per `epoch`, 
+where `epoch` indicates the number of `T` seconds elapsed since the Unix epoch event.


Do we need T, or could we consider making T more descriptive? it seems more like a local variable

It seems like we have:

message-rate 1
epoch

Epoch is a counter for the multiples of T (epoch=current Unix epoch time/ T), so they are not the same. T is the length of each epoch. I guess that the naming is confusing, let me know if you have any suggestions for better naming.

epoch=current Unix epoch time/ T I find this rather confusing, I keep re-reading it but it doesn't quite seem right to me:

epoch is being "redefined" inside a definition

we introduce a generic "T" parameter

Why not do something like:

unix time epoch is a well understood standard for seconds since 1970

call T period

Example:

unix_time is 1644810116s

period is 30s

epoch is lceil(unix_time/period)

Note that epoch refers to epoch in RLN and not Unix epoch. This means a message can only be sent every period, where period is up to the application.

(This assumes we want to keep epoch, but I suppose it is used everywhere so might as well keep using it. We should be explicit about this not being Unix epoch though).

oskarth · 2022-02-10T04:21:34Z

content/docs/rfcs/17/README.md

+where `epoch` indicates the number of `T` seconds elapsed since the Unix epoch event.
+The value of `T` is application-dependent.
+See section [Recommended System Parameters](#recommended-system-parameters) for some recommended ways to set a sensible `T` value.
+Peers subscribed to a spam-protected `pubsubTopic` are only allowed to send one message per `epoch`


Is one message hardcoded or a variable? Either case should make it explicit

Messaging rate is always 1 per some unit of time which is defined by T. It is a fixed value and the reason is that

The current rln lib does not have support for a higher messaging rate (higher degree polynomials)

In the other library developed by Blagoj, the support for a higher messaging rate is excluded as the same effect can be captured by tweaking the epoch duration. This means probably messaging rate is going to be always 1.

Changing the messaging rate to higher than 1 will affect the slashing process described in the spec (for which there is no clear definition of internal nullified either), so I'd say let's keep it simple and stick to the messaging rate of 1.

That makes sense! In that case we can make it explicitly that it is hardcoded to message per epoch per definition.

I'm still not clear the use of T here, seems like this could be clarified. See #484 (comment)

That makes sense! In that case we can make it explicitly that it is hardcoded to message per epoch per definition.

Sure, I'll update it

I'm still not clear the use of T here, seems like this could be clarified. See #484 (comment)

Please see this comment of mine https://github.com/vacp2p/rfc/pull/484/files#r804929807

oskarth · 2022-02-10T04:22:23Z

content/docs/rfcs/17/README.md

+The value of `T` is application-dependent.
+See section [Recommended System Parameters](#recommended-system-parameters) for some recommended ways to set a sensible `T` value.
+Peers subscribed to a spam-protected `pubsubTopic` are only allowed to send one message per `epoch`
+(messaging rate MAY be enforced for `WakuMessages` with a specific `contentTopic` published on a `pubsubTopic`, but that is an implementation choice).


What do we mean by an implementation choice?

Perhaps we could add this as a new paragraph, remove () and say "could be" but "not supported right now ~"

In fact, it is supported in the nim implementation, but it does not affect the specification as nowhere in the specs peers exchange the pubsubTopic or the contetTopic for which the rln-relay is enabled.

Sounds like it is underspecified right now? Which is ok, we can make it explicit. Implementation choice makes it seem arbitrary, but perhaps it is more that this is deferred to a higher level layer, such a specific chat protocol built on top?

Right, it is up to the higher-level protocols to dictate such granularity. I'll update the description accordingly.

oskarth · 2022-02-10T04:22:54Z

content/docs/rfcs/17/README.md

 ## SetUp and Registration
-A peer willing to publish a message is required to register. 
+Peers subscribed to a specific `pubsubTopic` form a [rln group](/spec/32).


rln or RLN? I'd say RLN everywhere to be consistent maybe

sure, revised.

oskarth · 2022-02-10T04:23:08Z

content/docs/rfcs/17/README.md

+See section [Recommended System Parameters](#recommended-system-parameters) for some recommended ways to set a sensible `T` value.
+Peers subscribed to a spam-protected `pubsubTopic` are only allowed to send one message per `epoch`
+(messaging rate MAY be enforced for `WakuMessages` with a specific `contentTopic` published on a `pubsubTopic`, but that is an implementation choice).
+
 ## SetUp and Registration


Suggested change

## SetUp and Registration

## Setup and Registration

thanks, done.

content/docs/rfcs/17/README.md

oskarth · 2022-02-10T04:27:47Z

content/docs/rfcs/17/README.md

-An overview of routing procedure is depicted in Figure 2.
+Proof generation relies on the knowledge of Merkle tree root `merkle_root` and `authPath` which both require access to the membership Merkle tree. 
+Getting access to the Merkle tree can be done in various ways. 
+One way is that all the peers construct the tree locally.


Below paragraph should be together same

Can you please clarify this? do you mean to combine the two paragraphs?

content/docs/rfcs/17/README.md

oskarth · 2022-02-10T04:29:27Z

content/docs/rfcs/17/README.md


-The `merkle_root` is an array of 32 bytes which holds the root of membership group Merkle tree at the time of publishing the message.
+The `merkle_root` is an array of 32 bytes in little-endian order which holds the root of membership group Merkle tree at the time of publishing the message.


These data types can we put them in a more clear list, table or ABNF form if protobuf isn't precise enough? E.g. https://rfc.vac.dev/spec/7/#abnf

I moved them inside a table 5eecaf2

oskarth · 2022-02-10T04:30:49Z

content/docs/rfcs/17/README.md

+In the proof of concept implementation of `17/WAKU-RLN-RELAY` protocol which is available in [nim-waku](https://github.com/status-im/nim-waku), the messaging rate is set to 1 per second i.e. `T = 1 second`.
+Nevertheless, this value is also subject to change depending on user experience.
+
+## Maximum Epoch Gap


Maybe we can add short paragraph with example of possibly sensible value?

Sure, I'll do a bit of research on this matter, especially the sensible clock drift, and will update the RFC with sensible value in another PR.

s1fr0 · 2022-02-10T15:08:40Z

content/docs/rfcs/17/README.md

+That is, the peer uses the  `share_x` and `share_y`  of the new message and the  `share'_x` and `share'_y` of the old record to reconstruct the `sk` of the message owner.
+The `sk` then can be used to delete the spammer from the group and withdraw a portion of its staked fund.
+2. If the `share_x` and `share_y` fields of the previously relayed message are identical to the incoming message, then the message is a duplicate and shall be discarded.
+3. If none is found, then the message gets relayed.



From the description looks like spam detection can be done exclusively by checking the nullifier and thus there is no need to stake. In fact, while 1. economically disincentivize spam, 2. looks more as a replay attack prevention mechanism which in principle can be executed with no group registration against honest users (with the final goal to mark them as spammers). Hence the need for both a nullifier and a stake mechanism.

From the description looks like spam detection can be done exclusively by checking the nullifier and thus there is no need to stake. In fact, while 1. economically disincentivize spam, 2. looks more as a replay attack prevention mechanism which in principle can be executed with no group registration against honest users (with the final goal to mark them as spammers). Hence the need for both a nullifier and a stake mechanism.

@s1fr0
Right, detection of double signaling i.e., spamming is done by tracking internal nullifiers.
I am not sure about the second point you made about the replay attack, can you please elaborate? In the current design, duplicate messages (or replayed messages) are found using their secret shares i.e., share_x regardless of their nullifier.

My comment was about stressing the reason of having both a nullifier mechanism and a share detection/stake mechanism. In principle, you can filter redundant/spam messages exclusively by looking at nullifiers and discarding messages which use an already seen one. But marking spammers only based on re-used nullifiers opens to replay attacks, where an attacker simply replays users' messages (i.e., nullifier, proof, etc.) to multiple nodes with the malicious intent of making honest users being tagged as spammers.

an attacker simply replays users' messages (i.e., nullifier, proof, etc.) to multiple nodes with the malicious intent of making honest users being tagged as spammers.

By replaying old messages it is not possible to make an honest peer look as a spammer, there needs to be a new message published by the same peer in the same epoch for it to be marked as a spammer.

Update: I see what you mean, right, I'd say such motivation should be (and is good to be) included in the RLN-RFC which is going to be soon part of the vac rfcs. The reason I do not recommend including it here is that it directly relates to the RLN construct whereas rln-relay is an application of the RLN construct.

yes! It was about providing more context on why there are two checks and not only one. In this construction, the two are indeed necessary to detect and disincentivize spammers.

s1fr0 · 2022-02-10T15:26:15Z

content/docs/rfcs/17/README.md


-The `epoch` is an array of 32 bytes that represents the epoch in which the message is published.
-<!-- TODO epoch is going to change to a different type -->
+The `epoch` is an array of 32 bytes in little-endian order that represents the epoch in which the message is published.


I expect epoch to be 8 bytes long (Timestamp type) or 16 in case for some reason it will be changed to int128. Is 32 bytes long fields a requirement for public circuit inputs in current implementation? (if so this may make the final circuit more complicated than necessary, i.e., make proof computation slower)

epoch is not of the timestamp type but is a counter and its type is dictated by the underlying circuit definition.
One important note about the epoch is that it corresponds to the external nullifier in the general rln construct, and conceptually can be any arbitrary value e.g., can represent a voting booth for which only one vote can be cast by each participant. As we are using rln for spam protection in a GossipSub network, we opted for the epoch definition which is smaller than 32 bytes, but in other rln applications, it may not be the case. I imagine the reason for it being 32bytes is to account for arbitrary values.

s1fr0

A great read! I wonder if the trustless property of the employed Merkle tree accumulator is necessary. Of course, it provides full transparency on accumulated pk, which is great. On the other hand it forces membership proofs to have logarithmic size (rather than constant) and thus the ZK circuit would result inefficient to first users (since the authPath private field length should take into account a possible large number of users). Also a Merkle tree requires membership witness updates on each pk addition/deletion operation which may result inconvenient on users' side and easily make proofs outdated in case of a large number of concurrent registered users.

If Merkle-trees can be replaced by (positive) accumulators managed by a trusted authority, it is then possible to have accumulator values which remain constant on pk additions and change only in case of deletions (ideal in the RLNRELAY setting). Also witnesses are constant-sized and can be updated even after million of pk additions/deletions in few elementary operations (under some assumptions). This might be of interest for future work.

staheri14

Thanks @oskarth for the comments, please see this commit 444076c and 5eecaf2 for the revisions I made based on your comments.

staheri14 · 2022-02-11T19:22:06Z

content/docs/rfcs/17/README.md

 ## SetUp and Registration
-A peer willing to publish a message is required to register. 
+Peers subscribed to a specific `pubsubTopic` form a [rln group](/spec/32).


sure, revised.

staheri14 · 2022-02-11T19:22:30Z

content/docs/rfcs/17/README.md

+For the registration, a peer creates a transaction that invokes the registration function of the contract via which registers its `pk` in the group. 
+The transaction also transfers  `v` amount of ether to the contract to be staked. 
+`v` is a system parameter.
+The peer who has the "private key" `sk` associated with a registered `pk` would be able to withdraw a portion `p` of the staked fund by providing valid proof. <!-- a secure way to prove the possession of a pk is yet under discussion, maybe via commit and reveal -->


sure, done.

staheri14 · 2022-02-11T20:22:59Z

content/docs/rfcs/17/README.md

+The state of the membership contract contains the list of registered members' public identity keys i.e., `pk`s. 
+For the registration, a peer creates a transaction that invokes the registration function of the contract via which registers its `pk` in the group. 
+The transaction also transfers  `v` amount of ether to the contract to be staked. 
+`v` is a system parameter.


sure, added a table under the "Recommended System Parameters".

staheri14 · 2022-02-11T20:24:25Z

content/docs/rfcs/17/README.md



-## Routing
+## Group  Synchronization


content/docs/rfcs/17/README.md

staheri14 · 2022-02-11T20:44:01Z

content/docs/rfcs/17/README.md

+In the proof of concept implementation of `17/WAKU-RLN-RELAY` protocol which is available in [nim-waku](https://github.com/status-im/nim-waku), the messaging rate is set to 1 per second i.e. `T = 1 second`.
+Nevertheless, this value is also subject to change depending on user experience.
+
+## Maximum Epoch Gap


Sure, I'll do a bit of research on this matter, especially the sensible clock drift, and will update the RFC with sensible value in another PR.

staheri14 · 2022-02-11T22:07:38Z

A great read! I wonder if the trustless property of the employed Merkle tree accumulator is necessary. Of course, it provides full transparency on accumulated pk, which is great. On the other hand it forces membership proofs to have logarithmic size (rather than constant) and thus the ZK circuit would result inefficient to first users (since the authPath private field length should take into account a possible large number of users). Also a Merkle tree requires membership witness updates on each pk addition/deletion operation which may result inconvenient on users' side and easily make proofs outdated in case of a large number of concurrent registered users.

If Merkle-trees can be replaced by (positive) accumulators managed by a trusted authority, it is then possible to have accumulator values which remain constant on pk additions and change only in case of deletions (ideal in the RLNRELAY setting). Also witnesses are constant-sized and can be updated even after million of pk additions/deletions in few elementary operations (under some assumptions). This might be of interest for future work.

Thanks for the suggestion @s1fr0, what you proposed directly impacts the rln construct and its circuit. I think it would be good if you open an issue in vac rfc research repo for it and elaborate on your suggested approach (we can also discuss it in our 1:1). In line with your suggestion, there is research on using Verkle trees instead of Merkle tree for efficiency reasons.

A quick few points about your suggestion:

Can you please clarify what kind of accumulators you mean by "(positive) accumulators"?
Also being managed by a trusted authority is a big assumption, we typically avoid trusting on one entity in a p2p network to lower the attack vectors. With one single entity, there will be security issues relayed to the integrity of the group state. Due to such issues, the on-chain solution (i.e., smart contract) is adopted to manage the trust, integrity as well as pk ordering.
By the way, why a trusted authority is needed anyway?

staheri14 · 2022-02-11T22:52:12Z

@oskarth please let me know if any further updates are needed.

s1fr0 · 2022-02-12T00:01:27Z

* Can you please clarify what kind of accumulators you mean by "(positive) accumulators"?

Positive accumulators are cryptographic accumulators supporting membership witnesses, i.e. you can prove that an element is accumulated into an accumulator value (in Merkle trees this correspond to "a leaf has a path towards the root"). Negative accumulators are those that support non-membership witnesses, i.e. you can prove that something is not accumulated in the accumulator value. Universal accumulators support both membership and non-membership witnesses.

* Also being managed by a trusted authority is a big assumption, we typically avoid trusting on one entity in a p2p network to lower the attack vectors. With one single entity, there will be security issues relayed to the integrity of the group state. Due to such issues, the on-chain solution (i.e., smart contract) is adopted to manage the trust, integrity as well as pk ordering.
  By the way, why a trusted authority is needed anyway?

AFAIK current schemes have some sort of decentralization/efficiency tradeoff, i.e. the more you go decentralized the less efficient the accumulator, and viceversa. Ideally you need a positive accumulator that doesn't change its accumulator value on additions (the most frequent scenario here) in order to avoid users to frequently update their witnesses (note that in case of n deletions, users must process O(n) data due to an impossibility result by Camacho and Hevia). When you have a trusted entity which accumulates elements and issues witnesses to users using a secret trapdoor (which might be MPC distributed to multiple smart contracts though), then this scenario is perfectly feasible and further optimizations are possible (up to allow even IoT to easily keep witnesses updated). By the way there is a specific positive construction we might discuss, where the trusted authority can be replaced by a trusted setup (done in MPC) and the smart contract can then accumulate and issue (constant-sized) witnesses using such (public) generated information. In this case, however, you lose the property of keeping the accumulator value constant on additions.

oskarth

Some comments but think good as draft, nice job!

oskarth · 2022-02-14T04:46:44Z

content/docs/rfcs/17/README.md

+The messaging rate is hardcoded to `1` message per `epoch` per definition. 
+The `epoch` is measured as `epoch` = $\lceil$ current Unix epoch time in seconds / `Epoch_Length` $\rceil$ where `Epoch_Length` indicates the length of the `epoch` in seconds. 
+In other words, the `epoch` value gets incremented after every  `Epoch_Length` passed from the Unix epoch event.
+The messaging rate `1` is a fixed value whereas the epoch duration  `Epoch_Length`  is  application-dependent.


Suggested change

The messaging rate is hardcoded to `1` message per `epoch` per definition.

The `epoch` is measured as `epoch` = $\lceil$ current Unix epoch time in seconds / `Epoch_Length` $\rceil$ where `Epoch_Length` indicates the length of the `epoch` in seconds.

In other words, the `epoch` value gets incremented after every `Epoch_Length` passed from the Unix epoch event.

The messaging rate `1` is a fixed value whereas the epoch duration `Epoch_Length` is application-dependent.

The messaging rate is hardcoded to `1` message per `epoch` per definition.

The `epoch` is measured as `epoch` = $\lceil$ current Unix epoch time in seconds / `Epoch_Length` $\rceil$ where `Epoch_Length` indicates the length of the `epoch` in seconds.

In other words, the `epoch` value gets incremented after every `Epoch_Length` passed from the Unix epoch event.

The messaging rate `1` is a fixed value whereas the epoch duration `Epoch_Length` is application-dependent.

The messaging rate is defined by the period which indicates how many messages can be sent in a given period.

We define an epoch as lceil(unix_time / period). For example, if unix_time is 1644810116 and we set period to 30, then epoch is lceil(unix_time/period) = 54827003.

Note that epoch refers to epoch in RLN and not Unix epoch. This means a message can only be sent every period, where period is up to the application.

See see section Recommended System Parameters for some recommended ways to set a sensible period value depending on the application.

thanks, done 8954039

oskarth · 2022-02-14T04:47:05Z

content/docs/rfcs/17/README.md

+The `epoch` is measured as `epoch` = $\lceil$ current Unix epoch time in seconds / `Epoch_Length` $\rceil$ where `Epoch_Length` indicates the length of the `epoch` in seconds. 
+In other words, the `epoch` value gets incremented after every  `Epoch_Length` passed from the Unix epoch event.
+The messaging rate `1` is a fixed value whereas the epoch duration  `Epoch_Length`  is  application-dependent.
+See section [Recommended System Parameters](#recommended-system-parameters) for some recommended ways to set a sensible  `Epoch_Length`  value.


Suggested change

See section [Recommended System Parameters](#recommended-system-parameters) for some recommended ways to set a sensible `Epoch_Length` value.

done 8954039

oskarth · 2022-02-14T04:47:53Z

content/docs/rfcs/17/README.md

 editor: Sanaz Taheri <sanaz@status.im>
 ---


Suggested change

editor: Sanaz Taheri <sanaz@status.im>

---

editor: Sanaz Taheri <sanaz@status.im>

contributors: Oskar Thoren <oskar@status.im>

---

Gonna add myself to this one :D

Sure, done 8954039

oskarth · 2022-02-14T04:48:11Z

content/docs/rfcs/17/README.md

-The security objective is to control the number of PubSub messages that each peer can publish per epoch where epoch is a system design parameter, regardless of the published topic.
+The security objective is to contain spam activity in a GossipSub network by enforcing a global messaging rate to all the peers.
+Peers that violate the messaging rate are considered spammers and their message is considered spam.
+Spammers are also financially punished and removed from the system. 


 **Protocol identifier***: `/vac/waku/waku-rln-relay/2.0.0-alpha1`


Is this still the protocol identifier? Have we ever bumped this? Think calling it beta might be more appropriate if it is a draft

Good point, In fact, we do not use the waku-rln-relay protocol identifier at all and I am going to delete it from the specs. Rln-relay is a configuration over the relay protocol that applications can switch on-off for specific pubsub topics. More specifically, rln-relay is a topicValidator that can be installed on a pubsub topic if need be.

oskarth · 2022-02-14T04:48:59Z

content/docs/rfcs/17/README.md

+To publish at a given `epoch`, the publishing peer proceeds based on the regular [`11/WAKU2-RELAY`](/spec/11) protocol.  
+However, to protect against spamming, each `WakuMessage` (which is wrapped inside the `data` field of a PubSub message) MUST carry a [`RateLimitProof`](##RateLimitProof) with the following fields. 


Suggested change

To publish at a given `epoch`, the publishing peer proceeds based on the regular [`11/WAKU2-RELAY`](/spec/11) protocol.

However, to protect against spamming, each `WakuMessage` (which is wrapped inside the `data` field of a PubSub message) MUST carry a [`RateLimitProof`](##RateLimitProof) with the following fields.

To publish at a given `epoch`, the publishing peer proceeds based on the regular [`11/WAKU2-RELAY`](/spec/11) protocol.

However, to protect against spamming, each `WakuMessage` (which is wrapped inside the `data` field of a PubSub message) MUST carry a [`RateLimitProof`](##RateLimitProof) with the following fields.

Like this, same across document. Makes it hard to read in plain text mode.

done in 8954039

oskarth · 2022-02-14T04:50:31Z

content/docs/rfcs/17/README.md


-<!-- TODO: may shorten or delete the Spam detection and slashing process -->
+**Epoch Validation**
+If the `epoch` attached to the message is more than `Max_Epoch_Gap` apart from the routing peer's current `epoch` then the message is discarded and considered invalid.


Nitpick but for constants can we keep them lower_case? E.g. max_epoch_gap (same above)

sure done in 8954039

* master: RFC16: add version call (#505) fix(noise): update RFC to implementation (#508) fixup: 37/WAKU2-NOISE fix images paths (#506) New RFC: 37/WAKU2-NOISE-SESSIONS (#504) 36/WAKU2-BINDINGS-API (#501) docs(16/WAKU2-RPC): add ENR to waku info (#502) Adding 35/WAKU2-NOISE to menu (#500) add RFC33 to index (#499) feat: 32/RLN raw spec New RFC: 35/WAKU2-NOISE (#496) Update on the rln registration figure to match the current spec (#497) 33/WAKU-DISCV5: Add first raw version (#487) Add pubsubTopic field to index (#492) Fix markdown links (#493) Categorize 22 & 31 (#490) Changed PB Timestamp index to 10 (#491) 13/14/16/21: Change in timestamp format (#483) add: RFC31 copyright statement (#489) 17/WAKU-RLN-RELAY: Revise spec for its draft version (#484)

staheri14 added 13 commits January 21, 2022 12:46

fixes broken links

ac09ff4

fixes naming mismatch

faf6672

revises publishing description

f386f67

Updates Publishing process

2e24d3d

revises update and registration

e9c5f8c

revised registration and publishing sections

385ca2d

major revisions on the rln-relay

09efdbb

marks as draft

9c1da66

edits motivation part

88acec5

adds max epoch gap and epoch

8cffe72

removes commented parts and revises recommended system parameters

70ab2d5

proofreading

3315e36

minor revision on the CA factor

2e46f51

staheri14 requested review from oskarth, jm-clius, kaiserd and s1fr0 February 8, 2022 22:07

staheri14 added 2 commits February 8, 2022 14:09

Merge branch 'master' into rln-relay/mark-as-draft

fca1c10

removes some redundant parts

7a51ebb

jm-clius reviewed Feb 9, 2022

View reviewed changes

jm-clius approved these changes Feb 9, 2022

View reviewed changes

fixes a typo

e8095c5

oskarth approved these changes Feb 10, 2022

View reviewed changes

oskarth changed the title ~~Revising Waku-RLN-Relay spec for its draft version~~ 17/WAKU-RLN-RELAY: Revise spec for its draft version Feb 10, 2022

s1fr0 reviewed Feb 10, 2022

View reviewed changes

s1fr0 approved these changes Feb 10, 2022

View reviewed changes

adresses comments

444076c

staheri14 commented Feb 11, 2022

View reviewed changes

moves protobuf field definition into a table

5eecaf2

moves rln-relay under the draft section of the menu

b3e4c7f

oskarth approved these changes Feb 14, 2022

View reviewed changes

staheri14 added 3 commits February 15, 2022 11:23

addresses comments

8954039

minor fix

e48d5ad

makes contributors itemized

df6b019

staheri14 merged commit 0659c15 into master Feb 15, 2022

staheri14 deleted the rln-relay/mark-as-draft branch February 15, 2022 19:31

s1fr0 mentioned this pull request Apr 13, 2022

chore|feat (waku-rln-relay): modules reorganization|Initial test for capturing events using nim-web3 waku-org/nwaku#941

Merged

	(messaging rate MAY be enforced for `WakuMessages` with a specific `contetTopic` published on a `pubsubTopic`, but that is an implementation choice).
	(messaging rate MAY be enforced for `WakuMessages` with a specific `contentTopic` published on a `pubsubTopic`, but that is an implementation choice).


		The `merkle_root` is an array of 32 bytes which holds the root of membership group Merkle tree at the time of publishing the message.
		The `merkle_root` is an array of 32 bytes in little-endian order which holds the root of membership group Merkle tree at the time of publishing the message.

		To publish at a given `epoch`, the publishing peer proceeds based on the regular [`11/WAKU2-RELAY`](/spec/11) protocol.
		However, to protect against spamming, each `WakuMessage` (which is wrapped inside the `data` field of a PubSub message) MUST carry a [`RateLimitProof`](##RateLimitProof) with the following fields.

17/WAKU-RLN-RELAY: Revise spec for its draft version #484

17/WAKU-RLN-RELAY: Revise spec for its draft version #484

Conversation

staheri14 commented Feb 8, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jm-clius left a comment

Choose a reason for hiding this comment

oskarth left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

oskarth Feb 14, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

staheri14 Feb 10, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

staheri14 Feb 10, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

staheri14 Feb 11, 2022 • edited Loading

Choose a reason for hiding this comment

s1fr0 Feb 11, 2022 • edited Loading

Choose a reason for hiding this comment

staheri14 Feb 11, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

s1fr0 Feb 10, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

s1fr0 left a comment • edited Loading

Choose a reason for hiding this comment

staheri14 left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

staheri14 commented Feb 11, 2022

staheri14 commented Feb 11, 2022

s1fr0 commented Feb 12, 2022

oskarth left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

oskarth Feb 14, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

staheri14 Feb 15, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

staheri14 commented Feb 8, 2022 •

edited

Loading

oskarth Feb 14, 2022 •

edited

Loading

staheri14 Feb 10, 2022 •

edited

Loading

staheri14 Feb 10, 2022 •

edited

Loading

staheri14 Feb 11, 2022 •

edited

Loading

s1fr0 Feb 11, 2022 •

edited

Loading

staheri14 Feb 11, 2022 •

edited

Loading

s1fr0 Feb 10, 2022 •

edited

Loading

s1fr0 left a comment •

edited

Loading

staheri14 left a comment •

edited

Loading

oskarth Feb 14, 2022 •

edited

Loading

staheri14 Feb 15, 2022 •

edited

Loading