Solana Firedancer是什么？如何运行？有何影响？Alpenglow、staking份额等

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

那么Firedancer是什么？Firedancer如何运行？Firedancer有何影响？下面就和脚本之家小编一起详细了解下吧！

Firedancer 是什么？

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

Firedancer 是由 Jump Trading Group 区块链部门 Jump Crypto 开发的 Solana 验证者客户端。验证者客户端是节点运行以接收交易、执行交易、构建区块并对链状态进行投票的软件，因此其设计直接决定了 Solana 的运行速度和可靠性。

这项工作始于 2022 年，任务说明不同寻常。Jump 的工程师没有对现有的 Rust 软件进行分叉，而是从第一性原理出发，用 C 语言重新构建了验证者，借鉴了其交易台使用的低延迟技术。其结果是不与其他 Solana 客户端共享任何共识或执行代码，这恰恰是其价值所在。

Solana 的大部分网络目前仍运行在 Agave（由 Anza 维护的客户端）的衍生版本上，其中包括 Jito 专注于 MEV 的分叉以及 Harmonic 的出块变体。Fidelity 的研究部门认为 Firedancer 是唯一能够在规模化运行中提供真正代码独立性的客户端，而 Overclock 基于 Go 语言的 Mithril 客户端在主网上仍缺乏有意义的staking份额。

Firedancer 不是代币、airdrop或协议分叉。它不会触及 SOL 发行、staking奖励和交易规则，因为每个客户端都必须遵循相同的协议规范。改变的是验证者执行任务的效率，以及其故障独立的程度。

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 借鉴了高频交易系统的设计：将工作拆分为小型专业化进程，将数据保留在预分配的内存中，并将操作系统从热路径中移除。四项工程选择完成了大部分工作。

1. 基于切片（Tile）的架构

Firedancer 将验证者划分为被称为 tile 的独立进程，每个进程负责一个阶段，例如接收数据包、验证签名、打包交易、重放区块或签名。每个 tile 通常拥有专用的 CPU 核心，并通过共享内存队列而不是锁或系统调用与其邻居传递消息。

所有内存都在启动时预留，并且Jump 的安全报告指出完全禁止动态分配。这消除了一整类分配错误，并意味着验证者不会因内存耗尽而崩溃。相比之下，Agave 作为单个大型多线程进程运行，共享公共地址空间。

2. 沙盒安全模型

由于验证者守护着质押资本，Firedancer 将每个 tile 都视为可能遭到compromise。每个进程启动时，仅映射其所需的内存，然后在处理来自对等节点的任何不受信任的网络数据之前，将自己锁定在沙盒内。

这种纵深防御设计的主要层级包括：

• Seccomp 过滤器：每个 tile 预先声明其可以调用的 Linux 系统调用，从而缩小入侵者在compromise单个组件后能够触及的内核攻击面。
• Landlock 规则：文件系统访问受限于经过验证的白名单，因此被劫持的网络工作单元无法打开磁盘上的敏感文件（例如验证者的身份 keypair）。
• 资源限制：针对核心转储、栈增长、文件描述符和锁定内存设置的显式 rlimit 上限，可防止任何单个工作单元耗尽其他进程所依赖的内核资源。
• 根目录透 视：每个工作单元将其可见的文件系统根目录 swap 为一个空目录，从而隐藏宿主机的其余部分，让攻击者无可探索之物。
• 命名空间隔离：工作单元在崭新的 Linux 命名空间内运行，并被阻止创建新的命名空间，这切断了共享服务器上常见的提权途径。
• 隔离签名：private key 仅存在于专用的签名工作单元中，该单元按 link 接受格式正确的请求，因此遭到攻击的八卦工作单元无法伪造投票或交易。

3. 内核绕过网络

标准验证者会将每个数据包路由穿过 Linux 网络协议栈，这会增加在负载下不断累积的复制、中断和上下文切换。Firedancer 使用 AF_XDP 直接从网卡将数据包拉取至其自身的内存中，因此吞吐量受限于硬件，而不是受限于介于中间的软件。

最上层是 fd_quic（Jump 对 Solana 用于交易摄取的 QUIC 传输协议的实现），以及跨核心的流量转向。网络工作单元进行忙轮询而不是休眠，以牺牲电力来换取可预测的延迟。Figment 归功于更快的握手和更强的垃圾邮件过滤能力，在 2025 年 10 月将其旗舰节点迁移至 Jump 的协议栈后，保持了验证者的响应能力。

