hyperledgerfabric官方文档,hyperledgerfabric

(译)超级账本官方文档 基本概念(三) - 节点(Peer)

超级账本是Linux基金会发起的项目，意在提供一套企业级区块链应用框架，便于大家开发基于区块链技术的应用。

Fabric的基本概念

最开始，应用程序会选出一组peer来生成账本更新提议。哪些peer会被选出来是依据的背书策略，这个背书策略决定了哪些组织需要在广播账本更新提议前对更新提议进行背书。这会影响到共识方式，任何一个关心更新提议是否背书的组织都会在广播给peer更新提议并被peer接受前确认提议是否有背书。

peer对一个提议响应进行背书，就是把自己的数字签名加入到响应中，并用自己的私钥对整个响应签名。背书内容随后可以被用于证明这个响应是某个组织的peer生成的。在我们的例子中，如果peer P1属于组织1(Org1)，那么背书E1就相当于可以证明L1上的交易T1和响应R1是由Org1的peer P1提供的。

当应用程序得到了足够多的签名的提议响应时，第一阶段就结束了。

我们注意到peer可能返回不同的信息，因此同一笔交易可能有不一致的返回信息。这可能由于响应是在不同时间，不同peer，在不同账本状态下生成的，大多数情况下应用程序可以多次请求更新的提议响应。另外更严重，但概率很小的原因是因为链码的不确定性导致的响应不一致。不确定性是链码和账本的大敌，如果这种情况发生了，对提议交易来说是很严重的，不一致的提议响应肯定不能提交到账本中。一个独立的节点是不可能知道交易结果是非确定性的交易，在检测到非确定性交易前，必须将交易汇总比较(严格地说，即使这还不够，但我们将此讨论推迟到交易部分，其中详细讨论了非确定性)。

在第一阶段结束时，如果应用程序希望如此的话，可以放心丢弃不一致的响应以提前结束交易流程。后面我们会看到如果应用程序使用不一致的响应提交到账本时，会被拒绝。

过程2 打包

第二个交易流程是打包。Orderer节点这个过程关键的点，它接收来自很多应用传来的背书过的提议交易响应。Orderer对交易进行排序，并将大量的交易打包进区块，并准备将区块分发到所有连接到Orderer的peer，包括背书peer。

orderer的第一个角色就是打包账本更新提议。在上图的例子中，应用A1发送给Orderer O1一个被E1和E2背书的交易T1。同时，应用A2发送给Orderer O1一个被E1背书的交易T2。O1将A1传来的交易和A2传来的交易以及其它交易共同打包进区块B2。我们可以看到区块B2里的交易排序是T1，T2，T3，T4，T6，T5，并不一定是按照到达orderer节点的顺序(这个例子展示了一个非常简单的orderer配置)。

Orderer节点会同时收到网络Channel中不同应用程序发送的账本更新提议。Orderer节点的任务就是按照事先定义好的顺序整理这些更新提议，并把它们打包进区块，为下一步的分发做准备。这些区块将构成区块链。一旦Orderer节点生成了期望大小的区块，或者超过最大等待时间，Orderer会向连接到它特定Channel的Peer发送区块。第三个过程会详述这个流程。

区块中的交易排列顺序和交易到达Orderer节点的顺序没有直接关系。交易在区块中可以是任意的排列顺序，这个次序就是交易执行的顺序。重点是有一个严格的交易排序，但具体是怎样的排序并不重要。

区块中的严格交易顺序排列使得Fabric与公链中一笔交易可以被打包进多个不同区块的情况不同。在Fabric中，这不可能发生，由多个Orderer生成的区块就是最终的区块，因为交易被写入区块后，交易的位置顺序就确定了。这意味着Fabric不会存在分叉。一旦交易被写入区块，以后就不能再重写了。

我们可以看到，peer是存储账本和链码的，orderer完全不会存储这些。每一笔交易到达orderer时，orderer只是机械的将交易打包进区块，而不会理会交易的价值，额度等。这是Fabric的一个重要特性，所有交易都会按照一个严格的顺序进行整理，没有交易会被抛弃掉。

到第二阶段结束时，我们可以了解到orderer的责任就是进行必要的，简单的收集交易更新提议，将他们排序，打包进区块，准备分发出去。

过程3 认证

