mirror of https://github.com/acid-info/vac.dev.git
137 lines
8.4 KiB
Plaintext
137 lines
8.4 KiB
Plaintext
---
|
|
layout: post
|
|
name: 'The Future of Waku Network: Scaling, Incentivization, and Heterogeneity'
|
|
title: 'The Future of Waku Network: Scaling, Incentivization, and Heterogeneity'
|
|
date: 2023-04-03 00:00:00
|
|
authors: franck
|
|
published: true
|
|
slug: future-of-waku-network
|
|
categories: platform, operator, network
|
|
image: /img/black-waku-logo-with-name.png
|
|
discuss: https://forum.vac.dev/t/discussion-the-future-of-waku-network-scaling-incentivization-and-heterogeneity/173
|
|
hide_table_of_contents: false
|
|
---
|
|
|
|
Learn how the Waku Network is evolving through scaling, incentivization, and diverse ecosystem development and what the future might look like.
|
|
|
|
<!--truncate-->
|
|
|
|
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.
|
|
|
|
## Scalability and Discovery Protocols
|
|
|
|
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.
|
|
|
|
## The Evolving Waku Network
|
|
|
|
The definition of the "Waku Network" will likely change over time. In the near future, it will transition from a single
|
|
gossipsub network to a sharded set of networks unified by a common discovery layer. This change will promote scalability
|
|
and allow various payment models to coexist within the Waku ecosystem.
|
|
|
|
In conclusion, the future of Waku Network entails growth, incentivization, and heterogeneity while steadfastly
|
|
maintaining its core principles. As Waku continues to evolve, we expect it to accommodate a diverse range of use cases
|
|
and business models, all while preserving privacy, resisting censorship, avoiding surveillance, and remaining accessible
|
|
to devices with limited resources.
|
|
|
|
## References
|
|
|
|
1. [51/WAKU2-RELAY-SHARDING](https://rfc.vac.dev/spec/51/)
|
|
2. [57/STATUS-Simple-Scaling](https://rfc.vac.dev/spec/57/)
|
|
3. [58/RLN-V2](https://rfc.vac.dev/spec/58/)
|
|
4. [Scaling Status Communities: Potential Problems](https://github.com/vacp2p/research/issues/177)
|
|
5. [Waku Network Testing](https://github.com/waku-org/pm/issues/2)
|
|
6. [51/WAKU2-RELAY-SHARDING: Control Message Shards](https://rfc.vac.dev/spec/57/#control-message-shards)
|