Protocol Berg v2: Sergei Tikhomirov - Waku Service Marketplace: Decentr. Infrastructure for dApps

take it away. Thank you. Uh, hi everyone. Okay. Um, my name is Sergey.

I'm a protocol research engineer at Vaku. And the goal of this talk is to first of all make you familiar with what we do at Vaku and what Vaku is. and second present quite a novel idea that we've been thinking about and invite your feedback and questions. So, Vako is a family of open-source modular peer-to-peer communication protocols. The goal of Vaku is to establish a peer-to-peer communication layer that decentralized 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 rail gun the graph and other projects. We aim to be permissionless, decentralized, privacy preserving and censorship resistant. So the um 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 are uh have the same basically the same properties, the same uh 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 fullyfledged participants. Uh 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 um own a currently valid membership in the membership set without revealing which membership you own.

So without revealing your identity. As for the light protocols, uh here are three of them which are used by what we call the edge nodes that may request certain services from service nodes. With the filter protocol, an edge node can subscribe to just a subset of messages that are being propagated. With light push protocol, an edge node may publish a message to the network without being a full relay node again. And with a store protocol, an an edge node can query historic messages.

So this is a simple diagram uh where Charlie is a 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 uh in yellow the VA 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 uh there is some application say on mobile device or on some other resource constrainted device and it wants to use some services. Um, of course in the ideal world we want it to be like fully decentralized independent um, 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 run 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. Uh it introduces a single point of failure. Uh it introduces operational costs on the developer part.

So if you're developing an application say a messenger for example uh not only you need to think about UX and application level logic but also you need to be um 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 Vaku 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 a service marketplace and then select in some way an appropriate provider and the provider provides the service to the user.

We envisioned two models uh 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. Um this is basically a free tier experience and this could 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 uh when they're being used with the particular user identity.

And on top of that, we uh 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. Um this is somewhat analogous to users paying blockchain fees for transaction processing. So from the um perspective of the app developer, uh 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. Uh 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 um 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 uh talk with me, talk to my colleagues about this new research project.

Uh 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. Uh how do we find this needle in the haststack? 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. Uh perhaps paying onchain for each interaction would be not feasible due to fees and delays. Um 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 um at least for the personal um use in the future remembers which service nodes behaved badly or which service nodes behave u 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 longerterm vision for this idea is a gen generalized service marketplace which is not limited to services specific for the vacuum network.

And if we develop um a sustainable and well-designed architecture for such a marketplace, it can well be used for other similar services where edge nodes or resource constraint devices ask for some services from independent providers. Think AI inference um a very trendy topic I must say uh you can I don't know find some model deployed on some server and the server replies with your with the response to your request using the AI model but of course not limited to that. So um finally I invite you all if you are interested to join the discussion around this idea. The QR code here uh links to the uh blog post on the Vaku blog that explains this idea in more detail and uh check out this blog post, check out our forums and go to vaku.org to learn more about what we do and other research directions at Vaku.

Thank you.