docs.waku.org/assets/js/4e726341.8be7f838.js

"use strict";(self.webpackChunkwaku_guide=self.webpackChunkwaku_guide||[]).push([[1733],{28453:(e,s,i)=>{i.d(s,{R:()=>o,x:()=>a});var n=i(96540);const r={},t=n.createContext(r);function o(e){const s=n.useContext(t);return n.useMemo(function(){return"function"==typeof e?e(s):{...s,...e}},[s,e])}function a(e){let s;return s=e.disableParentContext?"function"==typeof e.components?e.components(r):e.components||r:o(e.components),n.createElement(t.Provider,{value:s},e.children)}},77062:(e,s,i)=>{i.r(s),i.d(s,{assets:()=>c,contentTitle:()=>a,default:()=>d,frontMatter:()=>o,metadata:()=>n,toc:()=>l});const n=JSON.parse('{"id":"research/research-and-studies/incentivisation","title":"Incentivisation","description":"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.","source":"@site/docs/research/research-and-studies/incentivisation.md","sourceDirName":"research/research-and-studies","slug":"/research/research-and-studies/incentivisation","permalink":"/research/research-and-studies/incentivisation","draft":false,"unlisted":false,"editUrl":"https://github.com/waku-org/docs.waku.org/tree/develop/docs/research/research-and-studies/incentivisation.md","tags":[],"version":"current","lastUpdatedAt":null,"frontMatter":{"title":"Incentivisation"},"sidebar":"research","previous":{"title":"Capped Bandwidth in Waku","permalink":"/research/research-and-studies/capped-bandwidth"},"next":{"title":"Maximum Bandwidth for Global Adoption","permalink":"/research/research-and-studies/maximum-bandwidth"}}');var r=i(74848),t=i(28453);const o={title:"Incentivisation"},a="Incentivisation in decentralised networks",c={},l=[{value:"Incentivisation tools",id:"incentivisation-tools",level:2},{value:"Prior work",id:"prior-work",level:2},{value:"Early P2P file-sharing",id:"early-p2p-file-sharing",level:3},{value:"Blockchains",id:"blockchains",level:3},{value:"Decentralised storage",id:"decentralised-storage",level:3},{value:"Waku i13n challenges",id:"waku-i13n-challenges",level:2},{value:"Waku Store",id:"waku-store",level:2},{value:"Pricing",id:"pricing",level:2},{value:"Future work",id:"future-work",level:3},{value:"Payment",id:"payment",level:2},{value:"Future work",id:"future-work-1",level:3},{value:"Reputation",id:"reputation",level:2},{value:"Future work",id:"future-work-2",level:3},{value:"Results cross-checking",id:"results-cross-checking",level:2},{value:"Future work",id:"future-work-3",level:3}];function h(e){const s={a:"a",code:"code",em:"em",h1:"h1",h2:"h2",h3:"h3",header:"header",li:"li",ol:"ol",p:"p",ul:"ul",...(0,t.R)(),...e.components};return(0,r.jsxs)(r.Fragment,{children:[(0,r.jsx)(s.p,{children:"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."}),"\n",(0,r.jsx)(s.p,{children:"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."}),"\n",(0,r.jsx)(s.header,{children:(0,r.jsx)(s.h1,{id:"incentivisation-in-decentralised-networks",children:"Incentivisation in decentralised networks"})}),"\n",(0,r.jsx)(s.h2,{id:"incentivisation-tools",children:"Incentivisation tools"}),"\n",(0,r.jsx)(s.p,{children:"We can think of incentivisation tools as a two-by-two matrix:"}),"\n",(0,r.jsxs)(s.ul,{children:["\n",(0,r.jsx)(s.li,{children:"rewards vs punishment;"}),"\n",(0,r.jsx)(s.li,{children:"monetary vs reputation."}),"\n"]}),"\n",(0,r.jsx)(s.p,{children:"In other words, there are four quadrants:"}),"\n",(0,r.jsxs)(s.ul,{children:["\n",(0,r.jsx)(s.li,{children:"monetary reward: the node gets rewarded;"}),"\n",(0,r.jsx)(s.li,{children:"monetary punishment: the nodes deposits funds that are taken away (slashed) if it misbehaves;"}),"\n",(0,r.jsx)(s.li,{children:"reputation reward: the node's reputation increases if it behaves well;"}),"\n",(0,r.jsx)(s.li,{children:"reputation punishment: the node's reputation decreases if it behaves badly."}),"\n"]}),"\n",(0,r.jsx)(s.p,{children:"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."}),"\n",(0,r.jsx)(s.h2,{id:"prior-work",children:"Prior work"}),"\n",(0,r.jsx)(s.p,{children:"We may split incentivized decentralised networks into early file-sharing, blockchains, and decentralised storage."}),"\n",(0,r.jsx)(s.h3,{id:"early-p2p-file-sharing",children:"Early P2P file-sharing"}),"\n",(0,r.jsx)(s.p,{children:"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."}),"\n",(0,r.jsx)(s.h3,{id:"blockchains",children:"Blockchains"}),"\n",(0,r.jsx)(s.p,{children:"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."}),"\n",(0,r.jsx)(s.h3,{id:"decentralised-storage",children:"Decentralised storage"}),"\n",(0,r.jsx)(s.p,{children:"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."}),"\n",(0,r.jsx)(s.h1,{id:"waku-background",children:"Waku background"}),"\n",(0,r.jsxs)(s.p,{children:["Waku is a ",(0,r.jsx)(s.a,{href:"https://waku.org/about/architect",children:"family of protocols"})," for a modular privacy-preserving censorship-resistant decentralised communication network. The backbone of Waku is the Relay protocol (and its spam-protected version ",(0,r.jsx)(s.a,{href:"https://rfc.vac.dev/spec/17/",children:"RLN-Relay"}),"). Additionally, there are light protocols: Store, Filter, and Lightpush. Light protocols are also referred to as client-server protocols and request-response protocols."]}),"\n",(0,r.jsxs)(s.p,{children:["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 ",(0,r.jsx)(s.a,{href:"https://github.com/waku-org/research/issues/28",children:"discussion"}),")."]}),"\n",(0,r.jsx)(s.p,{children:"In light protocols, a client sends a request to a server, and a server performs some actions and returns a response:"}),"\n",(0,r.jsxs)(s.ul,{children:["\n",(0,r.jsxs)(s.li,{children:[(0,r.jsx)(s.a,{href:"https://rfc.vac.dev/spec/13/",children:"Store"}),": the server responds with messages relayed that match a set of criteria;"]}),"\n",(0,r.jsxs)(s.li,{children:[(0,r.jsx)(s.a,{href:"https://rfc.vac.dev/spec/12/",children:"Filter"}),": the server will relay (only) messages that pass a filter to the client;"]}),"\n",(0,r.jsxs)(s.li,{children:[(0,r.jsx)(s.a,{href:"https://rfc.vac.dev/spec/19/",children:"Lightpush"}),": the server publishes the client's message to the Relay network."]}),"\n"]}),"\n",(0,r.jsx)(s.h2,{id:"waku-i13n-challenges",children:"Waku i13n challenges"}),"\n",(0,r.jsxs)(s.p,{children:["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 ",(0,r.jsx)(s.a,{href:"https://rfc.vac.dev/spec/17/",children:"RLN-Relay"})," adds monetary punishments for spammers, slashing is yet to be activated."]}),"\n",(0,r.jsx)(s.p,{children:"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."}),"\n",(0,r.jsx)(s.p,{children:"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."}),"\n",(0,r.jsx)(s.h2,{id:"waku-store",children:"Waku Store"}),"\n",(0,r.jsx)(s.p,{children:"Waku Store is a light protocol for querying historic messages that works as follows:"}),"\n",(0,r.jsxs)(s.ol,{children:["\n",(0,r.jsxs)(s.li,{children:["the client sends a ",(0,r.jsx)(s.code,{children:"HistoryQuery"})," to the server;"]}),"\n",(0,r.jsxs)(s.li,{children:["the server sends a ",(0,r.jsx)(s.code,{children:"HistoryResponse"})," to the client."]}),"\n"]}),"\n",(0,r.jsxs)(s.p,{children:["The response may be split into multiple parts, as specified by pagination parameters in ",(0,r.jsx)(s.code,{children:"PagingInfo"}),"."]}),"\n",(0,r.jsxs)(s.p,{children:["We define a ",(0,r.jsx)(s.em,{children:"relevant"})," 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."]}),"\n",(0,r.jsx)(s.h1,{id:"waku-store-incentivisation",children:"Waku Store incentivisation"}),"\n",(0,r.jsx)(s.p,{children:"An incentivised Store protocol has the following extra steps:"}),"\n",(0,r.jsxs)(s.ol,{children:["\n",(0,r.jsxs)(s.li,{children:["pricing:","\n",(0,r.jsxs)(s.ol,{children:["\n",(0,r.jsx)(s.li,{children:"cost calculation"}),"\n",(0,r.jsx)(s.li,{children:"price advertisement"}),"\n",(0,r.jsx)(s.li,{children:"price negotiation"}),"\n"]}),"\n"]}),"\n",(0,r.jsxs)(s.li,{children:["payment:","\n",(0,r.jsxs)(s.ol,{children:["\n",(0,r.jsx)(s.li,{children:"payment itself"}),"\n",(0,r.jsx)(s.li,{children:"proof of payment"}),"\n"]}),"\n"]}),"\n",(0,r.jsx)(s.li,{children:"reputation"}),"\n",(0,r.jsx)(s.li,{children:"results cross-checking"}),"\n"]}),"\n",(0,r.jsx)(s.p,{children:"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:"}),"\n",(0,r.jsxs)(s.ul,{children:["\n",(0,r.jsx)(s.li,{children:"cost calculation is based on a common-knowledge price;"}),"\n",(0,r.jsx)(s.li,{children:"there is no price advertisement and no price negotiation;"}),"\n",(0,r.jsxs)(s.li,{children:["each query is paid for in a separate transaction, ",(0,r.jsx)(s.code,{children:"txid"})," acts a proof of payment;"]}),"\n",(0,r.jsx)(s.li,{children:"the reputation system is simplified (see below);"}),"\n",(0,r.jsx)(s.li,{children:"the results are not cross-checked."}),"\n"]}),"\n",(0,r.jsx)(s.p,{children:"In the PoC protocol:"}),"\n",(0,r.jsxs)(s.ol,{children:["\n",(0,r.jsx)(s.li,{children:"the client calculates the price based on the known rate per hour of history;"}),"\n",(0,r.jsx)(s.li,{children:"the client pays the appropriate amount to the server's address;"}),"\n",(0,r.jsxs)(s.li,{children:["the client sends a ",(0,r.jsx)(s.code,{children:"HistoryQuery"})," to the server alongside the proof of payment (",(0,r.jsx)(s.code,{children:"txid"}),");"]}),"\n",(0,r.jsxs)(s.li,{children:["the server checks that the ",(0,r.jsx)(s.code,{children:"txid"})," corresponds to a confirmed transaction with at least the required amount;"]}),"\n",(0,r.jsxs)(s.li,{children:["the server sends a ",(0,r.jsx)(s.code,{children:"HistoryResponse"})," to the client."]}),"\n"]}),"\n",(0,r.jsx)(s.p,{children:"In further subsections, we list the potential direction for future work towards a fully-fledged i13n mechanism."}),"\n",(0,r.jsx)(s.h2,{id:"pricing",children:"Pricing"}),"\n",(0,r.jsx)(s.p,{children:"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."}),"\n",(0,r.jsx)(s.p,{children:"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."}),"\n",(0,r.jsx)(s.h3,{id:"future-work",children:"Future work"}),"\n",(0,r.jsxs)(s.ul,{children:["\n",(0,r.jsxs)(s.li,{children:["DoS protection - see ",(0,r.jsx)(s.a,{href:"https://github.com/waku-org/research/issues/66",children:"https://github.com/waku-org/research/issues/66"})]}),"\n",(0,r.jsxs)(s.li,{children:["Cost calculation - see ",(0,r.jsx)(s.a,{href:"https://github.com/waku-org/research/issues/35",children:"https://github.com/waku-org/research/issues/35"})]}),"\n",(0,r.jsxs)(s.li,{children:["Price advertisement - see ",(0,r.jsx)(s.a,{href:"https://github.com/waku-org/research/issues/51",children:"https://github.com/waku-org/research/issues/51"})]}),"\n",(0,r.jsxs)(s.li,{children:["Price negotiation - see ",(0,r.jsx)(s.a,{href:"https://github.com/waku-org/research/issues/52",children:"https://github.com/waku-org/research/issues/52"})]}),"\n"]}),"\n",(0,r.jsx)(s.h2,{id:"payment",children:"Payment"}),"\n",(0,r.jsxs)(s.p,{children:["For the PoC, each request is paid for with a separate transaction. The transaction hash (",(0,r.jsx)(s.code,{children:"txid"}),") acts as a proof of payment. The server verifies the payment by ensuring that:"]}),"\n",(0,r.jsxs)(s.ol,{children:["\n",(0,r.jsx)(s.li,{children:"the transaction has been confirmed;"}),"\n",(0,r.jsx)(s.li,{children:"the transaction is paying the proper amount to the server's account;"}),"\n",(0,r.jsxs)(s.li,{children:["the ",(0,r.jsx)(s.code,{children:"txid"})," does not correspond to any prior response."]}),"\n"]}),"\n",(0,r.jsx)(s.p,{children:"The client gives proof of payment before it receives the response. Other options could be:"}),"\n",(0,r.jsxs)(s.ol,{children:["\n",(0,r.jsx)(s.li,{children:"the client pays after the fact;"}),"\n",(0,r.jsx)(s.li,{children:"the client pays partly upfront and partly after the fact;"}),"\n",(0,r.jsx)(s.li,{children:"a centralised third party (either trusted or semi-trusted, like a smart contract) ensures atomicity;"}),"\n",(0,r.jsx)(s.li,{children:"cryptographically ensured atomicity (similar to atomic swaps, Lightning, or Hopr)."}),"\n"]}),"\n",(0,r.jsx)(s.p,{children:"Our design considerations are:"}),"\n",(0,r.jsxs)(s.ul,{children:["\n",(0,r.jsx)(s.li,{children:"the PoC protocol should be simple;"}),"\n",(0,r.jsx)(s.li,{children:'servers are more "permanent" entities and are more likely to have long-lived identities;'}),"\n",(0,r.jsx)(s.li,{children:"it is more important to protect the clients's privacy than the server's privacy."}),"\n"]}),"\n",(0,r.jsx)(s.p,{children:"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."}),"\n",(0,r.jsx)(s.h3,{id:"future-work-1",children:"Future work"}),"\n",(0,r.jsxs)(s.ul,{children:["\n",(0,r.jsxs)(s.li,{children:["Add more payment methods - see ",(0,r.jsx)(s.a,{href:"https://github.com/waku-org/research/issues/58",children:"https://github.com/waku-org/research/issues/58"})]}),"\n",(0,r.jsxs)(s.li,{children:["Design a subscription model with service credentials - see ",(0,r.jsx)(s.a,{href:"https://github.com/waku-org/research/issues/59",children:"https://github.com/waku-org/research/issues/59"})]}),"\n",(0,r.jsxs)(s.li,{children:["Add privacy to service credentials - see ",(0,r.jsx)(s.a,{href:"https://github.com/waku-org/research/issues/60",children:"https://github.com/waku-org/research/issues/60"})]}),"\n",(0,r.jsxs)(s.li,{children:["Consider the impact of network disruptions - see ",(0,r.jsx)(s.a,{href:"https://github.com/waku-org/research/issues/65",children:"https://github.com/waku-org/research/issues/65"})]}),"\n"]}),"\n",(0,r.jsx)(s.h2,{id:"reputation",children:"Reputation"}),"\n",(0,r.jsx)(s.p,{children:"We use reputation to discourage the server from taking the payment and not responding. The client keeps track of the server's reputation:"}),"\n",(0,r.jsxs)(s.ul,{children:["\n",(0,r.jsx)(s.li,{children:"all servers start with zero reputation points;"}),"\n",(0,r.jsxs)(s.li,{children:["if the server honours the request, it gets ",(0,r.jsx)(s.code,{children:"+n"})," points;"]}),"\n",(0,r.jsxs)(s.li,{children:["if the server does not respond before a timeout, it gets ",(0,r.jsx)(s.code,{children:"-m"})," points."]}),"\n",(0,r.jsxs)(s.li,{children:["if the server's reputation drops below ",(0,r.jsx)(s.code,{children:"k"})," points, the client will never query it again."]}),"\n"]}),"\n",(0,r.jsxs)(s.p,{children:[(0,r.jsx)(s.code,{children:"n"}),", ",(0,r.jsx)(s.code,{children:"m"}),", and ",(0,r.jsx)(s.code,{children:"k"})," are subject to configuration."]}),"\n",(0,r.jsx)(s.p,{children:"Optionally, a client may treat a given server as trusted, assigning it a constant positive reputation."}),"\n",(0,r.jsx)(s.p,{children:"Potential issues:"}),"\n",(0,r.jsxs)(s.ul,{children:["\n",(0,r.jsxs)(s.li,{children:["An attacker can establish new server identities and continue running away with clients' money. Countermeasures:","\n",(0,r.jsxs)(s.ul,{children:["\n",(0,r.jsx)(s.li,{children:"a client only queries trusted servers (which however leads to centralisation);"}),"\n",(0,r.jsx)(s.li,{children:"when querying a new server, a client first sends a small (i.e. cheap) request as a test;"}),"\n",(0,r.jsx)(s.li,{children:"more generally, the client selects a server on a case-by-case basis, weighing the payment amount against the server's reputation."}),"\n"]}),"\n"]}),"\n",(0,r.jsx)(s.li,{children:"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."}),"\n"]}),"\n",(0,r.jsx)(s.h3,{id:"future-work-2",children:"Future work"}),"\n",(0,r.jsx)(s.p,{children:"Design a more comprehensive reputation system:"}),"\n",(0,r.jsxs)(s.ul,{children:["\n",(0,r.jsxs)(s.li,{children:["local reputation - see ",(0,r.jsx)(s.a,{href:"https://github.com/waku-org/research/issues/48",children:"https://github.com/waku-org/research/issues/48"})]}),"\n",(0,r.jsxs)(s.li,{children:["global reputation - see ",(0,r.jsx)(s.a,{href:"https://github.com/waku-org/research/issues/49",children:"https://github.com/waku-org/research/issues/49"})]}),"\n"]}),"\n",(0,r.jsx)(s.h2,{id:"results-cross-checking",children:"Results cross-checking"}),"\n",(0,r.jsx)(s.p,{children:"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."}),"\n",(0,r.jsx)(s.h3,{id:"future-work-3",children:"Future work"}),"\n",(0,r.jsxs)(s.ul,{children:["\n",(0,r.jsxs)(s.li,{children:["Cross-checking the results against censorship - see ",(0,r.jsx)(s.a,{href:"https://github.com/waku-org/research/issues/57",children:"https://github.com/waku-org/research/issues/57"})]}),"\n",(0,r.jsxs)(s.li,{children:["Use RLN to limit fake message insertion - see ",(0,r.jsx)(s.a,{href:"https://github.com/waku-org/research/issues/38",children:"https://github.com/waku-org/research/issues/38"})]}),"\n"]}),"\n",(0,r.jsx)(s.h1,{id:"evaluation",children:"Evaluation"}),"\n",(0,r.jsx)(s.p,{children:"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."}),"\n",(0,r.jsx)(s.h1,{id:"longer-term-future-work",children:"Longer-term future work"}),"\n",(0,r.jsxs)(s.ul,{children:["\n",(0,r.jsxs)(s.li,{children:["Analyze privacy issues - see ",(0,r.jsx)(s.a,{href:"https://github.com/waku-org/research/issues/61",children:"https://github.com/waku-org/research/issues/61"})]}),"\n",(0,r.jsxs)(s.li,{children:["Analyze decentralised storage protocols and their relevance e.g. as back-end storage for Store servers - see ",(0,r.jsx)(s.a,{href:"https://github.com/waku-org/research/issues/34",children:"https://github.com/waku-org/research/issues/34"})]}),"\n",(0,r.jsxs)(s.li,{children:["Analyze the role of message senders, in particular, whether they should pay for sending non-ephemeral messages - see ",(0,r.jsx)(s.a,{href:"https://github.com/waku-org/research/issues/32",children:"https://github.com/waku-org/research/issues/32"})]}),"\n",(0,r.jsxs)(s.li,{children:["Generalise incentivisation protocol to other Waku light protocols (Lightpush and Filter) - see ",(0,r.jsx)(s.a,{href:"https://github.com/waku-org/research/issues/67",children:"https://github.com/waku-org/research/issues/67"}),"."]}),"\n"]})]})}function d(e={}){const{wrapper:s}={...(0,t.R)(),...e.components};return s?(0,r.jsx)(s,{...e,children:(0,r.jsx)(h,{...e})}):h(e)}}}]);