fabric区块链需要多少节点

㈡ 区块链之联盟链（三） 认识Fabric

Fabric 是超级账本联盟推出的核心区块链框架，它适合在复杂的企业内和企业间搭建联盟链。根据超级账本联盟的目标， Fabric 被建设为一个模块化的、支持可插拔组件的基础联盟链框架。；

与以太坊系的Quorum不同，Fabric从一开始就只考虑企业间的应用。其独有的channel概念，将企业根据业务目的不同以不同的子网连接起来， 每一个子网对应一个channel，而每个channel有自己独立的区块链。而Quorum很显然是只有一个公网（所有企业节点都加入进去），企业与企业间的私有业务是通过Private Manager 完成的。

理解channel的最简单方法就是，将它类比为一个消息服务提供的Topic，实际上Fabic最早就是基于Kafka 的分布式消息服务来实现。

       在Fabric网络中，一个企业可以有一个或多个节点加入整个联盟链；一个企业可以加入1个或者多个Channel（子网）；  一个节点可以加入1个或者多个channel。每个channel构成一个子网，所以Fabric 是 一种由子网组成的网络。

那么Fabric是怎么实现智能合约的执行和完成业务上链（将事务结果记录在区块链里）的呢？

与其它框架不同， Fabric 将整个过程分成了三个阶段：

业务背书阶段 ： 客户的请求发送的背书节点，通过智能合约完成业务的计算（但不更新状态），并完成背书；将背书结果返回个客户端。

业务的排序阶段 ： 客户端将背书结果通过Channel被发送到排序节点（orderer），在排序节点完成事务的排序，并打包到block里，最后下发给所有连接到channel的节点。

业务验证并写入账本阶段 : 通过Gossip 网络，所有Channel的节点都会接收到新的block，节点会验证block中的每一个事务，确定是否有效：有效地将会跟新world state，无效的将会标志为“无效”，不会更新World state，但整个block会被完整的加入到帐本中（包括无效的事务）。

根据以上的描述，Fabric 节点实际可以分为  ，普通节点和Order节点：

 Peer, 普通节点, 完成背书（包括只能合约的执行）和验证.

orderer,  排序节点，完成排序。

加入orderer节点的Fabric网络可以被描述如下：

每一个Channel，都定义了所有属于channel的节点，但是并不需要所有节点都连接到Orderer 节点（节点间可以通过gossip 协议通讯来传播私有数据或事务）.

       在区块链中，共识是区块链的基础。与公有链不同，联盟链的共识要求所有加入账本的事务是确定的、最终的，也就是不可以有分叉，区块与区块间的顺序是一定的，只存在唯一条链。在Fabric 中，这个客观需求正是由排序实现的，所有的事务将被提交给orderer节点获得确定的顺序，并最终打包成block进入帐本。 Fabric 从1.4.1开始支持基于Raft实现排序服务,  可以认为基于Raft实现共识。

基于RAFT的排序服务相对于早期的Kafka 具有更好的分布性，配置更加简单，是联盟链里常用的一个常用的达成共识的算法，Quorum就 默认使用RAFT作为共识层。简单的说，RAFT是一个leader和follower的模式， 所有加入RAFT网络的节点，任意时候都有一个leader,  只有这个leader有权决定事务的顺序，并打包成Block，其它节点只能作为follower提交事务和同步block。

基于FAFT网络，每个企业可以有一个或多个节点参与到Orderer中去。在Frabric中企业间的网络连接可以变化成如下形式：

       区块链的使用用户在以太网中被称作EOA（External of Account）, EOA的载体是钱包。我们沿用这个概念，来看看Fabric是如何实现用户和发起事务的。Fabric中EOA是一个CA中心发布的certificate（x.509），一个Certificate代表一个Identity（这与以太坊还是有很大区别的， 以太坊中一个EOA其实是一个hash地址），EOA能够参与的channel以及被授权的操作是有channel的MSP（ Membership Service  Provider）决定的（如下图）。

