hyperledger-fabric documention官方文档

##介绍
Hyperledger Fabric 是分布式账本解决方案的平台，采用模块化架构，提供高安全性、弹性、灵活性和可扩展性。它被设计为支持以可插拔方式实现不同组件，并适应复杂的经济生态系统。
- ###私有和许可
- ###通道
  一些参与者可能是竞争对手，并且不希望他们做出的每笔交易都被每个参与者知晓，例如，他们只向某些参与者提供的特殊价格，而其他人不是。如果两个参与者组成一个通道，那么只有这两个参与者拥有该通道的账本副本，而其他参与者没有。
##区块链
- ###一个分布式账本
  - ####区块链账本通常被描述为去中心化的，因为它会被复制到许多网络参与者中，每个参与者都在协作维护账本。
  - ####不可修改，可被用作证明系统
- ###智能合约：提供对账本的受控访问
  用链码编写，当该应用程序需要与账本交互时，由区块链外部的应用程序调用。在大多数情况下，链码只与账本的数据库、世界状态（例如，查询）交互，而不与交易日志交互。
- ###共识：保持账本在整个网络中同步的过程
  - ####交易必须按照发生的顺序写入账本，即使它们可能位于网络中不同的参与者集合之中。为此，必须建立交易的顺序，且必须采用一种方法来拒绝错误（或恶意）插入到账本中的非法交易。例如，PBFT（实用拜占庭容错算法）可以为文件副本提供一种机制，使其能够保持各个副本的一致性，即使在发生损坏的情况下也是如此。或者，在比特币中，通过称为挖矿的过程进行排序，其中竞争计算机竞相解决加密难题，该难题定义所有过程随后构建的顺序。
  - ####当区块中交易的订单和结果满足明确的策略标准检查时，最终会达成共识。这些检查和平衡发生在交易的生命周期中，并包括使用背书策略来指定哪些特定成员必须背书某个交易类以及系统链码，以确保强制执行和维护这些策略。在提交之前，节点将使用这些系统链码来确保存在足够的背书，并且它们来自适当的实体。此外，在包含交易的任何区块附加到账本之前，将进行版本控制检查，在此期间，账本的当前状态为同意。此最终检查可防止双重花费操作和可能危及数据完整性的其他威胁，并允许针对非静态变量执行功能。
  - ####除了发生的大量背书、验证和版本检查之外，交易流的所有方向上还发生着持续的身份验证。访问控制列表在网络的层级上实现（排序服务到通道），并且当交易提议通过不同的体系结构组件时，有效负载被重复签名、确认和验证。总而言之，共识不仅限于一批交易的商定订单；相反，它是一种总体特征，是在交易从提案到背书的过程中进行的持续验证的副产品。
- ###共享账本
  - ####世界状态
    世界状态组件描述了在给定时间点的账本的状态。它是账本的数据库
  - ####交易日志
    记录产生世界状态中当前值的所有交易；这是世界状态的更新历史。然后，账本包括世界状态数据库和交易日志历史记录。交易日志不需要是可插拔的。它只记录区块链网络使用的账本数据库前后的值。
  - ####特性
    使用基于键的查找、范围查询和组合键查询来查询和更新账本 - 使用富查询语言的只读查询（如果使用 CouchDB 作为状态数据库） - 只读历史记录查询（查询键的账本历史记录），以支持数据溯源方案 - 包含链码读取的键/值的版本（读集）以及链码写入的键/值（写集）的交易 - 包含每个背书节点的签名，并提交给排序服务的交易 - 按顺序打包到区块，并从排序服务“分发”到通道上的节点的交易 - 节点根据背书策略验证交易并执行策略 - 在附加区块之前，执行版本检查以确保链码执行以后读取的资产的状态未发生更改 - 一旦交易被验证并提交，就不可改变 - 通道的账本包含了定义策略、访问控制列表和其他相关信息的配置区块 - 通道包含 Membership Service Provider 的程序实例，允许从不同的证书颁发机构派生加密材料
- ###区块链网络
- 一个为应用程序提供账本及智能合约（chaincode）服务的技术基础设施
  - R4 被分配作为网络的初始者，它有权设置网络的初始版本。R4 不会在网络中去进行任何的业务交易。**R1 和 R2 在整个网络中有进行私有通信的需求，R2 和 R3 也是。
  - 组织 R1 有一个客户端的应用能够在通道 C1 中进行业务的交易。**组织 R2 有一个客户端应用可以在通道 C1 和 C2 中进行类似的工作。组织 R3 可以在通道 C2 中做这样的工作。
  - 节点 P1 维护了 C1 的账本 L1 的副本。节点 P2 维护了 C1 的账本 L1 和 C2 的账本 L2 的副本。节点 P3 维护了 C2 的账本 L2 的副本。
  - 这个网络是根据在网络配置 NC4 中指定的规则来进行管理的，整个网络由组织 R1 和 R4 管理。通道 C1 是根据在通道配置 CC1 中指定的规则来管理的，这个通道由组织 R1 和 R2 管理。通道 C2 是根据在通道配置 CC2 中指定的规则来管理的，这个通道由组织 R2 和 R3 管理
  - 这有一个排序服务 O4 作为这个网络 N 的一个网络管理员节点，并且使用系统通道。排序服务同时也支持应用通道 C1 和 C2，来对交易进行排序、加入区块然后分发。每个组织都有一个首选的 CA。
