区块链fabric协议

1. 初识Hyperledger Fabric

Fabric是联盟链，Peer代表一系列组织，Peers是整个区块链网络的基础，因为它是账本和智能合约的载体。通过智能合约，账本通过不可篡改的方式记录了交易的全过程。

对于不能的公司来说，是有不同的业务的，不同的业务又与不同的公司相关联，需要创建多个联盟链，因此就需要创建多个channel，channel是多个特定成员之间以机密交易为目的建立的私网，一个peer可以加入多个channel，每个channel维护自己的账本，账本和账本之间是隔离的，每个channel可以维护一个或多个账本。所以为了满足复杂的交易需求，每个peer上可以安装不同的智能合约，当peer交易完成时，会发送事件通知Client。peer上还有一个Local MSP（成员服务提供器）服务，提供身份认证和加密签名等功能。

WorldState 以key-value的形式，维护着当前账本的当前信息。

智能合约（Smart Contract）是区块链的核心，定义了各个不同组织间的业务规范，创建交易并记录在账本里。多个智能合约可以打包到一个链码中。只有链码（Chaincode）部署之后，智能合约才能被应用使用。

不同于一般的链码运行在一个独立的容器，系统链码运行在peer进程上，实现了一些系统行为。

Fabric为了优化网络性能，提高安全性和可扩展性，将每个交易分到 Endorsing Peer 、 Ording-Service 和 Committting Peer 三个部分，这就需要一种安全的，可信的和可扩展的数据传输协议——Gossip Protocol。 Gossip 传输协议以随机的方式将信息散播到网络中，主要执行三个功能：

2. 区块链之联盟链（三） 认识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

3. 区块链技术如何为实体产业赋能

现在国内已经有企业将区块链技术落地到了实际的产业中，如旺链科技就将区块链应用到金融服务，医疗健康，IP版权，物联网，共享经济，通信，教育，
社会管理，慈善公益，文化娱乐等领域

4. （三）如何使用cello在fabric上创建属于自己的区块链

进入cello之前让我们来看一下当前的docker镜像

如图，如果您按照上一篇文章搭建好cello后，会看到这六个正在run的docer镜像，一切长长，下面让我们正式开始进入8080端口cello后台

注意如果提示创建失败，说明我们的docker并未开放外网IP访问，需要配置如下

修改

为

此操作是放开docker外网IP访问，然后我们重置docker

此时再去填写IP+端口2375即可

创建角色后我们登录8081端口界面

5. 各区块链架构的横向比较

