Table of Contents for How Ethereum memory works

Guide to memory on Ethereum

• memory on Ethereum is like the heap in other languages
• Memory is split into multiple 32 bytes
• There is no garbage collector
• You use memory when returning values from functions, logging messages, for arguments to function calls etc.
• memory is cheap to read from and write to (especially compared to storage).
  • It is cheaper to read/write to memory at low offsets. this is often not a consideration you have to think about, but is in the EVM to make it expensive to access lots of memory. The same does not apply for storage (where storage locations can be any of the 2^256 locations, with the same costs to access anywhere)

Solidity Assembly (yul) & memory

This section talks about assembly language (yul), but in normal day to day smart contract development you won’t need to use this info. I think explaining how it all works under the hood can help understand what is really going on.

There are four opcodes you will need to know:

• mload(location) to load 32bytes from memory, from an offset
• mstore(location, newVal) to store 32 bytes of data in memory at a specific offset (and mstore8(location, newVal) to store just a byte)
• msize() - the size of memory (this is actually just the largest accessed memory index, in the current transaction)

How Solidity uses memory

This section talks about how your Solidity code gets compiled. This section is not required in the EVM specs, it is just the convention that Solidity uses.

If you were to write things completely in assembly, you could invent your own system for the location of memory (but you probably shouldn’t!)

• first 4 bytes are scratch space.
  • memory location [0x00-0x20] (meaning starting at 0x00, going up to but not including 0x20) and [0x20-0x40]
  • The first four bytes are reserved as scratch space
• Then there is the free memory pointer
  • The next slot [0x40-0x60] is the free memory pointer
  • When you use more memory, your compiled Solidity code will update this to point to the new free memory location. This never goes down, only up.
• [0x60-0x80] are kept free
• then you are free to use from [0x80] onwards

Spotted a typo or have a suggestion to make this crypto dev article better? Please let me know!