{Solidity:​log}

Posted by Solidity Team on July 12, 2024

In its current default settings, the Solidity compiler does not transform the code into any intermediate representation (IR) for generating EVM bytecode but does it in a direct fashion. There is, however, the more recently developed via-IR compilation pipeline , which employs the Yul programming language as an intermediate representation. On a high level, the compilation steps of the two pipelines look like the following: compilation-pipelines In this blog post, we will be taking a closer look at the details of via-IR, understand...

Posted by Solidity Team on January 26, 2024

Solidity 0.8.24 supports the opcodes included in the upcoming Cancun hardfork and, in particular, the transient storage opcodes TSTORE and TLOAD as per EIP-1153. Transient storage is a long-awaited feature on the EVM level that introduces another data location besides memory, storage, calldata (and return-data and code). The new data location behaves as a key-value store similar to storage with the main difference being that data in transient storage is not permanent, but is scoped to the current transaction only, after which...

Posted by Kamil Śliwak, Matheus Aguiar on February 22, 2023

The highlight of Solidity 0.8.19 release is the support for defining operators on user-defined value types (UDVTs). If you have not been keeping up with recent features, UDVTs are a new class of types introduced in Solidity 0.8.8. They provide an abstraction over an elementary value type that results in a completely new type. This is similar to creating an alias, but the new type is distinct from the underlying value type and all other UDVTs derived from that underlying type. The ability to use operators...

Posted by Solidity Team on September 27, 2021

Solidity v0.8.8 introduces user defined value types as a means to create zero-cost abstractions over an elementary value type that also increases type safety and improves readability. Motivation A problem with primitive value types is that they are not very descriptive: they only specify how the data is stored and not how it should be interpreted. For example, one may want to use uint128 to store the price of some object as well as the quantity available. It is quite useful to have stricter type rules to avoid...

Posted by Franziska Heintel on May 3, 2021

Some time ago we decided to get a domain that the Solidity team has easy access to in order to streamline efforts and initiatives that were hosted on other domains before. And so soliditylang.org was born! 🎉 We announced most of these domain changes individually on Twitter, but we want to take a moment to also officially announce it here on the blog and explain the various subdomains we have now, what they are for and which older domains may be deprecated in the future. In short,...

Posted by Solidity Team on April 21, 2021

Starting from Solidity v0.8.4, there is a convenient and gas-efficient way to explain to users why an operation failed through the use of custom errors. Until now, you could already use strings to give more information about failures (e.g., revert("Insufficient funds.");), but they are rather expensive, especially when it comes to deploy cost, and it is difficult to use dynamic information in them. Custom errors are defined using the error statement, which can be used inside and outside of contracts (including interfaces and libraries). Example The following contract...

Posted by Christian Reitwiessner on March 2, 2021

Solidity v0.8.2 adds a simple inliner to the low-level optimizer of Solidity. In this post, we examine how it works and take a look at synergies with other steps of the optimizer. Low-Level Inliner The Low-Level Inliner is a component of the low-level optimizer of the Solidity compiler. To save gas, it can inline short functions that do not contain control-flow branches or opcodes with side-effects. The decision to inline or not is based on the trade-off parameter "runs": The combined code deposit cost and execution...

Posted by Franziska Heintel on February 15, 2021

The Solidity programming language is an open-source project governed by a core team. We rely on the community’s feedback, input and contributions to make the language as effective, safe and useful as possible. In this post, we will walk you through the various different ways how you can get involved contributing to Solidity! Do not hesitate to contact us in case anything is left unclear after reading the post. Overview of Contribution Opportunities There are plenty of options how you can contribute to...

Posted by Bhargava Shastry on February 10, 2021

Security vulnerabilities and bugs detract from software quality. To discover them early, at best before they are released, we have adopted fuzz testing: feeding randomly generated programs to the Solidity compiler and observing the compilation runtime and code generated. Since Q1 2019, the Solidity compiler is fuzz tested via Google's open-source software fuzz (oss-fuzz) framework. In this post, we briefly describe the work that has been done on this front, and work that is currently in progress. Fuzzer Overview Broadly speaking, we have developed two...

Posted by Franziska Heintel on June 25, 2020

Welcome to Sourcify's first short FAQ! If your questions around source verification haven't been answered after reading this post, please feel free to drop by the Sourcify Gitter channel and ask us any question there. Also stay tuned on more tutorials and developer focused content to follow here and on the Remix blog! Source Verification What is source verification? Solidity contract source code can be verified by checking whether the on-chain deployed code is matching with published source code files. In order to allow for source...

Posted by Elena Gesheva on June 18, 2020

Similar to object-oriented programming in Solidity - a contract-oriented language - the inheritance and polymorphism features are as widely adopted and critical for the language evolution. There is hardly any Solidity developer who hasn't used these language features in their contracts to decouple logic and increase code reuse. With version 0.6 of the language the main improvements introduced are to make existing rules explicit in addition to introducing interface inheritance and disallowing the dangerous state variable shadowing. The compiler continues...

Posted by Solidity Team on May 26, 2020

Starting from version 0.6.0, Solidity supports array slices. Array slices are handy when you want to reference a contiguous portion of an array but do not want to perform a full copy of that portion. For now, array slices are only supported for calldata arrays. How to use Array Slices The expression x[start:end] references a portion of the calldata array x starting at index start and ending just before index end. Both start and end are optional. If not provided, start defaults to 0 and end defaults...

Posted by Daniel Kirchner on May 13, 2020

With version 0.6.5, Solidity introduced the immutable keyword for state variables. Immutable state variables can only be assigned during contract creation, but will remain constant throughout the life-time of a deployed contract. The big advantage of immutables is that reading them is significantly cheaper than reading from regular state variables, since immutables will not be stored in storage, but their values will be directly inserted into the runtime code. How to use Immutables Immutable state variables can be declared using the immutable keyword. They cannot be read...

Posted by Elena Gesheva on March 26, 2020

In versions of Solidity before 0.6.x, developers typically used the fallback function to handle logic in two scenarios: contract received ether and no data contract received data but no function matched the function called The main use case of the pre-0.6.x fallback function is to receive ether and react to it, a typical pattern used by token-style contracts to reject transfers, emit events or forward the ether. The function executes when a contract is called without any data e.g. via .send() or .transfer() functions. The 0.5.x syntax...

Posted by Elena Gesheva on January 29, 2020

This post was originally published on the Ethereum blog. The try/catch syntax introduced in 0.6.0 is arguably the biggest leap in error handling capabilities in Solidity, since reason strings for revert and require were released in v0.4.22. Both try and catch have been reserved keywords since v0.5.9 and now we can use them to handle failures in external function calls without rolling back the complete transaction (state changes in the called function are still rolled back, but the ones in the...