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?
Aniket
  • 3,545
  • 2
  • 20
  • 42

1 Answers1

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.

goodvibration
  • 26,003
  • 5
  • 46
  • 86
  • Thanks for the answer @goodvibration. Please update in the answer that what does optimization and runs signify? – Aniket Dec 17 '18 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 Dec 17 '18 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 Dec 17 '18 at 11:22
  • You can read most or all of it in the official documentation. – goodvibration Dec 17 '18 at 11:27
  • 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 Dec 17 '18 at 22:44
  • @RickPark: From what I tested, as you increase runs, at a certain point, the output byte-code remains identical. This has led me to understand that the compiler runs a certain number of iterations until reaching maximum optimization. – goodvibration Dec 18 '18 at 06:36
  • 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 Dec 18 '18 at 06:45