Gas for Tezos protocol developers

By Tezos Protocol amendments team

Every transaction comes with a cost attached called gas. Whenever you send a transaction, of various types of manager operation, you will mostly come across gas in the transaction receipt. It also appears in the wallet transaction interface, where it may ask you for a maximally allowable gas value for this transaction. For instance, you may see this if you submit a transaction through octez-client.

This sequence of operations was run:
  Manager signed operations:
    .... snip ....
    Gas limit: 3689
    <<<< snip >>>>
      Amount: ꜩ0
      From: [PUBLIC_KEY_HASH]
      <<<< snip >>>>
      This transaction was successfully applied
      <<<< snip >>>>
      Paid storage size diff: 66 bytes
      Consumed gas: 2588.410
      Balance updates:
        [PUBLIC_KEY_HASH] ... -ꜩ0.0165
        storage fees ........................... +ꜩ0.0165
      Internal operations:
        Internal Transaction:
          Amount: ꜩ0
          From: [CONTRACT_HASH]
          To: [PUBLIC_KEY_HASH]
          <<<< snip >>>>
          Consumed gas: 1000.398
          <<<< snip >>>>

We vaguely connect the notion of gas to the cost attached to the action of sending transactions to Tezos blockchain. Have you ever wondered what is gas and what purpose does it serve? And as a Tezos protocol developer, how should you derive such numbers? Today in this blog post we will dive into this matter.

What is gas and what it is good for?

As you might have already been aware, the Tezos blockchain state is collectively maintained, mutated and verified by bakers participating in a consensus scheme. Most importantly, the mutation of the state happens when manager operations are selected and executed by bakers. They include, most prominently but not exclusively, calls to smart contracts. In essence, bakers provide services to validate and safely mutate Tezos state through various computational procedure.

We shall take execution of smart contracts as an example for the following discussion which can also be applied to all the other manager operations that Tezos supports. When a baker executes a smart contract, there are a few operations that are empirically found to constrain computational resources. They are typically slow and bounded by CPU time because it involves hard arithmetics, such as elliptic curve operations which is at the heart of modern cryptography; or they are bounded by I/O latency because it may need to read from disks.

As a general guide, here is the non-exhaustive list of operations in Michelson that are considered resource constraining.

  • Accessing big maps
  • Parsing Michelson from user input into memory representation and unparsing them back before writing them onto the chain
  • Constructing internal operations to effect other Tezos manager operations such as calling one contract from another, which definitely involves parsing and unparsing like the previous point
  • Elliptic curve arithmetics including BLS operations
  • Manipulating Michelson values, including reading and destructuring contract call parameters and contract storages as well as interpreter stack
    So this list covers basically all the Michelson instructions that you may encounter when composing a smart contract.

If you want to learn more about gas, please read our blogpost on Marigold website :point_right: Gas for Tezos protocol developers