When you open a wallet, the balance appears almost instantly. Many people naturally assume that the blockchain must directly store “how many coins a certain address currently has,” so the wallet is just reading that number out.
But the first impression many people get of a blockchain is often a string of transaction records: who transferred how many coins to whom and when. So the question arises: If the chain mainly records individual transactions, why can a wallet know the current balance immediately? This is the entry point for understanding blockchain State.
What Does a Node Look At When You Check Your Balance?
First, consider a thought experiment. Suppose a bank stores only all transfer records and does not store the current balance of each account. Every time you check your balance, the bank would have to start from the first transaction after you opened the account, add all income, subtract all expenses, and finally calculate a number. Checking once may be acceptable, but if a large number of users check every day, the cost would quickly become impractical.
So banks usually store two types of information at the same time:
- Transaction records: record “what happened” in chronological order.
- Account balances: record “what the result is now”.
A blockchain needs a similar distinction. A blockchain ledger does not have only a “transaction list” layer. It contains at least two key types of information:
- Ordered transaction history: transactions are packed into blocks and connected in order.
- The current result after transaction execution: that is, the current world state, usually called State.
Transaction history answers “what happened in the past”; State answers “what the world looks like now after these transactions have been executed”.
Here, let us briefly review two background concepts. A transaction is a request to change the ledger, for example, “transfer 10 tokens from address A to address B”; a block is a collection of transactions arranged in a certain order. An address is like an account identifier, used to receive, hold, or send assets. State is often organized around addresses to represent the current result.
The bank analogy helps explain the difference between “records” and “balance”, but it has limits: a bank is a centralized database, while blockchain state must be computed and verified by multiple nodes according to the same set of rules. The analogy cannot explain blockchain verification mechanisms; it only explains why “storing only records” creates query costs.
What Is State: A Snapshot of the Current World
In the blockchain context, State can be understood as: a snapshot of the current world result after all confirmed transactions have been executed.
In an account-model blockchain, State usually includes:
- the balance of each address;
- the nonce of each address;
- data stored by smart contracts, that is, contract storage;
- and other account information defined by the protocol.
Among these, nonce can be simply understood as the count of how many transactions an address has already sent; it is used for transaction ordering and to prevent certain forms of repeated submission. Different chains may define nonce slightly differently, but in the account model, it is part of the state.
You can think of it as a constantly updated table:
| Address or contract | Part of the current state |
|---|---|
| Address A | Balance 80 |
| Address B | Balance 70 |
| Contract C | A certain stored value is 42 |
This table is only illustrative. In real systems, state organization is more complex, and different blockchains may use different models. For example, some chains use the UTXO model, while others use the account model. This article will not go into a full comparison of the two, but only grasp the common idea: State represents “who has what now, and what is stored in contracts.”
It is especially important to emphasize that State does not exist out of thin air, nor is it permanent. It is the result of executing transaction history according to rules. When new transactions arrive, the state changes from one version to another.
In other words, blockchain “immutability” mainly means that the historical transaction order and state transition rules are difficult to rewrite at will, not that current balances never change. Balances certainly change; what changes is the current state, while what should not be rewritten at will is the transaction history that causes these changes.
Transactions Drive State Transitions
Once you understand that State is “the current result”, you also need to understand how it changes.
You can view a blockchain as a deterministic state machine. A state machine has a current state, inputs, and a new state obtained after processing inputs according to rules. For a blockchain:
- the current state is S1;
- the input is a transaction;
- the execution rules are defined by the protocol and contracts;
- the output is the new state S2.
Let’s look at a set of simple numbers. Suppose the initial state is:
- Alice: 100
- Bob: 50
The first transaction: Alice transfers 20 to Bob. After execution, the state becomes:
- Alice: 80
- Bob: 70
The second transaction: Bob transfers 10 to Alice. After execution, the state becomes:
- Alice: 90
- Bob: 60
The key here is not only the change in numbers, but order. Transactions in a blockchain are executed in the order within a block, and the result of the previous transaction becomes the premise for the next transaction. If the order is different, the result may be different.
More importantly, this process is deterministic: under the same initial state, same transaction order, and same execution rules, any honest executor will obtain the same new state. This is exactly the basis for nodes to verify each other’s results. Nodes do not need to trust a central institution saying “the balance is now this”; instead, they can execute transactions themselves, compute the state, and check whether the result is consistent.
Valid transactions bring state changes. Invalid transactions do not bring the expected asset or contract state changes; however, in actual systems, the handling of failed transactions depends on the rules of the specific chain. Some chains include failed transactions in blocks, possibly charging fees or updating the sender’s transaction count. To understand the main flow, first grasp the core: transactions are inputs to state transitions, and state is the result after execution.
This numerical example also has simplifications: it ignores fees, contract internal storage, failed transactions, and other details, and is only used to illustrate “how a transaction sequence deterministically changes a state snapshot”.
Why Can’t We Record Only Transactions?
Since transaction history already records every step, why do nodes need to specifically maintain State?
The reason lies in efficiency and verifiability.
If you want to answer “what is Alice’s balance now”, using only transaction history, a node must start from the genesis block, replay all related transactions in order, and keep computing up to the latest one. Suppose a chain has been running for many years, with millions of transactions each year; then checking a balance once may require recalculating a large amount of history. For wallets, exchanges, block explorers, and smart contract interactions, this cost is unacceptable.
Verifying a new transaction also requires the current state. For example, if Alice wants to transfer another 100 coins, the node needs to quickly check:
- Is Alice’s current balance sufficient?
- Does this transaction’s nonce match expectations?
- Are the conditions required for the contract call satisfied?
- Would the transaction violate protocol rules?
If every verification replays the entire history, the system becomes very inefficient. Maintaining the current state is equivalent to letting nodes keep a “latest result”, so that they can quickly check whether new transactions are valid.
Therefore, transaction history and State are not substitutes for each other:
- Transaction history is used for auditing, tracing, and replaying;
- State is used for efficiently querying current results and verifying new transactions.
In theory, state can be recalculated from transaction history. The reason full nodes maintain state is not that transaction history is worthless, but that real-world use requires quickly obtaining current results. Describing State as a “redundant cache” is inaccurate; it is a necessary design for a blockchain to support everyday queries and contract execution.
How Blockchain Commits to State: State Root
The next question is: state may be large, containing a large amount of account and contract data. Surely a blockchain cannot copy the complete state into every block, right?
Usually it does not. What is stored in the block header is a cryptographic commitment to the current state, commonly in the form of a state root.
A hash digest can be simply understood as a “fingerprint” of a piece of data: if the data does not change, the fingerprint does not change; if the data changes, the fingerprint usually changes. The state root is the commitment obtained by cryptographically digesting the current world state. It does not contain the complete balance of each account, but it can be used to check whether a certain state is consistent with the result recognized by the chain.
Taking Ethereum as an example, its block header contains a stateRoot field, used to commit to the world state after transaction execution. After nodes execute the transactions in a block, they calculate the new state root and compare it with the state root in the block header. If the two are inconsistent, it means the execution result does not match the result claimed by the block producer, and the block will be rejected.
This also explains a common misunderstanding: a blockchain does not directly write the complete current balance of every account into every block. The complete state is usually maintained locally by full nodes; the block header stores a digest commitment such as the state root. When a wallet queries a balance, it usually reads the state maintained by a node through that node, rather than directly reading the balance from some field in the block header.
The state root also brings verification benefits. With the state root and corresponding proofs, light nodes can verify whether a certain account or storage value belongs to this state without storing the complete state themselves. The specific proof structure involves more complex data structures, which this article will not cover; the key is to understand: a blockchain makes a verifiable commitment to the current state, rather than stuffing the complete state into every block.
Division of Labor Between Transaction History and State
At this point, another misunderstanding easily arises: since State is so important, does a blockchain mainly record State rather than transactions?
Not exactly. A more accurate statement is: a blockchain both stores ordered transaction history and commits to the state result after transaction execution.
Transaction history is like a complete video recording, recording what happened at every step; State is like the current score, telling you the current result. The recording can reconstruct the score, but when the game needs to continue, relying only on the current score is more efficient. This metaphor also has limits: blockchain state is not maintained by a single referee, but computed and verified by multiple nodes according to rules.
The division of labor between the two can be understood as follows:
- Transaction history provides an auditable sequence of events;
- State provides a queryable and verifiable current result;
- State can be recalculated from transaction history, so full nodes can verify rather than blindly trust;
- Nodes can also choose to retain older states, or rebuild state by replaying transactions, but this requires storage and computation costs.
In actual systems, different nodes store different content. Full nodes usually maintain the current state and verify transactions; archive nodes retain more historical states for querying data at a past moment; light nodes store only a small amount of information and rely on state roots and proofs for verification. There is no need to go deep into the implementation details of each type of node here; just know that transaction history and State together form a complete ledger, rather than being an either-or choice.
Putting State Back into the Blockchain Mental Model
Now we can return to the original question: why does a blockchain record State, not just transactions?
Because transactions describe changes, while State describes the result after those changes. To support balance queries, verify new transactions, and execute smart contracts, a blockchain must know the current state. Storing only transaction history can in theory recalculate state, but the cost grows with history and cannot support real-world use.
The core relationship can be compressed into one sentence:
Transactions answer “what happened”; state answers “what is now”.
Transactions are events, State is the result; transactions are inputs, and state transitions are outputs. Through ordered transactions and deterministic rules, a blockchain derives a new state from an old state, and uses state roots to make cryptographic commitments to the current result. Transaction history is still important; it is used for auditing and replaying. But State makes a blockchain a usable payment and computation system, rather than just an ever-growing historical log.
When you see data such as account balances, contract storage, or TVL in the future, you can understand them as references to or computations on a certain state. When you encounter deeper topics such as state bloat, state expiry, and stateless clients, you can also return to this basic model: a blockchain not only needs to remember what happened in the past, but also needs to know what is now.
