The Waku Roadmap
A comprehensive review of the Waku roadmap for H2 2023
Background on Waku
To understand why Waku exists, you need only to consider the centralised internet. Technology giants can dictate what we see and with whom we can communicate. The centralised platforms we regularly use to communicate have privileged access to outlandish realms of personal data that powerful commercial and political institutions can leverage. In contrast, Waku empowers internet users to circumvent these actions, offering a decentralised, open-source suite of privacy-preserving, peer-to-peer messaging protocols. The protocols are designed to flourish in resource-restricted environments to be accessible to people across the globe and can run on phones, servers, or browsers. Waku can be used for general messaging with humans, machines, or a hybrid situation.
We apply Waku Relay on top of the gossip protocol GossipSub from libp2p to route messages and information with a subset of connected peers, increasing security and privacy. A gossip protocol is a peer-to-peer protocol in which nodes periodically exchange information about themselves and other associated nodes. Currently, it is possible to use the Waku Network and join a public gossipsub network in a permissionless manner. Some projects using Waku that opt to do this include Status Desktop and Mobile, Railgun, and TheGraph.
Achievements in H1 2023
One of the critical limitations of Waku is its reliance on a single GossipSub network for all users, which necessitates that each user relay traffic for all applications. As the adoption of Waku continues to grow, the bandwidth consumption skyrockets. Users with limited bandwidth capabilities are marginalised and unable to participate fully in the Waku Relay network. The key focus of the Waku development team in the first half of this year was to resolve some of these limitations around scaling to support the Status app’s goal of serving one million users.
We met our milestone of providing a Waku network that can scale to approximately ten thousand active users within a Status Community, primarily thanks to implementing static sharding. Instead of having one relay network, we split the Waku Network into several relay (gossipsub) networks so that the end user is not required to relay the traffic of all applications, but rather just the traffic on the same shard. We have also developed opt-in message signing as another stopgap solution to match the Status app timeline and needs. The Community signs the messages with a single key belonging to the entire Community, presenting a more private solution than having individual signatures. This solution set, in addition to protocol and software improvements, should enable the Status team to launch the Status apps with reasonable bandwidth usage.
The manual coordination of shard assignment with static sharding requires the actions of a central entity. While it is still permissionless, and anyone could run a node on any shard, the lack of coordination would deteriorate the user experience. Being able to scale Waku to support one million users on the Status app is dependent on our ability to improve on our H1 deliveries, which we will be stress testing and running through simulations.
The Waku team also deployed basic protections. The Denial of Service (DoS) protections are very light and do not give any guarantees regarding bandwidth usage. Users running a node, such as Status Desktop, will not want it to hog their bandwidth. What was delivered in H1 has caveats in terms of permissionless and relative DOS protection. It is possible to build an application with either properties, but not both. You will find our approach to resolving this in the H2 roadmap below.
You can read more about all of the deliveries in H1 here.
Roadmap milestones in H2 2023
Waku’s core milestone for H2 is launching and bootstrapping Waku Network Gen 0. There are an additional two milestones for 2024 that we have begun working on; those are:
We will be researching and experimenting with nim in 2023 to lay the groundwork for supporting multiple platforms.
This workstream has been initiated this year.
Waku Network Gen 0
The Waku Network Gen 0 builds on H1 2023’s network sharding innovations and uses rate limiting from work done in 2021 and 2022. The goal is to create one permissionless, auto-scalable, DoS protected public network. The auto-sharding protocol automatically allocates messages for an application and does not require a centralised, manual allocator.
Through rate limiting, we will be working to ensure that users (or attackers) cannot flood the network beyond the maximum expected bandwidth usage. We will protect abuse through our RLN DoS protection, capping publishers to 1 message per second. We are also working on a dimensioning mechanism that would give publishers a maximum allocation of messages per day, limiting the maximum size of these messages within the overall network. Individuals can join a group on-chain and prove their membership in each message in a zero-knowledge manner – that is, without revealing which member they are. The number of members in the group is likely to be capped initially to guarantee maximum bandwidth usage by the network, although we will be able to review those when launching subsequent versions.
Running nodes that fully participate in the Waku Relay Network should be encouraged. We aim to do so by optimising the software and making participation permissionless. With such innovations, the community can benefit from more neutral contributions to the network, hence the backbone of a secure, scalable network, and a more extensive set of nodes to get sender and recipient k-anonymity.
It’s important to note that all current and future issues need to be solved while preserving our principles:
- Private
- Modular
- Scalable
- Censorship resistant
- Portable: works on mobile and browser
Development Roadmap tracks
We have organised our research and development work into three tracks:
General Track;
Service Protocols;
DoS protection.
We will review each track in more detail below.
General Track
The foundational work focuses on creating a scalable and auto-sharded Waku Network. Here, we determine specifications, design, and implement strategies based on our research and development that aid in scaling the Waku Network.
You can view the latest progress from the General Track here. Below are the key milestones and associated tasks from this track.
- 1.1: Network requirements and design
- Goal: 22 Sep 2023
- Key Activities:
- Determine network specifications and design.
- 1.2: Auto-sharding for autoscaling
- Goal: 30 Sep 2023
- Key Activities:
- Design and implement auto-sharding strategy.
- Launch a limited number of shards.
- 1.3: Node bandwidth management mechanism
- Goal: 31 Oct 2023
- Key Activities:
- Implement bandwidth management to choose shards based on availability for relay nodes dynamically
- Design predictable bandwidth limits per shard
- 1.4: Peer management and discovery
- Goal: 30 Nov 2023
- Key Activities:
- Design transparent interaction between applications and shards
- Peer management system to track and discover public shared peers
- 1.5: Launch and dogfood integrated public Waku Network MVP
- Goal: 31 Jan 2024
- Key Activities:
- Launch Waku Network MVP
- Gather feedback and improve
Service Protocols
Our focus within Service Protocols is required to upkeep and expand protocols such as filter, lightpush, peer exchange and store within the public network in a decentralised manner. Work within this track also involves ongoing efforts to incentivise our network.
You can view the latest progress from the Service Protocols Track here. Below are the key milestones and associated tasks from this track.
- 2.1: Production testing of existing protocols
- Goal: 30 Nov 2023
- Key Activities:
- Test and improve current service protocols: filter, lightpush, and peer-exchange.
- 2.2: Sharded capability discovery for light protocols
- Goal: 30 Sep 2023
- Key Activities:
- Peer selection mechanism that translates content topics to their underlying shard
- 2.3: Basic distributed store services
- Goal: 30 Nov 2023 (integrate in 2024)
- Key Activities:
- Discover Store nodes for specific content topics and time ranges.
- Service nodes to advertise their store services
- 2.4: Basic design for service incentivisation
- Goal: 31 Dec 2023
- Key Activities:
- Incentivize service provision of the Waku Network
- Tokenomics implementation
DoS Protection
Denial of Service (DoS) mitigation is a challenge within any network. Bandwidth is a scarce resource for the Waku network; DoS protection is about stopping an attacker from flooding the network or for a Waku node to hog all of a user’s bandwidth. This track covers consensus mechanisms such as our rate-limiting designs.
We balance free traffic with a fairly incentivised structure that doesn’t exhaust the overall bandwidth. We must implement measures to ensure the bandwidth usage is feasible for additional protocol-wide DOS protection. We need to assist node operators in maximising the use of their resources and allocate shard support depending on current traffic so that we can assure ongoing service guarantees.
You can view the latest progress from the DoS Protection Track here. Below are the key milestones and associated tasks from this track.
- 3.1: DoS requirements and design
- Goal: 22 Sep 2023
- Key Activities:
- Define DoS/spam protection specifications
- Design initial membership mechanisms
- Free and or paid traffic design
- 3.2: Basic DoS protection in production
- Goal: 31 Oct 2023
- Key Activities:
- Implement and launch the RLN mechanism
- Implement rate limiting
- 3.3: Membership for Status Communities
- Goal: 30 Nov 2023
- Key Activities:
- Design membership assignments for community members
- 3.4: Further memberships
- Goal: 31 Dec 2023
- Key Activities:
- Expanding memberships to third parties
Anticipated risks to delivering our H2 milestones
We have identified several challenges that may impact our ability to deliver on our roadmap milestones.
1. Ongoing structural design changes due to practical implications:
Our network dimensioning on modelling and assumptions may need to be modified when applied in real-world use cases. For example, we have designed the network not to allow more than one message published per second by each publisher. We have set message sizes to a maximum of 150 KB, implemented a 20-second grace period, and divided all traffic among 8 defined network shards. The risk is that, despite our modelling and research, the structural changes might not be helpful for all applications.
We are committed to building in the open and accept that our project management process could be better. This principle of openness is why we are dedicating effort to producing easily digestible content, such as our documentation at docs.waku.org.
2. Interactions between applications and nodes:
Waku Relay is the foundation for building decentralised communications. There is uncertainty on how applications will interact with the underlying nodes to ensure that all app traffic gets routed seamlessly and transparently, all while having a balanced data load throughout eight different routing shards.
3. Navigating Bandwidth Management
Bandwidth in peer-to-peer networks is a luxury that needs to be acutely observed and managed. To maintain a large group of peers hosting nodes, we must be capable of securely managing bandwidth allocation to their nodes.
Become a part of the Waku ecosystem
If you have questions about Waku’s development roadmap or want to join a like-minded community focused on bringing peer-to-peer communications to millions of users, join the Waku Discord or follow us on X.
If the technology speaks to you, check out our open job positions or crack some of our bounties.
You can also help to ensure that we stay decentralised by running your own Waku Node!
To integrate Waku into your application, check the table below for the necessary links. You can always get further support from us on Discord.
Integrate Waku into your application | |
docs | https://docs.waku.org |
nwaku | https://github.com/waku-org/nwaku |
browser (JS/TS) | https://github.com/waku-org/js-waku |
Go | https://github.com/waku-org/go-waku |
Rust | https://github.com/waku-org/waku-rust-bindings |
We look forward to connecting and hearing your feedback on our roadmap.