Fabric关键概念

Hyperledger Fabric

:::success
Hyperledger Fabric 是一个开源的企业级许可分布式账本技术（Distributed Ledger Technology，DLT）平台，专为在企业环境中使用而设计。
Fabric 具有高度模块化和可配置的架构，可为各行各业的业务提供创新性、多样性和优化，其中包括银行、金融、保险、医疗保健、人力资源、供应链甚至数字音乐分发。
Fabric 是第一个支持通用编程语言编写智能合约（如 Java、Go 和 Node.js）的分布式账本平台，不受限于特定领域语言（Domain-Specific Languages，DSL）。这意味着大多数企业已经拥有开发智能合约所需的技能，并且不需要额外的培训来学习新的语言或特定领域语言。
Fabric 平台也是许可的，这意味着它与公共非许可网络不同，参与者彼此了解而不是匿名的或完全不信任的。
Fabric 支持可插拔的共识协议，使得平台能够更有效地进行定制，以适应特定的业务场景和信任模型。
Fabric 可以利用不需要原生加密货币的共识协议来激励昂贵的挖矿或推动智能合约执行。不使用加密货币会降低系统的风险，并且没有挖矿操作意味着可以使用与任何其他分布式系统大致相同的运营成本来部署平台。
:::

模块化

:::success
Fabric 由以下模块化的组件组成：

• 可插拔的_排序服务_对交易顺序建立共识，然后向节点广播区块；
• 可插拔的_成员服务提供者_负责将网络中的实体与加密身份相关联；
• 可选的_P2P gossip 服务_通过排序服务将区块发送到其他节点；
• 智能合约（“链码”）隔离运行在容器环境（例如 Docker）中。它们可以用标准编程语言编写，但不能直接访问账本状态；
• 账本可以通过配置支持多种 DBMS；
• 可插拔的背书和验证策略，每个应用程序可以独立配置。
  :::

智能合约

Hyperledger Fabric 智能合约用链码编写，当该应用程序需要与账本交互时，由区块链外部的应用程序调用。在大多数情况下，链码只与账本的数据库、世界状态（例如，查询）交互，而不与交易日志交互。\

共识

最近，在分布式账本技术中，共识已成为单个函数内特定算法的同义词。然而，共识不仅包括简单地就交易顺序达成一致，Hyperledger Fabric 通过其在整个交易流程中的基本角色，从提案和背书到排序、验证和提交，突出了这种区别。简而言之，共识被定义为组成区块的一组交易的正确性的闭环验证。
当区块中交易的顺序和结果满足明确的策略标准检查时，最终会达成共识。这些制衡措施是在交易的生命周期内进行的，包括使用背书策略来规定哪些特定成员必须背书某个交易类别，以及使用系统链码来确保这些策略得到执行和维护。在提交之前，节点将使用这些系统链码来确保存在足够的背书，并且它们来自适当的实体。此外，在将包含交易的任何区块附加到账本之前，将进行版本检查，以确保在此期间，账本的当前状态是能与交易中的信息达成共识的。该最终检查可防止双重花费操作和可能危及数据完整性的其他威胁，并允许针对非静态变量执行功能。
除了众多的背书、验证和版本检查外，交易流的各个方向上还会发生持续的身份验证。访问控制列表是在网络的分层上实现的(排序服务到通道)，并且当一个交易提议通过不同的架构组件时，有效负载会被反复签名、验证和认证。总而言之，共识并不仅仅局限于一批交易的商定顺序；相反，它的首要特征是交易从提案到提交的过程中不断进行核查而附带实现的。

策略

