RLN + Interep

[rymnc]

Background

Interep

Interep is an Identity protocol which allows trustless verification of the reputation of a given "peer". This reputation is derived from one or more metrics on a given centralised service (Github, Twitter, Reddit). It banks on the assumption that bot accounts do not or, will not, gain a large number of human-like characteristics on these services. For example, only a real developer (and not a bot) would have more than a 100 stars on Github. However, it is difficult to trust that these centralised services will continue to operate with the same degree of bot prevention, over a longer period of time. For example, there are bots on Reddit which have over 100 "coins". The way we can use Interep safely is by increasing the threshold of what "peers" we allow to use the system, i.e only Silver tier or above on any of the centralised services. This would greatly reduce the number of bots and would make the system anti-sybil upto a degree.

• Docs: https://docs.interep.link/

RLN

RLN (Rate Limiting Nullifier), is used for spam prevention in a peer-to-peer network, while preserving anonymity. A "peer" registers themselves to be a part of a membership group, either with funds (See: https://rfc.vac.dev/spec/17/), or with their social reputation. The membership group refers to the set of anonymized "peers" that are allowed to send messages. Each message includes a ZK proof that proves that this "peer" belongs to the membership group. If spamming is detected, the message is dropped, and the sender is subsequently "slashed", and removed from the membership group. When the sender is removed from the membership group, their messages are no longer propagated, and therefore, spam prevention occurs. "Slashing" refers to the financial/social stake being taken away from the "peer". We will discuss more about social-slashing below.

• RLN Spec: https://rfc.vac.dev/spec/32/
• Waku RLN Relay Spec: https://rfc.vac.dev/spec/17/

Motivation

The motivation to use social-staking vs financial-staking is to lower the barrier of entry in a sybil-resistant manner. There are applications which do require this, and would benefit greatly from the lowered difficulty to participate in spam prevention. The barrier of entry is further reduced by implementing gasless transactions (EIP-2771) for the registering to be a part of the membership group.

Examples -

• Status Communities are groups which would ideally, not force their users to pay to be a part of them, to participate in spam prevention. In this case, the community could relay the membership registration transaction on behalf of their users. Partly related to https://github.com/vacp2p/research/issues/148

How RLN and Interep can work together

We are operating under the following assumptions -

• Each "peer" that wishes to send a message has a social account (Twitter, Reddit, Github), with a Silver tier or above
• The "peers" prefer to be anonymized, by using Interep
• The "peers" may or may not have the required gas fee to register themselves to a membership group, and the application takes care of it

The RLN contract can be forked/updated to add the following functions -

• A function that returns valid group Ids. Group Ids are generated in the following way - solidity and ts, Where the provider can be (Github, Twitter, Reddit), and the name can be (Gold, Silver, Bronze)
• A function for "social" registrations, where instead of accepting a financial stake, we accept the Semaphore proofs that the "peer" belongs to a given Interep group, as described here
• Integrate EIP-2771 for gasless transactions

To generate proofs for the messages, the "peers" can use their existing ID Commitment that they used with Interep, but using the RLN circuit, as described here. They can then be removed from the membership group by following the slashing scheme described here.

There are 2 disincentives to spamming the network with social stake -

• The "peer" will not be able to propagate messages throughout the network, and
• The "peer" risks exposing their identity secret hash to the public.

MVP PoC Details

Must Haves

• [x] Updates to the RLN contract to -

  • [x] Accept Interep Semaphore proofs in a custom membership registration function
  • [x] Validate Interep group Ids

• [x] A simple UI to demonstrate -

  • [x] A social login (Github, Twitter, Reddit)
  • [x] Interep group registration
  • [x] RLN Membership registration using Interep Semaphore proofs
  • [x] Ability to send messages using an existing rln-relay implementation, i.e Waku-RLN-Relay (https://rfc.vac.dev/spec/17/)

Nice to Haves

• Slashing, i.e exposing the identity secret of the malicious peer, and removing them from the membership group.
• Integrate EIP-2771 for gasless registrations.

Further reading

• https://github.com/njofce/zk-chat
• https://github.com/interep-project/reputation-service
• https://docs.interep.link/technical-reference/intro
• https://semaphore.appliedzkp.org/docs/guides/proofs
• https://github.com/interep-project/contracts/blob/24c9db8efb7ad28b3e5dc9659f0a5c1cb6e63add/contracts/Interep.sol
• https://github.com/vacp2p/rln-contract
• https://ethresear.ch/t/decentralised-cloudflare-using-rln-and-rich-user-identities/10774

[staheri14]

Thanks @rymnc for opening the issue! Nice one! One thing that would be good to capture is the dynamic of the Interrrep group, for example, when a peer's status may change over time (especially after registration to the RLN group). For the first PoC, we may want to scope out this aspect, but it would be good to keep it on the radar for the future.

[rymnc]

Thanks @rymnc for opening the issue! Nice one! One thing that would be good to capture is the dynamic of the Interrrep group, for example, when a peer's status may change over time (especially after registration to the RLN group). For the first PoC, we may want to scope out this aspect, but it would be good to keep it on the radar for the future.

Thanks for your comment! We could eventually incentivise peers to be a feedback loop to Interep group changes, but, yes, as you said, this can be dealt with later

[oskarth]

Thanks for the issue, it's a good start and summarizes useful background! A few things worth mentioning:

1) In terms of motivation, being able to get sybil resistant messaging without requiring user to have crypto funds is a big motivator -- e.g. this is why Status Communities don't want to rely on current RLN Relay with ETH/ERC20 as stake -- this requires thinking a bit about how contract updates work (e.g. relayer, maybe batcher? or non smart contract version?)

2) It'd be good to connect this back to https://ethresear.ch/t/decentralised-cloudflare-using-rln-and-rich-user-identities/10774 and decentralized captcha

