# The Waku Network

Note:
Hey everyone,
I will be talking today about the Waku Network, or public WN.
Talk may be a bit less technical than others, but I'm hoping this gives you an idea of what the Waku Research team has been working on and our roadmap ahead.
Most of it is under this banner of "the Waku Network", which may be confusing to some people, since we already have a Waku Network (in fact multiple), so hopefully this provides some necessary context.

---

## Programme

- Waku: the original vision
- Waku: what do we have?
- The Waku Network
- What's next?

Note:
We'll start just with a little bit of history to understand the original vision for Waku and the road to get to the status quo and why we believe this Waku Network effort is necessary.
Then I'll go into some detail as to each feature we're bringing together in TWN, when we plan to launch and our longer term plans.

---

## Waku: the original vision

https://vac.dev/rlog/waku-v2-plan (Jul 2020)

- replacement for Whisper/Waku v1
- reduce amplification factors
- more user-run nodes:
- less reliance on Status infra
- incentivisation
- resource-restricted nodes (topic interest)
- DoS protection
- privacy-preservation

Note:
Back in Jul 2020 Oskar wrote up the first plan for "Waku v2" that sets out the original intention.
Note that we've since stopped referring to Waku v2 and just to "Waku" as Waku v1 is not currently used anymore and the v2 seems to confuse people.
We only refer to v1 and v2 when explicitly contrasting current Waku with its predecessor.
Well, Waku v2 was mainly aimed at addressing some fundamental limitations in Waku v1 (our fork of Whisper protocol, with some minor improvements).
Most immediately to reduce amplification factors to allow for better scalability.
Amplification factor here, basically just implies that nodes participating in the network infrastructure would use a very high amount of bandwidth which increases dramatically with network growth, which effectively limits the size to which the network can grow.
Even worse this practically meant that the network was almost exclusively reliant on Status infrastructure, with all app users essentially being light clients leeching off this centralised service nodes provided by Status.
By reducing amplification factors, you make it theoretically feasible for users to run their own nodes, thereby dramatically increasing censorship resistance and real decentralisation.
Incentivisation, finding a way to make it profitable or desirable for user-run nodes, was mentioned from the very beginning.
This original vision also included features to allow resource-restricted devices to use the network, similar to topic interest that was introduced for Waku v1.
DoS protection was underspecified in this first post, though it mentions the idea to derive some properties from Waku v1 and use a system of peer scoring to maintain some level of DoS protection. RLN for DoS protection however became a major focus within the first couple of months, as it became clear that we'll need its sophistication to provide spam protection on the network layer without violating privacy preservation.
privacy-preservation itself is assumed as a goal for each of these features.

---

## Waku: the original vision

A public p2p messaging layer with:
- shared infrastructure
- scalability
- user-run nodes
- spam protection
- resource-restricted protocols

Note:

So, although Waku's original vision was mostly to address immediate needs for Status, the cohesive vision here was therefore to create a single public p2p network,
- that is shared by multiple applications sharing the same public infrastructure
- that keeps amplification factors low to achieve scalability
- focuses a lot on user-run nodes
- provides decent spam protection
- and defines capabilities and protocols suitable for resource-restricted devices

all of this in a privacy-preserving manner.

So I think it's useful to look at Waku has ended up building for each of these separate goals.

---

## Waku: shared infrastructure

- shared routing layer
- Waku Relay protocol
- common gossipsub (pubsub) topics
- default network -> default pubsub topic
- distributed service protocols, e.g. store

Note:

