Incentivized Lightpush: A Roadmap to Waku Service Incentivization

This document outlines the path towards a minimal viable (MVP) implementation of service incentivization in Waku.

Note: Although a protocol is not a product per se, we will use a familiar acronym MVP (“minimal viable product”) for the proposed initial implementation of an incentivized light protocol.

Background

The Waku network consists of nodes running RLN Relay. Such nodes may also run Waku light protocols and expose the corresponding services to clients. In the context of a light protocol, the node that provides the service is referred to as a server or a service node, and the node that consumes the service is referred to as a client or a light node.

Note: Contrary to traditional web services, servers in the context of this work should be thought of as access points to a service provided by a decentralized network (Waku) rather than owners of such service. This document uses the terms server and service node interchangeably.

Waku aims for economic sustainability, which implies that clients pay servers for their services. Currently, no such payment scheme is implemented. This document drafts a roadmap towards service incentivization in Waku, in particular:

  • lists design choices relevant for the task at hand;
  • proposes an initial architecture suitable for a simplified yet functioning MVP implementation;
  • outlines directions for future work.

The MVP will be used exclusively for testnet purposes. There are no plans to integrate the MVP into the Status app. The aim is to develop a simple application (possibly web-based) that utilizes the MVP, enabling internal testing and feedback collection. That should help us identify the key friction points that affect users most, allowing us to prioritize post-MVP improvements.

Defining the Scope

Let us define the scope of service incentivization in the context of Waku as a whole.

We can divide Waku protocols into three areas:

  1. the interaction among RLN Relay nodes and the RLN smart contract;
  2. the interaction between a service node and light clients (the topic of this document);
  3. the interaction between a Waku-based project (like Status) and its end-users.

This document focuses on the interaction between service nodes and light nodes.
Communication between RLN Relay nodes, RLN provision for service nodes, and projects’ interactions with their end-users, are out of scope.

Choosing Lightpush for Protocol Incentivization MVP

We propose using Lightpush with RLNaaS as the first service to incentivize.

Lightpush is a light protocol that allows clients to send messages to the Waku network without running RLN Relay. Instead, a client asks a server to send a message to the network on its behalf. The server attaches its RLN proof to the client’s message (aka RLNaaS, or proofs-as-a-service) and sends the message to the network. Note that the client not only consumes computational and bandwidth resources of a server, but also part of its RLN rate limit.

Lightpush is convenient for an incentivization MVP mainly because it can be cleanly separated into request-response pairs. This makes it more suitable for a simple one-transaction-per-request payment scheme (see below). In contrast, other light protocols (Filter and Store) imply that the server, in general, sends back multiple responses for one request.

Architecture Overview

The incentivized Lightpush MVP contains the following components:

  1. Price Negotiation: the client learns how much to pay for the service it needs;
  2. Payment: the client pays, generates a proof of payment, and sends the proof alongside its request to the server;
  3. Request Handling: the server handles the request;
  4. Reputation (including Service Quality Assessment): the client assesses the quality of service and adjusts the server’s reputation.

The overall architecture is shown in the following diagram:

Source code (Mermaid):

sequenceDiagram
    participant Client
    participant Server
    participant PriceSource
    participant WakuNetwork
    participant OtherServer

    alt
	    rect rgba(0, 0, 0, 0.05)
		    Note right of Client: Price Negotiation Component
	        opt Price Inquiry to Server
	            Client->>Server: Price request
	            Server->>Client: Price
	        end
	        opt Price Inquiry to Price Source
	            Client->>PriceSource: Price request
	            PriceSource->>Client: Price
	        end
	    end
    end
	rect rgba(0, 0, 0, 0.05)
		Note right of Client: Payment Component
	    Note over Client: Make payment
	    Client->>Server: Service request with proof of payment
	end
	rect rgba(0, 0, 0, 0.05)
		Note right of Server: Request Handling Component
	    Note over Server: Attach RLN proof
	    Server->>WakuNetwork: Client's message with RLN proof
	    Server->>Client: Acknowledgement
    end
    rect rgba(0, 0, 0, 0.05)
	    Note right of Client: Reputation Component
	    opt Service Quality Assessment
	        Client->>OtherServer: Waku Store request
	        OtherServer->>Client: Client's published message
	    end
	    Note over Client: Adjust Server's reputation
	end