注：certificate 是一种密码学上验证身份的通用做法； certificate包含了个人的信息，公钥以及发布这个certificate的CA的签名。验证方只需要拥有这个CA的证书（包含CA的公钥），就可以验证这个签名是否正确，certificate的内容是否有篡改。简单的说，通过CA和Certificate，我们可以获得一个可验证的的身份和信任链。

      如上图，fabric中通要使用Wallet作为EOA的载体，一个Wallet中可以包含多个Identity（x.509 certificate）。 Identity 通过 CA提供的信任链来验证正确性。

  验证了身份之后， Fabric 通过MSP在区块链网络中解决该身份是否代表组织的成员和在组织内具有什么角色。例如，channel首先会验证当前用户Identity是否是有效地身份，然后通过MSP查看其所处的企业和具有的角色，最终确定该用户是否有权执行操作。

可以说，Fabric的访问控制是通过MSP来完成的。在每一个需要访问控制的地方都需要定义一个MSP。  例如，每个channel都定义一个MSP，这个MSP规定了在channel范围内资源的访问权限。 MSP 是Fabric里一个晦涩难懂的概念，也是其赋予企业间安全访问的基础。

前文提到， Fabric 将业务处理和上网分成了三个部分， 背书，排序，验证后加入账本。

其中背书是Fabric执行智能合约的阶段。以太坊中，智能合约是在EVM中执行的，有多种语言支持。 在Fabric，智能合约被称为chaincode： 一个chaincode 可以理解为是智能合约的容器，可以包含一个或多个智能合约， 不用于EVM, chaincode是在 JVM 或NodeJS中执行。

客户应用程序通过智能合约来访问账本，每一个可访问的智能合约都被安装在客户端可以访问的节点上，并被定义在channel里。（有只能合约的节点被称为背书节点，没有只能合约的节点被称未提交节点，提交节点只维护账本）

客户应用提交一个交易请求， 请求到达背书节点， 背书节点首先会验证客户的签名，确保客户的身份有权执行本次交易，接着执行交易提及的智能合约（chaincode），并生成一个背书响应（或者叫做交易提案，tran-proposal）。这个背书响应中通常包含World state 的读集合，写集合， 以及节点对本次交易的签名。这里与以太坊系联盟链最主要的不同是： 背书阶段只模拟交易，并不真正更新交易结果。 而真正更新交易在第三阶段完成。背书节点最后将生成的背书响应fanhui给客户端， 智能合约部分的执行就结束了。

通常一个交易的执行需要多方的签名，所以客户端需要将一个交易发送给多个背书节点，这些背书节点的选择需要满足背书策略的要求。

下图是一个包含有客户、背书节点，提交节点的网络示意图。

根据Fabric官方的参考文档，客户交易的正果过程可使用下图描述。

如上图，从1到3，为背书阶段，4为排序阶段，4.1,4,2, 5为验证提交阶段。 参考 Frabic的节点 概念，可以了解更多在交易细节的概念。  

总的来看， Fabric 更专注于企业间，通过上文，可以让大家对Fabric的基本构成与概念有一个总的了解。  Fabric本身并不神秘，都是使用的现有的企业间的技术。要更好的了解，建议参考阅读分布式消息系统和企业的安全基础设施（CA相关）的支持。与以太坊系联盟链实现比较，  Fabric 的子网更概念对于复杂企业间应用适应更强，但是其复杂的安全考量，使得运营成本很高，另外，Fabric 使用Certificate做为用户身份，有很大的局限性，在新的2.0里，Fabric对于此处将有所改变。

下一篇，我们将来看看Sawtooth , 由Inter 提供的区块链框架。

区块链之联盟链(一) 认识以太坊

区块链之联盟链(二) 认识Quotum

区块链之联盟链(三) 认识Fabric

区块链之联盟链(四) 认识Sawtooth

㈢ Fabric 入门：Peer节点是什么

作为区块链产品经理，不需要太深入理解区块链的技术，但是基本的概念必须要懂，包括网络、通道、账本、节点、链码、SDK、MSP，它们之间的关系，以及数据写入的过程、数据查询的过程。

