使用结构测试网络

      下载Hyperledger Fabric Docker映像和示例后，可以使用fabric-samples存储库中提供的脚本来部署测试网络 。提供测试网络是为了通过在本地计算机上运行节点来了解Fabric。开发人员可以使用网络来测试其智能合约和应用程序。该网络只能用作教育和测试的工具，而不能用作建立网络的模型。通常，不建议对脚本进行修改，否则可能会破坏网络。它基于有限的配置，不应用作部署生产网络的模板：

      它包括两个对等组织和一个订购组织。

      为简单起见，配置了一个单节点Raft订购服务。

      为了降低复杂性，未部署TLS证书颁发机构(CA)。所有证书均由根CA颁发。

      该示例网络使用Docker Compose部署了一个Fabric网络。由于节点在Docker Compose网络中是隔离的，因此未将测试网络配置为连接到其他正在运行的Fabric节点。

      要了解如何在生产中使用Fabric，请参阅部署生产网络。

      注意：这些说明已通过验证，可与提供的tar文件中的最新稳定Fabric Docker映像和预编译的设置实用程序一起使用。如果使用当前master分支中的图像或工具运行这些命令，则可能会遇到错误。

      在你开始之前

      在运行测试网络之前，您需要克隆fabric-samples 存储库并下载Fabric映像。确保已安装前提条件并安装了示例，二进制文件和Docker映像。

      注意：测试网络已通过Docker Desktop 2.5.0.1版成功验证，目前是推荐的版本。更高版本可能无法正常工作。

      建立测试网络

      您可以test-network在fabric-samples存储库目录中找到用于启动网络的脚本。使用以下命令导航到测试网络目录：

      cd fabric-samples/test-network

      在此目录中，您可以找到带注释的脚本，network.sh该脚本使用本地计算机上的Docker映像站立在Fabric网络上。您可以运行 以打印脚本帮助文本：./network.sh -h

      从test-network目录内部，运行以下命令以从以前的任何运行中删除任何容器或工件：

      ./network.sh down

      然后，您可以通过发出以下命令来启动网络。如果尝试从另一个目录运行脚本，则会遇到问题：

      ./network.sh up

      此命令创建一个结构网络，该结构网络由两个对等节点(一个订购节点)组成。您在运行时不会创建任何渠道，尽管我们将在以后的步骤中实现。如果命令成功完成，您将看到正在创建的节点的日志：./network.sh up

      测试网络的组成部分

      部署测试网络后，您可能需要一些时间来检查其组件。运行以下命令以列出您的计算机上运行的所有Docker容器。您应该看到该network.sh脚本创建的三个节点：

      docker ps -a

      与Fabric网络交互的每个节点和用户都必须属于一个组织才能参与网络。测试网络包括两个对等组织，Org1和Org2。它还包括维护网络订购服务的单个订购者组织。

      对等是任何Fabric网络的基本组成部分。对等方存储区块链分类帐并在将交易提交到分类帐之前对其进行验证。对等方运行包含业务逻辑的智能合约，该业务逻辑用于管理区块链分类账上的资产。

      网络中的每个对等方都必须属于一个组织。在测试网络中，每个组织各自运营一个对等方，peer0.org1.example.com 并且peer0.org2.example.com。

      每个Fabric网络还包括订购服务。当对等方验证交易并将交易块添加到区块链分类账中时，他们并不确定交易的顺序或将其包括在新的块中。在分布式网络上，对等点可能彼此相距很远，并且对创建事务的时间没有共同的看法。在交易顺序上达成共识是一个代价高昂的过程，这会给对等方造成开销。

      订购服务允许对等方专注于验证交易并将其提交到分类账。在订购节点收到客户认可的交易后，他们就交易顺序达成共识，然后将其添加到区块中。然后将这些块分发到对等节点，对等节点将这些块添加到区块链分类账中。

      示例网络使用由订购者组织操作的单节点Raft订购服务。您可以看到正在计算机上运行的订购节点orderer.example.com。尽管测试网络仅使用单个节点订购服务，但是生产网络将具有多个订购节点，这些订购节点由一个或多个订购者组织操作。不同的排序节点将使用Raft共识算法来就网络上的事务顺序达成协议。

      建立频道

      现在，我们的机器上正在运行对等节点和订购者节点，我们可以使用该脚本为Org1和Org2之间的事务创建Fabric通道。通道是特定网络成员之间的专用通信层。频道只能由受邀加入该频道的组织使用，并且对网络的其他成员不可见。每个通道都有一个单独的区块链分类帐。被邀请的组织将其同行“加入”渠道以存储渠道分类帐并验证渠道上的交易。

      您可以使用network.sh脚本在Org1和Org2之间创建频道，并将其对等方加入该频道。运行以下命令以使用默认名称创建频道mychannel：

      ./network.sh createChannel

      如果命令成功执行，则可以在日志中看到以下消息：

      ========= Channel successfully joined ===========

      您也可以使用channel标志创建具有自定义名称的频道。例如，以下命令将创建一个名为的通道channel1：

      ./network.sh createChannel -c channel1

      通道标志还允许您通过指定不同的通道名称来创建多个通道。创建mychannel或后channel1，您可以使用以下命令创建另一个名为的频道channel2：

      ./network.sh createChannel -c channel2

      如果要一步一步建立网络并创建频道，可以将up和createChannel模式一起使用：

      ./network.sh up createChannel

      通道配置(configtx)

      笔记

      本主题描述了当尚未使用系统通道发生块自举网络时如何配置通道。有关配置结构(包括系统通道的配置)的信息，请 从v2.2文档中查看“ 通道配置(configtx) ”。

      Hyperledger Fabric区块链网络的共享配置存储在一个集合配置事务中，每个通道一个。通常，每个配置事务都使用简称 configtx来引用。

      通道配置具有以下重要属性：

      1、版本化：配置的所有元素都有一个关联的版本，每次修改都会对其进行升级。此外，每个提交的配置都会接收一个序列号。

      2、允许的：配置的每个元素都有一个关联的策略，该策略控制是否允许对该元素进行修改。拥有先前configtx副本(并且没有其他信息)的任何人都可以基于这些策略来验证新配置的有效性。

      3、层次结构：根配置组包含子组，层次结构的每个组都有关联的值和策略。这些策略可以利用层次结构从较低级别的策略中一级导出策略。

      配置剖析

      配置作为类型的事务存储HeaderType_CONFIG 在一个块中，没有其他事务。这些块称为 配置块，第一个称为 Genesis块。

      用于配置的原型结构存储在中 fabric-protos/common/configtx.proto。类型的信封HeaderType_CONFIG将ConfigEnvelope消息编码为 Payload data字段。的原型ConfigEnvelope定义如下：

      该last_update字段在下面的“更新到配置”部分中定义，但仅在验证配置而不读取时才是必需的。而是将当前提交的配置存储在config包含Config 消息的字段中。

      sequence对于每个已提交的配置，该数字将增加一。该channel_group字段是包含配置的根组。该ConfigGroup结构是递归定义的，并构建了一个分组树，每个分组都包含值和策略。它的定义如下：

      由于ConfigGroup是递归结构，因此具有层次结构。为了简化Go语法，表达了以下示例。

      每个组在配置层次结构中定义一个级别，每个组具有一组关联的值(由字符串键索引)和策略(也由字符串键索引)。

      请注意，值，策略和组都有一个version和一个 mod_policy。的version元素的是，元件被修改的每个时间递增。将mod_policy被用来管理所需的签名修改该元素。对于组，修改是在“值”，“策略”或“组”映射中添加或删除元素(或更改mod_policy)。对于“值”和“策略”，修改将分别更改“值”和“策略”字段(或更改 mod_policy)。mod_policy在配置的当前级别的上下文中评估每个元素。考虑下面定义的示例mod策略Channel.Groups["Application"](此处，我们使用Go map引用语法，因此 Channel.Groups["Application"].Policies["policy1"]是指基 Channel组的Application组的Policiesmap的 policy1策略。)

      policy1 映射到 Channel.Groups["Application"].Policies["policy1"]

      Org1/policy2 映射到 Channel.Groups["Application"].Groups["Org1"].Policies["policy2"]

      /Channel/policy3 映射到 Channel.Policies["policy3"]

      请注意，如果mod_policy引用的策略不存在，则不能修改该项目。

      新增功能

      更高的私密性：由于以前所有订购节点都已加入系统通道，因此网络中的每个订购节点都知道该订购服务上每个通道的存在。现在，订购节点仅知道其加入的渠道。

      可伸缩性：当系统通道上定义了大量的订购节点和订购通道时，订购节点要花很长时间才能就所有通道的成员资格达成共识。现在，订购服务可以通过将订购节点独立连接到特定渠道，以分散的方式水平扩展。

      运营收益

      将订购节点加入频道的简单过程。

      能够列出订购节点同意的渠道。

      从订购节点移除渠道的简单过程，该过程自动清除与该渠道关联的模块。

      对等组织无需与系统通道的管理员协调即可创建或更新其MSP。

      分类帐快照

      现在可以对一个对等方的频道信息(包括其状态数据库)进行快照，并根据快照将新对等方(在同一组织或不同组织中)加入该信道。

      使用分类帐快照具有以下优点：

      自从创世块以来，对等方不需要处理所有块：自从创世块以来，对等方可以在不处理所有先前块的情况下加入通道，从而大大减少了将对等方加入现有通道所需的时间。

      对等方可以使用最新的通道配置加入频道：由于快照包含最新的频道配置，因此对等方现在可以使用最新的频道配置加入频道。如果自创世以来，关键通道配置(例如订购者端点或TLS CA证书)已更新，则这一点尤其重要。

      降低存储成本：自从生成块以来，通过快照加入的对等方不会产生维护所有块的存储成本。

      状态检查点：对等管理员可以快照当前通道状态，并与同一组织或不同组织中的其他对等进行比较，以验证每个对等上账本的一致性和完整性。商定的快照可用作新加入对等方的检查点和基础。