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

（本文原创做者：张开翔-FISCO BCOS首席架构师 ）

区块链领域最受关注的一个方面是“性能”，或者说“TPS”，比起来有种“不服就跑个分”的感受。跑分项包括TPS（每秒处理交易数）、并发能力（同时承担交易量）、交易响应时间等。然而，相比每秒能发送200万封电子邮件、支持数百万用户同时登陆一个社交平台的互联网服务来讲，区块链的速度简直是太！慢！了！ 甚至有人调侃说“区块链，不就是最慢的分布式数据库吗”（这句话能够展开多方面解析，本篇先讨论慢的问题）

区块链技术前景无限美好，可若是没有高性能表现做为支撑，没法运行快速的、执行复杂的智能合约逻辑，快速的完成交易事务，那些使人振奋的前景就只能是摘不到的镜中花，捞不着的水中月。

 

#举个例子

数钱，好比数一个亿（是否是好刺激~）

一、若是一我的数，慢，但好在专一，尽心尽力，在可见的时间内能够数完。这叫单线程密集计算。

二、若是N我的一块儿数，每人平分，分头同时数，最后汇总总数，所用时间基本上是第一种状况的1/N，参与的人越多，所需时间就越少，TPS就越高。这叫并行计算和MapReduce。

三、若是N我的一块儿数，但因为这N我的互相不信任，得彼此盯着，首先抽签选一我的，这我的捡出一叠钱（好比一万块一叠）数一遍，打上封条，签名盖章，而后给另外几我的一块儿同时从新数一遍，数好的人都签名盖章，这叠钱才算点好了。而后再抽签换我的检出下一叠来数，如此循环。由于一我的数钱时别人只是盯着，并且一我的数完且打上封条和签名的一叠钱，其余人要重复数一遍再签名确认，那么可想而知，这种方式确定是最慢的。这就叫区块链。

但换个角度，方式1，一我的数有可能会数错，这我的有可能生病或休假，致使没有人干活，更坏的结果是，这我的可能调换假币或者私藏一部分钱，报一个错的总数。

方式2，N我的中会有必定比例数错，也可能其中一我的休假或者怠工，致使最终结果出不来，更可能由于人多手杂，出现部分人偷钱、换假钱、报假数……

方式3，很慢，可是很安全，由于全部人都会盯着全过程进行验算，因此确定不会数错。若是其中有人掉线，能够换人捡出新的一叠钱继续数，工做不会中断。全部数过的钱上面都有封条和签名，不会被作手脚，万一出错了也能够找到责任人进行追责。这种状况下，资金安全是彻底获得保障的，除非全部的参与者都串通一气了。该模式下，参与的人越多，资金安全性就越高。

因此，区块链方案致力追求的是，在缺少互相信任的分布式网络环境下，实现交易的安全性、公允性，达成数据的高度一致性，防篡改、防做恶、可追溯，付出的代价之一就是性能。

最著名的比特币网络，平均每秒只能处理5~7笔交易，10分钟出1个块，达到交易的最终肯定性须要6个块也就是1个小时，且出块过程至关损耗算力（POW挖矿）。

号称“全球计算机”的以太坊，每秒能处理的交易数也仅是2位数的量级，十几秒出1个块。以太坊目前也是采用损耗算力的共识机制POW挖矿，会逐步迁移到POS共识机制。

这两个网络在粉丝们爆炸性地进行交易时，可能会陷入拥堵状态，大量的交易发出后，一两天甚至更长的时间才会被打包确认。

但在资金安全就是命的场景下，有些事情是“必须”的，因此，即便慢，仍是会考虑选择区块链。

 

#区块链为何慢

分布式系统里有一个著名的理论叫CAP理论：2000年，Eric Brewer教授提出一个猜测：一致性、可用性和分区容错性三者，没法在分布式系统中被同时知足，而且最多只能知足其中两个。

CAP的大体解释

Consistency(一致性) ：数据一致更新，全部数据变更都是同步的

Availability(可用性)：好的响应性能

Partition tolerance(分区容错性)： 可靠性

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

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

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

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

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

具体哪里慢呢？

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

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

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

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

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

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

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

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

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

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

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

互联网服务由于基本不考虑分布式互验互信的问题，不多有使用这种树的证实结构，了不得算下MD5和HASH作为协议校验位。

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

在网络上增长新的节点，并不会增长系统容量和提高处理速度，这一点完全颠覆了“性能不足硬件补”的常规互联网系统思惟，其根因是区块链中全部节点都在作重复的验算以及生成本身的数据存储，并不复用其余节点数据，且节点计算能力良莠不齐，甚至会使最终确认的速度变慢。

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

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

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

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

综上所述，区块链系统天生就背着几座大山，包括单机内部计算开销和存储较大，背着串行计算的原罪，网络结构复杂冗余度高，区块打包共识的节奏致使时延较长，而在可扩展性上又难以直接增长硬件来平行扩容，致使scale up和scale out两方面，都存在明显瓶颈。

Scale Out（等同scale horizontally）：横向扩展，向外扩展，如：向原有系统添加一组独立的新机器，用更多的机器来增长服务容量

Scale Up（等同Scale vertically）：纵向扩展，向上扩展，如向原有的机器添加CPU、内存，在机器内部增长处理能力

直面区块链的速度困境，FISCO BCOS的开发者发挥“愚公移山”的精神，努力优化。通过一段时间的努力，已经移山倒海，修出了一条又一条高速通道，使区块链找到了迈向极速时代的路子。FISCO BCOS修出来的高速通道是怎么样的，欢迎你们关注【FISCO BCOS开源社区】公众号，期待下一篇《FISCO BCOS的性能优化》，咱们将具体阐述FISCO BCOS是如何将区块链交易处理性能提高的。

---

 

咱们鼓励机构成员、开发者等社区伙伴参与开源共建事业，有你在一块儿，会更了不得。多样参与方式：

1 进入微信社群，随时随地与圈内最活跃、最顶尖的团队畅聊技术话题（进群请添加小助手微信，微信ID：fiscobcosfan）；

2 订阅咱们的公众号：“FISCO BCOS开源社区”，咱们为你准备了开发资料库、最新FISCO BCOS动态、活动、大赛等信息；

3 来Meetup与开发团队面对面交流，FISCO BCOS正在全国举办巡回Meetup，深圳、北京、上海、成都……欢迎您公众号在菜单栏【找活动】中找到附近的Meetup，前往结识技术大咖，畅聊硬核技术；

4 参与代码贡献，您能够在Github提交Issue进行问题交流，欢迎向FISCO BCOS提交Pull Request，包括但不限于文档修改、修复发现的bug、提交新的功能特性。

代码贡献指引：

https://github.com/FISCO-BCOS/FISCO-BCOS/blob/master/docs/CONTRIBUTING_CN.md

 

本文首发于公众号【FISCO BCOS开源社区】，如转载请注明出处，原创不易，谢谢珍惜