Waku Service Marketplace: Decentralized Infrastructure for dApps

Take it away. Thank you. Hi, everyone. Okay. My name is Sergey.

I'm a protocol research engineer at WACU. And the goal of this talk is to, first of all, make you familiar with what we do at WACU and what WACU is, and second, present quite a novel idea that we've been thinking about and invite your feedback and questions. So, WACU is a family of open-source, modular, peer-to-peer communication protocols. The goal of WACU is to establish a peer-to-peer communication layer that essential applications or just applications in general can use for their communication needs. It is currently used by projects like Status, which is the messenger, which started this whole thing.

We grew out of Status. Also, Railgun, The Graph, and other projects. We aim to be permissionless, decentralized, privacy-preserving, and censorship-resistant. So, the architecture of the network consists of the backbone network, which runs the relay or RLN relay protocol. I will talk a bit about RLN later on.

This is a peer-to-peer protocol where all nodes have the same properties, the same role. And also, additionally, we have a few light protocols that can be used for resource-constrained devices to make use of the network without being fully-fledged participants. RLN, in the previous slide, stands for rate-limiting nullifiers. This is a technique that we use to protect the network against spam attacks or denial-of-service attacks. Of course, if we have a permissionless network that anyone can join, then spam becomes a problem.

And we don't want to compromise the user's privacy or introduce any kind of identification to fight that. So, instead of that, we use a zero-knowledge-based technique where users register with a smart contract. And then, with every message that you want to send, you attach a proof that proves that you own a currency-valid membership in a membership set without revealing which membership you own, so without revealing your identity. As for the light protocols, here are three of them, which are used by what we call the edge nodes that may request certain services from service nodes. With a filter protocol, an edge node can subscribe to just a subset of messages that are being propagated.

With a light-push protocol, an edge node may publish a message to the network without being a pull-relay node again. And with a store protocol, an edge node can query historic messages. So, this is a simple diagram where Charlie is an edge node. Alice and Bob are relay nodes. And Charlie can request some service, like some store service from Alice.

And Charlie can request, independently, the light-push service from Bob. And, in yellow, the VACU network is shown, which, of course, contains other nodes apart from Alice and Bob, not shown here for simplicity. Now, the question that I want to address in this talk is, who actually runs these service nodes? So, imagine there is some application, say, on a mobile device or on some other resource-constrained device, and it wants to use some services. Of course, in the ideal world, we want it to be fully decentralized and dependent, which I'll talk about later in a bit.

But, in practice, what actually happens is that we have an app developer, or a DAB developer for that matter, that runs the service nodes for their user. So, the user, by default, queries a particular service node that is controlled by the developer of the corresponding application, which we think is not very decentralized. So, of course, there are certain drawbacks to this design. It introduces a single point of failure. It introduces operational costs on the developer's part.

So, if you're developing an application, say, a messenger, for example, not only you need to think about UX and application-level logic, but also you need to be capable of running and maintaining your service nodes and connect your users to these service nodes. And, of course, we have censorship and privacy risks involved in the centralized element of app infrastructure. So, it's not truly decentralized, and we've been thinking about decentralizing service provision. How can we make this architecture fully decentralized? And our answer to this question, which is a very early stage idea, is the VACU service marketplace.

So, what is it, actually? In the vision that we have for the marketplace, there's going to be independent service providers that are going to provide services to the user through the marketplace. So, instead of asking one particular service node for some services, the user would connect to the service marketplace and then select, in some way, an appropriate provider, and the provider provides the service to the user. We envisioned two models of how a user, a developer of the application, and the marketplace provider would communicate. So, in the subsidized model, the app developer can pay for the users to use service nodes.

This is basically a free tier experience, and this would look like this. And a developer issues some amount of free credits or free credentials to the users, and the users can redeem these credentials with service providers of their choice. In this architecture, users get nice user experience, but they don't sacrifice their privacy because the app developer cannot relate their requests and their credentials when they're being used with a particular user identity. And on top of that, we think of a sovereign model where users would completely independently choose their favorite service provider and pay them directly through the marketplace, which, of course, provides greater control over privacy of the users. This is somewhat analogous to users paying blockchain fees for transaction processing.

So, from the perspective of the app developer, we think that the benefit is the, what we call, no-devops model. So, you don't have to care or know much about how to run a node. The marketplace takes care of that for you. It's flexible in the sense that users can choose a service provider if they wish. It provides a competitive environment where providers are incentivized by the free market forces to lower their prices and increase their quality of service.

And, of course, it's more resilient because if one provider starts to censor you or misbehave, then you can choose another one. There are a few research directions. There are many open questions here. And, basically, I invite you all, if you're interested, to think about this and talk with me, talk to my colleagues about this new research project. We have a few directions here.

So, first, discovery. If we have a diversified marketplace where lots of different services are provided, not necessarily limited to the three services that I mentioned, how do we find this needle in the haystack? How do I find a node that provides a service that's interesting for me? How would I negotiate the price of the service? So, we need to think about a mechanism for nodes to advertise what prices they want to charge and negotiate them with users, potentially.

The payment mechanism is also important. Perhaps paying on-chain for each interaction would be not feasible due to fees and delays. Again, we can think about some kind of off-chain payment mechanism or prepayment for multiple requests at a time. And, finally, reputation. We need to think about some kind of reputation system where a user maintains some history of interactions and, at least for the personal use in the future, remembers which service nodes behaved badly or which service nodes behaved good and provided good service.

Ideally, we would like this reputation system to be shared among users. But, again, how can we do this in a privacy-preserving manner? That's an open question for discussion. So, the long-term vision for this idea is a generalized service marketplace, which is not limited to services specific for the VACU network. And if we develop a sustainable and well-designed architecture for such marketplace, it can well be used for other similar services where edge nodes or resource-constrained devices ask for some services from independent providers.

Think AI inference, a very trendy topic, I must say. You can, I don't know, find some model deployed on some server and the server replies with a response to your request using the AI model. But, of course, not limited to that. So, finally, I invite you all, if you are interested, to join the discussion around this idea. The QR code here links to the blog post on the VACU blog that explains this idea in more detail.

And check out this blog post, check out our forums, and go to vacu.org to learn more about what we do and other research directions at VACU. Thank you.