区块链与现实｜数据延迟怎么办？吞吐量怎么扩

小提示：您能找到这篇{区块链与现实｜数据延迟怎么办？吞吐量怎么扩}绝对不是偶然，我们能帮您找到潜在客户，解决您的困扰。如果您对本页介绍的区块链与现实｜数据延迟怎么办？吞吐量怎么扩内容感兴趣，有相关需求意向欢迎拨打我们的服务热线，或留言咨询，我们将第一时间联系您！

前语

制约区块链投入大规模应用的瓶颈很多，很难在一篇文章里完全介绍，所以我们做了一个系列四篇文章来逐个探讨。这个系列分为四篇，分别从数据同步的吞吐量，跨中心的控制管理机制，多参与方的安全隐私交易，以及杀手级应用的实践与特点几个方面来解析。我们首先来谈谈区块链数据同步及吞吐量方面的难点及发展。

公有链和联盟链的区别

简单来说，区块链是一种分布式数据库，其特殊之处在于无（弱）中心化。从面向人群来分类，区块链可分为公有链和联盟链（或私有链）两大类。公有链面向所有参与者开放，所有人都可以参与；联盟链，通常认为与私有链类似，面向特定的组织团体或者单独的个人或实体开放。公有链和联盟链在实现上有很多不同，其中最显著的不同点就是共识机制的差异。

公有链共识机制的制约

区块链网络上的多个参与方，在每次更新链上数据时（例如转账）必须要获得一定数量的参与方认可才可以进行，这个认可过程就是共识机制。该机制的主要目标是在参与方控制多个节点的情况下，杜绝多个参与方联合造假的可能性。

目前，以比特币、以太坊为代表的公有链，其共识机制并不适合商业场景使用，主要有三个原因。第一是性能远低于商用需求，以金融系统为例，延迟 1 秒已经难以适用于多数场景。 而延迟 1 秒会带来什么？除了降低用户体验以外和热点账户使用率外，第三方也会获得充足时间通过高频交易策略给交易人带来损失，但最为恐怖的是， 这区区几秒的延迟可能会破坏整个体系个个子系统对交易”超时“的定义从而导致生产系统故障。因此目前耗时数秒，甚至数分钟的共识机制基本无法列入候选；第二是弱最终一致性，会导致参与方无法在固定时间内 100% 确定交易的成功与否，例如公有链上的一个现象是，一笔最初显示成功的交易有可能在几个小时后判定为失败，这在现实金融业场景中是无法接受的，因为这种特性同样可能带来金钱上的损失；第三是安全性，公有链的安全机制一般是靠参与者算力或者代币持有量来维持的，对资金额巨大的金融机构或者国家机关来说，是完全有能力创建或直接控制大部分资源，进而彻底破坏整个区块链网络。因此仅仅通过算力或代币规模进行利益绑定保证的安全机制是难以承担关系到金融体系的大格局网络的。

联盟链共识机制及瓶颈

为了解决公有链共识机制的问题，业内引入了联盟链。在联盟链场景中，共识机制里防止造假节点的问题通常称为拜占庭将军问题；能够防止恶意造假节点的算法，也被统称为拜占庭将军算法（ BFT ）。用通俗的话讲，共识机制就是让参与方来一起投票来决定是否接受一笔交易。其中较有代表性的舆情监测流程是PBFT算法（ PBFT 诞生于 1999 年，因为区块链的推动终于在沉睡十几年后获得长足发展的可能）。这些年中 PBFT 算法的衍生品能叫得出来名字的也有不下 20 种。基于 PBFT 的联盟链共识机制，虽然在理论上大大减轻了公有链问题的严重性，但其自身的一些劣势也长期限制了它们的发展。理想的商用共识机制必须是完整、稳定的，并且能够应对所有可宁夏舆情能发生的异常。什么是异常？简单说就是如果你去银行转账，但银行系统由于之前被黑客攻击或者网络堵塞等各种原因不能工作了。而 xBFT 系列算法的最大问题，正是由于需要处理各种异常而引入的复杂性。以 2003 年发表的第二版完整版本 PBFT 算法论文为例，文中只有一小部分论述算法的正常流程，绝大部分内容都在探讨各种可能出现的异常情况以及处理方案。目前国际上一般认为可用性最高的超级账本 Fabric 0.6 版本中的 PBFT 实现，也只实现了 PBFT 的基本功能，在“正常环境”下可以工作，离真正完整、稳定、可商用的目标还尚需时日。至于后面的 S（P）BFT，目前也还是在前期开发中。

