Breakpoint上的Solana验证器客户端Firedancer为何备受瞩目？

Foresight News ｜2024-09-24 19:00

Solana 验证器客户端 Firedancer 表现如何？怎样运行？

作者：Karen，Foresight News

在上周的 Solana Breakpoint 大会上，现场气氛活跃，生态产品发布接踵而至，各类丰富多彩的周边活动更是锦上添花。在这场盛宴中，尤为引人注目的亮点是 Solana 验证器客户端 Firedancer 的早期版本正式登陆主网，这一里程碑式的成就被赋予了特别的关注，标志着 Solana 网络将在性能上将实现质的飞跃，同时可避免 Solana 上单一客户端崩溃导致网络宕机的风险。

Firedancer 的开发历程可追溯至于 2021 年至 2022 年，作为由 Jump Trading Group 主导开发的 Solana 第二个验证器客户端（原有客户端 Agave 由 Anza 开发），其设计初衷在于消除单点故障隐患，增强网络的整体稳健性和坚韧性。与原有基于 Rust 的验证器不同，Firedancer 采用 C 语言编写，不包含 Rust 代码，这一选择显著降低了潜在漏洞对整个网络的影响，为 Solana 的安全性加上了又一道坚固的防线。

Firedancer 表现如何？

根据 Jump Crypto 首席科学官 Kevin Bowers 在 Solana Breakpoint 大会上的演示，Firedancer 展示了每秒处理超过 100 万笔交易的能力，这一数字远超 Solana 当前理论上的几万 TPS 极限。Kevin Bowers 还将这一成就形象地比喻为将「乡间小路」拓宽为「州际公路」，预示着网络成本和容量的双重优化。

Breakpoint上的Solana验证器客户端Firedancer为何备受瞩目？

Jump Trading 的核心工程师 Liam Heeger 则分享了 Firedancer 在测试网上的进展，该客户端已成功产出超过 2 万个区块，并实现了 1% 的质押比例。

另一工程师 Aryaman Jain 的演示进一步揭示了 Firedancer 在特定条件下的表现，如在 10 个验证器环境下，其 TPS 可达百万级别，每秒处理计算单元超过 12 亿次，同时展现出 3.5 Gbps 的 Blockspace 能力和 50 万 TPS 的 VM 执行效率。

Breakpoint上的Solana验证器客户端Firedancer为何备受瞩目？

Firedancer 如何运行？

Firedancer 围绕高性能计算堆栈和网络堆栈、Runtime 和共识机制三个主要组成部分构建。Firedancer 之所以能够将 Solana 网络的性能提升至 100 万 TPS（当前协议级别的限制将性能限制在 81,000 TPS 左右），关键在于其创新的架构设计和数据流优化。

该验证器采用了一种并发模型，通过少量线程执行多样化的作业，每个线程都专注于特定的任务，如网络数据包处理、交易验证、区块打包等。这种设计实现了资源的最大化利用与交易处理速度的显著提升。

Breakpoint上的Solana验证器客户端Firedancer为何备受瞩目？

具体来说，每个线程执行 11 个不同的作业之一。有些作业只需要一个线程来完成它们，但某些作业需要许多线程并行执行相同的工作。另外，每个线程都有一个 CPU core 来运行，并且线程拥有该 core 的所有权：永远不会休眠或让操作系统将其用于其他目的。

Firedancer 还引入了一个名为「tiles」的架构，每种 tile 代表了一个作业及其运行的线程和分配的 CPU core。这种组合方式使得性能调优变得灵活而高效。例如，net 和 quic 的每 tile 可处理 >100 万 TPS，而 verify 和 bank tiles 则专注于交易验证和区块执行，尽管它们的处理速度相对较低，但足以满足高并发场景下的需求。

Firedancer 官方文档中列出了 11 种 tile，分别为：

net：从网络设备发送和接收网络数据包（每 tile 可处理 >100 万 TPS）；
quic：接收来自客户端的交易，执行所有连接管理和数据包处理以管理和实施 QUIC 协议（每 tile 可处理 >100 万 TPS）；
verify：验证传入交易的加密签名，过滤无效交易（每 tile 可处理 20-4 万 TPS）；
dedup：检查并过滤掉重复的传入交易；
pack：当成为 leader 时，打包传入的交易并智能地安排它们执行；
bank：执行被安排的交易（每 tiles 可处理 20-4 万 TPS）；
poh：是一种连续在后台进行哈希运算的机制，将生成的哈希值与已执行的交易混合在一起，从而证明顺序性和时间性。
shred：当成为 leader 时，向网络分发区块数据；非 leader 时，接收并重传区块数据（吞吐量主要取决于集群大小。在基准测试中，如果集群规模较小，1 个 tile 可以处理>100 万 TPS）；
store：当成为 leader 时接收区块数据，或者当其他节点是 leader 时从其他节点接收区块数据，并将其存储在本地磁盘上的数据库中；
metric：收集有关其他 tiles 的监控信息并将其提供给 HTTP 端点；
sign：持有验证者私钥，并接收和响应来自其他 tile 的签名请求。

值得注意的是，在 Firedancer 成熟之前，其过渡版本 Frankendancer 已先行一步进入 Solana 主网。Frankendancer 是 Firedancer 和 Agave 部分代码的混合体，结合了 Firedancer 在网络堆栈和区块生产方面的优势，同时保留了 Agave 在执行和共识方面的功能。而 Firedancer 则是完全从头开始构建，不包含任何 Agave 的代码。