Firstly, let's look at shared infrastructure, that is Waku as a generalized network used by multiple applications.
Note that the reason to want to share resources with other applications is at least twofold:
- sharing infrastructure, rather than setting up infra belonging only to your own application, allows everyone to benefit from robustness and censorship resistance this bring
- you achieve much better k-anonymity, by having your app traffic mixed in with other apps (and no way to link specific app messages to specific peers/nodes)
So the way to share infrastructure in Waku comes down to sharing the routing layer in Waku Relay. Waku Relay is our main routing protocol, that is built on libp2p gossipsub and each shared routing layer here is identified by a common gossipsub topic.
This functions as the definition of which nodes participate in routing your messages in a publish-subscribe model. For that reason we internally refer to these as pubsub topics.
We mainly achieved this shared public network by defining what we called the default pubsub topic - a topic that all Waku nodes will subscribe to by default and that all applications will use by default if they don't configure their applications differently. This means that all nodes will route all the traffic for all applications by default on the network, with some level of anonymity guaranteed.
We also defined some service protocols which would allow user-run nodes to provide services that in Waku v1/Whisper would generally only be provided by Status, such as Store protocol for storing/retrieving historical messages, adding another way to share infrastructure publically.

---

## Waku: scalability

- libp2p gossipsub lowers amplification factors
- scaling by sharding:
- multiple pubsub topics
- manual process
- sharding and discovery

Note:

In terms of scalability our first step was to reduce amplification factors significantly by switching from Whisper/devp2p to libp2p's gossipsub as main routing protocol.
Although this keeps amplification factors in check, the unit defining the amount of traffic a node participating in the network will have to see/route is the pubsub topic(s) that node is subscribed to. If too many applications publish to that pubsub topic, there's not much you can do and you'd have to start redirecting some applications to use a different pubsub topic. So we started introducing multiple topics, beside the default pubsub topic and informed applications about it so they can start using it with slightly less bandwidth requirements.
However, this is more than a bit manual and there's no built-in way to trigger this transition or to find other peers sharing this same infrastructure/pubsub topic.
So we soon started with a much more integrated sharding strategy that was also integrated into how we discover peers. This will be an important part when we get to the meat of the Waku Network discussion.

---

## Waku: user-run nodes

- node operator programme
- intrinsic incentivisation (tit for tat)
- service incentivisation plans

Note:
In terms of user-run nodes, we launched a node operator programme, Waku is integrated in DappNode and we really tapped into the intrinsic incentivisation properties of Waku here,
although we set up a roadmap for incentivising service provisioning to the network which is now gaining significant traction again.

---

## Waku: spam protection

- very vulnerable routing layer
- no app-specific validation
- privacy-preservation (no blacklists)
- intense work on Rate-Limiting Nullifiers

Note:

However, much more important to highlight here, is to note how quickly spam/DoS protection became a major concern for Waku. If you have this shared public network on the default pubsub topic, anyone can essentially join and publish at an unsustainable rate, making this routing layer very vulnerable to attacks.

How an app can usually protect itself from DoS attacks would be to validate that the messages it sees really belong to that app, maybe that it originated with an authorised user, etc. However, on the routing layer here, the infra is public and shared with all other apps, with no access to your app-specific validation rules.

Furthermore, since Waku is privacy-preserving, messages are not linked to an origin, making it very hard to identify and blacklist/exclude bad actors.

Most of Waku's offering for spam protection therefore went into the effort to develop RLN, which uses a zero-knowledge proof system and membership mechanism to prevent high-rate publishing to the network. Much more on this later.

---

## Waku: resource-restricted protocols

- filter (several versions)
- lightpush
- Waku peer-exchange
- js-waku and other client libraries

Note:

Another goal was to provide protocols suitable for resource-restricted devices. Here we did develop several protocols, although production focus was much more on relay as main routing protocol. Redoubled efforts to productionise these protocols has really occurred within the last few months, especially for Status Community scaling.

---

## Waku Status Quo: the default network

- scaled manually by adding more named shards
- not DoS-protected
- high bandwidth usage
- centralised infra (especially Store)

Note:

So, the important takeway here is to take a look at what Waku looks like today. What did we end up having?

