Query fees

[dzhelezov]

Overview

Query fees are deducted from the user escrow account via a proxy address. This enables the following use cases:

• feeless queries submitted directly to the router
• Escrow paid in any currency and automatically converted to SQD (even on other chains via bridges)

The user story is as follows:

• A user navigates to the dApp webpage
• Logins with the wallet (in the future in ETH chains as well)
• Deposits the desired amount
• Signs a spend allowance with the wallet, and receives an "API key". The user can set limits per key and rotate.
• Interacts with the router with the API key

Funds flow

The query fees are deducted once the worker submits a claim. The router may abort the incoming transaction if the escrow account is too low.

The exact price of the query execution can only be calculated once the worker finishes the job. The worker executing the query (or part of the query) submits a claim based on the amount of processed data. As the query volume grows we will introduce the option to aggregate the claims to minimize the amount of data submitted on-chain. Since the worker rewards do not depend on the collected fees, there's no incentive for the worker to report excessive fees.

UPDATE

Here is an updated payment schema without a direct communication user <-> router:

1. The client is authenticated using the address Public Key
2. The client picks up a worker for the query
3. The client sends a signed message containing:
   • query
   • nonce
   • signature
   • max fee (optional)
     4. The worker receives the client request and authenticates it against the router, sending to the router:
   • the digest + signature of the client request
     5. The router checks that the client has sufficient credits and locks the specified amount (with a margin). Responds to the worker with the max fee to spend
     6. The worker executes the query. Upon completion, sends back to the router the digest of the result and the actual resource spent (scanned data)
     7. The router finalizes the transaction and posts the query digest for optimistic verification

The scheme achieves the following:

• A single state channel (only against the router)
• Mitigates the double-spend and replays attack since only the router authorized the transaction
• It is generates a proof that the client has sent a specific query and that the worker has generated the specified response
• There is no incentive for the worker to not respond to the client query (griefing) as it has to calculate the response hash
• The client can prove worker's wrong-doing by re-executing the query and submitting a fraud proof on-chain

[dzhelezov]

Architecture update 08.06.2023: https://gist.github.com/dzhelezov/5622ef130c8a2e671cddbc210b971178