---
title: Gas blog post
tags: gas,tezos
---

# Gas for Tezos protocol developers

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:
From: [PUBLIC_KEY_HASH]
.... snip ....
Gas limit: 3689
<<<< snip >>>>
Transaction:
Amount: ꜩ0
From: [PUBLIC_KEY_HASH]
To: [CONTRACT_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.

Since those operations are expensive in terms of time, they open the opportunity to block the progress of the mutation of Tezos state if the time to execute them accumulates in one single call. This is detrimental to the performance of bakers and, in the end, the Tezos blockchain as a whole. This can be further exploited to launch Sybil attack by taking bakers off the consensus. To do so, adversaries strategically send contract call operations to bakers to saturate the CPU time on them, hoping to remove the honest participants in the consensus protocol.

In addition, providing enough incentives for the bakers to provide Tezos services like execution of smart contracts. Having a measure for how much time it takes to execute a contract call would be an important factor in measuring the incentives to bakers for their services.

Therefore, the short answer to the question of the nature and definition of gas is that it is a benchmark on the **consumption of time** to provide Tezos services.

## Why gas is set at these values

It is very attempting to just use the raw CPU time measured to apply and include each of the manager operations received for gas values. In reality, it is nearly impossible for all bakers to use the same CPU time for one particular operation due to varying machine specifications. Even on the same machine, the time for executing the same operation may fluctuate over different runs due to factors such as the other workloads running on the machine and how the operating system is scheduling the tasks. To measure the consumption of computational resources fairly regardless of difference in bare-metal performance, an abstract accounting model is introduced throughout each Tezos protocol.

The complication comes when in fact most of the operations will take varying time to complete depending on the inputs and othe factors. For this reason, gas values are parameterized over a set of inputs such as the size of input Michelson value if they are simple, or the size of the map or big map that is being looked up on. One interesting example is the `PACK` instruction. Its workload parameters are specified in the `Interpreter_model.ir_model`. The gas values of executing a `PACK` instruction, serializing a run-time value while interpreting a contract code into bytes, is [modelled as linearly depending](https://gitlab.com/tezos/tezos/-/blob/444bbb721808a291afeb0b6a3f01a82260d4c32e/src/proto_alpha/lib_benchmarks_proto/interpreter_model.ml#L235) on the number of nodes in the input value, the size of integers and the size of the strings in the input value.

After making hypotheses on the relationship between potential inputs to the performance of executing each instruction and operation, what is left to be done is to create various benchmarks to measure the runtime of each of those operations to work out the parameters to our models. The observations will be the time in _nanoseconds_ taken to complete the operations in the various micro-benchmarks and benchmarks under various scenarios on a base-line machine. To enhance the accuracy, [`lasso`](https://en.wikipedia.org/wiki/Lasso_(statistics)) is used to compute the linear regression. Therefore, when these benchmarks are run on a base-line machine, the time reported will be the number of units of gas consumed for each operation.

So to summarize, the gas prices in the protocol are derived directly from the run-time statistics of each operation deemed worthy to track under the gas system. A benchmark suite is used and statistic methods are applied to remove the random noise in those benchmarks.

### Why can't I arrive at the same gas values?

Supposedly once changes to the Tezos protocol are implemented, you could just run `tezos-snoop` to get the new gas parameter numbers as reported by following the instructions [here](https://tezos.gitlab.io/developer/snoop_interpreter.html). However, if the runs are executed locally on your machine, the chances are you will never get the same numbers as prescribed in the protocol code. Why does this happen?

The answer is that you are not running the benchmarks on the base-line machine. The base-line machine is currently maintained by Nomadic Labs, which is a standard bare-metal Scaleway machine, aka. “Dedibox”, dedicated to the benchmarks just prior to each protocol proposal in preparation of updates on the gas parameters. The specification of this machine is _somewhat resonable_ so that it reflects the baseline performance of the bakers in a sense that Tezos network continues to progress without performant bakers.

For a good reason people would find _somewhat_ reasonable not staisfying. No matter how well Scaleway isolates the base-line machine during the benchmarks, flucutation in performance is inevitable. It is sharing the congestion on the network which affects the performance of disk access as cloud disks are likely mounted remotely. For this reason, Tezos developers are considering an upgrade on protocol benchmarks. Specifically, we will see a new process to derive those gas values with the help of independent benchmark runs on diversified machines. The benchmark numbers will be tallied together, by scaling back and forth to offset the relative difference in machine performance, to produce the final gas parameters.