We do have a shared public network, still defined by this default pubsub topic, although we can scale this manually by configuring more shards/pubsub topics.
Resource are shared, but there is no base layer DoS protection in the network, which is a vulnerability making it mostly only useful for experimental use cases.
This however does still provide value for multiple applications and we see a fairly high bandwidth usage.
Although anyone can in theory provide services in this network, in practice our own fleets/centralised infra still plays a crucial role to store historical messages, bootstrapping connection to the network etc.

---

## Waku Status Quo: "private" networks

- applications define own shards
- no shared resources
- loss of anonymity, censorship-resistance
- Waku: easy toolset for building on libp2p
- DoS protection quite easy
- XMTP and WalletConnect

Note:
Now, partly because of the limitations of the default network, we have seen the development of what I would call "private" Waku networks. These are usually still publically available, but they're private in that they don't share resources or shards with any other application. Applications define their own pubsub topics or shards. In other words, these are separate Waku networks belonging only to a single application.
This means they lose a lot of the anonymity and censorship resistance features that comes with a shared public p2p network.
Seen like this, Waku becomes an easy toolset to build bespoke p2p networks on libp2p (which we absolutely also aim to be).
I mean, this use case will always be attractive to some applications, even if it has disadvantages.
The big advantage here is that it's much easier to think about security and DoS protection within an application-bounded environment. Applications can simply validate that all messages being routed in the network really do belong to them and so protect their networks, or statically configure the network to only contain the nodes they already trust.
Examples of projects that have applied Waku in this way would be XMTP and WalletConnect.

---

## Waku Status Quo: static sharding

- special type of private network
- single shard per Community (or app)
- manual configuration
- integrated into discovery
- DoS protection
- application signatures
- sender/receiver unlinkability
- centralisation
- Status Community scaling (10-100 communities, 10K users)

