 Sudakar asks, how is gas used? Is it used only in Ethereum? This is a very interesting question, Sudakar. Gas is a fascinating topic when it comes to Ethereum and other smart contracts-based platforms. When you hear people talk about Ethereum, a term you will hear almost immediately is the term Turing Complete. When you hear Turing Complete, it sounds like something that is a great feature to have. After all, if you're not Turing Complete, that means you're Turing Incomplete, and that sounds like you're missing something. In fact, it's not the case. A Turing Complete language, such as the languages used in the smart contracts running on Ethereum or the 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's very easy to make something Turing Complete. Even very simple systems are Turing Complete. In some cases, even systems that were not meant to be Turing Complete become accidentally Turing Complete, and end up being far more flexible than originally thought. It's actually harder to make something Turing Incomplete, meaning preventing it from executing all kinds of arbitrary code and keeping it constrained. Part of the reason for all of this has to do with proof made by Alan Turing in 1936, which was the halting problem or unshidings problem, where 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, because with a smart contract running in the Ethereum virtual machine, every single Ethereum client that is participating on the network has to validate that program by running it. How does it know how long that program will run? Can the Ethereum client predict how long a program will run, and whether it will consume a certain amount of resources? What Turing proved back in 1936 is that you cannot predict that. Therefore, Ethereum doesn't have any way to know if a program, based on some starting conditions, like a specific input from a transaction in the blockchain, as it is 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 command, ten commands, a million commands, or infinity commands, never stopping and going into an infinite loop. If your Ethereum client has to run a program in order to validate it, how do you make sure that these programs do not consume all of the resources of all of the computers participating in Ethereum? Vitalik Buterin's solution to this was to make the language of Ethereum Turing complete, so as to give maximum flexibility, but then add a way to constrain it, so that it didn't consume resources without end. That mechanism is gas. So, gas is a way of prepaying 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 be able to consume. When the smart contract is executed by the Ethereum virtual machine, the Ethereum virtual machine starts accounting for gas by debiting an amount of gas for every instruction executed by the smart contract. If, during this process, the smart contract runs out of the available gas in the transaction, it stops it. It forces it to have an upper limit on how much execution, how much resource can be consumed by any smart contract. There is also a gas limit for every block, which ensures that 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 that, as a result, has no ability of predicting how long a program will run and could create conditions where a single transaction takes forever to validate and locks up all of the processing of all of the computers participating in Ethereum. WinterMatico asks, Andreas, can you please explain how can I, as a smart contract developer, be able to know how much the execution of my program will cost on the blockchain? That's 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 contract can use. In fact, Turing proved that even long before stored program computers existed, smart contracts and blockchains existed, he proved that it's not possible to predict whether a certain execution path will be executed by a program, other than running it, and in running it you never know what's going to happen. You can estimate the amount of gas that is used by a smart contract, but you can never predict it accurately, because 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 that has a counter in it, and every time you call it with a transaction, it increases this counter, and the first 99 times you call it, all it does is 1 plus 1 equals 2. It does a simple addition, and that's going to cost a certain amount of gas. Let's say that costs 400 units of gas to run. It's a simple addition, but in that contract it looks at how many times it's been called, and on the 100th time it decides to do something else. On the 100th time it decides to run a hash function a million times. Now that's going to cost you, I don't know, let's say 5 million gas. So the difference between the 99 times you run this contract and it only consumes 500 gas, and the 100th time you run the contract when it consumes 5 million gas is simply the order of transactions. It's very simple to create contracts like that, it's also very simple to accidentally create contracts, where the amount of gas that's used varies considerably between one execution and the next, based on circumstances that you can't predict. Let's say for example that you estimate the amount of gas that's going to be used to call this contract, and your software estimates this based on you being the 98th transaction in a row. As you transmit your transaction to other transactions, first call that contract. That means your transaction is now the 100th transaction in a row, and instead of costing 500 gas, it costs 5 million to run your transaction. So you can't predict how the conditions will change until you actually run your transaction, and it's included in the block, because the transaction just before yours may change the state of the contract in such a way as to cause it to follow a completely different execution path, to call other contracts who knows what they're going to do, and to use gas in a completely unpredictable way. So this is one of the challenges with writing smart contracts, and actually the ability 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.