-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The development roadmap of Waku store protocol incentivization using service credentials #135
Comments
@s1fr0 Please let me know your thoughts on the roadmap. |
Look good in general! My main concern is that Phase2 might require lots of new effort to adapt what already done in Phase1. That is, I would personally spend more time in studying/designing a game-theoretically solid protocol first, rather than risking to implement two potentially different schemes among Phase 1 and 2. Indeed, in my opinion, the most delicate part of Phase 1 probably is the circuit implementation, which would clearly be affected by the incentivization mechanism found and analyzed in Phase2. In other words, the game-theoretic solid proposal & analysis should be the first step, especially to understand the ZK primitives we might require: this is also what I recall we agreed during the offsite. As it is now, I would swap Phase1 and Phase2 and move raw RFC in the new Phase 1. Of course I'd be more than happy to follow this roadmap if we believe is better. |
Thanks for the comment @s1fr0 The other aspect is to coordinate the task distribution, please check the current task distribution and let me know your thoughts. |
Indeed the two phases seems a bit unbalanced in terms of tasks, i.e. phase 1 seems quite heavy given the time constraints you mention. I think we can work together on the RFC & game-theory analysis, while I can definitely take care of the circuit. For the integration, I also believe that it would be faster if there is your support too. since to me it looks like we essentially need to replicate what already done for RLN-RELAY (i.e. add an extra proof to messages) and there you have much more insight in the code-base to reach such goal than me. |
@s1fr0 Sounds good to me, we can certainly distribute the load for phase 2 as well. I believe you had a proposal for the game theory part, is it still in place? would be good if you could please open the issue so that we can start pushing that track further. If you prefer, I can also start with the initial game theory analysis, please let me know. |
Some updates: I merged phase1 and 2 (the game theory part can be a task inside the core implementation milestone). |
I agree that we should try to parallelize efforts where possible. In general, we should err on the side of working incrementally and getting something up and running as soon as possible. |
A couple of design decisions to make before the RFC write-up:
cc: @s1fr0 @oskarth comments, suggestions? |
What do you mean exactly by "should not require direct communication between the two parties"? The store query and response themselves already imply some (sort of) direct communication (or at least, an existing communication channel). Considering the remaining points 1.,2.,4.,5., the initial MVP seems to boil down to something on the lines of "pay a fixed amount in advance to the public store node's ethereum address to receive a (arbitrary long) store query result" (and modulo 3., the payment receipt could be sent along with the query itself). Is that correct? I also understand that this initial MVP doesn't address store protocol incentivization (i.e., incentivize store nodes to collect, keep updated and available their data), but defines how the fee is transferred between service requester and provider. In other words, the user seems to have no way to distinguish a "lazy" store node (low resources, poorly connected, etc. - but always behaving honestly as per 5.) from more active/connected ones, unless submits the same query at least twice. |
As a next step, I think it'd be a good idea to compare what we had originally planned with when discussing this multiple times, e.g. recent offsites, pre-Devcon discussions etc, with whatever diff we think is required for the solution to be acceptable. Right now it isn't very clear what we are talking about more concretely.
We can separate that part out as a separate milestone. Basically start with honest behavior assumption, then communicate more information like uptime etc, then look into slashing conditions. For initial phase we want to keep it simple. There are also game theoretic reasons you'll likely see long-term cooperation among honest nodes, since it is a repeated and possibly non-finite game. |
This meta issue embodies the development roadmap of achieving #99
At a high level, we need to take care of the following main components:
Milestones
In terms of user stories and milestones, we can proceed as follows. Note that phase1 and 2 can be pursued in parallel.
- Phase1, game-theoretic solid payment flow: This milestone is to study the game theory behind the flow of payment to make sure the two parties have enough at stake / or are incentivized enough to follow the protocol specifications.k
andr
values (the secrets for credential transfer). A Merkle tree is constructed based on the hardcoded list. The querying peer selects a credential from the hard-coded list and constructs a valid transfer proof and sends it alongside its HistoryQuery. The querier sends one credential per request regardless of the amount of queried data. The payment is done upfront by the querier. The receiver should verify the credential transfer and update the tree (the querying node should also update its tree).In terms of task distribution,
phase1 would be mainly run by @s1fr0, phase2 by @staheri14, and phase3 by both @staheri14 and @s1fr0.All phases will be done collaboratively by @s1fr0 and @staheri14.Once we agree on the general roadmap, we can follow up with individual milestone issues.
The text was updated successfully, but these errors were encountered: