5

This is about the parameters that we need to provide at the time of source code verification on Etherscan. I have a bit idea about it but i am looking for some deep and clear explanation.

So my question is what are these parameters i.e runs and optimization all about. Answer can consist the detail about:

  • How they exactly affect the source code verification?
  • Why enabling optimization sometimes prevents smart contract verification?
  • Why we usually pass 200 to runs?
Improve this question

1 Answer 1

Reset to default
4

How they exactly affect the source code verification?

If you pass to Etherscan different parameters than the ones you've used when you compiled the contract and deployed it, then the verification might fail because those different parameters might lead Etherscan compilation to generate a different byte-code than the byte-code that your compilation has generated.

Why enabling optimization sometimes prevents smart contract verification?

If you compile your contract without optimization, but you enable optimization on Etherscan, then the output byte-code of your compilation and of Etherscan compilation might be different, in which case the verification will fail.

Why we usually pass 200 to runs?

Because this is the Solidity Compiler default value.

Improve this answer
7
  • Thanks for the answer @goodvibration. Please update in the answer that what does optimization and runs signify?
    – Aniket
    Commented Dec 17, 2018 at 10:28
  • @A.K.: optimization can be either true or false, and it indicates whether or not the compiler should optimize the code. AFAIK, in our eco-system here (block-chain), 'optimize' translates to 'reduce gas consumption (in opposed to 'increase speed' or 'reduce memory consumption' on traditional eco-systems). optimization-runs indicates the number of iterations that the compiler should perform during the optimization process.
    – goodvibration
    Commented Dec 17, 2018 at 11:22
  • On every iteration, the compiler may improve the code a little bit more. Of course, at some point, depending on your specific code, there's no added value in increasing this value. You can find the minimum value of runs which yields maximum optimization, by trying different values, until you find a point where the output byte-code remains identical (binary-search would be ideal for that). Alternatively, you can just use a very large value to begin with.
    – goodvibration
    Commented Dec 17, 2018 at 11:22
  • 1
    I think that the optimization process description can be misleading. From the official docs: By default, the optimizer will optimize the contract assuming it is called 200 times across its lifetime. If you want the initial contract deployment to be cheaper and the later function executions to be more expensive, set it to --runs=1. If you expect many transactions and do not care for higher deployment cost and output size, set --runs to a high number. This means that if you set to 200 it assumes that the smart contract shall be called 200 times in its life. And optimizes accordingly.
    – Rick Park
    Commented Dec 17, 2018 at 22:44
  • 1
    The mechanism is somehow different, @goodvibration: the optimizer calculates for each possibility the cost using that parameter. F.i. Can try to decide to add a temporary variable somewhere, but this shall cost some more gas in deployment versus a lower gas cost when running on mainnet. At that point it calculates how much gas should be saved running the program ‘runs’ times and how much gas it should cost to implement that optimization. If the saving is higher than this cost it makes the modification. This is the basilar scheme. For ‘runs’ higher than a certain value, it apply all he can.
    – Rick Park
    Commented Dec 18, 2018 at 6:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.