- ###创建网络
  - 在我们的示例网络 N 中，排序服务 O4 由一个单独的节点组成，是根据一个网络配置 NC4 来进行配置的。在网络层面上，证书颁发机构 CA4 被用来向管理员和组织 R4 的网络节点分配身份信息。*
    证书颁发机构：CA4，它会被用来给管理者和网络节点颁发证书
    CA4 在我们的网络中扮演着重要的角色，因为它会分配 X.509 证书，这个证书能够用来识别属于组织 R4 的组件。由 CA 颁发的证书也可以用来为交易提供签名，来表明一个组织对交易的结果进行背书，背书是一笔交易可以被接受并记录到账本上的前提条件。
  - 可添加网络管理员
    
    尽管排序节点 O4 是运行在 R4 的基础设施上的，如果 R1 能够访问到的话就可以共享管理的权限。也就是说 R1 或者 R4 可以更新这个网络配置 NC4 来允许组织 R2 进行网络维护中的部分功能。通过这种方式，尽管 R4 运行着排序服务，但是 R1 在其中也具有着全部的管理员权限，R2 具有有限的创建新联盟的权限。排序服务通常是多节点的，也可以被配置为在不同组织中的不同节点上。比如，我们可能会在 R4 中运行 O4 并连接到 O2，O2 是在组织 R1 中的另一个排序节点。通过这种方式，我们就有了一个多节点、多组织的管理结构。
  - 定义联盟
    
    络管理员定义了一个包含两个成员的联盟 X1，包含组织 R1 和 R2。这个联盟的定义被存储在了网络配置 NC4 中，会在接下来的网络开发中被使用。CA1 和 CA2 是这两个组织对应的证书颁发机构。*
    由于 NC4 的配置方式，只有 R1 和 R4 能够创建新的联盟。这个图标显示了一个新的联盟 X1，它定义了 R1 和 R2 是它的联盟组织。我们也看到了 CA2 也被添加进来标识来自 R2 的用户。注意一个联盟可以包含任意数量的组织，这里我们仅包含了两个组织作为一个最简单的配置。
    我们能够看到联盟定义了网络中的一部分组织，他们共享了彼此能够交易的需求，在这个示例中就是 R1 和 R2 能够进行交易。这对于一组有着共同的目标的组织来说是有意义的。
  - 为联盟创建通道
    - 使用联盟 X1 为 R1 和 R2 创建的的通道 C1。这个通道通过通道配置 CC1 来进行管理，完全独立于网络配置。CC1 是由 R1 和 R2 管理的，他们在 C1 上具有同等的权利。R4 在 CC1 中是没有任何权利的。
    - 尽管 C1 是网络 N 中的一部分，它还是跟这个网络非常不同的。同时也要注意到组织 R3 和 R4 并没有在这个通道中，因为这个通道仅仅是为了处理在 R1 和 R2 之间进行的交易的。在上一步中，我们看到了 R4 是如何能够为 R1 分配权限来创建新的联盟。R4 同样也允许 R1 来创建通道。在这个图中，组织 R1 和 R4 创建了通道 C1。再次强调，一个通道可以包含任意数量的组织，但是我们目前只包含了两个组织，这是一个最简单的配置。
    - cc1是通道规则，只有被添加到cc1的用户才能跟c1通道交互
    - 一旦通道创建，只有通道配置指定组织才能控制。NC4任何改动不会对CC1造成影响。比如如果联盟定义 X1 被改动了，它不会影响通道 C1 的成员
  - 节点和账本
    
    一个 Peer 节点 P1 加入了通道 C1。物理上 P1 会存储账本 L1 的副本。P1 和 O4 可以使用通道 C1 来进行通信。
    - Peer 节点是存储区块链账本副本的网络组件
      P1 的配置中一个关键部分就是一个由 CA1 颁发的 X.509 身份信息，它将 P1 和组织 R1 关联了起来。当 P1 启动之后，它就可以使用排序 O4 加入通道C1。当 O4 收到这个加入请求，它会使用通道配置 CC1 来决定 P1 在这个通道中的权限。比如，CC1 决定 P1 是否能够向账本 L1 中读取或写入信息。
  - 应用程序和智能合约链码
    
    智能合约 S5 被安装在了 P1 上。在组织 R1 中的客户端应用 A1 可以通过 Peer 节点 P1 使用 S5 来访问账本。A1、P1 和 O4 都加入了通道 C1，他们都可以使用由这个通道提供的通信设施。
    - 在我们的例子中，客户端应用 A1 是跟组织 R1 相关联的，尽管它处在 Fabric 区块链网络的外边，但它是可以通过通道 C1 跟网络相连的。
    - 客户端应用 A1 需要通过智能合约 S5 来获得账本 L1。
    - 把智能合约想象为管理交易，链码则管理着智能合约应该如何被打包部署
    - 定义链码
      链码会被安装在组织的 Peer 节点上，一个组织必须要批准一个链码定义，才能使用已经安装的智能合约来查询账本和为交易背书。
    - 背书策略
    - 调用智能合约
  - 完成网络
    
    这个网络通过增加新组织 R2 的基础设施变得更大了。具体来说，R2 添加了 Peer 节点 P2，它会存有账本 L1 的一个副本，和链码 S5。R2 像 R1 一样批准了相同的链码定义。P2 也加入了通道 C1，也有一个客户端应用 A2。A2 和 P2 使用由 CA2 颁发的证书来标识 A2 和 P2。所有这些都说明了 A1 和 A2 能够使用 Peer 节点 P1 或者 P2 来调用在 C1 上的 S5
  - peer节点类型
    - 类型
      - *提交节点*。通道中的每个 Peer 节点都是一个提交节点。他们会接收生成的区块，在这些区块被验证之后会以附加的方式提交到 Peer 节点的账本副本中。
      - *背书节点*。每个安装了智能合约的 Peer 节点都*可以*作为一个背书节点。然而，想要*成为*一个真正的背书节点，节点上的智能合约必须要被客户端应用使用，来生成一个被签名的交易响应。
    - 角色
      - 主节点：当组织在通道中具有多个 Peer 节点的时候，会有一个主节点，它负责将交易从排序节点分发到该组织中其他的提节点
        
        静态选择的主节点：0个或者多个节点可以被配置为主节点
        
        动态选举的主节点：个节点会被选举成为主节点，如果一个主节点出错了，那么剩下的节点将会重新选举一个主节点。
      - 锚节点：跨组织通信
    - 只有一个通道，也就只有一个跟这个通道组件交互的逻辑账本。Peer 节点 P1 和 P2 具有相同的账本 L1 的副本
  - 排序服务
    一个从应用程序搜集背书过的交易的组件，然后它会把这些交易进行排序并放进区块中，这些区块会被分发到通道中的每个 Peer 节点。在每个这样的提交节点中，交易不管是有效的还是无效的都会被记录下来，并且他们本地账本副本也会更新。
  - 去中心化的交易分发：多排序点
  - 修改策略
  - 网络完全形成
    
    在这个图中，我们看到了这个 Fabric 区块链网络包括了两个应用程序通道以及一个排序通道。组织 R1 和 R4 负责排序通道，R1 和 R2 负责蓝色的应用程序通道，R2 和 R3 负责红色的应用程序通道。客户端应用程序 A1 是组织 R1 的元素，CA1 是它的证书颁发机构。注意到组织 R2 的节点 P2 可以使用蓝色的通信设施，也可以使用红色的应用程序通道。每个应用程序通道具有它自己的通道配置，这里是 CC1 和 CC2。系统通道的通道配置是网络配置 NC4 的一部分。
