Skip to main content

# Introducing nwaku

April 12, 2022
by
Hanno Cornelius
11 min read

Introducing nwaku, a Nim-based Waku v2 client, including a summary of recent developments and preview of current and future focus areas.

## Background​

If you've been following our research log, you'll know that many things have happened in the world of Waku v2 since our last general update. In line with our long term goals, we've introduced new protocols, tweaked our existing protocols and expanded our team. We've also shown in a series of practical experiments that Waku v2 does indeed deliver on some of the theoretical advantages it was designed to have over its predecessor, Waku v1. A sustainability and business workshop led to the formulation of a clearer vision for Vac as a team.

From the beginning, our protocol development has been complemented by various client implementations of these protocols, first in Nim, but later also in JavaScript and Go. A follow-up post will clarify the purposes, similarities and differences between these three clients. The Nim client, is our reference implementation, developed by the research team in parallel with the specs and building on a home-grown implementation of `libp2p`. The Nim client is suitable to run as a standalone adaptive node, managed by individual operators or as an encapsulated service node in other applications. This post looks at some recent developments within the Nim client.

## 1. nim-waku is now known as nwaku ​

Pronounced NWHA-koo. You may already have seen us refer to "`nwaku`" on Vac communication channels, but it is now official: The `nim-waku` Waku v2 client has been named `nwaku`. Why? Well, we needed a recognizable name for our client that could easily be referred to in everyday conversations and `nim-waku` just didn't roll off the tongue. We've followed the example of the closely related `nimbus` project to find a punchier name that explicitly links the client to both the Waku set of protocols and the Nim language.

## 2. Improvements in stability and performance​

The initial implementation of Waku v2 demonstrated how the suite of protocols can be applied to form a generalized, peer-to-peer messaging network, while addressing a wide range of adaptive requirements. This allowed us to lift several protocol specifications from `raw` to `draft` status, indicating that a reference implementation exists for each. However, as internal dogfooding increased and more external applications started using `nwaku`, we stepped up our focus on the client's stability and performance. This is especially true where we want `nwaku` to run unsupervised in a production environment without any degradation in the services it provides.

Some of the more significant productionization efforts over the last couple of months included:

1. Reworking the `store` implementation to maintain stable memory usage while storing historical messages and serving multiple clients querying history simultaneously. Previously, a `store` node would see gradual service degradation due to inefficient memory usage when responding to history queries. Queries that often took longer than 8 mins now complete in under 100 ms.

2. Improved peer management. For example, `filter` nodes will now remove unreachable clients after a number of connection failures, whereas they would previously keep accumulating dead peers.

3. Improved disk usage. `nwaku` nodes that persist historical messages on disk now manage their own storage size based on the `--store-capacity`. This can significantly improve node start-up times.

More stability issues may be addressed in future as `nwaku` matures, but we've noticed a marked improvement in the reliability of running `nwaku` nodes. These include environments where `nwaku` nodes are expected to run with a long uptime. Vac currently operates two long-running fleets of `nwaku` nodes, `wakuv2.prod` and `wakuv2.test`, for internal dogfooding and to serve as experimental bootstrapping nodes. Status has also recently deployed similar fleets for production and testing based on `nwaku`. Our goal is to have `nwaku` be stable, performant and flexible enough to be an attractive option for operators to run and maintain their own Waku v2 nodes. See also the future work section below for more on our general goal of `nwaku` for operators.

## 3. Improvements in interoperability​

We've implemented several features that improve `nwaku`'s usability in different environments and its interoperability with other Waku v2 clients. One major step forward here was adding support for both secure and unsecured WebSocket connections as `libp2p` transports. This allows direct connectivity with `js-waku` and paves the way for native browser usage. We've also added support for parsing and resolving DNS-type `multiaddrs`, i.e. multiaddress protocol schemes `dns`, `dns4`, `dns6` and `dnsaddr`. A `nwaku` node can now also be configured with its own IPv4 DNS domain name allowing dynamic IP address allocation without impacting a node's reachability by its peers.

