选型fabric作为联盟链时需要考虑的几个问题

Posted on 2020-01-17 Edited on 2020-11-02

参考链接==>https://thenextweb.com/podium/2019/05/05/ibms-hyperledger-isnt-a-real-blockchain-heres-why/

选型 Hyperledger Fabric 作为联盟链需要考虑的几个细节问题

1.区块链的智能合约语言如何安全、简单地表达出复杂的业务逻辑？
2.那些目光长远的企业还会考虑到被选择的区块链将来能否可以轻松地与其他公有区块链或私有区块链进行互操作？

3.如何保证公钥签名的有效性？

4.扩展性，升级性如何？

Hyperledger Fabric是如何工作的

区块链的核心是一个去中心化的不可篡改的账本，账本中存储着事件或者交易，而往账本中加入哪些数据完全由共识机制来决定。在比特币和以太坊这样的公有区块链中，这种共识是通过工作量证明或称“挖矿”来实现的。在许可区块链中，参与者提供密码学签名来对共识的内容进行投票，从而达成共识。无论是哪种方式，都不会有中央机构进行干预。

在 Hyperledger Fabric 所提供 API 的帮助下，一笔交易要经过如下步骤：

1）一笔交易预提案被提交后；2）由背书节点（ endorsing peer ）通过智能合约语言 chaincode 执行它的逻辑，同时它会查询状态数据库并生成要使用到的读写集（ RWset ）；3）之后它还会连同生成的读写集返回交易预提案的回应；4）接下来，系统会将带有读写集的交易预提案提交；5）Ordering服务会把一批次的交易加入到区块中；6/7）所有的节点都会收到订购服务发来的区块信息，但它们需要验证区块中的交易信息来保证区块链中数据的安全性。

结论一：共识过程无容恶、容错能力

在上述的第4步是有Application（SDK）端发出的。而Application相比区块链节点更加不容易被信赖。例如，Application可在一个交易背书成功的情况下，不将交易完成第4步，即不提交给到Orderer；Application也可在一个交易背书成功的情况下，适时（延迟）再行提交给到Orderer；Application也可在一个交易背书成功的情况下，再行将后续背书成功的交易先行提交，前序交易在其后再行提交。凡此等等，都使其无法防止恶意交易、错误交易。

结论二：Channel 设计带来的复杂性远远高于可用性，Private data 设计无容恶和容错能力

Hyperledger Fabric 使用 channel（通道）来保证参与者之间的隐私性。这种隐私性是私有“企业”区块链的一个重要特性，但它必然会带来一些折衷，也会大大增加区块链的复杂性。但从企业区块链需要的可拓展性方面来说，多链解决方案并不是一个好的选择，因为这样做会使得部署过程太过于复杂、节点分布不均匀、智能合约不可靠、还会大大增加潜在的故障点。且，合约无法跨 channel 执行，channel 内的数据形成了新的数据孤岛。

在 2.0 版本中，Private data相关交易在事先配置好的参与方内使用，交易通过达到签名门限数量决定该交易是否通过。门限数设置较高，则无法具备容错能力；门限数设置较低，则无法证实其容恶能力。

结论三：随着网络的扩展，交易延迟加重，网络性能堪忧

从根本上来说 Hyperledger Fabric 的架构根本无法在保持最佳性能的同时进行扩展。在 2.0 版本中，Orderer 集群从 Kafka&Zookeeper 切换至 raft，将改善 Orderer 集群的多中心部署，但交易延迟没有改善。Hyperledger Fabric 区块链在部署之后的性能指标并不尽如人意，随着节点的增加性能还会迅速下降，而且它所宣称的性能是单通道时的性能：如果你想跨过多个通道与整个区块链网络进行交互，这些所谓的性能指标没有任何意义。

对于每个独立的通道，区块链的每秒处理交易量很难突破800这个大关，但即使是拥有16个通道配置的区块链也几乎不能达到1500TPS，若区块链一直维持吞吐量上限运行，其延迟时间可能会达到10到20秒。

最近一些旨在加快 Hyperledger Fabric 运行速度的研究使得其每秒处理交易量能达到惊人的20000，但性能大幅度提升的背后是研究人员对 Hyperledger Fabric 架构的大规模“魔改”，这使得 Hyperledger Fabric 已经成一个近似的区块链变成了一个四不像：背书节点（Endorsers）不再充当验证者而 Kafka 被认定为唯一可行的订购服务。最后，这些仍然只是单通道的性能，这意味着它与区块链作为共享可信来源的整个理念相违背。

结论四：Chaincode与其执行环境的安全性低

Hyperledger Fabric 的智能合约（称为链码“Chaincode”）可以用多种编程语言编写，其中包括常见的 Javascript 语言以及 Go 语言。但使用开发人员十分了解的通用编程语言开发是一把双刃剑，它在大大简化开发过程的同时，在安全性方面与专为区块链开发的编程语言相比大大弱化。

在这时如果代码有缺陷或不正确（因为它不是专为区块链设计的）那么可能会造成数百万美元的损失。因此我们认为智能合约语言必须专为区块链设计且为安全性做出了优化。Chaincode 在这几个方面可谓是彻彻底底地失败了，我们发现被誉为开发人员的第一个程序 “Hello World” 在其他语言中仅需几行就可以实现，而在 Chaincode 中居然需要150行之多。代码越多，可能存在的漏洞就越多。这么大数量的代码中可能隐藏着很多能造成数百万美元损失的漏洞。甚至在 Chaincode 的执行环境中可以发送 http request，将合约运行中的运行变量值发送给到任意客户端。

实际上，Hyperledger Fabric 以及 R3 Corda 都因为架构的完全不兼容而与公有区块链切割开来，这里面也有智能合约的责任，因为它们的智能合约语言无法在公有区块链和私有区块链中无缝切换。联盟链更加希望自己的资产可以对公有区块链上的客户使用，部署在公有区块链上的去中心化应用程序也会希望将隐私数据存储在联盟区块链中。

与 IBM 的 Hyperledger 不同，Quorum 的区块链要简单得多，但在为保密交易构建架构时，它仍然面临着复杂性问题。现在，Quorum 的几个关键开发人员已经离开团队，去开发新的区块链项目，使用 Quorum 的客户是否会获得强大的支持，这仍有待观察。

也许让 Quorum 面临最大风险的是，这项技术是由一家大银行管理，而不是一家专门的技术公司。对摩根大通来说，Quorum 永远是一种产品，而不是其核心业务。