finalize MVP-centric version with links to future work issues

incentivization.md

@@ -1,47 +1,36 @@
 Waku is a family of decentralized communication protocols.
-The Waku network consists of independent nodes running the corresponding protocols.
-Waku needs incentivization (i13n) to ensure proper node behavior in the absence of any centralized coordinator.
+The Waku Network (TWN) consists of independent nodes running Waku protocols.
+TWN needs incentivization (shortened to i13n) to ensure proper node behavior.
 
-In this document, we overview the problem of i13n in decentralized systems.
-We classify the possible methods of i13n and give example used in prior successful P2P networks.
-We then briefly introduce Waku and outline the unique i13n challenges it presents.
+The goal of this document is to outline and contextualize our approach to TWN i13n.
+After providing an overview of Waku and relevant prior work,
+we focus on Waku Store - a client-server protocol for quer
+We then introduce a minimal viable addition to Store to enable i13n, and list research directions for future work.
 
-We then go into more detail into one of the Waku's protocols, Store, responsible for archival storage.
-We propose an i13n scheme for Store and implement an MVP solution.
-We discuss the choices we have made for the MVP version, and what design options may be considered in the future.
-
-# Classification of i13n tools
+# Incentivization in decentralized networks
+## Incentivization tools
 
 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 and gets slashed if it misbehaves;
-- reputation reward: the server's reputation increases if it behaves well;
-- reputation punishment: the server's reputation decreases if it behaves badly.
+- monetary reward: the node gets rewarded;
+- monetary punishment: the nodes deposits funds that are taken away (slashed) if it misbehaves;
+- reputation reward: the node's reputation increases if it behaves well;
+- reputation punishment: the node's reputation decreases if it behaves badly.
 
-Reputation can only work if there are tangible benefits of having a high reputation.
-For example, clients should be more likely to connect to servers with high reputation and 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).
+Reputation only works if high reputation brings tangible benefits.
+For example, if nodes chose neighbors based on reputation, low-reputation nodes may miss out on potential revenue.
+Reputation scores may be local (a node assigns scores to its neighbors) or global (each node gets a uniform score).
+Global reputation in its simplest implementation involves a trusted third party,
+although decentralized approaches are also possible.
 
-Monetary motivation should ideally be atomically linked with performance.
-If the client pays first, the server cannot deny service,
-and if the client pays after the fact, it's impossible to default on this obligation.
+## Prior work
 
-In blockchains, 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 is 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.
+We may split incentivized decentralized networks into early file-sharing, blockchains, and decentralized storage.
 
-# Related work
-
-There have been many example of incentivized decentralized systems.
-
-## Early P2P file-sharing
+### Early P2P file-sharing
 
 Early P2P file-sharing networks employed reputation-based approaches and sticky defaults.
 For instance, in BitTorrent, a peer by default shares pieces of a file before having received it in whole.
@@ -49,46 +38,52 @@ At the same time, the bandwidth that a peer can use depends on how much is has s
 This policy rewards nodes who share by allowing them to download file faster.
 While this reward is not monetary, it has proven to be working in practice.
 
-## Blockchains
+### Blockchains
 
-The key innovation of Bitcoin, inherited and built upon by later blockchains, is native monetary i13.
-In Bitcoin, miners create new blocks and are automatically rewarded with newly mined coins.
-An invalid block is rejected by other nodes and not rewarded.
-There are no intrinsic monetary punishments in Bitcoin, only rewards.
-However, mining nodes are required to expend physical resources for block generation.
+Bitcoin has introduced native monetary i13n in a P2P network with proof-of-work (PoW).
+PoW miners are automatically rewarded with newly mined coins for generating blocks.
+There are no intrinsic monetary punishments in Bitcoin.
+However, miners must expend physical resources before claiming the reward.
+Proof-of-stake (PoS) algorithms introduce intrinsic monetary punishments.
+PoS validators lock up (stake) native tokens to get rewarded for validating blocks or slashed for misbehavior.
 
-Proof-of-stake algorithms introduce intrinsic monetary punishments in the blockchain context.
-A validator locks up (stakes) native tokens and gets rewarded for validating new blocks and slashed for misbehavior.
+### Decentralized storage
 
