Diem 验证器节点Validator Nodes架构深度解析DiemBFT 共识、核心组件与状态同步机制【免费下载链接】diemDiem’s mission is to build a trusted and innovative financial network that empowers people and businesses around the world.项目地址: https://gitcode.com/gh_mirrors/di/diem本文围绕 DiemDiem Blockchain生态中的**验证器节点Validator Nodes**展开系统讲解它在交易提交、共识、执行与存储全链路中的核心职责逐一拆解其 Mempool、Consensus、Execution、Virtual Machine、Storage 与 State Synchronizer 六大逻辑组件的功能与协作关系并结合本仓库 diem-node 的启动代码与 consensus 实现文档说明 DiemBFT 共识协议如何容忍至多三分之一恶意验证器并保证安全性与活性。读完本文你将能够清晰回答验证器节点由哪些组件构成、它们如何协同工作、为何 Diem 采用 BFT 共识、验证器与全节点在网络中如何分层这一系列问题为后续阅读 Diem 全节点指南 与 节点网络与同步指南 打下基础。一、验证器节点在 Diem 网络中的角色Diem 节点Diem node是 Diem 生态中的对等实体peer entity它持续追踪 Diem 区块链的状态state。客户端Client通过 Diem 节点与区块链交互。整个生态中存在两种节点类型验证器节点Validator Nodes负责运行共识协议、执行交易并把结果写入区块链数据库全节点FullNodes复制并验证链上状态作为外部验证资源。Diem Core即本仓库的 Rust 实现这套开源软件可以配置为验证器节点运行也可以配置为全节点运行——两者的根本区别在于是否启用 Consensus共识组件。当一笔交易被提交到 Diem 区块链时验证器节点会运行分布式共识协议consensus protocol就交易集合与执行结果达成一致**执行execute**该交易将交易及其执行结果存储到区块链数据库中。验证器节点决定了哪些交易会被加入区块链、以何种顺序加入。Diem 支付网络DPN采用Byzantine Fault ToleranceBFT共识协议使验证器节点在最终确定finalized的交易账本及其执行结果上达成一致。因为验证器节点维护并处理这些交易所以它们始终拥有区块链的当前状态。从 glossary 的定义可以进一步确认验证器的职责边界验证器是 Diem 生态中负责在区块链上进行验证的实体它接收客户端请求并运行共识consensus、执行execution与存储storage内部需要维护当前状态、执行交易并计算下一个状态同时保留区块链上的全部交易历史。隐藏网络与分层架构验证器节点之间通过一个**隐藏网络hidden network**直接通信即独立的验证器节点网络validator node network。它可以配置为存储 Diem 区块链的全部历史数据也可以只存储部分历史数据。全节点则构成第二层公共全节点网络public FullNode network。两者形成两层架构two-tiered architecture公共全节点网络并不是完全对等的not peer-to-peer它只会从所连接的验证器节点接收新区块更新。全节点从上游节点接收交易后会在本地重新执行这些交易与验证器执行交易的方式相同并把重执行结果写入本地存储。这种机制使得全节点能够察觉并证明任何企图**改写历史rewrite history**的行为从而确保验证器节点无法串通collude进行任意的交易执行——这正是全节点被称为外部验证资源external validation resource的原因。DiemBFT可容忍至多三分之一恶意验证器DiemBFT 共识协议提供至多三分之一恶意验证器节点的容错能力。Diem 的共识算法DiemBFT基于 HotStuff 协议改进而来。根据本仓库 consensus/README.md 的说明DiemBFT 假设在验证器集合中分布着3f 1张投票权只要由拜占庭Byzantine验证器控制的投票权至多为f即至少有2f 1张投票权由诚实验证器持有协议就能保持安全防止双花double spend与分叉fork等攻击同时只要存在一个全局稳定时间点GST之后诚实节点之间的消息能在有限网络延迟Δ内送达即 Dwork-Lynch-Stockmeyer 的部分同步模型协议就能持续产出提交liveness。二、验证器节点的组件构成每个 Diem 节点都由若干**逻辑组件logical components**构成验证器节点完整启用了除 JSON-RPC 之外的全部核心组件组件验证器节点全节点JSON-RPC 服务禁用启用Mempool启用启用Consensus启用禁用Execution启用启用Virtual Machine启用启用Storage启用启用State Synchronizer启用启用在本仓库中这些组件的装配与启动可以在 diem-node/src/lib.rs 中看到对应实现start()函数首先初始化崩溃处理crash_handler、日志diem_logger与故障注入点failpoints随后调用setup_environment统一装配 JSON-RPCdiem_json_rpc::bootstrap_from_config、Mempooldiem_mempool::gen_mempool_reconfig_subscription、共识consensus::consensus_provider::start_consensus、执行器executor::Executor、虚拟机组件的 VM 实现diem_vm::DiemVM、存储diemdb::DiemDB与状态同步state_sync_v1::bootstrapper::StateSyncBootstrapper并通过 tokio 运行时Runtime驱动各个子服务。MempoolMempool 是验证器节点中保存已提交但尚未达成共识并执行的交易的内存缓冲区in-memory buffer并且这个缓冲区会在验证器节点之间进行复制replicated。全节点的 JSON-RPC 服务会把客户端提交的交易发送到验证器节点的 MempoolMempool 会对请求执行初步检查initial checks以保护验证器节点的其他部分免受损坏或高流量输入的影响当新交易通过初步检查并被加入 Mempool 后它会被共享给 Diem 支付网络中其他验证器节点的 Mempool当某个验证器节点成为领导者leader时它的 Consensus 组件会从自身的 Mempool 中拉取交易并提议这些交易构成一个区块的顺序随后验证器群体quorum对该提议进行投票。从实现上看Mempool 位于 mempool/src/core_mempool 与 mempool/src/shared_mempool 目录中core_mempool 负责单节点内部的交易缓冲与排序shared_mempool 负责将交易广播给对等验证器并通过 网络 组件与共识模块交互。ConsensusConsensus 是负责对交易区块进行排序ordering blocks of transactions、并与其他验证器节点参与共识协议以对执行结果达成一致的组件。它是验证器节点区别于全节点的标志性组件全节点中该组件被禁用。结合 consensus/README.md 可以还原 DiemBFT 的具体工作流验证器通过共享 Mempool 协议在彼此之间分享客户端提交的交易协议按**轮次round**推进每一轮由一名领导者提出一个区块用以扩展一串已认证的区块序列其中包含完整的交易历史其他验证器收到提议区块后按照**投票规则voting rules**判断是否投票认证该区块——这些简单规则保证了 DiemBFT 的安全性且实现上可以独立审计若验证器决定投票它会**推测性执行speculatively execute**该区块中的交易且不产生外部副作用计算出执行后数据库的认证器authenticator然后把带签名的投票连同数据库认证器一起发送给领导者领导者收集投票形成法定人数证书quorum certificate, QC即至少2f 1张投票的证据并广播给所有验证器区块的提交遵循3 链提交规则3-chain commit rule第k轮区块在拥有自己的法定人数证书、且随后第k1、k2轮的两个区块与证书确认它之后即被提交最终所有诚实验证器都会提交该区块及其链接的前序区块序列。Consensus 组件的主体实现位于 consensus/src采用 Actor 模型以消息传递方式在子组件间通信基于 tokio 运行时唯一的并行访问例外是管理区块、执行、法定人数证书等共享数据结构的BlockStore。ExecutionExecution 组件负责协调一个区块内交易的执行并维护瞬态状态transient state。共识组件投票所针对的正是这一瞬态状态。Execution 组件会在内存中维护执行结果的表示直到共识组件将该区块提交到分布式数据库。Execution 组件通过虚拟机组virtual machine来执行交易。本仓库中该组件的核心实现位于 execution/executor/src其执行器Executor::DiemVM::new(db)在 diem-node/src/lib.rs 中被构造为区块执行器ChunkExecutor同时服务状态同步的批量追块需求。Virtual Machine虚拟机组Virtual Machine用于运行提交交易中携带的Move 程序并确定执行结果。在验证器节点中虚拟机组被两处复用Mempool使用虚拟机组对交易执行验证检查validation checksExecution组件使用虚拟机组执行交易。Move 是 Diem 自研的智能合约语言其解释器/虚拟机实现位于 language/diem-vm对外暴露DiemVMMove 语言本身在 language/move-lang 中实现。Diem 框架Diem Framework的模块如 language/diem-framework/modules以 Move 字节码形式存储在链上。StorageStorage 组件用于持久化已经达成共识的区块及其执行结果。在本仓库中存储层主要由 storage/diemdbDiemDB实现它落盘账本信息ledger info、交易与状态并向上层提供读写接口storage/accumulator 与 storage/jellyfish-merkle 则分别实现了交易累积器transaction accumulator与稀疏默克尔树Sparse Merkle Tree为执行结果提供可验证的密码学数据结构。State Synchronizer验证器节点使用State Synchronizer状态同步器组件来追赶catch up区块链的最新状态。该组件的职责对所有类型的 Diem 节点一致利用专用的对等网络栈执行同步并使用长轮询 APIlong-polling API。同步动作发生在以下场景节点首次上线bootstrap节点重启节点离线一段时间后重新上线发生网络分区network partition之后恢复全节点在正常运行负载下持续与上游节点同步。不同节点的上游对等方不同验证器节点使用验证器节点网络公共全节点则使用初始对等方集合或对外开放的验证器节点。同步的具体机制按块/按 chunk 获取交易并重放详见 state-sync 目录中的实现。三、交易的完整生命周期从提交到提交到链上综合上述组件一笔交易在验证器节点中的完整生命周期可以概括为提交客户端或全节点的 JSON-RPC 服务将已签名的交易提交到验证器节点的 Mempool入池Mempool 做初步检查后把交易放入内存缓冲区并广播给其他验证器节点的 Mempool打包提议当选的领导者从自身 Mempool 拉取交易打包成区块并提出排序共识投票其他验证器按投票规则执行该区块中的交易推测性执行无外部副作用对区块 执行结果认证器进行签名投票领导者汇总2f 1张投票形成法定人数证书提交满足 3 链提交规则后区块被提交执行结果由 Execution 组件从内存写入 Storage 组件持久化同步扩散状态同步器把新的已提交区块传播给下游全节点全节点重执行并本地存储形成外部验证。四、验证器节点的容错模型与安全性说明DiemBFT 采用N 3f 1的投票分布模型N 为总票数对应验证器持有的总投票权f 为允许出错的票数。允许持有至多 f 票的验证器出错——无论是离线、恶意还是缓慢只要2f 1票由诚实验证器持有它们就能对一致的决策达成共识。这意味着一方最多只能容忍三分之一的投票权被攻破或故障也回答了Diem 为何能在部分节点恶意的情况下保持正确这一核心问题。此外DiemBFT 还具备以下工程化特性摘自 consensus/README.md验证器集体签名的是区块执行后的状态而不仅是交易序列这使客户端可以用法定人数证书认证数据库读取同时增强对非确定性 bug 的抵抗力使用**显式超时round_state quorum of timeouts**推进轮次无需同步时钟计划引入基于可验证随机函数VRF的不可预测领导者选举缩短攻击者针对领导者的 DoS 攻击窗口使用**聚合签名aggregate signatures**保留签名验证器身份便于激励且无需复杂的阈值密钥设置。五、从源码验证组件装配在 diem-node/src/lib.rs 中start()的启动顺序清晰呈现了各组件在真实节点进程中的装配关系崩溃处理crash_handler::setup_panic_handler()日志diem_logger::Logger支持异步、分级、文件输出故障注入fail::has_failpoints()仅编译期启用 failpoints feature 时生效环境装配setup_environment(config, logger)其内部依据配置启动 JSON-RPC、Mempool、Consensus仅验证器、State Sync、网络栈、Storage 服务与备份服务backup service。DiemHandle结构体也直接对应了这些子系统_rpc、_mempool、_state_sync_bootstrapper、_network_runtimes、_consensus_runtime注意为Option全节点模式下为空、_debug与_backup从源码结构可以推断共识运行时采用可选项设计正是为了在同一套 Diem Core 软件中通过配置区分验证器节点与全节点。六、延伸阅读Diem 全节点FullNodes全节点的职责、公共全节点运行场景与 JSON-RPC 用途节点网络与同步两层网络架构、独立网络栈与状态同步触发场景的详细说明Diem 术语表Validator、FullNode、DiemBFT、HotStuff、JSON-RPC Service、Mempool、State 等概念的权威定义共识实现文档 consensus/README.mdDiemBFT 协议形式化描述与实现细节节点启动代码 diem-node/src/lib.rs验证器/全节点组件装配的完整入口若需实际操作验证器节点可参考 docker/compose/validator-testnet 下的编排示例与 config/README.md 中的节点配置说明。【免费下载链接】diemDiem’s mission is to build a trusted and innovative financial network that empowers people and businesses around the world.项目地址: https://gitcode.com/gh_mirrors/di/diem创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考