The following sections go into more detail for each of the components.

Price Negotiation

We suggest a take-it-or-leave-it approach to price negotiation.

The server announces the price, and the client either accepts or rejects it. The server also decides which tokens it accepts. This scheme is simple and also quite similar to how most purchases are made in the B2C world: customers generally don’t negotiate prices with service providers.

The server may publish its prices off-band, e.g., on its website. The client then can look up the prices and pay the correct amount right away without a price request. This option assumes that the client knows the server’s payment address.

Payment

Within the Payment component, the following design decisions must be made:

  • Which network is used as payment rails?
  • Does the client pay before or after the service is delivered?
  • What does the client provide as proof of payment?
  • Does the client pay for every request, or pre-pay for multiple requests at once?

Payment Rails

We propose using an EVM-based L2 network (possibly Status Network, subject to its development timeline) as payment rails.

Potential options for payment rails include L1, L2, or off-band fiat payments. The latter is less preferable, as we strive for decentralization in general. L1 payments, generally, exhibit higher latencies and higher costs, albeit with stronger security guarantees. Low latency is important for UX, especially in the context of one-transaction-per-request payment scheme (see below). Overall, as we deal with relatively low-value transactions, the trade-off that L2s provide looks acceptable.

Pre-payment or Post-payment

We propose using a pre-payment scheme.

The main reason to use pre-payment rather than post-payment is to protect the server. Server’s security risks are two-fold:

  • The client consumes more resources than they pay for;
  • The client issues too many requests.

Pre-payment addresses both risks with economic means. A prepaid client can’t consume more service than they paid for and is discouraged from sending too many requests.

Proof of Payment

We propose using a transaction ID as proof of payment.

The steps related to proof of payment are similar on L1 and L2:

  • The client sends a transaction to the server’s address;
  • The client receives a transaction ID (a transaction hash) from the network used as payment rails;
  • The client attaches the transaction ID to its request as proof of payment;
  • The server looks up the client’s transaction to ensure that it is confirmed.

Implementation details for proof of payment depend on the architecture of a particular (L2) network chosen as payment rails.

Payment Frequency

We propose a one-transaction-per-request payment scheme: the client pays for each request separately.

The alternative is bulk payments, where a client pre-pays for multiple future requests with one transaction. Bulk payments amortize transaction costs over multiple requests. The drawback of bulk payments is that a client assumes the risk that the server would keep the money but fail to provide the services. This risk can be mitigated in one of two ways:

  • build trust between the client and a server, which likely requires a robust reputation system;
  • establish atomicity between service delivery and payment (so that the server cannot claim the payment without providing the service), which requires additional cryptographic schemes and is only applicable to provable services (see below).

We conclude that bulk payments are better suited for later development stages, whereas the traditional drawbacks of one-transaction-per-request scheme (latency and transaction cost), typical for L1 deployments, will be alleviated on L2.

The question of whether such payment scheme would induce too much stress on the payment rails is left for future analysis.

Request Handling

The server handles requests as it does currently in the non-incentivized version of the Lightpush protocol.

Note that the Waku network doesn’t provide an acknowledgement to the server.
To check whether the message has published, nodes may use Filter protocol. In the context of this work, we assign this responsibility to the client.

Reputation

We propose a local reputation system to punish bad servers and increase client’s security in the long run.

A client initially assigns 0 reputation score to all servers. After each request, the client performs Service Quality Assessment, and decreases the server’s reputation score if the service quality was unsatisfactory. If the service was of good quality, the client increases the server’s score. The decision on how much to increase and decrease the reputation is up to the clients.

Local reputation scoring does not solve the issue with client security completely. Malicious servers can accept payment from a new client and fail to provide the service, however:

  • the client’s monetary loss is minimal with one-transaction-per-request payment scheme;
  • over time, the client accumulates knowledge about servers’ reputation;
  • trust-based third-party scoreboards (akin to L2Beat or 1ML) can be used as a supplementary reputation mechanism.

Service Quality Assessment

Service Quality Assessment is an essential part of a reputation scheme. To decide on reputation change for a server, the client must evaluate the quality of the service provided. In the context of Lightpush, the client should check whether the message has been broadcast by making a Filter Store request to another server.

