The Waku Network: Technical Overview and Properties #26
Conversation
|
|
||
| Waku aims to overcome the following challenges: | ||
|
|
||
| - Generalized messaging: Waku aims to provide protocols and a network that enables the transfer of arbitrary payloads. While Waku was originally created for a chat application, Status, the aim is to be generalized enough so that many applications can be built using Waku. |
There was a problem hiding this comment.
to be generalized enough so that many applications can be built using Waku.
to be generalized enough so that any decentralized communication or signalling application can be built on Waku.
| Waku aims to overcome the following challenges: | ||
|
|
||
| - Generalized messaging: Waku aims to provide protocols and a network that enables the transfer of arbitrary payloads. While Waku was originally created for a chat application, Status, the aim is to be generalized enough so that many applications can be built using Waku. | ||
| - Ephemeral messaging: Waku aims to solve the problem of instant communication, where the aim is to provide fair latency to enable one or several users to exchange small data payloads. This is in contrast to IPFS or other decentralized storage systems, which provide a way to store large amounts of data, at the expense of latency and responsiveness. |
There was a problem hiding this comment.
"instant communication" - perhaps "real-time communication" is more accurate? Worried that "instant" just translates to IM in people's minds.
|
|
||
| This helps enable anonymity, privacy, and censorship-resistance. | ||
|
|
||
| Thanks to the protocol serviced being advertised, it enables mobile phones and the browser to find nodes that can service them. |
There was a problem hiding this comment.
| Thanks to the protocol serviced being advertised, it enables mobile phones and the browser to find nodes that can service them. | |
| Thanks to the supported protocols being advertised, it enables mobile phones and the browser to find nodes that can service them. |
Not sure about using "advertise" in this context, as it implies an active component whereas this is more a passive filter-after-discovery aspect. Not a major concern though.
|
|
||
| Similar to Ethereum, Waku uses libp2p-gossipsub. This brings several benefits: | ||
|
|
||
| - improved bandwidth performance in comparison to Whisper: in gossipsub, nodes form a group of neighbors (mesh), to which they send messages. it means that a given node will only attempt to maintain ~20 connections and actively exchange messages with ~4 other nodes. Reducing the number of times each message is uploaded or downloaded. |
There was a problem hiding this comment.
I would not add any connection numbers here (20 is inaccurate and 4 is subject to future changes). The correct way to state the bandwidth performance improvement:
In contrast to the flood-based routing of Whisper, gossipsub will as a rule only exchange messages with a small, stable subset of its peers rather than amplifying each message to all connected peers.
|
|
||
| One can see how this limits scalability: it cannot be expected to traffic the whole traffic of the network from a household internet connection. | ||
|
|
||
| To solve this problem, sharding is used: instead of having one gossipsub network. The Waku network is split into several networks, or shards. |
There was a problem hiding this comment.
Saying the Waku network is split into several networks may confuse readers (and is not quite accurate as many things are common between shards).
Rather: The Waku network is subdivided into several distinct message routing subnetworks, or shards.
|
|
||
| ### Message Routing - RLN Relay | ||
|
|
||
| Waku is generalized, meaning any kind of payload can be transported. Hence, there is no strict definition of “spam”. Whether the message contains a [meme](https://github.com/b4s36t4/waku-meme) or a [zk note for private DeFi](https://railgun.ch/#/), Waku shouldn't even know the content; metadata and data should remain private. |
There was a problem hiding this comment.
"Waku is generalized and privacy-preserving"
We do define spam (as high rate messages). There is no strict definition of "spam content".
| Rate-limiting publishers in a censorship-resistant and private manner is difficult; this is why we are using zero-knowledge technology: | ||
|
|
||
| 1. Users push their RLN credentials to a smart contract (currently on Ethereum Sepolia testnet). | ||
| 2. Nodes watch the contract and include the new membership. |
There was a problem hiding this comment.
Nodes keep track of all registered memberships on the contract.
| 2. Nodes watch the contract and include the new membership. | ||
| 3. When sending a message, the user attaches an RLN proof to the message with the current epoch (timestamp in seconds). | ||
| 4. Nodes can verify the proof, without being able to correlate the user’s Ethereum address (used on the smart contract) with the message being sent, preserving anonymity. | ||
| 5. If a user attempts to send more than 1 msg/s, nodes can detect this and drop the message surplus, or spam, protecting the network. |
There was a problem hiding this comment.
Importantly: and disconnect from peers forwarding spam, thereby isolating the spam origin from the network.
|
|
||
| ### Servicing Mostly-offline and Resource-restricted Devices | ||
|
|
||
| Finally, how is Waku useful to mobile and browsers? |
There was a problem hiding this comment.
resource-restricted devices, such as mobile phones and web browsers?
There was a problem hiding this comment.
"resource-restricted devices, " is such a mouthful I am trying to find a way to alternate a bit to make it easier to read. Thoughts @Amelia7689 ?
|
|
||
| Finally, how is Waku useful to mobile and browsers? | ||
|
|
||
| Waku defines a number of [request-reply protocols](https://rfc.vac.dev/spec/10/#requestreply-domain) to enable such devices to access the Waku network, without having to be always online or consume extensive amounts of bandwidth, i.e., without participating in the Waku Relay network. |
There was a problem hiding this comment.
*request-response (trying to bring some consistency to our terminology across platforms)
There was a problem hiding this comment.
I also prefer "request-response" but our specs says "request-reply": https://rfc.vac.dev/spec/10/#requestreply-domain
Very happy to deprecate "request-reply" I think it sounds weird.
There was a problem hiding this comment.
Yeah, I don't think we've been very consistent, but I'd rather we update RFC 10 to "request-response" (most other RFCs already use "request-response", e.g. Store here: https://rfc.vac.dev/spec/13/#wire-specification)
|
|
||
| In the press release, we defined the Waku Network as the first decentralized and privacy-preserving network that provides Denial-of-Service (DoS) protections for peer-to-peer messaging. Aiming to enhance privacy and security in peer-to-peer communication by implementing innovative protocols and technologies. | ||
|
|
||
| Let’s dig a bit deeper on the why and what is The Waku Network. |
There was a problem hiding this comment.
'Let us'
We should stick with not using contractions throughout the article
There was a problem hiding this comment.
We should also standardise capitalisation of 'the Waku Network'
There was a problem hiding this comment.
@Amelia7689 are you able to take over and proceed with corrections? feel free to open a 2nd PR and I can close this one.
Here is a link to get the file: https://github.com/waku-org/blog.waku.org/blob/waku-network-tech/posts/2024-02-15-waku-network-tech-overview.mdx
| ## Origin | ||
|
|
||
| If you have been following Waku or Status, you are likely to be familiar with the origin of Waku. | ||
| The Status mobile app was created to be a Web3 superapp, a portal to the Ethereum ecosystem that leverages the three original pillars: Ethereum for consensus, Swarm for storage and Whisper for communication. |
| If you have been following Waku or Status, you are likely to be familiar with the origin of Waku. | ||
| The Status mobile app was created to be a Web3 superapp, a portal to the Ethereum ecosystem that leverages the three original pillars: Ethereum for consensus, Swarm for storage and Whisper for communication. | ||
|
|
||
| The Status development team attempted to build Status with Whisper, but there were fundamental limitations to this protocol, especially for resource-restricted devices, aka, mobile phones. |
There was a problem hiding this comment.
'but this protocol had fundamental limitations'
|
Superseded by #27 |
No description provided.