4. 并行签名验证与重放

检查 Ed25519 签名是验证者执行的最繁重的工作之一。Firedancer 并行运行多个验证工作单元，并使用宽向量指令来同时检查一批批签名。其文档估计，在现代服务器硬件上，每个验证工作单元每秒可处理大约 20,000 到 40,000 笔交易。

重放（即重新执行区块以确认其结果的步骤）也被并行化。调度程序会同时运行触及不同账户的交易，这种设计带来了速度，但也产生了 Jump 2026 年审计竞赛中最严重的漏洞（一个可能导致共识分歧的调度缺陷）。

Firedancer 有何影响？

无疑，Firedancer 的推出对 Solana 生态系统具有重大影响，将极大地丰富验证器的多样性，进一步削弱单点故障对网络稳定性的影响，为 Solana 网络的可靠性筑起一座更加坚固的堡垒。

此外，Firedancer 保持了与现有协议的向后兼容性，能够确保生态系统的平稳过渡，无需 DApp 开发者及用户做出重大调整。

尽管目前 Firedancer 仍处于非投票模式，且需经历持续不断的优化与审核，但这为 Solana 网络的未来发展描绘了一幅更加充满希望的蓝图。

Solana Firedancer 亮点

根据 Solana 技术 Discord 服务器中的消息，到本周末，Solana 的核心开发人员希望该链的低风险测试网络上的「绝大多数」处理能力能够通过 Firedancer 的早期版本 Frankendancer 运行。并号召 Solana 验证者（即运行为网络提供动力的计算机的人）采取行动。自 2022 年起，该升级就一直在筹备中，当时该链经常出现故障，升级被视为对 Solana 稳定性和速度的提升。

史上最快区块链即将诞生？

Firedancer 的支持者认为，这款由交易巨头 Jump 的加密货币部门开发的软件将使 Solana 在加密货币吸引全球金融市场进入区块链的竞赛中占据无可匹敌的优势。他们指出，它的理论速度为：每秒 100 万笔交易，比当今任何基于区块链的系统都要快几个数量级。

作为 Jump Crypto 团队主导开发的 Solana 新验证器客户端，它从根本上致力于提升 Solana 网络的吞吐量和安全性。早在 2022 年，Firedancer 就开始了开发计划，它与 Solana 现有的 Rust 语言客户端（Agave）形成了鲜明的对比。Firedancer 采用 C 和 C++ 语言进行重新设计，这一决定极大地减少了由于内存泄漏等问题导致的系统崩溃的概率，因此比现有客户端更加稳定。

在早期阶段，Firedancer 的开发面临了许多挑战。例如，由于新软件的复杂性，验证者在测试过程中发现了许多缺陷，导致很多验证者对其持谨慎态度。

Firedancer 本身尚未确定发布日期。目前，Jump Crypto 仅推出了 Frankendancer，它是一种混合体，结合了 Firedancer 和 Solana 主要客户端架构的元素。本周之前，只有一小部分验证者采用了 Frankendancer；许多人告诉 CoinDesk，他们发现它存在缺陷且容易崩溃。

Solana 验证者社区的长期成员 Kollen House 表示：「让这个项目继续运行非常困难，但我们做到了。」他认为，推动更广泛地采用 Frankendancer 的新举措是该软件「成熟」的标志。

Firedancer 技术创新

Firedancer 与现有的 Solana 客户端相比，带来了多个重要的技术创新，尤其是在高性能计算和并行化处理方面。Firedancer 的架构由三个核心组成部分构成：高性能计算堆栈、网络堆栈、运行时和共识机制。这些创新使得 Solana 网络的吞吐量得到了大幅提升，理论上可以达到每秒超过 100 万笔交易，远远超过现有系统的吞吐量极限。

并行性与高效计算

Firedancer 的设计依赖于高并发的计算模型，每个验证节点通过多个独立的线程执行不同的任务，如交易验证、区块打包和数据处理等。这种并行化处理使得系统能够更加高效地分配计算资源，最大化吞吐量并提高处理速度。每个线程专注于某一任务，并拥有专门的 CPU 核心，这种设计避免了资源的浪费。

