vacp2p/rfc
1
0
Fork 0
mirror of https://github.com/vacp2p/rfc.git synced 2025-02-23 12:18:29 +00:00
Code Issues Packages Projects Releases Wiki Activity

feat(17/WAKU2-RLN-RELAY): acceptable window of roots updated on per-block basis (#555)

Browse Source 
* feat(17/WAKU2-RLN-RELAY): acceptable window of roots updated on per-block basis

* fix(17/WAKU2-RLN-RELAY): typo in rate_limit_proof type

Co-authored-by: G. <28568419+s1fr0@users.noreply.github.com>

* fix(17/WAKU2-RLN-RELAY): split sentences

* fix(17/WAKU2-RLN-RELAY): s/populate/replace

* fix(17/WAKU2-RLN-RELAY): explicitly mention rate_limit_proof is optional

* fix(17/WAKU2-RLN-RELAY): add example

* fix(17/WAKU2-RLN-RELAY): line breaks

* chore(17/WAKU2-RLN-RELAY): apply suggestions from code review

Co-authored-by: G. <28568419+s1fr0@users.noreply.github.com>

* fix(17/WAKU2-RLN-RELAY): make it clearer

* fix(17/WAKU2-RLN-RELAY): make it clearer

Co-authored-by: G. <28568419+s1fr0@users.noreply.github.com>
This commit is contained in:
Aaryamann Challani 2022-12-07 23:44:49 +05:30 committed by GitHub
parent 86eb2dac97
commit 5684d26461
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 20 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
content/docs/rfcs/17/README.md
View File

@ -94,6 +94,9 @@ Proof generation relies on the knowledge of Merkle tree root `merkle_root` and `
Getting access to the Merkle tree can be done in various ways. Getting access to the Merkle tree can be done in various ways.
One way is that all the peers construct the tree locally. One way is that all the peers construct the tree locally.
This can be done by listening to the registration and deletion events emitted by the membership contract. This can be done by listening to the registration and deletion events emitted by the membership contract.
Peers MUST update the local Merkle tree on a per-block basis.
This is discussed further in the [Merkle Root Validation](#merkle-root-validation) section.
Another approach for synchronizing the state of slashed `pk`s is to disseminate such information through a p2p GossipSub network to which all peers are subscribed. Another approach for synchronizing the state of slashed `pk`s is to disseminate such information through a p2p GossipSub network to which all peers are subscribed.
This is in addition to sending the deletion transaction to the membership contract. This is in addition to sending the deletion transaction to the membership contract.
The benefit of an off-chain slashing is that it allows real-time removal of spammers as opposed to on-chain slashing in which peers get informed with a delay, The benefit of an off-chain slashing is that it allows real-time removal of spammers as opposed to on-chain slashing in which peers get informed with a delay,
@ -106,24 +109,31 @@ The reason is that using an old root can allow inference about the index of the
Upon the receipt of a PubSub message via [`11/WAKU2-RELAY`](/spec/11) protocol, the routing peer parses the `data` field as a `WakuMessage` and gets access to the `RateLimitProof` field. Upon the receipt of a PubSub message via [`11/WAKU2-RELAY`](/spec/11) protocol, the routing peer parses the `data` field as a `WakuMessage` and gets access to the `RateLimitProof` field.
The peer then validates the `RateLimitProof` as explained next. The peer then validates the `RateLimitProof` as explained next.
**Epoch Validation** ### 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. 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.
This is to prevent a newly registered peer from spamming the system by messaging for all the past epochs. This is to prevent a newly registered peer from spamming the system by messaging for all the past epochs.
`max_epoch_gap` is a system parameter for which we provide some recommendations in section [Recommended System Parameters](#recommended-system-parameters). `max_epoch_gap` is a system parameter for which we provide some recommendations in section [Recommended System Parameters](#recommended-system-parameters).
**Merkle Root Validation** ### Merkle Root Validation
The routing peers MUST check whether the provided Merkle root in the `RateLimitProof` is valid. The routing peers MUST check whether the provided Merkle root in the `RateLimitProof` is valid.
It can do so by maintaining a local set of valid Merkle roots, which consist of `acceptable_root_window_size` past roots. It can do so by maintaining a local set of valid Merkle roots, which consist of `acceptable_root_window_size` past roots.
This allows peers which are not well connected to the network to be able to send messages, accounting for network delay. These roots refer to the final state of the Merkle tree after a whole block consisting of group changes is processed.
The Merkle roots are updated on a per-block basis instead of a per-event basis.
This is done because if Merkle roots are updated on a per-event basis, some peers could send messages with a root that refers to a Merkle tree state that might get invalidated while the message is still propagating in the network, due to many registrations happening during this time frame.
By updating roots on a per-block basis instead, we will have only one root update per-block processed, regardless on how many registrations happened in a block, and peers will be able to successfully propagate messages in a time frame corresponding to roughly the size of the roots window times the block mining time.
Atomic processing of the blocks are necessary so that even if the peer is unable to process one event, the previous roots remain valid, and can be used to generate valid RateLimitProof's.
This also allows peers which are not well connected to the network to be able to send messages, accounting for network delay.
This network delay is related to the nature of asynchronous network conditions, which means that peers see membership changes asynchronously, and therefore may have differing local Merkle trees. This network delay is related to the nature of asynchronous network conditions, which means that peers see membership changes asynchronously, and therefore may have differing local Merkle trees.
See [Recommended System Parameters](#recommended-system-parameters) on choosing an appropriate `acceptable_root_window_size`. See [Recommended System Parameters](#recommended-system-parameters) on choosing an appropriate `acceptable_root_window_size`.
**Proof Verification** ### Proof Verification
The routing peers MUST check whether the zero-knowledge proof `proof` is valid. The routing peers MUST check whether the zero-knowledge proof `proof` is valid.
It does so by running the zk verification algorithm as explained in [RLN](/spec/32). It does so by running the zk verification algorithm as explained in [RLN](/spec/32).
If `proof` is invalid then the message is discarded. If `proof` is invalid then the message is discarded.
**Spam detection** ### Spam detection
To enable local spam detection and slashing, routing peers MUST record the `nullifier`, `share_x`, and `share_y` of incoming messages which are not discarded i.e., not found spam or with invalid proof or epoch. To enable local spam detection and slashing, routing peers MUST record the `nullifier`, `share_x`, and `share_y` of incoming messages which are not discarded i.e., not found spam or with invalid proof or epoch.
To spot spam messages, the peer checks whether a message with an identical `nullifier` has already been relayed. To spot spam messages, the peer checks whether a message with an identical `nullifier` has already been relayed.
1. If such a message exists and its `share_x` and `share_y` components are different from the incoming message, then slashing takes place. 1. If such a message exists and its `share_x` and `share_y` components are different from the incoming message, then slashing takes place.
@ -161,10 +171,11 @@ message RateLimitProof {
message WakuMessage { message WakuMessage {
bytes payload = 1; bytes payload = 1;
string contentTopic = 2; string content_topic = 2;
uint32 version = 3; optional uint32 version = 3;
double timestamp = 4; optional sint64 timestamp = 10;
+ RateLimitProof rate_limit_proof = 21; optional bool ephemeral = 31;
+ optional bytes rate_limit_proof = 21;
} }
``` ```