区块链原理之交易背书基本流程初探！

“本文将阐述一下交易背书的基本流程，对交易背书的基本流程进行学习和掌握，会对我们自己实际部署、开发起到积极的作用。希望会对大家有所帮助。”

首先，我将交易背书的整体流程，绘图如下，望此形象化的图表有助大家理解。

交易背书的基本流程概括性的简述如下：

1）客户端创建交易后，发送请求到其选择的背书节点，即发送一个PROPOSE消息到交易所选择的背书节点集合。

2）背书节点模拟交易，然后生成背书签名。（在此首先会验证客户端的签名clientSig，然后模拟交易）

3）提交客户端获取交易的背书，通过排序服务进行广播。（之前提交节点会等待，当得到足够的消息及签名，得出交易已被背书的结论后，就会涉及其与背书节点之间的多轮交互；如果没有得到足够的消息及签名，其会放弃此次交易，稍后重试。在此的“足够多的消息及签名”和背书策略有关）

4）排序服务向所有节点投递传播交易的消息。

接下来，我将分别对其进行阐述。

1）客户端创建交易后，发送请求到其选择的背书节点，即发送一个PROPOSE消息到交易所选择的背书节点集合。

为了调用交易，客户端会发送一个PROPOSE消息至交易所在的背书节点集合，这里可能不是同时发送。交易可以被发送到指定chaincodeID的所有背书节点。当然，有一些背书者此时可能处于离线状态，还有可能一些可能会拒绝、不参与背书此次交易。这时就需要提交节点应尽可能的利用可用的背书者来完成背书以满足背书策略所需。

现对 PROPOSE 消息格式，提交客户端和背书者之间有可能存在的交互模式，进行说明。

PROPOSE消息格式

PROPOSE消息的格式为：

注：其中， tx 是必须要提供的，而 anchor 为可选参数。

如：

tx=

其中， clientID 是提交用户的 ID ；

chaincodeID 指的是交易所属的链代码的 ID ；

TxPayload 是发出的交易本身的有效载荷；

Timestamp 是对于每个新的交易，单调递增的整数，由客户端维护；

clientSig 是客户端交易消息中其它项的签名。

在进行调用交易和部署交易的时候，txPayload 的细节是不相同的，调用交易会应用一个特定部署的系统链代码。

对于一个调用交易，txPayload 是由以下两个域组成的：

txPayload =

注：其中，operation 是链代码提供的函数和参数；metadata 表示与调用相关的属性。

对于部署交易，txPayload 由以下三个域组成：

txPayload =  

注：其中，source 表示链代码的源代码；metadata 表示与链代码和应用相关的属性；policies 包含了所有节点都能访问的链码策略，如背书策略。

需要说明的是，在部署交易当中，背书策略不是由 txPayload 来提供的，但是部署的 txPayload 包含了背书的策略 ID 和与之相对应的参数。

anchor 包含了读版本的依赖，如果客户端指定了 anchor 参数，那么背书者会在其本地的 KVS 匹配 anchor 中基于相应键的读版本号来进行背书交易。

交易加密 Hash 作为唯一的交易标识符 tid 被所有的节点使用。客户端会将 tid 存储在内存中，并且等待来自背书节点的响应。

注：（tid = hash(tx)）

消息模式—提交客户端和背书者之间的交互模式

客户端和背书者决定了交互的序号。

举例，这样的典型场景：一个客户端向单个的背书节点发送，此处没有 anchor 参数。背书节点产生版本依赖（anchor），客户端其后会用到版本依赖，并将其作为 PROPOSE 消息的参数发送给其它的背书者。

再举一个例子，客户端可以直接发送消息到其选择的所有背书者上，至于采用何种通信的模式，客户端可以自由选择。（未完待续）

文章作者：Mercina-zy

文章来源：

https://mp.weixin.qq.com/s/dA6YptEjXjtZhkeNhpgj0A