Fabric和Sawtooth技术分析（上）

https://mp.weixin.qq.com/s?__biz=MjM5MDAxMTE0MA==&mid=2652049866&idx=1&sn=5b4aea961f3d64c9b240e042b6b434ee&chksm=bdaceba18adb62b7b8d935f122b4f90159640fb5ef88e83e0ba31421812ce7c082584c6df604&scene=21#wechat_redirect

 

背景

Fabric 和 Sawtooth 是 Hypherlegder 的两个重要企业级项目，在国家鼓励区块链无币化的当下，受到了普遍的关注。当咱们但愿改造传统项目，实现多方数据自动化对帐、自动化运维等功能时，它们每每成为了最佳的选择。但它们各自有什么特色，又应该如何选择呢？本文将分别分析这两个项目的结构和特色，又对它们进行了比较和总结。

区块链自己和虚拟货币（Token）没有任何关系，比特币，Ethereum 等引入虚拟货币所起的做用是费用计量，并经过费用来控制用户对资源的使用权限。在传统互联网体系结构中，访问权限的实现方式并非只有经过货币一种。因此，区块链的应用价值本质上仍是取决于它能作什么，或者说它是否能够做为一种通用技术普遍服务于商业领域，并提供现有系统没法实现的功能。

固然，有人看到 Fabric 框架的问题之后，选择本身改动其中不合理的部分。假如A看到了问题，项目开发者也看到了，随后B在新版本中进行更改，并且改法与A不一样，那样就会有版本更新的风险。因此最合理的方式仍是尽可能不改要动现有项目的核心部分，而是搞清楚以后，再进行合理的选择。从最后的比较结果看，笔者是强烈推荐 Sawtooth ，由于从通用性，灵活性角度看，几乎找不到 Sawtooth 的缺点。

本文将分为上下两部，本篇将讲述 Fabric 的相关内容，下一篇将为小伙伴们带来 Sawtooth 的相关内容敬请期待。

1、Hypherlegder Fabric 的分析

Fabric 是 IBM 公司推出的企业级区块链，2017年 IBM 将其贡献给 Hypherlegder 项目。本文将主要从 Fabric 产生的缘由，Fabric 的特色，和 Fabric 的结构及工做流程作简要介绍。

Fabric 产生的缘由

Fabric 的诞生主要是由于在金融、销售、供应链等特殊应用领域中，一些机构的数据不能公开，并且并非全部的机构都有权力发起 Transaction。而在 Fabric 诞生以前，主流的区块链结构 Ethereum 的体系结构不能知足数据的隐私与访问控制需求。正是看到这一机会，IBM 在2017年推出了 Fabric。这以前其实有个插曲，2014年美国几十家银行成立了一个 R3 区块链联盟，目的就是知足金融领域中带有特殊访问控制和隐私保护需求的区块链技术，结果2017年，R3 以为当隐私保护和访问控制需求变为主流需求后，区块链并非必须的，因而把本身从“区块链新创公司”改为了“受区块链启发的新创公司”。

因此，在分析 Fabric 时也没必要把“区块链”这种新存储结构看得和传统结构有什么不一样，由于 Fabric 主要是要弥补在它出现前的技术的不足。从体系结构角度看，Fabric 其实并不新颖。

Fabric 的特色

Fabric 把区块链分为须要许可的和不须要许可的区块链（Permissioned vs Permissionless Blockchains）。众所周知参与 Ethereum 的用户是匿名的，也就是任何人均可以参与，因此 Ethereum 是不须要许可的区块链，向 Ethereum 网络中提交一个合法的（只要有以太币即合法） Transaction，全部节点都会独立执行合约（根据数据）获得输出并生成区块。对 Ethereum 这种不须要许可的区块链来讲，因为程序和数据在全部节点上执行，跟本没啥保密可言。这对不少应用是不行的，好比，作销售，供应的，哪里还有底价一说，你们知道的都同样。还有用户位置、等等隐私数据也不能全网暴露。

Fabric 针对不须要许可的（Permissionless）区块链存在的问题提出须要许可的（Permissioned）区块链，简单来讲，就是在全部节点中选择一部分，造成一个个的联盟，特定 Transaction 只在联盟内的节点独立运行，这样只有通过选择的特定节点参与执行 Transaction，数据只在这部分节点范围内公开，这样隐私和访问控制就有可能缓解了（与Ethereum相比，效率提升也是天然的，虽然不是 Fabric的主要目标）。

具体怎么解呢：配置文件。在不一样的配置文件里写好访问控制逻辑便可，谁能够作什么一目了然。这里 Fabric 假设，进到联盟中的就没有坏人了，不会有节点经过有问题智能合约捣乱。为此，Fabric 提供了一套 CA ，确保联盟内任何人的身份都是能够验证的，其行为，包括修改网络设置，部署智能合约等能够被记录在区块链上，而且有人为其背书。这就能够识别出捣乱的人。

