Waku Network MVP: the public Waku network

[jm-clius]

We have learned a lot from the Status Communities MVP about the basic building blocks for a working Waku network. However, the Status MVP creates a private network. We want to take what we have learned and build a viable public Waku Network MVP. This issue tracks the work to specify and build the public Waku Network, with the minimum features for a viable network that is scalable, reasonably secure, and honest about trade-offs.

Why "Waku Network MVP"?

This is just a working title until we come up with something better. It denotes that this is our attempt to balance desired network features (such as scalability, anonymity, and security) against the practical tradeoffs necessary to make the network "work" within the medium term. In this paradigm, we recognise that the set of specifications that define an "ideal" messaging network with the highest level of guaranteed anonymity, security, etc. falls outside MVP scope.

What are some features WN must have?

Note: this is not a complete list of requirements, just some ideas of the scope that we should specify as part of this effort.

Auto-scaling with autosharding

The relayer network must be able to scale by automatically sharding content topics via some consistent hashing mechanism to deterministic pubsub topic shards. This should build on the static shard paradigm, by specifying the static shard index (or range of shard indices) across which WN auto-shards will be defined (making the shard something akin to a network-id for WN). This will include defining a pubsub topic format and range, but this must be abstracted from applications/platforms who should only be concerned with the content topic chosen for their application.

DoS Protection

WN should provide basic DoS protection, likely based on membership coupled with some form of rate-limiting. A basic version of the RLN would be ideal here, perhaps without slashing or staking. This should not prohibit more sophisticated methods of DoS protection from being implemented over time. The idea of a plugin JSON-RPC interface for validation could be useful here, e.g. RLN-validation-as-a-service, which would also allow innovation from applications to define their own validation rules where it makes sense.

Light protocols

The protocols for resource-restricted devices, including filter, lightpush, and peer-exchange are being hardened for the Status MVP. These will also form an integral part of WN, but with the added paradigm of making these services decentralizable via a form of service and capability discovery (see next point).

Service/capability discovery

WN must define a capability discovery method by which services, including light protocols and store for historical messages, can be provided by anyone in the network and discovered by interested clients.

Service incentivization

WN will not define any incentivization mechanisms in the MVP phase but, by allowing decentralizing and discovering services, should pave the way for incentivization to be implemented in the network.

How shall we go about this?

Currently, I envision that defining and building the WN MVP would be the main focusing effort for Waku Research after the Status MVP. Building a viable public network is not only crucial for the sustainability of the Waku project itself, but if we can demonstrate the value of such a network, many existing platforms (including Status) would choose to transition to the public network for their benefit as well.

Roughly, the steps we take could be:

1. Define the minimal requirements and properties that WN must have.
2. Publish an RFC that encompasses a network design with opinionated use of basic Waku protocols to achieve said requirements.
3. Breakdown and prioritize tasks.
4. Dogfood and launch.

cc @fryorcraken @alrevuelta @corpetty @kaiserd

[jm-clius]

Some more features to consider:

• decentralized bootstrapping (or at least allowing multiple/extendable DNS bootstrap lists) to remove reliance on waku fleets
• bandwidth limiting (per content topic?)
• timestamp validation

[alrevuelta]

Thanks for this @jm-clius. Some quick thoughts:

• More related to bussines development than technical, but I think we should consider launching partnerships with node operators with offchain incentives. So perhaps would repharse "will not define any incentivization mechanisms" by "will not define any onchain incentivization mechanisms". This could be a way of waku network relaying less on status fleets and being more decentralized (with some nuances ofc).
• While DoS protection is important, I think we should also enforce some maximum bandwidth per shard. Ofc assuming that we want anyone to run a "full node" at home. The tokenizing waku bandwidth idea can help here but would be more like a "tokenizing waku shards bandwidth" which makes things more difficult. Its main advantage is that we can assign x bandwidth to the max supply, so having 1% of the supply, gives you the right of publishing to y rate. We can do some zk magic here to unlink holder with message publiser, but wondering if we are being to hard with privacy. Linking a message to an address is ok imho, makes things easy to move forward and if someone wants more privacy, there are services beyond waku that offer that. Perhaps unpopular opinion given other discussions, but given the tradeoffs I would consider it.
• Agree that for dos protection, I dont think slashing is required, but unsure how RLN can work without staking. The tokenizing waku bandwidth idea does, since just holding is required.
• Will automatic sharding 100% abstract away from the user the concept of pubsub topic? Or will "custom topics" coexist in the waku network with "sharded topics"?

