Oops State Explode Again
Recently Vitalik published an essay on the State Explosion problem and Ethereum’s potential countermeasures. It’s the signal of a 2nd round siege after the first wave of attack on the same problem in around 2019. State explosion is one of the core problem Nervos was set out to solve, and I’m always proud of the solution we come up with, and I’m glad to see Vitalik is walking on the same direction too: he prefers storage-slot-level over account-level expiry. As we know, the state management of CKB is an ownership model based on storage slots (a.k.a cell).
Unfortunately, there’s nothing new about the potential solutions proposed in the essay, and neither state rent or stateless client is the solution imo. State rent is notoriously complicated with unclear security consequences, and intrusive to user experience because of data expiry (sometimes reminds me of the cache invalidation joke). Maybe that’s why stateless client is more popular in Ethereum community these days. However stateless client has its own problem. The idea of stateless client can go back to Peter Todd’s TXO commitment in 2016, which is a proposal to manage UTXO set size of Bitcoin. In 2019 Thaddeus Dryja published the utreexo paper which provides a variation of TXO commitment. Stateless client can be used as an auxiliary tool to improve user experience, like light client, but it should not be considered as the savior of layer-1-without-state-management. The major problem of making every client a stateless client is it changes the data availability model of layer 1: if the whole state is replicated to N clients, the availability of any data in state is N; if the state is only kept by a few or single client, then its availability is 1. Data availability is at the core of a layer 1 blockchain: the availability of layer 1 assets relies on it, smart contracts rely on it, layer 2 protocols rely on it. Actually many layer 2 solutions (e.g. payment/state channel, rollup[1]) use layer 1 as a trustless data availability engine. If the data availability model is different, everything is different.
State explosion problem also exists in other blockchains, especially those support smart contract and claim to be “scalable”. It’s solved on Nervos. It’s being attacked on Ethereum.
Is It Really A Big Problem?
Yes.
As a user you may have no strong feeling right now, because it’s a problem to full node operator, not you. It hurts decentralization not user experience. It’s the fire heating the pot, and you’re the frog in water. Remember what happens when Infura was shutdown 3 months ago? Binance freeezed withdrawal, even many dapps stopped working. Why do we put a ‘d’ before ‘app’ if a single point failure can bring it down?
With fewer and fewer full node operator, a public permissionless blockchain like Ethereum will eventually degenerate to a public permissioned blockchain. Only those who can afford expensive hardware and network can verify the transactions and history, and users can only trust those few nodes. Such a blockchain is still useful, can still accrue value, just like a centralized internet service can be valuable, but it fails on its initial vision and positioned itself in a different sector of the crypto space, where its rivals are public permissioned blockchains like BSC and Diem, who has larger user base, lower fees and much better performance.
I believe each blockchain in different sectors will have their own position and irreplaceable value in future. They will work together to provide services to users (probably by Interoperability 2.0). What is clear is that Nervos CKB is and will always be a public permissionless blockchain, that’s why there’s state management from the very beginning, and why it’s on PoW.
[1] Rollup use layer 1 as a data availability engine in a way that part of rollup data are stored in history not in state. Nonetheless state storage is still required for the data left.