-## Decentralized storage
-
-Decentralized storage networks, including Codex, Storj, Sia, Filecoin, IPFS, combine the techniques from early P2P file-sharing and blockchain-inspired reward mechanisms to incentivize nodes to store data.
+Post-Bitcoin decentralized storage networks include Codex, Storj, Sia, Filecoin, IPFS.
+Their i13n methods combine techniques from early P2P file-sharing with blockchain-inspired reward mechanisms.
 
 # Waku background
 
 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 (and its spam-protected version [RLN-Relay](https://rfc.vac.dev/spec/17/)).
-Additionally, there are three light (or client-server, or request-response) protocols: Filter, Store, and Lightpush.
+Additionally, there are light protocols: Filter, Store, and Lightpush.
+Light protocols are also referred to as client-server protocols and request-response protocols.
 
+A server is a node running Relay and Store (server-side).
+A client is a node running a client-side of any of the light protocols as a light node or a client.
+A server may sometimes be referred to as a full node, and a client as a light node.
 There is no strict definition of a full node vs a light node in Waku (see [discussion](https://github.com/waku-org/research/issues/28)).
-In this document, we refer to a node that is running Relay and Store (server-side) as a full node or a server, and to a node that is running a client-side of any of the light protocols as a light node or a client.
 
-In light protocols, a client sends a request to a server.
-A server (a Relay node) performs some actions and returns a response, in particular:
+In light protocols, a client sends a request to a server, and a server performs some actions and returns a response:
 - [[Filter]]: the server will relay (only) messages that pass a filter to the client;
-- [[Store]]: the server responds with messages that had been broadcast within the specified time frame;
+- [[Store]]: the server responds with messages broadcast earlier within the specified time frame;
 - [[Lightpush]]: the server publishes the client's message to the Relay network.
 
 ## Waku i13n challenges
 
-As a communication protocol, Waku lacks consensus or a native token.
-These properties bring Waku closer to purely reputation-incentivized file-sharing systems.
-Our goal nevertheless is to combine monetary and reputation-based incentives.
-The rationale is that monetary incentives have demonstrated their robustness in blockchains,
-and are well-suited for a network designed to scale well beyond the initial phase when it's mainly maintained by enthusiasts for altruistic reasons.
-Currently, Waku only operates under reputation-based rewards and punishments.
+Waku lacks consensus or a native token, which brings it closer to reputation-incentivized file-sharing systems.
+Indeed, currently Waku only operates under reputation-based rewards and punishments.
 While [RLN-Relay](https://rfc.vac.dev/spec/17/) adds monetary punishments for spammers, slashing is yet to be activated.
 
+Monetary rewards and punishments should ideally be atomically linked with performance.
+A benefit of blockchains in this respect is that the desired behavior of miners or validators can be verified on-chain.
+Enforcing atomicity in decentralized data-focused networks is more challenging:
+it is non-trivial to prove that a certain piece of data was sent or received.
+
+Our goal is to combine monetary and reputation-based incentives for Waku.
+Monetary incentives have demonstrated their robustness in blockchains.
+We think they are necessary to scale the network beyond the initial phase when it's maintained altruistically.
+
 ## Waku Store
 
 In this document, we focus on i13n for Waku Store.
@@ -108,8 +103,6 @@ The desired functionality of Store can be described as following:
 
 # Waku Store incentivization MVP
 
-In this section, we aim to define the simplest viable i13n modification to the Store protocol.
-
 We propose to add the following aspects to the protocol:
 1. pricing:
 	1. cost calculation
@@ -121,8 +114,10 @@ We propose to add the following aspects to the protocol:
 3. reputation
 4. results cross-checking
 
-The MVP version of the protocol has no price advertisement, no price negotiation, and no results cross-checking.
+In this document, we define the simplest viable i13n modification to the Store protocol (MVP).
+The MVP protocol has no price advertisement, no price negotiation, and no results cross-checking.
 Other elements are present in a minimal version.
+In further subsections, we list the potential direction for future work towards a fully-fledged i13n protocol.
 
 ## Pricing
 
@@ -144,7 +139,7 @@ After the client sends a `HistoryQuery` to the server:
 ## Payment
 
 If the client agrees to the price, it sends a _proof of payment_ to the server.
-For the MVP, each request is paid for with a separate transaction.
+For the MVP, each request is paid for with a separate blockchain transaction.
 The transaction hash (`txid`) acts as a proof of payment.
 
 Note that client gives proof of payment before it receives the response.
@@ -194,7 +189,7 @@ While rate limiting stops such attack, the server would need to link requests co
 ## Results cross-checking
 
 Cross-checking is absent in MVP but should be considered later.
-We can separate it into two questions: the client want to ensure that servers are a) not censoring real messages; b) not injecting fake messages into history.
+We can separate it into two tasks for the client: ensure that servers are a) not censoring real messages; b) not injecting fake messages into history.
 
 - Cross-checking the results against censorship - see https://github.com/waku-org/research/issues/57
 - Use RLN to limit fake message insertion - see https://github.com/waku-org/research/issues/38