首先需要明确的是，Peer节点是一个物理的概念（与之对比，通道是一个逻辑的概念，通道并没有实体），一台服务器可以充当Peer的作用。这台服务器既可以是私有物理机，也可以是云上的资源。Peer是整个Fabric体系的基础设施，下面会解释为什么。

Peer节点存储关键的数据，并且执行特定的程序。存储的数据包括账本、链码（智能合约），执行的程序主要包括背书以及链码的执行。所有的账本查询以及账本修改必须通过链码来操作，所有的链码操作必须通过Peer节点在唤起，所以SDK或者应用需要存取账本数据时，必须通过Peer。这就是为什么说Peer是Fabric的基础设施。

二、Peer与账本和链码的关系

刚刚说了，Peer是账本和链码的物理载体，Peer可以调动链码去查询和更新账本。

一个Peer可以存储0个或者多个账本，一个Peer也可以存储0个或者多个链码。

上图中，一个Peer节点，存储了L1、L2两个账本，以及S1、S2、S3三个链码，其中账本L1可以被链码S1、S2访问到，账本L2可以被链码S1、S3访问到。

一个组织可以有一个或者多个Peer，比如下图中，组织2管理了P3、P4、P5三个Peer节点，。而一个Peer可以加入一个或者多个通道中，比如下图中，P3、P5加入到紫色的这个Channel中。

还有其他的议题：Peer分为记账节点和背书节点；发生一笔交易的时候，Peer要发生哪些操作；Peer与证书的关系。

这些议题会在介绍交易提交流程、MSP部分等部分介绍。

2018年12月6日。

㈣ Fabric上链流程

看看一笔交易的上链过程：

1. 应用提出交易，首先从客户端发起一笔交易提交到3个Endorsing Peer，该笔交易的背书政策P（E0,E1,E2必须签名），客户端应用程序为智能合约提交一个交易。它必须提交给所需的对等点{E0,E1,E2}

2. 背书节点执行提议，将签名数据，传回给客户端。E0、E1、E2将分别执行提出事务。这些执行都不会更新至账本，每次执行都将获一组读和写数据，称为读写集，交易可以签名与加密。

3. 应用接受回复，读写集将异步返回给应用程序，读写集由每个背书节点签名，并且每个都记录了版本号(这些信息将在后面的共识过程中进行核对)。

4，交易排序，Ordering Node对交易进行排序，应用程序将背书节点的响应作为交易提交给排序节点，排序与应用程序的提交并行发生在fabric上。

5.   Orderer交付给记账节点，order service将所有交易打包到区块中，然后分发给提记账节点，记账节点可以交付给同层中的其他记账节点。目前支持的排序算法:Solo(单节点，开发)，Kafka(崩溃容错)，RAFT。

6. 记账节点验证交易，每个记账节点会根据背书政策进行验证。还要检查读写集对于当前世界状态是否仍然有效。验证有效的交易，将适用于世界状态（world state）并保留在区块链账本上，无效的交易也保留在区块链账上，但不更新世界状态。

7. 记账节点通知应用程序，当交易成功或失败时，以及当区块被添加到分类账时，应用程序将收到连接的记账节点的通知(事件触发器)。

㈤ 浅析 Fabric Peer 节点

Hyperledger Fabric，也称之为超级账本，是由 IBM 发起，后成为 Linux 基金会 Hyperledger 中的区块链项目之一。

Fabric 是一个提供分布式账本解决方案的平台，底层的账本数据存储使用了区块链。区块链平台通常可以分为公有链、联盟链和私有链。公有链典型的代表是比特币这些公开的区块链网络，谁都可以加入到这个网络中。联盟链则有准入机制，无法随意加入到网络中，联盟链的典型例子就是 Fabric。

Fabric 不需要发币来激励参与方，也不需要挖矿来防止有人作恶，所以 Fabric 有着更好的性能。在Fabric 网络中，也有着诸多不同类型的节点来组成网络。其中 Peer 节点承载着账本和智能合约，是整个区块链网络的基础。在这篇文章中，会详细分析 Peer 的结构及其运行方式。

