关于Hyperchain所使用的RBFT共识机制的具体流程，当前公开的搜索结果信息有限。以下是基于现有信息为您梳理的关键点。
🔍 搜索信息整理与辨析
在搜索结果中，“RBFT”这个词可能指代两种不同的技术概念，需要先进行区分：
| 维度 | Hyperchain官方定义的RBFT | 学术研究中的两级RBFT |
|---|---|---|
| 技术路线 | 改进自PBFT | Raft与PBFT结合的两级架构 |
| 核心思想 | 通过优化PBFT流程，加入动态节点管理、失效恢复等机制，提升容错性和可用性。 | 先将网络节点分组，组内用改进的Raft共识；然后由各组的领导者组成委员会，再用PBFT进行共识。 |
| 信息来源 | 趣链科技官方文档及相关技术博客。 | 学术期刊《通信学报》的论文。 |
| 与Hyperchain关联 | 官方确认采用。 | 未找到与Hyperchain直接关联的证据，属于同名但不同的共识机制设计。 |
根据官方文档，Hyperchain采用的是第一种，即改进自PBFT的Robust Byzantine Fault Tolerant (RBFT) 算法。
🔄 Hyperchain RBFT共识流程概览
关于其具体流程，搜索结果仅提供了框架性描述，缺少每一步的详细交互细节。下图整合了已知信息，描绘了共识的主要阶段和节点分工：
flowchart TDsubgraph Client[客户端]A[发起交易请求]endA --> B[交易发送至VP或NVP节点]subgraph Network[网络层]B --> C{NVP节点收到?}C -- 是 --> D[转发至验证节点 VP]C -- 否 --> E[VP节点直接接收]D --> Eendsubgraph Consensus[共识模块 RBFT]E --> F[主VP打包交易<br/>广播PrePrepare消息]F --> G[三阶段共识流程<br/>Pre-Prepare, Prepare, Commit]G --> H{共识是否达成?}H -- 是 --> I[账本模块更新]H -- 否 --> J[触发视图变更 View Change]J --> K[选举新的主节点]K --> FendI --> L[各节点执行区块<br/>更新本地状态]
关于流程中的关键点，需要说明的是：
- 基本流程：根据Hyperchain相关介绍，其RBFT流程包含了类似PBFT的三阶段验证（PrePrepare、Prepare、Commit），并包含了交易验证环节。
- 视图变更：当主节点失效时，算法会通过动态视图切换（View Change） 机制来选举新的主节点，以保障共识的连续性。