feat: Add incentivization PoC for RLNaaS in Lightpush

[s-tikhomirov]

Description

This WIP PR implements a PoC for light protocol incentivization as outlined in:

• Incentivization spec
• Incentivized Lightpush - Vac post

Associated deliverable: waku-org/pm#245

Changes

• cherry-pick prior PoC work from an experimental branch
• remove the dummy protocol (not needed anymore)
• implement the required transaction checks (payment amount, address)
• use Anvil for testing instead of a hard-coded Infura RPC endpoint

Changes planned for future PRs

• track used txids server-side to avoid double spend (feat: incentivization POC: add double-spend check for txid-based eligibility #3264)
• implement a simple local reputation (clients track the preformance of servers they've interacted with)
• integrate with Lightpush

[github-actions]

You can find the image built from this PR at

quay.io/wakuorg/nwaku-pr:3166

Built from 53aea7f

[Ivansete-status]

@s-tikhomirov - is there anything blocking this PR?

[s-tikhomirov]

@s-tikhomirov - is there anything blocking this PR?

Good question.

On the one hand, there are still things to implement before this can be considered a fully-fledged PoC. For example, the properties of a transaction that is checked for "eligibility" are now simply hard-coded. In the final vision, those should be node-specific and stored in a config file or something like that (and I'd have to figure out where such files should be located, how to manage them, etc). On the other hand, the current version is more or less self-contained, and in the spirit of merging things incrementally, I could see this PR at least considered for review.

For context: the overall vision of this PoC is that a client would attach a txid as proof of payment alongside its Lightpush request, and the server would check for eligibility of that txid. By eligibility we mean that the transaction:

• has been confirmed;
• is not a contract creation transaction;
• pays the expected amount;
• pays to the expected destination;
• hasn't been used in a previous request.

Here is what is implemented now:

• check that the tx has been confirmed;
• check that the tx is a simple transfer (not a contract creation and not a contract call);
• check that the amount is "expected" (a hard-coded amount from a totally random tx used in tests);
• check that the destination is "expected" (also hard-coded, same as with the amount).

These could be the next steps:

• avoid hard-coded values (use server-specific expected amounts and destinations);
• use token transfer transactions and not simple transfers (as described here; I'm using simple transfers now for simplicity);
• account for double-spent txids;
• avoid hard-coded Infura endpoint for querying the blockchain;
• attach this to Lightpush (behind a feature flag).

Given this, do you think it makes sense to consider this PR for review as it stands now?

@jm-clius , WDYT?

[jm-clius]

Without having looked at the code itself yet, based on your description I would certainly suggest opening for review - or even selecting a smaller increment that illustrates a specific function and creating a PR for that. This way we can show the POC growing, remain clear about next steps and what is WIP, while making the turnaround from PR to merge shorter due to the easier review burden on nwaku contributors.

[gabrielmer]

Amazing work! Thanks so much! 🤩

I added some questions and comments, please let me know if I'm missing anything in any of them :)

I also see that the Lint CI job is failing, please try installing the latest version of https://github.com/arnetheduck/nph/tree/latest and integrate it with your IDE (let me know if you have any issues with it, I can help out!)

[Ivansete-status]

Thanks for it!
I just added some nitpick comment that I hope you find useful

[jm-clius]

Thanks! Added a couple of initial comments to address below.

[jm-clius]

Btw, useful to add links to the associated deliverable in the PR description: waku-org/pm#245