各区块链架构的横向比较
时常听人们谈起区块链，从 2009 年比特币诞生至今，各式各样的区块链系统或基于区块链的应用不断被开发出来，并被应用到大量的场景中，而区块链技术本身也在不停地变化和改进。
区块链又被称为分布式账本，与之对应的则是中心化账本，比如银行。与中心化账本不同的是，分布式账本依靠的是将账本数据冗余存储在所有参与节点中，来保证账本的安全性。简单地说，区块链会用到三种底层技术：点对点网络技术、密码学技术和分布式一致性算法。而通常，区块链系统还会“免费附赠”一种被称为智能合约的功能。智能合约虽然不是区块链系统的必要组成部分，但由于区块链天生所具备的去中心化特点，使它可以很好地为智能合约提供可信的计算环境。
为了适应不同场景的需求，区块链系统在实际应用的过程中往往会需要进行各种改造，以满足特定业务的要求，比如身份认证、共识机制、密钥管理、交易频次、响应时间、隐私保护、监管要求等。而实际应用区块链系统的公司往往没有进行这种改造的能力，于是市场上慢慢出现了一些用于定制专用区块链系统的框架，采用这些框架就可以很方便地定制出适用于企业自身业务的区块链系统。
本文将对目前市场上几个典型的区块链框架进行横向对比，看看它们都有哪些特点，以及它们之间到底有哪些区别。为了保持对比的公正性，本文将只针对开源的区块链框架进行讨论。
各区块链架构的简单介绍
1、比特币
比特币(bitcoin)源自一名叫做中本聪(Satoshi Nakamoto)的人在 2008 年发表的一篇名为《比特币：一种点对点的电子现金系统》(Bitcoin: A Peer-to-PeerElectronic Cash System)的论文，文中描述了一种被他称为“比特币”的电子货币及其算法。在之后的几年里，比特币不断成长和成熟，而它的底层技术也逐渐被人们认识并抽象出来，这就是区块链技术。比特币作为区块链的鼻祖，在区块链的大家族中具有举足轻重的地位，基于比特币技术开发出的山寨币(altcoins)的数量有如天上繁星，数不胜数。
从论文中可以得知，中本聪设计比特币的目的，就是希望能够实现一种完全基于点对点网络的电子现金系统，使得在线支付能够直接由一方发起并支付给另外一方，中间不需要通过任何的中介机构。总结来说，他希望比特币的设计能够实现以下这些目标：
● 不需要中央机构就可以发行货币
● 不需要中介机构就可以支付
● 保持使用者的匿名性
● 交易无法被撤销
从电子现金系统的角度来看，以上这些目标在比特币中基本都得到了实现，但是依然有一些技术问题有待解决，比如延展性攻击、区块容量限制、区块分叉、扩展性等。
在应用场景方面，目前大量的数字货币项目都是基于比特币架构来设计的，此外还有一些比较实际的应用案例，比如彩色币、t? 等。
彩色币(coloredcoin)，通过仔细跟踪一些特定比特币的来龙去脉，可以将它们与其他的比特币区分开来，这些特定的比特币就叫作彩色币。它们具有一些特殊的属性，从而具有与比特币面值无关的价值，利用彩色币的这种特性，使得开发者可以在比特币网络上创建其它的数字资产。彩色币本身就是比特币，存储和转移不需要第三方，可以利用已经存在的比特币的基础。
t? 是比特币区块链在金融领域的应用，是美国在线零售商 Overstock 推出的基于区块链的私有和公有股权交易平台。
2、以太坊
以太坊(ethereum) 的目标是提供一个带有图灵完备语言的区块链，用这种语言可以创建合约来编写任意状态转换功能，用户只要简单地用几行代码来实现逻辑，就能够创建一个基于区块链的应用程序，并应用于货币以外的场景。
以太坊的设计思想是不直接“支持”任何应用，但图灵完备的编程语言意味着理论上任意的合约逻辑和任何类型的应用都可以被创建出来。总结来说，以太坊在比特币的设计目标之外，还需要实现以下几个目标：
● 图灵完备的合约语言
● 内置的持久化状态存储
目前基于以太坊的合约项目已达到数百个，比较有名的有 Augur、TheDAO、Digix、FirstBlood 等。
Augur 是一个去中心化的预测市场平台，基于以太坊区块链技术。用户可以用数字货币进行预测和下注，依靠群众的智慧来预判事件的发展结果，可以有效地消除对手方风险和服务器的中心化风险。
限于篇幅，基于以太坊智能合约平台的项目就不多介绍了。基于以太坊的代码进行改造的区块链项目也有不少，但几乎都是闭源项目，只能依靠一些公开的特性来推断，所以就不在本文展开讨论了。
3、Fabric
Fabric 是由 IBM 和 DAH 主导开发的一个区块链框架，是超级帐本的项目成员之一。它的功能与以太坊类似，也是一个分布式的智能合约平台。但与以太坊和比特币不同的是，它从一开始就是一个框架，而不是一个公有链，也没有内置的代币(token)。
超级账本(hyperledger)是 Linux 基金会于 2015 年发起的推进区块链技术和标准的开源项目，加入成员包括：荷兰银行(ABN AMRO)、埃森哲(Accenture)等十几个不同利益体，目标是让成员共同合作，共建开放平台，满足来自多个不同行业各种用户案例，并简化业务流程。
作为一个区块链框架，Fabric 采用了松耦合的设计，将共识机制、身份验证等组件模块化，使之在应用过程中可以方便地替换成自定义的模块。除此之外，Fabric 还采用了容器技术，将智能合约代码(chaincode)放在 docker 中运行，从而使得智能合约可以用几乎任意的高级语言来编写。
以下是 Fabric 的一些设计目标：
● 模块化设计，组件可替换
● 运行于 docker 的智能合约
目前已经有不少采用 Fabric 架构进行开发的概念验证(POC)项目在实施过程中，其中不乏一些金融机构做出的尝试，不过由于项目刚刚起步，还没有比较成熟的落地应用。
4、DNA
DNA(Distributed Networks Architecture，分布式网络架构)，是由总部位于上海的区块链创业公司“分布科技”开发的区块链架构，可以同时支持公有链、联盟链、私有链等不同应用类型和场景，并快速与业务系统集成。
与以太坊、Fabric不同的是，DNA 在系统底层实现了对多种数字资产的支持，用户可以直接在链上创建自己的资产类型，并用智能合约来控制它的发行逻辑。对于绝大部分的区块链应用场景，数字资产是必不可少的，而为每一种数字资产都开发一套基于智能合约的转账、发行逻辑是非常浪费且低效的。因此，由区块链底层提供直接的数字资产功能是十分必要的。而对于那些完全不需要数字资产的应用场景，同样可以基于 DNA 提供的智能合约架构来编写任意的自定义逻辑来实现。
DNA 的设计目标主要有以下几点：
● 多种数字资产的底层支持
● 图灵完备的智能合约和状态持久化
● 跨链互操作性
● 交易的最终性
目前已有不少金融机构采用 DNA 架构来进行区块链概念验证产品的开发。除此之外，还有一些已经落地的区块链项目，如小蚁区块链、法链等。
小蚁(antshares)是一个定位于资产数字化的公有链，将实体世界的资产和权益进行数字化，通过点对点网络进行登记发行、转让交易、清算交割等金融业务的去中心化网络协议。它采用社区化开发的模式，在架构上与 DNA 保持一致，从而可以与任何基于DNA 的区块链系统发生跨链互操作。
法链是全球第一个大规模商用的法律存证区块链，一个底层基于 DNA区块链技术，并由多个机构参与建立和运营的证据记录和保存系统。该系统没有中心控制点，且数据一旦录入，单个机构或节点无法篡改，从而满足司法存证的要求。
5、Corda
Corda 是由一家总部位于纽约的区块链创业公司 R3CEV 开发的，由其发起的 R3区块链联盟，至今已吸引了数十家巨头银行的参与，其中包括富国银行、美国银行、纽约梅隆银行、花旗银行、德国商业银行、德意志银行、汇丰银行、三菱 UFJ 金融集团、摩根士丹利、澳大利亚国民银行、加拿大皇家银行、瑞典北欧斯安银行（SEB）、法国兴业银行等。
从 R3 成员的组成上也可以看出，Corda 是一款专门用于银行与银行间业务的区块链架构。尽管 R3 自己声称 Corda 不是区块链，但从各项特征来看，它具备区块链的一些特性。
技术对比
1、数字资产
接下来，将对前文中提到的这些区块链框架进行一系列的技术对比，并从多个维度展开介绍它们的区别与相似之处。

