子母链杂谈：区块链的容量问题

容量的极限:内存。

吞吐量解决之后，容量的瓶颈

「容量」这个问题的关注度远远少于吞吐量，原因很简单：因为吞吐量这个短板还没解决，所以容量问题被掩盖住了。请记住，一旦吞吐量实现了大幅提升，容量问题马上就会出现：在一个高吞吐的系统上，如果用户量上不去，很可能高性能根本跑不满。

一个典型的例子是EOS。当EOS以丧失去中心化特性为代价而解决了吞吐量问题之后，容量的问题马上就凸显出来了。然后，EOS把账簿容量瓶颈这个问题包装成了一个稀缺资源，并将其代币化，成了EOSRAM虚拟币。当然除了内存，单台全节点CPU也会成为容量的瓶颈，所以也被代币化，成了EOSCPU虚拟币。不过，在类金融应用场景中，通常计算复杂度非常低，所以，内存会是主要瓶颈。

另外，我的另外一个观点是：共识算法其实帮不了解决性能和容量的瓶颈，试图从标新立异的共识算法出发，提升「ChainofBlocks」系统性能的努力，基本上不会让系统性能有实质上的大幅提升。总之，解决上面所提及的两个瓶颈问题，需要的是分布式系统设计上的巧思妙想，这和共识算法相关，也和密码学相关，但是本质的出发点不是共识算法和密码学。

在单链架构下容量存在一个横向扩展Scale-out的约束边界，CPU或者内存。一个单链结构的区块链，是一个分布式的计算机。任何一台计算机都有其约束边界，时间或者空间，对应在这个分布式计算机结构里面的就是CPU和内存如何平衡的问题。

那么通常我们的思路有两种，一种是单点的技术进步，一种是工程上的优化。比如你可以用超级计算机，也可以用谷歌的工程学做法，把廉价的二手机器做工程上的优化，同样可以满足应用的需要。一个是做局部的最优，一个是做全局的最优。

回到区块链这个架构下，和云计算不同的是，区块链无法通过直接加机器来实现性能和处理能力的提升。在一个网络下有其确定边界，但是现实世界的数据处理对于性能的要求是动态的。就像12306的火车票，日常卖不完，过年的时候不够卖。如何既能够做到满足日常的经济型，又能够动态的扩展满足弹性？这个就不是通过加机器，改善节点的处理能力能够解决的了。

一个可能的做法就是做并行链，比如北京一条链，河北一条链，天津一条链。这样就好比原来每个省市的高速公路，在一个区域内具备网络效应，实现局域互联，局域网链接在一起的时候就是一个广域网。

同构的子母链

那么对应在区块链上，就是把不同的链拼接互联在一起，每条链不受制于其他链而独立工作。而这些链又分别拿出一部分资源来做协议的互通，通常叫做跨链。但是这种结构都是同构的，比如三个基于以太坊技术的联盟链互通在一起。

异构的子母链

但是在整个广域网的结构上，不同的场景需要的区块链也各不相同。比如在物联网场景里面，DAG就比区块链结构更合适。一个相对稳定的组织内部，可能用POS的结构比POW更合适。基本上不存在一个绝对通用的共识协议适用于任何场景。

那么POS的链，POW的链，BFT的链如何互通，在一种弹性可扩展的广域网区块链上。第一解决性能的问题，第二解决容量的问题，第三解决适用场景的问题。基于以上几点解决弹性可扩展的问题。

想到这一层面，我忽然对于MOAC提出的子母链设计有了更深入的理解。好消息是这个架构设计也会移植到井通公链上来。未来也会支持异构的区块链，比如Fabric的链也可以迁移过来。

对于区块链会存在一个路径依赖效应，主要的不是技术迁移，数据迁移的困难，而是已经在稳定运行的区块链，所对应的时间戳，区块数据结构，要和新的业务需求相适应。有没有可能遇到以下这些问题呢：

1：一个无币的区块链在2022年，突然需要发币了。那么是分叉还是怎么处理？

2：分叉后，需要采用新的共识协议，如何桥接？

3：原来运行在以太坊上的项目如何无缝桥接到新的链上来？

容量问题，确实接下来会遇到的一个问题。说服别人采用自己的链的难度比我原想的要大很多很多。目前的感觉，也就是很难通过商业运作来达到技术的统一。一家机构，死活都认IBM的Fabric，很多时候你无法说服。如何提供一个兼容的环境，让这些不同技术流派都可以互通互联，也许是各个局域网（链）成熟之后的一个更重要的问题。

浏览过的版块