flâneur — a map of the web's best reading

Ethereum Virtual Machine — Storage layout | by Steve Ng | Medium

steveng.medium.com · 1,281 words · saved by 1 readers

In the earlier part 1 post, we describe EVM as a stack-based virtual machine and how Solidity compiles down to ByteCode which is a set of opcodes that will be executed by EVM. This post will describe how EVM stores data in storage and memory. There are in total 3 types of data locations: memory, calldata and storage. This is used to hold temporary values and only exists within the scope of the function call. However, they are mutable within the function call. Like memory, this is used to hold temporary values and erased between function calls. However, it is immutable within function call and is slightly cheaper in gas cost as it skipped copying the values into memory sload and sstore and read directly from call data (cheaper in gas, see calldataXxx opcodes). Calldata can only be specified in function argument. Each smart contract maintains its own storage. This persistent storage is basically a key-value mapping with 2 ²⁵⁶ keys mapped to each value of 32 bytes. Smart contract can read

Ethereum Virtual Machine — Storage layout Steve Ng 6 min read · Nov 22, 2022 -- 1 Listen Share Introduction In the earlier part 1 post , we describe EVM as a stack-based virtual machine and how Solidity compiles down to ByteCode which is a set of opcodes that will be executed by EVM. This post will describe how EVM stores data in storage and memory. Type of data location There are in total 3 types of data locations: memory, calldata and storage. 1. Memory This is used to hold temporary values and only exists within the scope of the function call. However, they are mutable within the function c

Explore this link on the map →

related reading