Hyperledger Fabric(分布式账本框架)

　　Hyperledger Fabric提供分布式账本管理方案，针对区块链业务开发，可以帮助企业建立区块链业务管理平台，可以在平台管理交易、管理订单，管理资产，管理分类账，这款软件功能非常丰富，针对企业开发，支持在软件查询分类账，支持查看历史数据，支持创建交易平台，帮助开发人员快速构建符合企业业务需求的区块链管理系统，如果您使用区块链办公就可以通过这款框架开发相关的业务管理系统，结合软件提供的插件、组件、API等资源就可以部署新的工作系统，如果你需要这款软件就下载吧！

软件功能

　　Hyperledger Fabric是分布式账本解决方案的平台，其模块化架构提供了高度的机密性，灵活性，灵活性和可扩展性。它旨在支持不同组件的可插拔实现，并适应整个经济生态系统中存在的复杂性和复杂性。

　　Hyperledger Fabric提供了独特的弹性和可扩展架构，将其与其他区块链解决方案区分开来。规划企业区块链的未来需要在经过全面审查的开源架构的基础上进行构建。Hyperledger Fabric是您的起点。

　　Hyperledger Fabric是一个开放源代码企业级许可分布式账本技术（DLT）平台，设计用于企业环境，与其他流行的分布式账本或区块链平台相比，它提供了一些关键的区分功能。

　　差异化的一个关键点是Hyperledger是在Linux基金会下建立的，它本身有着悠久而成功的历史，它在开放式治理下培育了开源项目，这些项目发展了强大的可持续社区和繁荣的生态系统。Hyperledger由多元化的技术指导委员会管理，Hyperledger Fabric项目由来自多个组织的多元化维护人员管理。自最早成立以来，它的开发社区已发展到35个以上的组织和近200个开发人员。

　　Fabric具有高度模块化和可配置的体系结构，可针对银行，金融，保险，医疗保健，人力资源，供应链甚至数字音乐交付等广泛的行业用例进行创新，多功能和优化。

　　Fabric是第一个支持以通用编程语言（例如Java，Go和Node.js）而非受约束的领域特定语言（DSL）编写的智能合约编写的分布式分类帐平台。这意味着大多数企业已经具备开发智能合约所需的技能，并且不需要额外的培训来学习新的语言或DSL。

　　Fabric平台也是经过许可的，这意味着，与公共的未经许可的网络不同，参与者是彼此了解的，而不是匿名的，因此是完全不受信任的。这意味着，尽管参与者之间可能不会完全信任对方（例如，他们可能是同一行业的竞争者），但网络可以在治理模型下运行，该治理模型是基于参与者之间确实存在的信任而建立的，例如处理争议的法律协议或框架。

软件特色

　　Hyperledger Fabric专门设计为具有模块化体系结构。无论是可插拔共识，可插拔身份管理协议（例如LDAP或OpenID Connect），密钥管理协议还是密码库，该平台的核心都经过了配置，可以满足企业用例需求的多样性。

　　在较高的层次上，Fabric由以下模块化组件组成：

　　可插拔的订购服务在交易顺序上达成共识，然后将区块广播给同级。

　　可插拔成员资格服务提供商负责将网络中的实体与密码身份相关联。

　　可选的对等八卦服务通过向其他对等点订购服务来分发输出的块。

　　智能合约（“链码”）在容器环境（例如Docker）中运行以进行隔离。它们可以用标准编程语言编写，但不能直接访问分类帐状态。

　　账本可以配置为支持各种DBMS。

　　可插拔的认可和验证策略实施，可以针对每个应用程序进行独立配置。

官方教程

　　使用结构测试网络

　　下载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证书）已更新，则这一点尤其重要。

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

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

更新日志

　　v2.3.2发行说明-2021年4月23日

　　改进之处

　　对等方和订购者-对Go 1.15实施旧版名称约束验证

　　这些更改在MSP中重现了Go 1.14名称约束验证。

　　如果没有这些更改，

　　由于Go 1.15发行说明中提到的更改，在Go 1.14中无法通过验证的证书链将在Go 1.15中成功验证。

　　具体来说，如果签名证书包含名称约束，叶子证书

　　不包括SAN扩展，并且叶子的公用名看起来像主机名，

　　则执行附加验证以确保相

　　对于先前Fabric版本释放确定性行为。

　　修正

　　FAB-18427：订购者-报告订购者群集中流中止的正确原因

　　此落实修复了一个错误，该错误使集群通信基础结构

　　在流终止后始终报告“异常终止”的原因。

　　FAB-18424：对等方-具有特殊值“ blockNumber 0”的分类帐快照请求提交

　　如果使用特殊值“ blockNumber 0”提交分类帐快照请求，则预期对等方将请求转换为最后一个提交的块。

　　此修补程序解决了有时将请求转换为块号1而不是最后提交的块的情况。

　　这导致无法生成快照（包括任何将来的快照请求）的情况。

　　如果您曾经使用过此特殊值，建议您使用来检查待处理快照请求的列表peer snapshot listpending。

　　如果您发现一个或多个待处理请求的块号低于最新提交的块，请取消此类请求，peer snapshot cancelrequest以处理其他快照请求。

　　FAB-18304：对等方和订购者-修复leveldb清单损坏

　　此修复程序更新了goleveldb的版本。goleveldb的先前版本存在一个错误，该错误

　　可能导致崩溃情况下（尤其是磁盘已满的崩溃情况下）明显损坏。

　　如果goleveldb数据库已损坏，则对等方或订购者将无法启动，并显示错误

　　“紧急：打开leveldb时出错：leveldb：清单已损坏”。

　　依存关系

　　Fabric v2.3.2已通过以下依赖项进行了测试：

　　转到1.15.7

　　CouchDB v3.1.1

　　弃用（现有）

　　FAB-15754：不推荐使用“ Solo”共识类型。

　　“ Solo”共识类型一直被标记为非生产类型，应

　　仅在测试环境中使用，但是出于兼容性考虑，它仍然可用，

　　但在将来的版本中可能会完全删除。

　　FAB-16408：不推荐使用“ Kafka”共识类型。

　　v1.4.1中引入了“筏”共识类型，它已成为首选的

　　生产共识类型。从

　　Kafka到Raft有一条经过记录和测试的迁移路径，现有用户应迁移到较新的Raft共识类型。

　　为了与现有部署兼容，仍支持Kafka，

　　但在将来的发行版中可能会完全将其删除。

　　此外，fabric-kafka和fabric-zookeeper码头工人镜像不再更新，维护或发布。

　　Fabric CouchDB映像已弃用

　　v2.2.0添加了对CouchDB 3.1.0的支持，作为CouchDB的推荐和经过测试的版本。

　　如果使用以前的版本，则对等日志中将显示警告。

　　请注意，CouchDB 3.1.0要求设置管理员用户名和密码，

　　而在CouchDB v2.x中这是可选的