Linux搭建Hyperledger Fabric区块链框架 - Hyperledger Fabric模型概念

企业选型的区块链底层技术

Hyperledger Fabric 概念

2015年，Linux基金会启动了Hyperledger项目，目标是发展跨行业的区块链技术。
Hyperledger Fabric是Hyperledger中的一个区块链项目，包含一个账本，使用智能合约并且是一个通过所有参与者管理交易的系统。
Hyperledger Fabric 是分布式账本解决方案的平台，以模块化架构为基础，支持不同组件的可插拔。

区块链

共享的、通过智能合约更新的多副本交易系统，并通过协作共识机制保持账本副本一致同步。

当前记录系统	区块链
无法统一管理参与者身份，确认源头费力	各参与者都有账本副本
明确交易耗时长	共享账本、共享更新账本流程
手工签订合约	减少与私人信息及处理的时间、成本和风险
数据独立，易单点故障	可见性高，信任度高

一个分布式账本（A Distributed Ledger）

区块链网络的核心是一个分布式账本，它记录了网络上发生的所有交易。

• 去中心化
• 网络中每个参与者都保存账本的副本
• 网络中每个参与者共同维护账本(协作)
• 信息只能以“附加”的方式记录在区块链中
• 使用加密技术保障交易一旦被添加进账本中，无法被篡改
  

智能合约（Smart Contracts）

为了持续的进行信息的更新，以及对账本进行管理（写入交易，进行查询等），区块链网络引入了智能合约来实现对账本的访问和控制。

智能合约不仅仅可用于在区块链网络中打包信息，它们也可以被用于自动的执行由参与者定义的特定交易操作。

共识

保持网络中所有账本交易的同步流程，就是共识。确保账本仅在交易被适当的参与者批准时更新，并且当账本更新时，它们以相同的顺序更新相同的交易。

Hyperledger Fabric 模型

• 资产（Assets） ：资产是可以通过网络交换的几乎所有具有价值的东西，从食品到古董车、货币期货。
• 链码（Chaincode）：链码执行与交易排序分离，限制了跨节点类型所需的信任和验证级别，并优化了网络可扩展性和性能。
• 账本特性（Ledger Features）：不可变的共享账本为每个通道编码整个交易历史记录，并包括类似 SQL 的查询功能，以便高效审计和解决争议。
• 隐私（Privacy） ：通道和私有数据集合实现了隐私且机密的多边交易，这些交易通常是在共同网络上交换资产的竞争企业和受监管行业所要求的。
• 安全和成员服务（Security & Membership Services ）：许可成员资格提供可信的区块链网络，参与者知道所有交易都可以由授权的监管机构和审计员检测和跟踪。
• 共识（Consensus）： 达成共识的独特方法可实现企业所需的灵活性和可扩展性。

资产

资产的范围可以从有形（房地产和硬件）到无形资产（合同和知识产权）。Hyperledger Fabric 提供使用链码交易来修改资产的功能。

资产在 Hyperledger Fabric 中表示为键值对的集合，状态更改记录为 Channel 账本上的交易。资产可以用二进制或 JSON 格式表示。

链码

链码是定义单项或多项资产的软件和能修改资产的交易指令；换句话说，它是业务逻辑。链码强制执行读取或更改键值对或其他状态数据库信息的规则。链码函数针对账本的当前状态数据库执行，并通过交易提案启动。链码执行会产生一组用于写入的键值对（写集），可以被提交到网络并应用于所有节点的账本。

账本特性

账本是 Fabirc 中所有状态转换的有序的防篡改的记录。状态转换是参与方提交的链码调用（“交易”）的结果。每个交易都会生成一组资产键值对，这些键值对以创建、更新或删除形式提交到账本。

账本由区块链（“链”）组成，用于以区块的形式存储不可变的顺序记录，以及用于维护当前 Fabirc 状态的状态数据库。每个通道有一个账本。每个节点为其所属的每个通道维护一个账本的副本。

Fabric 账本的一些特点：

• 使用基于键的查找、范围查询和组合键查询来查询和更新账本
• 使用富查询语言进行只读查询（如果使用 CouchDB 作为状态数据库）
• 只读历史记录查询（查询一个键的账本历史记录）用于支持数据溯源场景
• 交易包括链码读取键/值（读集）的版本以及链码写入键/值（写集）的版本
• 交易包含每个背书节点的签名，并被提交给排序服务
• 交易按顺序打包到区块，并被排序服务“分发”到通道上的节点
• 节点根据背书策略验证交易并执行策略
• 在附加一个区块之前，会执行一次版本检查，以确保被读取的资产的状态自链码执行以来未发生更改
• 一旦交易被验证并提交，就具有不变性
• 一个通道的账本包含一个配置区块，用于定义策略、访问控制列表和其他相关信息
• 通道包含 Membership Service Provider 的实例，允许从不同的证书颁发机构（CA）生成加密材料

隐私

Hyperledger Fabric 在每个通道上使用不可变的账本，以及可操纵和修改资产当前状态（即更新键值对）的链码。账本存在于通道范围内，它可以在整个网络中共享（假设每个参与者都在同一个公共通道上），也可以被私有化，仅包括一组特定的参与者。

在后一种情况下，这些参与者将创建一个单独的通道，从而隔离他们的交易和账本。为了想在完全透明和隐私之间获得平衡的场景，可以仅在需要访问资产状态以执行读取和写入的节点上安装链码（换句话说，如果未在节点上安装链码，它将无法与账本正确连接）。

当该通道上的组织子集需要对其交易数据保密时，私有数据集合用于将此数据隔离在私有数据库中，在逻辑上与通道账本分开，只有经授权的组织子集才能访问。

因此，通道在更广泛的网络上保持交易的私密性，而集合则在通道上的组织子集之间保持数据的私密性。

为了进一步模糊数据，在将交易发送到排序服务并将区块附加到账本之前，可以使用诸如 AES 之类的通用加密算法对链码内的值进行加密（部分或全部）。一旦加密数据被写入账本，它就只能由拥有用于生成密文的相应密钥的用户解密。

安全和成员服务

Hyperledger Fabric 支持一个交易网络，在这个网络中，所有参与者都拥有已知的身份。公钥基础设施用于生成与组织、网络组件以及终端用户或客户端应用程序相关联的加密证书。因此，可以在更广泛的网络和通道级别上操纵和管理数据访问控制。Hyperledger Fabric 的这种“许可”概念，加上通道的存在和功能，有助于解决隐私和机密性要求较高的场景。

共识

最近，在分布式账本技术中，共识已成为单个函数内特定算法的同义词。然而，共识不仅包括简单地就交易顺序达成一致，Hyperledger Fabric 通过其在整个交易流程中的基本角色，从提案和背书到排序、验证和提交，突出了这种区别。简而言之，共识被定义为组成区块的一组交易的正确性的闭环验证。

当区块中交易的顺序和结果满足明确的策略标准检查时，最终会达成共识。这些制衡措施是在交易的生命周期内进行的，包括使用背书策略来规定哪些特定成员必须背书某个交易类别，以及使用系统链码来确保这些策略得到执行和维护。在提交之前，节点将使用这些系统链码来确保存在足够的背书，并且它们来自适当的实体。此外，在将包含交易的任何区块附加到账本之前，将进行版本检查，以确保在此期间，账本的当前状态是能与交易中的信息达成共识的。该最终检查可防止双重花费操作和可能危及数据完整性的其他威胁，并允许针对非静态变量执行功能。

除了众多的背书、验证和版本检查外，交易流的各个方向上还会发生持续的身份验证。访问控制列表是在网络的分层上实现的(排序服务到通道)，并且当一个交易提议通过不同的架构组件时，有效负载会被反复签名、验证和认证。总而言之，共识并不仅仅局限于一批交易的商定顺序；相反，它的首要特征是交易从提案到提交的过程中不断进行核查而附带实现的。

身份 Identity

区块链网络中的不同参与者包括对等点（peers）、订购者（orderers）、客户端应用程序（client applications ）、管理员（administrators）等。这些参与者中的每一个（网络内部或外部能够使用服务的活动元素）都有一个封装在 X.509 数字证书中的数字身份。

