Hyperledger Fabric交易背书详解

欧易(OKX)

用戶喜愛的交易所

立即注冊立即下载

币安(Binance)

已有账号登陆后会弹出下载

立即注冊立即下载

图2-5 交易的请求流程

Peers：同级节点 Orderers：订单方 Endorse（TX）：发起交易TX Respond（TX）：响应交易TX Broadcast（EndorsedTX）：广播已发起的交易TX Blocks：写入区块

（1）客户端创建交易并发送给选择的背书peer节点。客户端发送一个PROPOSE消息到它选择的一组背书peer节点。客户端通过peer节点实现背书策略，从背书策略中得知背书peer节点的设置。交易可被发送给所有给定chaincodeID背书者或者只能发送给部分背书者。提交客户端尝试满足背书者可用的背书策略表达。

接下来，将描述PROPOSE消息格式，讨论在提交客户端和背书者之间可能的互动模式。

PROPOSE消息格式：其中tx是强制的，anchor可选参数在下面列出。

clientID是提交客户端的身份，chaincodeID引用交易相关的链码，txPayload是提交交易自身的载体，timestamp是由客户端维护的递增整型值，clientSig是tx的其它域客户端签名。

对于调用交易，txPayload包含两个域： ●operation表示链码操作函数和参数 ●metadata表示调用相关的属性

对于部署交易，txPayload包含三个域： ●source表示链码的源码 ●metadata表示链码和应用的相关属性 ●policies包含所有peer节点可访问的链码的相关策略，例如背书策略。注意背书策略在部署交易中不支持txPayload，但部署的txPayload包含背书策略ID和它的参数。 ●anchor包含读版本依赖，或更具体地说，键-版本对（即，anchor是KxN的一个子集），它捆绑或“锚”PROPOSE请求到指定KVS中key的版本。如果客户端指定anchor参数，背书者只基于读它本地KVS匹配anchor中的相应KEY的版本号背书交易。

tx加密哈希被所有node节点用作唯一的交易标识tid（即，tid=HASH（tx））。客户端保存tid在内存中，等待背书peer节点的响应。

（2）背书peer节点模拟交易并产生背书签名。在从客户端接收消息时，背书peer节点epID首先校验客户端签名clientSig，然后模拟一个交易。如果客户端指定了anchor，那么背书peer节点模拟交易只基于在它本地KVS匹配的由anchor指定的版本号对应的key读版本号（即下面定义的readset）。

模拟一个交易涉及背书节点尝试执行一个交易（txPayload），通过调用链码到交易引用（chaincodeID）和背书peer节点本地持有的状态拷贝。背书peer节点计算读版本依赖（readset）和状态更新（writeset），也在DB语言中称为MVCC+postimageinfo。

注意背书者不能改变它的状态，在背书没有影响状态的情况下交易模拟产生状态更新。

（3）提交客户端收集交易背书并通过排序服务广播它。提交客户端一直等待直到它在（TRANSACTION-ENDORSED，tid，，）上收集到“足够”的消息和签名来推断出交易提案已背书。如果提交客户端没有设法为交易提案收集背书，则放弃这个交易，稍后再试。

对于一个具有有效背书的交易，我们现在开始使用排序服务。提交客户端使用broadcast（blob）调用排序服务，其中blob=endorsement。如果客户端没有能力直接调用排序服务，它可以通过它选择的peer节点代理广播。注意代理peer节点不可能制造有效背书。

（4）排序服务向peer节点提交交易。当一个事件（seqno，prevhash，blob）发生并且一个peer节点已为所有序列号低于seqno的blobs更新状态，peer节点执行如下流程。它检查blob.endorsement是有效的，根据的是它引用的链码（blob.tran-proposal.chaincodeID）。在典型情况下，它也验证了依赖（blob.endorsement.tran-proposal.readset）在期间没有被违反。如果所有这些检查通过，交易被视为有效或承诺。在这种情况下，peer节点在PeerLedger用1标记交易，适用于blob.endorsement.tran-proposal.writeset区块链状态（如果交易提案是相同的，其它背书策略逻辑定义了函数处理blob.endorsement）。如果blob.endorsement背书策略验证失败，交易无效，并且peer节点在PeerLedger的位掩码用0标记交易。重要的是要注意无效交易不会改变状态。

图2-6 提交交易