Note:
Still, when at the beginning of this year the Status Community feature had very ambitious scaling targets, we set out to provide an interim strategy that allows simple scaling with DoS protection using a more systematic approach of creating a type of "private" network.
For that we introduced "static" sharding to emphasise the fact that this requires a manual, static configuration for applications (or in this case Status Communities) to each use their own shard and set up their own resources not shared by anyone else.
Note that this is an integrated strategy that also works with our various discovery methods - it should be possible to discover peers for the shards you are interested, so we have this information encoded now into discv5, rendezvous and other discovery options.
The main advantage here is that DoS protection becomes much easier in that the application can attach a verifiable signature to each authorised message and simply drop invalid messages as soon as they enter the network.
Note that although anonymity is much reduced, there is still no linkability on the Waku layer between a message and its origin.
Signature belongs to entire application, so is not linked to specific originator (you don't know who sent/received the message),
but it will be clear that the message belong to the specific application/community.
The anonymity set is therefore much reduced.
Another disadvantage here, is that this introduces a lot of logical and physical centralisation: for now, services are still either provided by Status or linked to a specific community rather than being a feature belonging to the general network.
Since you use application signatures there is a central authority that generates and distributes this key, the network is tied to the lifetime of the devices belonging to that specific application or community, etc.
Still, despite these tradeoffs, implementing this has been a massive effort to get us to a point where Status Communities can scale to 10s of 1000s or potentially million or more users. We calculate that each shard can accommodate up to 10K community users, and you can duplicate this to 10-100 communities to reach much bigger overall Status Community user numbers.

---

## Waku Status Quo: RLN spam protection

- multiple testnets
- experimental until recently
- uncertainty around tokenomics

Note:

- In parallel, though, to this simplified model, we've been making huge advances in RLN for spam protection and to get this to the point of production readiness.
- we've run multiple testnets to prove the concept
- however, these were never integrated into any of the shared topics as it remained an experimental feature until recently
- with some uncertainty around the exact tokenomics of staking and slashing until recently.

---

## Waku Status Quo: summary

A single public p2p messaging network with privacy-preserving:
- shared infrastructure
- not really useful for serious use cases
- multiple private networks
- scalability
- manual configuration, manual sharding (named or static)
- user-run nodes
- only intrinsic incentivisation/altruistic
- spam protection
- RLN experimental
- DoS protection only for private networks
- resource-restricted protocols
- works, but requires manual configuration
- no service discovery, etc.

---

## Waku Network: why?

- builds on:
- scaling effort
- productionisation of RLN and other protocols
- new cohesive vision of public p2p network
- tradeoffs: clear roadmap out
- DoS Protection in base layer
- useful abstractions for applications
- default services
- encoded scaling

Note:

So given our original vision,
great advances that we've made during the Status Community scaling efforts to develop important concepts such as sharding
and parallel advances we were making in RLN from an experimental DoS protection POC to something productionisable,
we asked ourselves
how can we combine all of these protocols and ideas into a cohesive whole
to get the minimum feature set necessary to create
a viable public and shared Waku network that is scalable,
reasonably secure and honest about trade-offs.
This is what we now term as "the Waku Network" effort, not because there is no existing Waku Network, but that we have defined the minimum feature set necessary for such a network to work in practice.
And where we make tradeoffs have a clear roadmap for each item to understand how we can improve on that in future.
This network must provide out-of-the-box DoS Protection in the base routing layer
It should also consider useful abstractions for applications, removing the need for them to have to reason about routing decisions, or think about scalability.
We want to specify here a slightly opinionated default use of protocols and service configuration in the network.
And scaling should be encoded into the network specification. That is, it should not be a manual ad-hoc process, but the underlying sharding strategy should emerge from network growth in a predictable and natural way.

Now, although this is quite an intense effort, in many ways the Waku Network does not necessarily introduce drastically new concepts, just productionising existing concepts and being rigorous in how we envision all the moving parts we've developed function in a unified way.

---

## Waku Network: what?

- multiple shards
- reasonable Waku usage (dimensioning)
- autosharding
- basic DoS protection with RLN
- limited free bandwidth
- default service provisioning, light clients

Note:
So for the rest of this talk I'll be discussing the most important features of the Waku Network. Note that these are in a sense the minimum feature set to launch a useful network. We have already defined roadmaps and improvements extending beyond these limited features.
?
?
?

---

## Waku Network: multiple shards

- 8 predefined shards (pubsub topics)
- abstract routing away from applications
- cluster ID and shard number
- encoded into discovery methods
- possibility of generations (releasing new shards)

/waku/2/rs/1/0
/waku/2/rs/1/1
...
/waku/2/rs/1/7

Note:
Firstly, to achieve scalability, the WN should define multiple shards from the beginning and specify how the number of shards will increase in future as the network scales.
For the first generation of the network we define 8 shards.
Since in gossipsub each shard maps to a different pubsub topic, we abstract the construction of the pubsub topic away from applications to be handled by the underlying Waku nodes. An app should preferably not have to think about the underlying routing at all.
Each shard is identified by a number
and they are grouped in clusters each with its own ID as well.
All shards for TWN will be given a cluster ID of 1.
One way to think of this cluster ID is similar to how the network ID concept works for Ethereum.
So the same shard numbers may exist in a different cluster ID, which could for example define a test network (which is not a fleshed out concept, but this approach allows us to have main networks and test networks in a systematic way).
These shard and cluster numbers are encoded into the various discovery methods so that peers servicing the same network shards can choose to connect only to each other and filter for other shard peers.
Although underdefined for now, we do have a rough generational concept here. In other words, if the number of shards in the network should be increased, these can be rolled out in subsequent network generations. Note though that this is not a process where we have any control over the rollout or usage of new shards to the network. This is simply a specification into the specs and default configuration in our client nodes (which is another way of saying polite suggestion).
The resulting pubsub topics encoding the Waku Network shards looks something like...

so you can think of these eight pubsub topics as the definition of the Waku Network.

---

## Waku Network: dimensioning

- max message size: 150KB
- maximum latency
- mandatory timestamps
- maximum publish rate: 1 message/second
- limited "free" bandwidth up to 1 Mbps
- soon: max daily allocation

Note:
Now in order to use TWN in a reasonable way and use Waku in a shared public network,
we do dimension the network to dictate for what type of application it's useful and for which it's not.
This was also born out of lessons we've learned helping existing applications use Waku for communication.
Firstly, in the public Waku Network, we've set max message sizes to 150KB. This is large enough for proper coordination use cases, but means that large files shouldn't be transferred over TWN. For this you'd probably want to use a distrib. storage provider with content indexes transferred over Waku.
We've also introduced a maximum latency for relayed messages (implemented as maximum age for messages to be relayed) to ensure that this is a real-time communications network.
To do this, originator timestamps are mandatory in the Waku Network, something which is optional for a Waku Message in other networks. To prevent timing attacks, this timestamp can be very approximate - as long as it fits in the 20s window we allow for deviating clocks.
Most importantly, we've introduced a maximum rate at which messages can be published (1 message/second) using RLN, which I'll discuss next. This is our main DoS protection offering.
One slightly controversial feature we're considering is to allow some free bandwidth on the network, for messages not being checked against this maximum rate (which we enforce with RLN), as long as the network is underutilised. The idea is that messages without RLN proofs will be relayed until the network reaches this capacity, after which only properly formed messages with RLN proofs will be allowed.
We also aim to set a daily allocation of messages per publisher which will allow us to better predict bandwidth utilisation in the network and give flexibility in how this is spent. Note that this is not implemented yet, but based on simulations Alvaro has done, we believe that around 300 message per day will be a good allocation for an average use case

---

## Waku Network: autosharding

- content topic vs pubsub topic
- content topic: app concern
- pubsub topic: (usually) not app concern
- abstraction for applications
- applications use API without shard
- Waku selects shard based on content topic hash
- no fundamental protocol changes (for now)

Note:
Autosharding is a feature that ended up being much less extensive than we initially imagined it might be, although it will still provide a lot of value for certain applications.
This comes down to the difference between content topics and pubsub topics.
Content topics in Waku are arbitrary strings that applications choose to mark their traffic within the Waku Network. For example, they can use this to filter for only their own traffic within the shared network. It is a content identifier and belongs to the application.
Pubsub topics, on the other hand, are the underlying gossipsub publish-subscribe topics that define how messages are routed in the network. These are shared between applications and is how we define the 8 shards for TWN (in 8 pubsub topics).
Applications can generally craft content topics as they do have insight into the content they're publishing. However, applications often do not know or care about routing decisions, in other words to which shard (or pubsub topic) they publish their messages, as long as the message gets reliably relayed, can be viewed by other members of the same application, etc.
Autosharding provides an abstraction (or API) for applications to publish a message and for the underlying Waku node to choose the shard which to publish these messages to on behalf of the application by simply hashing the content topic.
For now, though this feature does not affect any of the Waku protocols fundamentally and simply provides a convenient API for applications to use if they cannot reason about routing. However, manually selecting and configuring destination shards for your application is still possible.

---

## Waku Network: RLN spam protection

- membership
- rate-limiting (messages/second, messages/day)
- no staking*
- gossipsub scoring (no slashing)

\*except possibly to make memberships more expensive

Note:
I think the main offering of TWN is that we will launch this with a productionised RLN to protect the base routing layer against spam/DoS attacks.
We've somewhat stripped down the parts of RLN that is either not fully productionised yet or requires more complex reasoning in order to find the essential core that is ready to provide us with reasonable DoS protection and do so as a non-experimental, production feature.
The default protection here is to use RLN:
- to have membership-only publishing in the network: realised by publishers having to register a membership in some contract on Ethereum (Sepolia testnet for now)
- maximum rate limit of publishing to the network: realised by attaching a ZK proof to every published message that proves you are not exceeding rate of 1 message per second
This is how we can enforce the 1 message per 1 second limit I explained earlier. With the new version of RLN which is being integrated as we speak, we could also dimension this with a max allocation per day which can then be spent by each publisher as they wish (e.g. 300 messages per day)
The parts of RLN that we are not including in order to simplify what we productionised is:
- staking - for now registering a membership only costs as much as that transaction. We are considering adding staking to membership registrations in order to avoid abuse and make it a little bit more expensive to register the membership.
- However these funds and your membership won't in the current iteration be slashed. Instead we use gossipsub scoring to descore peers that forward spam in the network. If you get descored in Waku Relay you will eventually lose your connectivity to the network. This incentivises nodes to validate RLN proofs, that is to verify that they do not forward spam messages, regardless of the message's origin.

As I've mentioned, productionised RLN is the great innovation which we want to prove with TWN. In the last couple of weeks, great progress to show that this is feasible in production network. Alvaro key benchmarks...

---

## Waku Network: RLN Key Benchmarks

---

## Waku Network: default services

- store
- lightpush
- filter
- peer-exchange

Note:
One last point about TWN features is that we want to enable sensible default services in the network. These can of course be configurable by individual node operators, but we aim to have better availability of the service network, i.e. availability of Waku services especially for resource-restricted nodes, in TWN.
These protocols, store, lightpush, filter and peer-exchange, have seen great advances and we're still working quite intensely on these to have them be an integral part of TWN.

---

## Waku Network: when?

- internal CCs: within the next few weeks
- announce at Devconnect Istanbul (RLN sepolia contract)
- launch December 2023 (RLN mainnet contract)
- follow: https://github.com/waku-org/research/issues/3

Note:
So, people might ask when this network will be launched and ready to be used by applications.
Well, the main features: namely the underlying shards and production RLN is ready to be launched for internal CC use within the next couple of weeks. At this stage not all APIs will be ready for applications to build easily on TWN, but we will be able to start dogfooding the backbone of the network and start supporting the network with our own nodes.
Then the date that we're really targeting for a wider announcement is Devconnect in Istanbul in November. At this point we want to launch a network with a limited feature set to invite applications to start experimenting with building on TWN. We haven't finalised how the membership contract will look at this point, but it may still be an RLN contract deployed to Sepolia but with ability for apps to register a membership and start using the network.
Then our final target for the MVP network is a launch date end of this year, end-Dec 2023, with mainnet RLN contract, critical APIs, toolsets, client features, peer management, etc. in place.

what may be outstanding at devconnect: some convenience APIs, toolsets, client features, peer management.

---

## Waku Network: what next?

- RLNv2
- Peer and connection management
- Store protocol changes: synchronisation, message reliability
- Incentivisation
- RLN with slashing

Note:
At this stage, most of the Waku subteams are involved with ensuring that this vision gets serviced, protocols get properly dogfooded and productionised and that our three client implementations can behave maturely in the production network, especially when it comes to RLN proof generation and validation.
It's worth mentioning that we've tried to focus our efforts here on an MVP, where we can already identify and have started efforts in parallel to improve on this vision. We're already thinking beyond this MVP.
For example, I've already mentioned RLNv2 that will provide us with ability to set message allocation per user. The work here has progressed quite far. Afaik the circuits here are production ready, integration into our library, zerokit, is underway and then it's only a matter of integration into the Waku implementations.
Peer and connection management becomes more complicated with more shards and capabilities (a matrix of capabilities). Forced to make some simplifying assumptions for now.
We've also started a significant review and upgrade of the store protocol itself. It's a very naive history query protocol currently, but we believe it can be transformed into a protocol to synchronise between store nodes and in fact add a new layer of reliable delivery to the network.
We have a new hire in the research team that's picked up the incentivisation effort again, to ensure that we now build solid model for incentivised behaviour in the network.
Somewhat related to that, I think we may want to start thinking about RLN slashing again and at which point it may play a role in the network and the tokenomics around it.

---

# Q&A

---

___