从根本上来说，策略是一组规则，用来定义如何做出决策和实现特定结果。为此，策略一般描述了谁和什么，比如一个人对资产访问或者权限。我们可以看到，在我们的日常生活中策略也在保护我们的资产数据，比如汽车租金、健康、我们的房子等。
例如，购买保险时，保险策略定义了条件、项目、限制和期限。该策略经过了策略持有者和保险公司的一致同意，定义了各方的权利和责任。
保险策略用于风险管理，在 Hyperledger Fabric 中，策略是基础设施的管理机制。Fabric 策略表示成员如何同意或者拒绝网络、通道或者智能合约的变更。策略在网络最初配置的时候由联盟成员一致同意，但是在网络演化的过程中可以进行修改。例如，他们定义了从通道中添加或者删除成员的标准，改变区块格式或者指定需要给智能合约背书的组织数量。所有这些定义谁可以干什么的行为都在策略中描述。简单来说，你在 Fabric 网络中的所有想做的事情，都要受到策略的控制

为什么需要策略

策略是使 Hyperledger Fabric 不同于其他区块链系统（比如 Ethereum 或者 Bitcoin）的内容之一。在其他系统中，交易可以在网络中的任意节点生成和验证。治理网络的策略可以在任何时间及时修复，并且只可以使用和治理代码相同的方式进行变更。因为 Fabric 是授权区块链，用户由底层基础设施识别，所以用户可以在启动前决定网络的治理方式，以及改变正在运行的网络的治理方式。
策略决定了那些组织可以访问或者更新 Fabric 网络，并且提供了强制执行这些决策的机制。策略包含了有权访问给定资源的组织列表，比如一个用户或者系统链码。他们同样指定了需要多少组织同意更新资源的提案，比如通道或者智能合约。一旦策略被写入，他们就会评估交易和提案中的签名，并验证签名是否满足网络治理规则。

Fabric链码生命周期

Fabric 2.0 发布版本中，介绍了一个新的链码生命周期过程，这是一个在网络中更民主的治理链码的过程。新的过程允许多个组织在链码应用到通道之前如何操作进行投票。这个很重要，因为这是新生命周期过程和策略的融合，策略是在过程中指定的决定着网络的安全性。新的流程指定策略包含两步，当链码被组织成员批准的时候，以及当它被提交到通道后。\

链码背书策略

当使用 Fabric 链码生命周期链码被批准并提交到通道时会指定一个背书策略（这个背书策略会覆盖与该链码相关的所有状态）。背书策略可以引用通道配置中的背书策略或者明确指定签名策略。
如果在批准阶段没有明确指明背书策略，就默认使用Endorsement策略 “MAJORITYEndorsement”，意味着要想使交易生效就需要大多数不同通道成员（组织）的执行并验证交易。默认策略允许加入通道的组织自动加入链码背书策略。如果你不想使用默认背书策略，你可以使用签名策略格式来指定更复杂的背书策略（这样就需要链码先被通道中的一个组织签名，然后让其他组织签名）。
有一些场景可能需要一些特殊的状态（特殊的键-值对，或这其他的）有不同的背书策略。基于状态的背书可以指定与默认链码级别背书策略不同的键的背书策略。\

Peer节点

区块链网络主要由 Peer 节点（或者简单称之为 Peer）组成。Peer 是网络的基本元素，因为他们存储了账本和智能合约。之前我们说过账本不可篡改地保存着智能合约生成的所有交易（在 Hyperledger Fabric 中智能合约包含在_链码_中，稍后会详细介绍）。智能合约和账本将网络中共享的_流程_和_信息_对应地封装起来。Peer 节点的这些功能使它成为了理解 Fabric 网络很好的起点。
区块链网络中的其他部分当然也非常重要：账本和智能合约、排序节点、策略、通道、应用程序、组织、身份和成员关系等，你可以在其他的文档中了解更多。这个部分会集中在 Peer 节点上，以及他们和 Hyplerledger Fabric 网络中的其他要素的关系。

