Open jm-clius opened 9 months ago
My thoughts on SU2, I see 4 separate concept here; query, cache, sync and archive.
Thoughs on IU3:
Harberger tax on RLN membership could be the path to a $$$ self-sufficient protocol. Incentives would be aligned, Waku team would strive to make the protocol as good as possible to attract members and generate higher tax revenue.
It removes the one price fits all for memberships while keeping some decentralization and anonymity. The seriousness of the $ investment in TWN would reflects it's usefulness and the ranking of membership investment could act as a reputation system.
The downside would be gas and more smart contract would need to be created. Auctions for memberships, recurring tax, DAO management, etc...
Waku would become serious business :D
Harberger tax on RLN membership
Cool idea! Is this somewhat similar to DAI vaults? A contract keeps track of some invariant (in our case - whether I paid the tax), and if it is violated, the asset (RLN membership) goes on sale automatically, and liquidators buy it up.
allows for querying a list of keys (message hashes) from the Store
Does "querying a list of keys" mean "give me all keys for the given filters" (time frame, topic, etc), such that I can then selectively query the contents of messages by hash?
It looks to me that designing for SU1 and IU1 should be synchronized: we should think about what the synchronization methods mean in the incentivization context. It is now a bit unclear to me whether we draw a line between a light node querying messages from a full node, and full nodes helping each other sync. In particular, should both these processes be eventually paid for.
On reputation: the line between local and global reputation may be blurry, e.g., the Eigentrust protocol we've been discussing. AFAIU, it is a semi-global protocol: scores are kinda global, but only based on local-ish data. Would it be worth considering such option earlier than in a yet unscheduled milestone?
(Also, fixed a minor typo under SU: "this tracks work" -> "this track works").
Great roadmap overall.
Cool idea! Is this somewhat similar to DAI vaults? A contract keeps track of some invariant (in our case - whether I paid the tax), and if it is violated, the asset (RLN membership) goes on sale automatically, and liquidators buy it up.
I guess the mechanism is similar. Not paying tax would result in automatic auctioning of the RLN membership.
Weekly Update
After the launch of the public Waku Network (TWN) Gen 0, we want to track our vision for how the network should develop in terms of functional "upgrades". Each upgrade serves as a medium-term milestone consisting of incremental epics. Completed epics should be rolled out to the network as they're completed. This list does not include work in parallel to enable Status Communities to use TWN, which is tracked elsewhere.
Milestone: TWN Store Upgrade (SU)
Goal: After this upgrade, the network will provide distributed and synchronised store services Research tracks: Message Reliability
This track works to upgrade the Store service capability in the network from a collection of local, unsynchronised, semi-centralised (trusted) service nodes to a decentralised service capability in the network with inter-node synchronisation.
Epic SU1: Store v3-beta (message hashes)
An improved version of the Store protocol, marking a crucial increment towards a synchronisation protocol:
The proposed PR to simplify the Store protocol and use message hashes as index/cursor, can be used as a starting point.
Epic SU2: Store v3 (store synchronisation)
Building on Store v3-beta, this version of Store includes basic synchronisation between nodes. This will probably include:
Note that this can either be (i) designing a new synchronisation protocol built into the Store protocol (ii) adapting existing synchronisation building blocks (e.g. a Prolly Tree library) into Store, or (iii) simply swapping the key-value store itself to a synchronised backend, such as GossipLog IMO (iii) should be pursued as the preferred option, as far as possible.
Milestone: TWN Incentivisation Upgrade (IU)
Goal: After this upgrade, the network will provide proof of concept for incentivised service protocols, with a published breakdown clarifying the roadmap to productionisation Research tracks: Secure Scaling, Restricted Run, Protocol Incentivization
Epic IU1: Store Incentivisation POC
A POC incentivisation mechanism that incorporates POC versions of the three Waku service incentivisation elements:
Epic IU2: General Service Protocol Incentivisation POC
This expands POC incentivisation to other protocols:
Epic IU3 - Roadmap towards productionisation
The research and design necessary to come up with a roadmap to productionised incentivisation, including:
Milestone: TWN - Rate-limiting Upgrade (RU)
Goal: After this upgrade, the network will show maturity in how it rate limits, with better dimensioning for bandwidth capping, resource-restricted options and a clear evaluation of what is needed to improve DoS protection. Research tracks: Secure Scaling, Restricted Run, Rate Limiting
Epic RU1: RLNv2
Moving from RLNv1 to RLNv2 to allow better bandwidth dimensioning in the network. This will allow a message allocation per day per registered publisher, providing better statistical guarantees for network bandwidth usage.
See: https://github.com/waku-org/research/issues/22 for more
Epic RU2: RLN in resource-restricted clients
Enabling RLN proof generation and verification within light clients. Different options are set out in https://github.com/waku-org/research/issues/45. Most recently, the promising option of deploying the entire RLN membership tree to a L2 as opposed to a L1 chain, became the key focus of this effort.
Epic RU3: maturing RLN variables/parameters revision (staking, contract/chain, token)
Analyse RLN deployment in TWN Gen 0 and evaluate its DoS protection performance.
Further milestones (unscheduled)
The following milestones may be scheduled within the medium term if determined important in the course of other investigations: