In the continuous development of distributed ledger technology, scalability is always the top goal but also the biggest challenge for every protocol. While solutions like Layer 2 or Sharding focus on increasing transaction throughput, a more silent but dangerous problem is threatening the sustainability of the network: state growth and state bloat. The state of the blockchain is not simply a transaction history but a "current map" of the entire account, balance, and smart contract code. According to analysis from Tan Phat Digital, when this data grows uncontrollably, the hardware barrier to operating a full node will become too high, leading to the centralization of authentication power in the hands of a few entities with strong resources. In that context, the Stateless Client (stateless node) architecture emerged as a revolutionary direction, allowing the network to maintain decentralization even when the data scale expands to huge levels.
Analyzing Blockchain Data Structure: The difference between State and History
To understand the nature of Stateless Client, it is first necessary to deeply analyze the difference between two core types of data in a system Blockchain: history and state. Many users and even new developers often confuse these two concepts, but in system architecture, they have completely different roles and resource requirements.
Comparison of Characteristics between Historical Data and Status Data:
1. Historical Data (History):
Content: All transactions and blocks up to now since the original block.
Access frequency: Low (only when synchronizing or querying old events).
Hardware requirements: Large capacity, cheap HDD (can be up to thousands Terabyte).
Properties: Append-only and immutable.
Authentication role: Serves to check the long-term integrity of the ledger.
2. State Data:
Content: Current snapshot of account balance, contract code and storage memory.
Access frequency: Very high (retrieved continuously during every transaction processing step).
Hardware requirements: High-speed SSD or RAM to ensure ensures low latency.
Properties: Continuously changing (Read/Write) with each transaction block.
Authentication role: Necessary to validate the validity of instant transactions (for example, checking balance).
The uncontrolled growth of state is the cause of the "state bloat" phenomenon. As the number of users increases, the number of new accounts are created, and DeFi and NFT applications become more complex, the size of the state will gradually increase over time. This places a significant resource burden on full nodes, as they must maintain a complete and up-to-date copy of this state to participate in the consensus process.
See also: Blockchain What is Trilemma? 2030 Roadmap
State Bloat: A "Chronic Disease" and the Risk to Decentralization
State bloat is not a technical bug but a natural consequence of the success and adoption of blockchain. However, if left unmanaged, it will become a major barrier to the sustainable development of the network. The main drivers of state growth include the creation of new addresses, the deployment of complex smart contracts, and the storage of arbitrary data on-chain.
In a system like Ethereum, every "storage slot" used in a smart contract will exist forever in the state unless it is explicitly deleted. However, most developers and users have no economic incentive to delete old data, leading to the so-called "Tragedy of the Commons". Users only pay a one-time transaction fee to put data on the chain, but validating nodes must bear the cost of storing that data forever.
The consequences of state bloat for the blockchain network are severe:
Increased hardware threshold:Nodes require multi-Terabyte SSDs with extremely high IOPS performance to keep up with update rates.
Extended sync times synchronization: Initial state loading can take days or weeks, preventing new members from joining.
Risk of centralization: Only large organizations or specialized infrastructure providers have the resources to maintain the node, weakening decentralization.
Denial of service (DoS) risk: Attackers can exploit state creation Cheap way to fill up the database of nodes.
See more: Layer 1 and Layer 2 in Blockchain: Multi-layer architecture and network scaling solutions
What is a Stateless Client? Revolution in Validator Node Architecture
Stateless Client is a design concept in which validator nodes are not required to store the entire state of the blockchain to check the validity of a new block. The state still exists, but the responsibility for storing and serving it is shifted or redistributed.
In this architecture, the new block will come with an additional piece of information called witness. Witness is a set of specific state values accompanied by cryptographic evidence proving their accuracy based on the committed "State Root".
Classification of Statelessness levels:
Weak Statelessness (Weak Statelessness): Ethereum's short-term goal. Only the proposer and block builder need to store the full state to create a witness. Other validators can operate in stateless mode.
Strong Statelessness: Even block producers do not need to store state. Users must provide their own testimony for their transactions. However, this level faces a major barrier in terms of user experience.
Partial Statelessness (Partial Statelessness): Selective nodes store commonly used "hot" state parts and request witness for "cold" state parts.
Verkle Trees: Tool to realize Stateless capabilities
The biggest challenge of Stateless Client is the size of witness. With the current Merkle Patricia Trie structure, the witness size for each block can be up to Megabytes, causing bandwidth congestion. To solve the problem, Tan Phat Digital noted that Ethereum's roadmap is shifting towards Verkle Trees.
Technical Comparison between Merkle Patricia Trie and Verkle Tree:
1. Merkle Patricia Trie (MPT):
Linking mechanism: Uses traditional hash functions (SHA-256/Keccak).
Node width (k): Usually 2 or 16.
1 leaf proof size: Approximately 1 KB.
Witness size for 1 block: About 1 MB (not feasible for stateless architecture).
Computational cost: Low (only needs basic hash calculation).
2. Verkle Tree:
Bytes.Witness size for 1 block: Only from 150 Bytes to a few dozen KB (completely feasible).
Computational cost: High (requires complex calculations on elliptic curves).
Verkle Trees allow reducing witness size to about 1/20 to 1/30 compared to traditional ones, allowing mobile devices to also become authentication nodes.
Supporting paths: State Rent, State Expiry and State Pruning
State Rent
Apply economic mechanism: users must pay to maintain data on-chain.
Solana: Minimum SOL balance required to be "rent free". If not enough, the account can be deleted.
Nervos CKB: 1 CKB coin corresponds to 1 byte of storage. Users must lock tokens to save data, creating an economic barrier to state bloat.
State Expiry
Automatically removes parts of state that have been untouched for a long time (e.g. 1 year) from the active state set. To reuse, the user must provide evidence to "revive" that account.
State Pruning
Nodes' internal technique to purge old state data (e.g., keep only the most recent 128 blocks) to save local disk space.
Future Blockchain Architecture: Symbiosis between Modular and Stateless
In Tan Phat Digital's vision, the future architecture will be a combination of:
Execution Layer (L2 Rollups): Maintains full state (stateful) for high performance but only manages a small portion of data.
Settlement Layer (L1 Stateless): Becomes stateless, only responsible for authenticating evidence from Rollups without needing to store the original data.
Data Availability Layer (DA Layer): Ensures raw data is always available to reset the state when needed, without forcing every node to store history.
Frequently Asked Questions (FAQ)
1. What is the most basic difference between "State" and "History"? History is a diary that records every transaction that has occurred since the past, while State is the current "account map" needed to determine whether a new transaction is valid or not.
2. Why does State Bloat pose a risk to network centralization? When the state is too large, only organizations with superior hardware can run full nodes. This puts control of the network in the hands of a few resource-rich entities, causing a loss of decentralization.
3. How does Verkle Trees help reduce Witness size?
Instead of using an old-fashioned hash function that requires enclosing multiple "sibling nodes" in the data tree, Verkle Trees uses KZG polynomial commitments that help create extremely compact and fixed-sized membership proofs ($O(1)$ instead of $O(\log n)$).
4. How is "Weak Statelessness" different from "Strong Statelessness"?
Weak Statelessness only requires the block proposer to keep the state, other validators do not. Statelessness Manh requires that even the block proposer does not keep state, all burden of witness shifts to the user.
5. How does Solana's State Rent mechanism work?
Accounts on Solana must maintain a minimum SOL balance to pay hosting fees. If the account is closed, the user can reclaim the entire deposited SOL number.
6. What is Stateless Blockchain's "Impossible Law" about? Research shows that it is impossible to have a system where both the state at the validator node is constant and the frequency of updating evidence for users is low. There is always a trade-off between one of these two factors.
7. Does State Expiry permanently delete user data?
No. State Expiry only moves inactive data (e.g. unused for 1 year) into cold storage. Users can use evidence to "wake up" and bring the account back to active status when needed.
8. Who are Proof Providers and what role do they play?
They are specialized parties (like block builders or RPC providers) that own the full state. They are responsible for creating and sending cryptographic proofs (witness) to stateless clients so that these nodes can authenticate transactions without saving data.
9. How does Nervos CKB solve the "public land tragedy" in storage?
Nervos considers storage space to be private property. Users who want to save 1 byte of data must own and lock 1 CKB coin. Inflation from the annual issuance of additional CKBs (secondary issuance) acts as a "status rent tax" on those occupying this space.
10. Can mobile phones run blockchain nodes?
Yes, through Stateless Client architecture combined with SNARKs. When the storage burden is reduced to a few GB and authentication is just a mathematical proof check, a smartphone or smartwatch can also participate in network security.
State growth and state bloat are existential risks that threaten the survival of the decentralized ideal. Stateless Client, powered by Verkle Trees, provides a strategic way to decouple the authority of authentication from the burden of storage. The fight against state bloat is the fight to keep blockchain open, transparent, and belonging to everyone. With the companionship of research units like Tan Phat Digital, we can believe in a decentralized digital infrastructure that is sustainable and capable of mass application in the future.
Share
