Using Interep for Sybil-Resistant RLN

Background

Interep is a service that ties web2 identities to a reputation tier, and each reputation tier on a given web2 platform(Github, Twitter, Reddit) is a Semaphore Group which allows the user to anonymously prove that they are a part of a given “reputation set” on Interep.

By restricting access to certain resources to peers which belong to the higher reputation groups, we obtain sybil-resistance for those resources. However, this does increase the barrier of entry. For example, a new user on Github may not have the stars and followers required for a good reputation, and therefore, may miss out on membership to the “reputation set”. In support of Interep, the barrier of entry is much lower than that of a financial barrier of entry, i.e Financial stake. Financial stake is a predominant solution for sybil-resistance, but it allows actors with large coffers to create sybil identities.

RLN (Rate Limiting Nullifier) is a modification of Semaphore which effectively allows peers to derive the secret share of a peer that spams a network. This enables anonymous rate-limiting in a decentralized scenario, but can be applied in conventional situations as well.

An implementation of RLN is found in Waku, which makes use of a smart contract to handle changes to a membership set. When a peer wishes to send messages on a spam-protected content topic, they simply need to stake a nominal amount, along with their identity commitment, and relayers will validate messages sent by the peer. However, if the peer is malicious, and spams the network, their secret share is derived, and their financial stake is withdrawn by the relayer which derived their secret share.

How Interep fits in with RLN

As mentioned, to be a part of an RLN membership set in a decentralized scenario, one needs to financially stake. With Interep, we can reduce the barrier of entry by allowing only peers which belong to a medium/high reputation group to join the RLN membership set, without staking.

When this “socially staked” peer participates in spam, their secret share is revealed, and they are removed from the membership set, as usual. A third-party on-chain reputation service could then reduce the reputation for the slashed peer.

Work Done

So far, the RLN contracts have been updated and currently reside in rln-interep-contract. It is possible to register your membership on Interep, and use the same credentials for rate-limiting via RLN. A demo video is accessible here.

Future Work

Currently, Interep’s reputation service is centralized, i.e For a user to prove that they have a given reputation, they need to send an auth token to Interep’s service, through which they are added to the appropriate reputation set. There may be some effort done to decentralize this service for censorship resistance.

As mentioned previously, a third-party on-chain reputation service should reduce the reputation for a slashed peer. However, that service has not been integrated so far, and it can be done in the future.

Some careful consideration must be taken care when dealing with web2 providers, as their metrics for a non-sybil account may change over time, and a user’s reputation may change with time as well. For increased security, we may attach a timer for each registration to the membership set via Interep so that they can renew their membership with an additional proof that they still belong to the same reputation set.

There are also on-chain Interep groups available through POAPs, but they have not been integrated with this PoC. For example, If a DAO wishes to participate in rate-limiting, and should allow only its members to do so, they can issue a POAP to all the members, and the members may then use this to generate a proof that they belong to the DAO. The service can then filter traffic appropriately.

References

  1. https://interep.link
  2. https://semaphore.appliedzkp.org/docs
  3. 32/RLN | Vac RFC
  4. 17/WAKU2-RLN-RELAY | Vac RFC
  5. GitHub - vacp2p/rln-interep-contract: RLN+Interep contract
  6. https://poap.xyz/

I assume that upon receiving an auth token, someone has to do an on-chain transaction to update the contract with the new member?
Who funds this transaction? Can the funds be depleted?

By design, the Interep backend is centralized. It handles new member registrations, as well as the subsequent onchain interaction. Reference - GitHub - interep-project/reputation-service: 🚀 Interep back-end and front-end.

So to answer your question, the peer running this Interep server will have to pay for gas.

Additional context - Discord

Thanks @rymnc. Great. I think at a next step it would be good to understand as well what would be the cost per user (ie, can transactions be batched, what’s the gas cost).

I assume someone deploying the server can also deploy their contract on any EVM chain?

Finally, in terms of risk of depletion of funds for gas. I guess only users with valid credentials can trigger action to spend gas?

Unfortunately this link does not seem to work.

You can join Interep’s discord here to access the link mentioned.

  1. With the following parameters -
  • Optimizer enabled: false

  • Runs: 200

  • Block limit: 30000000 gas

  • ETH price: $1590 (as on date)

  • Gas price: 31 gwei

  • Updating the Interep group takes an average gas cost of 984,833. Cost per update = 984333 * 31 gwei = 0.030529823 eth ≈ 48.54 usd

While this is certainly expensive on mainnet, it is worth noting that these transactions can in fact be batched, and are automatically batched per epoch (can be operator set).

  • Registering to the RLN group with Interep membership proof takes an average gas cost of 142464. Cost per registration = 142464 * 31 gwei = 0.004416384 eth ≈ 7.02 usd.

These gas costs are derived from the hardhat-gas-reporter plugin and may not be 100% accurate. Refer to GitHub - vacp2p/rln-interep-contract: RLN+Interep contract to reproduce locally.

Given the cost per transaction, it would be wise to use a layer-2 for this application.

  1. Yes, anyone can deploy this contract and server on any evm chain

  2. Yes, their reputation-service handles that