Contract pricing references

Theory

Practice

  • Default - 10 szabo for 1 gas or 100,000 gas = 1 ETH
  • Fee estimates - using Ethereum JavaScript and JSON-RPC API
  • Estimates are just very rough (can be much less precise than Bitcoin tx fees) estimates as execution paths depend on inputs
  • EVM compute operations are listed here - http://ether.fund/tool/gas-fees
  • The default cost is 10 szabo for 1 gas plus 21000 gas per transaction so tx fee is currently big part of the total cost. For example, if a SC were to only make the simplest contract execution would cost just a tiny bit more than 21000 gas.
  • The default value of gasprice is set by miners when running geth (--gasprice) is 10 szabo. Most people use the default, but it can be zero (in which case the miner would only earn tx fees) - see here for details. It seems there’s no real “market” for contract processing services yet and potential earnings are insignificant.

##Other

  • In a future version of Ethereum it may be possible to have the contract pay costs. “Innovation in payment schemes – for some dapps, “contract pays” is a better model than “sender pays” as senders may not have any ether; now, individual dapps can implement such models, and if they are written in a way that miners can statically analyze and determine that they actually will get paid, then they can immediately accept them (essentially, this provides what Rootstock is trying to do with optional author-pays, but in a much more abstract and flexible way).” - from Vitalik’s blog post)

##Appendix

###Beginning of Chapter 5 from Gavin’s Paper above

In order to avoid issues of network abuse and to sidestep
the inevitable questions stemming from Turing completeness,
all programmable computation in Ethereum is
subject to fees. The fee schedule is specified in units of
gas (see Appendix G for the fees associated with various
computation). Thus any given fragment of programmable
computation (this includes creating contracts,
making message calls, utilising and accessing account storage
and executing operations on the virtual machine) has
a universally agreed cost in terms of gas.
Every transaction has a specific amount of gas associated
with it: gasLimit. This is the amount of gas which
is implicitly purchased from the sender’s account balance.
The purchase happens at the according gasPrice, also
specified in the transaction. The transaction is considered
invalid if the account balance cannot support such a purchase.
It is named gasLimit since any unused gas at the
end of the transaction is refunded (at the same rate of purchase)
to the sender’s account. Gas does not exist outside
of the execution of a transaction. Thus for accounts with
trusted code associated, a relatively high gas limit may be
set and left alone.
In general, Ether used to purchase gas that is not refunded
is delivered to the beneficiary address, the address
of an account typically under the control of the miner.
Transactors are free to specify any gasPrice that they
wish, however miners are free to ignore transactions as
they choose. A higher gas price on a transaction will therefore
cost the sender more in terms of Ether and deliver a
greater value to the miner and thus will more likely be
selected for inclusion by more miners. Miners, in general,
will choose to advertise the minimum gas price for which
they will execute transactions and transactors will be free
to canvas these prices in determining what gas price to
offer. Since there will be a (weighted) distribution of minimum
acceptable gas prices, transactors will necessarily
have a trade-off to make between lowering the gas price
and maximising the chance that their transaction will be
mined in a timely manner.