作用：确定了对资源的确切权限以及参与者在区块链网络中拥有的信息的访问权限

主体（principal）

身份和相关属性的联合提供了一个特殊的名称。 像userID 或 groupID，但更灵活一些，因为它们可以包含参与者身份的广泛属性，例如参与者的组织、组织单位、角色甚至参与者的特定身份。

成员服务提供者( MSP)

要使身份可验证，它必须来自受信任的权威机构。Fabric中使用成员服务提供者( MSP) 组件实现，它定义了管理该组织的有效身份的规则。
默认 MSP 实现使用 X.509 证书作为身份，采用传统的公钥基础设施 (PKI) 分层模型。

身份使用的场景

去超市结账假设只能用A信用卡、B信用卡（A、B为举例使用），那对于其他卡无论是否真实及其他卡是否有余额都无效。即便有了有效的信用卡还需要商店认可才能使用。

PKI 和 MSP 以相同的方式协同工作：PKI 提供身份列表，而 MSP 说明其中哪些是参与网络的给定组织的成员。PKI 类似卡片提供商：它分发许多不同类型的可验证身份（如发行A卡、B卡、C卡）。MSP 就像商店接受的卡提供商列表，确定哪些身份是商店支付网络的受信任成员（参与者）。MSP 将可验证的身份转变为区块链网络的成员（如商店仅支持A卡、B卡）。

PKI 公钥基础设施

公钥基础结构（PKI）是一组互联网技术，可在网络中提供安全通信。 如果在 Web 浏览器上打开的是https的链接，可能正在使用 PKI 来确保它来自经过验证的来源。

公钥基础设施 (PKI) 的元素。PKI 由向各方（例如，服务的用户、服务提供商）发布数字证书的证书授权中心组成，然后使用它们在与其环境交换的消息中对自己进行身份验证。CA 的证书撤销列表（CRL）构成不再有效的证书的参考。证书的撤销可能由于多种原因而发生。例如，因为与证书相关联的加密私有材料已被公开，所以证书可能被撤销。

区块链网络不仅仅是一个通信网络，它依赖于 PKI 标准来确保各种网络参与者之间的安全通信，并确保发布在区块链上的消息得到正确的身份验证。

PKI 四个关键要素

• 数字证书 (Digital Certificates)
• 公钥和私钥 (Public and Private Keys)
• 证书颁发机构 (Certificate Authorities)
• 证书吊销列表 (Certificate Revocation Lists)

数字证书(Digital Certificates)

数字证书是包含与证书持有者相关的属性的文档。最常见的证书类型是符合 X.509标准的证书，它允许在其结构中编码一些用于身份识别的信息。

Mary Morris 有一个带有 SUBJECT 属性为 C=US, ST=Michigan, L=Detroit, O=Mitchell Cars, OU=Manufacturing, CN=Mary Morris /UID=123456 的数字证书。

突出显示的 SUBJECT 文本显示了关于 Mary 的重要事实。如你所见，证书还包含更多信息。最重要的是，Mary 的公钥是在她的证书中分发的，而她的私人签名密钥则不是。此签名密钥必须保密。

• Mary 是证书的 SUBJECT，突出显示的SUBJECT文本显示了关于 Mary 的关键事实。
• Mary的公钥是在证书中分发的，私钥没显示，私钥必须保密。
• Mary的所有属性都可以使用称为密码学的数学技术记录下来，这样篡改就会使证书失效。只要对方信任证书颁发者，即证书授权中心（CA），密码学就允许 Mary 将证书提交给其他人以证明其身份。只要 CA 安全地保存某些加密信息（CA 的私钥），任何阅读证书的人都可以确定有关 Mary 的信息没有被篡改，它将始终具有 Mary Morris 的特定属性。将 Mary 的 X.509 证书视为无法改变的数字身份证。

身份验证、公钥和私钥 （Authentication, Public keys, and Private Keys）

身份验证和消息完整性是安全通信中的重要概念。

• 身份验证要求交换消息的各方确信创建特定消息的身份。
• 消息具有“完整性”意味着在其传输过程中不能被修改。

从技术上讲，数字签名机制要求每一方持有两个加密连接的密钥：

• 一个广泛可用并充当身份验证锚的公钥，
• 一个用于在消息上生成数字签名的私钥 。

数字签名消息的接收者可以通过检查附加签名在预期发送者的公钥下是否有效，来验证接收消息的来源和完整性。

私钥和公钥的唯一关系是保证安全通信的加密魔法。 密钥之间唯一的数学关系使得私钥可用于在消息上生成签名，只有相应的公钥才能匹配，并且只能在同一消息上。

Mary 使用她的私钥对消息进行签名。任何看到签名消息的人都可以使用她的公钥来验证签名。

证书颁发机构（Certificate Authorities）

人员或节点能够通过由系统信任的机构为其发布的数字身份参与区块链网络。数字身份（或简称身份）的形式为，符合 X.509 标准并由证书授权中心（CA）颁发的经加密验证的数字证书。 常见安全协议：Symantec、GeoTrust、DigiCert、GoDaddy 和 Comodo 等。

证书授权中心向不同的参与者颁发证书。这些证书由 CA 进行签名，并将参与者的公钥绑定在一起（可选是否具有全部属性列表）。因此，如果一个成员信任 CA（并且知道其公钥），则可以信任与参与者绑定的证书中包含的公钥，并通过验证参与者证书上的 CA 签名来获取所包含的属性。

证书可以广泛传播，因为它们既不包括参与者也不包括 CA 的私钥。因此，它们可以用作信任的锚，用于验证来自不同参与者的消息。CA 也有一个证书，它们可以广泛使用。这就可以让从给定 CA 获取身份证书的消费者验证自己的身份，因为只有对应的私钥才可以生成该证书。

在区块链设置中，希望与网络交互的每个参与者都需要一个身份。在此设置中，使用一个或多个 CA 从数字角度定义组织的成员 。CA 是为组织的参与者提供可验证的数字身份的基础。

根 CA、中间 CA 和信任链 (Root CAs, Intermediate CAs and Chains of Trust)

CA 有两种形式：根CA和中间CA。

因为根 CA（Symantec，Geotrust等）必须安全地向互联网用户颁发数亿个证书，所以将这个过程分散到中间 CA 中是很有用的。中间 CA 具有由根 CA 或其他中间 CA 颁发的证书，允许为链中的任何 CA 颁发的任何证书建立“信任链”。追溯到根 CA 的能力不仅让 CA 的功能在仍然提供安全性的同时进行扩展（允许使用证书的组织充满信心地使用中间 CA），还限制了根 CA 的暴露，如果根 CA 受到损害，将会危及整个信任链。另一方面，如果中间 CA 受到损害，则曝光量会小得多。

只要每个中间 CA 的证书的颁发 CA 是根 CA 本身或具有对根 CA 的信任链，就在根 CA 和一组中间 CA 之间建立信任链。

Fabric CA

Fabric 提供了一个内置的 CA 组件，允许在区块链网络中创建 CA。此组件称为 Fabric CA ，是一个私有根 CA 提供者，能够管理具有 X.509 证书形式的 Fabric 参与者的数字身份。

由于 Fabric CA 是针对 Fabric 的根 CA 需求的自定义 CA，因此它本身无法为浏览器中的常规或自动使用提供 SSL 证书。但是，由于一些 CA 必须用于管理身份，因此可以使用 Fabric CA 来提供和管理证书。

证书吊销列表（Certificate Revocation Lists）

证书撤销列表（Certificate Revocation List，CRL）是 CA 知道由于某些原因而被撤销的证书的引用列表。在上述商店场景，CRL 就像被盗信用卡列表一样。

当第三方想要验证另一方的身份时，首先检查颁发 CA 的 CRL 以确保证书尚未被撤销。验证者不是必须要检查 CRL，但如果不检查，则要冒着接受无效身份的风险。

使用 CRL 检查证书是否仍然有效。如果冒名顶替者试图将受损的数字证书传递给验证方，则可以首先根据颁发 CA 的 CRL 检查它，以确保它没有被列为不再有效。

被撤销的证书与证书过期不同。撤销的证书尚未过期，它们是完全有效的证书。