## 4. Peer discovery​

Peer discovery is the method by which nodes become aware of each other’s existence. The question of peer discovery in a Waku v2 network has been a focus area since the protocol was first conceptualized. Since then several different approaches to discovery have been proposed and investigated. We've implemented three discovery mechanisms in `nwaku` so far:

### DNS-based discovery​

`nwaku` nodes can retrieve an authenticated, updateable list of peers via DNS to bootstrap connection to a Waku v2 network. Our implementation is based on EIP-1459.

### GossipSub peer exchange​

GossipSub Peer Exchange (PX) is a GossipSub v1.1 mechanism whereby a pruning peer may provide a pruned peer with a set of alternative peers where it can connect to reform its mesh. This is a very suitable mechanism to gradually discover more peers from an initial connection to a small set of bootstrap peers. It is enabled in a `nwaku` node by default.

### Waku Node Discovery Protocol v5​

This is a DHT-based discovery mechanism adapted to store and relay node records. Our implementation is based on Ethereum's Discovery v5 protocol with some minor modifications to isolate our discovery network from that of Ethereum. The decision to separate the Waku Discovery v5 network from Ethereum's was made on considerations of lookup efficiency. This comes at a possible tradeoff in network resilience. We are considering merging with the Ethereum Discovery v5 network in future, or even implement a hybrid solution. This post explains the decision and future steps.

## 5. Spam protection using RLN​

An early addition to our suite of protocols was an extension of `11/WAKU-RELAY` that provided spam protection using Rate Limiting Nullifiers (RLN). The `nwaku` client now contains a working demonstration and integration of RLN relay. Check out this tutorial to see the protocol in action using a toy chat application built on `nwaku`. We'd love for people to join us in dogfooding RLN spam protection as part of our operator incentive testnet. Feel free to join our Vac Discord server and head to the `#rln` channel for more information.

## Future work​

As we continue working towards our goal of a fully decentralized, generalized and censorship-resistant messaging protocol, these are some of the current and future focus areas for `nwaku`:

### Reaching out to operators:​

We are starting to push for operators to run and maintain their own Waku v2 nodes, preferably contributing to the default Waku v2 network as described by the default pubsub topic (`/waku/2/default-waku/proto`). Amongst other things, a large fleet of stable operator-run Waku v2 nodes will help secure the network, provide valuable services to a variety of applications and ensure the future sustainability of both Vac as a research organization and the Waku suite of protocols.

We are targeting `nwaku` as the main option for operator-run nodes.
Specifically, we aim to provide through `nwaku`:

1. a lightweight and robust Waku v2 client. This client must be first in line to support innovative and new Waku v2 protocols, but configurable enough to serve the adaptive needs of various operators.
2. an easy-to-follow guide for operators to configure, set up and maintain their own nodes
3. a set of operator-focused tools to monitor and maintain a running node

### Better conversational security layer guarantees​

Conversational security guarantees in Waku v2 are currently designed around the Status application. Developers building their own applications on top of Waku would therefore either have to reimplement a set of tools similar to Status or build their own security solutions on the application layer above Waku. We are working on a set of features built into Waku that will provide the general security properties Waku users may desire and do so in a modern and simple way. This is useful for applications outside of Status that want similar security guarantees. As a first step, we've already made good progress toward integrating noise handshakes as a key exchange mechanism in Waku v2.

### Protocol incentivization​

We want to design incentivization around our protocols to encourage desired behaviors in the Waku network, rewarding nodes providing costly services and punishing adversarial actions. This will increase the overall security of the network and encourage operators to run their own Waku nodes. In turn, the sustainability of Vac as an organization will be better guaranteed. As such, protocol incentivization was a major focus in our recent Vac Sustainability and Business Workshop. Our first step here is to finish integrating RLN relay into Waku with blockchain interaction to manage members, punish spammers and reward spam detectors. After this, we want to design monetary incentivization for providers of `store`, `lightpush` and `filter` services. This may also tie into a reputation mechanism for service nodes based on a network-wide consensus on service quality. A big challenge for protocol incentivization is doing it in a private fashion, so we can keep similar metadata protection guarantees as the Waku base layer. This ties into our focus on Zero Knowledge tech.

