Variable packing in Blockchain / Solidity - Deep Dive

Overview - Variable packing

What is it?

Variable packing is a technique used in Solidity, the programming language for blockchain smart contracts, to store multiple smaller variables efficiently within a single 32-byte storage slot. Since each storage slot in Ethereum's virtual machine is 32 bytes, packing smaller variables together saves space and reduces gas costs. This means you can fit several small variables like booleans or uint8s into one slot instead of using separate slots for each.

Why it matters

Without variable packing, each small variable would occupy a full 32-byte slot, wasting storage and increasing transaction costs on the blockchain. Since every byte stored costs gas, inefficient storage makes smart contracts more expensive to deploy and use. Variable packing helps developers write cheaper and more efficient contracts, which is crucial for blockchain applications where cost and performance matter.

Where it fits

Before learning variable packing, you should understand Solidity basics, especially how storage works and data types. After mastering variable packing, you can explore advanced gas optimization techniques and low-level storage manipulation in smart contracts.

Mental Model

Core Idea

Variable packing groups multiple small variables into one storage slot to save space and reduce blockchain gas costs.

Think of it like...

Imagine a suitcase with fixed space: instead of packing one big jacket per suitcase, you fold several small t-shirts neatly to fit many in the same suitcase, saving space and luggage fees.

┌───────────────────────────────┐
│ Storage Slot (32 bytes total) │
├─────────────┬─────────────┬────┤
│ uint128 (16 bytes) │ uint64 (8 bytes) │ bool (1 byte) │
└─────────────┴─────────────┴────┘

Multiple small variables fit together in one slot.

Build-Up - 7 Steps

1

Foundation

Understanding Solidity Storage Slots

Concept: Learn how Solidity stores variables in 32-byte slots.

In Solidity, each storage slot is 32 bytes (256 bits). Variables are stored in these slots sequentially. Large variables like uint256 take a full slot, but smaller variables can share a slot if placed carefully.

Result

You know that storage slots are fixed-size containers where variables live.

Understanding storage slots is key because variable packing depends on how variables fit into these fixed-size slots.

2

Foundation

Data Types and Their Sizes

Concept: Recognize the size of common Solidity data types.

Solidity data types have fixed sizes: bool is 1 byte, uint8 is 1 byte, uint16 is 2 bytes, uint256 is 32 bytes, etc. Knowing these sizes helps decide which variables can be packed together.

Result

You can estimate how many variables fit in one slot.

Knowing variable sizes allows you to plan packing to minimize wasted space.

3

Intermediate

How Solidity Packs Variables Automatically

🤔Before reading on: do you think Solidity packs variables of different types automatically or do you need to do it manually? Commit to your answer.

Concept: Solidity automatically packs variables declared consecutively if they fit in one slot.

When you declare multiple small variables one after another, Solidity tries to pack them into the same 32-byte slot if their combined size is 32 bytes or less. For example, three uint8 variables declared consecutively will share one slot.

Result

Variables declared consecutively and small enough share storage slots, saving space.

Knowing Solidity's automatic packing helps you write code that benefits from packing without extra effort.

4

Intermediate

Ordering Variables to Maximize Packing

🤔Before reading on: do you think the order of variable declarations affects packing efficiency? Commit to your answer.

Concept: The order of variables affects how well Solidity can pack them together.

Solidity packs variables in the order they are declared. Placing smaller variables together before larger ones allows better packing. For example, putting all uint8 variables consecutively before a uint256 variable packs them efficiently.

Result

Reordering variables can reduce storage slots used and gas costs.

Understanding that declaration order impacts packing lets you optimize contract storage layout.

5

Intermediate

Limitations of Variable Packing

Concept: Recognize when packing does not happen or is inefficient.

Packing only works for variables declared consecutively and smaller than 32 bytes. Variables larger than 32 bytes or dynamic types like strings cannot be packed. Also, gaps appear if variables cross slot boundaries.

Result

You know when packing is possible and when it is not.

Knowing packing limits prevents false assumptions about storage savings.

6

Advanced

Manual Packing Using Structs

🤔Before reading on: do you think structs help with variable packing or make storage more complex? Commit to your answer.

Concept: Structs group variables and can improve packing by controlling layout explicitly.

By grouping related small variables inside a struct, you can ensure they are packed tightly in one slot. For example, a struct with several uint8 fields packs them together. This also improves code readability and maintenance.

Result

Structs help organize and pack variables efficiently.

Using structs for packing combines optimization with cleaner code design.

7

Expert

Gas Cost Impact and Storage Reads

🤔Before reading on: do you think packed variables cost more or less gas to read and write? Commit to your answer.

Concept: Packing reduces storage size but can affect gas costs for reading and writing variables.

While packing saves storage space and deployment gas, reading or writing packed variables may require extra bitwise operations, slightly increasing runtime gas. However, overall gas savings from reduced storage slots usually outweigh this cost.

Result

You understand the tradeoff between storage savings and access cost.

Knowing this tradeoff helps you balance packing benefits with runtime performance in production contracts.

