Hyperledger Fabric官网文档翻译(5) Architecture Reference - Transaction Flow(交易流)

本文档概述了标准资产交换过程中的交易机制。 该情景包括两个客户端,A和B,他们正在买卖萝卜。 他们每个人在网络上都有一个peer,通过这个peer发送交易并与账本进行交互。
Hyperledger Fabric官网文档翻译(5) Architecture Reference - Transaction Flow(交易流)_第1张图片

假设 (Assumptions)
此流程假定通道已设置并运行。应用程序用户已注册并且已经注册到了组织的证书颁发机构(CA),并收到了必要的加密材料,该材料用于向网络进行身份验证。

链码(包含表示萝卜市场初始状态的键值对集)安装在peers上并在通道上实例化。 链码包含定义交易指令集和商定萝卜价格的逻辑。 还为此链码设置了一个背书策略,该背书策略声明了peerApeerB都必须为任何交易背书。
Hyperledger Fabric官网文档翻译(5) Architecture Reference - Transaction Flow(交易流)_第2张图片

1.客户端A发起一个交易(Client A initiates a transaction)
发生了什么? - 客户A正在发送购买萝卜的请求。 该请求的目标是peerApeerB,它们分别代表客户端A和客户端B。背书策略规定两个peers端必须为任何交易背书,因此请求将转发给peerApeerB

接下来,构建交易提案。 应用程序利用功能支持的SDK(Node,Java,Python)的其中一个可用的API来生成一个交易提案。 该提案是一个调用链码功能的请求,以便可以将数据读取和/或写入账本(即为资产写入一个新的键值对)。 SDK用作填充程序,将交易提案打包为恰当的架构格式(gRPC上的协议缓冲区),并使用用户的加密证书为此交易提案生成一个唯一的签名。
Hyperledger Fabric官网文档翻译(5) Architecture Reference - Transaction Flow(交易流)_第3张图片

2.背书结点验证签名 & 执行交易(Endorsing peers verify signature & execute the transaction)
背书结点将验证(1)交易提案的格式是否正确,(2)它在过去未提交过(重放攻击保护),(3)签名是否有效(使用MSP),以及(4) 提交者(在示例中即为客户端A)被授权在该通道上执行提案的操作(也就是说,每个背书结点确保提交者满足管道的写入策略(channel’s Writers policy) )。 背书结点将交易提案作为调用的链码的函数的输入参数。 然后链码针对当前的状态数据库执行,以产生交易结果,该交易结果包括一个响应值,读取集和写入集。 此时没有对账本进行任何更新。 这些值以及背书结点的签名将作为一个“提议响应”传递回给SDK,该SDK解析负载以供应用程序使用。

注意
MSP是一个peer组件,它允许peer验证来自客户端的交易请求并签名交易结果(背书)。写入策略在通道创建时定义,它决定了哪些用户有资格向该通道提交交易。

Hyperledger Fabric官网文档翻译(5) Architecture Reference - Transaction Flow(交易流)_第4张图片

3.检查提案响应(Proposal responses are inspected)
应用程序验证背书结点的签名并和提议响应相比较以确定提议响应是否是相同的。 如果链码仅查询账本,那么应用程序将检查查询响应结果,并且通常不会将交易提交给排序服务(Ordering Service)。 如果客户端应用程序打算将交易提交给排序服务以更新总账,那么应用程序在提交之前需要确定是否已满足指定的背书策略(即,peerA和peerB是否都背书了)。 该体系结构是,即使应用程序选择不检查响应或者允许未经背书的交易通过,peer在提交验证阶段仍然会强制执行该背书策略。
Hyperledger Fabric官网文档翻译(5) Architecture Reference - Transaction Flow(交易流)_第5张图片

4.客户端将背书集中到交易中(Client assembles endorsements into a transaction)
应用程序将交易提案以"交易消息"的响应形式“广播”给排序服务。 该交易将包含读/写集,背书结点的签名和通道ID。 排序服务不需要为了执行它的操作而检查交易的全部内容,它只是从网络中的所有通道中接收交易,按时间顺序按通道对它们进行排序,并为每个通道创建交易区块。
Hyperledger Fabric官网文档翻译(5) Architecture Reference - Transaction Flow(交易流)_第6张图片

5.交易已被验证和被提交(Transaction is validated and committed)
交易区块被“传递”到通道上的所有peers。 区块中的交易需要被验证以确保满足背书策略,并确保自交易执行产生读集以来,读集变量的账本状态没有变化。 区块中的交易被标记为有效或者无效。
Hyperledger Fabric官网文档翻译(5) Architecture Reference - Transaction Flow(交易流)_第7张图片

6.账本更新(Ledger updated)
每个peer将区块添加到通道的链上,并且对于每个有效的交易,写集被提交到当前状态数据库。 peer会发出一个事件,通知客户端应用程序交易(调用)已被永久地添加到链中,以及通知该交易是否已经生效或者无效。

注意:可以查看sequence diagram以更好地理解交易流。

参考:
Hyperledger Fabric 官网翻译架构篇–之交易流程
Hyperledger Fabric 交易流程
《Fabric交易流程》Transaction Flow 非直译文
《Fabric交易流程》Transaction Flow 非直译文

官方英文原文档:
https://hyperledger-fabric.readthedocs.io/en/latest/txflow.html

你可能感兴趣的:(Hyperledger,Fabric,文档翻译,区块链)