Store is a Waku light protocol that allows a client to query a server for a message that was previously relayed in the Waku network. Note that Store will also be incentivized in the future. Until Store incentivization is rolled out, service quality assessment for Lightpush is free (at least in monetary terms).

The client may also use other methods for assessing service quality.

Post-MVP roadmap

A generalized service marketplace is the medium to long-term vision for Waku client incentivization. As first post-MVP steps, incentivization will be extended to other Waku protocols like Store and Filter. Ultimately, an open market for arbitrary services will be established, using Waku as a plug-and-play component for service provision and payment.

The rest of this section lists potential directions for post-MVP development related to service incentivization.

Server and Price Discovery

In the MVP, server discovery and price discovery happen off-band. Post-MVP, more decentralized methods will be considered. For instance, server announcements (along with provided services and prices) can be distributed in the Waku network itself in a special shard or content topic on which service nodes broadcast and clients listen. Such dedicated information channels may be seen as system features, and therefore provide free Store queries and Filter subscriptions for clients.

Price Negotiation

Multi-Step Price Negotiation

A more involved scheme for price negotiation would involve a multi-step process, where a client can make a counter-offer, which the server then accepts or rejects. The negotiation is then repeated for up to a certain number of steps. The server and the client may optionally commit to the agreed upon price for a certain number of future request to amortize the cost of price negotiation across multiple requests. A related potential research direction is whether servers should be able to offer zero fees to attract clients. Such scheme should be additionally protected against abuse, and we should ensure that protection measures preserver clients’ privacy.

Payment

Bulk Payments

Bulk payments optimize the one-transaction-per-request scheme by allowing:

  1. The client to pay once for N future requests.
  2. The server to record the client’s balance.
  3. The server to decrement the client’s balance while serving each request.

In this setup, the client effectively extends a line of credit to the server, which the server repays by providing the requested service.

The main advantage of bulk payments is better scalability, as transaction costs are spread out across multiple requests. However, the drawback is the additional risk to the client: if the server defaults on its promise of service provision, the client stands to lose more money than in the one-transaction-per-request scenario.

Reputation system becomes more important in the case of bulk payments. It may be possible to develop a cryptographic scheme (sometimes referred to as “credentials”) to establish a link between service performance and value transfer to the server.

Lower-Latency L2 Proof-of-Payment with Preconfirmations

Preconfirmations are a trending topic in L2 R&D that further reduces payment latency.

On L2, the definition of a “confirmed” transaction is more complex than on L1. Multiple actors—such as sequencers and provers—participate in L2 transaction processing. The core idea behind preconfirmations is that parties responsible for transaction processing issue signed promises of future transaction inclusion. Under a weaker trust model, such promises can signify transaction confirmations to servers that choose to trust preconfirmation issuers.

In the context of Waku, preconfirmations or similar add-ons in L2 protocols mean lower latencies and better user experience. However, changes in trust assumptions should also be considered.

Gasless Payments

To further reduce the barrier to entry for clients, gasless payment schemes (e.g. involveing paymasters) will be considered.

Reputation and Service Quality Assessment

Global Reputation

Global reputation allows clients to not only accumulate knowledge about server’s behavior and performance, but also to share this information, additionally protecting new clients. A central trusted reputation registry, while technically possible, would be a central point of failure (or censorship). Decentralized solutions for global reputation would be preferable (such as Eigentrust and Unirep).

Mutually Trusted Escrow for Service Quality Assessment

A server and a client may agree on a mutually trusted party (“escrow”) for service quality assessment. The escrow server would verify the server’s performance and report the results to the client. In the context of Lightpush, the escrow server would check whether a message has been relayed. It remains to be seen whether an escrow-based scheme is justified for lower-value payments expected in Waku light protocols.

Provable Services

Certain services can be verified cryptographically by the client. A toy example is revealing a preimage of a given hash value. For such services, a trustless verification procedure can be constructed. However, real-world scenarios for the usage of such services may be limited.

Privacy and Anonymity

The protocol will be improved to ensure stronger privacy guarantees for the client. in particular, zero-knowledge notes may be used to remove linkability between the client’s IP address and their wallet address.

Waku Sustainability and Service Incentivization

The long-term goal of Waku is to become financially sustainable. Service incentivization may be a step in that direction.

Broadly speaking, there are two ways to capture value from Waku protocols:

  • Redirect part of the value flow (a “tax” on every transaction); or
  • Link the functioning of the Waku protocol to the value accrual of a specific asset.

We will explore these and potentially other options to ensure Waku’s long-term sustainability.

Conclusion

This post introduces incentivized Lightpush as the first Waku light protocol to be incentivized. We describe the proposed MVP architecture and explain our design choices. We also outline directions for future work and discuss light protocol incentivization in the broader context of Waku’s overall sustainability.

Comments and suggestions are appreciated!

UPD (2024-09-19)

Thank you everyone for your insightful comments!

I’ve updated the post to reflect some discussion items, in particular:

  • specified the goals of the MVP more clearly;
  • suggested using Store (and not Filter) for service quality assessment;
  • added more post-MVP research directions including privacy and anonymity.

The next steps will be:

  1. update the specification to reflect the choice of Lightpush as the first incentivized service;
  2. start working on the implementation.

Thanks once again for the discussion!

6 Likes

Thanks for a nice and detailed post @sergei-tikhomirov .

I agree with almost all points, but have few concerns/comments

Wondering if point-2 falls under the scope of point-3 i.e interaction between Waku-based project and its end-users. Because typically in the waku-network light-clients will only be used by applications build on top of Waku.
So, why the segregation of these 2 points?
Do you see any other use-cases where lightClient usage of waku is independent of any project?

This will add a lot of overhead to lightClients, considering they are supposed to be light in nature. Currently, without incentivization it is just a single req-resp protocol to send a message via lightpush. But with this proposed change, in order to send a single message via lightpush a client has to perform almost 3 additional req-resp with various node in the network that will add lot of latency and may deter users from using this service. Instead a bulk payment option would suit better for a lightpush client, where either they pay ahead for a certain rate-limit from the serviceNode. This way for a light-client, the overhead for each message would not be that high in comparison to what they have today. Since waku is not to be used for sending large amounts of data (i.e it is only meant for small messages, this approach would deter usage of Waku) especially by light-clients considering they run on mobile/browser mostly.

I understand your reasoning for not considering bulk payments approach is due to the fact that a server can just vanish after taking payment and hence the client is at loss. In order to mitigate this, can’t we use the escrow model proposed post MVP where payment is held to server until client acknowledges service is provided? I see that this complicates the system little more, but it simplifies the flow for sending a message.

I am assuming for the MVP the payment channel be fixed. It would make the implementation of MVP also simple.

Any steps taken to protect the client since payment for sending a message involve monetary transaction, would be better to have some very simple approach of protecting the client as well.

Haven’t gone throught he post-MVP part of the post yet. Will go through again and reply separately.

Thank you @prem for your comments!

In my view, in scenario (2), light nodes operate as independent entities, while in scenario (3), they are somewhat “linked” to their respective service providers. In scenario (3), a project can set up its own centralized protocol for communicating with its end-users, and from Waku’s perspective, it would be seen as a single Relay node. As a result, reputation plays a smaller role in scenario (3) compared to scenario (2). This is because, as a user, I already trust the project I’ve chosen to connect to. In contrast, in scenario (2), the light node connects to a relatively random service node, so it needs to maintain at least a local reputation score.

Fair point. Do you think we can quantify the additional latency we’d introduce with this proposal, and what latency a typical client can tolerate?

My reasoning has been that, although we increase latency, the protocol remains conceptually simple and cleanly separates the handling of individual messages. However, if we move into bulk payments, we’d need to address several issues. For example, if a client pre-pays for 100 messages, uses 10, and then the service node raises prices, what happens next? Does the client retain the old pricing? Is the remaining quota of 90 messages reduced? Should the user have to approve any of these changes? If the service node doesn’t want to honor the old prices and the client refuses the new rates, should a refund be issued? I suspect this is just the beginning of the complications we’d face with bulk payments—these are merely the first that come to mind.

they pay ahead for a certain rate-limit from the serviceNode

Do you think we should frame pricing in terms of rate limits rather than messages? What would be the pros and cons of rate-limit-based approach?

can’t we use the escrow model proposed post MVP where payment is held to server until client acknowledges service is provided

My concern would be that the client would get the service and falsely claim that they didn’t. I would assume that the escrow model (which I briefly mention in the Post-MVP section) would require a mutually trusted third party (another server?).