Under the Hood

Ethereum's storage model uses 32-byte slots indexed by a key. Solidity assigns variables to these slots sequentially. When variables are smaller than 32 bytes and declared consecutively, Solidity packs them by placing their bits side-by-side within one slot. Accessing packed variables involves bit masking and shifting to isolate or modify the correct bits inside the slot.

Why designed this way?

Ethereum's 32-byte slot design matches the EVM word size for efficiency. Packing variables reduces the number of slots used, saving gas since each slot costs to store. Solidity automates packing to help developers optimize without manual bit manipulation, balancing ease of use and efficiency.

┌───────────────┐
│ Storage Slot 0│
├─────┬─────┬───┤
│var1 │var2 │...│
│(8b) │(8b) │   │
└─────┴─────┴───┘

Packing: bits of var1 and var2 stored side-by-side in one slot.

Access: mask and shift to read/write each variable.

Myth Busters - 4 Common Misconceptions

Quick: Does Solidity pack variables declared far apart in the contract? Commit yes or no.

Common Belief: Solidity packs all small variables regardless of where they are declared.

Reality: Solidity only packs variables declared consecutively without gaps or larger variables between them.

Why it matters: Assuming all small variables pack leads to wasted storage and higher gas costs.

Quick: Is packing always beneficial for gas costs? Commit yes or no.

Common Belief: Packing always reduces gas costs for all operations.

Reality: Packing reduces deployment gas but can increase gas for reading/writing due to extra bit operations.

Why it matters: Ignoring this tradeoff can cause unexpected higher runtime costs.

Quick: Can dynamic types like strings be packed? Commit yes or no.

Common Belief: All variable types, including strings and arrays, can be packed together.

Reality: Dynamic types are stored differently and cannot be packed in fixed slots with other variables.

Why it matters: Trying to pack dynamic types wastes effort and causes confusion about storage layout.

Quick: Does reordering variables affect contract behavior? Commit yes or no.

Common Belief: Changing variable order only affects readability, not storage or gas.

Reality: Reordering variables changes packing and storage layout, affecting gas costs and possibly upgrade safety.

Why it matters: Ignoring this can cause costly mistakes in contract upgrades and gas optimization.

Expert Zone

1

Packing variables can affect contract upgradeability because storage slot layout must remain consistent.

2

Bitwise operations for packed variables can increase complexity in assembly or inline code, requiring careful testing.

3

Compiler versions differ slightly in packing behavior; always verify with the specific Solidity version used.

When NOT to use

Avoid variable packing when variables are frequently updated individually and gas cost for access outweighs storage savings. Also, do not pack if contract upgrade patterns require fixed storage layouts or when using dynamic types that cannot be packed.

Production Patterns

In production, developers group related small flags or counters in structs to pack them. They carefully order variables to maximize packing and minimize gas. Some use custom getter/setter functions with bit masking for packed variables to control access and maintain clarity.

Connections

Data Compression

Variable packing is a form of data compression applied at the storage level.

Understanding data compression principles helps grasp how packing reduces space by eliminating wasted bits.

Memory Alignment in Systems Programming

Both involve arranging data to fit efficiently in fixed-size blocks for performance.

Knowing memory alignment concepts clarifies why packing order and sizes matter for efficient storage.

Packing in Logistics and Shipping

Both optimize space by arranging smaller items tightly within fixed containers.

Seeing packing as a logistics problem helps appreciate the tradeoffs between space savings and access complexity.

Common Pitfalls

#1 Declaring small variables scattered with large variables in between, expecting packing.

Wrong approach:

contract Example {
uint8 a;
uint256 big;
uint8 b;
}

Correct approach:

contract Example {
uint8 a;
uint8 b;
uint256 big;
}

Root cause:

Misunderstanding that packing only happens for consecutive small variables without gaps.

#2 Packing dynamic types like strings with small variables.

Wrong approach:

contract Example {
string name;
uint8 flag;
}

Correct approach:

contract Example {
uint8 flag;
string name;
}

Root cause:

Not knowing dynamic types are stored separately and cannot be packed with fixed-size variables.

#3 Reordering variables without considering upgrade safety.

Wrong approach:

contract V1 {
uint8 a;
uint8 b;
}

contract V2 {
uint8 b;
uint8 a;
}

Correct approach:

contract V1 {
uint8 a;
uint8 b;
}

contract V2 {
uint8 a;
uint8 b;
}

Root cause:

Ignoring that storage layout changes break upgradeable contract compatibility.

Key Takeaways

Variable packing in Solidity stores multiple small variables in one 32-byte slot to save storage space and reduce gas costs.

Solidity automatically packs consecutive small variables, but the order of declaration greatly affects packing efficiency.

Packing has limits: it only works for fixed-size small variables declared consecutively and not for dynamic types.

While packing saves deployment gas, it can increase gas for reading and writing due to extra bit operations, so balance is key.

Understanding packing is essential for writing efficient, cost-effective smart contracts and maintaining upgrade safety.