瓦片架构（Tiles Architecture）

Firedancer 引入了创新的瓦片架构（tiles），每个瓦片对应一个特定任务，并与一个特定的线程和 CPU 核心绑定。这种灵活的架构使得不同类型的任务能够根据实际需求灵活分配资源。例如，网络堆栈（net） 和 QUIC 协议 的瓦片处理速度极快，每秒能够处理超过 100 万笔交易，而 交易验证（verify） 和 银行操作（bank） 瓦片则专注于事务的安全验证和执行，虽然其吞吐量较低，但能够处理高并发的交易请求。

高效的共识与网络传输机制

Firedancer 的共识机制通过优化网络数据流和分布式处理，降低了交易验证的延迟，提高了整个系统的响应速度。这使得 Solana 网络在高并发和负载激增时，能够保持其高效运作，避免因单点故障导致的系统崩溃。

Firedancer 对 Solana 的影响

突破性吞吐量

Firedancer 的最大亮点之一便是其提升的性能。根据开发团队的展示，Firedancer 每秒能够处理超过 100 万笔交易，远超 Solana 当前 50,000 TPS 的理论极限。这一性能大幅提高了 Solana 区块链在全球金融市场中的竞争力，也为未来的 DeFi 和 Web3 应用提供了更为强大的基础设施。以 Visa 等传统金融支付系统为参考，其交易吞吐量通常仅为每秒数万笔。Firedancer 的性能无疑将让 Solana 在这些竞争者中脱颖而出，成为未来区块链支付的领导者。

增强网络稳定性与安全性

除了性能提升，Firedancer 还大大增强了 Solana 网络的安全性。通过引入与现有系统兼容的新客户端，Firedancer 不仅增强了 Solana 网络的去中心化程度，还进一步减少了由于单个客户端故障所带来的网络崩溃风险。与原有的 Rust 客户端不同，Firedancer 使用 C 和 C++ 编写，不仅能有效避免由于内存泄漏等问题导致的宕机，而且还能在出现故障时，将影响范围降到最低。

降低网络升级的复杂性

Firedancer 的引入还为 Solana 网络的升级提供了新的解决方案。在此前的版本中，Solana 必须依赖于较少的客户端进行网络更新和维护，而这种单点依赖往往会导致升级过程中的技术难题。随着 Firedancer 的加入，Solana 现在有了更多的客户端选项，使得网络升级更加灵活和高效。此外，Firedancer 与现有协议兼容，保证了生态系统的平稳过渡，无需 DApp 开发者和用户进行重大调整。

Frankendancer 与 Firedancer

这两个名称经常被混淆。Frankendancer 是一个混合体，它将 Firedancer 的网络和区块生产工作单元与 Agave 的运行时和共识代码配对。它于 2024 年 9 月上线 mainnet，允许运营商采用 Jump 更快的前端，而无需信任新的共识逻辑，其质押份额从 2025 年中期的约 8% 增长到 2025 年 10 月的约 21%。

完整的 Firedancer 取代了借来的部分。它在 Jump 自己的代码库中实现了整个管道，包括重放、共识和账户数据库，因此 Agave 中的漏洞不应波及它。这种独立的故障域正是 Solana 真正需要的，它于 2025 年 12 月在 mainnet 上线。

Frankendancer 的运行即将结束。Jump 表示，一旦 Alpenglow 激活，它将结束对该混合体的支持，因为其借用的 Agave 共识代码正在被替换。Solana Compass 数据显示，截至 2026 年 10 月中旬，Frankendancer 的质押份额已降至约 0.3%，仅为其 2025 年峰值的一小部分。

Firedancer 统计数据与趋势

进入 2026 年 10 月中旬，Firedancer 保证了 Solana 大约 15% 的质押份额，高于发布时的不到 1%。以下数据借鉴自来自 Jump Crypto、Solana Compass 和 Fidelity 的 FCAT 研究团队的最新数据。

截至 2026 年 10 月中旬的关键 Firedancer 采用率和安全指标：

