On State Management and Blockchain Positioning

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?


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.




最近Vitalik发表了一篇关于状态爆炸问题和以太坊潜在对策的文章。这是继 2019 年左右针对同一问题的第一波攻击之后,又出现第二轮围攻的信号。状态爆炸是 Nervos 打算解决的核心问题之一,我总是为我们想出的解决方案感到骄傲,我很高兴看到 Vitalik 也在往同样的方向前进:他说更喜欢存储槽(storage slot)而不是账户层级的过期方案。我们知道,CKB的状态管理是基于存储槽(也就是 cell)的所有权模型。

不幸的是,本文中提出的潜在解决方案并没有什么新意,而且状态租赁或无状态客户端都不解决方案(哈哈)。状态租赁(State rent )是出了名的复杂,还具有不明确的安全后果,并且由于数据过期而干扰用户体验(有时会让我想起缓存失效的笑话)。也许这就是无状态客户端在以太坊社区中越来越流行的原因。然而,无状态客户端有它自己的问题。无状态客户端的想法可以追溯到2016年 Peter Todd 的 TXO 承诺 ,这是一个管理比特币 UTXO 集(set)大小的提议。2019年,Thaddeus Dryja发表了 utreexo 论文,该论文提供了 TXO 承诺的变体。无状态客户端可以作为改进用户体验的辅助工具,就像轻客户端一样,但是它不应该被认为是第一层无状态管理的救世主。使每个客户端都成为无状态客户端的主要问题是它改变了 Layer1 底层公链的数据可用性模型:如果将整个状态复制到 N 个客户端,任何处于状态的数据的可用性为 N;如果状态仅由几个或单个客户端保存,则其可用性为1。数据可用性是区块链 Layer1 的核心,实际上许多 Layer2 的解决方案(例如支付/状态通道,聚合)使用 Layer1 作为一个无需信任的数据可用性引擎。如果数据可用性模型不同,那么一切都不同。

状态爆炸问题也存在于其他区块链中,特别是那些支持智能合约并声称是“可扩展的”的区块链。这(状态爆炸)是个在 Nervos 上已经解决,但仍然在攻击以太坊的问题。


作为用户,您现在可能没有强烈的感觉,因为这是全节点运维者的问题,而不是您。它伤害的是去中心化这个重要特性,而不是用户体验。这就像是用火在加热锅子,而您(用户)正是那水里的青蛙。还记得 3 个月前 Infura 关闭时发生了什么吗? 币安冻结了提款,甚至许多 dapp 都被迫停止了工作。如果单点故障就可能导致应用程序(dApp)崩溃,为什么我们要在“应用程序(App)”前面加上“d”呢?

随着运维(同步)全节点的人越来越少,像以太坊这样的无需许可的区块链最终会退化为公有许可的区块链。只有那些买得起昂贵的硬件和网络的人才能验证交易和历史记录,而用户只能信任这几个节点。这样一个区块链仍然是有用的,仍然可以产生价值,就像一个中心化的网络服务是能有价值的,但它在其最初的愿景上就失败了,并且会在加密世界中将自身定位在不同的地方,在那里的竞争对手会是像 BSC(币安智能链)或者 Diem (脸书)等拥有更大的用户群,更低的费用和更好的性能的 公有许可链。
我相信不同领域的每一种链在未来都会有自己的地位和不可替代的价值。他们将一起为用户提供服务(可能通过互操作性2.0)。有一个很清楚的点是 Nervos CKB会永远是一个公有且无需许可的区块链,这就是为什么从一开始我们就有状态管理,还有为什么它是采取PoW。