Permissionless Community Creation

An overview of the foundational requirements of permissionless communities and Waku's research on autosharding to enhance decentralisation, privacy, and scalability.

There is no one-size-fits-all approach to building permissionless communities. Indeed, Waku and other projects are still researching the best ways to enable such communities while retaining decentralisation, privacy protection, and censorship resistance. The following blog post will discuss the fundamental requirements of peer-to-peer systems, analysing the strengths and weaknesses of federated models before delving into Waku's cutting-edge research on autosharding and its potential to enable permissionless communities to scale exponentially.

Fundamentals of peer-to-peer systems

Peer-to-peer decentralised systems have several core components required to function:

• Bootstrapping: a way for a new node to enter the network.

This process typically involves obtaining a list of node addresses, enabling the new node to connect with existing ones. Various approaches to bootstrapping exist, such as hardcoding the list of addresses into the system's code, utilising a dynamic method, or posting the list on a DNS record. Regardless of the method chosen, bootstrapping is essential for enabling new nodes to join the network.

• Peer discovery: a way for nodes in the network to discover other nodes.

Peer discovery mechanisms allow nodes to find and establish connections with peers dynamically. This ensures that the network remains robust and resilient, avoiding bottlenecks that could arise from relying solely on a fixed set of bootstrap nodes. Peer discovery mechanisms vary depending on the specific requirements of the decentralised system but are essential for maintaining the network's integrity and scalability.

• Peer-to-peer transport: a way for two nodes to communicate with each other to execute the demands of the network.

This communication can take various forms, depending on the nature of the decentralised system. For example, in a file-sharing network like BitTorrent, nodes exchange file chunks directly, allowing for efficient transmission of large files. In blockchain networks, nodes communicate by exchanging transactions and blocks, facilitating consensus and maintaining the integrity of the distributed ledger. Peer-to-peer transport could also happen through a broadcast system based on peers congregating around publish-subscribe topics, i.e. a message is published to a topic and broadcast to all peers subscribed to the same topic.

These are the building blocks for any decentralised peer-to-peer network. Decentralisation is not an objective in itself but a way to ensure a system is resilient, permissionless, censorship-resistant, and private. The properties discussed are requirements for such a system's foundation, but additional requirements exist.

Hence, for a chat protocol to be resilient, permissionless, censorship-resistant and private, the three pillars must be implemented: decentralised bootstrapping, decentralised peer discovery, and unmediated peer-to-peer transport. One example of such a system that does this would be the federated system, Matrix.

The federated approach

Federated chat solutions such as Matrix provide the software infrastructure, primarily through clients like Element, enabling any community owner to run or request an operator to run server software. This approach decentralises the hosting of communication servers, allowing for greater autonomy and flexibility within communities. Users connect to specific hosting server instances in the ecosystem to engage with their respective communities. The domain name of the hosting server, such as matrix.org, is included in each user's name, facilitating cross-community and one-to-one chats seamlessly.

With a federated approach, there is a lack of participation and sender anonymity due to the localised centralisation around communication servers. The servers can log users' IP addresses, and observant parties can track user connections to such servers. Since users connect directly to their community servers to send messages, these servers may link IP addresses with message metadata.

Such a topology is also vulnerable to censorship; if a user's home server instance goes offline, they will experience service interruption. Moreover, if authorities seize the domain name, the entire community hosted on that server will be affected.

While federated systems usually have a permissionless approach, anyone is able to run and host server software and each separate instance is a centralised system in itself. This comes with a number of drawbacks in terms of privacy and de-platforming risk both for end users and server administrators.

A strategy can be implemented to enable users to back up their data on an alternative instance, but this usually does not help with privacy and only postpones the issue of censorship resistance. In other words, there is no easy path to solving those problems without changing the entire message routing layer.

Waku's message routing layer

To solve privacy and censorship-resistance issues, Waku uses GossipSub as a message routing protocol.

Nodes in the network connect to each other and forward messages they receive from peers. Contrary to FloodSub, used by Whisper, GossipSub only forwards messages to a small set of nodes (the recommended number of nodes for Waku is four), meaning that while there is some amplification, it is limited to save bandwidth.

As long as the metadata on each message is limited, it becomes difficult for an observer to find the sender of a particular message in this model. Moreover, as all nodes in the GossipSub network receive all messages, the recipient can also benefit from anonymity.

Using static sharding to scale Waku

A common message routing layer does not scale as the nodes receive every message. This could function for up to thousands of users, but beyond this, the bandwidth demand for each node would likely exceed the average household bandwidth. Excluding nodes with lower bandwidth from the network would then impact the decentralisation of the routing network.

Instead of having one relay network, Waku sharding splits the message routing network into several GossipSub topics so that the end user is not required to relay all of the applications' traffic but rather just the subset of traffic on the same shard.

With static sharding, the logic for dispatching messages on the correct shard is naive: a community or application is assigned a shard, and each shard is used by only one application or community. To provide some basic DoS protection, the application or community owner distributes a private key to all members or users, which they use to sign messages.

This enables nodes in the shard to only relay messages from legitimate publishers (i.e. members of the community) while preserving some anonymity properties. Senders cannot be identified by their signatures, as all senders use the same private key.

However, the current implementation of static sharding faces several challenges regarding privacy, censorship resistance and permissionless participation.

Bootstrapping
While passing multiple bootstrap node lists with several FQDNs to a Waku node is possible, further research is needed to enable truly decentralised bootstrapping.

Peer discovery dynamics
Waku leverages discv5 for peer discovery, a decentralised solution that enables privacy and censorship-resistance. However, decentralised discovery of capability, such as finding nodes with specific protocols like store and filter, is an area that needs improvement.

Peer-to-peer transport considerations
The current approach for providing predictable scalability per Status Community is to statically assign an individual shard to each community; no shard would be assigned to multiple communities. This implies a shard assignment process, which poses a hurdle. Overall, Waku's implementation has validated our assumptions that static sharding provides a useful stepping stone to an architecture where communities share shards. The approach includes features such as autosharding, enabling multiple communities to use the same set of shards without needing to consider shard assignments. Additionally, RLN will be implemented to provide DoS protection on the shared shards. It also validates our assumptions about discv5 in the context of shards and capabilities.

Future improvements: Autosharding and RLN

Static sharding on Waku is being rolled out to around 100 communities, with predictable scalability per community. The team is researching several sharding strategies to scale the rollout to more communities by enabling the sharing of shards, including autosharding and rate limit nullifiers (RLN).

Autosharding will help abstract routing and sharding decisions away from communities and applications while providing an easy way for communities to share a bounded number of shards. This will allow the network to maintain a manageable number of shards, ideally under 100. Our research indicates the network can accommodate unlimited communities as long as the total user count remains below 1 million. New research will be necessary to extend discv5 or explore alternative systems for scalability beyond this threshold.

It is important to note that as a new technology, Waku's reliance on RLN introduces some risk. However, the Waku team is committed to hardening RLN and fostering its adoption by other projects and users, thus mitigating this concern over time.

Become a part of the Waku ecosystem

The Waku research team made significant discoveries during their dogfooding of the Wau network. RLN provides DoS protections that do not compromise privacy or censorship resistance and can enable permissionless communities to scale to millions of users.

To integrate Waku into your application, check the table below for the necessary links. You can always get further support from us on Discord.