All right, great. So we've just made our contract a little bit more gas efficient. Little gas efficiency improvements are going to be concepts I sprinkle throughout this course. And when we get to the more advanced section, I'm going to break down exactly what's going on

and why all these gas efficiencies exist and what's going on behind the scenes for these gas efficiencies to occur. It's a little bit in the weeds, which is why I'm going to gloss over it right now. So if it's confusing, don't worry. I wouldn't

let these gas efficiencies be the thing that slows you down. Awesome. So we have these two gas optimizations. How else can we make this contract a little bit more gas efficient? Well, one of the ways we can make this more gas efficient is by updating our requires. Right now, with our

require statement, we actually have to store this "sender is not an owner" as a string array. Every single one of these characters in this error log needs to get stored individually. This string may not seem very big, but it's a lot bigger than the alternative with what we

can do as of 0.8.4 of Solidity. You can now actually do custom errors for our reverts. We declare them at the top and then use ifs instead of require and then just add a revert statement. This ends up saving a lot of gas since

we just call the error code as opposed to calling the entire string associated with the error. So, for example, with our require down here and with actually with all of our requires, what we could do is instead of having this require, we could create a custom error. So at the top, what we could do is we

could say error not owner and you'll notice that this is actually outside of the contract here now what we can do is we can take this error owner scroll down into our only owner instead of doing a require we'll do an if statement we'll say if

message dot sender is not owner then we're going to go ahead and revert with a not owner error this ends up saving us a lot of gas since we don't have to store and emit this long string here now in a lot of code today you'll still see

require a lot of places because these these custom errors are pretty new in solidity so you'll want to get used to writing it both ways I wouldn't be surprised if in the future the syntax for some of these errors looks like this so that it's more readable but for now

if you want to do a more gas efficient way than requires you can use something like this we could update all of our requires here for these custom errors but for now I'm going to leave both in just to show you the differences this revert keyword does the exact same thing

that require does without the conditional beforehand so you can actually go ahead and revert any transaction or any function call in the middle of the function call

Lesson 4 Part 23 | Advanced: Custom Errors - Solidity & Foundry Full Course

Book a smart contract audit here 👇
https://www.cyfrin.io/


Cyfrin Audits

Introduction to Gas Efficiency in Smart Contracts

Minor gas efficiency improvements will be discussed throughout the course.

A detailed explanation of gas efficiency will be provided in a later, more advanced section.

Two gas optimizations are already implemented.

Optimizing `require` Statements with Custom Errors

Current `require` statements store error messages as strings, which is inefficient.

Solidity 0.8.4 introduced custom errors for reverts, saving gas.

Example of creating a custom error and using it with an `if` statement and `revert` instead of `require`.

Many existing codes still use `require` due to the recency of custom errors.

Future syntax improvements for custom errors are anticipated.

Both `require` and custom error methods are shown for comparison.

The `revert` keyword functions similarly to `require` but without the conditional.

Lesson 4 Part 23 | Advanced: Custom Errors - Solidity & Foundry Full Course

Lesson 4 Part 23 | Advanced: Custom Errors - Solidity & Foundry Full Course

Scripts