Fabric网络交易流程

转载

云端筑梦师 2024-09-22 20:08:04

文章标签 Fabric网络交易流程区块链数据库大数据客户端 文章分类 运维

在生产环境中，一个最小的Fabric联盟链网络由4个结点组成，如下图：

为了避免单点故障，进行结构冗余，每个节点的角色安排如下：

· 192.168.1.120 peer1, orderer1, zookeeper0, kafka0, ca1，

· 192.168.1.121 peer2, orderer2, zookeeper1, kafka1 ca2

· 192.168.1.122 peer3, zookeeper2, kafka2 ,ca3

· 192.168.1.122 peer4, kafka3 ca4, fabric浏览器

在Fabric中，本由一个节点处理的过程，在逻辑上被分解为不同的角色，每个角色承担不同的功能；节点（Peer）分解为背书节点（Endorser peer）和提交节点（Committer peer），为了达到处理的顺序性，提炼出排序（Orderer）角色，kafka是联盟链中负责共享机制，zookeeper是个分布式应用协调器，负责点到点数据传输，CA负责证书发放。 Fabric是应用于联盟链的场景，在处理每一笔交易时，每个环节上需要对交易信息进行权限校验。
Fabric交易流程图如下所示：

交易过程详细流程：
1) 应用程序客户端通过SDK调用证书服务（CA）服务，进行注册和登记，并获取×××书；
2) 应用程序客户端通过SDK向区块链网络发起一个交易提案（Proposal），交易提案把带有本次交易要调用的合约标识、合约方法和参数信息以及客户端签名等信息发送给背书（Endorser）节点。

3) 背书（Endorser）节点收到交易提案（Proposal）后，验证签名并确定提交者是否有权执行操作，同时根据背书策略模拟执行智能合约，并将结果及其各自的CA证书签名发还给应用程序客户端。

     4) 应用程序客户端收到背书（Endorser）节点返回的信息后，判断提案结果是否一致，以及是否参照指定的背书策略执行，如果没有足够的背书，则中止处理；否则，应用程序客户端把数据打包到一起组成一个交易并签名，发送给Orderers。
     5) Orderers对接收到的交易进行共识排序，然后按照区块生成策略，将一批交易打包到一起，生成新的区块，发送给提交（Committer）节点；
     6) 提交（Committer）节点收到区块后，会对区块中的每笔交易进行校验，检查交易依赖的输入输出是否符合当前区块链的状态，完成后将区块追加到本地的区块链，并修改世界状态。

还有一个关于Fabric联盟链交易理解的说明：

这个示例中包含客户A和B，在进行萝卜买卖。他们各自有一个网络节点，通过节点他们发送交易并和账本进行交互。

首先，假设必要的条件：

该流程假设通道已建立并正常运行。用户已注册并使用组织认证授权（CA）登记，同时获得必要的加密材料来进行网络验证。

链码（包含一组代表萝卜市场初始状态的键值对）被安装在节点上并在通道上进行实例化。链码包含定义交易指令集合的逻辑和达成一致的萝卜价格。设置一项针对链码的背书策略，表明节点A和B都必须对任何交易进行背书。

1. 客户A发起交易

客户A发出萝卜购买请求。请求目标节点A和B，分别代表客户A和B。背书策略表明两个节点必须为任何交易进行背书，因而请求被发送到节点A和B。

接下来构建交易提案。一个以可用SDK（node, java, python）为支撑的应用利用有效的API来生成交易提案。这项提案作为调用链码功能的请求来完成数据到账本的读取和/或写入（即为资产写入新的键值对）。SDK有两个作用：把交易提案包装成合适架构格式的库（基于gRPC的协议缓冲）；使用用户的加密证书来创建交易提案的唯一签名。

2. 背书节点验证签名&执行交易

背书节点使用MSP验证签名并确定请求者是否被合理授权进行提案的操作（使用通道ACL）。背书节点以交易提案凭证为输入，基于当前状态的数据库执行来生成交易结果，输出包括反馈值、读取集合和写入集合。截止现在账本还未进行更新。这些值的集合，背书节点的签名以及是/否的背书声明一同作为“提案反馈”被传输回到SDK，SDK对应用消耗的载荷进行解析。