成员服务提供者 (MSP)

证书机构通过生成可以用来证实身份的由公钥和私钥形成的键值对来发放认证信息。因为一个私钥永远不会被公开，所以引入了一种可以证实身份的机制即MSP。

一个peer节点用它的私钥进行数字签名或背书交易。接着排序节点包含的该peer节点的公钥会被用来验证交易携带的签名是否合法。私钥被用作生成交易信息上的，只有与私钥相对应的且作为MSP一部分的公钥可以匹配的签名。因此，MSP是一个可让身份被信任和被网络中其他参与者公认的，而不需要暴露成员的私钥的机制。

MSP是一种机制，使用户能够加入一个需要许可的区块链网络。要在Fabric网络上进行交易，成员需要这样做：

• 拥有一个由网络信任的CA颁发的身份。
• 成为一个被网络成员认可和认可的 组织 的成员。MSP将身份与组织的成员资格联系在一起。成员资格是通过将成员的公钥(也称为证书、签名证书或签证)添加到组织的MSP来实现的。
• 将MSP添加到网络上的一个联盟或者通道。
• 确保MSP包括在网络中的策略定义。

MSP包含一个被允许的身份的列表。通过列出其成员的身份，或通过确定哪些是为其成员授权颁发有效身份的ca，来识别和确定接受来自这些根ca和中间ca所定义的信任域的成员。

MSP通过标识参与者在节点或通道上拥有的特定特权，将身份转换为角色。当用户使用Fabric CA注册时，该用户必须关联到管理员、peer节点、客户端、排序节点或成员其中之一的角色。例如，注册为“peer”角色的身份应该自然而然地给到peer节点。同样，注册为“admin”角色的身份也应该被授予给组织管理员。

MSP 域

在区块链网络中，MSP 出现在两个位置：

• 在参与者节点本地 （本地 MSP）
• 在通道配置中 （通道 MSP）

本地MSP

本地MSP是为客户端和节点（peer节点和排序节点）定义的。 本地MSPs定义节点的权限（谁是可以操作节点的peer节点管理员）。客户端的本地MSP，允许用户作为一个通道成员或作为一个特定角色的所有者如组织管理者，在其交易（如链码交易）进行身份验证从而进入系统。

每个节点都必须定义一个本地MSP，因为它定义了在该级别上谁拥有管理权或参与权（peer节点管理员不一定是通道管理员，反之亦然）。这允许在通道上下文之外对成员消息进行身份验证，并定义特定节点（能够在peer节点上安装链码的节点）的权限。请注意，一个组织可以拥有一个或多个节点。MSP定义了组织管理员。组织、组织的管理员、节点的管理员以及节点本身都应该具有相同的信任根。

排序节点的本地MSP也在节点的文件系统上定义，并且只应用于该节点。与peer节点一样，排序节点也由单个组织拥有，因此有一个MSP来列出它信任的参与者角色或节点。

通道MSP

通道MSP在通道层面上定义了管理权和参与权。 应用程序通道上的peer节点和排序节点共用通道MSP的相同视图，因此能够正确地对通道参与者进行身份验证。

如果组织希望加入通道，则需要在通道配置中添加包含组织成员信任链的MSP。否则，来自该组织身份的交易将被拒绝。

本地MSP表现为文件系统上的文件夹结构，而通道MSP则在通道配置中被描述。

从通道配置config.json文件中截取片段，其中包括两个组织MSP

通道MSP识别谁在通道层次拥有权限。 通道MSP定义通道成员(本身是MSP)的身份和通道级策略的执行之间的关系 。通道MSP包含通道成员组织的MSP。

每个参与通道的组织都必须为其定义一个MSP。 建议在组织和MSP之间建立一对一的映射。MSP定义了哪些成员被授权代表组织行事。这包括MSP本身的配置以及批准组织进行具有管理角色权限的任务，例如向通道添加新成员。如果所有网络成员都是单个组织或MSP的一部分，那将没有数据隐私。多个组织通过将账本数据仅隔离给通道成员来促成隐私保护。如果组织内部需要更细的隔离粒度，则可以将组织进一步划分为组织单元(ou)。

系统通道MSP包括参与排序服务的所有组织的MSP。 排序服务可能包括来自多个组织的排序节点，这些组织共同运行排序服务，最重要的是管理组织联盟和应用程序通道所继承的默认策略。

本地MSP仅在其应用的节点或用户的文件系统上定义。 因此，在物理上和逻辑上，每个节点只有一个本地MSP。由于通道MSP对通道内的所有节点都可用，它们在通道配置中逻辑上仅定义一次。通道MSP也在通道中的每个节点的文件系统上实例化，并通过共识保持同步。 因此，尽管每个节点的本地文件系统上都有每个通道MSP的副本，但从逻辑上讲，通道MSP存在并被维护于通道或网络上。

本地MSP和通道MSP在网络中是如何共存的：

peer节点和排序节点的MSP是本地化的，而一个通道(包括网络配置通道，也称为系统通道)的MSP是全局化的，被该通道的所有参与者共用。在该图中，网络系统通道由ORG1管理，而另一个应用程序通道可以由ORG1和ORG2管理。peer节点是ORG2的成员并由ORG2管理，而ORG1则管理图中的排序节点。ORG1信任来自RCA1颁布的身份，而ORG2信任来自RCA2颁布的身份。这些是管理身份标识，反映了谁可以管理这些组件。

组织在MSP中的角色

组织是一个逻辑上成员们的管理组。组织(或orgs)在单个MSP下管理其成员，MSP允许将标识链接到组织。

以组织的名字为前缀命名MSP，大多数策略配置都会采用这种约定。例如，组织ORG1可能有一个类似于ORG1-MSP的MSP。在某些情况下，一个组织可能需要多个成员组——例如，在组织之间使用通道执行完全不同的业务功能。在这些情况下，有多个msp并据此约定命名它们是有意义的，例如，ORG2-MSP-NATIONAL和ORG2-MSP-GOVERNMENT，反映了GOVERNMENT控制的通道与NATIONAL交易通道在ORG2中不同的成员资格信任根。

组织单元(ou)和MSP

一个组织也可以被划分为多个组织单元，每个单元都有一定的职责，也称为affiliations。 可以将组织单元看作组织内部的一个部门。例如，ORG1组织可能同时拥有ORG1.MANUFACTURING和ORG1.DISTRIBUTION组织单元，这反映了相隔离的业务流水线。当CA颁发X.509证书时，证书中的OU字段指定该身份所属的业务流水线。这样使用组织单元的一个好处是，这些值可以用于定义策略，以限制访问，或者用于基于属性的访问控制的智能合约。否则，就需要为每个组织创建单独的MSP。

如果不使用ou, MSP中的所有身份(由根CA和中间CA文件夹认定的)都将被视为组织的成员。

节点组织单元和MSP

节点组织单元，可用于授予角色以身份标识。 这些节点组织单元角色定义在$FABRIC_CFG_PATH/msp/config.yaml配置文件中，并包含一个组织单元列表，这些单元成员被认为是MSP所代表的组织的一部分。

将组织成员限制为只具有特定节点组织单元角色的身份标识时(由MSP指定的其中一个CA进行签名)，可以通过节点组织单元实现更细粒度的背书策略，该策略要求Org1的peer节点(而不是Org1的任何成员)为交易背书。

为了使用节点组织单元角色，必须为网络启用“身份分类”特性。使用文件夹形式的MSP时，这可以通过在MSP目录下的配置文件config.yaml中启用“Node OUs”字段来实现：

NodeOUs:
  Enable: true
  ClientOUIdentifier:
    Certificate: cacerts/ca.sampleorg-cert.pem
    OrganizationalUnitIdentifier: client
  PeerOUIdentifier:
    Certificate: cacerts/ca.sampleorg-cert.pem
    OrganizationalUnitIdentifier: peer
  AdminOUIdentifier:
    Certificate: cacerts/ca.sampleorg-cert.pem
    OrganizationalUnitIdentifier: admin
  OrdererOUIdentifier:
    Certificate: cacerts/ca.sampleorg-cert.pem
    OrganizationalUnitIdentifier: orderer

