当我们解决了scalability问题，区块链真正获得mass adoption，DApp和用户数量都爆炸式增长的时候，区块链历史和状态数据会以什么速度累积呢？

　　这就是状态爆炸问题，我们把它归类为post-scalability problem，因为它在解决scalability问题之后会非常明显。我们最早是在做许可链场景落地时注意到了这个问题，因为许可链的性能远高于公有链，刚好处于post-scalability的阶段。

　　历史数据的累积相对容易处理，未来可以通过去中心化的Checkpoint或是零知识证明等技术来压缩，在那之前全节点甚至可以把历史直接丢掉，依然可以正常运行。 状态数据的累积则麻烦许多，因为它是全节点运行必须的数据。

　　不少区块链项目已经看到了这个问题，并提出了一些解决方案。EOS RAM是解决状态爆炸问题的一个有益尝试：RAM代表了超级节点服务器可用的内存资源，无论是账户、合约状态还是代码，都需要占用一定的RAM才能运行。

　　RAM的设计也有很多问题，它需要通过内置的交易市场购买，不可转让，无法租用，将合约执行过程中的短期内存需求和合约状态的长期存储需求混在了一起，而且RAM的总量的设定没有确定的规则，更多取决于超级节点可以承受的硬件配置，而非共识空间的成本。

　　Ethereum社区也看到了这个问题并提出了Storage Rent的方案：要求使用者为存储资源的使用预支付一笔租金，占用存储资源会持续消耗这笔租金，占用时间越长，使用者需要支付的租金越多。Storage Rent方案存在两个问题：

　　1.预支付的租金终有一天会用完，这时候如何处理占用的状态？正是为解决这个问题，Storage Rent需要诸如resurrection的机制来补充，增加了设计的复杂度，使智能合约的immutability大打折扣，也为使用体验带来了麻烦；

　　2. Ethereum的状态模型是一种共享状态的模型，而不是First-class State。以ERC20Token为例，所有用户的资产记录都存放在单个ERC20合约的存储里面，在这种情况下，应该由谁来支付租金？

　　解决状态爆炸问题也是Nervos CKB的设计目标之一，为此我们走了一条完全不同、更为彻底的变革之路。简而言之，我们在 Nervos CKB 一个 token 代表一个单位的存储空间，通过经济模型的设计，限制世界状态的大小，利用市场手段调节状态存储的供需，并通过增发的设计持续向占用状态的用户收费，来协调生态中各方的利益，达到长期的安全和持久的稳定。

　　（未完待续）

    本文首发于微信公众号：链捕手。文章内容属作者个人观点，不代表和讯网立场。投资者据此操作，风险请自担。

继续阅读：

此文由 比特币官网 编辑，未经允许不得转载！：首页 > 比特币行情 » 区块链的状态爆炸困境 |硬核系列