• 质押份额：Jump 在其 10 月 16 日的更新中表示，Firedancer 确保了约 15% 的网络质押，使其成为唯一承载实质性共识份额的独立客户端。
• 客户端组合：Solana Compass 统计在 10 月 13 日的前 500 大验证者中，Firedancer 系列客户端的质押份额占 15.8%：HarmonicFiredancer 占 7.1%，Firedancer 占 6.8%，FireBAM 占 1.6%，Frankendancer 占 0.3%。
• 增长曲线：完整的 Firedancer 在 2025 年 12 月发布时拥有不到 1% 的已质押 SOL，因此达到约 15% 经历了大约十个月刻意谨慎的推出过程。
• Agave 统治地位：FCAT 数据显示，Jito BAM 和标准 Jito 客户端共同运行了约 63% 的质押，Harmonic 变体接近 24%，而纯正的 Agave 仅占 1.2%。
• 验证者集合：根据 Solana Compass 的数据，2026 年 10 月中旬，Solana 拥有 678 个验证者，持有约 4.39 亿枚质押的 SOL，Nakamoto 系数自 8 月初以来一直保持在 18 不变。
• 审计竞赛：Jump 于 2026 年 4 月 9 日至 5 月 9 日举办了价值 100 万美元的 Immunefi 竞赛，吸引了来自 162 名研究人员的 809 份报告，并产生了 127 个独特的安全发现。
• AI 提交：Jump 认为，几乎每一份竞赛报告都是由 AI 代理发现或编写的，这使得平均报告长度从 2025 年之前的 406 个字激增至 1,064 个字。
• 赏金加码：Firedancer 全新推出的内部赏金平台提供双倍奖励，对于与 Alpenglow 相关的漏洞则提供三倍奖励，活动持续到 11 月 20 日，每提交一次需销毁 1 枚 SOL 以遏制垃圾信息。
• 网络可靠性：FCAT 发现，在 2026 年连续两年内，没有报告显示 Solana 主网发生过中断，投票成功率接近 99.7%，这与早期的停机形成了鲜明对比。

有关更广泛的网络数据，请参阅我们对Solana 质押统计数据与趋势的详细分析。

主网启动与推出

Jump 于 2025 年 12 月 12 日在阿布扎比举行的Solana Breakpoint 大会上宣布了 Firedancer 的完整主网首秀。据Unchained 报道，在宣布之前，该客户端已在少数验证者中默默运行了大约 100 天，生产了超过 50,000 个区块，且没有出现重大问题。

随后，Jump 选择采用缓慢推出而非强势推进的策略。创始工程师里奇·帕特尔（Ritchie Patel）于 2026 年 5 月向 CoinDesk 表示，在安全审计完成之前，团队一直在限制广泛采用，这背后有一项从 4 月 9 日持续到 5 月 9 日的 100 万美元公开审计竞赛作为支撑。

采用率仍在稳步攀升。全功能 Firedancer 最初占质押 SOL 的比例不到 1%，而 HarmonicFiredancer 和 FireBAM 等出块变体随后扩大了其影响力。截至 2026 年 10 月，Jump 将其份额估计在 15% 左右，这是一个可观的比例，但距离客户端故障可能导致最终性暂停的三分之一水平还很远。

Firedancer 与 Alpenglow 迁移

近期最受关注也是最棘手的话题是：Solana 计划于 2026 年 10 月 21 日在第 1064 个纪 元（epoch）激活 Alpenglow，而 Solana 基金会明确表示，在迁移期间不支持 Firedancer 和 Frankendancer。每个验证者都必须运行基于 Agave 4.3.0 构建的 Agave 客户端。

在实践中，Firedancer 运营商必须在激活前临时切换到 Agave、Jito-Solana 或 Harmonic Salsa。交接过程需要由占质押份额 82% 的创世证书进行签名，Solana Compass 计算得出，如果排除占 15.8% 的 Firedancer 家族份额，将剩下约 84% 的份额，如果这些运营商未能切换，这将是一个只有两个百分点的微弱缓冲。

这一事件暴露了 Solana 多客户端方案中的一个缺口。在 Alpenglow 的初期阶段，几乎所有质押都将运行 Agave 衍生软件，这正是 Firedancer 旨在终结的单一文化（monoculture）。Jump 尚未公布支持 Votor 的 Firedancer 版本的发布日期，不过其三倍的 Alpenglow 赏金表明该工作正在积极推进中。

