With the recent launch of the Waku Network Gen 0 introducing a new type of message validation with RLN, the question of the future of the network and parameters choice arises. I argue that it is unlikely or unrealistic to expect any one set of parameters for the Network (msg/seconds, max msg size) to be satisfying for all apps wishing to build with Waku. This can already be witnessed with the usage of static sharding, i.e., their own network, by Status Communities.
The current parameters of The Waku Network have been chosen to enable low bandwidth usage of relay nodes running on one shard. Low bandwidth usage means a low barrier of entry, enabling the network to be as decentralized as it can be.
These parameters are subject to change, as we validate assumptions and deliver RLN-v2 and v3 to enable a more flexible rate limit.
Use Cases
Ad Hoc Networks
The creation of small ad hoc networks to enable low-latency use cases has been proposed from the early days. Now, it would be possible to leverage The Waku Network (TWN) to implement this in a dynamic manner. Using TWN as a signal network for negotiation and handshake. Another use case of such ad hoc network would be to enable high bandwidth transfer between nodes. Note that such network could, but does not have to, use libp2p-gossipsub and Waku Relay. It could also implement its own libp2p protocol or leverage the existing Waku req-res protocols. The parameters to form such a network can be hardcoded or exchanged over TWN.
If such a network were to use Waku protocols, one could see that the message validation rules would need to be different depending on the use case and application. It may be a case that RLN is still being used, possibly with different parameters, valid messages could be much bigger or specific payload format needs to be applied.
The usage of The Waku Network for the handshake would enable an application to still benefit from privacy, permissionless participation and auto-scaling properties. Even more so as a marketplace for node operators and consumers grows from the delivery of incentivization protocols.
Waku Store
As we are progressing on Waku Store incentivization the value of messages and anti-spam measures become relevant. RLN prevents the network from being flooded with messages, ensuring that bandwidth usage is capped to not boot off nodes with lower capacity. However, in the case of Waku Store incentivization (and other request-response protocols), the question of whether a message is valid from an application point of view matters. If possible, an operator would rather store and serve only messages useful to users. Same for users who would rather to save bandwidth and only download valid messages. Validity in this context is defined per application. To preserve privacy property, zero-knowledge proofing may remain the best option. For example, RLN with different parameters (merkle tree only for application users).
Until store incentivization is in place, we are likely to continue observing projects running their own Waku nodes. We need to encourage these nodes to be run on TWN, so the network can grow to realize the property of privacy, censorship-resistant, and auto-scaling and be a ripe to become a marketplace. Thanks to RLN Relay, bandwidth usage is capped and hence predictable. Now we are validating whether projects are keen to join The Waku Network for its upsides. Yet, resistance is expected in terms of storing and servicing messages to users from other applications. Enabling project operators to only serve messages for their users seems a necessity at this current point.
This is yet another form message validation. The naive version being a content topic format check: does application-name matches my application’s?
More advanced validation will be necessary to avoid namespace conflicts or deliberate spam.
Validation by Plugin
The need for a customizable message validation function arise from the use cases presented above. It also emerged from the fact that the early version of Status Communities will use a different spam protection protocol than RLN.
To enable custom message validation logic, we would need to provide an API that node operators and application developers can use to define valid messages.
Validation strategy peer discovery is the first challenge raised by such a feature. How does a user find a node that runs the same validation rule set. ie, plugin, as them?
User Experience would be impacted by a hit-and-miss strategy in a larger network if one cannot find a store or filter node that implements the same validation strategy. Implementing such a strategy at Waku Relay or gossipsub level is likely to lead to network unreliability, as nodes with a different validation strategy may de-score and disconnect from each other. Further research would be needed to understand how this can work.
Plugin Marketplace
When only considering request-response protocols, one can see how a plugin marketplace can emerge to enable more efficient usage of resources.
At first, we can expect projects to run their own nodes with their plugins. As more application-independent operators join, they are likely to run those plugins too. When looking at their own traffic and revenue, they are incentivized to take the time to set up the plugin for their biggest users (i.e. application) to ensure they remain competitive in terms of message quality.
On the other hand, applications developers are also likely to lobby the operator to run their plugin, to improve user experience and also prevent namespace conflict or squatting: if two applications use the same namespace, the one that convinced the most operators to run their plugin will have the best user experience.
Such a marketplace would be community-driven. There is no need for the Waku core team to intervene here, as long as the protocol and technology permit such diversity in message validation.
Network Competition
If and when it is possible to apply a similar concept at the Waku Relay level, then the competition between applications and operators can become a competition of Waku networks.
The most popular Relay message validations, or plugins, can now compete with each other; operators and application developers will select the most attractive rule set for their use case or revenue. The parameters do not need to be set by the Waku core team; parameter selection can be handed over to the laws of the market.
The need for a single, common, shared, default Waku Network remains likely. To onboard new developers, serve as a signal network, or potentially be the largest and hence most censorship-resistant network. If an alternative network raises and gets more used, then it may, and its rule set, need to become the default network.
While here we only address message validation parameters, we can also see how alternative Waku networks may be needed for specific use cases. As mentioned for ad hoc networks, an alternative routing system to gossipsub could be a possibility.
Prioritisation
The vision defined involves engineering and research challenges to overcome. Prioritization of the work needs to take into consideration:
- Short term: The need to push for network growth and adoption
- Long term: Network evolution a.k.a. migration strategy a.k.a. change management
When considering long-term requirements, it is important to look into ossification and how the network can evolve. Specific decisions made now may impede the ability to successfully deploy new feature or protocols at a later stage. Thus, ossifying the network. Are the gains from a new feature outweighing the cost of migration?
For example, privacy and anonymity are properties that are difficult to introduce later: Those properties only work when a majority of users contribute. On the Internet, anonymity is actually k-anonymity: the ability to act within a pool large enough so that individuals from this pool cannot be identified by their actions.
When privacy is optional, and not by default, then it fails. Such properties need to be opted in by a majority of users to be efficace. Introducing this property at a later stage or as an opt-in creates a risk that they never realize, simply because users do not care about privacy.
In terms of short-term requirements, functionality should be preferred over flexibility. Waku’s code is open source, but nobody will fork it if it’s useless. Ensuring that the technology is validated and functional is the priority. As we demonstrate a working network with given parameters, then can we make it easier for users to tune in or fork the network.
Good defaults are important for onboarding and first contact with the technology. It should just work out of the box. Once one is familiar with Waku, then can they tune in parameters and would they need more flexibility.
Our role is to identify what steps on the roadmap can be extracted and bring value in themselves, so they can be done first.
In the case of message validation, good defaults as defined in RFC 64 are what is needed first to validate assumptions and build a functional network. As this network realizes, we can provide more flexibility to operators and developers.
Concretely, it means that first, as we are today, no flexibility is provided because we need to validate our assumptions that the Waku Network as defined in RFC 64 is functioning.
As we onboard applications on the network, we can see a need for them to have a naive form of message validation: select the content topic their store nodes serve. In the first form, the application developer may need to hardcode an entry to their store node as domain or content topic discovery is not yet available.
As the network grows and consolidates, we will need to design and validate discovery protocols beyond shard and capability.
Another track is enabling high bandwidth and low latency usage of Waku by demonstrating how to use The Waku Network as a signal network to dynamically negotiate small group node connectivity. This, of course, comes with anonymity downsides and needs to be properly investigated and documented.
Only once we confirm reliable connectivity with an extended discovery protocol, can we look into the possibility of enabling competing Waku networks with their own rules, i.e., custom validation at the gossipsub level.
Risks
Core Principles
The principal risk with enabling custom validation rules, beyond the technical challenges, is the possible loss of Waku’s core principles. What if the dominant network is a surveillance, metadata harvesting network that does not provide privacy nor censorship resistance?
At this point in time, we may not have all the information to properly evaluate the risk. This is why an incremental approach is needed, to experiment, learn and validate at each step.
Moreover, it is also why privacy should be baked into the core of Waku, and the impact on user experience must be at the forefront of our minds. An alternative network with better UX will always be preferred by users.
Ossification
One of the risk is that by introducing flexiblity too late in the lifecycle, then we may ossify Waku in an undesirable form. Let’s review what it means practically.
A concrete example would be to leave privacy and censorship-resistance for later.
If a migration or protocol upgrade is needed to introduce it, and said upgrade brings no other value then there is a risk for it to never be adopted.
A counter-example would be an upgrade that has a financial incentive. For example, if node store all messages of the shard, and the ability to store only valid messages using a plugin is introduced, then we are likely to see adoption because operators would want to save disk space costs.
Sustainability
Another risk is around sustainability. The question on how can Waku development remain sustainable in the long-term remains open.
if sustainability were to come from revenue by the usage of a specific network or smart contract, then the ability for another party to spin up their own could risk the sustainability of Waku development.
This hypothetical scenarion may be worrying, but good in principle. It opens Waku development to competition, making Waku even more decentralized.
Conclusion
To create a truly decentralized network, then said network is unlikely to be unique. The definition of the Waku Network is likely to change over time, and competition of networks should most likely be enabled and encouraged.
However, there is still work to design, validate, and harden fundamental protocols (RLN, discovery & bootstrapping, incentivization). Our focus needs to be on creating a functional network first.
Having said that, we have identified concrete steps we can take towards this vision that would add value to Waku today: message validation plugin for req-res protocols and ad hoc network formed via negotiation over The Waku Network.
edit: improved risk section