在本文中，假设读者已经了解区块链、智能合约等概念。

本文基于 Fabric1.4 LTS。

区块链网络是一个分布式的网络，Fabric 也是如此，由于 Fabric 是联盟链，需要准入机制，所以在网络结构上会复杂很多，下面是一个简化的 Fabric 网络：

各个元素的含义如下：

对于 Fabric 网络，外部的用户需要通过客户端应用，也就是图中的 A1、A2 或者 A3 来访问网络，客户端应用需要通过 CA 证书表明自己的身份，这样才能访问到 Fabric 网络中有权限访问的部分。

在上面的网络中，共有四个组织，R1、R2、R3 和 R4。其中 R4 是整个 Fabric 网络的创建者，网络是根据 NC4 配置的。

在 Fabric 网络中，不同的组织可以组成联盟，不同的联盟之间数据通过 Channel 来隔离。Channel 中的数据只有该联盟中的组织才能访问，每一个新的 Channel 都可以认为是一条新的链。与其他的区块链网络中通常只有一条链不一样，Fabric 可以通过 Channel 在网络中快速的搭建出一个新的区块链。

上面 R1 和 R2 组成了一个联盟，在 C1 上交易。R2 同时又和 R3 组成了另外一个联盟，在 C2 上交易。R1 和 R2 在 C1 上交易时，对 R3 是不可见的，R2 和 R3 在 C2 上交易时，对 R1 是不可见的。Channel 机制提供了很好的隐私保护能力。

Orderer 节点是整个 Fabric 网络共有的，用来为所有的交易排序、打包。比如上面网络中 O4 节点。本文不会对 Orderer 节点进行详细说明，可以把这个功能理解为比特币网络中的挖矿过程。

Peer 节点表示网络中的节点，通常一个 Peer 就表示一个组织，Peer 是整个区块链网络的基础，是智能合约和账本的载体，Peer 也是本文讨论的重点。

一个 Peer 节点可以承载多套账本和智能合约，比如 P2 节点，既维护了 C1 的账本和智能合约，也维护了 C2 的账本和智能合约。

为了可以更深入了解 Peer 节点的作用，先了解一下 Fabric 整体的交易流程。整体的交易流程图如下：

Peer 节点按照功能来分可以分为 背书节点 和 记账节点 。

客户端会提交交易请求到背书节点，背书节点开始模拟执行交易，在模拟执行之后，背书节点并不会去更新账本数据，而是把这个交易进行加密和签名，然后返回给客户端。

客户端收到这个响应之后就会把响应提交到 Orderer 节点，Orderer 节点会对这些交易进行排序，并打包成区块，然后分发到记账节点，记账节点就会对交易进行验证，验证结束之后，就会把交易记录到账本里面。

一笔交易是否能成功是根据背书策略来指定的，每一个智能合约都会指定一个背书策略。

Peer 节点代表着联盟链中的各个组织，区块链网络也是由 Peer 节点来组成的，而且也是账本和智能合约的载体。

通过对上面交易过程的了解可以知道，Peer 节点是主要的参与方。如果用户想要访问账本资源，都必须要和 peer 节点进行交互。在一个 Peer 节点中，可以同时维护多个账本，这些账本属于不同的 Channel 。每个 Peer 节点都会维护一套冗余账本，这样就避免了单点故障。

Peer 节点根据在交易中的不同角色，可以分成背书节点（Endorser）和记账节点（Committer），背书节点会对交易进行模拟执行，记账节点才会真正将数据存储到账本中。

账本可以分成两个部分，一部分是区块链，另一部分是 Current State，也被称之为 World State。

区块链上只能追加，不能对过去的数据进行修改，链上也包含两部分信息，一部分是通道的配置信息，另一部分是不可修改，序列化的记录。每一个区块记录前一个区块的信息，然后连成链，如下图所示：

