The case for Waku financial incentivization

Waku
,
1

I am writing the fourth and last post of Waku explanation series, a series of post to introduced core concept, and value proposition to the reader [1] [2] [3].

This fourth post is different because it addresses the Waku Service Marketplace. Contrary to the other protocols and features covered in previous poist, the Waku Service Marketplace is only a concept. Research is in progress to deliver protocols and software to enable it.

Because this post is more about a vision, than actual code and protocols, it seems adequate to open the discussion before publishing it.

Of course, the Waku team discussed this matter many times, especially during the Athens offsite. So it shouldn’t be new to most people. It was also discussed in this forum [4].

With this present post, I’ll also expand on some of the concepts that I removed from the blog article for brevity purposes. You are welcome to discuss both the article draft [5] and the present post in this thread (or comment directly in Notion if you are an IFT CC).

Also, best to read the blog article first.

RAILGUN case study

In the argument of financial incentivization to ensure the reliable provision of Waku service, I make a case that store is a hungry service, for which incentivization is necessary.

Interestingly, RAILGUN [6] does not enable store services on their fleet or broadcasters [7].

Let’s quickly review how RAILGUN uses Waku:

  • Wallet users push fund to a zero-knowledge onchain contract, and then uses those fund to perform DeFi actions in privacy.
  • This is possible by having broadcaster performing the onchain actions for users.
  • Observers of the blockchain can only see wrapped transactions performed by broadcasters wallets, and cannot deduce what user actually performed said transaction.
  • Users transfer funds to broadcaster to perform the defi action, and pay the broadcaster, using zero-knowledge notes.
  • Which means that while you may see that a wallet has sent funds to the RAILGUN smart contract, you cannot deduced what kind of DeFi action they are doing.

RAILGUN do not have to use store, because:

  1. Broadcasters regularly send their fees; meaning a browser or mobile wallet can get online, and wait for the latest fee to be sent.
  2. RAILGUN developers implemented an end-to-end reliability protocol for transactions, where the broadcaster sends a ACK back to the wallet when receiving a transaction request. If no ACK is received, the wallet re-sends the transaction.

Which means that store is neither needed for historical message retrieval, nor for peer-to-peer reliability, as a robust end-to-end reliability is available.

Moreover, because of their early integration of Waku, past unreliability in our js-waku stack (we’re working on it [8] [9]), and, more importantly, a will to higher privacy standards, they use Waku relay in the browser.

So does the argument for incentivization still stand for RAILGUN?

The usage of relay in the browser has inherent scalability limitations [10]. This is mainly because of the lack of browser-to-browser connection. Leading browser to deplete the gossipsub mesh of service nodes. Note this is mitigated by the fact that Waku Relay uses flood publish (node initiating a message sends it to all connected peers in the shard, and do not restrict the publication to mesh peers).

Adding WebRTC to the Waku transport stack has been considered [11]. However, it comes with its own challenges. Not all WebRTC connections can be done without STUN/TURN servers.
Maybe enough connections can be done without them to make the Waku Relay network work?
The issue with such a bet (enough browsers can do WebRTC connections without TURN/STUN servers), may be loss when users from specific geographical location are flock in.

Adding TURN/STUN servers to Waku services is an idea we’ve be keen to explore. But it is very similar to store in terms of resource usage, most likely revalidating the argument for financial incentivization. Nonetheless,

Which means that if store is not needed, and light protocols are not needed, then there is still a scarce resource: the number of inbound connections from the fleet, to allow access to browser wallets (assuming mobile to mobile TCP connections are happening).

In this specific instance, it may be possible to have another form of incentivization to ensure this resource is available. For example, broadcasters could be encouraged to run services to support additional users, especially browser wallets. They are encouraged to do so as more user, more usage and hence more revenue.

Waku-network-per-app vs shared networks

In the blog post [5], I justify financial incentivization in a simplified scenario: one Waku network per application. While this simplify the reasoning, we aim for it to not be the de facto topology. Indeed, having a network per application implies caveats:

(1) no participation anonymity: if you are part of this app network, then it’s very likely you are using, or supporting, this app.
(2) reduced properties: a smaller network lead to reduced scalability, reliability and censorship-resistance.

We promote a model where privacy-focused applications use and remain in a shared network.
While other applications, may start in a shared network and graduate to their own network as they group. This post discussed various aspect of a Waku network of networks [12].

The shared network model strengthens the argument for financial incentivization. Indeed, in a network where all users are using the same app, it might be possible to put in place private tracker style reputations. By having some tracking in the app to encourage users sharing resources to the Waku network, and have some in-app rewards for it.

This becomes ineffective as soon as two apps share the same network. How to track that the resources shared by users of app A, are not exploited by users of app B?

The only solution here is either separate networks, or have a generalized system: financial incentivization. So it can be fine for both applications to share resources, as users, or projects, pay for what they use.

