{ skip to content }

Solidity 0.8.28 Release Announcement

Posted by Solidity Team on October 9, 2024

Releases

We are excited to announce the release of the Solidity Compiler v0.8.28.

This latest version of the compiler brings full support for transient storage state variables of value types, improvements that will speed up compilation via IR and significantly lower memory usage, some bugfixes, and more!

Notable Features

Support for Transient Storage Value Type State Variables

The previous release of the compiler (v0.8.27) introduced support for transient storage variables into the parser (see Additional Notes). This meant that the compiler could accept the syntax for marking some variables as transient and allowed users to generate transient storage layout.

However, it was previously not possible to generate bytecode for contracts using such variables. This newest release of the compiler provides full support for transient state variables of value types, in both the IR and legacy pipelines.

You can check the new docs to learn more about transient storage.

šŸ’” Note: If you want to promote a state variable in storage to transient storage, but don't want the storage layout to be affected for subsequent state variables, you need to add a dummy state variable of the same type in place of the promoted one, since storage layout and transient storage layout are independent.

Generating JSON representations of Yul ASTs only on demand

The compiler internally caches most of the outputs it generates, so that they can be reused. This is beneficial in situations such as requesting both --abi and --metadata at the same time (since the former is also embedded in the latter) or when there is a bytecode dependency between contracts (the intermediate Yul code has to only be generated once).

In some cases, however, this caching turned out to be overly eager. Especially when it comes to large projects and JSON artifacts, the data is large and accumulates quickly, taking up a lot of memory. Since artifacts like Yul ASTs are not reused yet, this cost was not actually resulting in improved performance, making it a bad trade-off.

Additionally, some of the recently introduced artifacts, such as Yul ASTs, being considered experimental, were not yet integrated into the compiler's lazy output evaluation mechanism, which meant that they incurred the memory and performance cost even when not explicitly requested.

This release eliminates some of the caching, reducing memory usage in IR compilation of real projects by up to 80%. It also prevents Yul ASTs from being generated when not explicitly requested, which reduces the running time of the IR pipeline by up to 25%.

Below you can see the changes in overall compilation time and RAM usage for compilation with bytecode generation via IR and full optimization in a few popular projects we benchmarked:

FileTime (0.8.27)Time (0.8.28)Change
openzeppelin40 s35 s-13%
uniswap-v4157 s128 s-18%
eigenlayer716 s545 s-24%
FileMemory (0.8.27)Memory (0.8.28)Change
openzeppelin1220 MiB506 MiB-59%
uniswap-v44805 MiB1496 MiB-69%
eigenlayer20346 MiB4455 MiB-78%

Per-contract pipeline configuration

The compiler has a mechanism for lazy evaluation, which allows it to execute only as much of the compilation pipeline as necessary to generate the requested outputs. The only mandatory stages are parsing and analysis, necessary to detect and display errors in the source. The information produced by analysis is enough for outputs such as ABI, metadata, Solidity AST or storage layout. If bytecode or IR are not requested, the later stages, i.e. code generation, optimization and bytecode generation may be skipped.

Until now, the simple design of the mechanism meant that the pipeline always had to run the same stages for all contracts. As a consequence, requesting bytecode for even one contract resulted in unnecessary bytecode generation for all of them, even though the output was ultimately discarded. This release eliminates this limitation.

The change is not expected to affect simple compilation workflows, as there's little reason to request different outputs for different contracts when compiling the whole project from scratch. However, it may allow frameworks to implement more advanced workflows where recompilation of modified code is sped up by caching the outputs and only selectively requesting the ones that are expected to change.

Note that the change only affects the Standard JSON interface, since per-contract output selection is not available via the CLI.

Full Changelog

Language Features

  • Transient storage state variables of value types are now fully supported.

Compiler Features

  • General: Generate JSON representations of Yul ASTs only on demand to reduce memory usage.
  • Standard JSON Interface: Bytecode or IR can now be requested for a subset of all contracts without triggering unnecessary code generation for other contracts.

Bugfixes

  • SMTChecker: Fix SMT logic error when assigning to an array of addresses.
  • Yul AST: Fix shifted native source locations when debug info selection included code snippets.

Build System

  • Removed USE_LD_GOLD option and default to use the compiler default linker. For custom linkers, CMAKE_CXX_FLAGS can be used.

How to Install/Upgrade?

To upgrade to the latest version of the Solidity Compiler, please follow the installation instructions available in our documentation. You can download the new version of Solidity here: v0.8.28.

If you want to build from the source code, do not use the source archives generated automatically by GitHub. Instead, use the solidity_0.8.28.tar.gz source tarball or check out the v0.8.28 tag via git.

And last but not least, we would like to give a big thank you to all the contributors who helped make this release possible!

Next post

Get involved

GitHub

Twitter

Mastodon

Matrix

Discover more

BlogDocumentationUse casesContributeAboutForum

2024 Solidity Team

ā€¢

Security Policy

ā€¢

Code of Conduct