作者 | Stuart Popejoy
编译 | 王国玺
出品 | 区块链大本营（blockchain_camp）
自 Libra 发布以来，沉寂已久的区块链社区又活跃了起来，一些探索区块链业务的公司也在暗地里较劲不甘落后。相信你也注意到了，这些大公司往往都对现有比特币、以太坊等区块链视而不见。这是因为它们深知数据的重要性，因而不会选用比特币、以太坊这些把数据开源公开的公有区块链，而是对可以控制参与者加入的私有区块链情有独钟。
说到私有区块链，就不得不提到 IBM。IBM 可谓是私有区块链领域的领头羊，其区块链产品 Hyperledger Fabric 是许多区块链开发人员的首选，同时 IBM 还与沃尔玛、美国安泰保险金融集团这样的大公司强强联手，一起进行区块链落地场景的探索，以在企业区块链中抢占先机，扩大优势。推特上有人统计，仅在过去一年，IBM 区块链专利的数量就增长了 300%。
作为开源非营利组织 Hyperledger 基金会的众多贡献者（其中包括最近加入的微软以及客户关系管理平台 Salesforce）之一，IBM 可谓是花了血本来推动 Hyperledger Fabric 的发展，这意味着 Hyperledger Fabric 会有和比特币、以太坊这些常见区块链一样的特性，同时会在其中删除“并不适合企业场景”的特性。
虽然说 IBM 将 Hyperledger Fabric 称为区块链并以区块链的名义来营销，但无论是与许可区块链相比还是与公有区块链相比，Hyperledger Fabric 都牺牲了很多一个真正意义上的区块链应有的特性。
虽然 Hyperledger Fabric 的架构远比任何区块链平台复杂，但它在防篡改与防范攻击等安全性特性方面依然做得不尽人意。你可能还会觉得“私有”区块链至少能保证在可扩展性和性能上满足需求，但 Hyperledger Fabric 的这两个特性也会让你失望。简而言之，基于 Hyperledger Fabric 的实验将面临区块链复杂且不安全的问题，同时区块链的可拓展性可能也不能满足业务快速增长带来的需求。
对此，前摩根大通区块链团队领导人物 Stuart Popejoy 更是一针见血，声称 IBM 做了一个假的区块链！
为什么 Stuart Popejoy 认为 IBM 做了一个假的区块链？这篇文章告诉你。
【声明：文章仅代表个人观点，其内容与观点不代表区块链大本营立场】
Hyperledger Fabric 性能指标
具有误导性
2016年我在摩根大通工作时，我领导了一个专攻前沿技术的团队，来研究区块链在银行业中的潜在应用以及对区块链的战略投资。作为工作的一部分，我们深入分析了早期版本的 Hyperledger、Axoni、Symbiont、Ripple 以及以太坊。当时很明确的一点是，市场上的几个区块链项目从技术上来说都不适合真实的企业场景。不幸的是，时至今日 Hyperledger Fabric 还是没有解决这个核心问题。当时我们考虑到的细节包括：
- 区块链的智能合约语言如何安全、简单地表达出复杂的业务逻辑？
- 如何保证公钥签名的有效性？
- 区块链是否可以在不大幅度降低性能的前提下加入其他的参与者（节点），从而实现可拓展性？
- 那些目光长远的企业还会考虑到被选择的区块链将来能否可以轻松地与其他公有区块链或私有区块链进行互操作？
从这几个细节入手分析，我认为 IBM 的 Hyperledger Fabric 从根本上缺乏区块链的必要元素，其性能指标充满了误导性，在长期业务上的可行性也不禁让人打一个大大的问号。
我们从来没有将 TPS、节点数这些忽悠外行人的数字游戏看作是区块链的采用标准，但在经历多了这些数字游戏之后我们认为有必要告诉读者什么是区块链，而什么不是区块链。
什么是区块链？什么不是区块链？
为更好地理解 IBM 区块链的定位，我们需要回到区块链的定义。区块链的核心是一个去中心化的不可篡改的账本，账本中存储着事件或者交易，而往账本中加入哪些数据完全由共识机制来决定。在比特币和以太坊这样的公有区块链中，这种共识是通过工作量证明或称“挖矿”来实现的。在许可区块链中，参与者提供密码学签名来对共识的内容进行投票，从而达成共识。无论是哪种方式，都不会有中央机构进行干预。
而 IBM 对区块链的定义延续了去中心化和不可篡改这两个区块链的元素，但它为了方便省去了去中心化的共识机制，从某种程度上来说，Hyperledger Fabric 根本不需要一个真正的共识机制。相反，Hyperledger Fabric 推荐使用一个名为 Kafka 的“订购服务”。
但问题是，如果没有基于密码学算法的强制执行、没有高度的民主化、没有密码学机制保证参与者投票的安全，那么你就不能证明是否有人篡改了区块链这个账本。带有容错机制的共识是区块链的标志性特征，少了它，IBM 的“区块链”只不过是一个带时间戳的项目列表。
Hyperledger Fabric 的体系架构暴露出许多可能会被恶意参与者利用的漏洞。就比如说，它在“网络内部”引入了公钥加密机制和验证者签名，但是这些主要的安全保证只有在提交了外部签名的交易之后才产生。
这从根本上废除了比特币以及其他区块链久经时间验证的安全模型，其中任何交易的来源仅由外部用户的公钥签名来保证，并且系统不能以任何方式进行干涉。
与之形成鲜明对比的是，Hyperledger Fabric 中唯一一个重要的签名就是验证者的签名，而用户的签名则消失在通过区块链网络复制的任意数据库中。
Hyperledger Fabric 1.0 交易生命周期
图片来源：developer.ibm.com
在 Hyperledger Fabric 所提供 API 的帮助下，向区块链中加入一笔交易要经过如下步骤：
一笔交易预提案被提交后，由背书节点（ endorsing peer ）通过智能合约语言 chaincode 执行它的逻辑，同时它会查询状态数据库并生成要使用到的读写集（ REset ），之后它还会连同生成的读写集返回交易预提案的回应。接下来，系统会将带有读写集的交易预提案提交。订购服务会把一批次的交易加入到区块中。所有的节点都会收到订购服务发来的区块信息，但它们需要验证区块中的交易信息来保证区块链中数据的安全性，步骤如下：
1、验证背书节点的执行策略；
2、验证当前状态数据库中读写集的版本；
3、向区块链中提交区块信息；
4、向状态数据库中提交已验证过的交易信息。
Hyperledger Fabric 的研究人员不遗余力地玩这些数字游戏，在所谓的性能指标上做文章，因为从根本上来说 Hyperledger Fabric 的架构根本无法在保持最佳性能的同时进行扩展。Hyperledger Fabric 使用一个多链环境（被称为“通道 channels ”）来保证参与者之间的隐私性。这种隐私性是私有“企业”区块链的一个重要特性，但它必然会带来一些折衷，也会大大增加区块链的复杂性。
但从企业区块链需要的可拓展性方面来说，多链解决方案并不是一个好的选择，因为这样做会使得部署过程太过于复杂、节点分布不均匀、智能合约不可靠、还会大大增加潜在的故障点。
因此，Hyperledger Fabric 区块链在部署之后的性能指标并不尽如人意，随着节点的增加性能还会迅速下降，而且它所宣称的性能是单通道时的性能：如果你想跨过多个通道与整个区块链网络进行交互，这些所谓的性能指标没有任何意义。
即便如此，对于每个独立的通道，区块链的每秒处理交易量很难突破800这个大关，但即使是拥有16个通道配置的区块链也几乎不能达到1500TPS，若区块链一直维持吞吐量上限运行，其延迟时间可能会达到10到20秒。
最近一些旨在加快 Hyperledger Fabric 运行速度的研究使得其每秒处理交易量能达到惊人的20000，但性能大幅度提升的背后是研究人员对 Hyperledger Fabric 架构的大规模“魔改”，这使得 Hyperledger Fabric 已经成一个近似的区块链变成了一个四不像：背书节点（Endorsers）不再充当验证者而 Kafka 被认定为唯一可行的订购服务。最后，这些仍然只是单通道的性能，这意味着它与区块链作为共享可信来源的整个理念相违背。
注：从理论上讲，Hyperledger Fabric 可以使用真正意义上的区块链共识，但这样做区块链会变得很慢，而在生产环境中慢是致命的，因此没有人会在生产环境中使用它。
为什么说智能合约很重要？
我们在评价区块链时，最后一个考虑因素是区块链准备如何扩展私有数据库，以及区块链的工具（比如，智能合约语言）如何在企业业务规模飞速发展时不掉链子。需要注意的是，智能合约不仅仅是一段代码，它是公司业务逻辑的体现。智能合约可以执行区块链上的产权登记，数字身份的验证，甚至可以用来执行二手车买方和卖方之间的托管交易。最重要的是，智能合约是可靠的，它始终会按照你给它的规定行事。
在区块链上构建业务逻辑时，你需要将自己想要进行的操作（买入、卖出、打包数据等等）用智能合约表示出来。如果智能合约语言使用起来简单而又方便，你就能快速地构建出想要的业务逻辑向你的老板或股东交差。更重要的是，你肯定会希望智能合约的功能十分强大，能够为你的业务带来收益或一些积极的影响。
Hyperledger Fabric 的智能合约（称为链码“Chaincode”）可以用多种编程语言编写，其中包括常见的 Javascript 语言以及 Go 语言。但使用开发人员十分了解的通用编程语言开发是一把双刃剑，它在大大简化开发过程的同时，在安全性方面与专为区块链开发的编程语言相比大大弱化。如果 Hyperledger Fabric 中累积的权益越来越多，总会有人铤而走险。
在这时如果代码有缺陷或不正确（因为它不是专为区块链设计的）那么可能会造成数百万美元的损失。因此我们认为智能合约语言必须专为区块链设计且为安全性做出了优化。在理想的情况下，智能合约语言也应该易于学习，并能便捷地在区块链环境中使用。
Chaincode 在这几个方面可谓是彻彻底底地失败了，我们发现被誉为开发人员的第一个程序 “Hello World” 在其他语言中仅需几行就可以实现，而在 Chaincode 中居然需要150行之多。代码越多，可能存在的漏洞就越多。这么大数量的代码中可能隐藏着很多能造成数百万美元损失的漏洞。
编写以及阅读智能合约本不应该如此困难。开发人员不得不处理调度（dispatch）、实参发现（arqument discovery）这些低级问题。代码越多，可能存在的漏洞就越多。
用 Hyperledger Fabric 编写“ Hello World ”智能合约
图片来源： Chainhero 、Kadena
没有为未来做好准备
在区块链生态系统中，越来越多老道的观察家都开始意识到私有区块链和公有区块链不可能完全隔离开来，而是会走向合作，相辅相成，共同促进：私有区块链会希望自己的通证对公有区块链上的客户可用，部署在公有区块链上的去中心化应用程序也会希望将隐私数据存储在私有区块链中。
很不幸，Hyperledger Fabric 以及 R3 Corda 都因为架构的完全不兼容而与公有区块链切割开来，这里面也有智能合约的责任，因为它们的智能合约语言无法在公有区块链和私有区块链中无缝切换。
IBM 通过与其他大公司深入合作主导了许多企业区块链的标准制定，但重要的是褪去表面的浮华去深入探索区块链这项技术实际可以做些什么。
IBM 所谓的“区块链”技术在安全性、性能、可靠性等很多方面都存在缺陷，换句话说，IBM 为希望使用区块链实现业务提升的企业提供了一个质量较差的解决方案。为更好实现区块链的价值，老练的客户将会选择那些有着更好工具、区块链性能更优、愿景更好以及真正懂得如何使用这项技术的区块链解决方案。
【声明：文章仅代表个人观点，其内容与观点不代表区块链大本营立场】
关于作者： Stuart Popejoy 拥有15年的金融机构构建交易系统和数据交换骨干网经验。2016年 Stuart 与 Will Martino 共同创立了区块链解决方案公司 Kadena 并成为公司总裁。在此之前，Stuart 曾在摩根大通集团的区块链产品部门工作，期间领导和开发了摩根大通的主要区块链产品 Juno，同时 Stuart 还为摩根大通编写了许多交易算法脚本，这些经验的积累帮助他在 Kadena 公司开发出简单、定制化的智能合约语言 Pact。
今日话题
一千个读者就有一千个哈姆雷特，本文作者对 Hyperledger Fabric 的批判可谓是一针见血。对此，你怎么看？