- 身份：每一个参与者（网络内部或外部能够使用服务的活动元素）都具有封装在 X.509 数字证书中的数字身份*确定了对资源的确切权限以及对参与者在区块链网络中拥有的信息的访问权限。
  - 主体
  - 身份可以被验证，它必须来自可信任的权威机构。成员服务提供者（Membership Service Provider，MSP）是 Fabirc 中可以信任的权威机构。一个 MSP 是定义管理该组织有效身份规则的组件。Fabric 中默认的 MSP 实现使用 X.509 证书作为身份，采用传统的公钥基础结构（Public Key Infrastructure,PKI）分层模型（稍后将详细介绍PKI）
- PKI 和 MSP 以相同的方式协同工作，PKI提供身份列表，MSP说哪些是参与网络的给定组织的成员
  - PKI 就像一个卡片提供商，它分配了许多不同类型的可验证身份，是一组互联网技术，可在网络中提供安全通信
    
    公钥基础结构（PKI）的元素。PKI 由向各方（例如，服务的用户，服务提供者）发布数字证书的证书授权中心组成，然后使用它们在与其环境交换的消息中对自己进行身份验证。CA 的证书撤销列表（CRL）构成不再有效的证书的参考。证书的撤销可能由于多种原因而发生。例如，因为与证书相关联的加密私有材料已被公开，所以证书可能被撤销。
    - 数字证书，例如X.509
    - 公钥和私钥
      - 传统的身份验证机制依赖于数字签名
      - 从技术上讲，数字签名机制要求每一方保存两个加密连接的密钥：广泛可用的公钥和充当授权锚的私钥，以及用于在消息上产生数字签名的私钥。数字签名消息的接收者可以通过检查附加签名在预期发送者的公钥下是否有效来验证接收消息的来源和完整性。
    - 证书授权中心CA
      - 根 CA，中间 CA 和信任链
        CA 有两种形式：根 CA和中间 CA 。因为根 CA（Symantec，Geotrust等）必须安全地向互联网用户颁发数亿个证书，所以将这个过程分散到所谓的中间 CA 中是很有用的。这些中间 CA 具有由根 CA 或其他中间 CA 颁发的证书，允许为链中的任何 CA 颁发的任何证书建立“信任链”。追溯到根 CA 的能力不仅让 CA 的功能在仍然提供安全性的同时进行扩展（允许使用证书的组织充满信心地使用中间 CA），还限制了根 CA 的暴露，如果根 CA 受到损害，将会危及整个信任链。另一方面，如果中间 CA 受到损害，则曝光量会小得多。
      - Fabric CA：Fabric 提供了一个内置的 CA 组件，允许在你的区块链网络中创建 CA
    - 证书撤销列表
      使用 CRL 检查证书是否仍然有效。如果模仿者试图将无效的数字证书传递给验证者，则可以首先检查颁发证书的 CA 的 CRL，以确保其未被列为无效
  - MSP 类似于商店接受的卡提供商列表，确定哪些身份是商店支付网络的可信成员（参与者）。MSP 将可验证的身份转变为区块链网络的成员。
    
    身份类似于你的信用卡，用来证明你可以支付。MSP类似于接受的信用卡列表。
  - MSP域
    - 在参与者节点本地（本地 MSP）
      - 为客户端和节点定义，让用户在其交易中验证自己作为一个通道的成员(例如在链码交易中)，或作为系统中特定角色的所有者(例如在配置交易中组织管理员)。
      - 每个节点都必须定义一个本地MSP，因为它定义了在该级别上谁拥有管理或参与权限，组织、组织的管理员、节点的管理员以及节点本身都应该具有相同的信任根
      - 排序节点也有，用来验证参与者、节点
    - 在通道配置中（通道 MSP）：定义通道层面的管理权和参与权
      
      频道配置的片段。json文件，其中包括两个组织MSPs。
      - 通道MSPs确定谁在通道级别具有权限。通道MSP定义了通道成员，通道MSP也会在通道中每个节点的文件系统上实例化，并通过协商一致保持同步
      - 本地MSPs仅在其所应用的节点或用户的文件系统上定义
      - 每个节点的本地文件系统上都有每个通道MSP的副本，本地MSPs和通道MSPs在网络中如何共存:
      - 证书中的OU字段指定标识所属的业务部门。
        
        在证书中如何表示角色和ou：
        
        node ou
        在上面的例子中，MSP有4种可能的节点OU角色:：客户端、同行、管理、开证申请人
        
        注：对于通道MSPs，仅仅因为参与者具有管理员角色，并不意味着他们可以管理特定的资源。给定标识在管理系统方面的实际能力由管理系统资源的策略决定
        
        联盟中的不同组织可以使用ou来区分彼此。但是在这种情况下，不同的组织必须为其信任链使用相同的根ca和中间ca，并分配OU字段来标识每个组织的成员。当每个组织都拥有相同的CA或信任链时，这使得系统比预期的更加集中
      - 本地MSP文件夹包含以下子文件夹:
        
        config.yaml:通过激活”Node OUs“节点、定义可接受角色，在Fabric中配置身份分类特性
        
        cacerts：此文件夹包含由此MSP所代表的组织所信任的根ca的自签名X.509证书的列表。此MSP文件夹中必须至少有一个根CA证书。这是最重要的文件夹，因为它标识了ca，所有其他证书都必须从这些ca派生出来，才能被认为是相应组织的成员，以形成信任链。
        
        intermediatecerts：此文件夹包含由该组织信任的中间ca的X.509证书的列表。每个证书必须由MSP中的一个根CA或任何中间CA签名，其颁发的CA链最终会返回受信任的根CA，中间的ca可以用来表示组织的细分
        
        请注意，可能有一个没有中间CA的正常运行的网络，在这种情况下，此文件夹将为空。
        
        与根CA文件夹一样，此文件夹定义了必须从哪个CA颁发证书才能被视为组织成员的CA
        
        admincerts (Deprecated from Fabric v1.4.3 and higher):此文件夹包含一个身份列表，用于定义具有该组织管理员角色的参与者。一般来说，应该有一个或多个X.509证书。建议在用户向CA注册时，使用admin角色指定节点管理员。然后，通过其signcert中的Node OU角色值将该标识识别为admin。提醒一下，为了利用管理角色，必须在配置中启用“身份分类”特性。通过设置“节点ou”为Enable: true
        
        keystore: (private Key)：此文件夹是为对等节点或订单节点的本地MSP定义的(或在客户机的本地MSP中定义的)MSP)，包含节点的私钥。此键用于签名数据
        
        通道MSP配置不包括这个文件夹，因为通道MSP仅旨在提供身份验证功能，而不是签名功能
        
        如果您使用HSM (Hardware Security Module)进行密钥管理，则此文件夹为空，因为私钥是由HSM生成并存储在HSM中
        
        signcert：包含节点的CA颁发的证书,可用于生成一个被有此证书副本的任何人验证的签名，此文件夹对于本地MSPs是必需的，并且必须包含一个公钥。
        
        必须将此文件夹的访问权限限制在对对等端负有管理责任的用户的身份上。
        
        通道MSP的配置不包括此文件夹，因为通道MSP仅旨在提供身份验证功能，而不是签名功能
        
        tlscacerts: 此文件夹包含该组织信任的根ca的自签名X.509证书列表，用于使用TLS在节点之间进行安全通信。MSP TLS信息涉及网络内部的节点
        
        tlsintermediatecacerts: 此文件夹包含中间CA证书列表，这些CA证书由MSP所代表的组织信任，用于使用TLS在节点之间进行安全通信。
        
        operationscerts:此文件夹包含与Fabric Operations Service API通信所需的证书
      - 通道MSP额外包含：
        
        Revoked Certificates:如果行为人的身份已被撤销，则有关该身份的识别信息-而不是身份本身-保存在此文件夹中。对于基于x .509的标识，这些标识符是一对对字符串，称为主题密钥标识符(SKI)和权限访问标识符(AKI)，每当使用证书时，都会检查这些标识符，以确保证书没有被吊销