MSP有4种节点组织单元角色：

• client
• peer
• admin
• orderer

这个约定允许根据X509证书的CommonName属性中显示的OU来区分MSP角色。 上面的示例说明由cacerts/ca.sampleorg-cert.pem颁发的任何证书，字段OU=client的将被认定为客户端，字段OU=peer的将被认定为peer，以此类推。从Fabric的1.4.3版本开始，还有一个用于排序节点和管理员的OU。新的admins角色意味着您不再需要显式地将证书放置在MSP目录下的admincerts文件夹中。相反，用户的signcert文件夹结构中呈现的admin角色使其具有管理员用户的身份标识。

当使用Fabric CA或SDK注册带有CA的用户时，这些角色和OU属性会被分配给一个身份标识。随后enroll用户命令会在用户的/msp文件夹中生成证书。

生成的角色和OU属性在位于/signcerts文件夹中的X.509签名证书中可见。ROLE属性被标识为hf.Type，其指的是参与者在其组织中的角色（例如，指定参与者是一个peer节点）。

以下来自签名证书的代码片段，它显示了角色和ou在证书中是如何表示的。

对于通道MSP，给定的身份标识在管理系统方面的实际权力由管理系统资源的策略决定。例如，通道策略可能指定ORG1-MANUFACTURING管理员，即具有admin角色和ORG1-MANUFACTURING节点组织单元的身份，使其有权向通道添加新组织，而ORG1-DISTRIBUTION管理员则没有这样的权限。

联盟中的不同组织可以使用组织单元来区分彼此。但在这种情况下，不同的组织必须为其信任链使用相同的根CA和中间CA，并分配OU字段来标识每个组织的成员们。当每个组织都拥有相同的CA或信任链时，这使得系统比预期中的更加中心化。

MSP结构

本地MSP文件夹包含以下子文件夹:

• config.yaml: 通过启用“Node OUs”和定义可接受的角色来配置Fabric中的身份分类特性。

• cacerts: 此文件夹包含此MSP代表的组织所信任的根CA的自签名X.509证书列表。此MSP文件夹中必须至少有一个根CA证书。
  最重要的文件夹，因为它确定了派生所有其他证书的必要CA，拥有这些证书才能被视为对应组织的成员，从而形成信任链。

• intermediatecerts: 此文件夹包含该组织所信任的中间CA的X.509证书列表。每个证书必须由MSP中的一个根CA，或者其本身颁发的CA链最终会指向一个受信任的根CA的任何中间CA，进行签名。
  一个中间CA可能代表组织的不同细分（如ORG1-MANUFACTURING和ORG1-DISTRIBUTION对应于ORG1），或者组织本身（商业CA被用于组织的身份管理）。在后一种情况下，中间CA可以用来表示组织的细分。**一个正常工作的网络可能没有中间CA，在这种情况下，这个文件夹将是空的。**与根CA文件夹一样，该文件夹也定义了CA，且证书必须从该CA颁发，才能被视为组织的成员。

• admincerts (在Fabric的1.4.3及以上版本被弃用): 此文件夹包含一个身份列表，这些身份定义了具有此组织管理员角色的参与者。通常，这个列表中应该有一个或多个X.509证书。

• keystore: (私钥) 这个文件夹是为peer节点或排序节点的本地MSP(或客户端的本地MSP)定义的，其包含节点的私钥。此私钥用于签名数据——例如，作为背书阶段的一部分，用其签名交易提案响应。
  **此文件夹对于本地MSP是强制性的，并且必须准确地包含一个私钥。显然，对该文件夹的访问必须仅限于对peer节点负有管理责任的用户。**通道MSP配置不包含此文件夹，因为通道MSP仅提供身份验证功能，而不提供签名功能。

• signcert: 对于 Peer 节点或排序节点(或在客户端的本地 MSP 中)，此文件夹包含 CA 发行的节点签名密钥。该证书表明节点的身份，与这个证书相对应的私钥可以用于生成签名，并且该签名可以被任何拥有这个证书的人验证。
  **此文件夹对于本地 MSP是强制性的，并且必须包含一个准确的公钥。对该文件夹的访问必须仅限于对 Peer 节点负有管理责任的用户。**通道 MSP的配置不包含此文件夹，因为通道MSP仅提供身份验证功能，而不提供签名功能。

• tlscacerts: 此文件夹包含受此组织信任的根CA的自签名X.509证书列表，用于进行节点之间基于TLS的安全通信。TLS通信的一个例子是peer节点需要连接到排序节点，以便它能接收到账本更新数据。此文件夹中必须至少有一个TLS根CA证书。

• tlsintermediatecacerts: 此文件夹包含一个受该MSP所代表的组织信任的中间CA证书列表，用于进行节点之间基于TLS的安全通信。当商业CA被用作一个组织的TLS证书时，此文件夹特别有用。与成员资格中间CA类似，TLS中间CA的指定是可选的。

• operationscerts: 此文件夹包含与Fabric运维服务API通信所需的证书。

通道MSP包含以下附加文件夹:

• Revoked Certificates: 如果参与者的身份被撤销，关于该身份的识别信息（而不是身份本身）会被保存在这个文件夹中。对于基于x.509的身份，这些标识符是被称为Subject Key Identifier(SKI)和Authority Access Identifier(AKI)的字符串对，并且在使用证书时被检查，以确保证书没有被撤销。

策略

在 Hyperledger Fabric 中，策略是基础设施的管理机制。Fabric 策略表示成员如何同意或者拒绝网络、通道或者智能合约的变更。策略在网络最初配置的时候由联盟成员一致同意，但是在网络演化的过程中可以进行修改。例如，定义了从通道中添加或者删除成员的标准，改变区块格式或者指定需要给智能合约背书的组织数量。

策略是使 Hyperledger Fabric 不同于其他区块链系统（比如 Ethereum 或者 Bitcoin）。在其他系统中，交易可以在网络中的任意节点生成和验证。治理网络的策略可以在任何时间及时修复，并且只可以使用和治理代码相同的方式进行变更。因为 Fabric 是授权区块链，用户由底层基础设施识别，所以用户可以在启动前决定网络的治理方式，以及改变正在运行的网络的治理方式。

策略决定了哪些组织可以访问或者更新 Fabric 网络，并且提供了强制执行这些决策的机制。 策略包含了有权访问给定资源的组织列表，比如一个用户或者系统链码。策略中同样指定了需要多少组织同意更新资源的提案，比如通道或者智能合约。一旦策略被写入，就会评估交易和提案中的签名，并验证签名是否满足网络治理规则。

Fabric实现策略

策略实现在 Fabric 网络的不同层次。每个策略域都管理着网络操作的不同方面。

系统通道配置（System Channel）

每个网络都从排序服务系统通道开始。网络中必须有至少一个排序服务的排序系统通道，它是第一个被创建的通道。 该通道也包含着谁是排序服务（排序服务组织）以及在网络中交易（联盟组织）的成员。排序系统通道配置区块中的策略治理着排序服务使用的共识，并定义了新区块如何被创建。系统通道也治理着联盟中的哪些成员可以创建新通道。

应用通道配置

应用通道用于向联盟中的组织间提供私有通信机制。 应用通道中的策略治理着从通道中添加和删除成员的能力。应用通道也治理着使用 Fabric 链码生命周期在链码定义和提交到通道前需要哪些组织同意。当系统通道初始创建时，它默认继承了排序系统通道的所有排序服务参数。同时，这些参数（包括治理它们的策略）可以被每个通道自定义。

权限控制列表（ACL）

ACL 通过将资源和已有策略相关联的方式提供了资源访问配置的能力。“资源”可以是系统链码中的方法（“qscc”中的“GetBlockByNumber”）或者其他资源（获取区块事件）。

Fabric ACL 的默认集合在 configtx.yaml 文件的 Application: &ApplicationDefaults 部分，但是它们可以也应该在生产环境中被重写。configtx.yaml 中定义的资源列表是 Fabric 当前定义的所有内部资源的完整集合。该文件中，ACL 以如下格式表示：

# ACL policy for chaincode to chaincode invocation
peer/ChaincodeToChaincode: /Channel/Application/Writers