最后一个交易工作流程是分发和验证从orderer到peer的区块，如果验证成功，将会被提交到账本中。

特别的，在每个peer中，在区块中的每一笔交易在更新到账本之前都是验证过的，以保证所有交易都是由相关的组织背书过的。失败的交易会保留，作为日后审查用，并不会更新到账本中。

Orderer除了在过程2中的打包角色外，在过程3中还负责分发区块到peer节点。在这个例子中，O1分发区块到P1和P2。P1处理区块2，然后将区块2添加到P1的账本L1中。同时，P2处理区块2，然后将区块2添加到P2的账本L1中。一旦操作完成，账本L1在P1和P2中都被更新了，每个Peer都可以向连接到他们的应用程序发送处理结果。

Orderer向连接到他的Peer分发区块是过程3的开始。连接到orderer节点的某个渠道的peer，会收到orderer生成的新区块的一份拷贝。每个peer节点都会独立的处理收到的区块，但所有peer处理区块的方式都是相同的。采用这种方式，不同peer中的账本可以达成共识。并不是所有的peer都必须连接到orderer节点，peer和peer之间可以通过gossip协议来传递区块，这样peer也可以独立的处理相同区块。

收到一个区块后，peer会按照交易在区块中出现的顺序依次处理。对于每一笔交易，peer会按照生成这笔交易的链码背书策略检查交易是否被与之相关组织的背书。例如，某些交易可能只需要一个组织背书，而另一些交易需要多个组织同时背书才有效。这个验证过程验证了所有相关组织产生的结果或者输出是否一致。同时请注意，第三阶段的验证和第一阶段不同，阶段一只是应用程序收到背书节点的响应，判断是否需要发送交易提议。如果应用程序发送错误的交易，违反了背书策略，在第三阶段的验证过程中peer还是可以拒绝本次交易。

如果交易背书正确，peer将尝试把交易提交到账本中。为了能写账本，peer必须进行账本一致性检查，保证当前账本的状态与账本更新后的状态一致。这个状态并不总会是一致的，即使交易拥有完整的背书。举个栗子，另外一笔交易可能已经更新了账本中的同一个资产，以至于我们正要更新的交易将永远不会被写入账本。这样的话，每个节点中的账本必须通过网络保持共识，每个节点的验证方式是一样的。

在peer验证完每笔独立交易后，将更新账本。失败的交易会保存下来作为审查资料。这意味着peer中的区块和从orderer中收到的区块一致，除了区块中指示交易成功或失败的标志。

我们也要注意到，第三阶段并没有执行链码，这一步只会在第一阶段完成，这很重要。这意味着链码只在背书节点可用，而不是整个网络中都可用，这保证了链码在背书组织中的安全及私密。这和收到链码的执行结果不同，执行结果会分享到所有在Channel里的peer，不论他是否能背书交易。背书节点的这种设计方式是为了方便扩展。

最后，每次区块被提交到peer的账本中时，这个peer会生成对应的事件。区块事件包含区块的所有内容，而区块交易事件只包含简要信息，比如每笔区块中的交易是否有效。由链码的执行而产生的链码事件也可以在这个时候发布。应用程序可以注册这些事件，当这些事件发生时，可以收到通知。这些通知在交易工作流程的第三阶段和最后阶段完成。

总的来说，我们可以知道第三阶段由orderer产生的区块被不断地同步到账本中。区块中交易的严格排序能让每个peer在区块链网络中始终如一地验证交易并提交到账本中。

Orderer和共识

整个交易工作流程被称为共识，因为所有peer都认同交易的排序和内容，在执行过程中由orderer节点来协调。共识是多步骤的过程，应用程序只会在共识过程结束时收到通知，但通知的时间在不同的peer上可能不同。

我们将会在后面更多的探讨orderer，现在，把orderer仅仅当做从应用程序收集、分发账本更新提议到peer，由peer进行验证及更新账本的过程。

使用 AWS 区块链模版搭建 Hyperledger Fabric

AWS 区块链模版号称可以在几分钟内完成创建并部署区块链网络。

使用 AWS 区块链模版可以搭建两种类型的区块链网络：