- 策略：
  - 系统通道配置：每个网络都从排序服务系统通道开始。网络中必须有至少一个排序服务的排序系统通道，它是第一个被创建的通道。该通道也包含着谁是排序服务（排序服务组织）以及在网络中交易（联盟组织）的成员。排序系统通道配置区块中的策略治理着排序服务使用的共识，并定义了新区块如何被创建。系统通道也治理着联盟中的哪些成员可以创建新通道。
  - 应用通道配置：应用通道用于向联盟中的组织间提供私有通信机制。应用通道中的策略治理着从通道中添加和删除成员的能力。应用通道也治理着使用 Fabric 链码生命周期在链码定义和提交到通道前需要哪些组织同意。当系统通道初始创建时，它默认继承了排序系统通道的所有排序服务参数。同时，这些参数（包括治理它们的策略）可以被每个通道自定义。
  - 权限控制列表（ACL）
  - 策略作用域
  - 智能合约背书策略
  - 更新策略
  - 如何在fabric里写策略
    - 签字策略：支持排序和多种逻辑关系
    - ImplicitMeta策略：基于分级构造的策略树的通道配置中有效
      - 隐元策略聚合了由签名策略最终定义的配置树深层的结果。它们是隐藏的，因为它们基于通道配置中的当前组织隐式构建，它们是元信息，因为它们的评测不依赖于特定 MSP 规范，而是依赖于配置树中它们的其他子策略。
      - 符合开闭原则
      - NodeOUs 进一步粒度和控制
    - 签名策略使用实例
    - implimeta使用实例
    - 生命周期