除了以上问题， xBFT 系类算法的另一个通病是多节点数据执行的确定性，节点分布在各个不同的地点，但是要求它们对同样指令的计算结果必须是一致的。虽然概率很低，但同样指令在不同环境不同物理机下执行结果不一致的情况也确实发生过。不解决这个问题，就无法应用在一些相对严苛的系统环境里，如金融类系统。解决这个问题需要对预计算的结果进行背书，虽然 PBFT 算法设计之初这类问题就被提及，遗憾的是目前各种 xBFT 实现中极少考虑到这个问题。

除此之外， xBFT 算法下如何动态增加节点也是一个多故障点的复杂工程，虽然已经有一些这方面的尝试（如 BFT-SMaRt ，已经开发 5 年 ），但是由于高复杂性目前还很难保障最基本的稳定运行，离商用需求的稳定性需求和各种异常处理机制的完善也还相差甚远。对这些问题的深入理解，也是平安壹账通在设计 FiMAX 产品时在共识机制的选择及开发上，尽量采用成熟度可商用且容易被接受的机制。

扩大吞吐量的尝试

在公有链上，扩大吞吐量近年来一直有很多尝试。使用的策略大多分为两类，第一类是链下清结算模式，在必要的时候才将交易写到链上，这类以闪电网络为代表；另一类是多链分片模式。

前者（链下清结算模式）虽然概念新颖，涉及点除了技术层面，还新增加了链下商业角色，对商业模式也有创新。该模式在公有链网络上才刚刚开始测试，并且功能上单一，短时间内还无法适用在需求繁琐的商业场景中。相比前者，后者（分链模式）虽然现在有了很多变种（如 DAG ）但难点则都主要集中在技术层面，由于分布式存储特性的限制，为换取更大的吞吐量往往要牺牲部分数据一致性，势必会为保证准确性而增加交易延迟，甚至是长时间不确定延迟。对于最终一致性问题本身已经不尽人意的区块链系统来说，分链分片的引入也许在公链环境能被接受，但在现实金融关键任务系统中的运用上不现实。

跨链的问题

近年来各种区块链和代币越来越多，代币之间的交易也随之增长，一个逐渐变为热点的话题就是“跨链”交易。从分布式数据库领域来看，跨链并不是一个新话题，如何实现两个不同数据库之间的更新同步，在该领域已经被探讨和实践了几十年。其中最重要的问题就是，如何保证两个或多个数据库上的信息更新是同时成功或者同时失败的，对区块链而言，就是不同区块链网络上的同一笔交易，要被两个网络同企业宣传片制作报价时认定为成功或失败，不能一边认定成功，另一边认定失败。举个例子，如果一个客户用现金购买股票，当现金转出的同时股票必须同时转给这个客户，不能出现款扣了但股票转让失败，或者股票成功转给了客户但没有扣款。目前，业内提出来的“跨链”技术虽然多种多样，但其原理都是分布式数据库理论中“二阶段提交”方法的变种。相比传统的二阶段提交，更为复杂的是，区块链的最终一致性导致“跨链”时的交易失败率提高。尤其在二阶段提交中对“超时”的定义和判断上，这个原本制约二阶段提交广泛应用的问题，会让区块链交易延迟不可控的问题进一步恶化。

因此，我们在设计 FiMAX 产品中秉承的理念是，突破吞吐量的限制必须，也只能，从单链开始，多链、跨链等机制都要尽量避免，不到迫不得已不要轻易使用。目前， FiMAX 网络上每个节点只需要 2.1Ghz 8 核 CPU 、无跨链、无分链分片的情况下，支持每秒 5000+ 笔的交易吞吐量，并能够通过简单方便的硬件升级迅速成倍提高单链吞吐量到数万级别，综合性能与传统数据库已很接近，已具备支撑大规模商业应用的能力。

在跨链方面， FiMAX 系列体系为客户提供三套方案。因为由于网络延迟，算法复杂等原因造成的一些无法避免问题，  FiMAX 的三套跨链方案的理念是让客户根据自身的需求在复杂度和效率上做出平衡选择。

发展方向

虽然还在起步阶段，但平安投产的区块链应用已经超过 14 个，国际国内专利也发表了 60 份以上。以我们的实践经验来看，要想说服大型机构真正采用区块链技术作为生产应用，而非仅仅是 PoC 实验项目，首先最值得关注的就是数据同步的稳定性和一致性，因为只要涉及真实生产数据的场景就必须是稳定压倒一切。 因为在关键任务系统中，任何“暂时”性的数据不一致或者理论上的“小概率”事件都会带来灾难性的后果。

（作者陆一帆系平安壹账通壹账链项目总监， FiMAX 总架构师；褚镇飞（平安壹账通壹账链技术副总监， FiMAX Core 首席架构师）