Understanding the Highly Anticipated Firedancer on Breakpoint in One Read

原文作者: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 还将这一成就形象地比喻为将「乡间小路」拓宽为「州际公路」,预示着网络成本和容量的双重优化。


Jump Trading 的核心工程师 Liam Heeger 则分享了 Firedancer 在测试网上的进展,该客户端已成功产出超过 2 万个区块,并实现了 1% 的质押比例。
另一工程师 Aryaman Jain 的演示进一步揭示了 Firedancer 在特定条件下的表现,如在 10 个验证器环境下,其 TPS 可达百万级别,每秒处理计算单元超过 12 亿次,同时展现出 3.5 Gbps 的 Blockspace 能力和 50 万 TPS 的 VM 执行效率。


Firedancer 如何运行?
Firedancer 围绕高性能计算堆栈和网络堆栈、Runtime 和共识机制三个主要组成部分构建。Firedancer 之所以能够将 Solana 网络的性能提升至 100 万 TPS(当前协议级别的限制将性能限制在 81, 000 TPS 左右),关键在于其创新的架构设计和数据流优化。
该验证器采用了一种并发模型,通过少量线程执行多样化的作业,每个线程都专注于特定的任务,如网络数据包处理、交易验证、区块打包等。这种设计实现了资源的最大化利用与交易处理速度的显著提升。


具体来说,每个线程执行 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 的代码。
Firedancer 有何影响?
无疑,Firedancer 的推出对 Solana 生态系统具有重大影响,将极大地丰富验证器的多样性,进一步削弱单点故障对网络稳定性的影响,为 Solana 网络的可靠性筑起一座更加坚固的堡垒。
此外,Firedancer 保持了与现有协议的向后兼容性,能够确保生态系统的平稳过渡,无需 DApp 开发者及用户做出重大调整。
尽管目前 Firedancer 仍处于非投票模式,且需经历持续不断的优化与审核,但这为 Solana 网络的未来发展描绘了一幅更加充满希望的蓝图。
参考:
1、
https://www.youtube.com/watch?v=InGI7BDUeX4list=PLilwLeBwGuK4eY3nT0vvvJ4GmcJLImcQEindex=14
2、
https://firedancer-io.github.io/firedancer/guide/tuning.html
3、
https://solanacompass.com/learn/Validated/firedancer-w-kevin-bowers