Incentivizing Waku Services using Service Credentials (store protocol)

[staheri14]

Context

Borrowed from https://forum.vac.dev/t/vac-sustainability-and-business-workshop/116

Waku nodes provide services that have a specific cost and this should be incentivized in a service network.
The first step is RLN Relay, which is used for private spam protection. It is based on detecting and punishing the sending of multiple messages in a given epoch over the gossip network.
After RLN, the next focus is store protocol, then filter/lightpush protocols. These are all request-reply protocols.
We believe credentials and subscription-based abstractions play an important role in incentivization.

Service credentials at a high level:
Service consumers need to purchase Service credentials or Tokens in order to obtain service from waku nodes.
The service consumer pays the cost of its service by handing its token/credentials to the provider.
The service provider can then claim funds associated with that credential.

The service credential incentivization model has multiple benefits:

• It requires less individual bookkeeping compared to the SWAP protocol.
• It avoids direct transactions between the consumer and the provider which is good for anonymity.
• It allows fine-grain control over the distribution of collected funds; providers can be paid based on their reputation.
• It is somewhat aligned with our potential future goal of adopting a DAO model.
• It has a lot of similarities with the rln-relay incentivization mode due to which some of the existing work (specs and implementation) can be borrowed from that effort.

Problem

This issue is specifically focused on enabling privacy-preserving service credentials for the Waku store protocol by adopting the privacy-preserving payment model.

Solution overview

Privacy-preserving payment model

At a high level,

A typical Privacy-preserving payment model uses smart contracts that accept tokens deposits from one address and enable their withdrawal from a different address. Those smart contracts work as pools that mix all deposited assets.
While tokens are in a Cash pool, the custody remains in users’ hands. Users, therefore, have complete control over their tokens

Users prove the ownership of their deposits anonymously using zk-Snark proofs by having the witness to the zk-Snark
circuit (see the relevant articles in the resources section).

Integration idea

This Privacy-preserving payment model can be used to incentivize the waku store protocol:

• A contract gets deployed on e.g., Ethereum blockchain
• A service consumer (store protocol user) deposits some token/funds to the contract and obtains a coin (some secret value to prove the ownership of the deposit)
• A service consumer crafts a transaction in which delegates the custody of its coin to the store protocol provider in the exchange for fetching historical messages. The Transction contains the zkSNARK proof of delegation of a valid deposit. The amount/number of coins required for the service can be proportional to the size or number of the queried historical messages.
• The service provider can use the obtained transaction to claim its fund from the pool i.e., the contract.
• To prevent double spending, the spent coin (i.e., the nullifier of the coin) can be advertised over a specific pubsub channel to which all the service providers are subscribed.

To be investigated

• An initial solution with specifications
• Whether or not a similar contract API can be used for waku-rln-relay and the service credentials? What is needed to consolidate these two? How about their underlying circuits, what are the differences? Is it possible to use the same circuit for both?
• Is it possible to bind tokens to a special service type e.g., store, filter, lighpush? what are the pros and cons?
• Which version of payment makes more sense: 1) traditional model with fixed amount pools 2) Or the Nova version, with arbitrary amounts & shielded transfers? What are the trade-offs?
• What are the anonymity guarantees we can provide for service consumers using this solution?
• What are the attacks against the service provider and consumer in this model? How to guarantee fairness?

Resources

• How does a Privacy-preserving payment model work? https://docs.tornado.cash/general/how-does-tornado.cash-work
• Privacy-preserving payment Solution (article) https://berkeley-defi.github.io/assets/material/Tornado%20Cash%20Whitepaper.pdf
• Waku store protocol specs https://rfc.vac.dev/spec/13/
• Waku-rln-relay specs https://rfc.vac.dev/spec/17/

Acceptance criteria

• A raw specifications of the waku store protocol incentivization via service credentials (in the RFC repo)
• A meta issue in the nim-waku repo capturing the rough implementation steps

cc: @oskarth

[oskarth]

Great stuff, I think this covers what we've talked about before. Some quick notes:

• It'd be useful if a consumer can get 100 credentials in one go, e.g. deposit 0.1 ETH and get 0.001 ETH x 100 tokens. This might be closer to the Nova model
• In addition to the nwaku issue, it'd be good to think about how implementation would work for Zerokit, as that's likely the first step and can be slightly more isolated
• https://github.com/ChihChengLiang/poseidon-tornado is a good example of a more modern and simple TC circuit that might be a better starting point for TC Classic, though it doesn't support the new Nova abstraction (haven't looked into this in detail yet)

[staheri14]

@s1fr0 following our conversation in the PM call regarding the next steps of the waku store protocol incentivization, here is the initial issue which captures the problem and the high-level solution idea. The development roadmap with more fine-grained milestones are captured in i.e., #135

As the first step, we need to decide on the payment model i.e., whether

1. users can spend (deposit & withdraw) a fraction of their service credentials
2. users can not spend a fraction of their service credentials
   and what are the pros and cons? If you could please look into that and see from the technical pov what are the trade-offs, that would be great. Once you share your thoughts in here, then we can make the next move and begin with the first milestone sketched in this issue The development roadmap of Waku store protocol incentivization using service credentials #135

Please have a look at this issue and the nwaku one and let me know if you have any comments or concerns.