声音|前摩根大通研发：为什么 IBM 区块链不是真正的区块链？

作者 | Stuart Popejoy，涉足金融领域 15 年，在贸易系统和交易平台框架创建方面拥有丰富经验。曾供职于美国摩根大通公司的新产品研发部，期间领导开发了摩根的区块链主打产品——Juno。Stuart 还参与编写了摩根的算法交易脚本，为日后 Kadena 简洁特定的智能合约语言奠定了基础。离开摩根后，与 Will Martino 在 2016 年联合成立智能合约创企 Kadena，任公司总裁。

翻译 | 岳巍

IBM 是企业区块链领域的重要参与者，其区块链平台以 Hyperledger Fabric 超级账本为基础，为很多大企业比如沃尔玛和安泰保险都开发过区块链试点产品。

Hyperledger 基金会是一个开源的公链项目，属于非盈利机构。作为机构的赞助商之一（最近微软和软件服务公司 Salesforce 也宣布入驻 Hyperledger），IBM 投入了大量资金，计划推动机构向私有链或“许可链”方向发展。IBM 似乎有他自己的投资意图：Hyperledger 既要与业界知名的比特币和以太坊等公链保持共通性，也要去除掉身上“不适合企业发展”的特点。

但不管公有还是私有，IBM 这种既保公链，又搞创收的行为恰恰忽略了 Hyperledger Fabric 区块链最重要的特征。Fabric 的架构比任何区块链平台都复杂，同时，面对未来可能的篡改和袭击风险也不够牢靠。你可能想，毕竟是“私有链”，多少有扩展性和效率的优势，但很抱歉，Fabric 在这方面也好不到哪儿去。简单说，基于 Fabric 建立的试点项目在部署过程中会面临很多复杂因素和不安全状况，未来扩展到其他企业的可能性不大。

2016 年，我还在摩根大通的时候，曾领导一个新兴的技术小组负责研究和审查市面上的区块链项目，为公司未来的战略开发和投资作铺垫。我们对 Hyperledger、Axoni、Symbiont、Ripple 和以太坊等早期版本都做了深入分析。当时我们发现，市面上的区块链项目在技术上都不足以支撑企业的应用。 非常遗憾的是，当时的问题在今天的 Hyperledger Fabric 上仍然存在，而且是核心问题。

问题有很多：区块链的智能合约语言如何将复杂的商业规则以安全简单的方式表达出来？公钥签名如何保证有效？区块链系统如何在不减缓效率的前提下扩展更多的节点？还有，作为一家面向未来的公司，如何与其他的公链和私链轻松做到交互操作？

从这些问题看，我认为 IBM 的区块链系统缺乏区块链的必要元素，不仅其效率指数可能给企业造成误导，而且在保证企业的长期生存能力方面也要打个问号。虽然我和同事不应该只把效率（比如每秒交易量和节点数等）作为区块链技术的唯一衡量因素，但我们认为，大家有必要知道区块链应该是什么不应该是什么。厘清这个概念有助于我们更好地理解区块链这项新技术的变化。

要想真正理解 IBM 的区块链立场，我们需要看看区块链的定义。所谓区块链，其核心要义是记录项目和交易数据的不可更改的去中心化账本，实际的交易记录通过共识机制执行。在比特币和以太坊等公链中，共识机制的实现方式是工作量证明机制，俗称“挖矿”。在许可链中，共识机制的实现方式是参与节点提供加密签名，对书面条款投票表决。不管哪种链，都没有中心机构参与其中。

IBM 的定义抓住了区块链的分布性和不可篡改性，但忽略了去中心化共识，这就是为什么 Hyperledger Fabric 没有对真正的共识机制提出要求。取而代之的是，它使用了一种叫做 Kafka 的“订阅系统”。但问题是，只有参与方强制执行了民主式投票机制，我们才能证明账本信息未被篡改。容错机制是区块链的标志特征。如果没有容错机制，IBM 的“区块链”几乎跟时间戳也没什么两样了。

Fabric 的架构同时暴露了很多弱点，这些弱点很容易被不法分子利用。例如，Fabric 在验证者签名的“网络内”上使用公钥加密技术，这种做法确实提供了安全保证，但前提条件是，只有当外部签名交易提交后才可启动。