收益解释了这种权衡。Alpenglow 将投票移至链下并形成证书，将最终性目标缩短至 150 毫秒（而不是 12.8 秒），并能容忍 20% 的恶意质押加 20% 的离线质押。在单一、经过充分排练的代码库上运行单槽共识兑换，限制了协调风险，代价则是牺牲了短期的客户端多样性。

为什么客户端多样性至关重要

Solana 的历史解释了这种紧迫性。Helius 的网络中断记录将大多数重大停机归咎于验证者软件中的漏洞，而不是共识设计中的缺陷。当几乎每个节点都运行相关代码时，一个缺陷就可能同时停止所有地方的出块，而不管链在纸面上的运行速度有多快。

阈值至关重要。在 Solana 当前的共识下，持有超过三分之一质押的客户端如果发生故障，可能会暂停最终性；而如果超过三分之二，有漏洞的客户端则可能最终确认无效状态。Ethereum 将把每个客户端保持在三分之一以下视作底线安全规则，而 Solana 距离达到这一标准还有很大差距。

多样性还关乎验证者的运行地点。Fidelity 的 FCAT 报告发现，法兰克福和阿姆斯特丹集中了大约 40% 的质押份额，而单一托管商在 2026 年 8 月发生的路由故障导致大约 90 个验证者离线了 33 分钟。当托管和地理位置也分散开时，软件独立性才能发挥最大的作用。

机构正密切关注这些数字。现货 SOL 产品（包括staking ETF）以及代币化基金现在都依赖于 Solana 的持续在线，而一个可靠的第二客户端回答了风险团队会问的一个核心问题：当占主导地位的软件崩溃时会发生什么？Firedancer 目前是 Solana 唯一令人信服的答案。

Firedancer 与 Solana 的路线图

Firedancer 处于多项并行升级的核心，这些升级正推动 Solana 朝着更重的区块、更短的区块时间和抗量子密码学迈进。每一项升级都增加了验证者必须承担的工作负载，而这正是 Jump 架构大显身手的地方。

更大的区块与更快的 Slot

Solana 于 2026 年 10 月完成了从 400 毫秒到 200 毫秒 Slot 的过渡，使leader出块频率翻倍。每个区块的计算限制也有所提升，在 2026 年 7 月下旬达到了 1 亿计算单元，而 FCAT 测得在测试周期间的区块利用率大约在 30% 到 45% 之间。

Firedancer 工程师主张采取更激进的举措，提议 SIMD-0370 以提高区块计算限制，其理由是 Alpenglow 让更高的硬件扩展变得安全。更快的 Slot 和更大的区块都会奖励那些积极进行并行化的客户端，这也是为什么许多人预计吞吐量将在迁移后随着 Firedancer 的普及而提升。

值得关注的核心路线图里程碑

除了 Alpenglow 的第一阶段外，多项协议变更将决定 Firedancer 的工作量及其恢复 stake 的速度。由于多数变更仍处于提议阶段，时间表可能会在没有太多预警的情况下发生变动。

接下来一年中与 Firedancer 最相关的里程碑：

• Votor 支持：Firedancer 必须在运营商回归之前发布并强化其自身的 Alpenglow 投票协议实现，而 Jump 尚未公布主网发布日期。
• Rotor 升级：Alpenglow 的第二阶段用单一的中继层取代了 Turbine 区块传播，但 Solana 基金会表示 Rotor 尚未排入任何发布日程。
• Leader 交接：Agave 4.4 中的快速 leader 交接允许 leader 在其父区块最终确认之前就开始构建区块，这增加了一项所有客户端都必须匹配的新行为。
• Falcon 签名：2026 年 4 月，Anza 和 Firedancer 独立采用了 Falcon，这是一种由 NIST 选定的抗量子方案，具有最小的签名大小，从而为高吞吐量网络将带宽成本控制在可管理的范围内。
• Falcon 系统调用：SIMD-0416 提议在运行时中添加 Falcon 验证系统调用，让开发者能够在任何强制性的全网签名迁移发生之前，构建抗量子的金库与转账功能。
• 计算限制：关于将区块计算限制进一步提高至超过 1 亿个单位的讨论仍在进行中，每一步提升都抬高了 Firedancer 并行设计旨在利用的硬件上限。

Firedancer 硬件要求

早期报道暗示 Firedancer 将降低验证成本。但实际情况恰恰相反：更短的 Slot 和更大的区块不断抬高门槛，Firedancer 针对的是配置优良的裸机服务器，而不是普通的家用机器。

