30 lines
2.3 KiB
Markdown
30 lines
2.3 KiB
Markdown
|
---
|
|||
|
|
title: 验证节点
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 历史
|
|||
|
|
|
|||
|
|
当我们首次启动Solana时，目标是降低TPS索赔的风险。 我们知道，在乐观并发控制和领导者在位时间太长之间，PoS共识并不是TPS的最大风险。 这是基于GPU的签名验证、软件流水线和并发银行业务。 因此，TPU诞生了。 在达到100kTPS之后，我们将团队划分出一个小组，争取突破710k TPS，另一小组则巩固验证程序管道。 因此，TVU诞生了。 当前的体系结构是按顺序和项目优先级进行增量开发的结果。 这并不反映我们曾经认为这些技术最为优雅的表现。 在领导者轮换的背景下，领导者与验证之间的明显区别变得模糊。
|
|||
|
|
|
|||
|
|
## 验证与领导之间的差异
|
|||
|
|
|
|||
|
|
管道之间的根本区别在于存在PoH的时间。 作为领导者的角色，我们处理交易，删除不良交易，然后用PoH哈希标记结果。 作为验证节点的角色，我们验证哈希，将其剥离并以完全相同的方式处理事务。 唯一的区别是，如果验证者看到错误的交易，不能像领导者一样简单地将其删除，因为这会导致PoH哈希发生变化。 相反，它拒绝整个区块。 流水线之间的另一个区别是银行交易_后_会发生的事情。 领导者将条目广播到下游验证节点，而验证节点已经在RetransmitStage中完成了此操作，这是确认时间的最优化。 另一方面，验证管道还有最后一步。 每当处理完一个区块后，它都需要权衡它所观察到的任何分支，并可能投一票，如果这样，则将其PoH哈希值重置为刚投票的块哈希值。
|
|||
|
|
|
|||
|
|
## 拟定设计
|
|||
|
|
|
|||
|
|
我们解开了许多抽象层，并构建了一个管道，只要验证者的ID在领导者时间表中显示，就可以切换领导者模式。
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
## 显著的变化
|
|||
|
|
|
|||
|
|
- TPU之外提升FetchStage和BroadcastStage
|
|||
|
|
- BankForks更名为Banktree
|
|||
|
|
- TPU转移到名为solana-tpu的新工具箱。
|
|||
|
|
- TPU的BankingStage吸收了ReplayStage
|
|||
|
|
- TVU消失了
|
|||
|
|
- 新的修复阶段吸收了碎片获取阶段和修复请求
|
|||
|
|
- JSONRPC服务是可选的-用于调试。 相反，它应该是单独的`solana-blockstreamer`可执行文件的一部分。
|
|||
|
|
- 新的MulticastStage吸收了RetransmitStage的重发部分
|
|||
|
|
- Blockstore下游的MulticastStage
|