Learning Assembly

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

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.

Storage Efficiency

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

It is time to face the final trial, that of The Whisperer. This figure is one of legend. The master of riddles, secrets, and rumors. Every word they speak is true, but that doesn’t mean everyone has the wit to understand them. To pass their trial, prove that you are able to understand that which so many others cannot…

Inline assembly also enables the precise control of calldata. In this quest, learn how to exploit this ability to achieve hidden functionality like implicit call parameters and custom-encoded data.

The Whisperer is the custodian of calldata.

When a contract is called via an external call, the parameters are passed through a read-only data location called the calldata. During contract execution, the EVM will read from this location to know which function to run, with what arguments.

lightBulb

Let use take a look at some concrete examples.

When we call <code class="richtext rt-inlinecode">myFunction()</code>, since the function takes in no parameters, the calldata will simply be the selector, or the first 4 bytes of <code class="richtext rt-inlinecode">keccak256("myFunction()")</code>.

large_assembly_empty.webp

medium_assembly_empty.webp

small_assembly_empty.webp

thumbnail_assembly_empty.webp

When we call <code class="richtext rt-inlinecode">myOtherFunction(1, 2)</code>, the calldata start with the first 4 bytes of <code class="richtext rt-inlinecode">keccak256("myOtherFunction(uint256,uint256)"</code>, followed by <code class="richtext rt-inlinecode">abi.encode(1, 2)</code>.

mediaLibraryStrapi

In Solidity, calldata management is abstracted from us. However, learning calldata structure allows us to manually read calldata using inline assembly, allowing some interesting use cases:

<a class="richtext rt-link" target="_blank" rel="noopener noreferrer" href="https://github.com/Nodeguardians/ng-quests/blob/develop/campaigns/learning-assembly/calldata-manipulation/description/part1.md#your-task"></a>Your Task

Read the description above to understand EVM calldata.

What is Calldata?

Cryptomantic whispering can be a neglected art. But proper study in this discipline can unlock secret spells.

There is a common misconception that calldata must adhere to the expected function signature. We can actually append extraneous data to the expected calldata which can be read in inline assembly.

The <code class="richtext rt-inlinecode">WhisperV1</code> contract wishes to implement the following pure function.

Implement the functions in <code class="richtext rt-inlinecode">WhisperV1.sol</code> using only inline assembly. Make sure your solution respects Solidity's memory model!

Reading Hidden Calldata

The Whisperer murmurs to you. To pass this test, echo back his uttered words.

These are the opcodes that might be useful.

The old Whisperer never lies, so you can assume that there is data appended to back of the expected calldata. Since the functions do not formally take up any parameters, the expected calldata consists of only the function selector (i.e. is only 4 bytes long).

<a class="richtext rt-link" target="_blank" rel="noopener noreferrer" href="https://github.com/Nodeguardians/ng-quests/blob/develop/campaigns/learning-assembly/calldata-manipulation/solution/walkthrough2.md#reading-the-whispered-uint256"></a>Reading the "whispered" uint256

Read 32 bytes from calldata starting at position <code class="richtext rt-inlinecode">0x04</code>.

The previous solution will not work for <code class="richtext rt-inlinecode">string</code> (or for dynamic types in general) because we cannot assume their size.

Let us first understand how strings are the abi encoded via this <code class="richtext rt-inlinecode">"example"</code> string:

large_assembly_07.webp

medium_assembly_07.webp

small_assembly_07.webp

thumbnail_assembly_07.webp

Why is there an offset? The offset can be seen as a 32 byte pointer to the actual data in calldata. Imagine a function expecting multiple parameters, some dynamically size, some not. Because of pointers, all parameters are 32-bytes indexed, and can easily be retrieved.

If we call <code class="richtext rt-inlinecode">mintToken(1, 2, "monkey")</code>. The calldata will look something like this:

large_assembly_05.webp

medium_assembly_05.webp

small_assembly_05.webp

thumbnail_assembly_05.webp

Here is a possible solution to <code class="richtext rt-inlinecode">whisperString()</code>:

It seems superfluous to append hidden data at the back of expected calldata. But this is actually a method to allow default un-parametered functions like <code class="richtext rt-inlinecode">receive()</code> and <code class="richtext rt-inlinecode">fallback()</code> to informally accept parameters!

In this section, we explore the possibility of custom encoded data. Since encoding is not standard, we might want to use inline assembly to manually parse the data into Solidity datatypes.

The <code class="richtext rt-inlinecode">WhispersV2</code> contract wishes to implement the following function:

Similar to before, when <code class="richtext rt-inlinecode">compressedWhisper()</code><code class="richtext rt-inlinecode"></code> is called, extraneous data is appended to the back of the expected calldata. The supplementary data is a compressed uint256 array that follows custom encoding rules:

For instance, the uint256 array <code class="richtext rt-inlinecode">[0x01020304, 0x0102]</code> can be encoded into: <code class="richtext rt-inlinecode">0x0401020304020102</code>.

Implement the function in <code class="richtext rt-inlinecode">WhispersV2</code> using only inline assembly. Remember to respect Solidity's memory model.

Custom Encoding

The Whisperer begins to speak in enigmatic riddles. Answer them to continue the trial.

The Whisperer falls silent and nods to you. You feel a sense of contentment from him. It has been long since he has met a stranger with the understanding to follow his speech and answer his riddles. 

The fifth Pillar, the Wanderer is the explorer. One who walks the lands in search of new knowledge and secrets.

Behind you, the door to the balcony opens, and the other three Pillars join you to welcome you to their ranks. By passing their trials, you have proven yourself worthy of joining their number. The remaining Pillars gather around to acknowledge their new Wanderer.

It will take some time to learn your new responsibilities and tasks. However, you can relax that your new mantle will not prevent you from continuing to travel the world and seek out the unknown. 

You are led out onto a balcony, the feel of the wind cool on your face as the hood is removed. Only… you were sure you were underground…

At the edge of the balcony stands the Whisperer. Their face is covered by the cowl of their robe, leaving only their mouth exposed. They say nothing to you as you approach. You’ve heard rumors of the Whisperer. Everyone has, although most people believe them to be little more than a myth. Their realm is one of secrets, rumors, and the half-known, but every word that passes their lips is the truth.

You approach, and without preamble, the Whisperer begins to speak, almost too low to hear.

To pass this final trial, you will have to prove you can hear and understand the cryptic words of the Whisperer.

In this quest, we learned about calldata in the context of inline assembly.

To recap, the calldata related instructions are:

We have explored how to support extraneous calldata parameters. This is typically unnecessary and introduces unwanted complexity in your code. However, this can be used to support informal parameters in default functions like <code class="richtext rt-inlinecode">receive()</code> and <code class="richtext rt-inlinecode">fallback()</code>. The proxy pattern actually uses low-level calldata manipulation extensively.

<a class="richtext rt-link" target="_blank" rel="noopener noreferrer" href="https://github.com/Nodeguardians/ng-quests/blob/develop/campaigns/learning-assembly/calldata-manipulation/description/summary.md#supporting-custom-encoding"></a>Supporting custom encoding

Another interesting use case we have explored is to support non-standard encoded parameters. In our hypothetical example, we passed a uint256 array encoded in a compressed format. We then wrote a function that decompresses the data into a standard <code class="richtext rt-inlinecode">uint256[]</code>.

Calldata Manipulation

prelude