Crypto-economic incentives in light clients side

[alrevuelta]

This issue explains the idea of having crypto-economic incentives on light clients side. Meaning that light client users should pay a small fee in exchange of such services (such as store, filter or lightpush). Since these so called "light clients" (nodes that don't run a full node and just use other nodes) don't really contribute to the network, it would be fair that they have to pay a small fee for such services. Trust assumptions in the different protocols are also explained, which at the moment, can't think of a way of being completely trust free.

Introduction

Crypto economic incentives in waku are not trivial, since:

• Incentivicing nodes for relaying every message wouldn't be practical. Tracking this would be a mess, since we would need some kind of ledger to account for all this, with proofs, store them etc. We would need some sort of consensus and even if we wanted to offload the consensus to a blockchain I don't think its feasible even with layer 2s. Its just to much to incentivice per every relayed message. Many nodes, hard to proove, hard to account.
• Incentivicing nodes for storing messages and serving them is indeed possible, but there would be a lot of overlap with codex and I'm not sure that persistent storage is a problem we need to solve at waku.

In fact there are some examples out there of blockchains that without having incentives for i) relay and ii) storage, work very well. For example, in Ethereum no one incentivices you (economically) for relaying traffic in their gossipsub network. Same for serving blocks to new nodes or for storing old state that you dont really need. But in the Ethereum case, economic incentives are placed somewhere else, so that you are indirectly incentiviced do i) and ii).

During the offsite, we decided to leave crypto-economic incentives a bit aside, and focus on some game theory and non crypto-economic incentives that will indirectly incentivice people to run nodes. Examples:

• Due to how gossipsub works, if you want to receive messages you need to also send them. Otherwise you will be de-scored and you risk losing messages (because other peers will disconnect from you).
• We can also use some default values so that people are altruistic with the network. Modyfying the code will act as a desincentive, so people will just rely on the defaults.
• We can use as referece other projects like Bittorrent, that without incentives, work quite reasonably. If you contribute more to the network (bandwidth) then you get more from the network. Gossipsub scoring is kind of similar, but we can always add waku specific stuff on top.

Crypto-economic incentives in light clients

But what if crypto economic incentives could be on light protocols side, meaning that light client users pay for filter, light-push and store requests? In other words, require light client users to pay for publishing and fetching messages to/from the network.

If a node is getting paid for providing these services to light clients, then it would be incentiviced to relay traffic and store messages, because its getting paid to do so. And by doing this, they are contributing to The Waku Network. If you are interested in running a full node, you can always do it (even with incentives disabled), but with this we can also ensure coverage to light clients. L2 technologies could be used, any Validium should be enough, with non onchain data availability but with sub cent fees.

There could be two approaches:

• subscriptions: eg monthly subscriptions for a flat rate. In every request you include a proof that you hold a valid subscription for the month and then you are free to access (store/filter/lightpush services). Note that these are some kind of out of band agreements between clients and given waku operators. Meaning that my "proof of subscription" is only valid with a given waku operator, the one that got paid the subscription. A problem could be: how do we ensure people don't share this subscription (like 1 netflix account shared by 1000 people).
• pay-per-message: pay for each publish, store request, etc. In this case for every message that you want to send or retrieve, you must pay a fee, that is charged per message/byte. In this case this payment system could be part of the protocol (not out of band) and every node in the network would be able to get the fee (if they have configured their fee recipient).

While I don't have anything against the subscription model, I would just analyze the pay-per-message one, since I think i) involves less trust in the node and ii) its not and out of band agreement between users and specific wkau operators. The analysis is divided into 3 incentives for the pay-per-message case:

• store incentives
• lightpush incentives
• filter incentives

store incentives

