State Diff

What Is a State Diff?

A state diff (short for state difference) is a compact summary of the changes a batch of transactions makes to a blockchain's state. Rather than listing every transaction that was executed, a state diff captures only the result: which accounts were modified, which storage slots changed, and what their new values are. It is the delta between the state before a batch and the state after.

Think of it like a spreadsheet: instead of recording every keystroke you made during an editing session, a state diff records only the cells that look different at the end. If you edited cell A1 five times, the diff contains just one entry: the final value of A1.

State diffs are primarily used by rollups to minimize the amount of data they must post to a base layer like Ethereum. By publishing only the net state changes instead of full transaction data, rollups can significantly reduce their L1 gas costs while still allowing anyone to reconstruct the current L2 state.

How It Works

To understand state diffs, it helps to contrast them with the alternative: posting full transaction data. A rollup has two fundamental choices for what it publishes to L1.

Full Transaction Data

In this approach, the rollup posts every transaction's inputs to L1: sender, recipient, value, calldata, and (in compressed form) signatures. This is the method used by optimistic rollups like Arbitrum and Optimism, and also by some ZK rollups like Scroll and Polygon zkEVM.

Anyone observing L1 can re-execute the transactions and independently derive the current L2 state. This is essential for optimistic rollups because their fraud proof mechanism requires challengers to replay transactions.

State Diff Posting

In the state diff approach, the rollup posts only the net state changes. A typical state diff entry contains:

• The account address that was modified
• The storage slot key that changed
• The new value of that slot

Additionally, the batch may include nonce updates, new contract deployments (address plus bytecode hash), and any other state mutations. Transaction signatures are omitted entirely because the accompanying validity proof already guarantees correct execution.

The process works as follows:

1. The rollup sequencer collects and executes a batch of transactions off-chain
2. A validity proof (SNARK or STARK) is generated proving the execution was correct
3. The rollup computes the state diff: the net change to each modified storage slot
4. Only the state diff and the validity proof are posted to L1
5. Anyone monitoring L1 can accumulate state diffs to reconstruct the current L2 state

Data Savings in Practice

The savings from state diffs depend on how much activity overlaps within a batch. Consider these examples:

The last row reveals an important nuance: state diffs can actually be larger than transaction data when there is little overlap between transactions. The savings come from consolidation, and consolidation requires repeated access to the same state.

In practice, popular DeFi contracts and token balances see heavy repetition. zkSync Era's Boojum upgrade reduced per-transaction data from approximately 211 bytes to 68 bytes on Ethereum, a roughly 68% reduction compared to full transaction posting.

Compression Techniques

Rollups apply additional compression on top of state diffs. zkSync Era replaces 32-byte storage keys with 8-byte enumeration indices for previously seen slots, cutting key size by 75%. StarkNet's v0.13.3 update introduced stateless compression that buckets field elements by bit length (15, 31, 62, 83, 125, and 252 bits), achieving up to 84x compression in optimal cases.

// Conceptual state diff structure
{
  "batchNumber": 42,
  "stateDiffs": [
    {
      "account": "0xAbC...123",
      "slot": "0x000...007",
      "newValue": "0x000...1F4"  // balance changed to 500
    },
    {
      "account": "0xDeF...456",
      "slot": "0x000...007",
      "newValue": "0x000...0C8"  // balance changed to 200
    }
  ],
  "deployedContracts": [
    {
      "address": "0x789...abc",
      "bytecodeHash": "0xef0...def"
    }
  ]
}

Which Rollups Use State Diffs?

The rollup ecosystem is split between the two approaches, and the choice is closely tied to rollup type:

All optimistic rollups must post full transaction data because their fraud proof mechanism requires re-executing transactions. Only ZK rollups have the option to use state diffs, since the validity proof guarantees correct execution without requiring anyone to replay the transactions.

Even among ZK rollups, the choice is not unanimous. Scroll and Polygon zkEVM post full transaction data for better finality characteristics and data completeness, accepting higher L1 costs in exchange.

State Diffs and Blob Transactions

Blob transactions (introduced by EIP-4844) provide temporary data space on Ethereum at much lower cost than permanent calldata. State diffs and blobs provide compounding savings: state diffs reduce the volume of data, and blobs reduce the per-byte cost of posting it.

StarkNet switched its state diff publishing from calldata to blobs in v0.13.1, with automatic fallback to calldata when blob fees spike. Combined with compression improvements in later versions, this has reduced L2 transaction fees by approximately 95% compared to pre-blob levels.

Ethereum's roadmap continues to expand blob capacity. The Fusaka hard fork in late 2025 introduced PeerDAS (Peer Data Availability Sampling), and subsequent parameter increases have raised the blob target toward 48 blobs per block. These upgrades benefit all rollups but are especially impactful for state-diff rollups, which already minimize data volume and now benefit from cheaper per-byte pricing as well.

Why It Matters

State diffs represent a fundamental design choice in how Layer 2 networks balance cost, transparency, and security. For users and developers, the choice between state-diff and transaction-data rollups affects:

• Transaction fees: state-diff rollups typically have lower L1 data costs, especially for DeFi-heavy workloads with repeated state access
• Finality time: state-diff rollups may have longer finality because validity proofs are batched less frequently to amortize proving costs
• Data transparency: full-transaction-data rollups allow complete history reconstruction from L1, while state-diff rollups only support current-state reconstruction
• Forced inclusion: transaction-data rollups can automatically force L1-to-L2 messages, while state-diff rollups typically require penalty-based enforcement mechanisms

As the broader ecosystem evolves toward modular blockchain architectures, the state diff approach informs how different layers handle data availability. Bitcoin Layer 2 solutions like Spark and state channel designs explore related tradeoffs around what data must live on-chain versus off-chain.

Risks and Considerations

Lost Transaction History

The most significant tradeoff of state diffs is that individual transaction details are not preserved on L1. While anyone can reconstruct the current state from accumulated diffs, they cannot determine which specific transactions produced that state. If the rollup's off-chain data store goes offline or is lost, transaction history becomes unrecoverable from L1 data alone.

This has practical implications for block explorers, analytics tools, and regulatory compliance. Full transaction history depends on the rollup operator or independent archival nodes maintaining off-chain records.

Finality Delays

State-diff rollups batch their validity proofs infrequently to amortize the high cost of proof generation. A transaction's outcome on L1 is only confirmed once the proof covering that batch is verified. This means finality can take minutes to hours, compared to transaction-data rollups where data is available on L1 as soon as it is posted.

Forced Inclusion Complexity

When a rollup sequencer censors transactions, users need a mechanism to force their transactions through L1. With transaction-data rollups, this is straightforward: post the transaction to L1 and the protocol includes it automatically. State-diff rollups cannot do this directly because L1 only sees state changes, not transactions. They must implement alternative mechanisms such as penalty-based escape hatches or escape hatches that impose costs on censoring sequencers.

Potential for Larger Diffs

In workloads where most transactions touch unique state (many distinct addresses, few repeated storage accesses), state diffs can actually be larger than the equivalent transaction data. The compression advantage depends on access pattern overlap within each batch, making the economics workload-dependent rather than universally beneficial.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.