peer/ChaincodeToChaincode 表示该资源是被保护的，相关的交易必须符合 /Channel/Application/Writers 引用侧策略才能被认为是有效的。

智能合约背书策略（Endorsement）

链码包中的每一个智能合约都有一个背书策略，该策略指明了需要通道中多少不同组织的成员根据指定智能合约执行和验证交易才能使一笔交易有效。因此，背书策略定义了必须“背书”（批准）提案执行的组织（Peer 节点）。

修改策略

修改（Modification）策略指明了需要签名所有配置更新的一组身份。它是定义如何更新策略的策略。每个通道配置元素都包含这一个治理它的变更的策略的引用。

策略作用域

一个完整的 Fabric 网络可以由许多不同职能的组织组成。通过支持排序服务创建者建立初始规则和联盟成员的方式，域提供了向不同组织扩展不同的优先级和角色的能力。还支持联盟中的组织创建私有应用通道、治理他们自己的商业逻辑以及限制网络中数据的访问权限。

• 系统通道配置和每个应用通道配置部分提供了排序组织对哪些组织是联盟成员、区块如何分发到通道以及排序服务节点使用的共识机制的控制。

• 系统通道配置为联盟成员提供了创建通道的能力。应用通道和 ACL 是联盟组织用来从通道中添加或删除成员以及限制通道中智能合约和数据访问的机制。

在Fabric中写策略

如果想修改 Fabric 的任何东西，和资源相关的策略都描述了谁需要批准它，可以是来自个人的一个显式签名，也可以是组的一个隐式签名。在 Hyperledger Fabric 中，策略中明确的签名使用 Signature 语法，隐含的签名使用 ImplicitMeta 语法。

签名策略

Signature 策略定义了要满足策略就必须签名的特定用户类型，比如 Org1.Peer OR Org2.Peer。策略是很强大的，因为它可以构造复杂的规则，比如“组织 A 和 2 个其他管理员，或者 6 个组织的管理员中的 5 个”。语法支持 AND、 OR 和 NOutOf 的任意组合。 例如，一个策略可以简单表达为使用 AND (Org1, Org2) ，表示满足该策略就同时需要 Org1 中的一个成员和 Org2 中的一个成员的签名。

隐元（ImplicitMeta）策略

隐元策略只在通道配置上下文中有效，通道配置在配置树策略中是基于分层的层次结构。隐元策略聚合了由签名策略最终定义的配置树深层的结果。 它们是隐藏的，因为它们基于通道配置中的当前组织隐式构建，它们是元信息，因为它们的评测不依赖于特定 MSP 规范，而是依赖于配置树中它们的其他子策略。

下图说明了应用通道分层的策略结构，演示了隐元通道配置管理策略（Channel/Admins）是如何处理的，当满足配置层级中它的 Admins 子策略时，就代表也满足了其子策略的子策略条件。

隐元策略，Type = 3，使用了一种不同的语法
“ ”

`MAJORITY sub policy: Admins`

上边的图表展示了一个在配置树中所有 Admins 策略都引用了的 Admin 子策略。你可以创建你自己的子策略并随意命名，并且可以定义在你的每一个组织中。

隐元策略比如 MAJORITY Admins 的主要优势在于当你向通道添加新组织的时候，你不必更新通道策略。 联盟中成员的新增或者退出只要联盟成员一致同意即可，不需要更新策略。

可以定义一个应用级别的隐策略来进行跨组织操作，例如在通道中，需要 ANY （任意）、 ALL （全部）或者 MAJORITY （大多数）组织来满足。

通过在组织定义中引入 NodeOUs 来实现进一步的粒度和控制。OU （Organization Units，组织单元）定义在 Fabric CA 客户端配置文件中，当创建身份的时候就会与之关联。在 Fabric 中， NodeOUs 提供为数字证书层级分类的功能。例如，一个指定了 NodeOUs 的组织可以让一个 ‘Peer’ 签名合法背书，或者组织也可以简单设置为任何成员都可以签名。

通道配置策略

背书策略的理解要从 configtx.yaml 开始，configtx.yaml 里边定义了通道策略。

可以在 fabric-samples/test-network目录查看/configtx/configtx.yaml文件。
链接: https://github.com/hyperledger/fabric-samples/blob/main/test-network/configtx/configtx.yaml

使用签名策略定义的组织示例

文件的第一部分（Organizations）定义了网络中的组织。在每个组织的定义中设置了默认策略，Readers, Writers, Admins, and Endorsement，可以任意定义策略命名。每个策略都有一个 Type 和 Rule， Type 描述了策略的表达式类型（Signature 或 ImplicitMeta）。

示例展示了组织 Org1 在系统通道中的定义，其中策略的 Type 是 Signature 背书策略规则定义为 “OR(‘Org1MSP.peer’)”，表示需要 Org1MSP 成员中的 peer 来签名。正是这些签名策略形成了隐元策略指向的子策略。

    - &Org1
        # DefaultOrg defines the organization which is used in the sampleconfig
        # of the fabric.git development environment
        Name: Org1MSP

        # ID to load the MSP definition as
        ID: Org1MSP

        MSPDir: ../organizations/peerOrganizations/org1.example.com/msp

        # Policies defines the set of policies at this level of the config tree
        # For organization policies, their canonical path is usually
        #   /Channel///
        Policies:
            Readers:
                Type: Signature
                Rule: "OR('Org1MSP.admin', 'Org1MSP.peer', 'Org1MSP.client')"
            Writers:
                Type: Signature
                Rule: "OR('Org1MSP.admin', 'Org1MSP.client')"
            Admins:
                Type: Signature
                Rule: "OR('Org1MSP.admin')"
            Endorsement:
                Type: Signature
                Rule: "OR('Org1MSP.peer')"

使用隐元策略定义的应用程序示例

示例展示了使用隐元策略定义了应用程序通道的许多重要特性的行为，例如谁可以查询通道分类帐、调用链代码或更新通道配置。

################################################################################
#
#   SECTION: Application
#
#   - This section defines the values to encode into a config transaction or
#   genesis block for application related parameters
#
################################################################################
Application: &ApplicationDefaults

    # Organizations is the list of orgs which are defined as participants on
    # the application side of the network
    Organizations:

    # Policies defines the set of policies at this level of the config tree
    # For Application policies, their canonical path is
    #   /Channel/Application/
    Policies:
        Readers:
            Type: ImplicitMeta
            Rule: "ANY Readers"
        Writers:
            Type: ImplicitMeta
            Rule: "ANY Writers"
        Admins:
            Type: ImplicitMeta
            Rule: "MAJORITY Admins"
        LifecycleEndorsement:
            Type: ImplicitMeta
            Rule: "MAJORITY Endorsement"
        Endorsement:
            Type: ImplicitMeta
            Rule: "MAJORITY Endorsement"

    Capabilities:
        <<: *ApplicationCapabilities

• LifecycleEndorsement 策略控制需要谁批准链码定义 。
• Endorsement 策略是链码的默认背书策略 。

Fabric链码生命周期

Fabric 2.0 发布版本中，介绍了一个新的链码生命周期过程。新的过程允许多个组织在链码应用到通道之前如何操作进行投票。新的流程指定策略包含两步，当链码被组织成员批准的时候，以及当它被提交到通道后。

链码背书策略

当使用 Fabric 链码生命周期，链码被批准并提交到通道时会指定一个背书策略（这个背书策略会覆盖与该链码相关的所有状态）。背书策略可以引用通道配置中的背书策略或者明确指定签名策略。

如果在批准阶段没有明确指明背书策略，就默认使用 Endorsement 策略 “MAJORITY Endorsement”，意味着要想使交易生效就需要大多数不同通道成员（组织）的执行并验证交易。默认策略允许加入通道的组织自动加入链码背书策略。 如果不想使用默认背书策略，可以使用签名策略格式来指定更复杂的背书策略（这样就需要链码先被通道中的一个组织签名，然后让其他组织签名）。

签名策略允许包含主角（principals），这是匹配角色和身份的一种简单方式。主角类似用户 ID 或者 组 ID，被描述为 ‘MSP.ROLE’，MSP 表示需要的 MSP ID（组织），ROLE 表示一下四种可接受的角色之一：Member、 Admin、 Client 和 Peer。 角色在用户使用 CA 登记（enroll）的时候与之关联。可以在 Fabric CA 中自定义可用的角色列表。