第一个区块被称之为 genesis block，其中不存储交易信息。每个区块可以被分为 区块头 、 区块数据 和 区块元数据 。区块头中存储着当前区块的区块号、当前区块的 hash 值和上一个区块的 hash 值，这样才能把所有的区块连接起来。区块数据中包含了交易数据。区块元数据中则包括了区块写入的时间、写入人及签名。

其中每一笔交易的结构如下，在 Header 中，包含了 ChainCode 的名称、版本信息。Signature 就是交易发起用户的签名。Proposal 中主要是一些参数。Response 中是智能合约执行的结果。Endorsements 中是背书结果返回的结果。

WorldState中维护了账本的当前状态，数据以 Key-Value 的形式存储，可以快速查询和修改，每一次对 WorldState 的修改都会被记录到区块链中。WorldState 中的数据需要依赖外部的存储，通常使用 LevelDB 或者 CouchDB。

区块链和 WorldState 组成了一个完整的账本，World State 保证的业务数据的灵活变化，而区块链则保证了所有的修改是可追溯和不可篡改的。

在交易完成之后，数据已经写入账本，就需要将这些数据同步到其他的 Peer，Fabric 中使用的是 Gossip 协议。Gossip 也是 Channel 隔离的，只会在 Channel 中的 Peer 中广播和同步账本数据。

智能合约需要安装到 Peer 节点上，智能合约是访问账本的唯一方式。智能合约可以通过 Go、Java 等变成语言进行编写。

智能合约编写完成之后，需要打包到 ChainCode 中，每个 ChainCode 中可以包含多个智能合约。ChainCode 需要安装，ChainCode 需要安装到 Peer 节点上。安装好了之后，ChainCode 需要在 Channel 上实例化，实例化的时候需要指定背书策略。

智能合约在实例化之后就可以用来与账本进行交互了，流程图如下：

用户编写并部署实例化智能合约之后，就可以通过客户端应用程序来向智能合约提交请求，智能合约会对 WorldState 中数据进行 get、put 或者 delete。其中 get 操作直接从 WorldState 中读取交易对象当前的状态信息，不会去区块链上写入信息，但 put 和 delete 操作除了修改 WorldState，还会去区块链中写入一条交易信息，且交易信息不能修改。

区块链上的信息可以通过智能合约访问，也可以在客户端应用通过 API 直接访问。

Event 是客户端应用和 Fabric 网络交互的一种方式，客户端应用可以订阅 Event，当 Event 发生时，客户端应用就会接受到消息。

事件源可以两类，一类是智能合约发出的 Event，另一类是账本变更触发的 Event。用户可以从 Event 中获取到交易的信息，比如区块高度等信息。

在这篇文章中，首先介绍了 Fabric 整体的网络架构，通过对 Fabric 交易流程的分析，讨论了 peer 节点在交易中的作用，然后详细分析了 peer 节点所维护的账本和智能合约，并分析了 peer 节点维护账本以及 peer 节点执行智能合约的流程。

文 / Rayjun

[1] https://hyperledger-fabric.readthedocs.io/zh_CN/release-1.4/whatis.html

[2] https://developer.ibm.com/zh/technologies/blockchain/series/os-academy-hyperledger-fabric/

[3] https://en.wikipedia.org/wiki/Gossip_protocol

㈥ 区块链的TPS

众所周知，比特币每秒只能进行大约7笔交易，以太坊稍微好一些，也就10-20笔。作为一个支付系统，这是远远远远不够的，经常也有人拿这点来说事，认为区块链效率低云云。

其实现在有很多的方案在试图解决TPS的问题，比如说fabric可以到数千的TPS，石墨烯系列可以到上万的TPS，比特币和以太坊的Off-chain方案理论上支持无限的TPS。那么是不是说这些新的技术才是区块链的未来呢？这个问题总是很难回答，要说一大堆共识，分布式，安全之类的事情。

过年期间看了BM的一个访谈，他提到了VB的一个理论，Scalability，Decentralization和Security在区块链中不能兼顾，类似于分布式系统里面的CAP理论。

