We can think of incentivization tools as a two-by-two matrix:
- rewards vs punishment;
- monetary vs reputation.
In other words, there are four quadrants:
- monetary reward: the client pays the server;
- monetary punishment: the server makes a deposit in advance and gets slashed in case of misbehavior;
- reputation reward: the server's reputation increases if it behaves well;
- reputation punishment: the server's reputation decreases if it behaves badly.
Reputation can only work if there are tangible benefits of having a high reputation and drawbacks of having a low reputation.
For example:
- clients are more likely to connect to servers with high reputation;
- clients disconnect from servers with low reputation.
In the presence of monetary rewards, low-reputation servers miss out on potential revenue or lose their deposit.
Without the monetary aspects, low-reputation nodes can't get as much benefit from the network.
Reputation either assumes a repeated interaction (i.e., local reputation), or some amount of trust (centrally managed rankings).
Ideally, monetary motivation should be atomically linked with performance.
A node should be rewarded if and only if it performed the desired action.
Analogously, it should be punished if and only it it misbehaved.
In other words, if the client pays first, the server cannot deny service,
and if the client pays after the fact, it's impossible to default on the obligation.
In blockchain networks, the desired behavior of miners or validators can be automatically verified and rewarded with native tokens (or punished by slashing).
Enforcing atomicity in decentralized data-focused networks can be challenging:
it is non-trivial to prove that a certain piece of data was sent or received.
Therefore, such cases may warrant a combination of monetary and reputation-based approaches.
# Related work
There have been many example of incentivized decentralized systems.
Early P2P file-sharing networks employed reputation-based approaches and stickly defaults.
For instance, in BitTorrent, a peer by default shares pieces of a file before having received it in whole.
At the same time, the bandwidth that a peer can use depends on how much is has shared previously.
This policy rewards nodes who share by allowing them to download file faster.
While this reward is not monetary, it has proven to be sufficient in practice.
## Blockchains
The key innovation of Bitcoin, inherited and built upon by later blockchain networks, is the introduction of native monetary i13 mechanism.
In the case of Bitcoin, miners create new blocks and are automatically rewarded with newly mined coins, as prescribed by the protocol.
An invalid block will be rejected by other nodes and not rewarded, which incentivizes good behavior.
There are no intrinsic monetary punishments in Bitcoin, only rewards.
However, mining nodes are required to expend physical resources for block generation.
Proof-of-stake consensus algorithms introduced intrinsic monetary punishments in the blockchain context.
A validator locks up (stakes) native tokens and gets rewarded for validating new blocks.
In case of misbehavior, the deposit is automatically taken away (i.e., the bad actor is slashed).
## Decentralized storage
Multiple decentralized storage networks have appeared in recent years, including Codex, Storj, Sia, Filecoin, IPFS.
They combine the techniques from early P2P file-sharing and blockchain-inspired reward mechanisms.
# Waku
Waku is a family of protocols (see [architecture](https://waku.org/about/architect)) for a modular decentralized censorship-resistant P2P communications network.
The backbone of Waku is the Relay protocol ([RLN-Relay](https://rfc.vac.dev/spec/17/) is an spam-protected version of the protocol).
Additionally, there are three light (client-server, request-response) protocols: Filter, Store, and Lightpush.
There is no strict definition of a full node vs a light node in Waku (see https://github.com/waku-org/research/issues/28).
In this document, we may refer to a node that is running Relay and Store (server-side) as a full node, and to a node that is running a client-side of any of the light protocols as a light node.
As Waku doesn't intent to establish consensus over past messages,
we can only rely on heuristics to determine whether a message had been relayed earlier.
To decrease the chance of missing some messages, a client may query multiple servers and combine their replies (union of all messages; messages reported by some majority of servers, etc).
- server (after internal calculations): here is the price
- client: pays (if price is ok; otherwise conversation ends)
- server: responds with data
- client: checks the data: if data is irrelevant - decreases server's reputation
- client (optionally): queries another server; compares responses; maybe decreases reputation of both (?) if responses diverge. Or queries 3 servers and assumes that messages returned by 2/3 or 3/3 are "real" ("Never Take Two Chronometers to Sea").
Note also that there may be different market models.
One model is that each client pays for its requests.
Another model assumes that (centralized) applications built on top of Waku buy "credits" in bulk for their users, for whom using the application (which may involve querying Store servers under the hood) is free of charge.
In file storage, I store a file and I pay for the ability to query it later. In Store, Alice relays a message, a server stores is, and later Bob queries it (and pays for it under an i13n scheme). Is there a mismatch between who incurs costs and who pays for it? Shall we think of ways to make Alice incur some costs too? See: https://github.com/waku-org/research/issues/32