- 节点:维护账本和链码
  
  在 Fabric 网络中故意提供了冗余，因为这样可以避免单点失效
  - 区块链网络是由 Peer 节点组成的，每个节点都保存着账本和智能合约的副本。在这个例子中，网络 N 是由节点 P1、P2 和 P3 组成的，每个节点都维护这他们自己的分布式账本 L1。P1、P2 和 P3 使用相同的链码 S1 来访问他们的分布式账本的副本。可以多账本维护，多链码维护
  - 应用程序和 Peer 节点：当应用程序需要访问账本和链码的时候，他们总是需要连接到 Peer 节点，通过连接 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 节点以及应用程序来彼此交互。在这个例子中，应用程序 A 能够直接同 Peer 节点 P1 和 P2 使用通道 C 进行沟通。你可以把通道想象为在某些应用程序和 Peer 节点之间进行通信的小路。（排序节点没有显示在这个图中，但是在工作网络中它必须存在。）
  - Peer 节点和组织：这里没有中心化的资源，如果这些组织不贡献他们的节点的话，网络 N 是不会存在的，除非并且直到组织贡献了他们的资源才会形成这样一个网络，否则这个网络没有存在的意义
  - Peer 节点和身份：在网络中的每个 Peer 节点都会被所属组织的管理员分配一个数字证书
    当 Peer 节点连接到一个通道的时候，它的数字证书会通过通道 MSP 来识别它的所属组织。在这个例子中，P1 和 P2 具有由 CA1 颁发的身份信息。通道 C 通过在它的通道配置中的策略来决定来自 CA1 的身份信息应该使用 ORG1.MSP 被关联到 Org1。类似的，P3 和 P4 由 ORG2.MSP 识别为 Org2 的一部分。
  - Peer 节点和排序节点：更新账本的应用程序会被引入到一个三阶段的流程
    - 在第一个阶段，应用程序会跟背书节点的子集一起工作，其中的每个节点都会向应用程序为提案的账本更新提供背书，但是不会将提案的更新应用到他们的账本副本上。
    - 在第二个阶段，这些分散的背书会被搜集到一起当做交易被打包进区块中。
    - 在最后一个阶段，这些区块会被分发回每个 Peer 节点，在这些 Peer 节点上每笔交易在被应用到 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 节点。在这个例子中，排序节点 O1 将区块 B2 分发给了 Peer 节点 P1 和 Peer 节点 P2。Peer P1 处理了区块 B2，产生了一个会被添加到 P1 的账本 L1 中的新区块。同时，peer P2 处理了区块 B2，产生了一个会被添加到 P2 的账本 L1 中的新区块。当这个过程结束之后，账本 L1 就会被一致地更新到了 Peer 节点 P1 和 P2 上，他们也可能会通知所连接的应用程序关于这笔交易已经被处理过的消息。
      - 链码只在第一阶段执行——保证隐秘性，但输出分享给所有节点
    - 排序节点和共识：整个交易处理流程被称为共识
- 账本：存储了有关业务对象的重要事实信息，其中既包括对象属性的当前值，也包括产生这些当前值的交易的历史
  - 账本、事实和状态：
    - 账本：
      - 世界状态是一个数据库，它存储了一组账本状态的当前值。通过世界状态，程序可以直接访问一个账本状态的当前值，不需要遍历整个交易日志来计算当前值。默认情况下，账本状态是以键值对的方式来表示的，可以创建、更新和删除状态，所以世界状态能够频繁更改。
      - 区块链是交易日志，记录了促成当前世界状态的所有改变。能帮助我们理解所有促成当前世界状态的改变的历史，不可篡改。
        
        账本 L 由区块链 B 和世界状态 W 组成，其中世界状态 W 由区块链 B 决定。我们也可以说世界状态 W 是源自区块链 B。
    - 世界状态：只有那些受到相关背书组织签名的交易才会更新世界状态，实时变更性。
      
      一个账本世界状态包含两个状态。第一个状态是： key=CAR1 和 value=Audi。第二个状态中有一个更复杂的值：key=CAR2 和 value={model:BMW, color=red, owner=Jane} 。两个状态的版本都是0。
    - 区块链：一群相互链接的区块的序列化日志，其中每个区块都包含一系列交易，各项交易代表了一个对世界状态进行的查询或更新操作。每个区块的头部都包含区块交易的一个哈希，以及前一个区块头的哈希。本上的所有交易都被按序排列，并以密码方式连接在一起。这种哈希和链接使账本数据变得非常安全。
      
      区块链 B 包含了 B0、B1、B2、B3这四个区块。B0 是该区块链的第一个区块，也叫创世区块。
      在上面的图中我们可以看到，区块 B2 有一个区块数据 D2，该数据包含了 B2 的所有交易：T5、T6、T7。
    - 区块
      - 区块头
        
        区块头详情：区块 B2 的区块头 H2 包含了区块编号 2，当前区块数据 D2 的哈希值 CH2，以及前一个区块头 H1 的哈希值。
      - 区块编号：编号从0（初始区块）开始，每在区块链上增加一个新区块，编号的数字都会加1。
      - 当前区块的哈希值：当前区块中包含的所有交易的哈希值。
      - 前一个区块头的哈希值：区块链中前一个区块头的哈希值。
      - 区块数据这部分包含了一个有序的交易列表。区块数据是在排序服务创建区块时被写入的。
      - 区块元数据这个部分包含了区块被写入的时间，还有区块写入者的证书、公钥以及签名。随后，区块的提交者也会为每一笔交易添加一个有效或无效的标记，但由于这一信息与区块同时产生，所以它不会被包含在哈希中。
    - 交易：交易记录了世界状态发生的更新，存储在区块内的区块数据中
      
      交易 T4 位于区块 B1 的区块数据 D1 中，T4包括的内容如下：交易头 H4，一个交易签名 S4，一个交易提案 P4，一个交易响应 R4 和一系列背书 E4。
      - 头这部分用 H4 表示，它记录了关于交易的一些重要元数据，比如，相关链码的名字以及版本。
      - 签名这部分用 S4 表示，它包含了一个由客户端应用程序创建的加密签名。该字段是用来检查交易细节是否未经篡改，因为交易签名的生成需要用到应用程序的私钥。
      - 提案这部分用 P4 表示，它负责对应用程序供给智能合约的输入参数进行编码，随后该智能合约生成提案账本更新。在智能合约运行时，这个提案提供了一套输入参数，这些参数同当前的世界状态一起决定了新的账本世界状态。
      - 响应这部分用 R4 表示，它是以读写集（RW-set）的形式记录下世界状态之前和之后的值。交易响应是智能合约的输出，如果交易验证成功，那么该交易会被应用到账本上，从而更新世界状态。
      - 背书 E4 显示的那样，它指的是一组签名交易响应，这些签名都来自背书策略规定的相关组织，并且这些组织的数量必须满足背书策略的要求
    - 世界状态数据库选项：包括 LevelDB 和 CouchDB ——可插拔
      - LevelDB 是世界状态数据库的默认选项，当账本状态是简单的键值对时，使用 LevelDB 非常合适。LevelDB 数据库与 peer 节点位于相同位置，它被嵌入与 peer 节点相同的操作系统进程中。
      - CouchDB ：账本状态结构为 JSON 文档，业务交易涉及的数据类型通常十分丰富，而 CouchDB 可支持对这些数据类型进行各种形式的查询和更新。在实现方面，CouchDB 是在单独的操作系统进程中运行的，但是节点和 CouchDB 实例之间仍然存在1:1的关系。智能合约无法看到上述任何内容。
    - 示例账本fabcar
      
      账本 L包含了一个世界状态 W 和一个区块链 B。其中 W 包含了四个状态，各状态的键分别是：CAR0，CAR1，CAR2 和 CAR3 。而 B 包含了两个区块 0和 1。区块1包含了四笔交易：T1，T2，T3，T4。
    - 命名空间
      - 每个链码都有自己的世界状态，并且与所有其他链码的世界状态分离。世界状态位于一个命名空间中，因此只有位于同一链码中的智能合约才能访问一个给定的命名空间。
    - 通道：每个通道都有一个完全独立的账本
