Shulou(Shulou.com)06/01 Report--

This article focuses on "how to understand the location of solidity variables", interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn how to understand the location of solidity variables.

1. Ethernet Square Virtual Machine

Before I start to explore the data storage of Solidity, I would like to introduce some of the relevant content of the ethernet virtual machine to make it easier to understand the following parts.

The internal structure of EVM is roughly shown in the following figure:

When we installed the Ethernet Square client, it included EVM, a lightweight operating system designed to run smart contracts. The architecture of EVM is based on the stack machine model, which means that its instruction set is based on stacks rather than registers. The list of EVM opcodes is described in the Yellow Book, which can be found in the Ethernet Fong virtual machine opcode and instruction reference manual.

The execution process of the instruction in EVM is as follows: when a transaction triggers the execution of the intelligent contract code, the ROM of an EVM,EVM is instantiated to load the contract code to be invoked. The program counter is cleared, the storage is loaded from the corresponding part of the contract account, the memory is cleared, blocks and environment variables are set, and then the code starts execution.

2. Data storage location of Solidity variable

Now let's go back to the memory keyword. Starting with version 0.5.0, all complex types must explicitly specify the location of their stored data, and there are three optional data locations: memory, storage, and calldata.

Note: the only thing that can omit the data location declaration is the state variable, because the state variable is always stored in the account's storage.

Storage/ storage

The data in storage is permanent. Storage is a key/value library-the data in the storage is written to the block chain, so the state is modified, which is why storage is expensive to use.

It takes 20000 gas to occupy a 256bit slot.

Modifying the value of a storage slot that is already in use consumes 5000 gas

When a storage slot is cleared, a certain amount of gas is returned

Storage is allocated according to 256-bit slots, and even if one slot is not fully used, the overhead needs to be paid.

Memory/ memory

Memory is a byte array with 256 bits of slot size (32 bytes)

The data exists only during the execution of the function and is destroyed after execution.

Reading or writing a memory slot consumes 3gas

In order to avoid excessive workload of miners, the cost of single operation will rise after 22 operations.

Calldata/ call data

The call data is an immutable, non-persistent region that holds function parameters and behaves like memory.

Arguments to external functions must use calldata, but can also be used for other variables

Calling data avoids data copying and ensures that the data is not modified

Functions can also return arrays and results declared with calldata, but it is not possible to assign these types

3. Research on Solidity data location and assignment cost.

If you don't expect the contract code to behave unpredictably, it's important to understand how the assignment of the data location works.

Here are some rules for assigning values between variables in different locations:

The assignment between storage and memory (or calling data) creates a new independent copy

Assignments between memory only create references, which means that changes to one memory variable are also reflected on other memory variables that refer to the same data.

The assignment of a variable from storage to local storage actually gives only one reference

All other assignments usually result in a new copy of the data. For example, when assigning a value to a state variable or a member of a local variable located in a stored structure type, a new copy of the data is generated even if the local variable is only a reference.

Let's take a closer look at it using remix debugger:

/ / SPDX-License-Identifier: GPL-3.0pragma solidity ^ 0.7.0X contract DataLocationTest {uint [] stateVar = [1Magne4 case 5]; function foo () public {/ / case 1: from storage to memory uint [] memory y = stateVar; / / copy the content of stateVar to y / / case 2: from memory to storage y [0] = 12; y [1] = 20; y [2] = 24 StateVar = y; / / copy the content of y to stateVar / / case 3: from storage to storage uint [] storage z = stateVar; / / z is a pointer to stateVar z [0] = 38; z [1] = 89; z [2] = 72;}}

Create a new file with the above code, and then deploy the contract. Now try calling the function, and you will see the details of the transaction and the debug button next to it on the console. Click this button:

At this point, you should see that the debugger area looks like this:

Click the arrow marked in red in the image above to step through the code.

The first thing you should notice is to store the content loaded with stateVar, as we mentioned earlier in the EVM section, of course, there are no local variables.

As you continue stepping, you should see the variable y appear in the local variable area (Solidity Locals). As you continue to step through, you will also see that you need to execute a lot of bytecode to create the necessary memory space, load all data from storage and copy it into memory. This means paying more gas, so assigning values from the storage area to the memory area is very expensive.

Now let's look at the second case: assigning values from the memory area to the storage area. For example, when you have finished modifying memory variables, you may need to save the changes back to the storage area. It also consumes a lot of gas. If we calculate the remaining gas difference before and after stepping in the debugger, we can see that 17083 gas has been consumed. This operation uses four SSTORE instructions: the first to save the array size, consuming 800gas, and the other three to update the values of the array, each consuming 5000gas.

Next, let's look at the third case: assigning values from the storage area to the storage area. This time a new local variable is created to hold the value of stateVar. If we look at the execution of the code, we will notice that what Solidity does is push the address of the first storage slot onto the stack, which holds the length of the array. According to the documentation, for a dynamic array, the location of the slot contains the length of the array.

If we compare the cost of copying data into memory in different situations, then based on the above (update and copy back to storage: 21629 gas, create reference and update status: 5085gas), it is clear that the cost of the second option is much lower.

But if we want to update the status variable directly, for example:

StateVar [0] = 12

This is also possible, but if you are dealing with mapped and nested data types, using storage pointers will make the code more readable.

At this point, I believe you have a deeper understanding of "how to understand the location of solidity variables". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.