Incentivized Lightpush: A Roadmap to Waku Service Incentivization

[sergei-tikhomirov]

@mart1n

@sergei-tikhomirov

In the context of Waku, preconfirmations or similar add-ons in L2 protocols mean lower latencies and better user experience. However, changes in trust assumptions should also be considered.

I am trying to understand the benefits and how this would play out if the payment precedes the service: If the node knows that the payment transaction is coming, it has more time to deliver the service and minimize latency?

Exactly. In the vanilla case, the client sends the payment, waits for transaction confirmation, obtains the transaction ID, and only then sends the request. Even on L2 this may take seconds. With preconfirmations (the way I understand them), the L2 operator (sequencer) can issue a signed promise of transaction inclusion before the block is even produced. If the server is willing to trust those promises (which may be crypto-economically backed, cf. shared sequencing with restaking), the server can deliver the service right away upon receiving the request + payment preconfirmation.

@mart1n

how we define atomicity in this environment. What would be an ideal execution in this sense?

Ideally, we may want to see some cryptographic (or, perhaps, cryptoeconomic) mechanism such that the paymend goes through if and only if the service is provided. This is indeed tricky when dealing with information transfer. I don’t have a concrete solution, and it may well be the case that in the Lightpush example atomicity is infeasible. It may be feasible though for other, more cryptographically self-contained services (within our future generalized service marketplace) - something along the lines of “I will pay you for a preimage of this hash”.

[fryorcraken]

@mart1n

If the public key of the service provider is available, the client can encrypt the message and only then sign the encrypted message. This allows the provider to verify the message and limits the “leak” to the case where provider’s private key is leaked as well. Of course, the provider if bad actor, can rotate these keys per client and bypass this.

I want to highlight the risk of linkability and no possible denial created by signing light push requests with a key related to a wallet account.
The intent of the service provider does not matter as much, as a well intended service provider may still be subject of a data breach.

All direct communication between Waku nodes are encrypted with Noise as part of the libp2p transport stack.

[sergei-tikhomirov]

I’ve added an update to the post reflecting changes related to some of the discussion items. Moving on to the next steps. Thanks everyone!