从根本上来看，比特币及其他真正区块链系统已验证的安全模式可能失效。在比特币等真正的区块链系统中，交易记录只能通过外部用户的公钥签名确定，任何形式的中间力量都无法参与到系统中。但是，Fabric 共识机制中真正重要的签名属于验证人，而用户签名在任意数据集的网络复制过程中往往不受重视。

Fabric 的研究者之所以不断强调效率指数（比如交易速度等），就是因为 Fabric 的架构无法在保持高效率的同时进行扩展。Fabric 运用多链环境（通道）为用户保密。保护用户隐私是私有“企业”链的一个重要特征，不可避免会涉及很多权衡和复杂因素，但是多链方案不适合扩展。而且在节点部署方面也很复杂，各节点参差不齐，智能合约可靠性低，单点故障容易扩散。

所以，对于一个标准的 Fabric 部署来说，效率指数高不能说明问题。随着节点数的增加，通道重新恢复为单通道，效率指数也会迅速降低：如果你想通过多通道与全网做交易，效率指数没有多大参考价值。即使你看见单独通道的每秒交易量已拼命达到 800 以上，但 16 个节点的通道参数也不会超过每秒 1500，节点参与量一旦变高，延迟可能达到 10-20 秒的长度。

最近，Fabric 下了大功夫，据说每秒交易量被提高到了 20,000 的水平，但研究者在架构层面做出的改变大大偏离了区块链的本质，以至于改后的架构属性面目全非：赞助人无法承担验证者的角色，而且 Kafka 系统作为唯一的订阅系统也成为摆设（从理论上说，Fabric 可以采用真正的区块链共识机制，但速度会很慢，实际应用的可能性不会很高）。

最后一点，速度指数只停留在单通道层面，意味着区块链无法成为整体的共享信息来源。

面对区块链，最后一个考虑的点是：它如何超越私有数据库进行扩展？区块链工具（比如智能合约语言）如何帮助企业取得广泛的成功。

请记住，智能合约不是所谓的“代码”，它是一种商业逻辑的体现。你可以通过智能合约在区块链上买房，确认自己的数字身份，或者买卖二手车。所以智能合约的可靠性非常重要，条款是什么，就按照什么执行。

如果你想在区块链上创建什么东西，你需要通过智能合约描述自己想做什么东西（比如实物交易、打包数据等等）。你描述的语言越简单，创建的速度就越快，也能更快让项目方看到成果。更重要的是，你需要智能合约获取收益或者给你的企业带来好业绩。

Hyperledger Fabric 的智能合约（“链式码”）一般由几种编程语言写成，包括通用的 JavaScript 语言和 Go 语言，但是需要权衡编程语言的便利性和安全性。如果区块链涉及的利益很大，比如如果程序出现 bug 或者写错了，导致上百万美金丢失，那编程语言确实应该目的明确，设计的时候把安全放在首位。在理想的区块链环境中，智能合约语言应该好学也好用，但实际情况不可能如愿以偿。我们知道，要成功完成经典的程序演示“Hello world”，需要写 150 行左右的代码。代码量如此之大，自然容易产生可能造成上百万美元损失的 bug。

区块链领域资深的观察家正意识到，私有链和公链不会毫无关系，两者在未来会发生联系。私有网络想发行代币给公链用户，而公链的去中心化应用也想在私有链中储存机密信息。但不幸的是，IBM Fabric 用户仅仅因为架构无法兼容，就被“隔离”在公链之外。不仅如此，他们因此也错过了智能合约语言的学习机会，无法在公链和私有链之间实现无缝操作。

随着 IBM 宣布建立企业区块链的消息持续成为媒体关注的焦点，我们需要看清楚聚光灯之下，这项技术到底有何作为。Hyperledger Fabric 很多方面的标准性不足（包括安全性、效率和可靠性等等），因此，想借助区块链技术寻求发展的公司或机构无法得到有价值的解决方案。要想真正理解区块链的价值，资深用户会寻找更有优势的服务公司，因为他们能提供更好的区块链技术，对未来的发展和技术的应用方式也有更好的规划。

原文链接：

https://medium.com/@mikeycrypto752/why-ibms-blockchain-isn-t-a-real-blockchain-7dbe820751ee