这篇文章给大家分享的是有关Fabric交易背书过程的示例分析的内容。小编觉得挺实用的，因此分享给大家做个参考，一起跟随小编过来看看吧。
Hyperledger Fabric和其他许多区块链的关键区别之一，就在于Fabric区块链的交易执行过程：Fabric交易需要首先通过节点的背书，然后再进行交易排序，最后才利用有序交易进行账本的更新。本文将介绍Hyperledger Fabric所采用的执行-排序-验证这一三步交易模型的工作原理，以及引入背书环节对Hyperledger Fabric区块链性能的有益作用。
在其他区块链平台中，交易生命周期基本由如下环节构成：
排序：交易有序加入账本，然后扩散到所有节点
执行：交易在所有节点上按顺序依次执行并更新账本
为了让所有节点保持一致的状态，交易必须确定性执行，也就是说，无论何时何地，同样的交易必须产生同样的结果。这一要求对智能合约形成了很强的约束，也是智能合约通常需要使用领域特定语言（DSL）来开发的原因之一，因此使用像Java或Go这样的通用开发语言基本上无法保证确定性。
在Hyperledger Fabric中，交易的声明周期则有所不同：
执行：交易（通过智能合约）以任意顺序执行，甚至可以并行执行
排序：当足够数量的节点对交易结果达成一致，该交易就会 被加入账本并扩散给所有节点。
验证：每个节点验证并按顺序执行交易，从而更新账本
首先需要注意的一点是，交易的执行和对账本的实际更新被拆分为两个环节，这一拆分带来一些有益的作用：
所有节点都需要更新账本，因此所有节点都需要执行验证步骤。 但并不是所有的节点都需要执行智能合约。Hyperledger Fabric 使用背书策略来定义哪些节点需要执行交易。这意味着指定的 链码（智能合约）不必开放给所有的节点 —— 那些不在背书策略中 的节点不需要由访问链码的权限。
交易可以在被排序之前先执行。这是的节点可以并行执行交易， 从而提高系统的吞吐量
在Fabric的三步交易模型中，在交易被添加到账本之前，其链码 执行结果是显式达成一致的，其他区块链的两步交易模型使用 确定性的链码，本身就隐含了节点之间就智能合约的执行结果 达成一致。显式达成一致可以让Fabric使用非确定性的链码， 这也是为什么我们可以使用Go、Java和Node.js编写Fabric链码 的原因。
Hyperledger Fabric允许用户自己定义链码执行的策略。这些背书策略定义了在交易被加入账本之前，哪些节点需要就交易结果达成一致。Fabric提供了一个小型的DSL来定义背书策略。下面展示了一些背书策略样例：
节点A、B、C和F都需要对类型为T的交易进行背书
通道中的大部分节点必须对类型为U的交易进行背书
A、B、C、D、E、F、G中的至少3个节点必须对类型为V的交易进行背书
背书策略并不保证正确的链码安装在正确的节点上。然而，背书和安装链码的确存在类似的机制，我们将在后续教程中介绍这一点。
到目前为止，我们都是松散地使用交易（transaction）这一术语。在排序-执行模型中，链码执行和账本更新被合二为一 —— 交易。在Fabric中，这两个概念是分开的，因此交易本身也被拆分。
Fabric从交易提议（Transaction Proposal）开始。这是一个用来触发链码执行的数据包。交易提议被发送给用于背书的节点。背书节点执行链码，如果成功的话就生成一个实际的账本交易。背书节点签名建议并返回交易提议的响应，这是执行-排序-验证模型中的执行步骤。
一旦交易提议的创建者收到足够的可以满足背书策略的签名，它就可以将交易（以及签名）提交以便添加到账本中，这就是排序步骤。
Hyperledger Fabric在区块链交易方面采取了一个新颖的思路，将智能合约的执行与账本的更新分开使它可以提高交易吞吐量，支持更细粒度的隐私控制，实现更灵活强大的智能合约。而这些特性得以实现的一个关键因素就是在交易加入账本之前进行显式地交易背书。
感谢各位的阅读！关于“Fabric交易背书过程的示例分析”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，让大家可以学到更多知识，如果觉得文章不错，可以把它分享出去让更多的人看到吧！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
