User pays for callback gas

État
In progress
Assignation
Jonathan Easterman
Timeline
November 14, 2022 → November 18, 2022

We want an end user OR client smart contract to pay for the gas required to submit a reencryption result and call the user-defined callback.

We have two goals:

  1. Node Reimbursement: The Medusa node does not lose money when paying for gas to submit a result
  2. User Estimation: The user or client application can easily and accurately estimate the gas they need to pay when submitting a request

Node Reimbursement

The protocol for node reimbursement is as follows:

  1. Medusa node estimates the cost to submit the result
  2. If cost ≤ paid:
    1. submit the result
    2. And set gas_limit = paid / current_gas_price
  3. else:
    1. Do not submit the result

Underestimation Policy

In the case where the node does not submit the result, we have two options:

  1. The user can opt to cancel their request and receive their gas money back at any time.
    1. Note: there is a race condition where the node tries to submit a result after the request has been cancelled and the node loses some gas money for a reverted transaction
  2. The node/relayer can retry the transaction at a later time when the network gas price is lower.
    1. This is similar to how blockchain transactions sit in a mempool until the network gas price lowers to meet the transaction’s designated gas price

User Estimation

In terms of who supplies the payment, the application developer has two options that they will be able to define in their smart contract:

  1. End-user pays for their requests
  2. Developer pays for end-user requests

In terms of allowing the end-user or developer to easily and accurately estimate their gas payment, we have a couple approaches:

  1. We use a special RPC method, debug_traceCall, that allows us to override EVM state so that we can correctly estimate the submit_result+callback cost before a request has been submitted.
    1. This might not work correctly on Arbitrum, TBD.
    2. This might not work if we cannot override state to bypass a BLS signature verification or other checks.
    3. This might not work if the user-defined callback also requires state overrides (though we could ask the user/developer to supply the necessary overrides)
  2. We use an RPC method, eth_estimateGasand estimate the gas in two parts:
    1. cost to submit and verify a result
      1. The gas usage is constant so we can include that number in the SDK.
      2. Except on Arbitrum, so we can use a special GasEstimator contract that bypasses verification + state checks.
    2. cost to execute the user-defined callback
      1. It should be easy for the user to estimate the gas usage of their callback

Arbitrum Gas calculation

The arbitrum gas usage is a function of L2 opcode usage and L1 gas price, therefore it is not constant for a given set of opcodes (a.k.a. a given smart contract method)

fee_L2 = gas_usage_L2 * gas_price_L2

gas_usage_L2 = F(gas_price_L1, opcode_usage_L2)

See Arbitrum’s blog post for more explanation

Roadmap to an ideal solution

Version 1

Timeline: Implement within ~2 weeks; coincides with our release on Wallaby

Scope:

  • Implement “Node Reimbursement” without “Underestimation Policy”
  • Implement one of the two options for “User Estimation”

Version 2

Timeline: Implement within 3 months; coincides with acquisition of users/developers building with Medusa

Scope:

  • Implement “Underestimation Policy”
  • Evaluate / Refine / Revisit “User Estimation” with feedback from actual users

Version 3

Timeline: Implement within 6 months; coincides with our mainnet release

Scope:

  • Evaluate existing implementation in the context of user feedback + cryptoeconomic model for Medusa

CryptoNet is a Protocol Labs initiative.