一些有效的主角：

• ‘Org0.Admin’: Org0 MSP 的一个管理员
• ‘Org1.Member’: Org1 MSP 的一个成员
• ‘Org1.Client’: Org1 MSP 的一个客户端
• ‘Org1.Peer’: Org1 MSP 的一个 Peer 节点
• ‘OrdererOrg.Orderer’: OrdererOrg MSP 的一个排序节点

覆盖策略定义

Hyperledger Fabric 包含了默认策略，但是在生产环境中需要自定义。通道配置策略可以使用任意单词扩展，不仅仅是 configtx.yaml 中的 Readers、 Writers、 Admins。当编辑 configtx.yaml 文件重写了排序系统通道或这指定通道的默认策略并提交了配置更新，就会覆盖排序系统和应用通道的默认策略。

Peer 节点

区块链网络是由 Peer 节点组成的，每个节点都保存着账本和智能合约的副本。Peer 节点可以被创建、启动、停止、重新配置甚至删除，管理者和应用程序可以通过一系列的 API提供的服务互动。

网络 N 是由节点 P1、P2 和 P3 组成的，每个节点都维护着他们自己的分布式账本 L1。P1、P2 和 P3 使用相同的链码 S1 来访问他们的分布式账本的副本。

账本和链码

Peer 节点维护着账本及链码的实例。 （P1 维护着账本 L1 和链码 S1 的实例。）Peer 节点是账本及链码的宿主，应用程序及管理员如果想要访问这些资源，他们必须要和 Peer 节点进行交互。这就是为什么 Peer 节点被认为是 Hyperledger Fabric 网络最基本的组成模块。当 Peer 节点被第一次创建的时候，它并没有账本也没有链码。

多账本

一个 Peer 节点维护着一个或者多个账本，并且每个账本具有零个或者多个链码使用账本。 （ Peer 节点 P1 维护着账本 L1 和 L2。账本 L1 通过链码 S1 来访问。账本 2 通过链码 S1 和 S2 访问。）大多数的 Peer 节点将会至少安装一个链码，用来查询或更新 Peer 节点的账本实例。无论用户是否安装了外部应用使用的链码，Peer 节点总是会有一个特殊的系统链码。

多链码

账本数量和访问账本的链码的数量之间没有固定的关系。一个运行着多个链码的 Peer 节点，每个账本可以拥有多个访问它的链码。（ Peer 节点 P1 维护着账本 L1 和 L2，L1 可以通过链码S1 和 S2 来访问，账本 L2 可以由 S1 和 S3 来访问。我们能够看到链码 S1 既能访问 L1 也能访问 L2。）

应用程序和 Peer 节点

当应用程序需要访问账本和链码的时候，总是需要连接到 Peer 节点。Hyperledger Fabric SDK 提供的API 使应用程序能够连接到 Peer 节点，调用链码生成交易，提交交易到网络，在网络中交易会被排序并且提交到分布式账本中，并且在这个流程结束的时候接收到事件。

Peer 节点和排序节点，确保了账本在每个 Peer 节点上都具有最新的账本。

应用程序 A 连接到了 P1 并且调用了链码 S1 来查询或者更新账本 L1。P1 调用了链码 S1 来生成提案响应，这个响应包含了查询结果或者账本更新的提案。应用程序 A 接收到了提案的响应，对于查询来说，流程到这里就结束了。对于更新来说，应用程序 A 会从所有的响应中创建一笔交易，它会把这笔交易发送给排序节点 O1 进行排序。O1 会搜集网络中的交易并打包到区块中，然后将这些区块分发到所有 Peer 节点上，包括 P1。P1 在把交易提交到账本 L1 之前对交易进行验证。当 L1 被更新之后，P1 会生成一个事件，该事件会被 A 接收到，来标识这个过程结束了。

Peer 节点可以马上将查询的结果返回给应用程序，因为满足这个查询的所有信息都保存在 Peer 节点本地的账本副本中。 Peer 节点从来不会为了应用程序的查询返回结果而去询问其他 Peer 节点的。但是应用程序还是能够连接到一个或者多个 Peer 节点来执行一个查询；比如，为了协调在多个 Peer 节点间的一个结果，或者当怀疑数据不是最新的时候，需要从不同的 Peer 节点获得更新的结果。

更新交易和查询交易起点相同，但是有两个额外的步骤。尽管更新账本的应用程序也会连接到 Peer 节点来调用链码，但是不像查询账本的应用程序，一个独立的 Peer 节点目前是不能进行账本更新的，因为其他的 Peer 节点必须首先要同意这个变动（即达成共识）。因此，Peer 节点会返回给应用程序一个被提案过的更新，这个 Peer 节点会依据其他节点之前的协议来应用这个更新。步骤4要求应用程序将响应的提案过的更新发送到网络中，网络中的 Peer 节点会将交易提交到它们相应的账本中。应用程序会收到排序节点打包了交易的区块，然后将他们分发到网络中所有的 Peer 节点，在区块被更新到每个 Peer 节点本地账本的副本中之前，这些区块都需要被验证。排序流程需要一定时间来完成 (数秒钟)，因此应用程序会被异步通知，像步骤5中展示的那样。

Peer 节点和通道

通道允许区块链网络中特定的一些 Peer 节点以及应用程序来彼此交互。

应用程序 A 能够直接同 Peer 节点 P1 和 P2 使用通道 C 进行沟通。（排序节点没有显示在这个图中，但是在工作网络中它必须存在。）

通道和 Peer 节点是以不同的方式存在的，将通道理解为由物理的 Peer 节点的组成的逻辑结构 ，因为 Peer 节点提供了对通道访问和管理的控制。

Peer 节点和组织

区块链网络中的 Peer 节点和多个组织。区块链网络是由不同的组织所拥有并贡献的 Peer 节点构成的。

在网络 N 中，由四个组织贡献了八个 Peer 节点组成一个网络。通道 C 连接了这些 Peer 节点中的五个：P1、P3、P5、P7 和 P8。这些组织拥有的其他节点并没有加入该通道，但是通常会加入至少一个其他通道。某个组织开发的应用程序将会连接到他们自己组织的 Peer 节点，其他组织也一样。

如果组织不为这个网络贡献他们的资源，这个网络是不会存在的。更关键的是，这个网络会随着这些互相合作的组织提供的资源而增长或者萎缩。

网络不依赖于任何一个单独的组织，只要还存在一个组织，网络就会继续存在，不管其他的组织加入或者离开。这就是去中心化网络的核心。

应用程序会连接到他们组织的 Peer 节点或者其他组织的 Peer 节点，取决于账本交互的需求。对于查询账本的交互，应用程序通常会连接到他们自己组织的 Peer 节点。对于更新账本的交互，应用程序需要连接到多个 Peer 节点，这些节点是每一个要为账本更新进行背书的组织的代表。

Peer 节点和身份

当 Peer 节点连接到一个通道的时候，它的数字证书会通过通道 MSP 来识别它的所属组织。

P1 和 P2 具有由 CA1 颁发的身份信息。通道 C 通过在它的通道配置中的策略来决定来自 CA1 的身份信息应该使用 ORG1.MSP 被关联到 Org1。P3 和 P4 由 ORG2.MSP 识别为 Org2 的一部分。

当 Peer 节点使用通道连接到一个区块链网络的时候，在通道配置中的策略会使用 Peer 节点的身份信息来确定它的权利。关于身份信息和组织的映射是由成员服务提供者（MSP）来提供的，它决定了一个 Peer 节点如何在指定的组织中分配到特定的角色以及得到访问区块链资源的相关权限。

一个 Peer 节点只能被一个组织所有，因此也就只能被关联到一个单独的 MSP。 MSP 在区块链网络中，为一个独立的身份信息和一个特定的组织角色之间提供了关联。

