<titledata-rh="true">Incentivisation | Waku Documentation</title><metadata-rh="true"name="viewport"content="width=device-width,initial-scale=1"><metadata-rh="true"name="twitter:card"content="summary_large_image"><metadata-rh="true"property="og:url"content="https://docs.waku.org/learn/research/research-and-studies/incentivisation"><metadata-rh="true"property="og:locale"content="en_GB"><metadata-rh="true"name="docusaurus_locale"content="en-GB"><metadata-rh="true"name="docsearch:language"content="en-GB"><metadata-rh="true"name="keywords"content="waku, web3"><metadata-rh="true"name="image"content="https://docs.waku.org/_og/e8dc43d175dbb46dde7724d6bfa818e925eb2073.png"><metadata-rh="true"name="docusaurus_version"content="current"><metadata-rh="true"name="docusaurus_tag"content="docs-default-current"><metadata-rh="true"name="docsearch:version"content="current"><metadata-rh="true"name="docsearch:docusaurus_tag"content="docs-default-current"><metadata-rh="true"property="og:title"content="Incentivisation | Waku Documentation"><metadata-rh="true"name="description"content="Waku is a family of decentralised communication protocols. The Waku Network (TWN) consists of independent nodes running Waku protocols. TWN needs incentivisation (shortened to i13n) to ensure proper node behaviour."><metadata-rh="true"property="og:description"content="Waku is a family of decentralised communication protocols. The Waku Network (TWN) consists of independent nodes running Waku protocols. TWN needs incentivisation (shortened to i13n) to ensure proper node behaviour."><linkdata-rh="true"rel="icon"href="/theme/image/favicon.ico"><linkdata-rh="true"rel="canonical"href="https://docs.waku.org/learn/research/research-and-studies/incentivisation"><linkdata-rh="true"rel="alternate"href="https://docs.waku.org/learn/research/research-and-studies/incentivisation"hreflang="en-GB"><linkdata-rh="true"rel="alternate"href="https://docs.waku.org/learn/research/research-and-studies/incentivisation"hreflang="x-default"><linkrel="alternate icon"type="image/png"href="/theme/image/favicon.png">
<p>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 querying historical messages. We introduce a minimal viable addition to Store to enable i13n, and list research directions for future work.</p>
<h2class="anchor anchorWithHideOnScrollNavbar_WYt5"id="incentivisation-tools">Incentivisation tools<ahref="#incentivisation-tools"class="hash-link"aria-label="Direct link to Incentivisation tools"title="Direct link to Incentivisation tools"></a></h2>
<p>We can think of incentivisation tools as a two-by-two matrix:</p>
<ul>
<li>rewards vs punishment;</li>
<li>monetary vs reputation.</li>
</ul>
<p>In other words, there are four quadrants:</p>
<ul>
<li>monetary reward: the node gets rewarded;</li>
<li>monetary punishment: the nodes deposits funds that are taken away (slashed) if it misbehaves;</li>
<li>reputation reward: the node's reputation increases if it behaves well;</li>
<li>reputation punishment: the node's reputation decreases if it behaves badly.</li>
</ul>
<p>Reputation only works if high reputation brings tangible benefits. For example, if nodes chose neighbors based on reputation, low-reputation nodes 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 form involves a trusted third party, although decentralised approaches are also possible.</p>
<h2class="anchor anchorWithHideOnScrollNavbar_WYt5"id="prior-work">Prior work<ahref="#prior-work"class="hash-link"aria-label="Direct link to Prior work"title="Direct link to Prior work"></a></h2>
<p>We may split incentivized decentralised networks into early file-sharing, blockchains, and decentralised storage.</p>
<h3class="anchor anchorWithHideOnScrollNavbar_WYt5"id="early-p2p-file-sharing">Early P2P file-sharing<ahref="#early-p2p-file-sharing"class="hash-link"aria-label="Direct link to Early P2P file-sharing"title="Direct link to Early P2P file-sharing"></a></h3>
<p>Early P2P file-sharing networks employ reputation-based approaches and sticky defaults. For instance, the BitTorrent protocol rewards uploading peers with faster downloads. The download bandwidth available to a peer depends on how much it has uploaded. Moreover, peers share pieces of a file before having received it in whole. This non-monetary i13n policy has been proved to work in practice.</p>
<h3class="anchor anchorWithHideOnScrollNavbar_WYt5"id="blockchains">Blockchains<ahref="#blockchains"class="hash-link"aria-label="Direct link to Blockchains"title="Direct link to Blockchains"></a></h3>
<p>Bitcoin has introduced proof-of-work (PoW) for native monetary rewards in a P2P network. PoW miners are automatically assigned newly mined coins for generating blocks. Miners must expend physical resources to generate a block. If the block is invalid, these expenses are not compensated (implicit monetary punishment). Proof-of-stake (PoS), used in Ethereum and many other cryptocurrencies, introduces explicit monetary punishments. PoS validators lock up (stake) native tokens and get rewarded for validating blocks or slashed for misbehaviour.</p>
<h3class="anchor anchorWithHideOnScrollNavbar_WYt5"id="decentralised-storage">Decentralised storage<ahref="#decentralised-storage"class="hash-link"aria-label="Direct link to Decentralised storage"title="Direct link to Decentralised storage"></a></h3>
<p>Post-Bitcoin decentralised storage networks include Codex, Storj, Sia, Filecoin, IPFS. Their i13n methods combine techniques from early P2P file-sharing with blockchain-inspired reward mechanisms.</p>
<p>Waku is a <ahref="https://waku.org/about/architect"target="_blank"rel="noopener noreferrer">family of protocols</a> for a modular privacy-preserving censorship-resistant decentralised communication network. The backbone of Waku is the Relay protocol (and its spam-protected version <ahref="https://rfc.vac.dev/spec/17/"target="_blank"rel="noopener noreferrer">RLN-Relay</a>). Additionally, there are light protocols: Store, Filter, and Lightpush. Light protocols are also referred to as client-server protocols and request-response protocols.</p>
<p>A server is a node running Relay and a server-side of at least one light protocol. A client is a node running a client-side of any of the light protocols. 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 <ahref="https://github.com/waku-org/research/issues/28"target="_blank"rel="noopener noreferrer">discussion</a>).</p>
<p>In light protocols, a client sends a request to a server, and a server performs some actions and returns a response:</p>
<ul>
<li><ahref="https://rfc.vac.dev/spec/13/"target="_blank"rel="noopener noreferrer">Store</a>: the server responds with messages relayed that match a set of criteria;</li>
<li><ahref="https://rfc.vac.dev/spec/12/"target="_blank"rel="noopener noreferrer">Filter</a>: the server will relay (only) messages that pass a filter to the client;</li>
<li><ahref="https://rfc.vac.dev/spec/19/"target="_blank"rel="noopener noreferrer">Lightpush</a>: the server publishes the client's message to the Relay network.</li>
</ul>
<h2class="anchor anchorWithHideOnScrollNavbar_WYt5"id="waku-i13n-challenges">Waku i13n challenges<ahref="#waku-i13n-challenges"class="hash-link"aria-label="Direct link to Waku i13n challenges"title="Direct link to Waku i13n challenges"></a></h2>
<p>Waku has no consensus and no native token, which brings it closer to reputation-incentivised file-sharing networks. As of late 2023, Waku only operates under reputation-based rewards and punishments. While <ahref="https://rfc.vac.dev/spec/17/"target="_blank"rel="noopener noreferrer">RLN-Relay</a> adds monetary punishments for spammers, slashing is yet to be activated.</p>
<p>Monetary rewards and punishments should ideally be atomically linked with the node's behaviour. A benefit of blockchains in this respect is that the desired behaviour of miners or validators can be verified automatically. Enforcing atomicity in a communication network is more challenging: it is non-trivial to prove that a given piece of data has been relayed.</p>
<p>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.</p>
<h2class="anchor anchorWithHideOnScrollNavbar_WYt5"id="waku-store">Waku Store<ahref="#waku-store"class="hash-link"aria-label="Direct link to Waku Store"title="Direct link to Waku Store"></a></h2>
<p>Waku Store is a light protocol for querying historic messages that works as follows:</p>
<ol>
<li>the client sends a <code>HistoryQuery</code> to the server;</li>
<li>the server sends a <code>HistoryResponse</code> to the client.</li>
</ol>
<p>The response may be split into multiple parts, as specified by pagination parameters in <code>PagingInfo</code>.</p>
<p>We define a <em>relevant</em> message as a message that matches client-defined criteria (e.g., relayed within a given time frame). Upon receiving a request, a server should quickly send back a response containing all and only relevant messages.</p>
<p>An incentivised Store protocol has the following extra steps:</p>
<ol>
<li>pricing:
<ol>
<li>cost calculation</li>
<li>price advertisement</li>
<li>price negotiation</li>
</ol>
</li>
<li>payment:
<ol>
<li>payment itself</li>
<li>proof of payment</li>
</ol>
</li>
<li>reputation</li>
<li>results cross-checking</li>
</ol>
<p>In this document, we focus on the simplest proof-of-concept (PoC) i13n for Store. Compared to the fully-fledged protocol, the PoC version is simplified in the following ways:</p>
<ul>
<li>cost calculation is based on a common-knowledge price;</li>
<li>there is no price advertisement and no price negotiation;</li>
<li>each query is paid for in a separate transaction, <code>txid</code> acts a proof of payment;</li>
<li>the reputation system is simplified (see below);</li>
<li>the results are not cross-checked.</li>
</ul>
<p>In the PoC protocol:</p>
<ol>
<li>the client calculates the price based on the known rate per hour of history;</li>
<li>the client pays the appropriate amount to the server's address;</li>
<li>the client sends a <code>HistoryQuery</code> to the server alongside the proof of payment (<code>txid</code>);</li>
<li>the server checks that the <code>txid</code> corresponds to a confirmed transaction with at least the required amount;</li>
<li>the server sends a <code>HistoryResponse</code> to the client.</li>
</ol>
<p>In further subsections, we list the potential direction for future work towards a fully-fledged i13n mechanism.</p>
<h2class="anchor anchorWithHideOnScrollNavbar_WYt5"id="pricing">Pricing<ahref="#pricing"class="hash-link"aria-label="Direct link to Pricing"title="Direct link to Pricing"></a></h2>
<p>For PoC, we assume a constant price per hour of history. This price and the blockchain address of the server are assumed to be common knowledge. This simplifies the client-server interaction, avoiding the price negotiation step.</p>
<p>In the future versions of the protocol, the price will be negotiated and will depend on multiple parameters, such as the total size of the relevant messages in the response.</p>
<h3class="anchor anchorWithHideOnScrollNavbar_WYt5"id="future-work">Future work<ahref="#future-work"class="hash-link"aria-label="Direct link to Future work"title="Direct link to Future work"></a></h3>
<ul>
<li>DoS protection - see <ahref="https://github.com/waku-org/research/issues/66"target="_blank"rel="noopener noreferrer">https://github.com/waku-org/research/issues/66</a></li>
<li>Cost calculation - see <ahref="https://github.com/waku-org/research/issues/35"target="_blank"rel="noopener noreferrer">https://github.com/waku-org/research/issues/35</a></li>
<li>Price advertisement - see <ahref="https://github.com/waku-org/research/issues/51"target="_blank"rel="noopener noreferrer">https://github.com/waku-org/research/issues/51</a></li>
<li>Price negotiation - see <ahref="https://github.com/waku-org/research/issues/52"target="_blank"rel="noopener noreferrer">https://github.com/waku-org/research/issues/52</a></li>
</ul>
<h2class="anchor anchorWithHideOnScrollNavbar_WYt5"id="payment">Payment<ahref="#payment"class="hash-link"aria-label="Direct link to Payment"title="Direct link to Payment"></a></h2>
<p>For the PoC, each request is paid for with a separate transaction. The transaction hash (<code>txid</code>) acts as a proof of payment. The server verifies the payment by ensuring that:</p>
<ol>
<li>the transaction has been confirmed;</li>
<li>the transaction is paying the proper amount to the server's account;</li>
<li>the <code>txid</code> does not correspond to any prior response.</li>
</ol>
<p>The client gives proof of payment before it receives the response. Other options could be:</p>
<ol>
<li>the client pays after the fact;</li>
<li>the client pays partly upfront and partly after the fact;</li>
<li>a centralised third party (either trusted or semi-trusted, like a smart contract) ensures atomicity;</li>
<li>cryptographically ensured atomicity (similar to atomic swaps, Lightning, or Hopr).</li>
</ol>
<p>Our design considerations are:</p>
<ul>
<li>the PoC protocol should be simple;</li>
<li>servers are more "permanent" entities and are more likely to have long-lived identities;</li>
<li>it is more important to protect the clients's privacy than the server's privacy.</li>
</ul>
<p>In light of these criteria, we suggest that the client pays first. This is simpler than splitting the payment, or involving an extra atomicity-enforcing mechanism. Moreover, pre-payment is arguably more privacy-preserving than post-payment, which encourages servers to deanonymise clients to prevent fraud.</p>
<h3class="anchor anchorWithHideOnScrollNavbar_WYt5"id="future-work-1">Future work<ahref="#future-work-1"class="hash-link"aria-label="Direct link to Future work"title="Direct link to Future work"></a></h3>
<ul>
<li>Add more payment methods - see <ahref="https://github.com/waku-org/research/issues/58"target="_blank"rel="noopener noreferrer">https://github.com/waku-org/research/issues/58</a></li>
<li>Design a subscription model with service credentials - see <ahref="https://github.com/waku-org/research/issues/59"target="_blank"rel="noopener noreferrer">https://github.com/waku-org/research/issues/59</a></li>
<li>Add privacy to service credentials - see <ahref="https://github.com/waku-org/research/issues/60"target="_blank"rel="noopener noreferrer">https://github.com/waku-org/research/issues/60</a></li>
<li>Consider the impact of network disruptions - see <ahref="https://github.com/waku-org/research/issues/65"target="_blank"rel="noopener noreferrer">https://github.com/waku-org/research/issues/65</a></li>
</ul>
<h2class="anchor anchorWithHideOnScrollNavbar_WYt5"id="reputation">Reputation<ahref="#reputation"class="hash-link"aria-label="Direct link to Reputation"title="Direct link to Reputation"></a></h2>
<p>We use reputation to discourage the server from taking the payment and not responding. The client keeps track of the server's reputation:</p>
<ul>
<li>all servers start with zero reputation points;</li>
<li>if the server honours the request, it gets <code>+n</code> points;</li>
<li>if the server does not respond before a timeout, it gets <code>-m</code> points.</li>
<li>if the server's reputation drops below <code>k</code> points, the client will never query it again.</li>
</ul>
<p><code>n</code>, <code>m</code>, and <code>k</code> are subject to configuration.</p>
<p>Optionally, a client may treat a given server as trusted, assigning it a constant positive reputation.</p>
<p>Potential issues:</p>
<ul>
<li>An attacker can establish new server identities and continue running away with clients' money. Countermeasures:
<ul>
<li>a client only queries trusted servers (which however leads to centralisation);</li>
<li>when querying a new server, a client first sends a small (i.e. cheap) request as a test;</li>
<li>more generally, the client selects a server on a case-by-case basis, weighing the payment amount against the server's reputation.</li>
</ul>
</li>
<li>The ban mechanism can theoretically be abused. For instance, a competitor may attack the victim server and cause the clients who were awaiting the response to ban that server. Countermeasure: prevent DoS-attacks.</li>
</ul>
<h3class="anchor anchorWithHideOnScrollNavbar_WYt5"id="future-work-2">Future work<ahref="#future-work-2"class="hash-link"aria-label="Direct link to Future work"title="Direct link to Future work"></a></h3>
<p>Design a more comprehensive reputation system:</p>
<ul>
<li>local reputation - see <ahref="https://github.com/waku-org/research/issues/48"target="_blank"rel="noopener noreferrer">https://github.com/waku-org/research/issues/48</a></li>
<li>global reputation - see <ahref="https://github.com/waku-org/research/issues/49"target="_blank"rel="noopener noreferrer">https://github.com/waku-org/research/issues/49</a></li>
</ul>
<h2class="anchor anchorWithHideOnScrollNavbar_WYt5"id="results-cross-checking">Results cross-checking<ahref="#results-cross-checking"class="hash-link"aria-label="Direct link to Results cross-checking"title="Direct link to Results cross-checking"></a></h2>
<p>As there is no consensus over past messages, a client may want to query multiple servers and merge their responses. Cross-checking helps ensure that servers are a) not censoring real messages; b) not injecting fake messages into history. Cross-checking is absent in PoC but may be considered later.</p>
<h3class="anchor anchorWithHideOnScrollNavbar_WYt5"id="future-work-3">Future work<ahref="#future-work-3"class="hash-link"aria-label="Direct link to Future work"title="Direct link to Future work"></a></h3>
<ul>
<li>Cross-checking the results against censorship - see <ahref="https://github.com/waku-org/research/issues/57"target="_blank"rel="noopener noreferrer">https://github.com/waku-org/research/issues/57</a></li>
<li>Use RLN to limit fake message insertion - see <ahref="https://github.com/waku-org/research/issues/38"target="_blank"rel="noopener noreferrer">https://github.com/waku-org/research/issues/38</a></li>
<p>We should think about what the success metrics for an incentivised protocol are, and how to measure them both in simulated settings, as well as in a live network.</p>
<li>Analyze privacy issues - see <ahref="https://github.com/waku-org/research/issues/61"target="_blank"rel="noopener noreferrer">https://github.com/waku-org/research/issues/61</a></li>
<li>Analyze decentralised storage protocols and their relevance e.g. as back-end storage for Store servers - see <ahref="https://github.com/waku-org/research/issues/34"target="_blank"rel="noopener noreferrer">https://github.com/waku-org/research/issues/34</a></li>
<li>Analyze the role of message senders, in particular, whether they should pay for sending non-ephemeral messages - see <ahref="https://github.com/waku-org/research/issues/32"target="_blank"rel="noopener noreferrer">https://github.com/waku-org/research/issues/32</a></li>
<li>Generalise incentivisation protocol to other Waku light protocols (Lightpush and Filter) - see <ahref="https://github.com/waku-org/research/issues/67"target="_blank"rel="noopener noreferrer">https://github.com/waku-org/research/issues/67</a>.</li>
