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?
0 ·
Comments
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?
The "calcfee" function is most pertinent.
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.
Any revision of my foggy understanding of this would be appreciated, thanks.
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@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
s.profile
, and JS API haseth.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, theeth.transact
could provide an optional maximum gas used in simulo.(avoid contract developers all doing the sameeth.call
to see the result)- what is encoded is what determines the gas value
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