logos-co/roadmap
1
0
Fork 0
mirror of https://github.com/logos-co/roadmap.git synced 2025-02-02 11:25:27 +00:00
Code Issues Packages Projects Releases Wiki Activity

Waku: update RLN milestone as per new roadmap

Browse Source
This commit is contained in:
fryorcraken 2024-10-02 16:00:52 +10:00
parent 1bf0348a30
commit 712d17fc76
No known key found for this signature in database
GPG Key ID: A82ED75A8DFC50A4
3 changed files with 70 additions and 32 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
content/waku/2024-milestones.md
View File

@ -8,6 +8,6 @@ date: 2024-06-04
- [End-to-end reliability protocol](waku/milestones/2024-e2e-reliability-protocol.md)
- [Static Sharding - dedicated shards](waku/milestones/2024-static-sharding-dedicated-shards.md)
- [Bandwidth optimization and protocol review](waku/milestones/2024-bandwidth-optimization-and-protocol-review.md)
- [Scale up number of Communities](waku/milestones/2024-scale-one-to-one-chat-poc.md)
- [Scale up number of Communities](waku/milestones/2024-scale-number-of-communities.md)
- [Nwaku in Status Desktop (Relay, *nix)](waku/milestones/2024-nwaku-in-status-desktop.md)
- [Scale 1:1 chat messages PoC](waku/milestones/2024-scale-one-to-one-chat-poc.md)
- [RLN Mainnet](waku/milestones/2024-rln-mainnet.md)

68
content/waku/milestones/2024-rln-mainnet.md Normal file
View File

@ -0,0 +1,68 @@
---
title: RLN Mainnet
tags:
- waku-milestone
date: 2024-09-07
---
# [RLN Mainnet](https://github.com/waku-org/pm/milestone/34)
Due Date: 2024-12-31
Once complemented, the economical behaviour of RLN will have been specified, implemented and discussed with the Status team.
An implementation of RLN for light clients will also be done, to demonstrate RLN’s UX with onchain Merkle tree.
Finally, the smart contract will be deployed on mainnet.
It will be then possible to design the usage of RLN in Status 1:1 chats.
## Deliverable: [RLNv2 in nwaku](https://github.com/waku-org/pm/issues/204)
Improved flexibility of the rate limit (from 1 msg/epoch to N msg/epoch), providing better dimensioning for bandwidth capping.
Moving from RLNv1 to RLNv2 to allow better bandwidth dimensioning in the network. This will allow a message allocation per hour or day per registered publisher, providing better statistical guarantees for network bandwidth usage.
Note this only concerns native libraries using nwaku.
## Deliverable: [Maturing RLN variables/parameters revision (staking, contract/chain, token) - roadmap](https://github.com/waku-org/pm/issues/205)
*A review of RLN security parameters and functionality in preparation for mainnet deployment.*
Analyse RLN deployment in the Waku proto-network and evaluate its DoS protection performance as well as review with the Status app team the potential cost mode of RLN:
- Should staking be introduced, especially to improve resilience against adversarial membership registrations?
- Should slashing be introduced or does the existing gossipsub scoring method provide enough protection?
- Which chain or L2 should we target for memberships?
- What token should be used?
- Do we need a combination of msg/sec and msg allocation/day rate limiting?
## Deliverable: Implement RLN smart contract for paid, multilevel memberships
This deliverable is an output of Maturing RLN variables/parameters revision (staking, contract/chain, token) - roadmap.
Once we have matured the RLN parameters and specified a minimal set of (smart contract) features for a production-ready membership mechanism, the proposed smart contract changes must be implemented. This also implies implementing each feature in the different Waku clients as needed.
Initial discussion indicates that our minimal feature set include:
Paid RLN memberships
RLN memberships at different rate-limit tiers
Expiry of memberships to prevent hogging
Support for RLN in resource-restricted clients, i.e. lightweight proof generation and validation
The exact set of features is to be defined in a RFC, as output of Maturing RLN variables/parameters revision (staking, contract/chain, token) - roadmap.
## Deliverable: RLN contract revision and audit
Once a minimal set of smart contract features for RLN has been implemented, the contract needs to be thoroughly revised (and possibly audited) by a group of experts before it can be used in production.
The Waku team will rely on Vac/SC to proceed/organise the smart contract review and audit
## Deliverable: Deploy RLN smart contract to a L2 mainnet
The RLN smart contract should be deployed to a Layer 2 mainnet.
A first step here may be to deploy to a Layer 2 testnet first. However, we could deploy a test contract to a Layer 2 mainnet directly if it's easier. (A contract used for testing does not have to be productionised/audited before deployment to mainnet.)
This deliverable tracks all steps to deployment of a production version of the contract to a L2.
## Deliverable: Public dogfooding RLNaaS web app
Second part of original scope of dogfooding web app.
One of the proposed strategies to roll out RLN for Status 1:1 chats is to use RLNaaS where a service node attaches RLN proof for light clients. This would enable a roll out of RLN without impacting UX or UI.
However, this would decrease the security that RLN brings, so we need to further test this topology to better under risks and mitigate them, or drop this approach.
Deliver a gamified web app to allow further dogfooding of RLN. This should build on the previously delivered (internal) web app to collect reliability and performance metrics.
This may include capturing new metrics from the fleets to gather data and assess the viability of RLNaaS from this experiment.

30
content/waku/milestones/2024-scale-one-to-one-chat-poc.md
View File

@ -1,30 +0,0 @@
---
title: Scale 1 to 1 chat messages PoC
tags:
- waku-milestone
date: 2024-09-07
---
[Milestone Scale 1:1 chat messages PoC](https://github.com/waku-org/pm/milestone/34)
Due Date: 2024-11-30
Improved flexibility of the rate limit (from 1 msg/epoch to N msg/epoch), providing better dimensioning for bandwidth capping.
Moving from RLNv1 to RLNv2 to allow better bandwidth dimensioning in the network. This will allow a message allocation per hour or day per registered publisher, providing better statistical guarantees for network bandwidth usage.
### Deliverable: [RLNv2 in nwaku](https://github.com/waku-org/pm/issues/204)
Improved flexibility of the rate limit (from 1 msg/epoch to N msg/epoch), providing better dimensioning for bandwidth capping.
Moving from RLNv1 to RLNv2 to allow better bandwidth dimensioning in the network. This will allow a message allocation per hour or day per registered publisher, providing better statistical guarantees for network bandwidth usage.
Note this only concerns native libraries using nwaku.
### Deliverable: [Maturing RLN variables/parameters revision (staking, contract/chain, token) - roadmap](https://github.com/waku-org/pm/issues/205)
*A review of RLN security parameters and functionality in preparation for mainnet deployment.*
Analyse RLN deployment in the Waku proto-network and evaluate its DoS protection performance as well as review with the Status app team the potential cost mode of RLN:
- Should staking be introduced, especially to improve resilience against adversarial membership registrations?
- Should slashing be introduced or does the existing gossipsub scoring method provide enough protection?
- Which chain or L2 should we target for memberships?
- What token should be used?
- Do we need a combination of msg/sec and msg allocation/day rate limiting?