I am assuming for the MVP the payment channel be fixed.

Do you mean by “fixed” that we should definitively agree which blockchain / L2 we’ll deploy on? I agree, although we’d need more information (such as Status Chain launch timeline), and I’m not in a position to make this decision.

Any steps taken to protect the client since payment for sending a message involve monetary transaction, would be better to have some very simple approach of protecting the client as well.

I’m not sure I get this point. For clarity, by “protecting the client” I mean “avoid situation where the client pays but doesn’t get the service”, and by “protecting the server” I mean, symmetrically, avoiding “the server provides the service but doesn’t get paid”.

Thank you @sergei-tikhomirov for the detailed post.

I agree with the scope of the MVP. I also agree to leave bulk payment and other concerns addressed by @prem in Incentivized Lightpush: A Roadmap to Waku Service Incentivization - #2 by prem to a second iteration.

The MVP, integrated in some web app or other light client, should help us better understand the friction points that impact the user the most, and prioritize accordingly post MVP.

The post does not address what will be done with the MVP. I think it would be relevant to state expectations such as:

  • MVP would be for testnet purposes only
  • Aiming to have toy app that uses the MVP (potentially web based), to dogfood and gather feedback.
  • Not aiming to have Status app PoC integration for this MVP.

Here are further notes:

Reputation

I would not emphasis too much on the usage of filter as store is what the reliability protocols use.
Filter is fine to use, if the client has already a subscription running on the right content-topic.
One of the issue in the diagram is that it seems a filter request is done after sending the message. This won’t work as the filter subscription should happen before sending the message.
I would suggest to hook in the reliability protocols instead, such as store confirmations.

Post-MVP roadmap

Multi-Step Price Negotiation

I am not convinced that we would need any form of multi-step price negotiation.
The proposed take-it-or-leave-it approach is likely to be enough. The assumption is that if a client is not satisfied with those prices, then they can go and find an new server.

Instead, I would suggest price discovery as a step on the roadmap. So that a client can get easy access to price information to select a service node.

Privacy

Privacy and anonymity is not covered in this post. We should highlight that a service node will be able to link a wallet address to an IP address. Which can put the user to a $5 wrench attack.

In the context of Waku, improving privacy is an important Post-MVP step.

Priorities

From a UX perspective, it seems the post MVP items touch on:

  • Latency (pre-confirmations, bulk payments)
  • Cost:
    • Gas (bulk payments)
    • Price (negotiation)
  • Privacy
  • Quality of Service (reputation, escrow, provable)

The MVP should be used as a tool to understand the needs of our users (e.g. Status) and prioritize the points above accordingly.

I also think the following should be considered in the post-mvp roadmap:

  • zero-knowledge notes to remove linkability between IP and wallet address
  • off-chain payments to remove gas cost for client → service-node payment
  • price discovery
1 Like

Thanks for the explanation. Makes sense.

Hard to say as it may be app specific(e.g status may have different latency requirements than say some other app), just wanted to indicate the overhead added in comparison to current lightpush seems multi-fold.

Got it, understood why we are taking simpler approach for MVP. As @fryorcraken indicate, if this is meant mainly to build a POC app and not for actual prod integration, i agree that we can go ahead with current proposed MVP approach.

i was thinking of this as synonymous to how RLN is priced based on rate-limits and not just messages. I was thinking it would make it easier to map these limits to RLN limits in service-nodes then.

yes and i understand we don’t need to make a decision now.

Sorry for not being clear, what i meant was that most of the approach in MVP is taken considering protecting the server and not the client and hence wanted to know if there is a plan to include any protections for the client in MVP. As i understand MVP is not meant to be integrated with any production apps it is fine to not include any such measures to start with.

Thanks for the feedback @fryorcraken!

Thanks for the pointer, this absolutely makes sense.

Any ideas on how price discovery could work, in broad strokes? Does price discovery entail a (semi-?)centralized bulletin board where service nodes post their prices? I’m expecting difficult trade-offs here in regards to performance vs censorship resistance. Is there an example in some other project where price discovery is working in roughly the way that suits our use case?

Agree, although it’s hard, in my view, for the client-server model to preserve the same privacy model as the P2P model.

Is a VPN or Tor a reasonable temporary privacy-protecting measure for clients here?

