[Milestone] Waku Network can support 1 million users

[fryorcraken]

2023 Milestones: https://notes.status.im/s/iylE6wdli#

Milestone label: E:2023-1mil-users

Priority Tracks: Secure Scalability
Due date: 30 Jun 2023

Summary

This epic builds on #59 and assumes that one shard can support 10k users. To support up to a million users, an application (ie, Status Communities) need to be spread over 100 shards.
This issue tracks the research and development needed to enable multi-sharding.

While it may not be possible to confirm this level of scalability until an application uses Waku with a user base of this size, every possible actions need to be taken to gain confidence Waku can achieve such target. This includes:

• Theoretical analysis
• Large scale simulations
• Software delivery
• Some dogfooding (may be at a smaller scale)

Justification

Waku needs to deliver the level of scalability needed by the Status application to ensure the success of the Status app, including DDOS protection.
Also, Waku needs to prove scalability capacity so external large platforms can adopt it with confidence.

Epics

• Roadmap(SeM): Secure Scaling vacp2p/research#154
• js-waku: Static Sharding
• go-waku: Auto-sharding v1
• research: 1.1 Network requirements and task breakdown

[fryorcraken]

We need somewhere to also track js-waku specific items for scaling. Here is a justification:

The current Status need focus on Desktop and Mobile environments. A Status Web client does exist, but the priority is to demonstrate that Waku can scale for Desktop environment, and hence, that Waku Relay can scale to 1 million users (in communities of 10,000 users). This is the work tracked by #31.

However, browser environment, via js-waku, is the Waku client:

• Primarily used to onboard developers and projects
• When it is not the first onboarding step, it is on the roadmap of various Waku users (such as Status).

I believe this work has two main angles:

1. Enabling browser nodes to connect to other nodes to access the network.
2. Enabling as many nodes as possible to serve browser nodes

• peer exchange support to find new nodes
• circuit-p2p support to connect to node behind nat
• webtransport and/or webrtc direct support to connect to SSL-less nodes
• Robustness strategies to cope with flaky (ie, a node running on a laptop) service node
• Measure/simulation to understand resources needed from service node (e.g. how much memory is needed to service 1000 browser nodes via filter and light push? How many browser can a cheap vps service? And on the other hand, what resources are needed for a someone to service their application/community of 10k browser users).

What would be out of scope if relay support in the browser and browser extension as they would be a 2nd step in browser support (more anonymity and improved UX).

Not sure if all items above should be covered under waku-org/research#3 or have their own milestones.

Note that webrtc direct and webtransport are not ready in nim-libp2p but I believe they are in go-libp2p.

[fryorcraken]

monthly update

Autosharding protocol has been defined and implemented in nwaku.
Breakdown of the technical roadmap to the Waku Network Gen 0 has progressed waku-org/research#3 (comment)

[jm-clius]

Closing as this milestone has been replaced by #50