Solidity: Smart Contract Language Series 4 – Data Storage Location Analysis Solidity has been updated to read for real

Solidity Tutorial Series part 4 – Solidity Data Location Analysis.

Writing in the front

Solidity is the Ethereum Smart Contract programming language. Before reading this, you should know something about Ethereum, smart contracts, and if you don’t already, what is Ethereum

This section is not very clear-cut in the official English documentation so I have included in-depth analysis along with the official Solidity document (latest version: 0.4.20). Please subscribe.

Data Location

In the first of the series we mentioned that Solidity Types are divided into two Types: Value Types and Reference Types. We covered the Value Types earlier and will cover Reference Types next.

Reference types are complex types that take up more than 256 bits of space and are expensive to copy, so we need to consider where to store them in memory. All complex types like arrays and structs have an additional property: the data location. Can be memory or storage.

Depending on the context, most of the time the data location has a default value, which is also modified by specifying the keywords storage and memory.

Function arguments (including returned arguments) default to memory. Local complex type variables and state variables default to storage.

Local variable: a locally scoped (out-of-scope, unreachable, waiting to be reclaimed) variable, such as a variable within a function. State variables: Public variables declared within the contract

Another storage location is callData, a data location used to store function parameters that is read-only and not permanently stored. Arguments to external functions (excluding return arguments) are forced to be callData. The effect is similar to memory.

Data location specifications are important because they affect assignment behavior. Assigning values between memory and storage or to state variables always creates a completely independent copy. Assigning a storage state variable to a storage local variable is passed by reference. So for local variable modification, also modify the associated state variable. On the other hand, assigning one memory reference type to another memory reference does not create a copy (i.e., reference passing between memories).

  1. Note: You cannot assign memory to local variables.
  2. For value types, copies are always made.

Let’s look at some code:

Pragma solidity ^ 0.4.0; contract C { uint[] x; // X is stored in storage. // memoryArray is stored in memoryfunctionf(uint[] memoryArray) public { x = memoryArray; // Copy from memory to storage var y = x; // storage reference passes local variable y (y is a storage reference) y[7]; // return y.length = 2; // x is also modified delete x; // y = memoryArray; // y = memoryArray; // delete y; g(x); // Pass by reference, g can change the contents of x h(x); // Copy to memory, h cannot change the contents of x}function g(uint[] storage storageArray) internal {}
    function h(uint[] memoryArray) public {}
}
Copy the code

conclusion

Forced Data Location

  • External function parameters (excluding return parameters) are mandatory: calldata
  • State variables must be storage

Default Data Location

  • Function argument and return argument: memory
  • Local variable of complex type: storage

In-depth analysis

The storage structure is determined when the contract is created and depends on the state variables declared by the contract. But the content can be changed by the call.

Solidity calls this state change, which is why contract-level variables are called state variables. You can also better understand why state variables are stored in storage.

Memory can only be used inside functions, and the memory declaration is used to tell EVM to create a (fixed-size) memory area for variables to use at runtime.

Storage is stored as a key/value in a blockchain, while memory is represented as an array of bytes

About stacks

EVM is a stack-based language. The stack is actually a data structure in memory. Each stack element is 256 bits and the maximum length of the stack is 1024 bits. Local variables of value types are stored on the stack.

Consumption of different storage (GAS consumption)

  • Storage will permanently store the contract state variable, which is the most expensive
  • Memory only holds temporary variables, which are released after function calls, with minimal overhead
  • Stack holds small local variables and is almost free to use, but limited in number.

Refer to the video

We also have the most comprehensive video course on the market: In-depth Solidity, the Ethereum Smart Contract language. We are currently looking for course experiential experts, check out the link.

The resources

Official Solidity documentation – Type

Blockchain in Simple terms – systematic learning of blockchain to create the best blockchain technology blog