I have been trying to read into how via-ir works by reading the solidity docs, but I am confused how it works exactly. I see that you can avoid stack too deep errors by enabling it. From what I understand, it is because the optimizer uses yul to manage the variables state in memory instead of the stack. If that is correct, does using it create any security vulnerabilities for memory mismanagement? Has this been tested out or are there ways to test it? Is it secure for deploying a smart contract to mainnet?
- It is enabled in several contracts deployed by various renowned vendors (uniswap, etc).
- It is not enabled by default in the current most recent compiler version (0.8.21).
Neither one of these two points answers your question directly, and in fact, each one of them implies towards a different conclusion. But you may still want to take them into consideration.
Note that there are some known technical issues (not specific to security though), related to enabling it along with the optimizer; see for example this issue on HardHat’s GitHub repository.
2 Likes
The two major issues holding us back from making it the default are really the performance (still not good enough) and some adjustments needed in the Yul->EVM transform (i.e. you can still run into “Stack Too Deep” in some corner cases).
Has this been tested out or are there ways to test it? Is it secure for deploying a smart contract to mainnet?
There are no unresolved security issues. It has been thoroughly tested and we consider it on par with the legacy pipeline in this regard.
3 Likes
hi, sorry to revive this thread.
what is the current recommendation when you are forcibly using viaIR to avoid stack too deep errors?
For context I own an SDK that takes about 15s to compile, which I do not think is that long, but some users say the viaIR feature is experimental and do not want to use my code because it is not yet mainstream.
these developers are using legacy code that runs without viaIR at the expense of higher gas cost from optimizations in a newer SDK. So I wanted to know if my team should really focus as many efforts on solving stack too deep with pure debugging and Yul, or if in this case my users are in the wrong.
1 Like
some users say the viaIR feature is experimental and do not want to use my code because it is not yet mainstream.
The IR pipeline has been considered production ready since 0.8.13, which was released 3.5 years ago.
I think there is some confusion stemming from the fact that it is still not the default pipeline. But that has nothing to do with it being experimental or not. It’s simply not fast enough yet. We need to get the compilation time down to acceptable levels before we do that. The way its implemented also makes it a bit harder for debuggers to track variables on the stack, so it really needs ethdebug. It is superior to the evmasm pipeline in other aspects though. You should really not hold back with switching to it if you can live with those two downsides and it will only get better from here.
We are working on addressing the compilation time - it’s actually our main backend effort right now, in the form of the SSA-CFG stage of the pipeline, which will let us bypass some of the limitations of the current Yul optimizer. There was a presentation about it on Solidity Summit and we will also publish more about it on our blog soon.
BTW, we are also in the process of introducing the --experimental flag to more explicitly delineate what is and isn’t an experimental feature. Hopefully this will prevent misconceptions like this in the future. Though the fact that --via-ir used to be called --experimental-via-ir in past and the experimental part was dropped from it should be a hint too 