feat: POC incentivisation protocol

[jm-clius]

Problem

This is a simplification and restatement of https://github.com/waku-org/nwaku/issues/1961

The goal of this issue is to create a proof of concept branch in nwaku, with the following new feature: incentivise light protocol requests requiring a proof of payment in the form of a raw on-chain transaction in order to be processed. After successfully validating that the transaction exists, the requested node will respond with successful response.

Note that this is intended to stay as an experimental branch, and most likely not merged into master in the short term. It will help explore some of the concepts set out in this overview document

Suggested solution

Some informal requirements. Let requester be the node that requests the generic service and responder the full node that provides the service:

• Let the requester include a transaction ID in the Eligibility Proof included in the request
• Let the responder verify the existence of the transaction ID on-chain and return indication of success/failure in the Eligibility Status response

Some notes:

• We can use Ethereum, Sepolia testnet would be fine, as we have nodes to use, and RLN is already integrated with this. Of course in reality it wouldn't be feasible to do this due to fees and processing times, but for the proof of concept its fine. As long as we target EVM (or Ethereum RPC compatible chains, we can then change).
• In order to avoid the complexities of existing request-response protocols, we can define a bare bones Dummy req-resp protocols that simply wraps an Eligibility Proof in the request and Eligibility Status in the response, as defined in the raw spec
• To cut scope for this proof of concept, we can avoid having smart contracts and just confirm existence of a transaction ID on chain.

The deliverable would be a branch with such a feature, where a requester and responder instance can be run illustrating the interaction. For POC purposes the requester and responder can be initialised only in some unit test cases, showing both successful and unsuccessful attempts.

[Ivansete-status]

Thanks for the detailed description @jm-clius ! Do we have an expected date for completion? I think @NagyZoltanPeter can help in that matter :) Cheers

[jm-clius]

Ah! This is something that @s-tikhomirov is already working on and is just aimed to improve the scope and description of his work. I think it should be done within the next 2 weeks, as he's making steady progress

[s-tikhomirov]

confirm existence of a transaction ID on chain

Should we care about possible re-orgs? In other words, should it matter at which depth the transaction is included?

[jm-clius]

I think not. For the sake of simplicity we can even write our POC test to check for any existing (old) transaction hash.

[NagyZoltanPeter]

@s-tikhomirov , @jm-clius: Sorry to talk in... maybe a full stupid question: Do we want that a node serving a store/lightpush/... request to check on-chain data? How fast is it? How will we merge with DOS protection?

For the first read, it seems to me a similar problem that is normally solved (in web2 world) with oauth or jwt. So the transaction is checked separately and you get a token that is valid for a certain amount of time/request/bandwidth or combination. Such token can be easily combined with current DOS protection and has no much resources needed to validate. Also, request prioritization can be solved easily.

Sorry for talking into it.... just my two cents with my limited knowledge on the topic.

[jm-clius]

Not in the least a stupid question. :) I think it's clear that the POC model of a service node doing on-chain checks for every request will probably not be fast enough. We do want to evolve this into a much more comprehensive model where requesters use some service credentials/micropayments to get access to a service. Combining this with authenticated session logic sounds like a promising solution. For now, note that the POC is only meant to explore some of the main concepts and libraries and will not be merged into production code.

[s-tikhomirov]

Merged into a feature branch as planned, closing this issue.