logos-messaging/research
1
0
Fork 0
mirror of https://github.com/logos-messaging/research.git synced 2026-01-05 23:53:08 +00:00
Code Issues Packages Projects Releases Wiki Activity

finalize MVP-centric version with links to future work issues

Browse Source
This commit is contained in:
Sergei Tikhomirov 2023-11-20 11:57:59 +01:00
parent f5f89494c3
commit a656e965ad
1 changed files with 53 additions and 58 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

111
incentivization.md
View File

@ -1,47 +1,36 @@
Waku is a family of decentralized communication protocols. Waku is a family of decentralized communication protocols.
The Waku network consists of independent nodes running the corresponding protocols. The Waku Network (TWN) consists of independent nodes running Waku protocols.
Waku needs incentivization (i13n) to ensure proper node behavior in the absence of any centralized coordinator. TWN needs incentivization (shortened to i13n) to ensure proper node behavior.
In this document, we overview the problem of i13n in decentralized systems. The goal of this document is to outline and contextualize our approach to TWN i13n.
We classify the possible methods of i13n and give example used in prior successful P2P networks. After providing an overview of Waku and relevant prior work,
We then briefly introduce Waku and outline the unique i13n challenges it presents. 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. # Incentivization in decentralized networks
We propose an i13n scheme for Store and implement an MVP solution. ## Incentivization tools
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
We can think of incentivization tools as a two-by-two matrix: We can think of incentivization tools as a two-by-two matrix:
- rewards vs punishment; - rewards vs punishment;
- monetary vs reputation. - monetary vs reputation.
In other words, there are four quadrants: In other words, there are four quadrants:
- monetary reward: the client pays the server; - monetary reward: the node gets rewarded;
- monetary punishment: the server makes a deposit and gets slashed if it misbehaves; - monetary punishment: the nodes deposits funds that are taken away (slashed) if it misbehaves;
- reputation reward: the server's reputation increases if it behaves well; - reputation reward: the node's reputation increases if it behaves well;
- reputation punishment: the server's reputation decreases if it behaves badly. - 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. Reputation only works if high reputation brings tangible benefits.
For example, clients should be more likely to connect to servers with high reputation and disconnect from servers with low reputation. For example, if nodes chose neighbors based on reputation, low-reputation nodes may miss out on potential revenue.
In the presence of monetary rewards, low-reputation servers miss out on potential revenue or lose their deposit. Reputation scores may be local (a node assigns scores to its neighbors) or global (each node gets a uniform score).
Without the monetary aspects, low-reputation nodes can't get as much benefit from the network. Global reputation in its simplest implementation involves a trusted third party,
Reputation either assumes a repeated interaction (i.e., local reputation), or some amount of trust (centrally managed rankings). although decentralized approaches are also possible.
Monetary motivation should ideally be atomically linked with performance. ## Prior work
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.
In blockchains, the desired behavior of miners or validators can be automatically verified and rewarded with native tokens (or punished by slashing). We may split incentivized decentralized networks into early file-sharing, blockchains, and decentralized storage.
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.
# Related work ### Early P2P file-sharing
There have been many example of incentivized decentralized systems.
## Early P2P file-sharing
Early P2P file-sharing networks employed reputation-based approaches and sticky defaults. 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. 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. 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. 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. Bitcoin has introduced native monetary i13n in a P2P network with proof-of-work (PoW).
In Bitcoin, miners create new blocks and are automatically rewarded with newly mined coins. PoW miners are automatically rewarded with newly mined coins for generating blocks.
An invalid block is rejected by other nodes and not rewarded. There are no intrinsic monetary punishments in Bitcoin.
There are no intrinsic monetary punishments in Bitcoin, only rewards. However, miners must expend physical resources before claiming the reward.
However, mining nodes are required to expend physical resources for block generation. 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. ### Decentralized storage
A validator locks up (stakes) native tokens and gets rewarded for validating new blocks and slashed for misbehavior.
## Decentralized storage 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.
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.
# Waku background # Waku background
Waku is a family of protocols (see [architecture](https://waku.org/about/architect)) for a modular decentralized censorship-resistant P2P communications network. 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/)). 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)). 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. In light protocols, a client sends a request to a server, and a server performs some actions and returns a response:
A server (a Relay node) performs some actions and returns a response, in particular:
- [[Filter]]: the server will relay (only) messages that pass a filter to the client; - [[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. - [[Lightpush]]: the server publishes the client's message to the Relay network.
## Waku i13n challenges ## Waku i13n challenges
As a communication protocol, Waku lacks consensus or a native token. Waku lacks consensus or a native token, which brings it closer to reputation-incentivized file-sharing systems.
These properties bring Waku closer to purely reputation-incentivized file-sharing systems. Indeed, currently Waku only operates under reputation-based rewards and punishments.
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.
While [RLN-Relay](https://rfc.vac.dev/spec/17/) adds monetary punishments for spammers, slashing is yet to be activated. 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 ## Waku Store
In this document, we focus on i13n for 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 # 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: We propose to add the following aspects to the protocol:
1. pricing: 1. pricing:
1. cost calculation 1. cost calculation
@ -121,8 +114,10 @@ We propose to add the following aspects to the protocol:
3. reputation 3. reputation
4. results cross-checking 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. 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 ## Pricing
@ -144,7 +139,7 @@ After the client sends a `HistoryQuery` to the server:
## Payment ## Payment
If the client agrees to the price, it sends a _proof of payment_ to the server. 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. The transaction hash (`txid`) acts as a proof of payment.
Note that client gives proof of payment before it receives the response. 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 ## Results cross-checking
Cross-checking is absent in MVP but should be considered later. 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 - 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 - Use RLN to limit fake message insertion - see https://github.com/waku-org/research/issues/38