区块链的内置代币通常是一种经济激励模型和防止垃圾交易的手段。比特币天生就有且只有一种内置代币，所以在比特币系统中所有的“交易”本质上都是转账行为，除非通过外部的协议层来给比特币增加额外的数字资产。
以太坊和 DNA 具有内置代币，它们的作用除了以上提到的经济激励和防止垃圾交易之外，还具有为系统内置功能提供一个收费的渠道。比如以太坊的智能合约运行需要消耗 GAS，而 DNA 的数字资产创建也需要消耗一定的代币。
以太坊和 Fabric 没有内置的多种数字资产支持，而是通过智能合约来实现相应的功能。这种方式的好处在于，系统设计可以做到非常简洁，而且资产的行为可以任意指定，自由度极高。然而这样的设计也会带来一系列的负面影响，比如所有的资产创建者不得不自己编写重复的业务逻辑，而用户也没有办法通过统一的方式去操作自己的资产。
相比之下，DNA 和 Corda 采用了在底层支持多种数字资产的方式，让资产创建者可以方便地创建自己的资产类型，而用户也可以在同一个客户端中管理所有的资产。对于逻辑更加复杂一点的业务场景来说，他们同样可以利用智能合约来强化资产的功能，或者创建一种与资产无关的业务逻辑。
2、账户系统

