Fabric交易的共识流程

本文介绍了Fabric区块链平台中的共识流程,包括提议、打包和验证三个阶段。提议阶段涉及交易背书,打包阶段由Orderer节点对交易进行排序,验证阶段确保交易的有效性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

目录

一、概述

二、共识流程

(一)提议阶段

(二)打包阶段

(三)验证阶段

三、小结


一、概述

Fabric中提供了Orderer排序节点,作为区块链网络的一种共识机制,提供对交易进行排序的服务。目前,Fabric已发布的版本中提供了一种基于崩溃容错(Crash Fault-Tolerant, CFT)等排序机制。这种机制是通过Kafka实现的,后续版本中会提供基于Raft共识的排序机制。本文不具体关注Orderer的实现机制,而是从整体了解一下Fabric的共识流程。

在讨论Fabric的共识流程前,首先需要对Fabric的交易流程有一定的了解。Fabric中简化的交易流程如下图所示:

具体的描述可以参考Fabric官方文档: Peers

在Fabric中,交易可以分为两类,一类是查询交易,用于账本查询,不更新账本数据;另一类是更新交易,用于修改账本中的数据。很显然,查询交易只需要单个Peer参与即可,不需要进行排序共识的,而更新交易(下文简称交易)需要通常需要多个Peer参与(同一Channel中),在这种情况下,排序共识就会起到作用。

二、共识流程

交易的共识包括3个阶段的处理:提议阶段、打包阶段和验证阶段,下面结合交易流程,分别介绍各个阶段。

(一)提议阶段

提议阶段我们可以理解为背书阶段,这一阶段可以分为三个步骤,如下:

1. 用户通过Application(封装了Fabric SDK的客户端应用程序)构造出交易提议,交易提议中包含欲执行的Chaincode和函数名,背书节点列表(与具体的Chaincode背书策略有关,包含在同一个Channel中)等数据,并将交易提议发送至相应的Peer。

2. 各背书节点接收到交易提议后,首先进行一些检查和签名的验证,然后独立地模拟执行指定的Chaincode函数(不将执行结果写入本地账本),生成一个提议结果,并对结果进行背书,即在结果中添加数字签名并利用私钥对结果进行签名。

3. 将提议结果返回至Application。

当Application收集到足够多的提议结果后,提议阶段完成。

(二)打包阶段

打包阶段也就是对交易进行排序的阶段,Orderer节点在这个阶段中起着至关重要的作用,过程如下:

1. Orderer接收到来自于多个Application的交易提议结果

2. 对每个Application提交的交易进行排序,这里值得注意的是排序的规则不是按照Orderer接收到交易的时间,而是按照交易的时间进行排序

3. 将交易分批打包进区块中,形成一个统一的共识结果,这种机制保证了Fabric不会出现账本的分叉

4. 当等待足够时间或区块满足大小后,Orderer将打包好的区块发送给特定Channel中的所有Peer

(三)验证阶段

Channel中的节点在接收到Orderer广播的区块后,每个节点都按照相同的方式独立处理接收到的区块,保证账本的一致性,步骤如下:

1. 通过VSCC检查交易是否满足背书策略。

2. 检查账本当前状态是否与提议结果生成时一致。

3. 通过检查的成功交易将被更新到账本中。

4. 构造Event消息,向注册了事件监听的Application通知Event消息。

三、小结

至此,一个交易的三个阶段就走完了,通过这三个阶段共同组成了Fabric的共识流程,并提供了一致性的保障,值得注意的是Fabric中是通过Channel来进行数据隔离的,因此所谓的一致性也是基于Channel考量的。

本文中没有深入的讨论Orderer排序的细节,这些细节Fabric在 A Kafka-based Ordering Service for fabric 一文中进行了详细的介绍,后续在一起深入学习吧。

### Hyperledger Fabric 共识算法介绍 Hyperledger Fabric共识机制设计与比特币存在显著差异。作为一个由许可节点构成的分布式系统,所有参与记账过程中的成员均被认为是可信赖方,因此无需依赖于工作量证明(Proof of Work, POW)[^1]。 #### 排序服务的重要性 为了确保整个网络内各节点间交易记录的一致性和有序性,Hyperledger Fabric引入了排序服务(Ordering Service),该组件负责收集来自不同客户端提交过来未经确认的提案请求,并按照一定规则对其进行排列组合成区块后再广播给其他peer节点执行验证流程。这种集中式的预处理方式有效地防止了因并发写入而导致的数据冲突现象发生。 #### SOLO 和 Kafka 排序策略对比 当前版本支持两种主要类型的Orderer实现方案: - **SOLO**: 此种模式下仅部署单一实例作为全局唯一的订单处理器角色承担全部事务管理职责;由于缺乏冗余备份机制以及扩展能力有限等原因,在实际应用场景中较少被采用,更多地服务于开发调试阶段或是小型封闭式联盟链建设需求场景之中。 - **Kafka**: 利用了Apache Kafka消息队列技术构建而成的大规模高可用性事件流平台,通过多个Broker协同运作来保障数据传输效率的同时也增强了系统的容错性能。然而值得注意的是尽管其具备良好的横向伸缩特性但仍受限于特定物理位置范围内部署要求从而影响到了跨地域分布程度较高的企业级应用案例适应度[^3]。 #### Raft 协议概述 鉴于上述局限性考量,官方团队进一步推出了基于Raft一致性协议的新一代排序引擎设计方案。相较于前两者而言不仅继承发扬了原有优势特点而且还针对现有痛点进行了针对性优化改进措施如下所示: - 支持多数据中心环境下灵活配置参与者身份信息; - 实现完全意义上的去中心化治理结构转型目标; - 提升整体架构稳定可靠性水平至更高层次标准之上。 ```go // 示例代码展示如何初始化一个简单的Raft consensus模块 package main import ( "fmt" raft "github.com/hashicorp/raft" ) func initRaft() error { config := raft.DefaultConfig() // 配置具体的参数... } ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值