Internal improvement: Add optimize flag to VyperSettings type in source-fetcher
#4735
Conversation
packages/source-fetcher/lib/types.ts
Outdated
| @@ -78,6 +78,7 @@ export interface SolcSettings { | |||
|
|
|||
| export interface VyperSettings { | |||
| evmVersion?: string; //not gonna enumerate these | |||
| optimize?: boolean; //warning: defaults to true if not specified! not currently supported by Etherscan | |||
There was a problem hiding this comment.
I'm confused by this comment for a non-functional change. How can optimize default to true and not supported by Etherscan?
There was a problem hiding this comment.
Ah, sorry, I should possibly rewrite that to be clearer. Well -- let me explain first and I'll see what you have to say.
By "optimize defaults to true if not specified", what I mean is that the Vyper compiler will treat optimize not being present the same as optimize: true. So, when I say "defaults to true if not specified", that's a comment about the Vyper compiler.
When I say that Etherscan doesn't support that flag, I mean that Etherscan doesn't give you any way to specify it when verifying, and, more specifically, when verifying always acts as if it was omitted. (So, Vyper contracts compiled with optimize: false currently cannot be verified on Etherscan, as there's no way for you to tell Etherscan that it was compiled with that option.) So, for Vyper contracts on Etherscan, optimize is always unspecified (meaning they are compiled with optimizations turned on).
(Note, btw, that this flag was only added in Vyper 0.3.1 -- prior to that, there was no way to turn off optimization.)
Actually, Etherscan currently doesn't allow you to specify evmVersion for Vyper either! I didn't realize that when I wrote the Vyper-handling code. But, oh well. I assume if they do ever allow that, it'll work just like for Solidity contracts, so the current code for that is fine.
By contrast, it's not clear how Etherscan would handle optimize if they ever supported that. Currently, if you get a Vyper contract off of Etherscan, it'll report OptimizationUsed: "0" (which for Solidity signals no optimization, as you might expect) even though in fact optimization was used! So, uh, it'd be quite premature to write code that attempts to handle however Etherscan might one day decide to report that a Vyper contract was actually compiled with optimization turned off...
There was a problem hiding this comment.
Wow that's valuable context surrounding optimize and evmVersion ! It's worth the extra comment verbiage to document the state of things.
There was a problem hiding this comment.
OK, I rewrote the comments, hoping this sufficiently explains the matter?
I noticed this was missing from the
VyperSettingstype. There's no functional change here as Etherscan doesn't currently support this flag, so there was no need to make any updates to make the fetcher support it, but I thought I'd at least update the type (and comments).