One concern here would be not to avoid unwanted financialized use cases.

By “off-chain” here do you mean via paymasters?

Thank you, @sergei-tikhomirov, for this comprehensive post. Some thoughts and comments:

Payment Denomination

For the sake of completeness, I think it’s worth mentioning that the denomination of payments remains an open question. This could extend to the possibility of accepting multiple tokens in the future. However, for the MVP, it probably makes sense to keep things simple and focus on one payment method to mature the payment rails.

Bespoke Services and Pricing

This proposal seems tailored to a standardized service model where the server announces a price for a generic product. However, one can envision a more bespoke service where the client submits parameters for a desired service, and the server offers custom pricing based on those inputs. Would you consider this as a future extension of the current scheme?

Alternatively, such negotiation could happen outside the protocol itself, with only the outcome (the agreed price) being integrated into the server’s offer. This leads to the question of whether we should impose any structure on this negotiation process. I think this also touches on @fryorcraken ’s point—where any back-and-forth before the server’s final offer could essentially be “cheap talk.”

Proof of Payment and Role of Intermediaries

I could see payment and service verification evolving into a potential service offered by nodes, perhaps with added privacy benefits. This seems aligned with the escrow QA role you mentioned. Similarly, considering that service agreements are peer-to-peer without visibility across the broader network, I foresee a role for trusted intermediaries in facilitating these agreements. These intermediaries could also contribute to unofficial or proprietary reputation systems. Another motivation for using an intermediary comes from the bulk payment design: rather than leaving funds with a single service node (and risking that node going out of business), the balance could be held by a trusted facilitator, who could switch between service nodes as needed.

In this respect, I wonder if there would be any benefit to having an optional mechanism for disclosing/attesting service agreements publicly. I’m not entirely sure how this would function, but having a way to push agreement receipts on-chain or off-chain could create a data source for custom reputation metrics. In addition, this might be essential for enabling future services being provided outside the Waku network while being facilitated through it.

Reputation and Service Provider Differentiation

It’s worth noting that reputation could become a centralizing force if there aren’t enough differentiating factors between service providers. If the main dimensions remain limited to price and service quality (which may be difficult to observe), clients might optimize for price alone, and discovery could gravitate toward the cheapest tier. This, in turn, could have adverse effects on the presence of high-quality service providers in the market.

Service Discovery

One missing piece here, in my opinion, is the issue of service discovery. How does a client identify a / the right service node when they need it? While I understand this has been discussed elsewhere, I believe it’s a crucial point in this context as well. Node visibility could play a strong centralizing role, especially in the absence of a global reputation system.

Thanks for your comment @mart1n!

Indeed, another reason why Lightpush is well-suited for the MVP is that the service is standardized: there is not a lot of ways in which message publishing can be personalized.

As a post-MVP research direction - possibly (depending on priorities set based on the initial feedback).

Do I understand your idea correcty: the server would publish a commitment a-la “I promise to deliver service X for whoever pays the price Y”, and a client can later show this commitment along with a proof that a) they paid Y; b) they didn’t get service X, and the server would be punished as a result (have its reputation decreased, or maybe slashed even)?

That’s a very good question, I’d need to think more about it.

Thanks for the post!

I think this is a decent starting point for the Service Incentivisation roadmap and the scope looks good for an initial MVP.

A comment on what we build first: even though I’d still see this as part of the MVP, I’d focus on the price negotiation mechanism last and build everything else in the MVP first. This is because the proposal works equally well if we assume that client and server has somehow agreed out of band what the service will cost or that the server has published its prices “somewhere”.

Next step is perhaps to expand the existing spec (we could replace this section to reflect Lightpush: specs/standards/core/incentivization.md at master · waku-org/specs · GitHub) and start working on the implementation?

@sergei-tikhomirov thank you for this detailed write up!

One question I have re:

  • The client sends a transaction to the server’s address;
  • The client receives a transaction ID (a transaction hash) from the network used as payment rails;
  • The client attaches the transaction ID to its request as proof of payment;
  • The server looks up the client’s transaction to ensure that it is confirmed.

As described, would it be possible for a bad actor to be listening to the server’s address for such events and steal tx ids?

I would assume the TX id is signed with the same address keys no?

1 Like