具体搭建步骤可以参考 AWS Blockchain Templates 开发人员指南 ，里面有关于搭建 Ethereum 的详细步骤，文档中的 「先决条件」 设置项是用于搭建 Ethereum 网络的，对 Fabric 网络并不适用，所以这里说一下搭建超级账本的 Fabric。

在使用模版快速创建堆栈前，务必要提前设置好的相关内容：

说明：

以上的5个前提条件设置正确了，我们就可以用区块链模版创建 Fabric 网络了，下面具体说一下画红框的比较难的两个配置：

设置步骤：

点击右下角的 「Review Policy」 ,设置这个权限策略文件的名称（myFabricPolicy）和描述（...），最后点击 「Create Policy」 ：

设置如下：

AWS控制台——服务——VPC——在VPC控制面板中点击蓝色的按钮「 Launch VPC Wizard 」,选择带有单个公有子网的 VPC：

设置 VPC 名称、子网名称，其他值为默认值。

在 AWS Blockchain Templates 开发人员指南 的Hyperledger Fabric 部分点击启动链接：

设置参考如下：

创建之后，喝一杯咖啡??等一会儿...

等状态显示为「 CREATE_COMPLETE 」就OKK了。??????

Hyperledger Fabric 介绍几个关键配置文件（三）

configtx.yaml是Hyperledger Fabric区块链网络运维工具configtxgen用于生成通道创世块或通道交易的配置文件，configtx.yaml的内容直接决定了所生成的创世区块的内容。

configtx.yaml主要用到了以下YAML语法：

当byfn.sh脚本执行networkUp启动网络时，会调用generateChannelArtifacts创建Orderer通道的创世区块，应用通道配置配置交易文件channel.tx。根据不同的共识机制，传入不同的profile参数。

Profiles配置段用来定义用于configtxgen工具的配置入口。包含consortium的配置入口，可以用来生成排序节点的创世区块。如果在排序节点的创世区块中正确定义了consortium 的成员，那么可以仅使用机构成员名称和委员会的名称来生成通道创建请求。

Capabilities段定义了fabric程序要加入网络所必须支持的特性。通过定义通道的能力，就明确了不满足该能力要求的fabric程序，将无法处理 交易，除非升级到新的版本。

Organizations配置段用来定义组织机构实体，以便在后续配置中引用。

Fabric主要通过策略(Policy)来控制各种场景下访问这些资源的权限限制。Fabric实现了两种类型的Policy来满足不同的场景需求：

Orderer配置段用来定义要编码写入创世区块或通道交易的排序节点参数。

Channel配置段用来定义要写入创世区块或配置交易的通道参数。

Application配置段用来定义要写入创世区块或配置交易的应用参数。

core.yaml配置文件是Peer节点的示例配置文件，该core.yaml示例配置文件中共指定了六大部分内容。

Hyperledger Fabric 分享文档

一组业务逻辑创建一个通道，各个组织可以订阅自己需要的通道，任何发往该通道的交易都会发往该节点，通道之间相互隔离，但是每个组织可以选择多个通道

区块存储

fabric使用读写集的原因：因为fabric的交易是分阶段的，交易模拟负责执行，交易验证负责验证

优点：交易模拟时可以并发执行速度快，交易验证时简单

缺点：存储占用空间大，比如对一个数据+1，指令集存储+1指令，而读写集存储+1之后的值

同时读写集的缺点引发了账本裁剪等问题

超级账本是一个明星项目，可以看到参与者有开源界顶级组织Linux基金会，以及商业界的顶级机构IBM、Inter... 等公司，其中IBM是贡献最多的，我们这次主要也是IBM的项目Fabric。因为大家都是做公链，炒币过来的，所以这里需要说明一下，喜欢以价值互联网标榜的公链不同，hyperledger是一个联盟链，核心目的是 （建立信任、责任和透明度，同时简化业务流程和法律限制），在这里面发币成为了次要的东西，所以这个正真顶级开发阵容的区块链，在链圈不怎么被炒币的人关注。

因为没有币不够性感~

Hyperledger Fabric 社区中文文档

我这里应该不会再更新了，毕竟翻译的不是那么专业，请参考社区的中文文档。

社区又完成了一大波 fabric 中文文档，敬请阅读斧正！！

我是 hyperledgerDocs 。

目前列出的文章都已翻译完毕，包含了官方文档的大部分关键内容，欢迎小伙伴们继续参与贡献。