区块链架构设计建议：我们应该用区块链做什么？

一、区块链的“困境”

热得发烫的区块链在实际应用方面确实有很多难处，主要几点如下：

（一）吞吐量。比特币、以太坊自不用讲，号称百万级的 EOS，实测也只有几千 TPS，可以无币的 Fabric 实测也只有 300-500TPS，最新上线的百度区块链应用——图腾，号称单链过万，但是比起现有分布式数据库，比起阿里双十一的 25.8 万 TPS，仍是无法相提并论。

（二）容量。多数联盟链在实际应用场景中都难以支持较多节点数，因为节点多意味着交易验证、通信压力急剧增加，链的效率会大幅下滑。公链虽然可以支持较多节点，但是效率的降低导致容量的扩大缺乏了实际意义。

（三）智能合约。智能合约（Fabric 中称为“链码”）目前难以支持复杂逻辑，复杂逻辑不仅会在前述问题的基础上进一步降低效率，也很容易出错。这也导致目前的区块链系统无法像传统开发方式那样“神通广大”，支持各类复杂场景。

（四）存储。现有区块链如果应用于大型行业级业务场景或者数据量较大的业务场景，都将产生“灾难性”后果，而在笔者看来，存储才是“人手一本帐”最大的挑战，比特币对存储是做了高度精简的，而且比特币交易产生的数据量已经是很小了，在多年累积后存储依然是问题，如果希望广泛应用区块链技术，存储似乎就“无解”了。

那么产生这些问题的根本原因是什么呢？

核心其实是比特币的交易验证逻辑，比特币是对交易过程和结果的双重验证，即全网首先验证交易行为（签名），出块后再由全网验证交易条件（UTXO）、确认交易结果，为了支持这套逻辑，出块时间要控制、数据要人人都有、验证要人人都做，这对中本聪要构建的电子现金系统而言是必须的，要安全，也就是说，基于这个逻辑上述所有问题的产生都正常，是必要的“代价”，这也是 BM 提出要提升比特币效率时中本聪说他不懂比特币的原因。

对于以“币”为核心的应用来讲，这一切无可厚非，但是对于不以“币”为核心的应用，这个做法似乎有点“过犹不及”了。可问题恰恰就在于大家对区块链的“共识”导致可以无“币”的区块链应用或者说框架也在遵循“币”的逻辑，对交易过程和结果执行双重验证，试图监督所有“人”的一举一动，这导致区块链不堪重负，对于去中心化的共识使“人人都验证”成了思维定式。

比特币提供了一个非常好的、去中介的交易机制，于是被称为“信任机器”，但是对于大部分业务场景，我们是否需要比特币这样完整、严密的交易验证逻辑？大多数情况下，我们要达成的“共识”是对交易过程和结果的同时认可，还是更注重结果的不可篡改、不可抵赖？我们是试图同时监督所有人，还是更好地监督中心化节点的行为？笔者认为，大家目前除了致力于提升区块链的底层技术外，更需要多从业务自身的角度出发，考虑应该怎么用区块链，用区块链证明什么、监督什么，从而优化区块链的设计思路。

区块链所谓的“困境”也许并不是技术造成的困境，而是目的造成的困境。

下面笔者拟就 Hyperledger Fabric 架构探讨优化区块链设计的方法。

二、以 Fabric 为例的架构设计优化思路

（一）Fabric 的现状与优化的出发点

Fabric 是目前较为成熟的联盟链设计框架，其主要交易过程如下图所示：

从上图的 Fabric 基本流程中，我们可以发现，一笔交易由应用程序提出后，在 Fabric 网络中，首先由背书模拟节点执行并返回执行结果（读写集）给应用程序，再由应用程序提交排序节点出块，之后所有记账节点要执行对链码版本、状态数据版本、背书策略等校验，通过后再完成账本更新。整个过程即考虑到了对交易的验证，也考虑到了链码升级、数据一致性等问题，设计上可以说比较完备。但是回到本文之前的观点，这种严格的一致性、安全性产生了网络性能问题，无论在吞吐量、容量、链码设计自由度、存储这几个方面，Fabric 都有很多需要改进之处，但这些是否都是有待技术突破的问题呢？

如果我们换个思路考虑下，从业务自身的角度出发，我们是否需要这种对过程和结果的双重监督？比如医疗行业的业务场景，医生开处方这件事，需要什么样的验证过程呢？甲医院开的处方正常情况下要拿到乙医院去验证吗？显然不会。我们要监督的不是医生开处方的过程，而是确保医生开的处方不可篡改、不可抵赖，需要患者在转院、在药店购药、医保审核处方、监管部门检查“高药占”等问题时，处方可以被区块链网络证明为真实。从这个角度思考的话，我们在很多业务场景下需要的只是将关键数据的 hash 上链，成为数据监督机制、数据公证机制，使对中心化节点、专业领域的公开监督成为可能。

也许很多人会认为，数据本身不上链将无法保证数据的不可篡改，但是实际应用中，我们通常需要的是证明没有发生篡改，而未必是不可篡改。还是处方的例子，如果医患双方对处方发生了争执，首先要解决的就是双方证据的真伪，通过比对双方提供的证据是否能够还原出链上的 hash 值，即可快速完成证据的验证，即便是医院，如果无法提供与 hash 值相符的处方数据，也将无法自证清白；如果任意一方的数据没有问题，都可以做为继续调查的基础，区块链做到这里其实已经足够了，剩下的事情不是区块链该去解决的问题。

