44/WAKU2-PRIVATE-SETTLEMENT: RAW RFC by staheri14 · Pull Request #540 · vacp2p/rfc

staheri14 · 2022-09-27T23:49:34Z

Raw RFC for private settelement.

Some of the rationales behind the design choices are provided as inline comments (in the MD file), please read them through.

As a general note, we may want to simplify the UTXO usage, but I tried to first convey how UTXOs are originally used in other designs (so that we can use the current existing circom circuits) . Later we can revise and make it simpler if need be.
The main reason for using UTXOs is to allow custom value tokens (this is how it is done in Nova). I have already explained my reasoning in the RFC, copying them again here:
Custom token values have multiple benefits in the store protocol: 1) allow service providers to have their own pricing strategy, 2) it also copes with the Ether price fluctuations, 3) it lowers the computation overhead incurred by generating zk proofs e.g., instead of spending 100 different tokens each worth of x Ether (hence generating 100 proofs), one can spend one token worth of 100*x Ether

oskarth · 2022-09-29T04:51:33Z

content/docs/rfcs/44/README.md

+
+Upon receiving a history query, the service provider measures the cost of the service e.g., in terms of the size of the history response.
+It then communicates with the querying node 1) the cost in Ether, 2) a random `request_ID` 3) the necessary information for the payment e.g., its registered Ethereum address.
+The querying node sends a [transaction](#interaction-with-the-waku-service-contract), with the `request_ID` attached to it, to the contract to spend one of its service credential to pay to the service node.


I'm confused by this part. Isn't the whole point of this design to decouple payment with service credentials from settlement? If you require contract interactions every history quest this cost gas and it makes the system not scalable due to reasonable tps limits of underlying chain. It is also not realistic in terms of latency from HistoryQuery to HistoryResponse. What am I missing?

Or is the idea that you pre-pay for many HistoryQueries in advance? Not clear from text

How I see it there are two possible approaches:

the querying node generates and sends the zk proof directly to the service node, which can -verify it before answering to the query; -submit it to the contract and get paid preserving anonymity of the querying node but opening to possible double spend attacks (no need for request_ID).

the querying node submit the proof to the contract first using some info the service provide can use to track the payment. This implies that the service provide would be able to get and trace the querying node ethereum public key through the request_IDby looking at the contract, even before providing any meaningful response. As a result a probe service node could collect public keys of querying nodes that performs certain queries.

@s1fr0 both it possible, however, the first one is only possible if the spent token contains the exact amount as the amount requested by the store node (but not more). Otherwise, the token owner needs to wait for the store node to send the transaction to the contract so that it can use the remaining amount if its token.

oskarth · 2022-09-29T04:52:59Z

content/docs/rfcs/44/README.md

+
+Upon receiving a history query, the service provider measures the cost of the service e.g., in terms of the size of the history response.
+It then communicates with the querying node 1) the cost in Ether, 2) a random `request_ID` 3) the necessary information for the payment e.g., its registered Ethereum address.
+The querying node sends a [transaction](#interaction-with-the-waku-service-contract), with the `request_ID` attached to it, to the contract to spend one of its service credential to pay to the service node.


Or is the idea that you pre-pay for many HistoryQueries in advance? Not clear from text

oskarth · 2022-09-29T04:53:25Z

content/docs/rfcs/44/README.md

+  string request_id = 1;
+  HistoryQuery query = 2;
+  HistoryResponse response = 3;
+ SttlementRequest sttlement_request = 19;


Settlement typo in a few places ("Stt" / "stt")

oskarth · 2022-09-29T04:55:36Z

content/docs/rfcs/44/README.md

+# Waku Service Contract
+
+## Registered store nodes
+Nodes offering store protocol who are willing to use the private settlement MUST be registered in the Waku service contract.


Why? This makes it harder to do zero-cost entry too, e.g. if you want to make some crypto by providing a useful service (key insight behind Swarm's SWAP). If we can relax this assumption to e.g. only use new address + e.g. relayers it'd be useful.

We can relax it (it is not a critical design choice), but it may be good later for scoring and reputation, and also making sure some two random users can not transact with the contract (it just makes it harder but not impossible).
On the other side, I support the idea of zero entry.

oskarth · 2022-09-29T04:57:40Z

content/docs/rfcs/44/README.md

+Users interact with the contract to either `purchase` a credential or `transfer` a portion of their credential for some storage service. 
+Regardless of the type of the transaction i.e., being a `purchase` or `transfer`, all the transactions follow a general structure which is inspired by bitcoin UTXO idea. 
+
+Each service credential is treated as a UTXO.


This sounds interesting, but I'm not quite sure I follow. Perhaps motivation and illustration would be useful?

(Or maybe I just need to read it more carefully 😅 )

Is this idea from somewhere in particular? Is this how Nova works under the hood somehow?

Thanks for the comments @oskarth
This write up was not ready for review :) I will soon finish up my revisions and make it ready!
The quick response is that
-> UTXO is how Nova works under the hood
-> Registration is only needed for the store nodes, not the querying node, and the reason is to later be able to add reputation, also to make it hard for the users of the system to use the contract for arbitrary payments (outside of the store protocol)

I am adding more details on the rationale of design choices, hopefully, they would address your concerns

s1fr0 · 2022-09-29T21:23:45Z

content/docs/rfcs/44/README.md

+where `index` indicates the position of the `commitment` in the Merkle tree,
+and the `signature` is generated over the `commitment` and the `index` as:
+```
+signature = poseidonHash(privkey, commitment, index)


The name signature is confusing given that it represents an hash or you meant signing under privkey the commitment and index?

It is a hash, we can certainly change the name.

s1fr0 · 2022-09-29T21:46:42Z

content/docs/rfcs/44/README.md

+| `encryptedOutput1` |    | encryption of the first output UTXO|
+| `encryptedOutput2` |    | the encryption of the second output UTXO|


Are those really encryptions or commitments? I see you later use blinding factors..

s1fr0 · 2022-09-29T21:52:54Z

content/docs/rfcs/44/README.md

+The input UTXOs, if non-zero, should be part of the Merkle tree. 
+The output UTXOs are added to the Merkle tree.
+
+For example,  if a user wants to purchase a credential of value `amount`, it will create  two zero-value input UTXOs, and two output UTXOs, one with zero value and the other one with `amount` value. 


At this point may sound confusing that you create value from zero-value transactions. But is the (here hidden) extAmount that balances the output UTXOs' values, right?.

Your observation is right, the extAmount determines whether a fund should be deposited in the contract or can be withdrawn to the recipient. Please check this comment of mine #540 (comment).

s1fr0 · 2022-09-29T21:54:02Z

content/docs/rfcs/44/README.md

+Regardless of the type of the transaction i.e., being a `purchase` or `transfer`, all the transactions follow a general structure which is inspired by bitcoin UTXO idea. 
+
+Each service credential is treated as a UTXO.
+Each transaction involves  two input UTXOs (can be extended to up to 16 UTXOs) and creation of two output UTXOs.


I don't see why you need at least 2 inputs and not just 1 (that can be extended up to 16).

This is to make all the transactions look identical which is good for anonymity. Although, as I mentioned in the description, we may later decide to simplify things.

s1fr0 · 2022-09-29T22:24:29Z

content/docs/rfcs/44/README.md

+
+# Interaction with the Waku Service Contract
+
+Interaction of the user with the contract for 1) purchasing a credential and 2) transferring fund from an already existing credentials is identical. 


Is not clear to me how purchasing credential works: if identical a user that just joined the network how does generate the zk-proof? what input UTXOs uses? I guess recipient address and amount will be the contract address and the credential value, respectively.

Right, for the deposits i.e., purchase of credentials, the two inputs UTXOs are zero values, and the output UTXOs are zero and amount values. The extAmount will be equal to the amount and will be paid to the contract.
Please check the formula for the extAmount at line 222 and the contract verification part at line 274 of the RFC. let me know if that addresses your question.

how zero-value UTXOs are generated? Since are nullified I expect the user to be able to generate them, those are not required to be accumulated in the tree?

Please also check line 270 where the verification is explained.

staheri14 · 2022-09-30T00:11:02Z

Thank you @s1fr0 and @oskarth for your comments
I have finished my edits on the RFC and marked it as ready. Please check the new description and let me know your comments.

staheri14 · 2022-09-30T00:33:23Z

@oskarth @s1fr0 Please re-check the PR description.

oskarth · 2022-10-16T18:54:59Z

Sorry, devcon and travel, have had this PR on backlog. Why was this PR closed?

oskarth · 2022-10-18T00:37:30Z

This PR was closed without reason. It is still relevant. If we are doing it a different way then this should be explained in a comment and link to follow up issue.

oskarth · 2022-10-18T03:25:00Z

We need to restore the previous contents of this PR with work that was started more than 3 weeks ago. Otherwise we are lagging behind a month on critical work. It was also mentioned in several conversations to people to look over here to see the design, but now this has been forcefully removed with poor justification.

jimstir · 2024-03-07T18:25:37Z

Continue discussion at logos-messaging/specs#5. Some Waku rfcs are being moved to waku/specs repo as there will be a new rfc process.

oskarth reviewed Sep 29, 2022

View reviewed changes

s1fr0 reviewed Sep 29, 2022

View reviewed changes

staheri14 marked this pull request as ready for review September 30, 2022 00:09

staheri14 requested review from oskarth and s1fr0 September 30, 2022 00:30

add the initial md file

8d57ea5

staheri14 force-pushed the waku-incentivization/raw-rfc branch from 6726b8f to 8d57ea5 Compare October 15, 2022 01:48

staheri14 closed this Oct 15, 2022

oskarth reopened this Oct 18, 2022

oskarth removed request for oskarth and s1fr0 March 7, 2024 03:04

jimstir mentioned this pull request Mar 7, 2024

44/WAKU2-PRIVATE-SETTLEMENT: RAW RFC logos-messaging/specs#5

Open

jimstir closed this Mar 7, 2024

		\| `encryptedOutput1` \| \| encryption of the first output UTXO\|
		\| `encryptedOutput2` \| \| the encryption of the second output UTXO\|


		# Interaction with the Waku Service Contract

		Interaction of the user with the contract for 1) purchasing a credential and 2) transferring fund from an already existing credentials is identical.

Conversation

staheri14 commented Sep 27, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

staheri14 commented Sep 30, 2022

Uh oh!

staheri14 commented Sep 30, 2022

Uh oh!

oskarth commented Oct 16, 2022

Uh oh!

oskarth commented Oct 18, 2022

Uh oh!

oskarth commented Oct 18, 2022

Uh oh!

jimstir commented Mar 7, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

staheri14 commented Sep 27, 2022 •

edited

Loading