What is a Status Node Really?
At its core a Status Node is software that allows relaying of messages of application users in a way that is as pseudonymous and as private as possible while still maintaining resource requirements that can be fulfilled by a mobile device or a low end laptop.
A Status Node needs to provide several functionalities:
- Communicate with peers in a decentralized way
- Relay messages in a private and anonymous manner
- Provide historical messages for peers that are offline periodically
The software we currently use to provide the Status Node functionality has went through many iterations, and there are new versions on the horizon, but currently we are exclusively using the status-go implementation which was built on top of a fork of go-ethereum. We have diverged from the original implementation quite a bit, and now the only thing that we really inherit fully is the DevP2P protocol and some cryptographic functions.
Status nodes initially spoke the Whisper protocol, which originated from the Ethereum project as a Proof-of-Concept peer-to-peer protocol for Dapps. Status adopted the protocol as it seemed to fit our needs well. Unfortunately in reality there were multiple issues with it, main ones being:
- Scalability issues, especially related to bandwidth and broadcast nature
- Poor SPAM-resistance due to incompatibility of proof-of-work with mobile devices
- No built-in way to provide incentivization for running nodes
You can read in detail about the scalability issues in the great "Fixing Whisper with Waku" post by Oskar.
For these and many other reasons the Vac project was born, and out of it came the Waku v1 protocol - an incremental improvement on the original. The main difference being the use of topic interests instead of Bloom filters for the sake of improving bandwidth usage by reducing collisions and in effect reducing deliveries of unwanted envelopes.
A Bloom filter is 512 bit array(64 bytes) with all bits set to 0 by default. These bits are flipped based on first 4 bytes of SHA3-256 hash of given topic which is then converted to 3 bits out of the 512 available in the Bloom filter. This way the information about which peer is interested in which topics is obscured from any relaying nodes. The issue with this approach is that it can also result in a lot of false positives, as being subscribed to multiple topics would cause multiple bits being flipped in the same single filter.
Since the size of the filter is only 512 bits, and the number of channels people can be subscribed to can be quite large - even in the hundreds - it wouldn't be that improbable to find a peer who's bloom filter has more than half of it's bits flipped, in result giving you a very high probability of receiving envelopes you are not interested in. A bloom filter with all of its bits flipped to 1 would in effect indicate desire to receive all envelopes available.
A topic interest is a 4 byte field that indicates what messages the peer in the network is interested in. The value for this field is derived from hashing the channel name or partition ID with Keccak-256, but instead of converting that to just 3 bits the first 4 bytes are taken. In addition to that Waku allows for defining of multiple topic interests for each peer, which drastically reduces the possibility of a topic collision. In Waku v1 a peer can specify up to 10000 topic interests, effectively limiting the number of chats/groups/communities they can be subscribed to to that number.
It's worth noting that topic interests are an adjustment to the trade-off between bandwidth and privacy in favor of better bandwidth usage. Since topic interests contain 4 bytes of data as opposed to just 3 bits, it is much easier to identify which channels a peer is subscribed to by hashing well known channel names and comparing the results. And even if the exact channel is not known it is also possible to roughly correlate if two people are members of the same channel without actually knowing which one exactly it is. Considering the horrible performance issues of bloom filters it was decided that the trade-off is worth it.
Originally we used the same discovery mechanisms as normal Ethereum nodes - a protocol inspired by Kademlia DHT which stores and relays node records - which was Discovery v5, but the issue with that approach is that it would also discovery far too many nodes which didn't speak the protocols we needed, Whisper and later Waku v1. For this reason we deployed our own modified version of discovery protocol called Rendezvous which would speed up peer discovery by only limiting it to nodes with the right capabilities.
The next possible solution which might be part of Waku v2 is using DNS discovery proposed in EIP-1459, which is the preferred solution for low resource devices like smart phones. But the reality is that the best solution to the discovery problem is using multiple methods - or indeed as many as possible - in order to keep it reliable and decentralized.
One of crucial abilities of a Status node is providing historical messages to peers which are not always online to receive them. Originally Status nodes with this functionality were called Mailservers and this naming was retained for Waku v1 but we currently call them History nodes. Their main purpose is storing all received envelopes in some format - in case of our fleet it's PostgreSQL database - and replying to queries from peers for envelopes matching specific topic interests for a specified time rage.
Nodes providing history are considered "trusted" by their peers because they are allowed to respond with expired envelopes. In addition they may receive more frequent updates from peers about their topic interests, since whenever a user joins a new channel they will most probably request history of messages from that channel. In effect a history node has a much better opportunity for trying to profile a peer and analyze their messaging habits than a relay node.
Considering v1 is only a small incremental improvement on the original Whisper protocol and our needs for a well performing gossip protocol will gradually grow as our numbers of users increase the Vac team started work on the v2 version in parallel. The second iteration is different from both of its ancestors to such an extent that it could be considered a completely new protocol.
Waku v2 is built using LibP2P instead of DevP2P and is split into multiple sub-protocols, the stable or near-stable ones being:
- Relay - Receiving and sending messages withing the same pub-sub topic
- Store - Returning historical messages from relay nodes based on topic interests
- Filter - Cheap receiving of messages based on specified topic interests
- Lightpush - Cheap sending of messages without being part of the Relay network using the pub-sub topic
As well as unstable future protocols related to discovery of peers or enforcing message and bandwidth limits:
- Swap - Incentivization layer that does the accounting of costs, debit, credit, and payments
Some of the improvements that Waku v2 introduces are:
- Lower amplification factors which cause fast growth of required resources based on number of users
- Lower peer connectivity limits related to node limits and mesh of connections in the network
For more in-depth look at Waku v2 read excellent articles from Oskar like "What's the Plan for Waku v2?" and "Privacy-preserving p2p economic spam protection in Waku v2".
There are a few reasons why Status wants the community to run their own nodes:
- 1It helps make the network less reliant on our own infrastructure, in effect making it actually decentralized
- 2It might facilitate communication in locations where our own fleet of Status nodes is being blocked
- 3It helps us research and understand the limitations of Waku v1 better
There are some detrimental effects though. Because of the broadcast nature of Waku v1 the additional relay nodes in the network will increase the amount of traffic between nodes in an exponential manner. Due to small scale of the node program this should not be an issue, but it could more clearly indicate the need for rolling out Waku v2 as soon as possible due to poor resource usage.
If you are interested in running a Status node visit the Node Program site.