UTXO(Unspent Transaction Output)是这样一种机制：每一枚数字货币都会被登记在一个账户的所有权之下，一枚数字货币有两种状态，即要么还没有被花费，要么已经被花费。当需要使用一枚数字货币的时候，就将它的状态标记为已经花费，并创造一枚新的与之等额的数字货币，将它的所有权登记到新的账户之下。在这个过程中，被标记为已花费的数字货币就被称为交易的输入，而创造出来的新的数字货币被称为交易的输出，在一笔交易中，可以包含多个输入和多个输出，但是输入之和与输出之和必须相等。要计算一个账户的余额时，只要将所有登记在该账户下的数字货币的面额相加即可得出。
比特币和 Corda 就采用了 UTXO 这样一种账户机制，而以太坊则采用了更加直观的余额机制：每个账户有一个状态，状态中直接记录了账户当前的余额，转账的逻辑就是从一个账户中减去一部分余额，并在另一个账户中加上相应的余额，减去的部分和加上的部分必须相等。DNA 在账户机制上同时兼容这两种模式。
那么 UTXO 模式和余额模式，究竟有什么优缺点呢？UTXO 最大的好处就是，基于 UTXO 的交易可以并行验证且任意排序，因为所有的 UTXO 之间都是没有关联的，这对区块链未来的伸缩性是有很大帮助的，而基于余额的设计就没有这个优势了；反过来，余额设计的优点是设计思想非常简洁和直觉化，便于程序实现，特别是在智能合约中，要处理 UTXO 的状态是非常困难的。这也是为什么以智能合约为主要功能的以太坊选择余额设计的原因，而比特币、OnchainDNA、Corda 这些以数字资产为核心的架构则更倾向于 UTXO 设计。
关于身份认证，比特币和以太坊基本没有身份认证的设计，原因很简单，因为这两者的设计思想都是强调隐私和匿名，而反对监管和中心化，而身份认证就势必要引入一些中心或者弱化的中心机构。Fabric、DNA 和 Corda 不约而同地选择了采用数字证书来对用户身份进行认证，原因在于这三者都有应用于现有金融系统的设计目标，而金融系统必然要考虑合规化并接受监管，此外现有的金融系统已经大范围地采用数字证书方案，这样便可以和区块链系统快速集成。

6. 浅析 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

7. 区块链 --- 共识算法

PoW算法是一种防止分布式服务资源被滥用、拒绝服务攻击的机制。它要求节点进行适量消耗时间和资源的复杂运算，并且其运算结果能被其他节点快速验算，以耗用时间、能源做担保，以确保服务与资源被真正的需求所使用。

PoW算法中最基本的技术原理是使用哈希算法。假设求哈希值Hash(r)，若原始数据为r（raw），则运算结果为R（Result）。

R = Hash(r)

哈希函数Hash()的特性是，对于任意输入值r，得出结果R，并且无法从R反推回r。当输入的原始数据r变动1比特时，其结果R值完全改变。在比特币的PoW算法中，引入算法难度d和随机值n，得到以下公式：

Rd = Hash(r+n)

该公式要求在填入随机值n的情况下，计算结果Rd的前d字节必须为0。由于哈希函数结果的未知性，每个矿工都要做大量运算之后，才能得出正确结果，而算出结果广播给全网之后，其他节点只需要进行一次哈希运算即可校验。PoW算法就是采用这种方式让计算消耗资源，而校验仅需一次。

 

PoS算法要求节点验证者必须质押一定的资金才有挖矿打包资格，并且区域链系统在选定打包节点时使用随机的方式，当节点质押的资金越多时，其被选定打包区块的概率越大。

POS模式下，每个币每天产生1币龄，比如你持有100个币，总共持有了30天，那么，此时你的币龄就为3000。这个时候，如果你验证了一个POS区块，你的币龄就会被清空为0，同时从区块中获得相对应的数字货币利息。