Peer 节点以及同一个区块链网络进行交互的每件事情都会从他们的数字证书和 MSP 来得到他们的组织的身份信息。Peer 节点、应用程序、终端用户、管理员以及排序节点如果想同一个区块链网络进行交互的话，必须要有一个身份信息和一个相关联的 MSP。我们使用身份信息来为每个跟区块链网络进行交互的实体提供一个名字——一个主角（principal）。

Peer 节点物理上在哪并不重要（它可以放在云中，或者是由一个组织所有的数据中心中，或者在一个本地机器中）是与它相关联的数字证书信息来识别出它是由哪个组织所有的。在上边的例子中，P3 可以运行在 Org1 的数据中心中，只要与它相关联的数字证书是由 CA2 颁发的，那么它就是 Org2 所拥有的。

Peer 节点和排序节点

Peer 节点构成了一个基本的区块链网络，维护着账本和智能合约，连接到 Peer 节点的应用程序进行查询及更新。但是，应用程序和 Peer 节点彼此互相交互来确保每个 Peer 节点的账本永远保持一致是通过以排序节点作为中心媒介的一种特殊机制。

一个单独的 Peer 节点不能够由它自己来更新账本，更新需要网络中其他节点的同意。在一个账本的更新被应用到 Peer 节点的本地账本之前， Peer 节点会请求网络中的其他 Peer 节点来批准这次更新，这个过程被称为共识。

想要更新账本的应用程序会被引入到一个三阶段的流程，这确保了在一个区块链网络中所有的 Peer 节点都彼此保持着一致的账本。

• 第一阶段，应用程序会跟背书节点的子集一起工作，其中的每个节点都会向应用程序为提案的账本更新提供背书，但是不会将提案的更新应用到他们的账本副本上。
• 第二阶段，这些分散的背书会被搜集到一起当做交易被打包进区块中。
• 第三阶段，这些区块会被分发回每个 Peer 节点，在这些 Peer 节点上每笔交易在被应用到 Peer 节点的账本副本之前会被验证。

阶段1：提案

交易流程的第一阶段会引入在应用程序和一系列的 Peer 节点之间的交互（它并没有涉及到排序节点。）第一阶段只在乎应用程序询问不同组织的背书节点同意链码调用的提案结果。

为了开始第一阶段，应用程序会生成一笔交易的提案，它会把这个提案发送给一系列的被要求的节点来获得背书。其中的每一个背书节点接下来都会独立地使用交易提案来执行链码，以此来生成这个交易提案的响应。这并没有将这次更新应用到账本上，只是简单地为它提供签名然后将它返回给应用程序。当应用程序接收到有效数量的被签过名的提案响应之后，交易流程中的第一个阶段就结束了。

交易提案会被 Peer 节点独立地执行，Peer 节点会返回经过背书的提案响应。

应用程序 A1 生成了交易 T1 和提案 P，应用程序会将交易及提案发送给通道 C 上的 Peer 节点 P1 和 Peer 节点 P2。P1 使用交易 T1 和 提案 P 来执行链码 S1，这会生成对交易 T1 的响应 R1，它会提供背书 E1。P2 使用交易 T1 提案 P 执行了链码 S1，这会生成对于交易 T1 的响应 R2，它会提供背书 E2。应用程序 A1 对于交易 T1 接收到了两个背书响应，称为 E1 和 E2。

最初，应用程序会选择一些 Peer 节点来生成一套关于账本更新的提案。应用程序会选择哪些 Peer 节点呢？这取决于背书策略（这是为链码定义的），这个策略定义了在一个账本提案能够被网络所接受之前，都需要哪些 Peer 节点需要对这个账本变更提案进行背书。

Peer 节点通过向提案的响应添加自己的数字签名的方式提供背书，并且使用它的私钥为整个的负载提供签名。然后这个背书会被用于证明这个组织的 Peer 节点生成了一个特殊的响应。如果 Peer 节点 P1 是属于组织 Org1 的话，背书 E1 就相当于一个数字证明（在账本 L1 上的交易 T1 的响应 R1 已经被 Org1 的 Peer 节点 P1 同意了）。

第一阶段在当应用程序从足够多的有效的 Peer 节点那里收到了签过名的提案响应的时候就结束了。 不同的 Peer 节点能够返回不同的响应，因此对于同一个交易提案应用程序可能会接收到不同的交易响应。这可能简单地因为这个结果是在不同的时间，不同的 Peer 节点以及基于不同状态的账本所产生的，在这个情况下，一个应用程序可以请求一个更新的提案响应。还有一种严重的可能，结果的不同可能会是因为链码是非确定性的。非确定性是链码和账本的敌人，并且如果它真的发生了的话，这代表着这个提案的交易存在一个很严重的问题，因为非一致的结果很明显是不能够被应用到账本上的。一个单独的 Peer 节点是无法知道他们的交易结果是非确定性的——在非确定性问题被发现之前，交易的响应必须要被搜集到一起来进行比较。

阶段2：排序和将交易打包到区块

交易流程的第二个阶段是打包阶段。排序节点是这个过程的关键（它接收交易），这些交易中包含了来自很多个应用的已经背书过的交易提案，并且将交易排序并打包进区块。

阶段3：验证和提交

在每个 Peer 节点上，区块中的每笔交易都会被验证，以确保它在被提交到账本之前，已经被所有相关的组织一致地背书过了。失败的交易会被留下来方便审计，但是不会被提交到账本中。

排序节点的第二个角色是将区块分发给 Peer 节点。

排序节点 O1 将区块 B2 分发给了 Peer 节点 P1 和 Peer 节点 P2。Peer P1 处理了区块 B2，产生了一个会被添加到 P1 的账本 L1 中的新区块。同时，peer P2 处理了区块 B2，产生了一个会被添加到 P2 的账本 L1 中的新区块。当这个过程结束之后，账本 L1 就会被一致地更新到了 Peer 节点 P1 和 P2 上，也可能会通知所连接的应用程序关于这笔交易已经被处理过的消息。

排序节点将区块分发到所有与它连接的 Peer 节点，Peer 节点会和通道中的排序节点相连，所有跟这个排序节点相连的 Peer 节点将会收到一个新的区块的副本。每个 Peer 节点会独立处理这个区块，但是会跟这个通道上的每一个其他 Peer 节点使用完全一致的方式处理。通过这种方式，账本始终保持一致。不是每个 Peer 节点都需要连接到排序节点（Peer 节点可以使用 gossip 协议将区块的信息发送给其他 Peer 节点，其他 Peer 节点也可以独立地处理这些区块）。

当接到区块的时候，Peer 节点会按照区块中的顺序处理每笔交易。对于每一笔交易，每个 Peer 节点都会确认这笔交易已经根据产生这笔交易的链码中定义的背书策略由要求的组织进行过背书了。比如，在一些交易被认为是有效之前，这些交易可能仅仅需要一个组织的背书，但是其他的交易可能会需要多个背书。这个验证的流程确认了所有相关的组织已经生成了相同的产出或者结果。也需要注意到的是，这次的验证跟在阶段 1 中进行的背书检查是不同的，应用程序从背书节点那里接收到了交易的响应，然后做了决定来发送交易提案。如果应用程序违反了背书策略发送了错误的交易，那么 Peer 节点还是能够在阶段 3 中的验证流程里拒绝这笔交易。

如果一笔交易被正确的背书，Peer 节点会尝试将它应用到账本中。Peer 节点必须要进行账本一致性检查来验证当前账本中的状态同应用了更新提案后的账本是能够兼容的。通过这种方式，账本在通道中的每个 Peer 节点都是保持一致的，因为他们中每个都在遵守相同的验证规则。

当 Peer 节点成功地验证每笔单独的交易之后，它就会更新账本了。失败的交易是不会应用到账本中的，但是他们会被保留为之后的审计使用，就像成功的交易那样。这意味着 Peer 节点中的区块几乎会跟从排序节点收到的区块是一样的，除了在区块中每笔交易中会带有有效或者无效的指示符。

第三阶段并没有要求执行链码，这意味着链码仅仅需要在背书节点中有效，而不需要在区块链网络的所有部分都要有。这保持了链码逻辑的机密性只有背书组织了解。这个同链码的输出（交易提案的响应）恰恰相反，这个输出会被分享给通道中的所有 Peer 节点，不管这些 Peer 节点是否为这交易提供背书。

