Understanding Storage

In some specific cases, assembly, and its full control over memory, is the most efficient way to optimize a snippet of code.

Practice using inline assembly in your Solidity smart contracts to further optimize them, to an extent vanilla Solidity does not offer!

Assembly Optimization

The Solidity compiler packs state variables in a contract's storage space in a prudent manner. Walk through how the different types of variables are interpreted and kept in storage.

Storage Layout

Although found in niche use cases, the ability to discern a delegate call from an ordinary external call could be useful. Figure out how this can be done with some simple engineering.

Delegate Call Detection

To newer developers, the use of call() and delegatecall() can be intimidating. Especially since it seems more verbose or dangerous. However, these low-level calls are crucial to many use-cases. In this quest, learn the EVM Application Binary Interface (ABI) and how to safely use these calls.

Low-Level Calls

Inline assembly allows the fine-grained manipulation of EVM's unconventional memory model. In this quest, learn about the EVM memory model and how to exercise control over it.

Memory Manipulation

You have heard stories of lost temples deep inside the Black Forest, but you never thought you’d actually find one. You’ve found what you were looking for, but the temple’s protector looks like they have no intention of allowing you to get out alive…

Equipped with the knowledge of Solidity's storage model, we can now execute some gas optimization tricks. Explore how the reordering of state variables and the use of memory caching can save some functions a considerable amount of gas.

Study <code class="richtext rt-inlinecode">Elegy1.sol</code> and its differently sized variables. The code works, but is not gas efficient.

Unshuffle the variables to make variable assignment more gas friendly.

Rewrite <code class="richtext rt-inlinecode">Elegy1.sol</code> so as to make its construction more gas efficient. Make sure that the contract retains all its ABI and functionality.

Variable Packing

Decrypt the song for the bard to perform and calm the treant before it's too late.

It takes gas to write data into a single storage slot. Hence we want to minimize the number of times we write onto storage slots.

To solve this quest, We are looking to reorder the state variables in <code class="richtext rt-inlinecode">Elegy1</code>, such as the total number of storage slots they take up are minimized.

This way, during compilation, Solidity’s optimizer can merge multiple writes onto the same slot in <code class="richtext rt-inlinecode">setVerse(...)</code> into a single write, which will save gas.

Study <code class="richtext rt-inlinecode">Elegy1</code>’s initial variable order. Applying our knowledge from the first quest, storage should look like this.

medium_storage_07.webp

small_storage_07.webp

thumbnail_storage_07.webp

medium_storage_08.webp

small_storage_08.webp

thumbnail_storage_08.webp

Notice that we are writing onto 2 less slots than before. Thereby, when we call <code class="richtext rt-inlinecode">setVerse(...)</code>, the number of times we write onto a slot can be minimized by the Solidity optimizer. As a result, <code class="richtext rt-inlinecode">setVerse(...)</code> becomes cheaper!

Study <code class="richtext rt-inlinecode">Elegy2.sol</code> and its <code class="richtext rt-inlinecode">play()</code> function.

Rewrite <code class="richtext rt-inlinecode">Elegy2.sol</code>, specifically the <code class="richtext rt-inlinecode">play()</code> function, to make it more gas efficient.

Variable Caching

You’ve figured out the key to the scrolls. Quickly, translate the text so Cassilyn can perform the correct song!

In the EVM, persistent data is kept in the storage. Reading and writing to storage is generally gas expensive.

Conversely, non-persistent data (e.g. local variables in function execution) is stored in two possible locations:

The choice of whether to store data in the stack or memory is handled by the Solidity compiler.

Reading and writing to memory or the stack (i.e. local variables) is significantly cheaper in gas.

Observe <code class="richtext rt-inlinecode">play()</code>, notice that <code class="richtext rt-inlinecode">totalSum</code> is read and written on multiple times. To avoid this, we can create a temporary local value <code class="richtext rt-inlinecode">_totalSum</code>, and update it in our loop. Then, only write onto <code class="richtext rt-inlinecode">totalSum</code> after the value is finalized.

But wait, we can even do better. Observe that <code class="richtext rt-inlinecode">lines.length</code> is read in every iteration. To prevent this, we can just read <code class="richtext rt-inlinecode">lines.length</code> once, and cache it into memory as well.

Notice how now the number of storage reads/writes becomes 1 per value! Now, running <code class="richtext rt-inlinecode">play()</code> will be much cheaper.

As the treant’s branches raise over your heads, ready to strike, Cassilyn begins to sing. The music is surprisingly sorrowful but nevertheless enchanting. 

The treant slows, then retreats back to where it had been standing. As you watch, tears of pale sap run down its gnarled features. Is the creature mourning the memory of those who once inhabited this temple? How long has it been since it heard this music performed? 

What’s important is that it no longer shows any hostility towards you or your party. It simply watches as Cassilyn begins to gather the other scrolls. Nor does it move as you continue to explore the courtyard and, to your surprise, find a Node Stone. You’ve no idea how it came here, but you wrap it up to transfer to the nearest chapterhouse. 

Satisfied with your loot, you make to leave. Cassilyn, however, decides to stay. There is so much here to study, and she feels perfectly safe now she has the music required to calm the temple's protectors. Wishing her well, you begin your journey out of the Black Forest and back to civilization. 

mediaLibraryStrapi

........intruuuuuuuudeeeeeeeeeeeerrrrrssss?

The Treant raises its branches, thicker and stronger than any human arms, and smashes them into the ground. You attempt to back away, only to discover thin vines winding around your ankles, holding you in place. Nature itself guards this place! You can’t escape, and you have no chance of facing a Treant head-on. You need to find a different solution quickly, or you’re all dead! 

Look at the songs here! If we can perform them, it might appease the Treant!

The bard hurriedly begins to pick through the tattered scrolls, but it seems like they are encrypted with some ancient script! 

Help decrypt the writing on the scrolls so that Cassilyn can attempt to calm the rampaging treant before it’s too late…

In this quest, we learned how the ordering of variables can impact gas efficiency.

By strategically ordering storage slots such that variables share the same slot, the EVM can combine multiple reads/writes on the same slot into a single operation, saving gas.

It is also wise to reduce datatype sizes (e.g. from <code class="richtext rt-inlinecode">uint256</code> to <code class="richtext rt-inlinecode">uint128</code>) if it allows for better packing and it still fits within your needed integer constraints.

Unlike in storage, data in memory are not packed into slots. So you do not have to worry about the order of variables in memory.

It might also be pointless squeezing memory variables into smaller datatype sizes. The EVM performs arithmetic operations on 32 byte units. It takes more gas for the EVM to operate on <code class="richtext rt-inlinecode">uint128</code> than <code class="richtext rt-inlinecode">uint256</code> since it takes gas for the EVM to convert the smaller datatype into 32 bytes first.

Reading and writing on storage is more gas expensive than doing the same on memory. By temporarily caching storage values into memory, we minimize the number of reads/writes on storage, resultantly saving gas.

Storage Efficiency

prelude