节点通过PoS算法出块的过程如下：普通的节点要成为出块节点，首先要进行资产的质押，当轮到自己出块时，打包区块，然后向全网广播，其他验证节点将会校验区块的合法性。

 

DPoS算法和PoS算法相似，也采用股份和权益质押。

但不同的是，DPoS算法采用委托质押的方式，类似于用全民选举代表的方式选出N个超级节点记账出块。

选民把自己的选票投给某个节点，如果某个节点当选记账节点，那么该记账节点往往在获取出块奖励后，可以采用任意方式来回报自己的选民。

这N个记账节点将轮流出块，并且节点之间相互监督，如果其作恶，那么会被扣除质押金。

通过信任少量的诚信节点，可以去除区块签名过程中不必要的步骤，提高了交易的速度。
 

拜占庭问题：

拜占庭是古代东罗马帝国的首都，为了防御在每块封地都驻扎一支由单个将军带领的军队，将军之间只能靠信差传递消息。在战争时，所有将军必须达成共识，决定是否共同开战。

但是，在军队内可能有叛徒，这些人将影响将军们达成共识。拜占庭将军问题是指在已知有将军是叛徒的情况下，剩余的将军如何达成一致决策的问题。

BFT：

BFT即拜占庭容错，拜占庭容错技术是一类分布式计算领域的容错技术。拜占庭假设是对现实世界的模型化，由于硬件错误、网络拥塞或中断以及遭到恶意攻击等原因，计算机和网络可能出现不可预料的行为。拜占庭容错技术被设计用来处理这些异常行为，并满足所要解决的问题的规范要求。

拜占庭容错系统 ：

发生故障的节点被称为 拜占庭节点 ，而正常的节点即为 非拜占庭节点 。

假设分布式系统拥有n台节点，并假设整个系统拜占庭节点不超过m台（n ≥ 3m + 1），拜占庭容错系统需要满足如下两个条件：

另外，拜占庭容错系统需要达成如下两个指标：

PBFT即实用拜占庭容错算法，解决了原始拜占庭容错算法效率不高的问题，算法的时间复杂度是O(n^2)，使得在实际系统应用中可以解决拜占庭容错问题
 

PBFT是一种状态机副本复制算法，所有的副本在一个视图（view）轮换的过程中操作，主节点通过视图编号以及节点数集合来确定，即：主节点 p = v mod |R|。v：视图编号，|R|节点个数，p：主节点编号。

PBFT算法的共识过程如下：客户端（Client）发起消息请求（request），并广播转发至每一个副本节点（Replica），由其中一个主节点（Leader）发起提案消息pre-prepare，并广播。其他节点获取原始消息，在校验完成后发送prepare消息。每个节点收到2f+1个prepare消息，即认为已经准备完毕，并发送commit消息。当节点收到2f+1个commit消息，客户端收到f+1个相同的reply消息时，说明客户端发起的请求已经达成全网共识。

具体流程如下 ：

客户端c向主节点p发送<REQUEST, o, t, c>请求。o: 请求的具体操作，t: 请求时客户端追加的时间戳，c：客户端标识。REQUEST: 包含消息内容m，以及消息摘要d(m)。客户端对请求进行签名。

主节点收到客户端的请求，需要进行以下交验：

a. 客户端请求消息签名是否正确。

非法请求丢弃。正确请求，分配一个编号n，编号n主要用于对客户端的请求进行排序。然后广播一条<<PRE-PREPARE, v, n, d>, m>消息给其他副本节点。v：视图编号，d客户端消息摘要，m消息内容。<PRE-PREPARE, v, n, d>进行主节点签名。n是要在某一个范围区间内的[h, H]，具体原因参见 垃圾回收 章节。

副本节点i收到主节点的PRE-PREPARE消息，需要进行以下交验：

a. 主节点PRE-PREPARE消息签名是否正确。

b. 当前副本节点是否已经收到了一条在同一v下并且编号也是n，但是签名不同的PRE-PREPARE信息。

c. d与m的摘要是否一致。

d. n是否在区间[h, H]内。

