Firedancer 是由 Firedancer 团队使用 C 语言开发的全新独立验证器客户端。Firedancer 的设计考虑了可靠性，采用模块化架构、最小的依赖性和广泛的测试流程。它提出了对 Solana Labs 客户端的三个功能组件（网络、运行时和共识）进行重大改写。每个级别都经过了最大性能的优化，因此客户端的运行能力只受验证器硬件的限制，而不会受到当前面临的软件效率不足导致的性能限制。通过 Firedancer，Solana 将能够根据带宽和硬件进行扩展。
Firedancer 的目标是：
记录和规范化 Solana 协议（最终，人们应该能够通过查看文档而不是 Rust 验证器代码来创建一个 Solana 验证器）；
提高验证器客户端的多样性；
提高生态系统的性能。
Firedancer 的工作原理
模块化架构
Firedancer 通过其独特的模块化架构与当前的 Solana 验证器客户端有所区别。与 Solana Labs 的 Rust 验证器客户端作为单个进程运行不同，Firedancer 由许多称为“tiles”的独立 Linux C 进程组成。一个 tile 是一个进程和一些内存。这种 tile 架构是 Firedancer 运行理念和提高鲁棒性和效率的方法的基础。
进程是运行中程序的实例。它是现代操作系统的基本组件，代表一组指令的执行。每个进程都有自己的内存空间和资源，操作系统独立地分配和管理这些资源，不受其他进程的影响。进程就像是一个大工厂里独立的工人，使用自己的工具和工作空间处理特定的任务。
在 Firedancer 中，每个 tile 都是一个具有特定角色的独立进程。例如，QUIC tile 负责处理传入的 QUIC 流量，并将封装的交易转发到 verify tile。verify tile 负责签名验证，其他 tile 也有类似的任务。这些 tile 独立且并发地运行，共同构成了整个系统的功能。独立的 Linux 进程可以形成小的、独立的故障域。这意味着一个 tile 的问题只会对整个系统产生最小的影响，或者说只会有很小的“影响范围”，而不会立即危及整个验证器。
Firedancer 架构的一个关键优势是能够在几秒钟内替换和升级每个 tile，且无需任何停机时间。这与 Solana Labs 的 Rust 验证器客户端在升级之前需要完全关闭的要求形成鲜明对比。这种差异源于 Rust 缺乏 ABI（应用程序二进制接口）的稳定性，这导致无法在纯 Rust 环境中进行即时升级。而采用 C 进程的方式，可以依靠 C 运行时模型中的二进制稳定性，显著减少与升级相关的停机时间。这是因为各个 tile 在不同的工作空间中管理验证器状态。只要验证器开机运行，这些共享内存对象就会持续存在。在重新启动或升级过程中，每个 tile 可以无缝地从离开的地方继续处理任务。
总体而言，Firedancer 是根据 NUMA 感知、基于 tile 的架构构建。在这个架构中，每个 tile 使用一个 CPU 核心。它具有高性能的 tile 之间的消息传递，优化了内存局部性、资源布局和组件延迟。
网络处理
Firedancer 的网络处理旨在处理 Solana 网络在升级到每秒千兆比特速度时的高强度需求。这个过程分为入站和出站活动。
入站活动主要涉及接收用户的交易。Firedancer 的性能非常重要，因为如果验证器在处理数据包时落后，共识消息可能会丢失。目前 Solana 节点的操作带宽约为 0.2 Gbps，而 Jump 节点记录的最大带宽峰值约为 40 GBps。这种带宽峰值突显了一个强大而可伸缩的入站处理解决方案的需求。
出站活动包括区块打包、区块创建和发送碎片。这些步骤对 Solana 网络的安全高效运行至关重要。这些任务的性能不仅影响吞吐量，还影响网络的整体可靠性。
Firedancer 旨在解决 Solana 以往在处理交易的点对点接口方面存在的问题。过去 Solana 点对点接口的一个重大缺点是其在处理入站交易时缺乏拥塞控制。这个缺点导致了 2021 年 9 月 14 日（17 小时）和 2022 年 4 月 30 日（7 小时）的宕机 。
作为回应，Solana 进行了几次网络升级，以正确处理高交易负载。Firedancer 紧随其后，采用 QUIC 作为其流量控制方案。 QUIC 是一种多路复用的传输网络协议，是 HTTP/3 的基础。 它在抵御 DDoS 攻击和管理网络流量方面起着重要作用。然而，需要注意的是，在某些情况下，成本超过了收益。QUIC 结合数据中心专用硬件用于缓解 DDoS 攻击，消除了对交易洪水攻击的动机。
QUIC 的 151 页规范给开发带来了相当大的复杂性。由于无法找到符合他们许可、性能和可靠性需求的现有 C 库，Firedancer 团队自行构建了自己的实现。Firedancer 的 QUIC 实现，被昵称为 fd_quic，引入了优化的数据结构和算法，以确保最小的内存分配和防止内存耗尽。
Firedancer 的自定义网络堆栈是其处理能力的核心。该堆栈从零开始设计，以利用接收端扩展（RSS）。RSS 是一种硬件加速的网络负载均衡形式，将网络流量分配到不同的 CPU 核心，以增加网络处理的并行性。每个 CPU 核心处理一部分传入流量，几乎没有额外开销。这种方法通过消除复杂的调度器、锁和原子操作，优于传统的基于软件的负载均衡。
Firedancer 引入了一种新的消息传递框架，用于组合高性能 tile 的应用程序。这些 tile 可以绕过受限于基于套接字的内核网络，通过使用 AF_XDP 来利用 AF_XDP，一种专为高性能数据包处理进行优化的地址族。使用 AF_XDP 使 Firedancer 能够直接从网络接口缓冲区读取数据。
这种 tile 系统在 Firedancer 堆栈中实现了各种高性能计算概念，包括：
NUMA 感知 – NUMA（非一致性存储访问）是一种计算机内存设计，其中处理器访问自己的内存比访问与其他处理器关联的内存更快。对于 Firedancer 来说，具备 NUMA 感知意味着客户端能够在多处理器配置中高效处理内存。这对于高交易量处理非常重要，因为它优化了可用硬件资源的利用。
缓存局部性 – 缓存局部性指的是利用已经存储在靠近处理器的缓存中的数据。这通常是一种时间局部性的变体（即最近访问的数据）。在 Firedancer 中，对缓存局部性的关注意味着它被设计成在最小化延迟和最大化速度的同时处理网络数据。
无锁并发 – 无锁并发指的是设计算法时不需要锁定机制（如互斥锁）来管理并发操作。对于 Firedancer 来说，无锁并发允许多个网络操作并行执行，而无需由于锁而导致延迟。无锁并发增强了 Firedancer 同时处理大量事务的能力。
大页面大小 – 在内存管理中使用大页面大小有助于处理数据集，减少页面表查找和潜在的内存碎片化。对于 Firedancer 来说，这意味着改进了内存处理的效率。这对于处理大量网络数据非常有益。
构建系统
Firedancer 的构建系统遵循一组指导原则，以确保可靠性和一致性。它强调最小化外部依赖，并将构建过程中涉及的所有工具都视为依赖项。这包括将每个依赖项（包括编译器）固定到确切的版本。该系统的一个关键方面是在构建步骤期间进行环境隔离。环境隔离增强了可移植性，因为构建过程不受系统环境的影响。