我发现这个理论用来解释区块链技术真是简单粗暴而有效。

比如说：联盟链通过准入机制，控制了验证节点的数量，通过牺牲Decentralization提升了Scalability；石墨烯系列的DPOS，RippleNet的共识也是同理；比特币通过提高每个区块的容量，也可以达到扩容的目的，但结果是对矿机提出了更高的要求，形成自然的准入门槛，实际上也是牺牲了Decentralization；比特币和以太坊挖矿难度都可以调整，降低挖矿难度实际上也可以提升Scalability，但付出的代价是抗攻击能力下降了，牺牲的是Security。

但这个理论放在off-chain类型的方案上就失效了，比如说闪电网络（雷电网络），以太坊的plasma还有R3 Corda（这个比较特殊，直接把链都省了）。对off-chain方案原理感兴趣的童鞋移步这里， http://www.8btc.com/ln-rn-corda 。大致方案就是交易双方锁定准备金，把海量的交易打包以后上链，链上只保存交易的最终结果。通过智能合约和线下的多重签名机制，作弊方将会被罚没准备金。

Off-chain方案看上去很完美，保证Decentralization和Security，同时无限扩展。

但天下没有免费的午餐，我们以闪电网络为例（事实上plasma我还没完全理解😅），至少它有下面几个缺点：

1.闪电网络中锁定的比特币只能用在闪电网络中，只有交易通道关闭的时候才能真正成为链上承认的货币，这在理论上会出现类似银行挤兑的情况。如果大家对闪电网络失去信心，集中关闭通道，会拖垮比特币网络。但，这个似乎也不是很大的问题，只要闪电网络没有爆出什么漏洞，比如说签名算法被攻破之类的。

2.交易是在链外执行，链上无法验证提交的交易是否最新版本，虽然脚本保证了提交旧版本交易的攻击者有被罚没准备金的风险，但前提是要防御者监控网络并提交更新版本交易的证据。也就是说从原来比特币的被动防御（私钥不丢失就能保证资金安全）转变成主动防御。从这个角度看也算是降低了Security吧。这个主动防御的操作交给用户也不太现实，最终必然会衍生出一些服务公司，代替用户保存链外交易凭证，并防止作弊。某种意义上面又从“去中介化的信任”转变为需要信任中介了。这个角度看，似乎也是牺牲了Decentralization。

3.闪电网络中只有保存最终的资金状态保存，中间的交易细节全部被忽略，支持者认为是保护了用户的隐私，反对者认为是损失了交易数据。

4.因为通道需要准备金维持，不可能任意两个用户间都存在交易通道，用户之间转账可以通过中转的方法，最终很可能会有大资金形成中心化的中转节点。

㈦ fabric国密改造记录及思路-具体工作(3)

七、msp成员关系服务模块改造

       (1)、fabric的成员身份基于标准的x509证书,秘钥使用的是ECDSA算法,利用PKI体系给每个成员颁发数字证书，通道内只有  相同MSP内的节点才可以通过Gossip协议进行数据分发;

       (2)、国密改造需要把x509证书修改成sm2证书,ECDSA算法修改成sm2算法；

       (3)、修改程序文件列表如下： 

             msp/identities.go

             msp/cert.go

            msp/mspimplsetup.go

            msp/mspimplvalidate.go

           msp/mspimpl.go

八、Orderer节点模块改造

       (1)、orderer节点在fabric架构中处于最核心位置,主要功能是排序打包交易，生成新的区块，然后通过共识算法将数据广播;

       (2)、orderer节点模块的共识模式有，solo单机模式,kafka消息队列模式,etcdraft一致性算法模式，最开始采用的是kafka模式，后边为了减少资源开销切换成etcdraft模式；

       (3)、如果采用kafka模式共识，需要确认kafaka的tls连接是否支持国密算法,再决定是否对kafka的tls做出修改；

       (4)、改程序文件列表如下：

             orderer/common/cluster/comm.go

             orderer/common/cluster/connections.go

             orderer/consensus/kafka/config.go

