Service Incentivisation MVP

[haelius]

Background

Service incentivisation over Waku is a topic that has been discussed and investigated more or less since the founding of Waku. Most recently we’ve published a speculative roadmap towards incentivisation focusing on Lightpush protocol. This resulted in a working proof of concept that shows basic payment for RLNaaS using Lightpush.

The MVP described here builds upon this PoC. It introduces a minimal but practically feasible system for incentivising service provision, managing payments, and tracking on-chain reputation. The goal is to demonstrate a working, end-to-end flow for incentivised services on Waku, that is usable in a testnet setting. This should be a significant step towards a robust service incentivisation layer in Waku.

MVP Scope

I suggest that we develop a protocol consisting of (only) three discrete, but integrated subprotocols:

1. Payment protocol: a privacy-preserving payment protocol for clients to pay for Waku services without requiring an on-chain transaction per service request.
2. On-chain reputation protocol: a transparent, minimal on-chain footprint to help clients identify reputable service providers based on observable behaviour (e.g., deposits, uptime, longevity)
3. Progressive trust protocol: protocol by which a client-service relationship can bootstrap from little (or zero) trust to a trusted relationship based on repeated good service provision and on-chain reputation.

What is out of scope?

• Service discovery is assumed to happen out of band. Clients “know” which service providers nominally provide a service interesting to them.
• Price negotiation for specific services is also assumed to happen out of band. In other words, we assume a client “knows” how much a service costs before the first payment.

MVP Components

1. Payment protocol

Purpose

The payment protocol defines how clients pay service providers in a way that is at least moderately scalable, unlinkable, and resistant to abuse. It ensures that service requests are paid for without requiring an on-chain transaction per request or linking the client’s identity to their wallet.

Requirements

1. No need for an on-chain transaction per service request
2. No direct link between Waku client identity and a specific wallet
3. Mechanism to prevent, detect or discourage double-spending

Possible implementation notes

• Service Credential-based Payments: Clients deposit funds on-chain and receive a batch of unlinkable, single-use service tokens (similar to other note-redeemable payment systems).
  • Each token has a nullifier associated with leaf in on-chain Merkle tree, preventing double-spending (at least of redeemed tokens).
  • Tokens are redeemed off-chain by submitting them to the service provider, who can redeem in batch
  • Tokens can be of equal denominations to simplify anonymity and validation.
  • In order to prevent abuse or frontrunning, we may have to make the token/notes redeemable only by a target wallet, which makes this (somewhat?) similar to a payment channel.
  • Double spending remains an issue before batch redemption, so mechanism to discourage this will still be required.
• Alternatives: Probabilistic micropayments, but these are possibly too complex or under-researched for this MVP phase.

2. On-Chain reputation protocol

Purpose

The on-chain reputation protocol provides a public, verifiable signal about a service provider’s trustworthiness. It is not a reputation score in the traditional sense (e.g., attestations or reviews), but rather a set of observable economic behaviors that clients can use to infer a basic trust level.

Requirements

• Clients must be able to query public, on-chain data to form a basic trust metric for service providers
• Reputation must be derived from behaviors that are costly to fake or incentivise honest participation

Possible implementation notes

• Provider Deposit: Service providers must publicly commit funds (collateral deposit or stake) in a smart contract as a signal of intent. This deposit is visible and timestamped on-chain.
  • Opportunity cost of keeping funds locked should be meaningful.
  • Stake is not slashed in MVP, but not withdrawing the funds is an implicit cost.
• Clients must be able to verify that a provider has deposited funds and not recently withdrawn.
• Trust/Reputation score can initially just be a combination of:
  • length of time provider’s stake has remained untouched
  • total number of service tokens redeemed
• This informs the initial trust metric a client assigns to a service provider before using it for the first time. It can also be used to continuously revise the trust metric for a specific service provider, augmenting the local reputation (see next protocol).

3. Progressive trust protocol

Purpose

This protocol governs the initial interaction and trust evolution between a client and an unknown service provider. It assumes a hostile environment where trust must be earned incrementally, using the signals provided by the on-chain reputation protocol and service quality assessments after each interaction.

Requirements

