“How is gas used? Is it used only in Ethereum?”
This is a very interesting question.
Gas is a fascinating topic regarding
Ethereum and other smart contract platforms.
When people talk about Ethereum, a term you
will hear almost immediately is “Turing-complete.”
When you hear “Turing-complete,” it sounds
like something that is a great feature to have.
I mean, if you are not Turing-complete,
that means you are Turing-incomplete.
That sounds like you are missing something.
In fact, that is not the case.
A Turing-complete language, such as
the language used in smart contracts…
running on the Ethereum virtual machine, is one
that can execute a program of arbitrary complexity.
Usually that means the programming
language has the ability to run loops.
In fact, it is very easy to make
Even very simple systems are Turing-complete.
Even systems that are not meant to be Turing-complete
can accidentally become Turing-complete…
and end up being more flexible than originally thought.
It is actually harder to make something
Turing-incomplete, preventing it from…
executing all kinds of arbitrary code
and keeping [the language] constrained.
All of this [originates from] a proof made
by Alan Turing in 1936, which was about…
the halting problem and Entscheidungsproblem
(German for ‘decision problem’).
Alan Turing proved that if you have a
Turing-complete system, you cannot predict…
whether that system will ever stop running,
or whether it will simply run forever.
You also can’t predict if it will follow a specific
execution path or execute a specific part of the code.
This causes a significant problem.
With a smart contract running in the Ethereum
virtual machine, every single Ethereum client that is…
participating on the network must
validate that program by running it.
Can the Ethereum client predict how long a program
will run, or how many resources it will consume?
Turing proved back in 1936 that you cannot predict it.
Therefore, Ethereum doesn’t have a way to know
if a program, based on some starting conditions…
like a specific input transaction on
the blockchain at the time of execution,
will run for a second, a thousand
seconds, a million seconds, or infinity.
It doesn’t know if it will execute one,
ten, a million, or infinity commands,
never stopping in an infinite loop.
If your Ethereum client must run a program in order
to validate it, how do you make sure these programs…
do not consume all the resources of the
computers participating in Ethereum?
Vitalik Buterin’s solution was to make Ethereum’s
language Turing-complete, to give maximum flexibility,
but then add constraint so that programs
didn’t consume resources without end.
That mechanism is gas, a way of pre-paying for
a specific amount of execution or resources…
for every computer that will validate it.
Every transaction in Ethereum provides an upper limit
on the amount of gas that the execution will consume.
When the smart contract is executed,
the Ethereum virtual machine starts accounting…
for gas, by debiting an amount of gas for
every instruction executed by the smart contract.
During this process, if the smart contract runs out of
the available gas in the transaction, it stops [executing].
It is forced to have an upper limit on how much
execution, how much resource, it can consume.
There is also a gas limit for every block.
No matter how many transactions are in a block,
there is an upper limit on the maximum
amount of computation and resources…
consumed to validate and execute that block.
That is the role of gas.
Gas is the solution to the problem introduced by
the extra flexibility of a Turing-complete language,
which has no ability to predict
how long the program will run.
[Without a constraint], this could create conditions
where a single transaction takes forever to validate…
and locks up all the processing [power] of
the computers participating in Ethereum.
“Can you please explain how I,
as a smart contract developer,
can know how much the execution of my
smart contract will cost on the blockchain?”
That is a great question. I have a difficult
answer for you, and maybe you won’t like this.
It is not possible to guess how much gas
the execution of a smart contract can use.
Turing proved that long before stored-program
computers, smart contracts, and blockchains existed.
He proved that it is not possible to predict whether
a certain execution path will be used by a program,
[You can only find out] by running it.
You may never know what will happen.
You can estimate the amount of gas that will be used
by a smart contract, but you cannot predict it accurately.
The conditions under which it runs may change
between your estimate and what actually happens.
Let me give you a silly, contrived
example that shows how this works.
Let’s say I write a smart contract which has a counter,
and every time you call it with a transaction,
it increases this counter; the first ninety-nine times
you call it, all it [will do] is simple addition, 1+1=2.
That will cost a certain amount of gas to run,
let’s say 400 units of gas [for] simple addition.
But that contract will look at how
many times it has being called.
On the hundredth time, it does something else.
It decides to run a hash function a million times.
Let’s say that will cost you 5 million units of gas.
[After] you run this contract ninety-nine times,
it only consumes 500 units of gas;
then on the hundredth time you run the contract,
it consumes 5 million units of gas.
[The difference is] simply the order of transactions.
It is very simple to create contracts like that.
It is also very simple to accidentally create contracts
where the amount of gas used varies considerably…
between one execution and the next,
based on circumstances that you can’t predict.
For example, let’s say your software estimates the
amount of gas that will be used to call this contract,
based on you being the 98th transaction in a row.
As you [make] your transaction,
two other transactions first call that contract.
That means your transaction is now
the 100th transaction in a row.
Instead of costing 500 units of gas, it costs
5 million units of gas to run your transaction.
You can’t predict how the conditions will change until
you run your transaction and it is included in a block.
The transaction just before yours
may change the state of the contract,
cause it to follow a different execution path, or call
other contracts. Who knows what they will do?
They will use gas in a completely unpredictable way.
This is one of the challenges
with writing smart contracts.
The [option] to have the contract pay for the gas gives us
a bit more flexibility in how to plan gas expenditure…
and estimates for smart contract developers.