Persistence depends on where a value lives and how it is updated.
LET’S PICTURE IT
A notebook entry survives the meeting; a scratch calculation on a temporary board may not.
SEE IT FOR YOURSELF
Pack small values into Solidity storage slotsStep 1 / 4
In this simple default-layout example, two uint128 values come before one uint256. Each slot holds thirty-two bytes.
In this simple default-layout example, two uint128 values come before one uint256. Each slot holds thirty-two bytes.The first sixteen-byte value occupies the low-order half of slot zero. Low-order bytes are shown on the right.The second uint128 fits in the remaining sixteen bytes. Both values now share slot zero.C needs a complete thirty-two-byte slot, so it begins at slot one. Two packed small values plus C use two slots.
Animated local teaching model. No wallet, RPC or live blockchain data. Some labels and hashes are abbreviated for readability.
State variables belong to storage layout
A declared state variable can persist between calls. Its location and representation follow Solidity’s storage rules, including packing and inheritance context.
Locals support execution
Local variables can hold temporary values or references with specific data locations. A local copy of a number is not automatically a new persistent field.
References deserve extra care
For arrays, structs and other reference types, storage and memory annotations can determine whether code changes persistent data or operates on a copy. Similar-looking assignment syntax can have different effects.
Read the update path
The example computes next locally and then explicitly writes it into count. Without the assignment to the state variable, the computed value alone would not update persistent storage.
Read the example
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
contract LearningExample {
uint256 public count;
function increment() external {
uint256 next = count + 1;
count = next;
}
}
next is local; assigning count performs the persistent update.