• Clients should start with minimal trust in a service provider and only increase that trust based on successful interactions.
• Initial interactions should have limited financial exposure to the client (e.g., low-value payments).
• Service providers must be able to advertise their staking/payment address and credentials.
• Clients must be able to verify the provider’s public address, match it against on-chain reputation signals, and decide on risk thresholds (see “On-chain reputation protocol”).
• Clients must evaluate service quality locally after each interaction and adjust local reputation scores accordingly. Bad service providers should not be used again.

Possible implementation notes

• I imagine we can use Metadata protocol for the service provider to provide some proof-of-delegation and its staking/payment address to potential clients. It’s possible that pricing and other service-related information be included in the Metadata exchange.
• The first payment from a client to an untrusted service provider should be small enough that it’s an acceptable risk to lose this payment.

Next steps

I propose that we treat the three components and their associated requirements outlined above as the definition of our MVP. The immediate action is to add or remove from this definition to gain consensus on an MVP definition.

The first concrete step after MVP agreement is to design a minimal protocol and specification that:

• Meets the stated requirements, even if imperfectly;
• Clearly documents assumptions, tradeoffs, and known limitations;
• Is practically implementable within the MVP scope.

The desired output is a single specification document that defines the overall incentivisation protocol.

[haelius]

Note that, although, I have jotted down some thoughts on implementation, the important thing is to agree on the requirements first. We likely need more research to design an implementation for each subprotocol.

[SionoiS]

I will argue that 2 and 3 are unnecessary.

We can keep reputation informal by just talking to users and service providers then make recommendations ourselves.

Nascent tech. attracts nerds, moderation, reputation or abuse prevention is not needed at first. Once we start scaling it will be important then.

With micropayment in place, risk is so small that trying new providers is not a big deal even if some could be scammers.

Building decentralized and private payment system is plenty complicated already.

The least usage of blockchains the better, we’re trying to be decentralized, private and with good UX.

P.S.
Also incrementalism =

[prem]

Thanks for detailing out the requirments.

I kind of agree with @SionoiS on 2 things

1. The least usage of blockchains the better, blockchains come with their own overhead and complexity that may not be needed.
2. Items 2 and 3 are not necessary for an MVP, we could just start with local reputation that was already built as part of POC.

@haelius

Price negotiation for specific services is also assumed to happen out of band. In other words, we assume a client “knows” how much a service costs before the first payment.

We could start with a fixed price per service-quantity at network level (e.g store query for X msgs has Y cost or store for duration T has Y1 cost) to make it simple and not have out of band negotiation. Price negotiation can be taken up at a later stage.

[Ivansete]

Thanks for the post!

1. I like the idea of requiring service providers to hold a deposit. It can act as a guarantee for consumers, covering potential damages.

2. How is trust measured?

3. Off-topic: The “Metadata” protocol feels too general-purpose. At some point, we may need to narrow its scope to ensure clear responsibilities and prevent it from growing unchecked.

[fryorcraken]

@SionoiS

Also incrementalism =

I assume you see the proposal as offering too little of an increment on current PoC? Can you expand on your thoughts?

Especially as at the same time, you suggest that the MVP can be reduced in scope (and hence a smaller increment )

---

Good stuff. Are we still thinking Light Push service? Or do we want to start expanding to store?

Is that the right direction building on the PoC? I haven’t yet played with the PoC, I guess my question is whether we should furthering the integration of the PoC (js-waku, store, etc) to continue dogfooding.

What did we learn from the PoC so far?

[haelius]

Are we still thinking Light Push service? Or do we want to start expanding to store?

Undecided for now, but I think the MVP will be easier to demonstrate with Store than Lightpush. This also matches long-term roadmap a bit better, I’d say. I don’t necessarily see RLNaaS as a major part of Waku in the future.

whether we should furthering the integration of the PoC (js-waku, store, etc) to continue dogfooding.

I don’t think there’s much point. The PoC demonstrates the different moving parts, but what is proposed here is substantially different enough that trying to maintain the PoC or expand it will not have much long-term benefit.

What did we learn from the PoC so far?

I think the PoC mostly allowed some things that we expected to be confirmed and demonstrated (e.g. the cost of frequent chain interactions, different functions involved with incentivisation, etc.). I think most of its benefit however is not so much in protocol exploration as in familiarising ourselves with the different technologies involved, web3 library, the nwaku codebase, etc.