区块链网络是由 Peer 节点组成的，每个节点都保存着账本和智能合约的副本。在这个例子中，网络 N 是由节点 P1、P2 和 P3 组成的，每个节点都维护这他们自己的分布式账本 L1。P1、P2 和 P3 使用相同的链码 S1 来访问他们的分布式账本的副本。
Peer 节点可以被创建、启动、停止、重新配置甚至删除。他们暴露了一系列的 API，这就可以让管理者和应用程序同这些 API 提供的服务互动。

Peer 节点和通道

这些组件通常是 Peer 节点、排序节点和应用程序，并且通过加入通道的方式，表明他们同意在那个通道中通过互相合作来共享以及管理完全一致的账本副本。概念上来说，你可以把通道想象为类似于一个由朋友组成的群组一样（尽管一个通道中的成员不需要是朋友！）。一个人可能会有很多个群组，在每个群组中他们会共同地进行一些活动。这些群组可能是完全独立的（一个工作伙伴的群组和一个兴趣爱好伙伴的群组），或者群组间可能会有交叉的部分。然而，每个群组都是它自己的实体，具备某种”规则”。

通道允许区块链网络中特定的一些 Peer 节点以及应用程序来彼此交互。在这个例子中，应用程序 A 能够直接同 Peer 节点 P1 和 P2 使用通道 C 进行沟通。你可以把通道想象为在某些应用程序和 Peer 节点之间进行通信的小路。（排序节点没有显示在这个图中，但是在工作网络中它必须存在。

Peer 节点和组织

区块链网络是由多个组织来管理的，而不是单个组织。对于如何构建这种类型的分布式网络，Peer 节点是核心，因为他们是由这些组织所有，也是这些组织同这个网络的连接点。

区块链网络中的 Peer 节点和多个组织。区块链网络是由不同的组织所拥有并贡献的 Peer 节点构成的。在这个例子中，我们看到由四个组织贡献了八个 Peer 节点组成一个网络。在网络 N 中，通道 C 连接了这些 Peer 节点中的五个：P1、P3、P5、P7 和 P8。这些组织拥有的其他节点并没有加入该通道，但是通常会加入至少一个其他通道。某个组织开发的应用程序将会连接到他们自己组织的 Peer 节点，其他组织也一样。为了简化，排序节点没有在这个图中表示出来_。_
真正重要的是，你能够看到在形成一个区块链网络的时候都发生了什么。这个网络是由多个组织来组成并维护的，这些组织向这个网络贡献资源。Peer 节点是我们在这个话题中正在讨论的资源，但是一个组织提供的资源不仅仅是 Peer 节点。这里有一个工作原则：如果组织不为这个网络贡献他们的资源，这个网络是不会存在的。更关键的是，这个网络会随着这些互相合作的组织提供的资源而增长或者萎缩。

Peer 节点和身份

Peer 节点会有一个身份信息被分给他们，这是通过一个特定的证书认证机构颁发的数字证书来实现的。你可以在本指南的其他地方阅读更多的关于 X.509 数字证书是如何工作的，但是，现在，就把数字证书看成是能够为 Peer 节点提供可验证信息的身份证。

当 Peer 节点连接到一个通道的时候，它的数字证书会通过通道 MSP 来识别它的所属组织。在这个例子中，P1 和 P2 具有由 CA1 颁发的身份信息。通道 C 通过在它的通道配置中的策略来决定来自 CA1 的身份信息应该使用 ORG1.MSP 被关联到 Org1。类似的，P3 和 P4 由 ORG2.MSP 识别为 Org2 的一部分。
当 Peer 节点使用通道连接到一个区块链网络的时候，_在通道配置中的策略会使用 Peer 节点的身份信息来确定它的权利。关于身份信息和组织的映射是由_成员服务提供者（MSP）来提供的，它决定了一个 Peer 节点如何在指定的组织中分配到特定的角色以及得到访问区块链资源的相关权限。更多的是，一个 Peer 节点只能被一个组织所有，因此也就只能被关联到一个单独的 MSP。我们会在本部分的后边学习更过关于 Peer 节点的访问控制，并且在本指南中还有关于 MSP 和访问控制策略的部分。目前，可以把 MSP 看作在区块链网络中，为一个独立的身份信息和一个特定的组织角色之间提供了关联。

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。

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

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