非法请求丢弃。正确请求，副本节点i向其他节点包括主节点发送一条<PREPARE, v, n, d, i>消息, v, n, d, m与上述PRE-PREPARE消息内容相同，i是当前副本节点编号。<PREPARE, v, n, d, i>进行副本节点i的签名。记录PRE-PREPARE和PREPARE消息到log中，用于View Change过程中恢复未完成的请求操作。

主节点和副本节点收到PREPARE消息，需要进行以下交验：

a. 副本节点PREPARE消息签名是否正确。

b. 当前副本节点是否已经收到了同一视图v下的n。

c. n是否在区间[h, H]内。

d. d是否和当前已收到PRE-PPREPARE中的d相同

非法请求丢弃。如果副本节点i收到了2f+1个验证通过的PREPARE消息，则向其他节点包括主节点发送一条<COMMIT, v, n, d, i>消息，v, n, d, i与上述PREPARE消息内容相同。<COMMIT, v, n, d, i>进行副本节点i的签名。记录COMMIT消息到日志中，用于View Change过程中恢复未完成的请求操作。记录其他副本节点发送的PREPARE消息到log中。

主节点和副本节点收到COMMIT消息，需要进行以下交验：

a. 副本节点COMMIT消息签名是否正确。

b. 当前副本节点是否已经收到了同一视图v下的n。

c. d与m的摘要是否一致。

d. n是否在区间[h, H]内。

非法请求丢弃。如果副本节点i收到了2f+1个验证通过的COMMIT消息，说明当前网络中的大部分节点已经达成共识，运行客户端的请求操作o，并返回<REPLY, v, t, c, i, r>给客户端，r：是请求操作结果，客户端如果收到f+1个相同的REPLY消息，说明客户端发起的请求已经达成全网共识，否则客户端需要判断是否重新发送请求给主节点。记录其他副本节点发送的COMMIT消息到log中。
 

如果主节点作恶，它可能会给不同的请求编上相同的序号，或者不去分配序号，或者让相邻的序号不连续。备份节点应当有职责来主动检查这些序号的合法性。

如果主节点掉线或者作恶不广播客户端的请求，客户端设置超时机制，超时的话，向所有副本节点广播请求消息。副本节点检测出主节点作恶或者下线，发起View Change协议。

View Change协议 ：

副本节点向其他节点广播<VIEW-CHANGE, v+1, n, C , P , i>消息。n是最新的stable checkpoint的编号， C 是 2f+1验证过的CheckPoint消息集合， P 是当前副本节点未完成的请求的PRE-PREPARE和PREPARE消息集合。

当主节点p = v + 1 mod |R|收到 2f 个有效的VIEW-CHANGE消息后，向其他节点广播<NEW-VIEW, v+1, V , O >消息。 V 是有效的VIEW-CHANGE消息集合。 O 是主节点重新发起的未经完成的PRE-PREPARE消息集合。PRE-PREPARE消息集合的选取规则：

副本节点收到主节点的NEW-VIEW消息，验证有效性，有效的话，进入v+1状态，并且开始 O 中的PRE-PREPARE消息处理流程。
 

在上述算法流程中，为了确保在View Change的过程中，能够恢复先前的请求，每一个副本节点都记录一些消息到本地的log中，当执行请求后副本节点需要把之前该请求的记录消息清除掉。

最简单的做法是在Reply消息后，再执行一次当前状态的共识同步，这样做的成本比较高，因此可以在执行完多条请求K（例如：100条）后执行一次状态同步。这个状态同步消息就是CheckPoint消息。

副本节点i发送<CheckPoint, n, d, i>给其他节点，n是当前节点所保留的最后一个视图请求编号，d是对当前状态的一个摘要，该CheckPoint消息记录到log中。如果副本节点i收到了2f+1个验证过的CheckPoint消息，则清除先前日志中的消息，并以n作为当前一个stable checkpoint。

这是理想情况，实际上当副本节点i向其他节点发出CheckPoint消息后，其他节点还没有完成K条请求，所以不会立即对i的请求作出响应，它还会按照自己的节奏，向前行进，但此时发出的CheckPoint并未形成stable。