Do I understand your idea correcty: the server would publish a commitment a-la “I promise to deliver service X for whoever pays the price Y”, and a client can later show this commitment along with a proof that a) they paid Y; b) they didn’t get service X, and the server would be punished as a result (have its reputation decreased, or maybe slashed even)?

Actually, I was thinking in more basic terms: The server can publish the proof of the payment optionally somewhere publicly along with some other agreement details (which would probably make sense for store). Although this might actually be implemented (and enforced) within the payment scheme by design (e.g. redeeming notes on-chain), this public record could serve additional purposes beyond just settling the payment.

Potential benefits:

  • Bragging rights for service providers: Providers can showcase successful transactions as proof of their reliability.
  • Metering: The Waku team could observe network activity.
  • Easier service provider discovery: Clients could find providers based on popularity or activity, helping to surface trusted nodes.
  • “Event” triggers: These records could initiate actions outside the Waku Network.

Great question, @chair! TBH I haven’t given it much thought, though the solution by @SionoiS solves it:

the TX id is signed with the same address keys

I’d note that there may be privacy implications from requiring the client to sign a message with the same Ethereum address they send the payment from, but I don’t see it as critical for the MVP.

Fundamentally, I see another way to look at this issue: it is essentially front-running, right? Front-running aka MEV (the latter term is more generic) is common everywhere these days (both L1 and L2). The usual way to address it is via a trusted party. There is a “MEV-protection service” which you (or your wallet) exclusively submit your transactions to. The service prevents other actors from seing your transactions until it’s too late to front-run them, and you trust the service that it won’t frunt-run you either. If that’s where the general L2 security model is moving, then maybe our use case is just fine. At the very least, front-runners will likely have more valuable targets (AMM liquidations, arbitrage, etc) rather than our humble message-publishing service. Something to analyze post-MVP.

2 Likes

For me this sounds somewhat privacy-intruding. In the “real world”, I don’t think it’s generally OK (or even legal) for businesses to publish details of their agreements with clients (if that agreement is not a publicly available standard offering).

Also, isn’t it easy for a server to inflate transaction-based metrics? The server operator can create many addresses to play the role of “clients”, send transactions from those addresses to its own server’s address, and climb in the ranking without providing any real service.

1 Like

Great point @haelius, I agree. I see price negotiation as optional for the MVP, especially in the absense of server discovery. If clients would have to look up servers “somewhere” anyway, why not look up their prices in the same source?

Speaking of: what’s your take on server discovery? Should we include this aspect in the MVP?

I would exclude it, although it’s certainly part of the longer term roadmap. In the same way that prices can be “known” out of band, we can assume that servers providing the service is known without hindering dogfooding the mechanism itself.

It depends what we mean by privacy. I was specifically referring to linkability between IP address and wallet address.

Most likely a specific shard or content topic on which service provider broadcast and clients listen. Some special rules may be useful on this one such as free store queries and filter subscription as it could be seen as a system feature.

Yes, implementing TOR-PUSH would help here but I assume we will have opportunities to fix this as we further the work on incentivisation.

Yes, we can keep that in mind.

Something that does not cost gas at every action. We can review when needed.

Such a signature should not be part of the Waku message, but part of the light push request so that it is ideally only seen by the service provider.

In terms of privacy, it falls on the same bucket than the concerns I highlighted in terms of wallet address to IP address linkability. As well as wallet address to message metadata linkability.

Finally, even if the signature is only on the light push request and not propagated to the relay network with the message, the service provider could leak the light push request and provide non-deniable proof that a given wallet address is the sender of a given message. Something to note in the RFC.

This is an additional reason why privacy strategy need to be added to the post-mvp roadmap.

1 Like

I am trying to understand the benefits and how this would play out if the payment precedes the service: If the node knows that the payment transaction is coming, it has more time to deliver the service and minimize latency?

You also mention atomicity as an ideal outcome. However, this operation takes place on an L2 and in the WN (pay and be able to send messages). Therefore, I think the question is how we define atomicity in this environment. What would be an ideal execution in this sense?

If the public key of the service provider is available, the client can encrypt the message and only then sign the encrypted message. This allows the provider to verify the message and limits the “leak” to the case where provider’s private key is leaked as well. Of course, the provider if bad actor, can rotate these keys per client and bypass this.