which would also allow innovation from applications to define their own validation rules where it makes sense.

Unsure if its a good idea. imho there should be one DoS protection solution to rule them all very well defined and neutral, that protects the network from being DoSed. Ethereum has gas to prevent spamming and we should have ???. I dont imagine Ethereum allowing custom validations that allow people to validate according to: OFAC compliant, unethic MEV, or whatever. This has been done but on top of the protocol, which required to change the software to somoe extent, which is difficult and desincentivices doing so.

Some people say its DoS validation but what it really could be is censorship.

timestamp validation

Without going into the possible attack vectors that it can open up, timestamp validation can be a very efficient mechanism to mitigate spam. Specially since other validation techniques may not be enough if one can do a "replay attack" aka spamming with old messages seen in the network, no longer cached by gossipsub.

As an opinion, if the attack vectors that timestamp introduces are really worring to us, then waku will never scale for the end user and it will stay a niche protocol used by privacy obsesed people. Both options are fine, but we have to choose.

TLDR:

• offchain incentives to get external node operators
• limit bandwidth per share to allow running waku from home
• one single DoS neutral protection to rule them all
• reevaluate tradeoffs and past decisions to decide what can be sacrified and what not given our goals.

[alrevuelta]

Adding:

• Reconsider max message size

[fryorcraken]

Agree that for dos protection, I dont think slashing is required, but unsure how RLN can work without staking. The tokenizing waku bandwidth idea does, since just holding is required.

What about joining the RLN using interep credentials? Or proving you own a zk notes in RAILGUN contracts?
Do you see major issues to use RLN this way? Or do you consider this as "staking" still?

[jm-clius]

UPDATE: I've removed all references to "Waku Network 1" or "WN1" in the description above and have opted for "Waku Network" or "Waku Network MVP" instead. The 1 was just confusing.

[fryorcraken]

Once we have a viable strategy to handle membership from different sources, it may be interesting to review sismo to define broader membership groups:

• https://docs.sismo.io/sismo-docs/sismo-factory/create-your-group
• https://docs.sismo.io/sismo-docs/knowledge-base/resources/sismo-hub/data-providers

[alrevuelta]

Adding a new point.

Improve store protocol decentralization

Problem:

• Right now the network relies on a set of few/honest/high-availability nodes to provide store capabilities.
• The are no incentives to run store nodes.
• Default configuration doesnt really help the network.

Solution:

• Further decentralize store by defaulting to a configuration that provides some store capabilities. By "some" I mean in terms of i) bandwidth usage and ii) disk usage, so that it works for a node running in a consumer grade laptop with a residential connection. This could be something like: store max x bytes (like we have) (or given retention time in days) and don't take more than y kb/s upstream.
• Instead of relying on a single node for store requests (like we currently kind of do) a store request should try to fetch messages from multiple nodes, and return the union of them. With this we mitigate the risk of a node i) not having some messages or ii) the node being offline.
• Even if the default retention time is just one or two days (which shouldn't take much space on the nodes), this would be an improvement as requests for this timespan will be leveraging the decentralization of the network. For more than that, we can always fallback to bootstrap nodes as we currently do.
• Response time could increase, since with this we can paralelize the requests, and offload the bootsrap nodes.

Trying to be more specific, these are the short term (low hanging fruit-ish) that we can do to decentralize store without much effort:

• set limits on what store can serve. We already have store (days/bytes) but we are missing max upstream allowed bandwidth: feat: set limit on store responses nwaku#1809
• change defaults, so that every node (at least using the providing binaries) provide some safe store capabilities.
• paralelize store requests, using multiple peers instead of just one.

[fryorcraken]

Relevant: waku-org/pm#21