区块链的速度困境：“贵”在信任，“慢”得其所

这个理论虽然有一些争议，但从工程实践中看，和光速理论一样，可以无限逼近极致但是难以突破。

区块链系统能把一致性和可靠性做到极致，但是“好的响应性能”方面一直有点被人诟病。

我们面向的“联盟链”领域，因为在准入标准，系统架构、参与节点数、共识机制等方面都和公链不同，其性能表现远高于公有链，但是目前几个主流的区块链平台，在常规PC级服务器硬件上实测，TPS一般是在千级的样子，交易延迟一般在1秒到10秒这个级别。（听说TPS十几万级和百万级千万级区块链已经做出来了？好吧，期待）

笔者曾在大型互联网公司工作多年，在海量服务领域，面对C10K问题（concurrent 10000 connection，万级并发）已经有轻车熟路的解决方案，对一般的电商业务或内容浏览服务，普通pc级服务器单机达到几万TPS，且平均延时在500毫秒以内，飞一般的体验已经是常态，毕竟互联网产品卡一下说不定就会导致用户流失。对于快速增长的互联网项目，通过平行扩容、弹性扩容、立体扩容的方式，几乎能无底线、无上限地面对山呼海啸的海量流量。

相比而言，区块链的性能比互联网服务慢，而且难以扩容，根因还是在其“用计算换信任”的设计思路上。

具体哪里慢呢？

从“古典”区块链的系统内部来看👇

1、为了安全防篡改防泄密可追溯，引入了加密算法来处理交易数据，增加了CPU计算开销，包括HASH、对称加密、椭圆曲线或RSA等算法的非对称加密、数据签名和验签、CA证书校验，甚至是目前还慢到令人发指的同态加密、零知识证明等。在数据格式上，区块链的数据结构本身包含了各种签名、HASH等交易外的校验性数据，数据打包解包、传输、校验等处理起来较为繁琐。

对比互联网服务，也会有数据加密和协议打包解包的步骤，但是越精简越好，优化到了极致，如无必要，绝不增加累赘的计算负担。

2、为了保证交易事务性，交易是串行进行的，而且是彻底的串行，先对交易排序，然后用单线程执行智能合约，以避免乱序执行导致的事务混乱、数据冲突等。即使在一个服务器有多核的CPU，操作系统支持多线程多进程，以及网络中有多个节点、多台服务器的前提下，所有交易也是有条不紊地、严格地按单线程在每台计算机上单核地进行运算，这个时候多核CPU其他的核可能完全是空闲的。

而互联网服务则是能用多少服务器的多少个核，采用全异步处理、多进程、多线程、协程、缓存、优化IOWAIT等等，一定会把硬件计算能力跑满。

3、为了保证网络的整体可用性，区块链采用了P2P网络架构以及类似Gossip的传输模式，所有的区块和交易数据，都会无差别地向网络广播，接收到的节点继续接力传播，这种模式可以使数据尽可能地传达给网络中的所有人，即使这些人在不同的区域或子网里。代价是传输冗余度高，会占用较多的带宽，且传播的到达时间不确定，可能很快，也可能很慢（中转次数很多）。

对比互联网服务，除非出错重传，否则网络传输一定是最精简的，用有限的带宽来承载海量的数据，且传输路径会争取最优，点对点传输。

4、为了支持智能合约特性，类似以太坊等区块链解决方案，为了实现沙盒特性，保证运行环境的安全和屏蔽不一致性因素，其智能合约引擎要么是解释型的EVM，或者是采用docker封装的计算单元，智能合约核心引擎的启动速度，指令执行速度，都没有达到最高水平，消耗的内存资源也没有达到最优。

而用常规计算机语言如C++、JAVA、go、rust语言直接实现海量互联网服务，在这方面常常没有限制。

5、为了达到可容易校验防篡改的效果，除了第一条提到的，区块数据结构里携带数据较多之外，针对交易输入和输出，会采用类似merkle树、帕特里夏（Patricia ）树等复杂的树状结构，通过层层计算得到数据证明，供后续流程快速校验。树的细节这里不展开，可以通过网络上的资料来学习其机制。

基本上，生成和维护这种树的过程是非常非常非常非常繁琐的，既占用CPU的计算量，又占用存储量，使用了树后，整体有效数据承载量（即客户端发起的交易数据和实际存储下来的最终数据对比）急剧下降到百分之几，极端情况下，可能接受了10m的交易数据后，在区块链磁盘上可能实际需要几百兆的数据维护开销），因为存储量的几何级数增加，对IO性能要求也会更高。

互联网服务因为基本不考虑分布式互验互信的问题，很少有使用这种树的证明结构，了不起算下MD5和HASH做为协议校验位。

6、为了达到全网一致性和公信力，在区块链中所有的区块和交易数据，都会通过共识机制框架驱动，在网络上广播出去，由所有的节点运行多步复杂的验算和表决，大多数节点认可的数据，才会落地确认。

在网络上增加新的节点，并不会增加系统容量和提升处理速度，这一点彻底颠覆了“性能不足硬件补”的常规互联网系统思维，其根因是区块链中所有节点都在做重复的验算以及生成自己的数据存储，并不复用其他节点数据，且节点计算能力参差不齐，甚至会使最终确认的速度变慢。

在区块链系统中增加节点，只会增加可容错性和网络的公信力，而不会增强性能表现，使得在同一个链中，平行扩展的可能性基本缺失了。 

而互联网服务大多是无状态的，数据可缓存可复用，请求和返回之间的步骤相对简单，容易进行平行扩展，可以快速调度更多的资源参与服务，拥有无限的弹性。

7、因为区块数据结构和共识机制特性，导致交易到了区块链之后，会先排序，然后加入到区块里，以区块为单位，一小批一小批数据的进行共识确认，而不是收到一个交易立刻进行共识确认，比如：每个区块包含1000个交易，每3秒共识确认一次，这个时候交易有可能需要1~3秒的时间才能被确认。

更坏的情况是，交易一直在排队，而没有被打包进区块（因为队列拥堵），导致确认时延更长。这种交易时延一般远大于互联网服务500ms响应的标准。所以区块链其实并不适合直接用于追求快速响应的实时交易场景，行业通常说的“提高交易效率”是把最终清结算的时间都算在内的，比如把T+1长达一两天的对账或清结算时延，缩短到几十秒或几分钟，成为一个“准实时”的体验。