### Improved store capacity​

The `nwaku` store currently serves as an efficient in-memory store for historical messages, dimensioned by the maximum number of messages the store node is willing to keep. This makes the `nwaku` store appropriate for keeping history over a short term without any time-based guarantees, but with the advantage of providing fast responses to history queries. Some applications, such as Status, require longer-term historical message storage with time-based dimensioning to guarantee that messages will be stored for a specified minimum period. Because of the relatively high cost of memory compared to disk space, a higher capacity store, with time guarantees, should operate as a disk-only database of historical messages. This is an ongoing effort.

### Multipurpose discovery​

In addition to the three discovery methods already implemented in `nwaku`, we are working on improving discovery on at least three fronts:

#### Capability discovery: ​

Waku v2 nodes may be interested in peers with specific capabilities, for example:

1. peers within a specific pubsub topic mesh,
2. peers with store capability,
3. store peers with x days of history for a specific content topic, etc.

Capability discovery entails mechanisms by which such capabilities can be advertised and discovered/negotiated. One major hurdle to overcome is the increased complexity of finding a node with specific capabilities within the larger network (a needle in a haystack). See the original problem statement for more.

#### Improvements in Discovery v5 ​

Of the implemented discovery methods, Discovery v5 best addresses our need for a decentralized and scalable discovery mechanism. With the basic implementation done, there are some improvements planned for Discovery v5, including methods to increase security such as merging with the Ethereum Discovery v5 network, introducing explicit NAT traversal and utilizing topic advertisement. The Waku v2 Discovery v5 Roadmap contains more details.

#### Generalized peer exchange ​

`nwaku` already implements GossipSub peer exchange. We now need a general request-response mechanism outside of GossipSub by which a node may learn about other Waku v2 nodes by requesting and receiving a list of peers from a neighbor. This could, for example, be a suitable way for resource-restricted devices to request a stronger peer to perform a random Discovery v5 lookup on their behalf or simply to be informed of a subset of the peers known to that neighbor. See this issue for more.

This concludes a general outline of some of the main recent developments in the `nwaku` client and a summary of the current and future focus areas. Much more is happening behind the scenes, of course, so for more information, or to join the conversation, feel free to join our Vac Discord server or to check out the `nwaku` repo on Github. You can also view the changelog for past releases here.

## References​

- 17/WAKU-RLN-RELAY
- 32/RLN
- 33/WAKU2-DISCV5
- Capabilities advertising
- Configuring a domain name
- Conversational security
- Discovery v5 Topic Advertisement
- EIP-1459
- GossipSub Peer Exchange
- go-waku
- js-waku
- `multiaddr` formats
- nimbus-eth2
- nim-libp2p
- nim-waku
- nim-waku releases
- Node Discovery Protocol v5 - Theory
- Noise handshakes
- RLN tutorial
- Vac <3 ZK
- Vac About page
- Vac Research log
- Vac RFC site
- Vac Sustainability and Business Workshop
- Waku Update
- Waku v1 vs Waku v2: Bandwidth Comparison
- Waku v2 Peer Exchange
- Waku v2 Discovery v5 Roadmap
- What's the Plan for Waku v2?

- Background
- 1. nim-waku is now known as nwaku
- 2. Improvements in stability and performance
- 3. Improvements in interoperability
- 4. Peer discovery
  - DNS-based discovery
  - GossipSub peer exchange
  - Waku Node Discovery Protocol v5
- 5. Spam protection using RLN
- Future work
  - Reaching out to operators:
  - Better conversational security layer guarantees
  - Protocol incentivization
  - Improved store capacity
  - Multipurpose discovery
    - Capability discovery:
    - Improvements in Discovery v5
    - Generalized peer exchange
- References