Waku Store vs Codex

The purpose of Waku Store is to cache messages for offline devices. Waku store is not expected to be durable, it is not designed to keep your messages forever, or even 30 days.

Codex [13] has been designed for data durability. The expectation is that if Waku messages need to be retained, then a mechanism should be developed to archive them on Codex [14]. This implies paying Codex for archiving.

Which means there may be a case to reduce the pressure on Waku Store. If Waku store nodes may only need to keep message for a day, or even few hours, before the important ones get archived on Codex. Then one could imagine how desktop users sharing some gigabits of hard drive would be enough.

But again, this only work in a topology where all users can share resources. Similarly to BitTorrent, where all users can seed as they leech.

This fails as soon as mobile and browser are brought in the picture, as each store node will have a limit on how many edge node they can serve.

References

1 Like
2

Thanks for the interesting post (both the general explainer and this forum).

Some orthogonal comments:

I’d say, if the end game for incentivisation is “no infra”, then the argument stands even if the Waku-using (d)app doesn’t use any Waku services, such as Store. I think the question to ask ourselves here is how an app like RAILGUN will be incentivised to contribute their infra to the general network. For one, if we can add enough value in terms of k-anonymity and RLN-based DOS protection,the tit-for-tat incentives would be enough for app users to participate as full relay nodes in a shared relay infrastructure (like the TWN). The one outstanding building block would be bootstrapping, which I believe can similarly be decentralised. In other words, by focusing on the tit-for-tat model we can create a strong self-sustained infrastructure without Waku services.

Another point we’ve made before is that (presumably), if we had the building blocks for a generalised service marketplace, RAILGUN could benefit from the mechanisms for service discovery, payment, etc. for their own service.

One important difference between Waku Store and Codex is where the value lies - in Codex there is value to the data owner in storing data for a certain time. The model of data ownership (at this abstraction layer) in Waku is not simple - the closest we have is that Store infrastructure nodes themselves have an interest in storing data (for multiple clients/applications) in the long term. In general for Waku Store then, the value lies in accessing/querying the data (with the paying client not really caring how the data is stored). I would see Store nodes as being Codex “clients” behind the scenes, with the Store service remaining the main incentivised service to provide distributed client access (i.e. paying for queries).

3

Yes, indeed. The blog post and forum post already had a lot of content. So I did not address the “generalised Waku service marketplace”.

I think it’s post for another day. But for the readers:

Once we have designed, built, and deployed incentivization mechanisms for Waku services (store, light push, bootstrap, etc) and all the component it needs (capability discovery, negotiation, payment, reputation), then it should be possible to re-use those components as an off-the-shelf framework to incentivizes other offchain services.

The “offchain” is important, because if the service is onchain, then most likely component such as “reputation” or even “discovery” may not be needed.

The assumption is that we can generalize this framework to enable a plethora of off-chain services to be provided and paid for in a decentralized manner.

Think VPNs, WebRTC servers, etc. The hard part being the fact that such services are offchain, and hence there are needs for reputation, etc.

Will expand on this another day :slight_smile:

4

Great post, @fryorcraken!
To be honest, I would not invest effort in incentivizing cases such as Railgun.
If a project wants to run its own infrastructure, that’s far from the Web3 we want to build.
Therefore, I’d try to invite Railgun to use The Waku Network instead, a.k.a. TWN.

I’m envisioning Waku’s future as:

  • A W3aaS (Web3-as-a-Service) solution
  • A family of SDKs to easily interact with such W3aaS

For that, we will need to leverage RLN and other ZK components.

For example, as a developer, I want to establish communication in a simple way:

  • Adding a simple HTML tag to my page
  • Having a straightforward SDK that I can integrate into my preferred language

Also, as a developer, I greatly appreciate the abstraction provided by Waku’s W3aaS solution, and I’m happy to register myself within RLN and pay a monthly fee based on the tier I choose (assuming we support different tiers).

Similarly, as a developer/team, I may have spare infrastructure, an unused Raspberry Pi (or Railgun infrastructure, for example), and I’d like to profit from it.
Therefore, I run my Waku node(s) there, registering my appliance as a contributor to TWN.

We can offer better incentives for running a node on a private appliance and fewer incentives for running it on AWS, GCP, or Azure. Additionally, the new ZK components can generate proof-of-service, verifying that the node has been actively participating in the network.

This, in some way, responds to @haelius 's question: <<how an app like RAILGUN will be incentivised to contribute their infra to the general network?>>.

5

I think it’s important to note that some projects may have good reason to stay on their own network. It is unrealistic to think that one set of RLN parameters can fit all use cases.

In the case of RAILGUN, it may make more sense for them to do have plugin based message validation where being in the RAILGUN smart contract is used to validate messages at the routing layer.

We should not discard incentivization because an application use their own network.