Background
The current core Waku protocols can roughly be divided into two groups:
- Routing/discovery: RLN and Waku Relay, which are generally considered a unified protocol known as RLN Relay, are focused on privacy-preserving message propagation within a peer-to-peer network with built-in spam protection. Since a network mesh must be established as prerequisite for Relay, the suite of Waku discovery protocols can be seen as a necessary part of this group.
- Service protocols: This is the set of protocols adding some value on top of the network to allow access to services generally considered useful within the decentralized communication domain. Currently, Waku service protocols are Store for message history and Lightpush/Filter for resource-restricted publishing/receiving. Peer-exchange allows for resource-restricted randomized peer discovery in the network. Service protocols may also be reliant on a discovery protocol for service discovery, but assumes the existence of an established Relay network as prerequisite for service provisioning.
What do we have?
All Waku services can be provided by individual node operators aimed at specific applications and statically configured (out of band) as the service provider by these applications.
Note that these operators may be incentivized out of band in contract with the service clients/application. It’s also a common model for applications to operate and configure their own service nodes for their own clients.
In addition, Waku and Status also provide service nodes as an altruistic service for third parties. These service nodes are publicly discoverable and available as a best-effort service to all applications, especially to help new adopters.
Where do we want to go?
We envision each Waku service protocol to become a general distributed capability in the network,
with any node operator in the network able to provide a Waku service publicly and permissionlessly.
These service providers should either actively advertise the set of services enabled
or participate in discovery such that service clients can find the services for their specific needs.
The qualitative difference with how services are currently provisioned, is that a service client should no longer need out-of-band trust and application-level configuration to “know” which specific operators/nodes provide a trusted service for its use case.
Instead, such a client could simply ask “the network” for services matching a specific description, using a variety of decentralized discovery techniques, and be returned with a set of suitable service providers matching its needs. The client application can then locally configure the trust, redundancy and reputation aspects to match its use case.
If this public service provisioning is coupled with service differentiation (such as different service pricing or global reputation for the service operators), this will facilitate creation of a decentralized service marketplace.
How are we building a decentralized service marketplace?
For such a decentralized service network to be practical, we need at least three high level capabilities in the network:
1. Decentralized service discovery
Discovering a Waku service provider for a very specific use case is like trying to find a needle in a haystack. The number of parameters/capabilities that node operators have to advertise may have a higher cardinality than current randomized decentralized discovery methods, such as discv5, can gracefully handle. The Waku Research team is investigating alternative approaches to service capability discovery that will allow for highly specialized service provisioning within a large p2p network. See this issue for detail on the work being done here. Some possible approaches include topic discovery in discv5, sub-DHTs and other methods of converging on suitable service nodes faster.
2. Distributed reputation mechanism
In order for service nodes to participate in a marketplace mechanism in a permissionless, trustless p2p environment, clients should be able to avoid nodes providing subpar service or behaving maliciously. This may require a global reputation mechanism to encourage better service provisioning and weed out bad actors.
3. Incentivization
While there is a clear incentivization vector for nodes commissioned out-of-band to provide specific services for specific applications, a general marketplace requires incentivization. Any node operator should be able to run a service node and be rewarded for doing so. For service incentivization to be practical, in the narrowest sense at least two elements are required, namely:
a) a mechanism to advertise/negotiate service prices
b) a (privacy-preserving) mechanism for trustless payments
In a wider sense, incentivization should also be integrated with decentralized discovery (see (1) above) and a distributed reputation mechanism (see (2) above) to function as a coherent marketplace: service clients should be able to discover a variety of service providers, compare pricing and reputation and select the nodes with the best price/reputation combination for the specific use case. Service nodes in turn should be incentivized by the market mechanism to provide quality services and refrain from malicious behavior (which would lower their reputation scores and therefore the price they can charge for their services).
Store Incentivization as starting point
The Waku Research team is currently building all three these elements for the use case of Store Protocol incentivization. A far more detailed breakdown of the incentivization problem for Store appears in this post. We consider Store a good starting point, as we have the clearest understanding of its use cases (thanks to close collaboration with Status and other flagship projects) and the cost of service provisioning (mainly storage costs) is already well-studied. A POC implementation is already well underway. Once we have a workable mechanism for service discovery, reputation and incentivization within Store, these elements will be generalized for other Waku service protocols, such as Lightpush and Filter.
Future work
1. Tokenomics Strategy and Sustainability
The service marketplace presents an opportunity to accrue value to the Waku ecosystem. However, how this can be captured in a Tokenomic strategy that ensure the future sustainability of Waku is yet to be defined.
2. Generalization of the Service Marketplace
The mechanisms and infrastructure described above are developed with Waku service protocols in mind. However, this can serve as a blueprint to enable any distributed or Web3 service to seamlessly integrate into the Waku network and offer generalized services to users. This would make the Waku network a universal platform for a wide range of decentralized services.
