"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 something Turing-complete.
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.