Hyperledger Fabric 1.0分析

  Hyperledger是linux基金会于2015年发起的推进区块链数字技术和交易验证的开源项目,有多个子集,Fabric是其中最成熟的一个,其由IBM 和Digital Asset最初贡献给Hyperledger项目。Fabric面向的对象主要是联盟链以及私有链等对于加入的节点需要设置一定准入门槛的区块链项目,其也是目前最有希望投入实际运用的区块链。

  Fabric是由很多相互通信的节点组成的分布式系统,其上运行的程序称为链码chaincode,保存状态和总账数据,并执行交易。交易必须要获得背书,只有背过书的交易才能被提交,才能使状态生效。链码使整个Fabric的核心,是智能合约在Fabric上的实现形式,部署在Fabric区块链各节点上。这里的节点分为三个类型:

  1. 客户端(Client)或者提交客户端(submitting-client):提交实际交易请求的客户端。客户端表示的是代表终端用户的实体,它必须连接到Peer节点才能和区块链通信。客户端可以根据自己的选择连接到任意一个Peer节点上,创建交易再调用交易

  2. Peer节点:Peer节点通过共识服务通信维护区块链状态和总账。它们从共识服务接收有序的更新状态,然后更新本地维护的状态。Peer节点有两种特殊的角色:

   请求节点(submitting peer或者submitter),请求节点是一种特殊的角色,它给客户端提供接口,这样客户端就可以连接到请求节点调用交易和获取结果。这个Peer节点代表一个或者多个客户端和其他节点通信来执行交易

   背书节点(endorsing peer或者endorser),背书节点的特殊功能是对特定的链码,在其提交交易前对它进行背书。每个链码都可以指定一个背书策略,可能会包含一个背书节点的集合。策略定义了一个有效交易背书(典型情况是背书节点的签名集合)的充要条件

  3. 共识服务节点(Consensus-service-node)或(ordering-node):该节点群构成了共识服务,目前的Fabric共识机制尚未实现PBFT,在用的为Solo(单节点共识)和kafka(分布式队列)和SBFT(简单拜占庭容错),Solo是中心化的共识服务,具体采用哪一种根据应用场景可插拔。

  这里需要注意的是,共识服务节点和客户端是不维护区块链状态的,只有Peer节点才有这个权利。

  下面概要的描述一下交易的流程:

  客户端发送如下的消息给请求节点,retryFlag是一个布尔值,告诉请求节点万一交易失败了要不要重新执行一次;tx包含了客户端的ID号clientID,本次交易所属的链码ID号chaincodeID,客户端的签名信息clientSig以及本次交易的信息部分txPayload等信息,即tx=

  请求节点收到客户端的消息后,首先要验证客户端的签名clientSig,之后请求节点会对交易信息txPayload执行模拟交易,根据结果构成tran-proposal,请求节点会将结果发送给背书节点请求给予背书,消息格式为

  链码chaincodeID对应的背书节点收到请求节点发来的消息后,首先验证签名clientSig,之后同样利用txPayload进行模拟交易,如果通过,则对交易信息进行数字签名,生成epSig,发送消息给请求节点,消息格式,TRANSACTION-VALID即表明本次交易有效;tid是tran-proposal的哈希值。由于一直到这一步都没有用到共识服务,所以交易信息还没有写进区块。

  请求节点如果收到足够的背书节点的回复,则称此次交易是有了有效背书的交易,开始启用fabric的共识服务。请求节点使用broadcast(blob)调用共识服务,其中blob=(tran-proposal, endorsement)。
  
  共识服务节点通过deliver(seqno, prevhash, blob)回送给请求节点和为此次交易背过书的背书节点。一次交易完成这所有的操作后这个交易就被认为是有效的(valid)或者提交的(committed),这就是说,这次交易会被添加到总账上。到这一步,算完成了一次 hyperledger fabric v1.0基本的运行流程。

您的支持将是我最大的动力!