Hyperledger Fabric和其他许多区块链的关键区别之一，就在于 Fabric区块链的交易执行过程：Fabric交易需要首先通过节点的背书， 然后再进行交易排序，最后才利用有序交易进行账本的更新。 本文将介绍Hyperledger Fabric所采用的执行-排序-验证这一三步 交易模型的工作原理，以及引入背书环节对Hyperledger Fabric区块链 性能的有益作用。
1、交易的生命周期：Hyperledger Fabric vs. 其他区块链
在其他区块链平台中，交易生命周期基本由如下环节构成：
- 排序：交易有序加入账本，然后扩散到所有节点
- 执行：交易在所有节点上按顺序依次执行并更新账本
为了让所有节点保持一致的状态，交易必须确定性执行，也就是 说，无论何时何地，同样的交易必须产生同样的结果。这一要求 对智能合约形成了很强的约束，也是智能合约通常需要使用领域特定 语言（DSL）来开发的原因之一，因此使用像Java或Go这样的通用 开发语言基本上无法保证确定性。
在Hyperledger Fabric中，交易的声明周期则有所不同：
- 执行：交易（通过智能合约）以任意顺序执行，甚至可以并行执行
- 排序：当足够数量的节点对交易结果达成一致，该交易就会 被加入账本并扩散给所有节点。
- 验证：每个节点验证并按顺序执行交易，从而更新账本
首先需要注意的一点是，交易的执行和对账本的实际更新被拆分 为两个环节，这一拆分带来一些有益的作用：
- 所有节点都需要更新账本，因此所有节点都需要执行验证步骤。 但并不是所有的节点都需要执行智能合约。Hyperledger Fabric 使用背书策略来定义哪些节点需要执行交易。这意味着指定的 链码（智能合约）不必开放给所有的节点 —— 那些不在背书策略中 的节点不需要由访问链码的权限。
- 交易可以在被排序之前先执行。这是的节点可以并行执行交易， 从而提高系统的吞吐量
- 在Fabric的三步交易模型中，在交易被添加到账本之前，其链码 执行结果是显式达成一致的，其他区块链的两步交易模型使用 确定性的链码，本身就隐含了节点之间就智能合约的执行结果 达成一致。显式达成一致可以让Fabric使用非确定性的链码， 这也是为什么我们可以使用Go、Java和Node.js编写Fabric链码 的原因。
2、Hyperledger Fabric的交易背书策略
Hyperledger Fabric允许用户自己定义链码执行的策略。这些背书 策略定义了在交易被加入账本之前，哪些节点需要就交易结果达成 一致。Fabric提供了一个小型的DSL来定义背书策略。下面展示了 一些背书策略样例：
- 节点A、B、C和F都需要对类型为T的交易进行背书
- 通道中的大部分节点必须对类型为U的交易进行背书
- A、B、C、D、E、F、G中的至少3个节点必须对类型为V的交易进行背书
背书策略并不保证正确的链码安装在正确的节点上。然而，背书和安装 链码的确存在类似的机制，我们将在后续教程中介绍这一点。
3、Hypereledger Fabric交易背书的实现机制
到目前为止，我们都是松散地使用交易（transaction）这一术语。在 排序-执行模型中，链码执行和账本更新被合二为一 —— 交易。在Fabric 中，这两个概念是分开的，因此交易本身也被拆分。
Fabric从交易提议（Transaction Proposal）开始。这是一个用来 触发链码执行的数据包。交易提议被发送给用于背书的节点。背书节点 执行链码，如果成功的话就生成一个实际的账本交易。背书节点签名 建议并返回交易提议的响应，这是执行-排序-验证模型中的执行步骤。
一旦交易提议的创建者收到足够的可以满足背书策略的签名，它就可以 将交易（以及签名）提交以便添加到账本中，这就是排序步骤。
4、结论
Hyperledger Fabric在区块链交易方面采取了一个新颖的思路，将智能 合约的执行与账本的更新分开使它可以提高交易吞吐量，支持更细粒度 的隐私控制，实现更灵活强大的智能合约。而这些特性得以实现的一个 关键因素就是在交易加入账本之前进行显式地交易背书。
原文链接：Understanding Hyperledger Fabric — Endorsing Transactions
汇智网翻译整理，转载请标明出处