- 排序服务
  - 排序节点和通道配置：排序节点还维护着允许创建通道的组织列表——联盟。表本身保存在“排序节点系统通道”（也称为“排序系统通道”）的配置中，此列表及其所在的通道只能由排序节点管理员编辑
  - 排序节点和身份（MSP）：排序节点属于组织，为每个组织使用单独的证书授权中心（CA），至于何种CA自定
  - 排序节点和交易流程
    - 阶段一：提案
    - 阶段二：将交易排序并打包到区块中
      
      排序节点的第一个角色是打包提案的账本更新。在本例中，应用程序 A1 向排序节点 O1 发送由 E1 和 E2 背书的交易 T1。同时，应用程序 A2 将 E1 背书的交易 T2 发送给排序节点 O1。O1 将来自应用程序 A1 的交易 T1 和来自应用程序 A2 的交易 T2 以及来自网络中其他应用程序的交易打包到区块 B2 中。我们可以看到，在 B2 中，交易顺序是 T1、T2、T3、T4、T6、T5，但这可能不是这些交易到达排序节点的顺序！（这个例子显示了一个非常简单的排序服务配置，只有一个排序节点。）
      - 区块中的交易数量取决于区块的期望大小和最大间隔时间相关的通道配置参数（确切地说，是 BatchSize 和 BatchTimeout 参数）
      - 由排序服务生成的区块是最终的，Hyperledger Fabric 的最终性意味着没有账本分叉，也就是说，经过验证的交易永远不会被重写或删除。
      - 排序节点只排序，不发生交易
    - 阶段三：验证和提交：不是每个 Peer 节点都需要连接到一个排序节点，Peer 节点可以使用 gossip 协议将区块关联到其他节点
      
      排序节点的第二个角色是将区块分发给 Peer 节点。在本例中，排序节点 O1 将区块 B2 分配给节点 P1 和 P2。节点 P1 处理区块 B2，在 P1 上的账本 L1 中添加一个新区块。同时，节点 P2 处理区块 B2，从而将一个新区块添加到 P2 上的账本 L1中。一旦这个过程完成，节点 P1 和 P2 上的账本 L1 就会保持一致的更新，并且每个节点都可以通知与之连接的应用程序交易已经被处理。
      - 节点的背书和背书策略相匹配，并且不会因最初认可该事务时可能正在运行的其他最近提交的事务而失效。无效的交易仍然保留在排序节点创建的区块中，但是节点将它们标记为无效，并且不更新账本的状态。
    - 排序服务实现
      - Raft (推荐)：作为 v1.4.1 的新特性，Raft 是一种基于 [etcd](https://coreos.com/etcd/) 中 Raft 协议实现的崩溃容错（Crash Fault Tolerant，CFT）排序服务。Raft 遵循“领导者跟随者”模型，这个模型中，在每个通道上选举领导者节点，其决策被跟随者复制。Raft 排序服务会比基于 Kafka 的排序服务更容易设置和管理，它的设计允许不同的组织为分布式排序服务贡献节点。
        
        崩溃容错：系统可以承受节点的损失，包括领导者节点，前提是要剩余大量的排序节点（称为“法定人数（quorum）”）
        
        Raft 更容易设置，原生支持，使用 Raft，所有内容都会嵌入到您的排序节点中。
        
        Kafka 和 Zookeeper 并不是为了在大型网络上运行，需要自己获取所需镜像，Kafka使用服务器池
        
        Raft 概念
        
        日志条目（Log entry）：Raft 排序服务中的主要工作单元是一个“日志条目”，该项的完整序列称为“日志”。如果大多数成员（换句话说是一个法定人数）同意条目及其顺序，则我们认为条目是一致的，然后将日志复制到不同排序节点上
        
        共识者集合（Consenter set）：主动参与给定通道的共识机制并接收该通道的日志副本的排序节点。
        
        有限状态机（Finite-State Machine，FSM）。Raft 中的每个排序节点都有一个 FSM，它们共同用于确保各个排序节点中的日志序列是确定（以相同的顺序编写）。
        
        法定人数（Quorum）。描述需要确认提案的最小同意人数。
        
        领导者（Leader）
        
        跟随者（Follower）
        
        交易流程中的 Raft：通道创建者（和通道管理员）能够选择可用排序节点的子集，并根据需要添加或删除排序节点（只要一次只添加或删除一个节点）。eer 节点和应用程序在任何特定时间都不需要知道谁是领导者节点。只有排序节点需要知道。
        
        Raft 是如何选举领导者的：节点总是处于以下三种状态之一：跟随者、候选人或领导者。所有节点最初都是作为跟随者开始的。在这种状态下，他们可以接受来自领导者的日志条目（如果其中一个已经当选），或者为领导者投票。如果在一段时间内没有接收到日志条目或心跳（例如，5秒），节点将自己提升到候选状态。在候选状态中，节点从其他节点请求选票。如果候选人获得法定人数的选票，那么他就被提升为领导者。领导者必须接受新的日志条目并将其复制到跟随者。
        
        快照：，Raft 使用了一个称为“快照”的过程，在这个过程中，用户可以定义日志中要保留多少字节的数据。这个数据量将决定区块的数量（这取决于区块中的数据量。注意，快照中只存储完整的区块）。
        假设滞后副本 R1 刚刚重新连接到网络。它最新的区块是100。领导者 L 位于第 196 块，并被配置为快照20个区块。R1 因此将从 L 接收区块 180，然后为区块 101 到 180 区块分发请求。然后180 到 196 的区块将通过正常 Raft 协议复制到 R1。
      - Kafka (在 v2.0 中被弃用)：和基于 Raft 的排序类似，Apache Kafka 是一个 CFT 的实现，它使用“领导者和跟随者”节点配置。Kafka 利用一个 ZooKeeper 进行管理。基于 Kafka 的排序服务从 Fabric v1.0 开始就可以使用，但许多用户可能会发现管理 Kafka 集群的额外管理开销令人生畏或不受欢迎。
      - Solo (在 v2.0 中被弃用)：排序服务的 Solo 实现仅仅是为了测试，并且只包含了一个单一的排序节点。它已经被弃用了，可能会在将来的版本中被完全移除。既存的 Solo 用户应该迁移到一个单一节点的 Raft 网络获得同样的功能。
- 智能合约和链码
  - 智能合约
    
    智能合约用可执行的代码定义了不同组织之间的规则。应用程序调用智能合约来生成被记录到账本上的交易。
  - 智能合约定义的是控制世界状态中业务对象生命周期的交易逻辑，随后该交易逻辑被打包进链码，紧接着链码会被部署到区块链网络中。可以将智能合约看成交易的管理者，而链码则管理着如何将智能合约打包以便用于部署
    
    一个智能合约定义在一个链码中。而多个智能合约也可以定义在同一个链码中。当一个链码部署完毕，该链码中的所有智能合约都可供应用程序使用。
  - 账本：智能合约主要在世界状态中将状态写入（put）、读取（get）和删除（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)));}
  - 背书:指明了区块链网络中哪些组织必须对一个给定的智能合约所生成的交易进行签名，以此来宣布该交易有效
    
    每个智能合约都有一个与之关联的背书策略。这个背书策略定义了在智能合约生成的交易被认证为有效之前，哪些组织必须同意该交易。
    - 参与区块链网络的四个组织中有三个必须在交易被认为有效之前签署该交易。所有的交易，无论是有效的还是无效的，都会被添加到分布式账本中，但只有有效交易会更新世界状态。
  - 有效交易
    - 智能合约提取一组名为交易提案的输入参数，并将其与程序逻辑结合起来使用以读写账本.对世界状态的更改被捕获为交易提案响应（或简称交易响应），该响应包含一个读写集，其中既含有已读取的状态，也含有还未书写的新状态（如果交易有效的话）
    - 在执行智能合约时世界状态没有更新
      
      所有的交易都有一个识别符、一个提案和一个被一群组织签名的响应。所有交易，无论是否有效，都会被记录在区块链上，但仅有效交易会更新世界状态。
    - 一项交易被分发给网络中的所有节点，各节点通过两个阶段对其进行验证。
      - 首先，根据背书策略检查交易，确保该交易已被足够的组织签署。
      - 其次，继续检查交易，以确保当该交易在受到背书节点签名时它的交易读集与世界状态的当前值匹配，并且中间过程中没有被更新。如果一个交易通过了这两个测试，它就被标记为有效。
  - 通道
    
    通道在一群组织之间提供了一种完全独立的通信机制。当链码定义被提交到通道上时，该通道上所有的应用程序都可以使用此链码中的智能合约。
    - 智能合约代码被安装在组织节点的链码包内，但是只有等到链码被定义在通道上之后，该通道上的成员才能够执行其中的智能合约
  - 互通:一个智能合约既可以调用同通道上的其他智能合约，也可以调用其他通道上的智能合约。这样一来，智能合约就可以读写原本因为智能合约命名空间而无法访问的世界状态数据
  - 系统链码
    - 生命周期系统链码（LSCC）
    - 配置系统链码（CSCC）
    - 查询系统链码（QSCC）
    - 背书系统链码（ESCC）
    - 验证系统链码（VSCC）
  - 链码生命周期——channel上的定义
    - 通道成员通过以下步骤达成一致，不是channel中的每个组织都需要完成：
      - 打包链码
      - 在peers上安装链码
      - 在组织中批准一个链码定义
      - 将链码运用到通道
    - 第一阶段：打包智能合约
      
      ·链代码需要打包在tar文件中，以.tar.gz文件扩展名结束。
      •tar文件需要包含两个文件(无目录):元数据文件“metadata”。Json”和另一个tar“code.tar.gz”包含chaincode文件。
      元数据。包含指定链码语言、代码路径和包标签的json。你可以看到一个元数据文件的例子如下:
      该链码由Org1和Org2分别包装。这两个组织都使用MYCC_1作为它们的包标签，以便使用名称和版本标识包。组织没有必要使用相同的包装标签
    - 第二阶段：在peers上安装链码
      
      来自Org1和Org2的对等体管理员将链码包MYCC_1安装到连接到通道的对等体上。
      安装chaincode包将构建chaincode并创建一个MYCC_1:hash的包标识符。
    - 第三阶段：在组织中批准链码定义
      - 组织批准过程相当于接纳投票，通道成员允许运用后可以用，涉及到以下需要在组织之间保持一致的参数(Package Identifier)不用一致
        
        name
        
        version
        
        sequence
        
        endorsement policy
        
        collection configuration
        
        ESCC/VSCC plugins
        
        Initialization:如果您使用Fabric Chaincode Shim API提供的低级API，那么您的Chaincode需要包含用于初始化Chaincode的Init函数
      - 来自Org1和Org2的组织管理员批准其组织MYCC的链码定义。
        链码定义包括链码名称、版本和背书策略等字段。由于两个组织都将使用chaincode来支持交易，因此两个组织的核准定义都需要包含packageID。
    - 第四阶段：有足够数量的渠道成员批准了链码定义即可将chaincode定义提交到通道，先发给通道成员peers,peers核实批准的链码定义，并背书，递交给排序服务，然后再返回给通道
      
      来自Org1或Org2的组织管理员将链码定义提交到通道。通道上的定义不包括packageID。
      - 组织可以在不安装链码包的情况下批准链码定义
      - 一旦在通道上定义了MYCC, Org1和Org2就可以开始使用chaincode。第一次调用链码在每个peer上启动该链码容器。
  - 更新链码：链码可以更新背书单，提交给通道即生效，不必特意调用
    - 重新包装链码
    - 在节点上安装新链码包
    - 批准一个新链码定义
    - 把定义提交到通道