阶段3：验证和提交

在第二阶段末尾，我们看到了排序节点需要负责这个简单但是重要的搜集提案的交易变更，将他们排序，并且打包到区块中，让他们准备好分发给 Peer 节点的整个流程。
这个交易流程的最后一个阶段是分发以及接下来的对于从排序节点发送给 Peer 节点的区块的验证工作，这些区块最终会提交到账本中。具体来说，在每个 Peer 节点上，区块中的每笔交易都会被验证，以确保它在被提交到账本之前，已经被所有相关的组织一致地背书过了。失败的交易会被留下来方便审计，但是不会被提交到账本中。

通道（Channel）

Hyperledger Fabric 的通道是两个或多个特定网络成员之间通信的专用“子网”，用于进行私有和机密的交易。通道由成员(组织)、每个成员的锚点节点、共享账本、链码应用程序和排序服务节点定义。网络上的每个交易都在一个通道上执行，在这个通道上，每一方都必须经过身份认证和授权才能在该通道上进行交易。加入通道的每个 Peer 节点都有MSP提供的身份，MSP为每个节点授权访问通道中的其他节点和服务。
要创建一个新通道，客户端SDK调用配置系统链码并引用属性，如“锚点节点”和成员(组织)。这个请求为通道账本创建一个“创世区块”，它存储关于通道策略、成员和锚点节点的配置信息。当将新成员添加到现有通道时，可以与新成员共享这个创世区块，也可以共享最近的重配置区块。
为通道上的每个成员选择一个“主节点”，确定哪个节点代表该成员与排序服务通信。如果没有标识出主，可以使用算法来标识。共识服务对交易进行排序，并将它们以区块的形式交付给每个主节点，然后由每个主节点将该区块分发给它的成员节点，并使用 gossip 协议分发到整个通道。
尽管任何一个锚节点都可以属于多个通道，因此可以维护多个账本，但是账本数据不可以从一个通道传递到另一个通道。这种基于通道的账本隔离，是由配置链码、MSP 服务和 gossip 协议定义和实现的。数据的分发（包括交易信息，账本状态和通道成员信息）仅限于通道上身份可验证的节点。基于通道的节点及账本数据的隔离，使得需要私有和机密交易的网络成员与其业务竞争者和其他受限成员可以在同一区块链网络上共存。

Hyperledger Fabric CA

Hyperledger Fabric提供一个可选的证书授权服务，您可以选择使用该服务生成证书和密钥材料，以配置和管理区块链网络中的身份。然而，任何可以生成 ECDSA 证书的 CA 都是可以使用的。\

Hyperledger Fabric 中错误处理的通用准则

• 若要处理用户请求，应记录并返回错误。
• 若错误来自外部来源（如 Go 依赖库或 vendor 的包），则用 errors.Wrap() 包装该错误，为其生成一个调用堆栈。
• 若错误来自另一个 Fabric 函数，当有需要时，在不影响调用堆栈的情况下使用 errors.WithMessage() 在错误信息中添加更多上下文。
• Panic 不应被传播给其他软件包。

示例程序

以下案列程序清楚地展示了如何使用软件包：

