背景
Fabric 和 Sawtooth 是 Hypherlegder 的两个重要企业级项目，在国家鼓励区块链无币化的当下，受到了广泛的关注。当我们希望改造传统项目，实现多方数据自动化对账、自动化运维等功能时，它们往往成为了最佳的选择。但它们各自有什么特点，又应该如何选择呢？本文将分别分析这两个项目的结构和特点，又对它们进行了比较和总结。
区块链本身和虚拟货币（Token）没有任何关系，比特币，Ethereum 等引入虚拟货币所起的作用是费用计量，并通过费用来控制用户对资源的使用权限。在传统互联网体系结构中，访问权限的实现方式并不是只有通过货币一种。所以，区块链的应用价值本质上还是取决于它能做什么，或者说它是否可以作为一种通用技术广泛服务于商业领域，并提供现有系统无法实现的功能。
当然，有人看到 Fabric 框架的问题以后，选择自己改动其中不合理的部分。假如A看到了问题，项目开发者也看到了，随后B在新版本中进行更改，而且改法与A不同，那样就会有版本更新的风险。所以最合理的方式还是尽量不改要动现有项目的核心部分，而是搞清楚之后，再进行合理的选择。从最后的比较结果看，笔者是强烈推荐 Sawtooth ，因为从通用性，灵活性角度看，几乎找不到 Sawtooth 的缺点。
本文将分为上下两部，本篇将讲述 Fabric 的相关内容，下一篇将为小伙伴们带来 Sawtooth 的相关内容敬请期待。
一、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，图中共有 R1、R2、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 是T1、T2、T3、T4、T6、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 是 CAR1、CAR2、CAR3 和 CAR4。B包含两个blocks：0 和 1。Block 1 包含4个 Transactions T1、T2、T3、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 的并行化更像是传统电脑中的进程级的并行，针对的改进对象是单用户没有并行功能的系统。