数据的不可篡改或者说数据安全，并不一定是区块链必然的职责，考虑到区块链存储方案的特殊性和高昂成本，数据中心对于解决海量数据的存储与管理仍是最优选择，而搭配上区块链提供的防伪机制，数字社会的建立将更加可靠。所以，区块链本身与其说是“去中心化”不如说是“防中心化”，防止中心节点“作恶”，但即便是比特币也要通过经济手段达成“防中心化”。

那么，我们思考区块链应用时，不如也从监督“中心化”节点的行为入手，来思考利用区块链数据共享、数据防篡改的能力，通过 hash 上链的方式，为极富效率的“中心化”系统加上一个“阳光”的监督，在大部分领域，将设计由对交易行为、交易验证的关注，转移到对交易结果真伪的易验证性的关注。

（二）优化后的设计思路

基于前述出发点，我们可以重新考虑下 Fabric 的交易过程，如下如所示：

优化后的流程中，应用程序首先在 Fabric 网络之外产生需要监督的数据，然后提交给 Fabric 网络，出于提高可信性的考虑，网络随机选择记账节点去调用链码产生待监督数据的 hash，连同用于计算的字段名提交给排序节点出块，然后再广播至全网。由于链码只生成了 hash，因此原来的确认阶段只需要检查链码的状态后即可直接入账，架构中不需要状态库和历史库，只保留账本数据即可。支持其他应用程序自由查询待监督数据的链上 hash，对获得的原始数据进行验伪。

这样设计的优点如下：

1. 可以实现前文所述的数据真伪的易验证性。hash 数据在链上可供任何接入的应用程序自由查询，去跟原始数据做校验。其实在数据验伪、溯源方面一直存在一个误区，我们总想拼命证明一件事情是真的，但实际上，我们最多只能做到证明一件事情在记录后没有被篡改过。
2. 吞吐量上升。由于只处理 hash 值，网络在算力消耗、通信方面的压力大幅下降，基本上可与目前多数公有云的效率相当。
3. 更容易做到数据的隐私保护。区块链的开放性和数据的隐私保护一直是个矛盾的话题，尽管出现了不少能够在一定程度上解决问题的方法，但是，我们也要思考下，当我们应用了区块链的共享优点时，是必须给这个优点打个折，还是另寻其他数据隐私保护机制？现在的系统建设提倡平台思维、生态圈建设，实际上在做平台设计时，链外本身就有更有效的数据处理方式，我们要做的其实应该是给“中心化”的平台设计，提供“阳光”的监督，给各参与方都提供便捷的方式监督中心节点对数据的威胁。
4. 提升链码的能力。图中虽然链码只做了 hash 计算，但实际上，由于大量数据不在链上，链的性能提高，反而可以解放链码的设计，支持复杂应用，与“传统”业务系统进行融合设计。只要保持链码无状态，加强对链码的监督和审计，也能防止链码造成数据泄露。在对链码部署、更新权限进行控制（其实联盟链的设计过程本来就偏中心化，因此控制链码的部署、更新权限与现实情况基本是一致的）的基础上，链码设计上可以参考 SOA 或者微服务的形式，成为可自由调用的服务，链码运行结果中，依然是 hash 上链，其他数据返回给调用链码的应用程序在链外数据库存储，区块链网络与本地系统的融合与混合云架构的实现方式非常类似。
5. 容量可以充分扩大。由于摆脱了大量的数据和繁复的校验，网络容量可以大幅提高，节点的增加对网络不会造成过大的压力。
6. 减轻存储压力。与保存完整数据相比，保存 hash 值对存储的消耗要小的多。
7. 可扩展性。由于链上只存储 hash，所以，网络在不同数据类型、标准方面具有很强的兼容性，实际上也不存在跨链问题。

三、尾声

区块链虽是一项众说纷纭的技术，但是其潜力不容忽视。

本文提出的观点在很多区块链的拥趸看来可能是一种倒退，但是技术人员是现实主义者，或者说是具有浪漫主义色彩的现实主义者，不会为了定义去设计系统，而是从解决问题的角度出发去应用技术，我们的社会生活中，有很多环节需要提供有效的监督机制。

比特币“人手一本账”的解决方式的确非常有效，尤其是在虚拟货币方面，但是对于大量非虚拟货币应用，其实现代价和难度在现阶段过高，但是它提供的思路却非常值得我们借鉴，可以仅通过 hash 上链来监督节点，创造一种数据公证机制，即对恶意行为构成一种威慑，也为正常业务行为提供了良好的自证方式，提高数据可信性，降低交易成本，但是灵活应用区块链，需要我们真的可以跳出“币”的思维。越多的数据上链，就意味着越复杂的验证机制，对架构设计而言，就意味着必要的权衡，需要认真思考业务目的及其实现方式。

区块链面临的技术问题留给时间解决，但是这并不妨碍我们在现阶段以合适的目的与方式大规模应用区块链技术。

作者介绍

付晓岩，中国建设银行股份有限公司北京开发中心，业务经理。多年从事银行业务架构设计工作，负责过客户关系、金融市场、同业、资管、养老金等多个领域核心系统的业务架构设计。在银行业务条线工作 12 年，技术条线工作 6 年，作为业务架构设计人员参加建行“新一代核心业务系统”建设五年，具有丰富的银行业务经验和企业级项目业务架构设计经验。对区块链技术有厚兴趣，曾在建行报发表过用区块链技术构建同业市场的文章，在未央网发表过谈谈数字货币可能诱发现金社会的文章。