Config fulfillmentGasLimit for QRNG callback

copsupemli · May 9, 2023, 11:51am

We can specify minConfirmations to get Airnode callback faster.

Does it possible to specify/set/config fulfillmentGasLimit same way? Because our logic needs up to 2-3M gas and we run out of 500K.

copsupemli · May 19, 2023, 1:55pm

Resolved in GitHub issue.

github.com/api3dao/airnode

Have RRP fulfillments estimate gas

opened 03:14PM - 06 Dec 22 UTC

bbenligiray

needs documentation

Currently we have a [`fulfillmentGasLimit` field in `config.chains`](https://doc…s.api3.org/airnode/v0.9/reference/deployment-files/config-json.html#options-fulfillmentgaslimit) that is by default 500,000. This means you need a minimum of `500,000 *gasPrice` of the native currency in your sponsor wallet for it to be able to respond to a request. Considering that a fulfillment typically costs less than 100,000 gas, having to send the extra 400,000 to the sponsor wallet becomes very annoying. The reasoning behind hardcoding the gas limit was to minimize the number of blockchain provider calls. This is also why we hardcode the chain ID in the config and only call `getTransactionCount()` once per sponsor wallet per coordinator invocation. However, we still follow this up with [a static call](https://github.com/api3dao/airnode/blob/34f94258e48f8f1dfe7e7e836539effceb4dd576/packages/airnode-node/src/evm/fulfillments/api-calls.ts#L122) to see if the fulfillment will revert. I propose replacing this static test call with a gas limit estimation call for the happy path. [Gas estimation calls are typically more expensive for the blockchain provider than regular static calls](https://stackoverflow.com/a/55431746/14558682), but they are by no means exotic (any transaction where the gas limit is not specified is preceded with a gas estimation) and assuming that the main issue is I/O, replacing a blockchain provider call with another should be fine. So I'm proposing that in the case that the gas limit is not specified, a gas estimation call to be done first. If the estimation is successful, skip the static test call because it's guaranteed to not revert (otherwise gas estimation would have failed). If the estimation errors, follow up with the static test call to get the revert string, which will be submitted along with the failure. As a result, the fulfillment will be done with a gas limit that is just enough. Finally, let me give the context about oracles and forced gas limits. There is this idea that relayers can trick their client to believe that their meta-tx reverts (which still results in the relayer being paid in most implementations), even though [the reason it reverts is that the relayer didn't provide enough gas](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/98967feeb294f26e8d99dcac57f340669ad7c09e/contracts/metatx/MinimalForwarder.sol#L59). The same issue is addressed in a less leet way by [not accepting fulfillments that don't come with a large enough gas limit](https://github.com/smartcontractkit/chainlink/blob/0518d8cf4c1bb1cb0d6b31b53a4c3c3915eb7ea1/contracts/src/v0.4/Oracle.sol#L171). In the Airnode protocol-context this is an irrelevant issue because: (1) A requester of a specific Airnode already trusts it with the delivery of the data, which makes a lot of sense in the first-party context because they already trust the API provider with the correctness of the data, (2) Fulfillments are already paid for by the requester so there is no incentive for the Airnode to minimize the gas burn, which is what the relayers perform this attack for. The Airnode operator can just claim the funds in the sponsor wallet, which is already accepted as a tradeoff.