Ethereum 等技术是遵循顺序执行的体系结构 （order-execute architecture） 的。须要先验证全部 Transaction 的执行顺序，而后把状态复制到全部节点上，而后每一个节点各自顺序执行。简单来讲就是在架构上就没考虑过 Transaction 的并行。Fabric 引入了一种称为（execute-order-validate）的架构。先执行 Transaction 而后再检查它的正确性，而后为其背书；经过可插拔的共识协议给 Transaction排序；在提交给帐本前，用应用程序描述的背书策略（application-specific endorsement policy）验证 Transaction。这里所谓“程序描述的背书策略”是指哪些节点，多少节点，须要保证给定智能合约执行的正确性。这种结构容许 Transaction 并行执行，提升了效率，由于非肯定性的（non-determinism）、不一致（inconsistent）的结果能够在排序（ordering）前被过滤掉，使得 Fabric 能够支持标准编程语言（standard programming languages），智能合约能够用 Go 或者 Node.js 来写，未来也支持 Java。

当咱们面对隐私保护需求的时候，可能有不一样的解决方法。Fabric 列出了下面几种：

1) Fabric 认为，一种是数据加密。但因为加密数据被部署到每一个节点上，只要给定足够的时间和计算资源，加密能够被破解。(这显然是Fabirc的设计者想固然，但 Fabric 把它做为 Permissioned 体系结构存在乎义的证据)。

2) Fabric 认为，另外一种是零知识证实，但零知识证实须要至关可观的时间和计算资源。

因此，为了解决数据的访问控制与隐私保护问题，Fabric提出了一种称为 channel 的体系结构，只有参加 channel 的 nodes 有权访问 smart contract（Fabric 称为 chaincode）和数据。(在我印象中，76年现代密码学的开山之做就是说怎么干这事，说是 Fabric 提出的，不太合适，但 Fabric 确实是用这种方法在网络中隔离出一个个的联盟)。

Fabric 的网络结构

下面是一个 Fabric 示例网络结构图。图中的字母：R表明 organizations，图中共有 R一、R二、R3 和 R4四个组织（organizations）。P表明 Peer node，P1 隶属于 R1。S 表明 Smart Contract，L 表明 Ledger，图中 L1，S5 物理部署于 P1 上。C 表明 channel。NC 是n etwork configuration。CC 是 channel configuration。CA 是 Certificate Authority。A 表明 Client application，这里是用户操做的界面。O 是 ordering service，或者叫 orderer。

放眼过去，是否是以为很杂乱？不要急，接下来 Fabric 会告诉咱们怎么一步步造成这样的复杂体系结构。先来看图中的 R4 以及它的网络配置文件 NC4，以及排序服务O4，和提供身份服务的 CA4。NC4 包含初始网络管理能力设置的策略。简单点说，就是 R4 有权配置网络。CA 的功能比较简单，基本上众所周知，就再也不赘述了。

接下来增长一个新的组织 R1 和为 R1 内用户提供身份服务的 CA1。此时，能够由 R4 修改配置文件 NC4，令 R1 具备和 R4 同样的管理权限。

在联盟的基础上，就能够建立 channel 了。C1 表示 channel ，根据CC1 建立。它是联盟内部成员之间的主要通讯机制。这里联盟内有 R1 和 R2，CC1 由它们控制，R4 不能参与。注意，C1 须要与 O4 相连。这样的目的是，只要能连上 O4，就能与 C1 链接的节点通讯。

接下来，Peer node P1 链接到 channel，它能够经过 C1 与 O4 通讯。注意，L1 物理部署在P1上，从数据存储角度，能够把 L1 看作待访问资源。逻辑上，L1 能够被全部可以链接到 C1 的节点访问。加入过程是经过 P1 发送一个链接 C1 的请求给 O4，而后 O4 根据 CC1 的策略设置决定 P1 能否链接 C1。

接下来，智能合约 S5 能够被安装到 P1 上，P1 能够看到 S5 的代码。R1 中的一个 Client Application A1 能够加入 C1，并经过 P1 执行 S5 来访问 L1。这时，因为 A1 是 R1 的成员，它能够选择链接O4 或者 R1，经过它们中的哪一个均可以链接上 P1。S5 由 R1 实现，并在 P1 上安装。并且 S5 还要在 C1 上安装，以便别的 Client Application 能够找到它。

咱们能够继续加入资源P2到C1上：

把上图中的C1简化掉，获得下图：

而后能够再增长一个联盟以下图：

而后再在新联盟内创建一个 channel 以下图：

在新 channel 上链接新的资源 P3 以下图：

此时，P2 既能够被 C1 内节点访问，也能够被 C2 内节点访问，能够把 P3 上的资源同步到 P2 上，以下图：

这样就获得了开始看到的网络结构图。

经过上述网络结构能够看到，Fabric 的访问控制机制大致上分为两层，一层是关于安全的，或者叫成员服务，也就是说画个圈，把成员划进来。另外一层是关于隐私的，意思是一个 Transaction 能够指定由全部成员中的一部分来执行，这样别人就看不到程序和数据了。