package main import (   "fmt"   "github.com/pkg/errors" ) func wrapWithStack() error {   err := createError()   // do this when error comes from external source (go lib or vendor)   return errors.Wrap(err, "wrapping an error with stack") } func wrapWithoutStack() error {   err := createError()   // do this when error comes from internal Fabric since it already has stack trace   return errors.WithMessage(err, "wrapping an error without stack") } func createError() error {   return errors.New("original error") } func main() {   err := createError()   fmt.Printf("print error without stack: %s\n\n", err)   fmt.Printf("print error with stack: %+v\n\n", err)   err = wrapWithoutStack()   fmt.Printf("%+v\n\n", err)   err = wrapWithStack()   fmt.Printf("%+v\n\n", err) }

交易流程

该场景包含两个客户端 A 和 B，他们分别代表萝卜的买方和卖方。他们在网络上都有一个 Peer 节点，他们通过该节点来发送交易和与账本交互。

该流程中，假设已经设置了一个通道，并且该通道正常运行。应用程序的用户已经使用组织的 CA 注册和登记完成，并且拿到了用于在网络中用确认身份的加密材料。
链码（包含了萝卜商店初始状态的键值对）已经安装在 Peer 节点上并在通道上完成了实例化。链码中的逻辑定义了萝卜的交易和定价规则。链码也设置了一个背书策略，该策略是每一笔交易都必须被 peerA 和 peerB 都签名。

客户端 A 发起一笔交易

客户端 A 发送一个采购萝卜的请求。该请求会到达 peerA 和 peerB，他们分别代表客户端 A 和客户端 B。背书策略要求所有交易都要两个节点背书，因此请求要到经过 peerA 和 peerB。
然后，要构建一个交易提案。应用程序使用所支持的 SDK（Node，Java，Python）中的 API 生成一个交易提案。提案是带有确定输入参数的调用链码方法的请求，该请求的作用是读取或者更新账本。
SDK 的作用是将交易提案打包成合适的格式（gRPC 使用的 protocol buffer）以及根据用户的密钥对交易提案生成签名。

背书节点验证签名并执行交易

背书节点验证（1）交易提案的格式完整，（2）且验证该交易提案之前没有被提交过（重放攻击保护），（3）验证签名是有效的（使用 MSP），（4）验证发起者（在这个例子中是客户端 A）有权在该通道上执行该操作（也就是说，每个背书节点确保发起者满足通道 Writers 策略）。背书节点将交易提案输入作为调用的链码函数的参数。然后根据当前状态数据库执行链码，生成交易结果，包括响应值、读集和写集（即表示要创建或更新的资产的键值对）。目前没有对账本进行更新。这些值以及背书节点的签名会一起作为“提案响应”返回到 SDK，SDK 会为应用程序解析该响应。

检查提案响应

应用程序验证背书节点的签名，并比较这些提案响应，以确定其是否相同。如果链码只查询账本，应用程序将检查查询响应，并且通常不会将交易提交给排序服务。如果客户端应用程序打算向排序服务提交交易以更新账本，则应用程序在提交之前需确定是否已满足指定的背书策略（即 peerA 和 peerB 都要背书）。该结构是这样的，即使应用程序选择不检查响应或以其他方式转发未背书的交易，节点仍会执行背书策略，并在提交验证阶段遵守该策略。

客户端将背书结果封装进交易

应用程序将交易提案和“交易消息”中的交易响应“广播”给排序服务。交易会包含读写集，背书节点的签名和通道 ID。排序服务不需要为了执行其操作而检查交易的整个内容，它只是从网络中的所有通道接收交易，将它们按时间按通道排序，并将每个通道的交易打包成区块。
\

验证和提交交易

交易区块被“发送”给通道上的所有 Peer 节点。对区块内的交易进行验证，以确保满足背书策略，并确保自交易执行生成读集以来，读集中变量的账本状态没有变化。块中的交易会被标记为有效或无效。

账本更新

每个 Peer 节点都将区块追加到通道的链上，对于每个有效的交易，写集都提交到当前状态数据库。系统会发出一个事件，通知客户端应用程序本次交易（调用）已被不可更改地附加到链上，同时还会通知交易验证结果是有效还是无效。\

交易流程图

命令参考

peer

peer 命令的4个子命令如下：

peer chaincode [option] [flags]
peer channel   [option] [flags]
peer node      [option] [flags]
peer version   [option] [flags]

用法

在 peer channel join 命令上使用 --help 标记。

peer channel join --help

Joins the peer to a channel.

Usage:
  peer channel join [flags]

Flags:
  -b, --blockpath string   Path to file containing genesis block
  -h, --help               help for join

Global Flags:
      --cafile string                       Path to file containing PEM-encoded trusted certificate(s) for the ordering endpoint
      --certfile string                     Path to file containing PEM-encoded X509 public key to use for mutual TLS communication with the orderer endpoint
      --clientauth                          Use mutual TLS when communicating with the orderer endpoint
      --connTimeout duration                Timeout for client to connect (default 3s)
      --keyfile string                      Path to file containing PEM-encoded private key to use for mutual TLS communication with the orderer endpoint
  -o, --orderer string                      Ordering service endpoint
      --ordererTLSHostnameOverride string   The hostname override to use when validating the TLS connection to the orderer.
      --tls                                 Use TLS when communicating with the orderer endpoint

peer chaincode

语法

peer chaincode命令有以下子命令：

• install
• instantiate
• invoke
• list
• package
• query
• signpackage
• upgrade

不同的子命令选项（安装，实例化）牵涉到与一个peer相关的不同链码操作。例如，用peer chaincode install子命令选项在节点上安装一个链码，或者用peer chaincode query子命令选项为一节点上账本的当前值查询链码。

peer lifecycle chaincode

语法

该命令具有以下子命令：

• package
• install
• queryinstalled
• getinstalledpackage
• approveformyorg
• queryapproved
• checkcommitreadiness
• commit
• querycommitted

peer channel

语法

peer channel 命令有以下子命令：

• create

• fetch

• getinfo

• join

• list

• signconfigtx

• update

  Operate a channel: create|fetch|join|list|update|signconfigtx|getinfo.

  Usage:
  peer channel [command]

  Available Commands:
  create Create a channel
  fetch Fetch a block
  getinfo get blockchain information of a specified channel.
  join Joins the peer to a channel.
  list List of channels peer has joined.
  signconfigtx Signs a configtx update.
  update Send a configtx update.

  Flags:
  –cafile string Path to file containing PEM-encoded trusted certificate(s) for the ordering endpoint
  –certfile string Path to file containing PEM-encoded X509 public key to use for mutual TLS communication with the orderer endpoint
  –clientauth Use mutual TLS when communicating with the orderer endpoint
  –connTimeout duration Timeout for client to connect (default 3s)
  -h, --help help for channel
  –keyfile string Path to file containing PEM-encoded private key to use for mutual TLS communication with the orderer endpoint
  -o, --orderer string Ordering service endpoint
  –ordererTLSHostnameOverride string The hostname override to use when validating the TLS connection to the orderer.
  –tls Use TLS when communicating with the orderer endpoint

  Use “peer channel [command] --help” for more information about a command.

peer version

peer version命令可以查看peer的版本信息。它会显示版本号、Commit SHA、Go 的版本、操作系统及架构和链码信息。例如：

peer:
   Version: 2.1.0
   Commit SHA: b78d79b
   Go version: go1.14.1
   OS/Arch: linux/amd64
   Chaincode:
    Base Docker Label: org.hyperledger.fabric
    Docker Namespace: hyperledger

peer version 命令没有参数

Print current version of the fabric peer server.

Usage:
  peer version [flags]

Flags:
  -h, --help   help for version  

peer node

管理员可以通过peer node命令来启动 Peer 节点，将节点中的所有通道重置为创世区块，或者将某个通道回滚到给定区块号。
peer node 命令有如下子命令：

• start
• reset
• rollback

peer node start

启动一个和网络交互的节点。

Usage:
  peer node start [flags]

Flags:
  -h, --help                help for start
      --peer-chaincodedev   start peer in chaincode development mode

peer node reset

将通道重置到创世区块。执行该命令时，节点必须是离线的。当节点在重置之后启动时，它将会从排序节点或者其他 Peer 节点从1号区块开始获取区块，并重建区块存储和状态数据库。

Usage:
  peer node reset [flags]

Flags:
  -h, --help   reset 的帮助

peer node rollback

从指定的区块号回滚通道。执行该命令时，节点必须是离线的。当节点在回滚之后启动时，它将会从排序节点或者其他 Peer 节点获取回滚过程中删除的区块，并重建区块存储和状态数据库。


Usage:
  peer node rollback [flags]

Flags:
  -b, --blockNumber uint   通道要回滚的区块序号
  -c, --channelID string   要回滚的通道
  -h, --help               rollback 的帮助

configtxgen

configtxgen命令允许用户创建和查看通道配置相关构件。所生成的构件取决于configtx.yaml的内容。

Usage of configtxgen:
  -asOrg string
      以特定组织（按名称）执行配置生成，仅包括组织（可能）有权设置的写集中的值。
  -channelCreateTxBaseProfile string
      指定要视为排序系统通道当前状态的轮廓（profile），以允许在通道创建交易生成期间修改非应用程序参数。仅在与 “outputCreateChannelTX”  结合时有效。
  -channelID string
      配置交易中使用的通道 ID。
  -configPath string
      包含所用的配置的路径。（如果设置的话）
  -inspectBlock string
      打印指定路径的区块中包含的配置。
  -inspectChannelCreateTx string
      打印指定路径的交易中包含的配置。
  -outputAnchorPeersUpdate string
      创建一个更新锚节点的配置更新（仅在默认通道创建时有效，并仅用于第一次更新）。
  -outputBlock string
      写入创世区块的路径。（如果设置的话）
  -outputCreateChannelTx string
      写入通道创建交易的路径。（如果设置的话）
  -printOrg string
      以 JSON 方式打印组织的定义。（手动向通道中添加组织时很有用）
  -profile string
      configtx.yaml 中用于生成的轮廓。
  -version
      显示版本信息。  

configtxlator

configtxlator命令允许用户在 protobuf 和 JSON 版本的 fabric 数据结构之间进行转换，并创建配置更新。该命令可以启动 REST 服务器并通过 HTTP 公开，也可以直接用作命令行工具。
configtxlator工具有五个子命令：

• start
• proto_encode
• proto_decode
• compute_update
• version

cryptogen

cryptogen是用来生成 Hyperledger Fabric 密钥材料的工具。它为测试提供了一种预配置网络的工具。通常它不应使用在生产环境中。
cryptogen有如下五个子命令:

• help
• generate
• showtemplate
• extend
• version

cryptogen help

usage: cryptogen [<flags>] <command> [<args> ...]

生成 Hyperledger Fabric 密钥材料的工具。

Flags:
  --help  查看完整的帮助（可以尝试 --help-long 和 --help-man）。

Commands:
  help [<command>...]
    显示帮助。

  generate [<flags>]
    生成密钥材料。

  showtemplate
    显示默认配置模板。

  version
    显示版本信息。

  extend [<flags>]
    扩展现有网络。

cryptogen generate

usage: cryptogen generate [<flags>]

生成密钥材料

Flags:
  --help                    查看完整的帮助（可以尝试 --help-long 和 --help-man）。
  --output="crypto-config"  用来存放构件的输出目录。
  --config=CONFIG           使用的配置模板。 

cryptogen showtemplate

usage: cryptogen showtemplate

Show the default configuration template

Flags:
  --help  Show context-sensitive help (also try --help-long and --help-man).

cryptogen extend

usage: cryptogen extend [<flags>]

扩展现有网络。

Flags:
  --help                   查看完整的帮助（可以尝试 --help-long 和 --help-man）。
  --input="crypto-config"  存放现有网络的输入目录。、existing network place
  --config=CONFIG          使用的配置模板。

cryptogen version

usage: cryptogen version

显示版本信息。

Flags:
  --help  查看完整的帮助（可以尝试 --help-long 和 --help-man）。