Explainers

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... [Read More]

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. [Read More]

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... [Read More]

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... [Read More]

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. [Read More]

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. [Read More]

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. [Read More]

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 turorials and developer focused content to follow here and on the Remix blog! [Read More]

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... [Read More]

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. [Read More]

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. [Read More]

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... [Read More]

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... [Read More]