Solana 验证器架构演进从 TPU/TVU 双管道走向统一 Leader/Validator 管道的设计提案【免费下载链接】solanaWeb-Scale Blockchain for fast, secure, scalable, decentralized apps and marketplaces.项目地址: https://gitcode.com/GitHub_Trending/so/solanaSolana 节点的交易处理单元TPU与交易验证单元TVU是理解其共识与吞吐能力的关键。本文基于仓库中的 validator-proposal.md 设计提案梳理这两条管道的诞生背景、验证与出块的本质差异以及解包抽象层、构建可切换 Leader 模式的单一管道的演进方向并结合当前仓库源码core/src/tpu.rs、core/src/tvu.rs、core/src/validator.rs等给出实现层面的印证。读完本文你将掌握 TPU/TVU 的职责划分、PoH 在两条管道中的不同角色以及该提案提出的架构重组清单与潜在收益。背景TPU 与 TVU 诞生的历史动因提案开篇回顾了 Solana 早期架构决策的来龙去脉理解这段历史有助于把握两条管道为何是今天的样子。为 TPS 去风险化而生项目起步时核心目标是去风险化de-riskTPS 声明。当时的判断是只要采用乐观并发控制optimistic concurrency control并设置足够长的 Leader 时隙leader slotPoS 共识本身并不会成为 TPS 的最大瓶颈真正的风险在于基于 GPU 的签名验证signature verification软件流水线software pipelining并发记账concurrent banking。正是为了应对这些风险**TPUTransaction Processing Unit交易处理单元**应运而生。在仓库中TPU 的模块注释同样将其定义为多阶段软件交易处理流水线见 core/src/tpu.rs 的tpu模块说明。突破 100k TPS 后的分工在吞吐量突破 100k TPS 之后团队被拆分为两个小组一组继续冲刺 710k TPS另一组则负责充实验证器validator管道。后者催生了TVUTransaction Validation Unit交易验证单元。在仓库中TVU 的模块注释将其定义为多阶段软件交易验证流水线见 core/src/tvu.rs。提案明确承认当前架构是上述开发顺序与项目优先级下增量演进的产物而非当时认为的技术上最优雅的交叉切面。在 Leader 轮换leader rotation的语境下出块leading与验证validating之间的强区分其实是被模糊的——这为后面合并为单一管道的提案埋下伏笔。验证与出块的本质差异PoH 的在与不在提案用一个非常精炼的标准来区分两条管道PoHProof of History历史证明出现在流水线的哪个位置。Leader先记账、再打 PoH 标签Leader 的处理流程是处理交易剔除坏交易removing bad ones将处理结果打上 PoH 哈希标签tag the result with a PoH hash。也就是说Leader 在记账之后才生成 PoH 哈希因此它拥有删除坏交易的自由——删除行为本身会被纳入后续哈希计算不影响已产出的区块。Validator先验证哈希、再按原样记账Validator 的处理流程则是验证收到的 PoH 哈希verify that hash剥离peel off该哈希以与 Leader完全相同的方式处理交易。关键约束在于Validator 看到坏交易时不能像 Leader 那样简单地将其删除——因为那样会改变 PoH 哈希交易集合不同哈希必然不同导致与 Leader 广播的哈希不一致。因此 Validator 只能选择拒绝整个区块rejects the whole block。这正是验证者没有出块自由度的密码学根源。记账之后的差异广播时机与投票除了 PoH 位置不同两条管道在记账之后的行为也不同阶段LeaderValidator记账后动作将 entries 广播给下游验证器已在 RetransmitStage重传阶段完成广播额外动作无评估所观察的分叉、可能投出一票并将 PoH 哈希重置为刚投票的区块哈希提案指出Validator 侧的广播发生在 RetransmitStage 中这是一种确认时间优化confirmation time optimization——不必等记账完成再广播而是在收块/转发阶段就提前传播。而 Validator 独有的最后一步则涉及共识核心逻辑每当处理完一个区块它需要权衡观察到的各个分叉weigh any forks its observing决定是否投票cast a vote若投票则把自身的 PoH 哈希重置为所投票区块的哈希reset its PoH hash to the block hash it just voted on。在源码中这一选分叉并重置逻辑由 ReplayStage 承担。例如 core/src/replay_stage.rs 的ReplayStage及其配置结构ReplayStageConfig包含vote_account、authorized_voter_keypairs、wait_for_vote_to_start_leader、wait_to_vote_slot等字段见 core/src/replay_stage.rs并可在其中看到分叉检测与重置相关的日志如PARTITION DETECTED waiting to join heaviest fork与select_vote_and_reset_forks_elapsed_us统计项见 core/src/replay_stage.rs。提案核心解包抽象层构建单一可切换管道提案的核心理念非常直接解包unwrap层层叠叠的抽象层构建一条单一管道只要验证者的 ID 出现在 Leader 调度表leader schedule中就开启 Leader 模式toggle leader mode on。这意味着不再维护两条结构上高度重复、仅在 PoH 处理位置与记账后动作上不同的流水线而是让同一套记账/验证逻辑根据角色自动切换行为。原提案附有对应的架构框图/img/validator-proposal.svg用于示意单一管道的组成与数据流该 SVG 未随仓库文档目录同步提交故此处以文字描述其要点。从当前源码看这条统一路线尚未落地core/src/validator.rs中仍然是先let tvu Tvu::new(...)见 core/src/validator.rs再let (tpu, mut key_notifies) Tpu::new(...)见 core/src/validator.rs的并行启动模式且leader_schedule_cache被同时传给两条管道。因此本文以下内容严格按设计提案的定位来阐述并将当前源码作为现状对照。源码印证当前 TPU/TVU 双管道的真实面貌TPU 内部结构core/src/tpu.rs 中Tpu结构体聚合了以下子服务fetch_stage: FetchStage——交易入口抓取sigverify_stage与vote_sigverify_stage——普通交易与投票交易的签名验证TransactionSigVerifierbanking_stage: BankingStage——记账见 core/src/banking_stage.rscluster_info_vote_listener——从 gossip 监听投票broadcast_stage: BroadcastStage——区块/entries 广播来自solana_turbine::broadcast_stage以及 QUIC 服务线程、TpuEntryNotifier、质押节点更新服务、BankingTracer等。TpuSockets见 core/src/tpu.rs则定义了交易、转发、投票、广播等多组 UDP 套接字与 QUIC 套接字。TPU 创建时还接收PohRecorder与BankForks见 core/src/tpu.rs与提案中Leader 在记账后打 PoH 标签的描述一致。TVU 内部结构core/src/tvu.rs 中Tvu结构体聚合了fetch_stage: ShredFetchStage——shred数据分片抓取shred_sigverify——shred 签名验证线程retransmit_stage: RetransmitStage——重传来自solana_turbine::retransmit_stage即提案提到的确认时间优化所在window_service、cluster_slots_service——收块窗口与槽位信息维护replay_stage: ReplayStage——重放/验证与投票决策voting_service、blockstore_cleanup_service、cost_update_service、warm_quic_cache_service、drop_bank_service、duplicate_shred_listener等。TvuSockets见 core/src/tvu.rs包含fetch、repair、retransmit、ancestor_hashes_requests四组套接字TvuConfig见 core/src/tvu.rs则暴露了shred_version、repair_validators、repair_whitelist、wait_for_vote_to_start_leader、replay_slots_concurrently等配置项。对比可见两条管道在抓取 → 验签 → 记账/重放 → 广播/重传的骨架上是同构的差异集中在 PoH 写入位置与投票重置逻辑——这正是提案主张合并的合理性的源码级佐证。提案的显著变更清单Notable changes提案列出了一组明确的重构动作可逐条对应到当前源码中的相应模块将 FetchStage 与 BroadcastStage 从 TPU 中上提Hoist当前FetchStage见 core/src/fetch_stage.rs与BroadcastStage均为Tpu的成员见 core/src/tpu.rs提案希望它们成为独立于单条管道的公共组件被统一管道复用。BankForks 更名为 Banktree当前BankForks同时被 TPU、TVU 与 Validator 广泛引用如 core/src/tpu.rs、core/src/validator.rs更名更多是语义与命名层面的整理。TPU 迁移到新的无套接字 cratesolana-tpu提案设想把 TPU 与具体网络套接字解耦。当前仓库中已有独立的tpu-clientcrate见根目录 Cargo.toml 中solana-tpu-client的依赖声明而提案中的solana-tpu属于另一层面的服务端管道拆包方向。TPU 的 BankingStage 吸收 ReplayStage这是合并管道的关键——记账banking与重放验证replay在统一管道中共享同一套处理交易核心仅凭 PoH 写入与否区分角色。TVU 消失统一管道取代 TVU验证职责由单一管道在非 Leader 模式下承担。新的 RepairStage 吸收 Shred Fetch Stage 与修复请求当前Tvu中既有ShredFetchStage又有repair::repair_service::RepairService见 core/src/tvu.rs提案建议合并为统一的 RepairStage消除职责重叠。JSON RPC 服务改为可选、仅用于调试提案主张将 RPC 服务拆入独立的solana-blockstreamer可执行程序使核心节点不再背负调试型接口的负担。新的 MulticastStage 吸收 RetransmitStage 的重传部分当前RetransmitStage位于solana_turbinecrate 并被Tvu持有见 core/src/tvu.rs提案希望将重传语义显式化为多播阶段。MulticastStage 置于 Blockstore 下游即重传发生在数据已落盘/排队到区块库之后保证重传内容的确定性与可追溯性。其中第 4、5 条直接呼应提案开篇的判断——在 Leader 轮换的语境下leading 与 validating 的强区分是被模糊的既然两者共享同一套交易处理内核那么合并为一条按需切换角色的管道既能减少代码重复也能让 Leader/Validator 角色切换轮到自己出块时更加顺滑。总结一份架构减法的设计路线图这份提案的本质是一次架构减法剥离 TPU/TVU 双管道中重复的抓取、验签、记账骨架仅保留PoH 写入位置与记账后动作两个真正的差异点并通过 Leader 调度表驱动的模式开关将其统一。从当前仓库实现看双管道架构依然健在提案所列各项变更也大多停留在设计层面但理解这份提案能让你在阅读core/src/tpu.rs、core/src/tvu.rs、core/src/replay_stage.rs、core/src/repair/repair_service.rs等模块时清楚地知道每条代码路径在整体演进蓝图中处于什么位置、为何如此组织以及未来可能向何处收敛。【免费下载链接】solanaWeb-Scale Blockchain for fast, secure, scalable, decentralized apps and marketplaces.项目地址: https://gitcode.com/GitHub_Trending/so/solana创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Solana 验证器架构演进：从 TPU/TVU 双管道走向统一 Leader/Validator 管道的设计提案
Solana 验证器架构演进从 TPU/TVU 双管道走向统一 Leader/Validator 管道的设计提案【免费下载链接】solanaWeb-Scale Blockchain for fast, secure, scalable, decentralized apps and marketplaces.项目地址: https://gitcode.com/GitHub_Trending/so/solanaSolana 节点的交易处理单元TPU与交易验证单元TVU是理解其共识与吞吐能力的关键。本文基于仓库中的 validator-proposal.md 设计提案梳理这两条管道的诞生背景、验证与出块的本质差异以及解包抽象层、构建可切换 Leader 模式的单一管道的演进方向并结合当前仓库源码core/src/tpu.rs、core/src/tvu.rs、core/src/validator.rs等给出实现层面的印证。读完本文你将掌握 TPU/TVU 的职责划分、PoH 在两条管道中的不同角色以及该提案提出的架构重组清单与潜在收益。背景TPU 与 TVU 诞生的历史动因提案开篇回顾了 Solana 早期架构决策的来龙去脉理解这段历史有助于把握两条管道为何是今天的样子。为 TPS 去风险化而生项目起步时核心目标是去风险化de-riskTPS 声明。当时的判断是只要采用乐观并发控制optimistic concurrency control并设置足够长的 Leader 时隙leader slotPoS 共识本身并不会成为 TPS 的最大瓶颈真正的风险在于基于 GPU 的签名验证signature verification软件流水线software pipelining并发记账concurrent banking。正是为了应对这些风险**TPUTransaction Processing Unit交易处理单元**应运而生。在仓库中TPU 的模块注释同样将其定义为多阶段软件交易处理流水线见 core/src/tpu.rs 的tpu模块说明。突破 100k TPS 后的分工在吞吐量突破 100k TPS 之后团队被拆分为两个小组一组继续冲刺 710k TPS另一组则负责充实验证器validator管道。后者催生了TVUTransaction Validation Unit交易验证单元。在仓库中TVU 的模块注释将其定义为多阶段软件交易验证流水线见 core/src/tvu.rs。提案明确承认当前架构是上述开发顺序与项目优先级下增量演进的产物而非当时认为的技术上最优雅的交叉切面。在 Leader 轮换leader rotation的语境下出块leading与验证validating之间的强区分其实是被模糊的——这为后面合并为单一管道的提案埋下伏笔。验证与出块的本质差异PoH 的在与不在提案用一个非常精炼的标准来区分两条管道PoHProof of History历史证明出现在流水线的哪个位置。Leader先记账、再打 PoH 标签Leader 的处理流程是处理交易剔除坏交易removing bad ones将处理结果打上 PoH 哈希标签tag the result with a PoH hash。也就是说Leader 在记账之后才生成 PoH 哈希因此它拥有删除坏交易的自由——删除行为本身会被纳入后续哈希计算不影响已产出的区块。Validator先验证哈希、再按原样记账Validator 的处理流程则是验证收到的 PoH 哈希verify that hash剥离peel off该哈希以与 Leader完全相同的方式处理交易。关键约束在于Validator 看到坏交易时不能像 Leader 那样简单地将其删除——因为那样会改变 PoH 哈希交易集合不同哈希必然不同导致与 Leader 广播的哈希不一致。因此 Validator 只能选择拒绝整个区块rejects the whole block。这正是验证者没有出块自由度的密码学根源。记账之后的差异广播时机与投票除了 PoH 位置不同两条管道在记账之后的行为也不同阶段LeaderValidator记账后动作将 entries 广播给下游验证器已在 RetransmitStage重传阶段完成广播额外动作无评估所观察的分叉、可能投出一票并将 PoH 哈希重置为刚投票的区块哈希提案指出Validator 侧的广播发生在 RetransmitStage 中这是一种确认时间优化confirmation time optimization——不必等记账完成再广播而是在收块/转发阶段就提前传播。而 Validator 独有的最后一步则涉及共识核心逻辑每当处理完一个区块它需要权衡观察到的各个分叉weigh any forks its observing决定是否投票cast a vote若投票则把自身的 PoH 哈希重置为所投票区块的哈希reset its PoH hash to the block hash it just voted on。在源码中这一选分叉并重置逻辑由 ReplayStage 承担。例如 core/src/replay_stage.rs 的ReplayStage及其配置结构ReplayStageConfig包含vote_account、authorized_voter_keypairs、wait_for_vote_to_start_leader、wait_to_vote_slot等字段见 core/src/replay_stage.rs并可在其中看到分叉检测与重置相关的日志如PARTITION DETECTED waiting to join heaviest fork与select_vote_and_reset_forks_elapsed_us统计项见 core/src/replay_stage.rs。提案核心解包抽象层构建单一可切换管道提案的核心理念非常直接解包unwrap层层叠叠的抽象层构建一条单一管道只要验证者的 ID 出现在 Leader 调度表leader schedule中就开启 Leader 模式toggle leader mode on。这意味着不再维护两条结构上高度重复、仅在 PoH 处理位置与记账后动作上不同的流水线而是让同一套记账/验证逻辑根据角色自动切换行为。原提案附有对应的架构框图/img/validator-proposal.svg用于示意单一管道的组成与数据流该 SVG 未随仓库文档目录同步提交故此处以文字描述其要点。从当前源码看这条统一路线尚未落地core/src/validator.rs中仍然是先let tvu Tvu::new(...)见 core/src/validator.rs再let (tpu, mut key_notifies) Tpu::new(...)见 core/src/validator.rs的并行启动模式且leader_schedule_cache被同时传给两条管道。因此本文以下内容严格按设计提案的定位来阐述并将当前源码作为现状对照。源码印证当前 TPU/TVU 双管道的真实面貌TPU 内部结构core/src/tpu.rs 中Tpu结构体聚合了以下子服务fetch_stage: FetchStage——交易入口抓取sigverify_stage与vote_sigverify_stage——普通交易与投票交易的签名验证TransactionSigVerifierbanking_stage: BankingStage——记账见 core/src/banking_stage.rscluster_info_vote_listener——从 gossip 监听投票broadcast_stage: BroadcastStage——区块/entries 广播来自solana_turbine::broadcast_stage以及 QUIC 服务线程、TpuEntryNotifier、质押节点更新服务、BankingTracer等。TpuSockets见 core/src/tpu.rs则定义了交易、转发、投票、广播等多组 UDP 套接字与 QUIC 套接字。TPU 创建时还接收PohRecorder与BankForks见 core/src/tpu.rs与提案中Leader 在记账后打 PoH 标签的描述一致。TVU 内部结构core/src/tvu.rs 中Tvu结构体聚合了fetch_stage: ShredFetchStage——shred数据分片抓取shred_sigverify——shred 签名验证线程retransmit_stage: RetransmitStage——重传来自solana_turbine::retransmit_stage即提案提到的确认时间优化所在window_service、cluster_slots_service——收块窗口与槽位信息维护replay_stage: ReplayStage——重放/验证与投票决策voting_service、blockstore_cleanup_service、cost_update_service、warm_quic_cache_service、drop_bank_service、duplicate_shred_listener等。TvuSockets见 core/src/tvu.rs包含fetch、repair、retransmit、ancestor_hashes_requests四组套接字TvuConfig见 core/src/tvu.rs则暴露了shred_version、repair_validators、repair_whitelist、wait_for_vote_to_start_leader、replay_slots_concurrently等配置项。对比可见两条管道在抓取 → 验签 → 记账/重放 → 广播/重传的骨架上是同构的差异集中在 PoH 写入位置与投票重置逻辑——这正是提案主张合并的合理性的源码级佐证。提案的显著变更清单Notable changes提案列出了一组明确的重构动作可逐条对应到当前源码中的相应模块将 FetchStage 与 BroadcastStage 从 TPU 中上提Hoist当前FetchStage见 core/src/fetch_stage.rs与BroadcastStage均为Tpu的成员见 core/src/tpu.rs提案希望它们成为独立于单条管道的公共组件被统一管道复用。BankForks 更名为 Banktree当前BankForks同时被 TPU、TVU 与 Validator 广泛引用如 core/src/tpu.rs、core/src/validator.rs更名更多是语义与命名层面的整理。TPU 迁移到新的无套接字 cratesolana-tpu提案设想把 TPU 与具体网络套接字解耦。当前仓库中已有独立的tpu-clientcrate见根目录 Cargo.toml 中solana-tpu-client的依赖声明而提案中的solana-tpu属于另一层面的服务端管道拆包方向。TPU 的 BankingStage 吸收 ReplayStage这是合并管道的关键——记账banking与重放验证replay在统一管道中共享同一套处理交易核心仅凭 PoH 写入与否区分角色。TVU 消失统一管道取代 TVU验证职责由单一管道在非 Leader 模式下承担。新的 RepairStage 吸收 Shred Fetch Stage 与修复请求当前Tvu中既有ShredFetchStage又有repair::repair_service::RepairService见 core/src/tvu.rs提案建议合并为统一的 RepairStage消除职责重叠。JSON RPC 服务改为可选、仅用于调试提案主张将 RPC 服务拆入独立的solana-blockstreamer可执行程序使核心节点不再背负调试型接口的负担。新的 MulticastStage 吸收 RetransmitStage 的重传部分当前RetransmitStage位于solana_turbinecrate 并被Tvu持有见 core/src/tvu.rs提案希望将重传语义显式化为多播阶段。MulticastStage 置于 Blockstore 下游即重传发生在数据已落盘/排队到区块库之后保证重传内容的确定性与可追溯性。其中第 4、5 条直接呼应提案开篇的判断——在 Leader 轮换的语境下leading 与 validating 的强区分是被模糊的既然两者共享同一套交易处理内核那么合并为一条按需切换角色的管道既能减少代码重复也能让 Leader/Validator 角色切换轮到自己出块时更加顺滑。总结一份架构减法的设计路线图这份提案的本质是一次架构减法剥离 TPU/TVU 双管道中重复的抓取、验签、记账骨架仅保留PoH 写入位置与记账后动作两个真正的差异点并通过 Leader 调度表驱动的模式开关将其统一。从当前仓库实现看双管道架构依然健在提案所列各项变更也大多停留在设计层面但理解这份提案能让你在阅读core/src/tpu.rs、core/src/tvu.rs、core/src/replay_stage.rs、core/src/repair/repair_service.rs等模块时清楚地知道每条代码路径在整体演进蓝图中处于什么位置、为何如此组织以及未来可能向何处收敛。【免费下载链接】solanaWeb-Scale Blockchain for fast, secure, scalable, decentralized apps and marketplaces.项目地址: https://gitcode.com/GitHub_Trending/so/solana创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
