#### Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

# Calculating the number of operations in a contract's execution.

edited April 2014
Gas, a contract needs gas to run, and some small amount, a unit, of gas is "burned" or required to fuel a single operation. The cost of an Ethereum contract, the cost to execute that contract is measured in units of gas, which are some division, some fungible measure of an ether, some Ethereum currency unit, or a subdivision of that unit.

How does one calculate the amount of gas needed to run a contract?

In the early stages of exploring this calculation, perhaps we should write some code that calculates the number of operations a contract executes, and then in the future that number of operations can then be converted to some equal units of an ether currency unit, or subdivision of an ether currency unit.

How would one calculate the number of operations in an LLL script, or in an HLL script that runs a contract?

Are we calculating operations of bytecode execution, or operations in the higher level language?

• My understanding of "gas" is that contract operations that are processed by Ethereum mining nodes, by the CPU of some miner, or the GPU of some miner, this is the "gas". And for that gas provisioning, a miner must get a payment, and that payment is fee in the form of some Ethereum cu., (currency unit), is this correct?
• Yes, conceptually the miners require gas in order to fuel the execution of contracts.

Gas is provided in the transaction that activates the contract as two variables "gas" (amount) and gasPrice (in wei) - currently the minimum gasPrice is 10 szabo. Gas is consumed by each instruction in the contract (some cost more than others) until it is depleted or the contract terminates. When the contract terminates, any unused gas is returned to the sender.

This gasPrice mechanism allows the ETH/gas ratio, or the cost of execution, to be set to a level the network will accept on a per transaction basis. In theory this automatically drives the transaction fee down to the actual (hash-power-weighted average) cost of processing a transaction.
• ``` gasValue = gasAmount * gasPrice thisOperationCost = 0 for operation in contract: thisOperationCost = calculateOperationCost(operation) if gasValue >= thisOperationCost: executeOperation(operation) gasValue = gasValue - thisOperationCost if gasValue > 0: returnRemainingGas(gasValue) ```

Will there be some algorithm to determine the cost of an operation, will that cost vary according to network difficulty, or contract length and other factors?
Feel free to dig here: https://github.com/ethereum/pyethereum/blob/master/pyethereum/processblock.py

The "calcfee" function is most pertinent.
• <- Dives deep. Thank you @Vitalik
• @tjade273? The part of the payment transaction that funds execution of a contract is given in two parts - "gas" which represents the basic unit cost of each of the opcodes being executed (based on the values coded into the software), and "gas price" which specifies the value of gas units in wei. Any miner who thinks the gas price is sufficient will execute the contract at that price.
• Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
If you run out of gas early, what happens. I hope the changes get cancelled!? I mean otherwise presumably all sorts of nasty things can be done using partial execution!

I should probably have figured out both of these questions, but can contract buy some more gas for the user? That way the user isnt as dependent on the (wallet satelite)contract if is funds are low, but contract writers can still be less concerned about determining how much gas everything costs.
• So one can increase the likelihood that their contract call will execute faster than others, because, miners find the reward more attractive. So gas is an arbitrary unit, and only takes on value when we specify the price of the gas. For example, my contract takes 20 gas units to execute the OPcodes, and I assign each gas unit the value of a single wei. Another contract also requires 20 units of gas to run, to execute its OPcodes, but those gas units have had an ether assigned to each gas unit. So, the second contract in the example has a higher probability of being executed first. So, the miner wants to execute contracts which have more valuable gas units, yes?

Any revision of my foggy understanding of this would be appreciated, thanks.
• Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
@ethergrok heard some stuff about voting being used for pricing, and trying to prevent pricing being used as incentive. (not entirely sure though)

I was wrong, reading vitalik's (neat)code it does cancel everything it did. Looks like gas is not refunded aswel. `block.coinbase` seems to get more if the gas isnt used.(not sure why about that one) Also probably as it should be, i think i should do the 'trust but verify' thing • edited September 2014
What I don't understand is, why does the gas price need to be stated explicitly if the average cost per processed byte can be determined as @Chris613 also stated in an earlier post. The only way I can see a use for specifying the gas price when executing a contract function is if the gas price acts as some form of incentive to the miners?

@Stephan_Tual‌ gave some clarity on the gas pricing in the following comment if anyone is interested: http://forum.ethereum.org/discussion/comment/6318#Comment_6318
• I might be wrong on this, but I'm pretty sure calculating the amount of gas a contract will need to run given some input is the same or related to the halting problem. finding a solution to this problem will probably earn you a few awards as well as some significant advancements in AI.
• Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
@EluavsMoloch the theorem says that programs exists for which you can't calculate if it is stops, not that all of them are like that. For particular cases, it can be trivial to calculate, and this will probably go for most contracts. A simple way to calculate the gas the contract use is.. to just run everything in simulation. Pyethereum has a function for that, `s.profile`, and JS API has `eth.call`. Note, however, the 'simulated call' might operate a different state than the current, as transactions are processed before, and using the simulation doesnt help against unexpected cases, because.. you get the same unexpected result from the simulation. So i would suggest using an independent way to estimate a gas limit to choose. I feel perhaps, the `eth.transact` could provide an optional maximum gas used in simulo.(avoid contract developers all doing the same `eth.call` to see the result)
• edited December 2014
the miner wants to execute contracts which have more valuable gas units, yes? [edited by admin: remove obnoxious whitespace & signature]
Post edited by Jasper on
• gas is calulated based on payload - so the length of the string
- what is encoded is what determines the gas value
• Maybe an example would be helpful.
Can someone give a rough idea about the specific script operations (e.g. step, sha3, call etc.) needed for transactions that make the following requests:
1) create a token that represents stock in a company
2) change the owner of this stock