How will use of cpu resources or storage needs translate into gas usage? Any charts or guides?

Is there anything that simply shows required gas for certain operations? For example, if I dimension a contract to pay for storage of 500GB of data for 10 yrs, how much gas would the storer(s) require and the counterpart to verify through the EVM? Or what return would I have (ETH) if I was going to offer X computational resource (cpu power, space, etc)? I've looked at the formulas in the yellow paper but this isn't clear.


  • StephanTualStephanTual London, EnglandMember, Moderator Posts: 1,282 mod
    Nothing that high level like this I'm afraid, but this excel spreadsheet is IMHO slightly easier to consult than the YP, albeit a tad outdated.
  • rzurrerrzurrer Member Posts: 2
    Thanks for the reply.

    If anyone wants to help me derive such a set of calculations, I would be willing to sponsor a prize (if multiple people are interested) or fee for the work (if only a single person/group is interested).

    It would be interesting to have a calculator for investors to dimension possible ROI scenarios considering a set of variables for resource allocation into something like storage or CPU power to support the network. It could be somewhat similar to the mining calculators people created for Bitcoin back in the day. Ping me on Skype - rzurrer if anyone is interested.

  • tym4ttym4t Nagata-ku, Kobe-shi, Hyogo-ken, JapanMember Posts: 71 ✭✭✭
    Here's a good independent analysis that talks about this very question.
    There will inevitably be a number of under- and over-priced opcodes, for which their arbitrarily-assigned "gas" value is not representative of their true costs. For example, G_sha3, the cost of a basic SHA3 operation (before including input size), is currently set to be 10 times the cost of a basic one-cycle addition operation, despite being a vastly more complex operation that takes thousands of CPU cycles. SHA3 may be an underpriced opcode. Also, the actual processing cost of opcodes is unlikely to be identical for every miner or verifier. For example, some verifier's machines may contain a SHA-2 coprocessor.

    Contracts which use lots of underpriced opcodes may consume more actual CPU time than the miner had first predicted: a low gas_limit doesn't necessarily mean low CPU usage. Likewise, overpriced opcodes may yield more overall profit.

    Storage costs are particularly difficult to measure with the same units one uses for computation. Contract storage operations (G_sset) obligates the miner, and all verifiers, to store a word of data forever. There is a kind of refund mechanism that provides a weak incentive to free storage (R_sclear), but it is local to a single message, and is unlikely to effective in prompting contract authors to conserve storage space.
Sign In or Register to comment.