Waku is preparing for production with a focus on the Status Communities use case. In this blog post, we will provide an
overview of recent discussions and research outputs, aiming to give you a better understanding of how the Waku network
may look like in terms of scaling and incentivization.
## DOS Mitigation for Status Communities
Waku is actively exploring DOS mitigation mechanisms suitable for Status Communities. While RLN
(Rate Limiting Nullifiers) remains the go-to DOS protection solution due to its privacy-preserving and
censorship-resistant properties, there is still more work to be done. We are excited to collaborate with PSE
(Privacy & Scaling Explorations) in this endeavor. Learn more about their latest progress in this [tweet](https://twitter.com/CPerezz19/status/1640373940634939394?s=20).
## A Heterogeneous Waku Network
As we noted in a previous [forum post](https://forum.vac.dev/t/waku-payment-models/166/3), Waku's protocol
incentivization model needs to be flexible to accommodate various business models. Flexibility ensures that projects
can choose how they want to use Waku based on their specific needs.
### Reversing the Incentivization Question
Traditionally, the question of incentivization revolves around how to incentivize operators to run nodes. We'd like to
reframe the question and instead ask, "How do we pay for the infrastructure?"
Waku does not intend to offer a free lunch.
Ethereum's infrastructure is supported by transaction fees and inflation, with validators receiving rewards from both sources.
However, this model does not suit a communication network like Waku.
Users and platforms would not want to pay for every single message they send. Additionally, Waku aims to support instant
ephemeral messages that do not require consensus or long-term storage.
Projects that use Waku to enable user interactions, whether for chat messages, gaming, private DeFi, notifications, or
inter-wallet communication, may have different value extraction models. Some users might provide services for the
project and expect to receive value by running nodes, while others may pay for the product or run infrastructure to
contribute back. Waku aims to support each of these use cases, which means there will be various ways to "pay for the
infrastructure."
In [his talk](https://vac.dev/building-privacy-protecting-infrastructure), Oskar addressed two strategies: RLN and service credentials.
### RLN and Service Credentials
RLN enables DOS protection across the network in a privacy-preserving and permission-less manner: stake in a contract,
and you can send messages.
Service credentials establish a customer-provider relationship. Users might pay to have messages they are interested in
stored and served by a provider. Alternatively, a community owner could pay a service provider to host their community.
Providers could offer trial or limited free services to Waku users, similar to Slack or Discord. Once a trial is expired or outgrown,
a community owner could pay for more storage or bandwidth, similar to Slack's model.
Alternatively, individual users could contribute financially, akin to Discord's Server Boost, or by sharing their own
resources with their community.
We anticipate witnessing various scenarios across the spectrum: from users sharing resources to users paying for access to the network and everything in between.
## Waku Network: Ethereum or Cosmos?
Another perspective is to consider whether the Waku network will resemble Ethereum or Cosmos.
For those not familiar with the difference between both, in a very concise manner:
- Ethereum is a set of protocols and software that are designed to operate on one common network and infrastructure
- Cosmos is a set of protocols and software (SDKs) designed to be deployed in separate yet interoperable networks and infrastructures by third parties
We want Waku to be decentralized to provide censorship resistance and privacy-preserving communication.
If each application has to deploy its own network, we will not achieve this goal.
Therefore, we aim Waku to be not only an open source set of protocols, but also a shared infrastructure that anyone can leverage to build applications on top, with some guarantees in terms of decentralization and anonymity.
This approach is closer in spirit to Ethereum than Cosmos.
Do note that, similarly to Ethereum, anyone is free to take Waku software and protocols and deploy their own network.
Yet, because of the difference in the fee model, the Waku Network is unlikely to be as unified as Ethereum's.
We currently assume that there will be separate gossipsub networks with different funding models.
Since there is no consensus on Waku, each individual operator can decide which network to support, enabling Waku to maintain its permission-less property.
Most likely, the Waku network will be heterogeneous, and node operators will choose the incentivization model they prefer.
To enable scalability, the flow of messages in the Waku network will be divided in shards,
so that not every node has to forward every message of the whole network.
Discovery protocols will facilitate users connecting to the right nodes to receive the messages they are interested in.
Different shards could be subject to a variety of rate limiting techniques (globally, targeted to that shard or something in-between).
Marketplace protocols may also be developed to help operators understand how they can best support the network and where
their resources are most needed. However, we are still far from establishing or even assert that such a marketplace will be needed.
## Open Problems
Splitting traffic between shards reduces bandwidth consumption for every Waku Relay node.
This improvement increases the likelihood that users with home connections can participate and contribute to the gossipsub network without encountering issues.
However, it does not cap traffic.
There are still open problems regarding how to guarantee that someone can use Waku with lower Internet bandwidth or run critical services, such as a validation node, on the same connection.
We have several ongoing initiatives:
- Analyzing the Status Community protocol to confirm efficient usage of Waku [[4]](https://github.com/vacp2p/research/issues/177)
- Simulating the Waku Network to measure actual bandwidth usage [[5]](https://github.com/waku-org/pm/issues/2)
- Segregating chat messages from control and media messages [[6]](https://rfc.vac.dev/spec/57/#control-message-shards)
The final solution will likely be a combination of protocols that reduce bandwidth usage or mitigate the risk of DOS attacks, providing flexibility for users and platforms to enable the best experience.
