Fabric中的交易流!!

1.标准交易流:(查询需要3步,更新需要5步)

查询:

①应用程序连接到节点(安装有链码);

②应用程序向节点发送一个调用链码(方法)的提案,节点使用该提案调用链码,然后链码产生一个查询提案响应(包含查询结果)

③节点将提案响应返回给应用程序。

 

更新:

应用程序连接到节点(安装有链码);

应用程序向节点发送一个调用链码(方法)的提案,节点使用该提案调用链码,然后链码产生一个更新的提案响应;

节点将提案响应返回给应用程序;

应用程序将收集到的来自所有背书节点的响应打包成一个交易,然后将交易发送给排序节点。排序节点将从全网收集到的交易打包成区块,然后再将区块发送给所有节点。节点接收到区块后,使用区块更新本地的账本副本;

账本更新后,节点向应用程序发送一个账本更新事件,通知应用程序账本已更新。

 

*应用程序应该在提交交易后侦听交易事件,例如使用submitTransaction API,该API自动侦听交易事件。如果不侦听交易事件,你将不知道你的交易是否已经被排序、验证并提交到账本上。


 

2.具有私有数据的交易流:

客户端应用程序提交一个用来调用链码函数(读取或写入私有数据)的提议请求作为集合中被授权组织一部分的背书节点私有数据,或者用于在中生成私有数据的数据,被发送到提案的一个transient字段中。

背书节点模拟交易,并将私有数据存储在transient data store(对等节点本地的临时存储)中。他们根据集合策略,通过gossip将私有数据分发给被授权的对等节点。

背书节点将提案响应发送回客户机。提案响应包括已背书的读/写集,其中包括公共数据,以及任何私有数据键和值的散列。没有将私有数据发送回客户机。

客户端应用程序将交易(包括带有私有数据散列的提案响应)提交给排序服务。带有私有数据哈希的交易像往常一样被包含在块中。带有私有数据哈希的区块被分发给所有的对等节点。通过这种方式,通道上的所有对等都可以用私有数据的哈希以一致的方式验证交易,而不需要知道实际的私有数据。

在提交区块时,授权的对等节点使用集合策略来确定它们是否被授权访问私有数据。如果是,他们将首先检查他们的本地transient data store,以确定他们是否已经在链码背书时收到了私有数据;如果不是,它们将尝试从另一个被授权节点拉取私有数据。然后,他们将根据公共中的哈希验证私有数据,并提交交易和区块。在验证/提交之后,私有数据被移动到私有状态数据库和私有写集存储的副本中。然后从transient data store中删除私有数据。

 


 

附:私有数据集合PDC(Private Data Collection)

私有数据集合是为通道上的部分组织定义的,只有这些组织有对私有数据背书、提交或查询的能力,通道上的其它组织不行。私有数据集合是两个元素的组合:

 

①实际的私有数据通过gossip协议点对点地发送到只有被授权查看它的组织。此数据存储在被授权组织的对等节点上的私有状态数据库(有时称为“侧”数据库,或“SideDB”),可以从这些被授权节点上的链码访问这些数据库。这里不涉及排序服务,它也看不到私有数据。注意,由于gossip将私有数据点对点地分布在被授权的组织中,因此需要在通道上设置锚节点,并在每个节点上配置CORE_PEER_GOSSIP_EXTERNALENDPOINT,以引导跨组织通信

 

②数据的哈希,经过背书、排序,然后写入每一个节点的账本。哈希作为交易的证据,用于状态验证,并可用于审计目的。

 

  1. 如果集合的成员陷入争议,或者如果他们想将资产转让给第三方,则可以决定与其他方共享私有数据。然后,第三方可以计算私有数据的哈希,并查看它是否与通道账本上的状态匹配,从而证明在某个时间点上集合成员之间存在的状态。
  2. 当交易(和账本)必须在一组组织之间共享,但只有这些组织的一个子集有权访问交易中的部分(或全部)数据时,使用集合。此外,由于私有数据是通过点对点(peer-to-peer)传播的,而不是通过块传播的,所以当交易数据必须对排序服务节点的保密时,请使用私有数据集合。
  3. 当在链码中引用私有数据集合时,为了保护私有数据的机密性,在提议、背书和提交到分类帐时,交易流略有不同

 

 

 

 

猜你喜欢

转载自www.cnblogs.com/skzxc/p/10850358.html