mirror of https://github.com/vacp2p/rfc-index.git
Update and rename SWAP.md to swap.md
This commit is contained in:
Jimmy Debe
GitHub
parent
b35846a546
commit
0d8ad08222
|
|
@ -7,11 +7,13 @@ editor: Oskar Thorén <oskarth@titanproxy.com>
|
|||
contributor: Ebube Ud <ebube@status.im>
|
||||
---
|
||||
|
||||
## Abstract
|
||||
|
||||
This specification outlines how we do accounting and settlement based on the provision and usage of resources, most immediately bandwidth usage and/or storing and retrieving of Waku message. This enables nodes to cooperate and efficiently share resources, and in the case of unequal nodes to settle the difference through a relaxed payment mechanism in the form of sending cheques.
|
||||
|
||||
**Protocol identifier***: `/vac/waku/swap/2.0.0-beta1`
|
||||
|
||||
# Motivation
|
||||
## Motivation
|
||||
|
||||
The Waku network makes up a service network, and some nodes provide a useful service to other nodes. We want to account for that, and when imbalances arise, settle this. The core of this approach has some theoretical backing in game theory, and variants of it have practically been proven to work in systems such as Bittorrent. The specific model use was developed by the Swarm project (previously part of Ethereum), and we re-use contracts that were written for this purpose.
|
||||
|
||||
|
|
@ -19,7 +21,7 @@ By using a delayed payment mechanism in the form of cheques, a barter-like mecha
|
|||
|
||||
Theoretically, nodes providing and using resources over a long, indefinite, period of time can be seen as an iterated form of [Prisoner's Dilemma (PD)](https://en.wikipedia.org/wiki/Prisoner%27s_dilemma). Specifically, and more intuitively, since we have a cost and benefit profile for each provision/usage (of Waku Message's, e.g.), and the pricing can be set such that mutual cooperation is incentivized, this can be analyzed as a form of donations game.
|
||||
|
||||
# Game Theory - Iterated prisoner's dilemma / donation game
|
||||
## Game Theory - Iterated prisoner's dilemma / donation game
|
||||
|
||||
What follows is a sketch of what the game looks like between two nodes. We can look at it as a special case of iterated prisoner's dilemma called a [Donation game](https://en.wikipedia.org/wiki/Prisoner%27s_dilemma#Special_case:_donation_game) where each node can cooperate with some benefit `b` at a personal cost `c`, where `b>c`.
|
||||
|
||||
|
|
@ -57,7 +59,7 @@ A tit-for-tat strategy basically means:
|
|||
|
||||
This can be complemented with node selection mechanisms.
|
||||
|
||||
# SWAP protocol overview
|
||||
## SWAP protocol overview
|
||||
|
||||
We use SWAP for accounting and settlement in conjunction with other request/reply protocols in Waku v2,
|
||||
where accounting is done in a pairwise manner.
|
||||
|
|
@ -75,7 +77,7 @@ Sending cheques is done once payment threshold is hit.
|
|||
|
||||
See [Book of Swarm](https://web.archive.org/web/20210126130038/https://gateway.ethswarm.org/bzz/latest.bookofswarm.eth) section 3.2. on Peer-to-peer accounting etc., for more context and details.
|
||||
|
||||
## Accounting
|
||||
### Accounting
|
||||
|
||||
Nodes perform their own accounting for each relevant peer based on some "volume"/bandwidth metric. For now we take this to mean the number of `WakuMessage`s exchanged.
|
||||
|
||||
|
|
@ -85,7 +87,7 @@ Each accounting balance SHOULD be w.r.t. to a given protocol it is accounting fo
|
|||
|
||||
NOTE: This may later be complemented with other metrics, either as part of SWAP or more likely outside of it. For example, online time can be communicated and attested to as a form of enhanced quality of service to inform peer selection.
|
||||
|
||||
## Flow
|
||||
### Flow
|
||||
|
||||
Assuming we have two store nodes, one operating mostly as a client (A) and another as server (B).
|
||||
|
||||
|
|
@ -97,13 +99,14 @@ Assuming we have two store nodes, one operating mostly as a client (A) and anoth
|
|||
|
||||
Note that not all of these steps are mandatory in initial stages, see below for more details. For example, the payment threshold MAY initially be set out of bounds, and policy is only activated in the mock and hard phase.
|
||||
|
||||
## Protobufs
|
||||
### Protobufs
|
||||
|
||||
We use protobuf to specify the handshake and signature. This current protobuf is a work in progress. This is needed for mock and hard phase.
|
||||
|
||||
A handshake gives initial information about payment thresholds and possibly other information. A cheque is best thought of as a promise to pay at a later date.
|
||||
|
||||
```
|
||||
```protobuf
|
||||
|
||||
message Handshake {
|
||||
bytes payment_threshold = 1;
|
||||
}
|
||||
|
|
@ -118,9 +121,10 @@ message Cheque {
|
|||
// For now karma counter
|
||||
uint32 amount = 3;
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
# Incremental integration and roll-out
|
||||
## Incremental integration and roll-out
|
||||
|
||||
To incrementally integrate this into Waku v2, we have divided up the roll-out into three phases:
|
||||
|
||||
|
|
@ -131,19 +135,19 @@ To incrementally integrate this into Waku v2, we have divided up the roll-out in
|
|||
|
||||
An implementation MAY support any of these phases.
|
||||
|
||||
## Soft phase
|
||||
### Soft phase
|
||||
|
||||
In the soft phase only accounting is performed, without consequence for the
|
||||
peers. No disconnect or sending of cheques is performed at this tage.
|
||||
|
||||
SWAP protocol is performed in conjunction with another request-reply protocol to account for its usage.
|
||||
It SHOULD be done for [13/WAKU2-STORE](/spec/13/)
|
||||
It SHOULD be done for [13/WAKU2-STORE](../../standards/core/13/store.md)
|
||||
and it MAY be done for other request/reply protocols.
|
||||
|
||||
A client SHOULD log accounting state per peer
|
||||
and SHOULD indicate when a peer is out of bounds (either of its thresholds met).
|
||||
|
||||
## Mock phase
|
||||
### Mock phase
|
||||
|
||||
In the mock phase, we send mock cheques and send cheques/disconnect peers as appropriate.
|
||||
|
||||
|
|
@ -153,27 +157,23 @@ In the mock phase, we send mock cheques and send cheques/disconnect peers as app
|
|||
- If any node behaves badly, the other node is free to disconnect and pick another node.
|
||||
- Peer rating is out of scope of this specification.
|
||||
|
||||
## Hard phase
|
||||
### Hard phase
|
||||
|
||||
In the hard phase, in addition to sending cheques and activating policy, this is
|
||||
done with blockchain integration on a public testnet. More details TBD.
|
||||
|
||||
This also includes settlements where cheques can be redeemed.
|
||||
|
||||
## References
|
||||
|
||||
1. [Prisoner's Dilemma](https://en.wikipedia.org/wiki/Prisoner%27s_dilemma)
|
||||
|
||||
2. [Donation game](https://en.wikipedia.org/wiki/Prisoner%27s_dilemma#Special_case:_donation_game)
|
||||
|
||||
3. [Axelrod - Evolution of Cooperation (book)](https://en.wikipedia.org/wiki/The_Evolution_of_Cooperation)
|
||||
|
||||
4. [Book of Swarm](https://web.archive.org/web/20210126130038/https://gateway.ethswarm.org/bzz/latest.bookofswarm.eth/)
|
||||
|
||||
# Copyright
|
||||
## Copyright
|
||||
|
||||
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
|
||||
|
||||
## References
|
||||
|
||||
1. [Prisoner's Dilemma](https://en.wikipedia.org/wiki/Prisoner%27s_dilemma)
|
||||
2. [Axelrod - Evolution of Cooperation (book)](https://en.wikipedia.org/wiki/The_Evolution_of_Cooperation)
|
||||
3. [Book of Swarm](https://web.archive.org/web/20210126130038/https://gateway.ethswarm.org/bzz/latest.bookofswarm.eth)
|
||||
4. [13/WAKU2-STORE](../../standards/core/13/store.md)
|
||||
|
||||
<!--
|
||||
|
||||
Loading…
Reference in New Issue