Fabric 的通讯流程

咱们先看看Client Application请求资源的流程，以下图：

首先，经过 orderers ，Peers 确保 Ledger 老是保持最新状态。以 A调用 S1 来查询或者更像 L1 为例，P1 收到合法调用请求后，调用 S1 生成一个应答。A 在收到应答。若是是查询请求就结束了。若是是更新请求，A 在它收到的全部应答基础上构造 Transaction 发给 O1 。O1 收集网络上的 Transactions，而且分发给全部 peers，包括P1 。peers 验证 Transaction，经过后更新 L1，而后生成一个事件。

接下来，咱们再看看通讯的具体流程：

endorsing peer 主要是给 client 背书的。它的功能是验证，而后再签名，有些 endorsing peer 可能不在线，有些可能不理 client。client 在收集到足够的(达到背书策略要求的)背书 endorsing peer 后，把 transaction 发给 orderer。orderer 再把 transaction 发给具体执行智能合约的 committing peers。这里 Fabric 说得不够细致，orderer 在这样的通讯流程中是很重要的，如何保证 orderer 在处理这些来自不一样节点的信息的时序性呢。Fabric 没说清楚，咱们只能假设它作到了。但这是隐患，在分布式系统中保持全局时序一致性并不容易。

咱们知道，更新 Transaction 和查询 Transaction 是不一样的，更新涉及到写入操做，须要全部相关节点达成共识后才能执行，一个 peer 是不能更新 Ledger 的。因此，为了实现共识，Fabric 更新涉及到3个阶段。

Phase 1: Proposal：Transaction proposals 被每一个返回背书 proposal 的 peer 独立执行。

A1生成 Transaction T1 带 proposal P，而后发给 channel C 上的 P1 和 P2 。P1 执行 S1 使用 T1 带 P，以 R1 带 E1 相应。P2 执行 S1 使用 T1 带 P，以 R2 带 E2 相应。A1 收到这两个响应。

Phase 2: Packaging：orderer 的第一个角色是给 proposed ledger updates 打包。

A1 发送由 E1 和 E2 背书的 Transaction T1 给O1。并行的 A2 发送由 E1 背书的 Transaction T2 给 O1。O1 把来自 A1 的 T1 和来自 A2 的 T2，以及其它可能得 Transactions 打包 到 Block B2 中。咱们能够看到 transaction order 是T一、T二、T三、T四、T六、T5。

Phase 3: Validation：orderer 的第二个角色是把 Block 分发给 peers。

O1 把 block B2 发给 peer P1 和 P2 。P1 处理 B2，添加一个新的 block 到 P1 的 L1 上。并行地，P2 也处理 B2 ，添加一个新的 block 到 P2 的 L1 上。一旦这一过程完成，L1 就在 P1 和 P2 上被一致更新了。而后它们分别通知本身链接的 applications ，Transaction就被处理了。

帐本示例：fabcar

fabcar 是一个 Fabric 的例子应用，执行它会建立以下 Ledger 。该例子建立一个 car 的集合，有不一样的颜色、制造商、牌子、全部者。

帐本 L 包括一个 world state W 和一个区块链 B 。W 包含4个状态，key 是 CAR一、CAR二、CAR3 和 CAR4。B包含两个blocks：0 和 1。Block 1 包含4个 Transactions T一、T二、T三、T4。

总结

看完 Fabric 结构流程等介绍，笔者的第一个感受是 Fabric 对标的是 Ethereum ，它全部的技术、结构等的设计都是为了解决 Ethereum 中的问题，能够看到它确实作到了。

因此，给人一种直观的感受是 Fabric 不像是一个通用企业级架构，而是一个企业级的解决方案。Fabric 定义的 Transactions 有两类，一种叫 Deploy transactions，是用来部署 chaincode 的。另外一种叫 Invoke transactions，是用来执行已经部署的 chaincode 的。从这里的 Deploy transactions 设计能够看出，Fabric 已经有把 Transaction 自己做为 on-chain 的设计思想了，但整体上却又大量依赖配置文件，并未充分利用区块链自己实现对区块链的配置。

所以让人感受虽然 Fabric 能够实现预设的功能，但若是想稍做改动（实际状况中的常态），配置文件的管理可能隐藏不少潜在问题。Fabric 中的 Ordering service 是一个关键。它为 clients 和 peers 提供了共享的通讯 channel，为包含 Transaction 的消息提供广播服务。Client 链接 channel ，能够广播消息到全部 peers 。换句话说，channel以相同的逻辑顺序将一样的消息发送给全部与其相连的 peers 。

简单来讲它的功能就是按照当前配置文件中设定的网络结构，或者说控制结构规则将收到的消息或者交易转发给相应的节点。order 很是像如今网络中的路由器，或者说入口网关。Fabric 的并行化更像是传统电脑中的进程级的并行，针对的改进对象是单用户没有并行功能的系统。