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:
- Node Reimbursement: The Medusa node does not lose money when paying for gas to submit a result
- 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:
- Medusa node estimates the cost to submit the result
- If cost ≤ paid:
- submit the result
- And set gas_limit = paid / current_gas_price
- else:
- Do not submit the result
Underestimation Policy
In the case where the node does not submit the result, we have two options:
- The user can opt to cancel their request and receive their gas money back at any time.
- 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
- The node/relayer can retry the transaction at a later time when the network gas price is lower.
- 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:
- End-user pays for their requests
- 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:
- 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. - This might not work correctly on Arbitrum, TBD.
- This might not work if we cannot override state to bypass a BLS signature verification or other checks.
- 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)
- We use an RPC method,
eth_estimateGas
and estimate the gas in two parts: - cost to submit and verify a result
- The gas usage is constant so we can include that number in the SDK.
- Except on Arbitrum, so we can use a special GasEstimator contract that bypasses verification + state checks.
- cost to execute the user-defined callback
- 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