A node can be incentiviced by getting a small fee on every time it replies to a `fetchMessage(topic, startTime, endTime) request. Assuming that the more messages the node replies to, the higher the fee it gets, then its incentiviced to store as many messages as possible, since a non stored message has an opportunity cost. Meaning that you will fail to profit from that if someone requests it. This section suggest how to implement incentives on store providers by:

• proposing a simple req/resp interaction
• giving some idea on pricing mechanism
• analyzing the trust assumptions

We could add a previous req/resp interaction before the existing store interactions (+ some minor mods), to settle the payment. Something around the lines of:

• Light client lc wants to request messages from a node
• lc expresses its intention to node (eg i want the last 10 messages from this topic)
• node returns a quotation (puts a price) + an invoice number in
• lc pays the in and submits a proof to node that it paid it
• node returns the messages to lc

The pricing mechanisim is open but should take into account the following.

• The amount of bytes served: Since this consumen upload bandwidth from the serving node.
• The amount of messages served: Perhaps it would be enough to just track bytes, as its related.
• The average message timestamp of the served messages: Retrieving older messages should pay a premium.

There are two ways of completing the payments. Leaving aside other fancy designs with escrows, disputation systems etc. I would opt for i) since the node operator has some reputation that can work as collateral.

• i) Light client pays first, gets message afterwards.
• ii) Light client gets the messages, pays afterwards.

However, with the current state of the art in waku, there are some trust assumptions:

• How do we know the message is real?: Assuming that every stored message contains a RLN proof, we can use it to verify that the message was indeed sent and not invented by the node the gain the reward. There might be an attack vector here where the node also holds an RLN membership and can create messages "on the fly".
• How de we ensure we get the message after submitting the payment?: We can call this the "withholding attack" where I pay for fetching 5 store messages, give the node the proof of payment but the node never replies back to me.

In both cases, i) using more than 1 node to run the query and crosschecking the responses and ii) node reputation can reduce trust, but by now its an open problem to do this in a fully trustless manner.

lightpush incentives

TODO

filter incentives

TODO

tldr: Have light protocol users to pay for filter, light-push and store requests.

[s-tikhomirov]

How do we know the message is real?

Isn't this question orthogonal to incentivization? Even without incentivization, how can a light node be sure that the message it receives is real, and what is real anyway? (In the absence of a canonical history.)

[alrevuelta]

Isn't this question orthogonal to incentivization? Even without incentivization, how can a light node be sure that the message it receives is real, and what is real anyway? (In the absence of a canonical history.)

Not per se part of incentivization but very connected, since with incentives in serving messages, the incentive to attack the protocol is way higher (create fake messages out of thin air and get paid for each one, easy exploit). Without incentives, well, the attack is still there but it makes less sense to exploit it (from an economical perspective). Said that:

• Currently there is no way to know if a message is "real". There is no consensus between the nodes, where each one says "i saw x message". A random idea could be to have all nodes update a merkle root onchain, representing the messages seen in the last eg. day. Then this onchain merkle root (voted by all nodes) can be used to know if a given message belongs to it or not. We haven't explored this, and the implication/complexity is non trivial.
• But at least we can limit the damage. RLN proofs can be used to verify if a message is "ok or not". So you can create fake messages but only i) if you hold a valid rln memberships, ii) up to a rate of x (depending on your rln membership) and iii) you have to do a small PoW (creating the proof).

how can a light node be sure that the message it receives is real
Note that this problem affects both light nodes and full nodes. Note that your full node might be down for few hours, and then you would need a store node to fetch the messages during this time window.

and what is real anyway?

I would define by real a message that has been seen by the majority of relay nodes. But by now what we have is just "valid rln proof".

[alrevuelta]

Storing nodes are supposed to take on risk without being sure that they will get reimbursed in the future. A full node must store non-ephemeral messages as they arrive, in the hope that someone, sometime in the future will be interested in them. This is akin to PoW mining where miners expend energy first hoping to get rewarded later, so that's not to say this cannot work, but it's something I'd keep in mind.

@s-tikhomirov (my bad, I meant here)