การเพิ่มประสิทธิภาพพื้นที่จัดเก็บ

Contract storage is a giant array of 32-byte slots, indexed from slot 0. State variables are assigned to slots in declaration order.

Every slot you write costs gas, so the fewer slots your data occupies, the cheaper your contract is to use. Understanding the slot layout is the foundation of storage optimization.

The Solidity compiler packs multiple small variables into a single 32-byte slot when they fit consecutively.

A uint128 uses 16 bytes, so two of them share one slot. A bool uses 1 byte and a uint8 uses 1 byte. Packing reduces both deployment and runtime storage costs.

Packing only works for variables that are adjacent in declaration. A poorly ordered layout wastes slots.

In the bad example below, the uint256 forces the two uint128s into separate slots. Reordering so the small types are together lets them pack.

Smaller integers only save gas when they pack. A lone uint8 in its own slot is not cheaper than a uint256, and may even cost more because of masking operations.

Rule of thumb: use uint256 by default, and only downsize when you can fit several small values into one slot.

Structs follow the same packing rules. Order struct members so small types group together. A well-packed struct can cut the number of SSTORE operations dramatically.

Values that never change should not live in storage at all.

• constant — inlined into bytecode at compile time, zero storage
• immutable — set once in the constructor, stored in bytecode not storage

Both avoid expensive SLOAD operations entirely.

Mappings and dynamic arrays do not pack. Each entry occupies its own slot computed by hashing the key with the base slot.

You cannot pack across mapping entries, but you can pack the struct stored as a mapping value. Designing the value struct to fit in fewer slots saves gas on every write.

Reading a storage variable repeatedly inside a function pays for each access. Copy it into a local memory variable once, then use the local.

This is especially valuable inside loops, where each iteration would otherwise re-read storage.

When updating multiple fields of a packed struct, load the struct into memory, modify it, then write it back once. The compiler can combine adjacent fields into a single SSTORE.

Writing fields one at a time may trigger multiple read-modify-write cycles on the same slot.

Initializing a slot from zero to non-zero costs 20000 gas, while updating an already non-zero slot costs only 5000 gas.

This is why some contracts pre-warm slots or use a sentinel value (like 1 instead of 0) to keep slots non-zero, trading a one-time cost for cheaper repeated updates.

When auditing storage for gas:

• Group small types so they pack into shared slots
• Use constant / immutable for fixed values
• Cache repeated storage reads in memory
• Batch struct writes
• Avoid unnecessary zero to non-zero transitions

Always verify with a gas report after changes.

You declare a uint128, then a uint256, then another uint128. How many storage slots do they use?

You learned to optimize storage layout:

• Storage is 32-byte slots; adjacent small types pack together
• Declaration order determines packing
• constant and immutable avoid storage entirely
• Cache reads and batch struct writes
• Mind the zero to non-zero write penalty

Next we look at optimizing loops and calldata handling.