根据 Firedancer 文档和运营商基准测试，典型的 2026 年生产环境配置如下：

• CPU：将 12 核、24 线程、主频 2.8GHz 的芯片视为底线，不过生产环境运营商通常将目标锁定在 3.5GHz 以上的 24 核或更多核心，通常采用 AMD EPYC 9354 或 9355 部件。
• 指令集：主要的 fdctl 构建至少需要 AVX2 和 FMA 支持，而配备 AVX-512 的芯片则能解锁 Firedancer 在现代服务器上提供的最快批量签名验证路径。
• 内存：Firedancer 文档将 256GB 列为绝对最低要求，并建议使用 512GB ECC 内存，部分原因是该客户端会在巨型页面（huge pages）中预分配所有内存。
• 存储：具备高耐久性的企业级 NVMe Gen4 或 Gen5 驱动器是标准配置，理想情况下，ledger、账户和操作系统应分散在不同的物理磁盘上。
• 网络：内核绕过（kernel-bypass）网络依赖于 AF_XDP，它在支持零拷贝模式的网络驱动程序（例如高带宽低延迟链路上的 mlx5、i40e 或 ice）上运行效果最好。
• 核心调优：每个 tile 都需要一个专用的物理核心，因此运营商会禁用超线程竞争，将核心从内核调度程序中隔离出来，并设置亲和性以确保没有其他进程干扰。
• 运营预算：FCAT 估计运行一个 Solana 验证者的成本大约为每年 60,000 美元或更多，在通胀和 MEV 奖励享有 5% 佣金的情况下，其盈亏平衡点接近 200,000 个委派的 SOL。

Firedancer 对 SOL staker 意味着什么

对于大多数 SOL 持有者而言，Firedancer 是不可见的：无论验证者运行哪个客户端，钱包、费用和奖励的运作方式都完全相同。不过，在选择委托对象时，它依然至关重要，尤其是在 Alpenglow 切换前后。

本季度参与 staking 的用户应牢记以下实用要点：

• 检查客户端：向您的验证者或staking 平台询问其运行的是哪个客户端，并确认在 10 号 epoch 于 10 月 21 日开始之前，已迁移至基于 Agave 4.3 的构建版本。
• 错过 epoch：跳过此次切换或未对其投票账户投入足够资金的验证者，将在下一个 epoch 无法投票或出块，而委托者也将失去该 epoch 的收益。
• VAT 费用：Alpenglow 用固定 0.8 SOL 的Validator Admission Ticket替代了每个 epoch 大约 1 SOL 的投票费用，该费用将从每个验证者的投票账户中销毁。
• 分散委托：一旦 Firedancer 支持 Alpenglow，将代币委托给独立客户端验证者将直接增强网络的韧性，因为 stake 权重决定了每个客户端在整个网络中所控制的共识权力大小。
• yield 影响：客户端的选择会影响收入：Figment 发现 Firedancer 每个区块打包的更有价值的交易更多，而 FCAT 则显示 Harmonic 验证者每个 compute unit 获得的 priority fee 是普通 Agave 的两倍。
• 流动性质押：流动性质押代币将存款分散到众多验证者中，因此由矿池运营方而非持有者来管理客户端暴露风险以及像 Alpenglow 这类升级过程中的迁移风险。
• 报告的 TPS：投票交易在激活时会离开区块，因此仪表板将显示显著较低的交易计数；这反映的是会计口径的变化，而非 Solana 上用户活跃度的下降。

为什么 Jump 正在构建 Firedancer？

Jump 的动机可以追溯到其核心业务。Jump Trading 花费了二十年时间构建能够以微秒级延迟传输巨量数据的系统，而 Firedancer 将这种严谨性应用到了区块链节点中。首席科学家 Kevin Bowers 领导了早期的吞吐量演示，首次让 100 万 TPS 的数字在业界流传。

其中也存在商业逻辑。Jump 是加密货币市场中活跃的交易公司，并公开撰文探讨了 Solana 的市场结构，例如专有 AMM，这些结构依赖于快速且可预测的出块速度。一个更稳健的网络能够改善包括 Jump 在内的每位交易员最终所依赖的交易场所。

