链台 | 确保安全的 Fabric 交易流程分析

的

作者：ChainDesk 韩晓东，ChainDesk 区块链行业分析师，ChainDesk 区块链工程师

本文阅读时间：3.3分钟

目标

Hyperledger Fabric 网络中的节点分类

熟悉Hyperledger Fabric交易流程

任务完成

下面我们就深入Hyperledger Fabric的内部，详细了解Hyperledger Fabric的交易实现过程，了解相应的核心内容。

区块链技术最重要的特征之一是它能够保证安全交易。 Hyperledger Fabric 和公链的交易实现有很大区别。 如：权限、认证、数据隔离等。

Hyperledger Fabric典型的交易流程如下图所示：

的

完整的交易流程解释如下：

应用程序使用相应SDK（Node、Java、Python）提供的API构造交易提案，提交给相应的背书节点。 交易提案包括：

channelID：频道信息

chaincodeID：要调用的chaincode信息

时间戳：时间戳

签字：客户签字

txPayload：提交的交易本身包含的内容比特币交易流程实例，包括两项：

operation：要调用的chaincode的函数和对应的参数

元数据：调用的相关属性

的

的

的

2. 背书节点验证收到的交易提议请求：

交易提案的格式是否正确？

事务之前没有提交过（重复攻击保护）

提交交易提案的客户端签名是否有效（使用MSP）

提交交易提案的请求者在通道中是否有相应的执行权限

验证通过后，调用链码模拟执行，生成交易结果，包括响应值、读集和写集。 认可结果并回应客户。

注意，此时调用链码是模拟执行，不会对账本中的数据进行真正的改动。

提示：MSP的相关内容请参考第六章

的

的

1. 应用收集到足够多的消息和背书签名后，构造一个合法的交易请求比特币交易流程实例，并将交易请求广播给Ordering服务节点。

如果应用的请求只是查询账本，应用会检查查询响应信息，不会将交易提交给Ordering服务。

如果客户端应用的请求是更新账本数据，则交易会被提交给Ordering服务进行下一步，应用会检查判断请求是否满足指定的背书策略（即指定的背书政策）在提交交易之前。 节点被识别）。

的

2. 交易请求提交给Ordering服务节点，交易中会包含读写集、背书签名和通道ID； Orderer节点收到交易请求后，不需要去查看交易中的具体数据，它只是从网络中读取所有通道接收的交易，按时间顺序排序，创建交易区块。 然后在同一个频道广播给所有组织的Leader节点。

的

3. Leader节点：Leader节点验证接收到的块（交易消息结构是否正确，是否重复，背书是否足够，读写集版本），并将结果写入校验通过后的本地账本。

的

4、同步广播：Leader节点向组织内其他节点同步广播（保证在同一个频道）。

提示：在Fabric中，广播到其他节点默认是相邻的3个节点。 这个广播数量可以通过配置修改。

注：跨组织广播由组织内的Anchor节点负责。

账本更新：

每个Peer节点将区块追加到区块链上，写入集提交到当前状态数据库。 对于每个有效交易，都会发出一个事件，通知客户端应用程序交易（调用）已不可更改地附加到链上，以及交易是否已验证或无效。

的