为了防止i的处理请求过快，设置一个上文提到的 高低水位区间[h, H] 来解决这个问题。低水位h等于上一个stable checkpoint的编号，高水位H = h + L，其中L是我们指定的数值，等于checkpoint周期处理请求数K的整数倍，可以设置为L = 2K。当副本节点i处理请求超过高水位H时，此时就会停止脚步，等待stable checkpoint发生变化，再继续前进。
 

在区块链场景中，一般适合于对强一致性有要求的私有链和联盟链场景。例如，在IBM主导的区块链超级账本项目中，PBFT是一个可选的共识协议。在Hyperledger的Fabric项目中，共识模块被设计成可插拔的模块，支持像PBFT、Raft等共识算法。
 

 

Raft基于领导者驱动的共识模型，其中将选举一位杰出的领导者(Leader)，而该Leader将完全负责管理集群，Leader负责管理Raft集群的所有节点之间的复制日志。
 

下图中，将在启动过程中选择集群的Leader（S1），并为来自客户端的所有命令/请求提供服务。 Raft集群中的所有节点都维护一个分布式日志（复制日志）以存储和提交由客户端发出的命令（日志条目）。 Leader接受来自客户端的日志条目，并在Raft集群中的所有关注者（S2，S3，S4，S5）之间复制它们。

在Raft集群中，需要满足最少数量的节点才能提供预期的级别共识保证， 这也称为法定人数。 在Raft集群中执行操作所需的最少投票数为 (N / 2 +1) ，其中N是组中成员总数，即 投票至少超过一半 ，这也就是为什么集群节点通常为奇数的原因。 因此，在上面的示例中，我们至少需要3个节点才能具有共识保证。

如果法定仲裁节点由于任何原因不可用，也就是投票没有超过半数，则此次协商没有达成一致，并且无法提交新日志。

 

数据存储：Tidb/TiKV

日志：阿里巴巴的 DLedger

服务发现：Consul& etcd

集群调度：HashiCorp Nomad
 

只能容纳故障节点(CFT)，不容纳作恶节点

顺序投票，只能串行apply，因此高并发场景下性能差
 

Raft通过解决围绕Leader选举的三个主要子问题，管理分布式日志和算法的安全性功能来解决分布式共识问题。

当我们启动一个新的Raft集群或某个领导者不可用时，将通过集群中所有成员节点之间协商来选举一个新的领导者。 因此，在给定的实例中，Raft集群的节点可以处于以下任何状态: 追随者(Follower)，候选人(Candidate)或领导者(Leader)。

系统刚开始启动的时候，所有节点都是follower，在一段时间内如果它们没有收到Leader的心跳信号，follower就会转化为Candidate；

如果某个Candidate节点收到大多数节点的票，则这个Candidate就可以转化为Leader，其余的Candidate节点都会回到Follower状态；

一旦一个Leader发现系统中存在一个Leader节点比自己拥有更高的任期(Term)，它就会转换为Follower。

Raft使用基于心跳的RPC机制来检测何时开始新的选举。 在正常期间， Leader 会定期向所有可用的 Follower 发送心跳消息（实际中可能把日志和心跳一起发过去）。 因此，其他节点以 Follower 状态启动，只要它从当前 Leader 那里收到周期性的心跳，就一直保持在 Follower 状态。

当 Follower 达到其超时时间时，它将通过以下方式启动选举程序：

根据 Candidate 从集群中其他节点收到的响应，可以得出选举的三个结果。

共识算法的实现一般是基于复制状态机（Replicated state machines），何为 复制状态机 ：

简单来说： 相同的初识状态 + 相同的输入 = 相同的结束状态 。不同节点要以相同且确定性的函数来处理输入，而不要引入一下不确定的值，比如本地时间等。使用replicated log是一个很不错的注意，log具有持久化、保序的特点，是大多数分布式系统的基石。

有了Leader之后，客户端所有并发的请求可以在Leader这边形成一个有序的日志（状态）序列，以此来表示这些请求的先后处理顺序。Leader然后将自己的日志序列发送Follower，保持整个系统的全局一致性。注意并不是强一致性，而是 最终一致性 。