Jump 为此也承受了实际成本：三年的开发、100 万美元的公开审计竞赛，以及现在双倍奖励的内部漏洞赏金平台。只有在升级后运营方足够信任该客户端并将 stake 迁移回来，这笔支出才能得到回报。

风险与未解之问

Firedancer 是一项重大的工程成就，但它在 2026 年 10 月的地位比头条新闻中的 stake 数据所暗示的要脆弱得多。以下是未来几个季度值得追踪的问题。

当前围绕 Firedancer 的主要风险和未解问题：

• Alpenglow 缺口：Firedancer 将缺席 10 月 21 日的迁移，因此在支持 Votor 的版本到达主网之前，Solana 的客户端多样性将暂时回退至单一代码库。
• Stake 回归：切换到 Agave 的运营方可能更愿意留在原地，一旦迁移成本支付了两次，重新赢得大约 15% 的 stake 并非易事。
• 基准差距：100 万 TPS 的数字来自受控演示，而根据 Solana Compass 的数据，2026 年 10 月初 Solana 的实时用户吞吐量平均约为每秒 1,780 笔交易。
• 分歧风险：两个客户端可能会对区块的结果产生分歧；Jump 的竞赛发现了一个高严重级别的重放排序漏洞，该漏洞本可能导致 Firedancer 与其他客户端分叉。
• AI 分诊负载：AI 生成的漏洞报告正涌入安全项目，Jump 的积压报告峰值达到了 299 份，这表明评估发现结果的成本现在已经超过了发现它们的成本。
• 中心化压力：高要求的硬件、大约 20,000 SOL 的盈亏平衡点以及法兰克福和阿姆斯特丹占 40% 的 stake，这些都对大型专业运营方更为有利，而对小型独立验证者不利。
• 无直接敞口：没有 Firedancer 代币；任何投资角度都通过 SOL 进行，该代币在 2026 年 10 月中旬交易价格接近 103 美元，且无论升级与否都保持高度波动。

常见问题解答

Firedancer 是开源的吗？

是的。Firedancer 的源代码在 GitHub 上公开，因此节点运营商、审计员和研究人员可以构建、测试和审查它。这种开放性为 Jump 的公开漏洞赏金计划提供了基础，该计划向发现代码漏洞的外部研究人员支付奖励。

可以在云服务器上运行 Firedancer 吗？

技术上可以，但大多数运营商会避免这样做。Firedancer 的内核旁路网络依赖于特定的网络驱动程序和专用的物理核心，而虚拟机很少能干净利落地暴露出这些核心，因此生产环境验证者绝大多数都在专业数据中心使用物理服务器。

Firedancer 会降低 Solana 交易费吗？

不会直接降低。费用由 Solana 的协议规则以及每个客户端都遵循的区块空间需求决定。不过，更高效的区块打包和更强大的垃圾信息过滤可以缓解拥堵；请参阅我们的Solana gas 费指南以及修复失败的 Solana 交易指南。

什么是 FireBAM？

FireBAM 是 Jito 区块构建市场（Block Assembly Marketplace）的 Firedancer 版本，它改变了区块的构建和排序方式。截至 2026 年 10 月中旬，它持有约 1.6% 的 stake，并且Jito 曾告知运营商在 Alpenglow 过渡期间不要运行 FireBAM。

最后总结

Firedancer 已经改变了对 Solana 的评判标准。多年来，该网络在宣传原始速度的同时，却依赖于曾导致频繁宕机的单一软件血脉。一个真正独立的客户端在主网上线十个月后获得了约 15% 的 stake，正是批评者们一直要求的结构性解决方案。

Alpenglow 迁移让情况变得更加复杂。在一段时间内，Solana 将在共识层实现更高的速度与容错能力，而客户端层的多样性则会有所降低。Jump 交付并加固 Votor 支持的速度，将决定这种低迷期是持续数周还是延续到 2027 年。

对于质押者和开发者而言，实际的经验教训是关注 stake 分布，而不是吞吐量的头条新闻。100 万 TPS 的演示将会继续流传，但最关键的数字是多少 SOL 运行在能够独立失效的代码上。从这个标准来看，Firedancer 仍然是 Solana 最重要的升级。

以上就是脚本之家小编给大家分享的Firedancer是什么？如何运行？有何影响？希望大家喜欢！

Tag：Firedancer