DoS protection of Store servers

[s-tikhomirov]

Protect a server from clients that issue too many requests.

There are two scenarios: the PoC protocol, and the fully-fledged protocol.

In PoC, the initial request already contains a proof-of-payment (price is not negotiated). Hence, requests are not free for the client. Therefore, a simple IP-based rate limiting might be sufficient: the server would temporarily block a client who sends too many requests with incorrect proof-of-payment.

In a fully-fledged protocol, price negotiation is separate from payment. A malicious client may overwhelm the server with price negotiation requests, and not proceed with the payment. As such requests are essentially free, it may be necessary to generalize a reputation system to servers ranking clients. IP-based rate limiting would work as the first line of defense, but it may not be sufficient if an attacker rotates IP addresses.

Note: with rate limiting either by IP or by reputation score, the server would need to link requests coming from one client, threatening its privacy.

[fryorcraken]

Note that it may be possible to leverage RLN Relay here for this problem where the initial communication is done over Waku (meta content topic per shard?) and hence rate limit functionality from RLN can be used to limit customer to do too many queries.

This could be similar to the RAILGUN protocol.
In RAILGUN, "relayer" sell a service: doing a defi transaction on chain, in exchange for a price.

The RAILGUN protocol is as follows and takes place over Waku

sequenceDiagram
    actor Alice (Relayer)
    actor Bob (Relayer)
    actor Carole (Wallet)
    Alice (Relayer)->>Waku Network: 15DAI or 14USDC + pubkey
    Waku Network-->>Carole (Wallet): Alice's price is 15DAI or 14USDC + pubkey
    Bob (Relayer)->>Waku Network: 16USDC or 15DAI + pubkey
    Waku Network-->>Carole (Wallet): Bob's price is 16USDC or 15DAI + pubkey
	Carole (Wallet)-->>Carole (Wallet): Only holds USDC
    Carole (Wallet)-->>Carole (Wallet): Selects Alice
	Carole (Wallet)->>Waku Network: Payment + transaction to forward (encrypted with Alice's pubkey)
    Waku Network-->>Alice (Relayer): Take payment, proceed with onchain transaction

Loading

Possible difference:

• store node broadcast multiaddr instead of pub key
• last part of the protocol is not done over Waku Relay but via direct connection

Do note here it's not a negotiation.

In our case, part of the negotiation could happen over Waku Relay and then be finalized as a direct connection when DoS risks are mitigated.