From a656e965adb9958d73e04091435e5050824b28f7 Mon Sep 17 00:00:00 2001 From: Sergei Tikhomirov Date: Mon, 20 Nov 2023 11:57:59 +0100 Subject: [PATCH] finalize MVP-centric version with links to future work issues --- incentivization.md | 111 ++++++++++++++++++++++----------------------- 1 file changed, 53 insertions(+), 58 deletions(-) diff --git a/incentivization.md b/incentivization.md index ac4b1c3..59bfe94 100644 --- a/incentivization.md +++ b/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