- 私有数据
  - 私有数据集合：
    - 实际的私有数据：gossip协议点对点发给能看到的组织，其他都看不到
    - 数据的哈希值：公开的部分，背书排序后写入账本
  - 关于用一个单独通道还是现有通道内的私有数据集合：
    - 通道：整个账本需要保密
    - 集合：部分
      
      以图为例，不同组织之间的不同保密需求
  - 使用私有数据的交易流
    - 客户端应用程序提交一个提案请求，让属于授权集合的背书节点执行链码函数（读取或写入私有数据）。私有数据，或用于在链码中生成私有数据的数据，被发送到提案的 transient（瞬态）字段中。
    - 背书节点模拟交易，并将私有数据存储在瞬态数据存储（ transient data store ，节点的本地临时存储）中。它们根据组织集合的策略将私有数据通过[gossip]()分发给授权的 Peer 节点。
    - 背书节点将提案响应发送回客户端。提案响应中包含经过背书的读写集，这其中包含了公共数据，还包含任何私有数据键和值的 hash。私有数据不会被发送回客户端。更多关于带有私有数据的背书的信息
    - 客户端应用程序将交易（包含带有私有数据 hash 的提案响应）提交给排序服务。带有私有数据 hash 的交易同样被包含在区块中。带有私有数据 hash 的区块被分发给所有节点。这样，通道中的所有节点就可以在不知道真实私有数据的情况下，用同样的方式来验证带有私有数据 hash 值的交易。
    - 在区块提交的时候，授权节点会根据集合策略来决定它们是否有权访问私有数据。如果节点有访问权，它们会先检查自己的本地瞬态数据存储，以确定它们是否在链码背书的时候已经接收到了私有数据。如果没有的话，它们会尝试从其他已授权节点那里拉取私有数据，然后对照公共区块上的 hash 来验证私有数据并提交交易和区块。
    - 当验证或提交结束后，私有数据会被移动到这些节点私有数据库和私有读写存储的副本中。随后瞬态数据存储中存储的这些私有数据会被删除。
  - 共享私有数据
    - 使用相应的公钥来追踪公共状态，私有同理
    - 通过链码控制客户端是否可以访问私有数据（是否在证书中或者密码是否一致）
    - out of band分享：验证哈希值
    - 和其他集合分享私有数据：链码 GetPrivateDataHash() 验证集合中是否有私有数据，验证成功之后再把你的集合中该数据删除，并在其他组织的集合中生成该键，可能需要额外背书
    - 使用私有数据进行交易审批：在交易完成前获得对方认可，链码让他们有一个预同意或者在他/你的私有数据集合上签私钥，之后用GetPrivateDataHash()检验
    - 使交易者保密：用私有数据的哈希值

hyperledger-fabric documention官方文档

猜你喜欢