Solana 验证者的 TPU 和 TVU 是什么？出块与传块的两条流水线

验证者不是一台机器，是两条流水线

很多人把验证者想成一个”收交易、出块”的黑盒：交易丢进去，等它出现在链上就行。Agave 官方文档把 Solana 验证者拆成两套逻辑：TPU（交易处理单元）负责块的生产端，TVU（交易验证单元）负责块在网络里的传播与回放到执行端。从可观察证据出发，这条分界解释了大量日常现象——为什么同一笔交易发给不同节点体验完全不同，为什么节点端口开了却仍然收不到某些数据，为什么质押规模会间接影响一个普通发送者的送达率。

TPU：从 QUIC 流到打包广播

TPU 是负责出块的那套逻辑。客户端与验证者的连接走 QUIC 流，quic streamer 阶段负责分配内存、读取包数据并把同时到达的包做合并；连接层面有配额：以节点身份标识的客户端可建立的并发连接数有上限，单连接内并发流的数量按发送方质押权重分配，质押越高的客户端能开更多流，系统还按质押对每秒包数做限速，超限时服务器可以以”被限流”的错误码丢弃该流，官方文档要求客户端此时做指数退避重试。注意这里的配额单位：限制落在连接与流上，不是落在”每笔交易”上，一个高频发送者占住配额，同一条连接后来的交易就一起排队——这解释了部分钱包反复重连却仍发不进去的体感来源。之后是 sigverify 阶段：先去重，再对超量流量做有选择的丢弃，最后验证签名、给无效签名的包打上丢弃标记，三件事按这个顺序做，意味着过载时最先掉的是还没验签的原始流量，而不是随机丢掉正常交易。banking 阶段在节点临近出块时开始缓存收到的交易包，一旦确认自己成为区块生产者，就用当前最新槽位的 Bank 把攒下和新到的交易一起处理；打包后的数据交给广播阶段，切成碎片经 Turbine 树向外发。中间还有转交阶段：按优先级排序后把交易递给当前或即将出块的节点，普通交易是否转交受开关与质押覆盖规则约束，投票类交易则总是转——投票是共识原料，优先级由协议兜底，普通交易则更多依赖费用与路由。把这几段串起来看，一个包的旅程是：QUIC 收包合并、去重与验签、缓存进 banking、被出块者采纳成条目、切块广播；任何一个环节的损失都会在链上留下同一种表象——“交易没到”，但排查的面板完全不同。

TVU 与观察者能核什么

TVU 对外看起来是一个 UDP 端口——典型是 8002——文档说明内部实际用多套 socket 绑在同一端口上靠内核分流，节点把这个地址经 Gossip 发布进 ContactInfo 供全网发现，其他节点只需知道这一个地址对，收包由内核摊到各 socket 对应的线程。收到块后，retransmit 阶段继续向下游转传，数据最终进入重放路径供执行与投票。对排查问题的人，这套分工给出三个可核验的点：交易迟迟不进块，先分清是没到正确的领导者、在 sigverify 被丢弃，还是排队时优先级不够；质押权重直接换算成连接带宽，匿名小钱包的高频发送更容易撞上限流；观察节点间的块传播缺漏，对应的排查面在 TVU 侧的转传链而不是 TPU。还有一条隐含约束值得普通用户留意：交易广播到网络里之后，能否进入下一个领导者的 banking 队列，取决于沿途节点的转交策略与排队状态，客户端的”发送成功”只代表 QUIC 连接收下过这个包，不代表任何节点承诺处理它——判断是否真的在途，最终还是回到签名状态查询与超时重发的纪律上。Turbine 是什么？Solana 区块怎么拆成碎片传到全网 讲过 Turbine 怎么把块切片铺满全网，Sealevel 怎么决定谁能同时跑？Solana 并行执行的账户读写集规则 讲过执行阶段如何按账户读写集并行——两篇加起来正好覆盖这里说的两段管道。本文为机制说明，不构成任何投资建议。