Gas metering in cairo / bytecode

📜 Development Proposals Starknet Technical Development
1

Hi There,

Since I don’t have a prescriptive solution here, wanted to present a use case that may be difficult to handle at present to see what we should build towards.

In Yagi, users will create tasks and pay keepers for transaction execution. On L1, similar keeper networks require users to pay a premium of transaction gas fees. They are able to do that through the use of three capabilities:

  • built in gas-metering (GASLEFT opcode) => this allows a contract to measure the cost of a transaction it initiates
  • gas limits on sub-transactions => this allows a contract to cap the cost of a transaction that it initiates
  • built in gas prices (GASPRICE opcode)

Our implementation will be heavily dependent on the gas metering architecture and it would be helpful to gather more information about plans there.

I understand that the GASLEFT opcode is problematic for various reasons (difficult to estimate gas, gas re-pricings can make existing contracts fail, etc.) and may not be introduced in StarkNet.

Are the other two features planned for StarkNet or perhaps another architecture entirely? Minimally we would like to be able for task authors to set a fee for task execution but this fee would need to be linked with the current gas price. While not as compelling as simply paying a fixed margin on gas, this would be good enough!

7 Likes
2

Hello!
Interesting question. I don’t have the specific answer to your question and will let others comment on that; but I wanted to suggest you look at the possibilities to implement this at the account contract level.
Fees will be paid by smart contract wallets; this means they will have access to some level of information of gas prices.
You could implement your own smart contract wallet, that takes as input signed data in a standardized way. But this account contract would not be the entry point for the transaction, and it could pay the actual entry point (that is, the wallet of the keeper).
Does that make sense?

8 Likes
3

Thanks @henri.lieutaud! Here is how the contracts are structured right now, I think it maps your model to some extent:

  • There is a registry contract
  • Each keeper has their own account contract
  • They call the account contract → which calls the registry → which executes the task
  • The idea is for payment to go from the task’s registry holdings directly to the keeper’s account contract

The problem lies in:

  1. being able to define prices that task authors will pay to keepers for execution. Without a gas price opcode, we would have to use a gas price oracle to link prices more effectively to keeper costs

  2. being able to guarantee profitable execution for task authors. Without a gas estimator/cap in cairo, task authors would have to set a fixed fee and keepers would have to assess independently whether execution gas costs will exceed that fee

7 Likes