fryorcraken
commented
5 months ago https://forum.vac.dev/t/message-validation-marketplace-waku-network-of-networks/262/4
Another strategy is to have RLN, or another proofing system, in addition to the current RLN. This second proofing system would be applicable per app name in the content topic. A developer would be encouraged to develop such proofing to help with QoS on their app content topics. A node operator would be encourage to install said plugin to have better QoS to the user of the given app.
In the context of Store incentivization (https://github.com/waku-org/nwaku/issues/1961), a question arises on how do discourage servers from creating fake messages.
The client pays the server for historical messages. The client, in general, has no way of knowing whether a given message had really been broadcast. If the server gets paid per message (or per byte), an incentive appears for the server to send fake messages to the client.
We can use RLN - a method of spam prevention in Relay (RLN-Relay) - to limit the server's ability to generate fake messages. An RLN proof signifies that the message has been generated by a node with an active membership during a particular epoch. Note that a server with a valid RLN membership can still accumulate messages without broadcasting them. With RLN, however, the number of such messages is limited to the maximal allowed message rate, and require the server to have a valid RLN membership.
Analyze RLN in the context of Store incentivization. It is somewhat similar to PoW in this context; how far does this comparison go?
A complementary countermeasure - to query multiple servers - is discussed in #57 .