Solana 验证节点内部架构解析：TPU 与 TVU 的流水线设计

Solana 验证节点内部架构解析TPU 与 TVU 的流水线设计【免费下载链接】solanaWeb-Scale Blockchain for fast, secure, scalable, decentralized apps and marketplaces.项目地址: https://gitcode.com/GitHub_Trending/so/solanaSolana 验证节点Validator之所以能以极高的吞吐处理交易核心秘诀在于其借鉴 CPU 设计思想的流水线Pipelining架构节点内部同时运行着两个分工明确的流水线——负责创建账本条目的 TPUTransaction Processing Unit交易处理单元与负责验证账本条目的 TVUTransaction Validation Unit交易验证单元。本篇指南以仓库文档 docs/src/validator/anatomy.md 为主干结合同目录下的 TPU/TVU 详细文档与core、turbine等 crate 的源码实现系统拆解流水线的设计动机、TPU/TVU 的各处理阶段以及围绕它们的 Blockstore、Gossip、Runtime 等配套设施帮助你从整体架构层面理解 Solana 节点如何高效运行。从洗衣房到区块链为什么要用流水线在深入 Solana 源码之前先理解流水线这一核心设计思想。Solana 验证节点在吞吐性能上远超同类项目靠的不是某个单点优化而是对数据流的持续并发处理——这正是计算机体系结构中经典的流水线技术。原文档用了一个非常直观的类比假设有三批衣服需要依次完成洗涤 → 烘干 → 折叠三道工序且每道工序由一台独立设备洗衣机、烘干机、折叠位负责。顺序执行时第二批衣服必须等第一批全部完成后才能开始设备存在大量空闲而流水线执行时第一批放入烘干机的同时就把第二批放入洗衣机第一批开始折叠时第三批已进入洗衣机——三批衣服在不同设备上同时推进整条流水线以最慢工序的速率源源不断地产出成品。流水线适用的前提条件恰好是 Solana 面临的场景存在连续的数据流交易、分片shred不断从网络流入处理步骤有先后依赖签名验证必须在记账之前记账必须在广播之前不同步骤由不同硬件负责网络输入、GPU 卡、CPU 核、磁盘写入、网络输出各司其职。CPU 设计中正是用流水线让取指、译码、执行等阶段并行推进Solana 验证节点将同样的思想迁移到区块链数据处理上从而让多批数据在同一时间处于不同处理阶段充分利用所有硬件资源。验证节点中的两条流水线TPU 与 TVU原文档明确指出验证节点包含两条流水线进程一条在 leader 模式下运行、名为TPU一条在验证者模式下运行、名为TVU。两条流水线经过的硬件完全相同——网络输入、GPU 卡、CPU 核、磁盘写入、网络输出——但它们的职责截然不同TPUTransaction Processing Unit负责创建账本条目ledger entries即区块生产block productionTVUTransaction Validation Unit负责验证账本条目即区块的验证与传播。关于验证节点的定位可参见 docs/src/what-is-a-validator.md同一份验证节点软件既可以运行投票/共识节点也可以运行不参与投票的 RPC 节点。本文讨论的是参与共识的投票节点。在 Solana 中当前负责生产区块的验证节点被称为leader由 PoS 权益大小决定出块机会其余节点则验证 leader 产出的区块——这正是 TPU 与 TVU 并存于同一节点程序中的原因。从源码结构看core/src/tpu.rs中定义了Tpu结构体其成员字段明确包含banking_stage: BankingStagecore/src/tpu.rs与broadcast_stage: BroadcastStage并在构造函数中调用BankingStage::new(...)core/src/tpu.rs完成组装core/src/tvu.rs中的Tvu结构体则持有retransmit_stage: RetransmitStage字段core/src/tvu.rs并通过RetransmitStage::new(...)core/src/tvu.rs初始化。两条流水线在代码层面被清晰地拆分为独立模块验证了文档描述的架构。TPUleader 模式下的四阶段生产流水线TPU 的职责是区块生产其完整工作流程在 docs/src/validator/tpu.md 中有详尽的阶段划分。交易由客户端其他验证节点或普通用户编码后通过 QUIC 流发送到验证节点依次经过以下四个阶段1. QUIC 流接收quic streamerQUIC 流接收器负责分配包内存、从 QUIC 端点读取包数据并对同一时间到达的包做合并coalescing。这里有一整套基于stake质押量的资源分配机制每个流stream用于传输一个包对于由IP 地址节点公钥标识的客户端与服务器之间可并发建立的 QUIC 连接数存在上限每条连接上可并发打开的流数也有限制且限制基于发送方的 stake——stake 越高的客户端被允许打开越多的流在总上限之内系统还按每秒包数PPS做速率限制同样与 stake 挂钩stake 越高带宽越好若传输速率超限服务器会以错误码15STREAM_STOP_CODE_THROTTLING流停止-节流丢弃该流客户端应退避重试指数退避——这体现了高质押节点在网络资源上的优先权。2. 签名验证阶段sigverify stage签名验证阶段对包做去重deduplicates并实施负载削减load-shedding以剔除过量包随后通过置位包的 discard 标志过滤掉签名无效的包。对应实现位于 core/src/sigverify_stage.rs其中引入了Deduper去重器并统计total_dedup、total_discard_random、count_discarded_packets等指标来监控丢弃行为。由于签名验证是计算密集操作该阶段也是 GPU 发挥作用的主要场所。3. 记账阶段banking stage记账阶段决定每个包是转发forward、暂存hold还是处理process。当节点检测到自己就是区块生产者leader时它会以tip slot 处的 BankSolana 的账本状态抽象处理暂存的包和新到达的包将它们组织成账本条目Entry并同时生成 Proof of HistoryPoH哈希链。对应实现位于 core/src/banking_stage.rs其中的BankingStageStats记录了forwarded_transaction_count、forwarded_vote_count、dropped_forward_packets_count等统计core/src/banking_stage.rs可见转发是 banking stage 的重要行为——非 leader 节点或高峰期的多余交易会被转发给其他节点处理。4. 广播阶段broadcast stage广播阶段接收 banking stage 产出的有效交易已打包为 Entry将它们切分成 shred分片通过Turbine 树形结构发送给网络中的对等节点。在发送前节点会执行**序列化、签名、生成纠删码erasure codes**等操作再投递给合适的网络对等节点。对应实现位于 turbine/src/broadcast_stage.rsBroadcastStage结构体定义于第 210 行broadcast_shreds函数turbine/src/broadcast_stage.rs负责为每个 shred 构建 turbine 重传树并分发。以上四阶段构成一条完整流水线当上一批包还在广播阶段时新一批包已经在签名验证阶段并行推进四批数据同时在四个阶段运行节点吞吐因此显著提升。TVU验证者模式下的验证与传播流水线TVU 的职责是验证并传播区块并将区块中的交易送入运行时Runtime处理。其流程在 docs/src/validator/tvu.md 中描述首当其冲的是重传阶段Retransmit Stage。Retransmit Stage分片的接收与转发作为 TVU 流水线的入口重传阶段接收来自网络的 shred对其进行验证并转发给 Turbine 树中的下游节点确保区块数据能在整个集群内快速传播。对应实现位于 turbine/src/retransmit_stage.rsRetransmitStage定义于第 421 行其内部核心函数包括retransmitturbine/src/retransmit_stage.rs、retransmit_shredturbine/src/retransmit_stage.rs以及retransmitterturbine/src/retransmit_stage.rs。重传的详细机制如广播树、纠删码冗余、分片确认等可进一步阅读 turbine/src/retransmit_stage.rs 与 docs/src/consensus/turbine-block-propagation.md。TVU 的后续处理TVU 在重传阶段之后会利用Blockstore持久化分片、通过ReplayStage重放交易即把分片还原为 Entry 并交给 Bank 执行、在 PoH 验证完成后将交易送入 Runtime 处理最终产出验证后的区块与投票信息。关于 TVU 如何与 Blockstore、Bank 交互详见下文及 docs/src/validator/blockstore.md。围绕流水线的三大配套设施TPU/TVU 两条流水线并非孤立运行Solana 验证节点还依赖以下基础设施来支撑生产—验证—共识的完整闭环。它们与流水线架构共同构成了验证节点的整体解剖图原文档配图 validator.svg 展示了这一总览结构。Blockstore分叉管理与持久化在区块达到 finality最终性之前验证节点必须维护所有可能有效的链即分叉forks分叉如何因 leader 轮换自然产生参见 docs/src/consensus/fork-generation.md。Blockstore 正是节点应对分叉的数据结构持久化只要收到的 shred 由该 slot 的预期 leader 签名与 leader schedule 一致就立即存储。Blockstore 位于验证流水线前端紧跟网络接收与签名验证之后修复Repair能够提供任意已接收 shred 的服务含签名保留来源链新近 shred 从 RAM 或近期文件中服务较旧的从深层存储中服务分叉支持Blockstore 以leader slot shred index作为键空间存储全部 skip-list 结构无需预先选择跟随哪个分叉从而支持从 Bank checkpoint 回滚重放重启恢复经过正确的剪枝/剔除后可从 slot 0 开始按顺序枚举条目重放账本。Blockstore 为每个 slot 维护SlotMeta元数据包括num_blocks用于链式连接到前一 slot、consumed已连续消费的最高 shred 索引、received已接收的最高 shred 索引、next_slots可能链接到的未来 slot 列表、last_index标记为末位 shred 的索引、is_connectedslot 0..n 是否无空洞地完整连接等字段。它向 ReplayStage 提供订阅式 API如get_slots_since、get_slot_entriesReplayStage 借此找到能挂在最近投票之下的最长条目链若该链不挂在最新投票之下则回滚 Bank 到该投票处重新重放。当投票达到最大锁定期max lockout后不在该投票 PoH 链上的 Blockstore 内容即可被剪枝清除。Gossip 服务控制平面的信息广播Gossip 服务是节点接入**控制平面control plane**的网关负责让集群中所有节点共享已签名的数据对象联系信息、账本高度、投票等其协议细节见 docs/src/validator/gossip.md。它每十分之一秒发送一次 push/pull 消息Push告知集群自己有新信息发送给PUSH_FANOUT个 push 对等节点收到方检查重复重复则丢弃若是低质押节点转发还可能回复PushMessagePrune、存储新数据并继续转发、丢弃超过PUSH_MSG_TIMEOUT的过期消息Pull向随机单个对等节点询问是否有新信息消息内含一个表示自己已拥有什么的Bloom 过滤器接收方遍历自身值构造一个包含未命中过滤器且能装进消息的响应剪枝Prune当存在比直接 push 更高质押加权的路径时收到 prune 消息的节点会丢弃对应的 push 对等节点push 对等集合每PUSH_MSG_TIMEOUT/2毫秒轮入一个新节点保持新鲜防止 Eclipse 攻击节点的选择权重基于距上次被选中时间与stake 权重的自然对数ln计算——取 ln 是为了让低质押节点只需等待数个 ln(stake) 秒即有机会被选中兼顾网络覆盖率与公平性且攻击者无法影响这些参数。Runtime并发的交易执行引擎流水线最终要把交易交给Runtime执行。Runtime 是一个并发交易处理器交易预先声明数据依赖动态内存分配显式化通过将程序代码与其操作的状态分离Runtime 能够编排并发访问——只读账户的交易并行执行写入账户的交易串行执行。其设计要点见 docs/src/validator/runtime.md账户由 lamport 余额与程序专属内存构成程序通过定义良好的入口点entrypoint与 Runtime 交互TPU 与 TVU 的执行路径略有差异TPU 的 Runtime 确保PoH 记录先于内存提交TVU 的 Runtime 确保PoH 验证先于任何交易处理Runtime 强制执行四条规则只有 owner 程序可修改账户内容因此 Assign 时数据向量保证为零交易执行前后所有账户总余额不变只读账户执行后余额必须等于执行前交易内所有指令原子执行任一失败则全部账户修改被丢弃系统程序SystemProgram提供CreateAccount、CreateAccountWithSeed、Assign、Transfer等指令用于创建账户、派生地址、分配归属与转账。源码地图从文档到实现的索引以下文件路径可供继续深入研读将文档中的架构描述与真实实现一一对应文档章节对应实现节点总览与两条流水线docs/src/validator/anatomy.mdTPU 四阶段详述docs/src/validator/tpu.md、core/src/tpu.rs签名验证阶段core/src/sigverify_stage.rs记账阶段core/src/banking_stage.rs广播阶段Turbineturbine/src/broadcast_stage.rsTVU 与重传阶段docs/src/validator/tvu.md、core/src/tvu.rs、turbine/src/retransmit_stage.rs分叉与持久化docs/src/validator/blockstore.md控制平面docs/src/validator/gossip.md交易执行引擎docs/src/validator/runtime.md总结Solana 验证节点的强大吞吐能力根源在于它将 CPU 流水线思想完整迁移到区块链数据处理中以相同的硬件网络、GPU、CPU、磁盘同时驱动TPU 生产流水线与TVU 验证流水线让多批交易始终处于不同处理阶段并行推进。TPU 的 QUIC 接收 → 签名验证 → 记账 → 广播四阶段与 TVU 的重传、Blockstore 持久化、Runtime 执行相互配合再辅以 Gossip 控制平面与基于 stake 的资源分配机制构成了一个高度并发、环环相扣的节点架构。理解这套流水线设计是深入 Solana 共识、调度与性能调优的起点。【免费下载链接】solanaWeb-Scale Blockchain for fast, secure, scalable, decentralized apps and marketplaces.项目地址: https://gitcode.com/GitHub_Trending/so/solana创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考