九、Peer节点模块改造

        (1)、peer可是区块链网络的基石，包含了账本和链码，应用程序或管理员都得通过节点去管理网络的资源；

        (2)、channel对应账本，一个peer节点可以接入到多个channel， 所以一个节点可以有多个账本副本;

        (3)、国密改造中对chaincode和common部分有修改;

        (4)、改程序文件列表如下：

               peer/common/common.go

               peer/common/peerclient.go

               peer/common/ordererclient.go

               peer/chaincode/common.go 

十、vendor目录国密改造

     （1）、修改程序文件列表如下：

                vendor/github.com/Shopify/sarama/config.go

总结:

       到目前为止fabric的国密修改已经完成，修改完毕后通过前面提到的编译方式进行编译，然后进行测试,如有bug再增对性的进行处理,遇到问题和解决问题是比较好的熟悉系统的方式。

㈧ (译)超级账本官方文档 基本概念(三) - 节点(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进行验证及更新账本的过程。

㈨ 主流区块链技术有哪些

本文试图对区块链有关技术流派和主流平台进行一个概览，作为学习区块链技术体系的导览，意在抛砖引玉，促进区块链开发社区的讨论与共识。区块链技术的流派未战先谋局，你想投入区块链开发这个领域，至少先要搞清楚现在有哪些玩家，各自的主张和实力如何。划分区块链技术流派并无一定之规，据我所见，或可有以下四种方式：第一是按照节点准入规则，划分为公有链、私有链和联盟链。公有链的代表自然是比特币和以太坊，私有链则以R3 Corda声名最盛，联盟链的代表作品是Hyperledger名下的Fabric。公有链注重匿名性与去中心化，而私有链及联盟链注重高效率，而且还往往设置了准入门槛。公有链、私有链与联盟链之间的这些不同都在技术中有所体现，比如私有链和联盟链假设节点数目不大，可以采用PBFT算法来形成共识。而公有链假设有大量且不断动态变化的节点网络，用PBFT效率太低，只能采用类似抽彩票的算法来确定意见领袖。这就意味着，私有链与联盟链很难变成公有链，而用公有链来作联盟链或私有链虽然容易，却也并非即插即用。此种差异，学者不可不察。第二是按照共享目标，划分为共享账本和共享状态机两派。比特币是典型的共享账本，而Chain和BigchainDB也应属此类，这几个区块链系统在各个节点之间共享一本总账，因此对接金融应用比较方便。另一大类区块链系统中，各个节点所共享的是可完成图灵完备计算的状态机，如以太坊、Fabric，它们都通过执行智能合约而改变共享状态机状态，进而达成种种复杂功能。第三是按照梅兰妮· 斯旺所描述的代际演进，将区块链系统分为1.0、2.0和3.0三代。其中1.0支撑去中心化交易和支付系统，2.0通过智能合约支撑行业应用，3.0支撑去中心化的社会体系。比特币和Chain应属于区块链1.0系统，而以太坊和Fabric是区块链2.0系统，目前尚无成功的区块链3.0系统出现，不成功的尝试倒是有那么一个，就是著名的The DAO。第四是按照核心数据结构，分为区块链和分布式总账两派。区块链这一派在系统中真的实现了一个区块的链作为核心数据结构，而分布式总账这一派，只是吸取了区块链的精神，并没有真用一条区块链作为核心数据结构，或者虽然暂时用了，但声明说吾项庄舞区块链，意在分布式总账耳，若假以时日，因缘际会，未尝不可取而代之也。主流区块链技术平台了解流派划分，仍是只能用来指点江山，吹牛论道，要动手，总要有个切入点。区块链货币据说已经有上千个了，但值得关注的技术平台大概只有数十个，而如果要进入区块链开发领域，打下一个好基础，练出一身好功夫，捞到几个好offer，则值得深入研究学习的平台，屈指可数。首先当然是比特币。比特币作为区块链的第一个也是目前为止最成功、最重要的样板工程，已经上线运行了八年多，本身没有发生任何严重的安全和运维事故，其稳定与强悍堪称当代软件系统典范。比特币Bitcoin Core是一个代码质量高、文档良好的开源软件，从学习区块链原理、掌握核心技术的角度来说，Bitcoin Core是最佳切入点，能够学到原汁原味的区块链技术。当然，Bitcoin Core是用C++写的，而且用了一些C++11和Boost库的机制，对学习者的C++水平提出了较高的要求。学习比特币平台开发还有一个优势，就是可以对接繁荣的比特币技术社区。目前围绕比特币进行改进和提升的人很多，人多力量就大，诸如隔离验证、闪电网络、侧链等比较新的想法和技术，都率先在比特币社区里落地。比如侧链技术的主要领导者Blockstream是由密码学货币元老Adam Back领衔的，而Blockstream是Bitcoin Core最大的贡献者之一，所以一些有关侧链的技术在比特币社区里讨论最充分。但比特币作为一个典型的区块链1.0系统，是不是支撑其他类型区块链应用的最佳技术平台，存在很大的争议。另外，也不是所有人都有能力和必要精通区块链底层技术。所以对那些急于冲到区块链领域里做（quān）事（qián）的人来说，可能更直截了当的学习目标是以太坊和Hyperledger Fabric。在以太坊上面用Solidity进行的智能合约开发是切入区块链开发最简单的方式，没有之一。以太坊的理想非常宏大，由于配备了强大的图灵完备的智能合约虚拟机，因此可以成为一切区块链项目的母平台，是驮住整个区块链世界的大乌龟。在以太坊上开发一个类似比特币的加密货币，是一个不折不扣的小目标。一般有经验的开发者在文档指导下，半天到一天即可入门。问题在于，入门以后又如何？靠写Solidity是否就可以包打天下？这是大大存疑的。我们也可以反过来说，如果以太坊+Solidity是区块链的终极解决方案，那么怎么还会出现那么多区块链技术门派呢？特别是，以太坊似乎并没有给现实世界中巨型的中心化组织们留下一条活路，这种彻底不妥协的革命态度有可能也成为以太坊推广的障碍。当前以太坊项目的开发进展并不顺利。一个比较突出的问题是项目过多，力量分散，导致项目质量参差不齐。但尽管如此，跟其他区块链2.0平台相比，以太坊提供的开发环境是最简单最完善的。初学区块链的人绝对有必要学习以太坊，从而对区块链和智能合约建立起一个最“正宗”的认识。主流区块链技术平台的第三支就是Fabric，它是Hyperledger的第一个也是最知名的孵化项目。 Fabric最早来自IBM的Open Blockchain项目，到2015年11月，IBM将当时已经开发完成的44,000行Go语言代码交给Linux基金会，并入Hyperledger项目之中。在2016年3月一次黑客马拉松中，Blockstream和DAH两家公司将各自的代码并入Open Blockchain，随后改名为Fabric。到目前为止，Fabric与Intel提供的Sawtooth Lake并列为Hyperledger的一级孵化项目，但前者得到的关注远超后者。从技术角度来说，Fabric思路不错，重点是满足企业商用的需求，比如解决交易量问题。众所周知，比特币最大的短板是它每秒钟7个交易的上限，完全无法满足现实需要。而Fabric目标是实现每秒钟10万交易，这个量接近刚刚过去的双十一交易量瞬时峰值，完全可以满足正常条件下的行业级应用。Fabric用Go语言开发，也提供多种语言的API。特别值得一提的是，Fabric比较充分地运用了容器技术，比如其智能合约就运行在容器当中。这也是Go语言带给Fabric的一项福利，因为Go语言静态编译部署的特征很适合开发容器中的程序。Fabric还有一些特点，比如其membership服务可以设置节点准入审查，这是典型的联盟链特征。再比如其共识算法是可定制的。Fabric的短板是体系较为复杂，虽有文档，但缺少经验的开发者学习起来障碍比较大。然而由于其定位清楚，迎合了不少企业的心态，所以已经有多家机构在基于Fabric秘密研发行业内的联盟链项目。