最终，每次当区块被提交到 Peer 节点的账本的时候，那个 Peer 节点会生成一个合适的事件。区块事件包括了整个区块的内容，然而区块交易事件仅仅包含了概要信息，比如是否在区块中的每笔交易是有效的还是无效的。链码已经被执行的链码事件也可以公布出去，应用程序可以对这些事件类型进行注册，所以在这些事件发生的时候他们能够被通知到。这些通知结束了交易流程的第三以及最后的阶段。

在第三阶段中，由排序节点生成的区块被一致地应用到了账本中。将交易严格地排序到区块中让每个 Peer 节点都来验证交易更新，并一致地应用到区块链网络中。

排序节点和共识

整个交易处理流程被称为共识，因为所有 Peer 节点在由排序节点提供的流程中对交易的排序及内容都达成了一致。共识是一个多步骤的流程，并且应用程序只会在这个流程结束的时候通知账本更新（这个在不同的 Peer 节点上可能在不同的时间会发生）。

智能合约和链码

智能合约与账本一起构成了 Hyperledger Fabric 区块链系统的核心。账本包含了与一组业务对象的当前和历史状态有关的事实，而智能合约定义了生成这些被添加到账本中的新事实的可执行逻辑。管理员通常使用链码将相关的智能合约组织起来进行部署，并且链码也可以用于 Fabric 的底层系统编程。

Hyperledger Fabric 用户经常交替使用智能合约和链码。通常，智能合约定义的是控制世界状态中业务对象生命周期的交易逻辑，随后该交易逻辑被打包进链码，紧接着链码会被部署到区块链网络中。可以将智能合约看成交易的管理者，而链码则管理着如何将智能合约打包以便用于部署。

一个智能合约定义在一个链码中。而多个智能合约也可以定义在同一个链码中。当一个链码部署完毕，该链码中的所有智能合约都可供应用程序使用。

上图中，vehicle 链码包含了以下三个智能合约：cars、boats 和 trucks；而 insurance 链码包含了以下四个智能合约：policy、liability、syndication 和 securitization。以上每种智能合约都涵盖了与车辆和保险有关的业务流程的一些关键点。以 car 智能合约为例，智能合约是一个特定领域的程序，它与特定的业务流程相关，而链码则是一组相关智能合约安装和实例化的技术容器。

智能合约

智能合约用可执行的代码定义了不同组织之间的规则。应用程序调用智能合约来生成被记录到账本上的交易。

使用区块链网络，可以将这些合约转换为可执行程序（业内称为智能合约），因为智能合约可以为任何类型的业务对象实现治理规则，以便在执行智能合约时自动执行这些规则。

上图中，我们可以看到组织 ORG1 和 ORG2 是如何通过定义一个 car 智能合约来实现 查询、转移 和 更新 汽车的。来自这些组织的应用程序调用此智能合约执行业务流程中已商定的步骤，例如将特定汽车的所有权从 ORG1 转移到 ORG2。

账本 Ledger

区块链记录着更新账本状态的交易，且记录不可篡改。智能合约以编程方式访问账本两个不同的部分：一个是区块链（记录所有交易的历史，且记录不可篡改），另一个是世界状态 World State （保存这些状态当前值的缓存，是经常需要用到的对象的当前值）。

智能合约主要在世界状态中将状态写入（put）、读取（get）和删除（delete），还可以查询不可篡改的区块链交易记录。

• 读取（get） 操作一般代表的是查询，目的是获取关于交易对象当前状态的信息。
• 写入（put） 操作通常生成一个新的业务对象或者对账本世界状态中现有的业务对象进行修改。
• 删除（delete） 操作代表的是将一个业务对象从账本的当前状态中移除，但不从账本的历史中移除。

在任意情况下，无论交易创建、读取、更新还是删除世界状态中的业务对象，区块链都包含了这些操作的记录，且记录不可更改 。

智能合约开发

一个链码中可定义一个或多个智能合约。将链码部署到网络中以后，网络上的组织就都可以使用该链码中的所有智能合约。这意味着只有管理员才需要考虑链码；其他人都只用考虑智能合约。

智能合约的核心是一组交易定义。

async createCar(ctx, carNumber, make, model, color, owner) {

    const car = {
        color,
        docType: 'car',
        make,
        model,
        owner,
    };

    await ctx.stub.putState(carNumber, Buffer.from(JSON.stringify(car)));
}

智能合约几乎可以描述所有与多组织决策中数据不可变性相关的业务案例。智能合约开发人员的工作是将一个现有的业务流程（可能是管理金融价格或交付条件）用 JavaScript、GOLANG 或 Java 等编程语言来表示成一个智能合约。

背书策略 Endorsement

每个链码都有一个背书策略与之相关联，该背书策略适用于此链码中定义的所有智能合约。背书策略指明了区块链网络中哪些组织必须对一个给定的智能合约所生成的交易进行签名，以此来宣布该交易有效。

每个智能合约都有一个与之关联的背书策略。这个背书策略定义了在智能合约生成的交易被认证为有效之前，哪些组织必须同意该交易。

一个示例背书策略这样定义：参与区块链网络的四个组织中有三个必须在交易被认为有效之前签署该交易。所有的交易，无论是有效的还是无效的，都会被添加到分布式账本中，但只有有效交易会更新世界状态。

如果一项背书策略指定了必须有不止一个组织来签署交易，那么只有当足够数量的组织都执行了智能合约，才能够生成有效交易。在示例中，要使用于车辆 transfer 的智能合约交易有效，需要 ORG1 和 ORG2 都执行并签署该交易。

背书策略是 Hyperledger Fabric 与以太坊（Ethereum）或比特币（Bitcoin）等其他区块链的区别所在。在这些区块链系统中，网络上的任何节点都可以生成有效的交易。而 Hyperledger Fabric 更真实地模拟了现实世界；交易必须由 Fabric 网络中受信任的组织验证。

背书策略只是 Hyperledger Fabric 中策略的一个例子。还可以定义其他策略来确定谁可以查询或更新账本，或者谁可以在网络中添加或删除参与者。总体来说，虽然区块链网络中的组织联盟并非一成不变，但是它们需要事先商定好策略。

有效交易 Valid transactions

当智能合约执行时，它会在区块链网络中组织所拥有的节点上运行。智能合约提取一组名为交易提案（transaction proposal）的输入参数，并将其与程序逻辑结合起来使用以读写账本。对世界状态的更改被捕获为交易提案响应（transaction proposal response 或简称交易响应 transaction response），该响应包含一个读写集，其中既含有已读取的状态，也含有还未书写的新状态（如果交易有效的话）。
在执行智能合约时世界状态没有更新！

所有的交易都有一个识别符、一个提案和一个被一群组织签名的响应。所有交易，无论是否有效，都会被记录在区块链上，但仅有效交易会更新世界状态。

图例：检查 车辆转移 交易。可以看到 ORG1 和 ORG2 之间为转移一辆车而进行的交易 t3。通过输入 {CAR1，ORG1，ORG2} 和输出 {CAR1.owner=ORG1，CAR1.owner=ORG2} 来表示汽车的所有者从 ORG1 变为了 ORG2。输入是由应用程序的组织 ORG1 签名的，输出是由背书策略标识的两个组织（ ORG1 和 ORG2 ）签名的。这些签名是使用每个参与者的私钥生成的，这意味着网络中的任何人都可以验证网络中的所有参与者是否在交易细节上达成了一致。 t3 是一个有效的交易，因此 CAR1 的所有者已更新为 ORG2。但是 t4 （未显示）是无效的交易，所以当把它记录在账本上时，世界状态没有更新，CAR2 仍然属于 ORG2 所有。

一项交易被分发给网络中的所有节点，各节点通过两个阶段对其进行验证。首先，根据背书策略检查交易，确保该交易已被足够的组织签署。其次，继续检查交易，以确保当该交易在受到背书节点签名时它的交易读集与世界状态的当前值匹配，并且中间过程中没有被更新。如果一个交易通过了这两个测试，它就被标记为有效。所有交易，不管是有效的还是无效的，都会被添加到区块链历史中，但是仅有效的交易才会更新世界状态。