17/WAKU2-RLN-RELAY: Update #32
Conversation
waku/standards/core/17/rln-relay.md
Outdated
| Spammers are also financially punished and removed from the system. | ||
|
|
||
|
|
||
| <!-- **Protocol identifier***: `/vac/waku/waku-rln-relay/2.0.0-alpha1` --> | ||
| **Protocol identifier***: `/waku/waku-rln-relay/2.0.0-alpha1` |
There was a problem hiding this comment.
Is this needed for a node implementing rln-relay node. I am assuming the implementer would only use /waku/relay/2.0.0
There was a problem hiding this comment.
agree, this should be removed
| The proof generation relies on the knowledge of two pieces of private information i.e., `sk` and `authPath`. | ||
| The `authPath` is a subset of Merkle tree nodes by which a peer can prove the inclusion of its `pk` in the group. <!-- TODO refer to RLN RFC for authPath def --> |
There was a problem hiding this comment.
Should authPath be replaced with path_elements and indices?
waku/standards/core/17/rln-relay.md
Outdated
| This amount is denoted by `staked_fund` and is a system parameter. | ||
| The peer who has the secret key `sk` associated with a registered `pk` would be able to withdraw a portion `reward_portion` 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 --> | ||
| The peer who has the secret key `sk` associated with a registered `pk` would be able to withdraw a portion `reward_portion` 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 --> |
There was a problem hiding this comment.
Is this still under discussion?
There was a problem hiding this comment.
waku does not plan on using slashing so it may be removed
cc: @jm-clius for confirmation
There was a problem hiding this comment.
Slashing can be removed from RLN-Relay, yes
There was a problem hiding this comment.
@jm-clius Slashing is not implemented in the rln-relay contract, correct? Does this mean off-chain slashing does not occur with spam detection?
There was a problem hiding this comment.
Indeed. When spam is detected, the gossipsub score of the spam-forwarding peer gets lowered. This eventually means that nodes would disconnect from peers that do not drop spam before relaying it to the network.
|
hey, thanks for this PR, not sure if this should go to stable yet? as rln-v2 is planned to be shipped for waku's production (and therefore stable) network? |
waku/standards/core/17/rln-relay.md
Outdated
| This amount is denoted by `staked_fund` and is a system parameter. | ||
| The peer who has the secret key `sk` associated with a registered `pk` would be able to withdraw a portion `reward_portion` 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 --> | ||
| The peer who has the secret key `sk` associated with a registered `pk` would be able to withdraw a portion `reward_portion` 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 --> |
There was a problem hiding this comment.
Slashing can be removed from RLN-Relay, yes
waku/standards/core/17/rln-relay.md
Outdated
| @@ -2,7 +2,7 @@ | |||
| slug: 17 | |||
| title: 17/WAKU2-RLN-RELAY | |||
| name: Waku v2 RLN Relay | |||
| status: draft | |||
| status: stable | |||
There was a problem hiding this comment.
The changes to the draft spec below are useful. However, I wouldn't move this to stable yet. As @rymnc mentions, we are currently transitioning to RLNv2 and will stabilize on that version. I think we also need to explain the role of gossipsub scoring in our protocol before it would be a complete description.
jimstir
changed the title
Move 17/WAKU2-RLN-RELAY to stable open discussion.
Implementation :