主流区块链技术特点及Hyperledger Fabric V1.0版本特点

一、主流区块链技术特点

二、Hyperledger fabric V1.0 架构

1、逻辑架构：

2、区块链网络

3、运行时架构

3、Fabric 1.0 交易的生命周期

    1、客户端创建交易提案(chaincode函数和参数)，并发送交Endorse Peer(背书节点);
    2、Endorse Peer执行chaincode，基于读取和写入的Key生成读写操作集;
    3、Endorse Peer向客户端返回提案结果(包含读写操作集);
    4、客户端把交易提交到Order Service，交易包含来自提案结果的读写操作集;
    5、Order Service将排完序的交易封装到区块中去;
    6、区块将被发送到Commit Peer;
    7、Commit Peer执行以下操作：
        运行验证逻辑(VSCC检查背书策略，MSCC检查读操作的版本自仿真交易以来未在数据库中被修改);
        在区块中指明哪些交易是有效和无效的;
        在内存或文件系统中把区块加入区块链，并将区块内的有效交易写入状态数据库;
        触发Event消息，使得客户端通过SDK侦听知道哪些交易有效的或无效得;

三、架构总结

1、架构要点

　　分拆Peer的功能，将Blockchain的数据维护和共识服务进行分离，共识服务从Peer节点中完全分离出来，独立为Orderer节点提供共识服务； 基于新的架构，实现多通道（channel）的结构，实现了更为灵活的业务适应性（业务隔离、安全性等方面） 支持更强的配置功能和策略管理功能，进一步增强系统的灵活性和适应性；

2、架构目标

　　1、chaincode信任的灵活性：支持多个ordering服务节点，增强共识的容错能力和对抗orderer作恶的能力    
　　2、 扩展性： 将endorsement和ordering进行分离，实现多通道（实际是分区）结构，增强系统的扩展性；同时也将chaincode执行、ledger、state维护等非常消耗系统性能的任务与共识任务分离，保证了关键任务（ordering）的可靠执行     
　　3、保密性：新架构对于chaincode在数据更新、状态维护等方面提供了新的保密性要求，提高系统的业务、安全方面的能力     
　　4、共识服务的模块化：支持可插拔的共识结构，支持多种共识服务的接入和服务实现

3、重要特征【支持多chain和多channel】

多链chain

　　所谓的chain（链）实际上是包含Peer节点、账本、ordering通道的逻辑结构，它将参与者与数据（包含chaincode在）进行隔离，满足了不同业务场景下的”不同的人访问不同数据“的基本要求。同时，一个peer节点也可以参与到多个chain中（通过接入多个channel）；如下图所示

 多通道

　　通道是有共识服务（ordering）提供的一种通讯机制，类似于消息系统中的发布-订阅（PUB/SUB)中的topic；基于这种发布-订阅关系，将peer和orderer连接在一起，形成一个个具有保密性的通讯链路（虚拟），实现了业务隔离的要求；通道也与账本（ledger）-状态（worldstate）紧密相关；如下图所示：

　　peer 1,2和N订阅红色通道，并共同维护红色账本; peer 1和N订阅蓝色通道并维护蓝色账本; 类似地，peer 2和peer N在黑色通道上并维护黑色账本。

　　在这个例子中，peer N在订阅了所有通道，我们看到每个通道都有一个相关的账本。 一般来说，我们称不涉及所有peer的账本为子账本，另一种是系统账本，即全账本。

　　通道和账本的组合是一个虚拟链，因此一个区块链网络可以具有1个共识服务的多个链。 系统通道和全账本构成系统链。 每个区块链网络只有1个系统链。如果交易是公开的，区块链网络可能永远不需要多个链; 所有的交易对所有Peers成员都可见。 然而，在成员间进行私密交易（例如双边合同），单独的链是隔离数据、提供保密的方式。

4、交易（数据）流程说明

　　事物

　　事物处理流程【交易流程】，如下：

1. 应用程序通过SDK发送请求道Peer节点（一个或多个）
2. peer节点分别执行交易（通过chaincode），但是并不将执行结果提交到本地的账本中（可以认为是模拟执行，交易处于挂起状态），参与背书的peer将执行结果返回给应用程序（其中包括自身对背书结果的签名）
3. 应用程序 收集背书结果并将结果提交给Ordering服务节点
4. Ordering服务节点执行共识过程并生成block，通过消息通道发布给Peer节点，由peer节点各自验证交易并提交到本地的ledger中（包括state状态的变化）

　　事务流（peer节点内）

 　　上述过程对应的执行序列图如下：

5、账本

　　总体流程如下图所示：在新的架构中，Peer节点负责维护区块链的账本（ledger）和状态（State），本地的账本称为PeerLedger，其结构如下：

　　整个区块结构分为文件系统存储的Block结构和数据库维护的State状态，其中state的存储结构是可以替换的，可选的实现包括各种KV数据库（LEVELDB，CouchDB等）；

四、整体账本设计详述

 五、1.0版本的版本计划

　　很明显Febric V0.6与V1.0的架构及流程差异极大，在V0.6下开发的应用很难在V1.0环境下运行，所以我们还是不要费劲折腾V0.6，还是从V1.0开始吧！（官方公布的计划）