日志由有序编号（log index）的日志条目组成。每个日志条目包含它被创建时的任期号（term），和日志中包含的数据组成，日志包含的数据可以为任何类型，从简单类型到区块链的区块。每个日志条目可以用[ term, index, data]序列对表示，其中term表示任期， index表示索引号，data表示日志数据。

Leader 尝试在集群中的大多数节点上执行复制命令。 如果复制成功，则将命令提交给集群，并将响应发送回客户端。类似两阶段提交(2PC)，不过与2PC的区别在于，leader只需要超过一半节点同意（处于工作状态）即可。

leader 、 follower 都可能crash，那么 follower 维护的日志与 leader 相比可能出现以下情况

当出现了leader与follower不一致的情况，leader强制follower复制自己的log， Leader会从后往前试 ，每次AppendEntries失败后尝试前一个日志条目（递减nextIndex值）， 直到成功找到每个Follower的日志一致位置点（基于上述的两条保证），然后向后逐条覆盖Followers在该位置之后的条目 。所以丢失的或者多出来的条目可能会持续多个任期。
 

要求候选人的日志至少与其他节点一样最新。如果不是，则跟随者节点将不投票给候选者。

意味着每个提交的条目都必须存在于这些服务器中的至少一个中。如果候选人的日志至少与该多数日志中的其他日志一样最新，则它将保存所有已提交的条目，避免了日志回滚事件的发生。

即任一任期内最多一个leader被选出。这一点非常重要，在一个复制集中任何时刻只能有一个leader。系统中同时有多余一个leader，被称之为脑裂（brain split），这是非常严重的问题，会导致数据的覆盖丢失。在raft中，两点保证了这个属性：

因此， 某一任期内一定只有一个leader 。
 

当集群中节点的状态发生变化（集群配置发生变化）时，系统容易受到系统故障。 因此，为防止这种情况，Raft使用了一种称为两阶段的方法来更改集群成员身份。 因此，在这种方法中，集群在实现新的成员身份配置之前首先更改为中间状态（称为联合共识）。 联合共识使系统即使在配置之间进行转换时也可用于响应客户端请求，它的主要目的是提升分布式系统的可用性。

8. 超级账本之——Fabric

目前超级账本下面有5个并行的项目，Fabric属于其中较为成熟的一个。这个项目由，来自28个不同组织的159名工程师参与开发。

在Fabric的区块链网络中，有四类节点：MSP，Ordering Node，Endorsing Peer，Commtting Peer

MSP(Membership Service Provider), 这类节点主管区块链网络中其他的节点的授权，准入，踢除。通过给不同节点颁发证书的方式，授予不同类型的节点相应的权限。

中文可以称作排序节点。通常在一个网络中至少有一个或多个排序节点，这类节点负责 按照指定的算法，将交易进行排序，并返回给Committing Peer。其并不关心具体的交易细节。

这类节点的主要负责接收交易请求，验证这笔交易之后，并做一些预处理之后，并将签名后的数据传回给客户端。

这类节点做是区块链网络中的全节点，它们需要记录完整的区块信息，并且验证每笔交易的正确性，是最终将交易打包进区块链的节点。

结合下面这种图，看看一笔交易的上链过程：

1，首先从客户端发起一笔交易提交到Endorsing Peer，进行预处理。

2，预处理通过之后，将签名数据，传回给客户端。

3，客户端发起请求，将收到的签名数据传给Ordering Node。

4，Ordering Node对交易进行排序，然后传给Committing Peer。

5，Committing Peer这里将排序好的交易进行验证，并打包，通过指定的共识算法达成一致，形成新的区块。

6，最后将交易结果返回给客户端。

6，中间过程的每一步，都伴随着权限的验证。会根据MSP颁发的证书，进行判断。

9. 如何创建属于自己的 fabric 区块链

这个是需要借助平台进行创建。
IBM中国研究院开发的超能云（SuperVessel）平台提供了给区块链爱好者、开发者的区块链开发测试环境。通过该平台，用户能够免费、超快速创建基于Hyperledger Fabric的多节点区块链、并在自己的链上花式玩转智能合约。
当然，国外的去中心化内容分享平台DECENT也是可以创建的。