3) Finally, the issue currently provides background and a rough sketch for how they can work together. It is missing a scope for MVP / next steps and what would be must-have and what can be added later as nice to haves. If we can create a tight scope for MVP POC + spec that'd make things more concrete.

[rymnc]

Thanks for the issue, it's a good start and summarizes useful background! A few things worth mentioning:

1. In terms of motivation, being able to get sybil resistant messaging without requiring user to have crypto funds is a big motivator -- e.g. this is why Status Communities don't want to rely on current RLN Relay with ETH/ERC20 as stake -- this requires thinking a bit about how contract updates work (e.g. relayer, maybe batcher? or non smart contract version?)
2. It'd be good to connect this back to https://ethresear.ch/t/decentralised-cloudflare-using-rln-and-rich-user-identities/10774 and decentralized captcha
3. Finally, the issue currently provides background and a rough sketch for how they can work together. It is missing a scope for MVP / next steps and what would be must-have and what can be added later as nice to haves. If we can create a tight scope for MVP POC + spec that'd make things more concrete.

Updated the issue to include -

• motivation
• a link to the ethresearch post.
• MVP PoC scope

[rymnc]

An update on the PoC for those interested -

• https://github.com/vacp2p/rln-interep-contract has been created which addresses the contract updates required to accept registrations from peers that are part of a valid Interep group
• We will use the rln-js example, and add social login, Interep group registration, and rln membership. src
  • This will lead to using the same credentials (for Interep and RLN) to send messages via waku-rln-relay, which is already integrated into the rln-js example

[rymnc]

Something to note with interep is that it requires a trusted intermediary which collects auth tokens (which have pii) and id commitments, and adds them to the merkle tree, which is then used to update the onchain root of the tree at intervals. We will have to design the relay protocol for this in a way that we have trusted relayers for a specific groupId (provider + tier, i.e github gold) which accept membership requests, and then submit the updated merkle root onchain, for a fee. This action could then be contested by other relayers, if a malicious action is detected. To ensure that all relayers see all membership requests(so that they can compute the same root), we will have to introduce a delay, in terms of number of blocks, etc. This would lead to worse UX, at the cost of decentralizing the trusted intermediary. May be worth to note that censorship can happen, because the auth token of the user is passed around, and by extension their PII as well. Even if one relayer does accept this membership request, the other relayers can contest it. We will have to design a threshold of non-malicious relayers to ensure that censorship does not occur.

[rymnc]

Something to note with slashing is that the actual identity_secret of the malicious peer is not revealed. It is the identity_secret_hash from which the id_commitment is derived. Due to this, there is no real-world disincentive/consequence for a peer who registered with Interep to be malicious, unless we link this to a reputation system, where their reputation reduces if they are removed from the membership set.

[rymnc]

Since we have completed the spec as well as the forum post I will close this issue. Please feel free to re-open when required!