区块链技术分享 HyperLedger Fabric1.0架构解析

Hyperledger fabirc 1.0逻辑架构

区块链服务（BlockChain）负责节点之间的共识管理，账本的分布式计算，账本的存储以及节点间的P2P协议功能的实现，是区块链核心组成部分，为区块链的主体功能提供了底层支撑。

成员管理（Membership）会员注册，身份保护，内容保密，交易审计功能，以保证平台访问的安全性。

ChainCode的集成平台，为ChainCode提供了部署运行的环境。

Event贯穿于其他各个组件中间，为各个组件间的异步通信提供了技术实现。

HyperLedger Fabric1.0区块链网络

链=Peers+Ledger+Ordering Channel

链将参与者和数据（包含chaincode）进行隔离，一个Peer节点可以参与多个链。

从这张HyperLedger Fabric1.0区块链网络途中可以看到每个组织结构下可有由多个节点构成，可以有多个背书节点，多个提交节点，由多个节点构成一个组，多个组加上共识节点形成完整的区块链网络。

这个区块链网络中大概分为两个chain，绿色部分形成一个chain，紫色部分形成一个chain，在这个chain中一个节点可以参与到多个节点中，这样可以通过chain的方式把参与者个参与者对应的数据进行分离。

HyperLedger Fabric1.0运行时架构图

对于事务的打包过程单独拆分，这样可以形成一个共识独立节点，提供可拔插的一种实现逻辑

区块组成可以理解为一组事务按照一定顺序进行打包的过程形成的一个block（区块）

区块链本身处理的数据是事务，对于Fabric来说事务就是一次ChainCode的调用

上图中为事务处理的过程，由应用提起TransactionPropsal然后由节点对这个Propsal进行ChainCode的执行，在ChainCode执行完成之后peer节点，背书借点，共识节点需要对这个事务进行背书，共识的管理，以及对背书的结果进行验证之后写入账本

事务类型有三种：

1.Chain code

2. Configuracon

3.Custom

当一个节点加入/去除都会形成一个 Configuracon事务

事务处理流

由应用向一个或多个节点发送对事物的背书请求；背书请求节点执行ChainCode，但不会将结果提交到本地账本，只是将结果返回给应用；应用收集所有背书节点的结果后，将结果广播给Orderers；Orderers执行共识过程，并生成Block，通过消息通道批量的将Block发布给Peer节点；各个Peer节点验证交易，并提交到本地账本中。

事务流（Peer节点中）

当每一个节点部署一个新的ChainCode时，系统会自动给ChainCode关联两个系统的ChainCode一个是背书（ESCC）一个是验证（VSCC），其中ESCC决定如何对Proposal进行背书，VSCC决定事务的有效性（包括对背书的正确性）。

当一个应用将Peoposal提交给节点后，每一个节点会运行智能合约（ChainCode），当智能合约运行完成后，系统会调用ESCC对整个结果进行背书，背书完成后将结果返回应用，应用将结果提交给共识节点形成Block后，这个Block重新传给每一个peer节点，peer节点调用VSCC进行效验，包括背书本身的效验，完成后写入到本地账本中。

账本

对于Fabric来讲账本分为两个部分

1.Block结构：文件系统方式存储

2.State状态：KV数据库维护

这两个部分是存在关联关系的，当这两个部分结合到一起后就可以完整的描述账户中有多少资产，发生了几次交易，交易过后还有多少资产，这样可以保证整个账户的历史过程可以被追踪。

State的存储结构是可以替换的，可选实现包括各种KV数据库（LeveLDB，CouchDB等）。

今天就分享这么多，有什么不对的和不足的欢迎各位指出，大家一起交流，一起学习。