In this milestone, we would like to add support for a basic private payment model in the store protocol, as the most resource-intensive protocol in the waku stack.
The settlement is inspired by the existing private payment pools. However, the pool management is done off-chain i.e., a Merkle tree of a hardcoded list of tokens is available to each peer. The opening to the tokens is also available.
The querying peer selects a token from the hard-coded list and constructs a valid transfer proof and sends it alongside its HistoryQuery to the serivce provider. The payment is done upfront by the querier. The receiver should verify the token transfer and update the tree (the querying node should also update its tree). At this phase, there is no global view of the tree rather each peer updates the tree based on its local view.
Above is a rough solution overview and is subject to change in the RAW RFC.
Risks and uncertainty
Limited time
The expected timeline is the end of September.
Acceptance criteria
[ ] Basic comparison between classic payment model with fixe-value tokens vs Nova model with arbitrary token values
[ ] Raw RFC capturing the current MVP
[ ] Implementation of the relevant circuit for the private settlement (Nova) and porting it to the nim-waku codebase
[ ] Protocol implementation in nim-waku
[ ] Dogfooding
Out of scope
Game-theory analysis concerning the fairness of the settlement in the adversarial setting
Problem
Please check this issue for the problem definition https://github.com/vacp2p/research/issues/99 The following milestone was agreed following https://github.com/vacp2p/research/issues/135
Scope
In this milestone, we would like to add support for a basic private payment model in the store protocol, as the most resource-intensive protocol in the waku stack. The settlement is inspired by the existing private payment pools. However, the pool management is done off-chain i.e., a Merkle tree of a hardcoded list of tokens is available to each peer. The opening to the tokens is also available. The querying peer selects a token from the hard-coded list and constructs a valid transfer proof and sends it alongside its HistoryQuery to the serivce provider. The payment is done upfront by the querier. The receiver should verify the token transfer and update the tree (the querying node should also update its tree). At this phase, there is no global view of the tree rather each peer updates the tree based on its local view. Above is a rough solution overview and is subject to change in the RAW RFC.
Risks and uncertainty
Limited time
The expected timeline is the end of September.
Acceptance criteria
Out of scope
Game-theory analysis concerning the fairness of the settlement in the adversarial setting
Notes and links
Check some of the links in https://github.com/vacp2p/research/issues/99
Future steps
The on-chain private settlement where the token deposits and transfers are moderated via a smart contract.