Having a Waku Service Marketplace that is functional, means having solved the problem of provisioning off-chain services in a censorship-resistant (decentralized) manner.
The problem of Waku service incentivization is quite unique - in the blockchain ecosystem - because there is no on-chain trace of services being provided.
When providing services on-chain, it is possible to programmatically proceed to the payment based on whether the service is delivered. RAILGUN is great example of that: the broadcaster does not get paid if they don’t broadcast the user’s defi transaction onchain.
A seller does not get paid for an NFT, if the NFT is not being transferred to the buyer.
Sometimes, fraud might be possible at the service delivery, but optimistic models can allow for pushing after the service is delivered: think optimistic roll ups or Bitcoin lightning HTLC.
However, in the case of Waku, the services are not provided on chain, nor do they leave trace on chain:
- RLNaaS: user gives a message to provider, provider attaches RLN proof and broadcast
- Store: user asks for a specific message - or messages in a time range - provider send messages back
- Filter: user asks for any new messages on a given content topic - provider forward what it sees from Relay
In all those scenarios, the interactions are one-to-one from consumer to provider, and relate to data see on the Waku network. Waku is an offchain communication protocol. There is no global consensus on what messages are exchanged over Waku.
This means that to provide a service marketplace, specific problems need to be solved:
- Finding provider with specific capabilities (stores messages on a specific shard)
- Paying providers by minimizing both gas costs and potential loss
- Handing reputation to avoid
a. a user being fooled twice by the same provider
b. a provider fooling all users once.
fooling = running away with the money without providing a service.
We assume user pays before service is delivered, in the reverse scenario, same problem apply with provider being the victim this time.
A general problem
While being unique in the blockchain world, they are not unique to Waku services. They are actually very common in the Internet world. Most Internet services are not on-chain.
The Waku incentivization problem is actually quite general.
- Decentralized capability discovery: finding nodes in a peer-to-peer network that provide a specific service
- Payment: pay the provider
- Reputation and quality assessment: a way to “assess” that the quality of a service, and remember to better select future providers.
In the context of Waku, p2p reliability and e2e reliability are two mechanisms that can help assess the quality of service when pushing messages in the network.
Identifying similar services
A solution to Waku service incentivization, can be applied to problems with similar characteristics. So in short, again taking the same list to drive the point:
- Am I looking at a service provider among a decentralized group of nodes, where the characteristic of this provider may be varied, but bounded?
- Can I pay the provider via crypto? Is the cost of the service vs cost of gas economically acceptable?
- Can I evaluate the quality of the service provided by myself? If I am fooled, can still use the service in an economically viable manner?
Let’s take an example: WebRTC providers.
Imagine you are running an app that uses WebRTC for browser-to-browser connection.
You need to run STUN and TURN servers so that:
- Users behind an aggressive NAT can still exchange connections details (SDP, using STUN)
- Users behind the most agressive NAT can still connect to each other, with only one hop (TURN).
So, for a STUN/TURN scenario, could we re-use Waku incentivization technology?
- Yes, I am looking at a service provider among a decentralized group of nodes. Specific characteristics are: STUN support, TURN support, potentially specific bandwidth speed available or geographical location for low latency
- Let’s say yes, I need to be able to do small payment. could be streaming payment per SDP exchanged or MB transferred. A good business could provide free SDP to attract user who would then use their TURN, TURN being the most resource heavy service
- Can I evaluate the quality of the service? Probably yes: connection success/fail, actual bandwidth speed, potentially coordinate with other browser to share experience from both side.
Off-the-shelf solution
It seems that the Waku incentivization framework, once delivered, could be an off-the-shelf solution to bootstrap any kind of offchain service marketplace, as long as the 3 properties apply.
Note that those properties are stated at a high level, and only once we have developed the technology, we will be able to better define the properties needs by a service, to use the waku service marketplace framework.
Conclusion
This narrative is based on several assumptions. The key one being delivering Waku incentivization.
Once done, there is a potential for this tooling to be used beyond chat and communication applications. While the services may not use Waku themselves (but might), they could use the marketplace as a censorship-resistant way of finding customers.
However, due to the expected lack of guarantees in service quality, this will only be attractive for services where payments can be low, and service provider switching cheap.