RLN-based micropayment scheme

[SionoiS]

In the context of Waku service marketplace I’ve had this idea for a micro-payment scheme using RLN tech.

Smart contract

• Membership
• Gated by payment escrow
• Payment value
• Probability of payment
• Registered vendor pubkeys

RLN

• Membership proof (since the SC is gated by payment it’s also proof of payment)
• Limits the number of probabilistic payment (tickets) that can be sent otherwise the secret key used for the escrow can be stolen (slashing).
• Vendor pubkey is part of the proof.

Probabilistic payment

• RLN proofs are verified by vendors
• Proof data is used as VRF input with the vendor keys
• Random output is checked against the SC probability of payment
• If winning vendor submit onchain; RLN proof, VRF proof and is payed

Advantages

• Does not have the double spend problem (assuming RLN proofs are verified)
• Payment escrow can be very close to face value

Disadvantages

Expensive onchain verification???

WDYT? Am I missing something?

[fryorcraken]

To reduce UX the intent is to move away from deposit for RLN membership acquisition, or at least, propose alternatives.

Having said that, a model where the RLN deposit can be used for payments makes sense.

It can still be something that lives together:

1. user uses some PoH to get RLN membership (or paid by app dev)
2. user uses some free quota, or subsidised quota (tbd)
3. user wants to upgrade, use deposit to get bigger RLN membership and then start using model.

[SionoiS]

I should have been more clear I’m not taking about RLN-relay or Waku.

I’m talking about RLN as the tech itself used for micropayment in the context of a service marketplace.

[haelius]

I may not understand your full scheme, but why wouldn’t a user “slash” itself in order not to pay for the full service it received?
Perhaps this model will work better without slashing? In that case the escrow cannot be slashed, but a user’s service requests can be rate-limited and any requests over the rate limit simply ignored. In that case, though, why not use the simpler model though of simply having an escrow contract that gets probabilistically settled?

We’ve previously considered applying RLN for a “service subscription” model, where users pay to be included in a membership that has access to a service. However, we’ve imagined the payment to be settled and distributed prior to membership inclusion, which of course leaves users open to service node exploitation.

[SionoiS]

@haelius

I may not understand your full scheme, but why wouldn’t a user “slash” itself in order not to pay for the full service it received?

Ah that’s a good point! Maybe slashing should only be a part of the total value deposited.

@haelius

Perhaps this model will work better without slashing? In that case the escrow cannot be slashed, but a user’s service requests can be rate-limited and any requests over the rate limit simply ignored. In that case, though, why not use the simpler model though of simply having an escrow contract that gets probabilistically settled?

Double spend is always a problem, you have to deal with it somehow. You can’t “simply” probabilistically settle transactions. Either you find an economic way to make it not worth doing or you try to find another solution.

@haelius

We’ve previously considered applying RLN for a “service subscription” model, where users pay to be included in a membership that has access to a service. However, we’ve imagined the payment to be settled and distributed prior to membership inclusion, which of course leaves users open to service node exploitation.

That’s why micropayments makes more sense, if the service provider stop providing then no more payments.

[SionoiS]

I realized that since the user can always slash itself at any point then the whole system can’t possibly work. Oh well…