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 的批判可谓是一针见血。对此，你怎么看？
推荐阅读：在币圈, 如何玩转反间计?
从这5个场景, 看MPC多方安全计算的行业应用Libra硬刚微信、支付宝? 你也试试!Python三十年技术演变史登月源码登顶 GitHub Top1，37000 Star 致敬人类登月 50 周年！AI 补代码神器诞生，百度网盘克星诞生，Google 取消中国搜索引擎项目！面试鹅厂，我三面被虐的体无完肤……中国第一程序员，微软得不到他就要毁了他！

猛戳""有惊喜哟

老铁在看了吗？👇








Stuart Popejoy




扫一扫下载订阅号助手，用手机发文章

赞赏



长按二维码向我转账


受苹果公司新规定影响，微信 iOS 版的赞赏功能被关闭，可通过二维码转账支持公众号。


















已同步到看一看



取消
发送


我知道了








朋友会在“发现-看一看”看到你“在看”的内容
确定













已同步到看一看写下你的想法



最多200字，当前共字
发送







已发送







朋友将在看一看看到
确定



写下你的想法...









取消
发布到看一看
确定




最多200字，当前共字








发送中













微信扫一扫
使用小程序







取消
允许






即将打开一个新页面

取消
允许