Firedancer验证器推出，为Solana大规模采用铺路

本文来自： 《What is Firedancer? A Deep Dive into Solana 2.0 》

原文作者： 0xIchigo

Odaily星球日报译者：夫如何

 

众所周知，Solana 作为目前公链中高性能的代表之一，其较快的链上处理速度受到众多项目方的追捧，也吸引了像 Visa 等传统巨头的青睐。但 Solana 一直存在着网络宕机的隐患，网络宕机问题该怎么解决，Jump 将推出的 Firedancer 验证其客户端或能给出答案。

本文将从验证器以及验证器客户端对区块链的作用入手，探究 Firedancer 验证器客户端如何加持 Solana 网络。

以下由Odaily星球日报编译。

验证器以及验证器客户端多样性是什么？

验证器是参与权益证明区块链的计算机。验证器是 Solana 网络的支柱，负责处理交易并参与共识过程。验证器通过锁定一定数量的 Solana 原生代币作为抵押来保护网络的安全。质押代币可以将其视为一笔安全保证金，将验证器与网络进行经济联系。这种联系激励验证器准确高效地执行任务，因为他们会根据自己的贡献获得奖励。同时，对于恶意或故障行为，验证器也会受到处罚。验证器的权益会因为不当行为而被减少，这个过程称为减持。因此，验证器有充分的动力正确执行职责以增加自己的权益。

验证器客户端是验证器用来执行任务的应用程序。客户端是验证器的基础，通过其加密的唯一身份参与共识过程。

拥有多个不同的客户端可以提高容错能力。例如，如果没有任何一个客户端控制超过 33% 的份额，崩溃或影响活跃性的错误就不会使网络崩溃。同样，如果一个客户端存在错误导致无效的状态转换，只有少于 33% 的份额使用该客户端，网络就可以避免安全故障。这是因为大多数网络将保持在有效状态，防止区块链出现分裂或分叉。因此，验证器客户端的多样性能够提高网络的弹性，不会因为一个客户端的错误或漏洞对整个网络造成严重影响。

客户端多样性可以通过每个客户端运行的权益份额百分比和可用客户端的总数来衡量。在撰写本文时， Solana 网络上有 1979 个验证器。 这些验证器在主网上使用的两个客户端是由 Solana Labs 和 Jito Labs 提供的。Solana 在 2020 年 3 月推出时，使用的是由 Solana Labs 开发的一个验证器客户端。2022 年 8 月，Jito Labs 发布了第二个验证器客户端。该客户端是由 Jito 维护和部署的 Solana Labs 代码的分支。该客户端优化了区块中最大可提取价值（MEV）的提取。Jito 的客户端创建了一个伪内存池，因为 Solana 在没有内存池的情况下流式传输区块。值得注意的是，内存池是一组未确认和待处理交易的队列。伪内存池允许验证器搜索这些交易，将其优化地捆绑在一起，并提交给 Jito 的区块引擎。

截至 2023 年 10 月，Solana Labs 客户端持有活跃抵押的 68.55 ％，而 Jito 持有 31.45 ％。使用 Jito 客户端的验证器数量比 Solana 基金会先前的健康报告增长了 16 ％。 Jito 客户端使用率的增长显示出客户端多元化的演变趋势。

尽管这种增长的消息令人振奋，但它并非完美无缺。需要强调的是，Jito 的客户端是 Solana Labs 客户端的一个分支。这意味着 Jito 与原始验证器代码库共享许多组件，并且可能容易受到影响 Solana Labs 客户端的错误或漏洞的攻击。在理想的未来中，Solana 至少应该拥有四个独立的验证器客户端。不同的团队将使用不同的编程语言构建这些客户端。没有单一的实现会超过 33 ％的权益份额，因为每个客户端将持有约 25 ％的份额。这种理想化的设置将在整个验证器堆栈中消除单一故障点。

开发第二个独立的验证器客户端对于实现这种未来至关重要，Jump 致力于实现这一目标。

为什么 Jump 要构建一个新的验证器客户端？

Solana 的主网过去曾经四次出现宕机的情况，每次都需要数百个验证器进行手动修复。这种宕机情况凸显了对 Solana 网络可靠性的担忧。 Jump 认为协议本身是可靠的，而将停机时间归因于影响共识的软件模块问题。 因此，Jump 正在开发一个新的验证器客户端来解决这些问题。这个客户端的总体目标是提高 Solana 网络的稳定性和效率。

开发一个独立的验证器客户端是一项艰巨的任务。然而，这并不是 Jump 第一次构建可靠的全球网络。过去，证券交易（即股票买卖）是由市场专家手动执行的。随着电子交易平台的出现，证券交易变得更加开放。这种开放性增加了竞争，自动化，并减少了投资者进行交易的时间和成本。市场专家之间开始了技术上的竞争。

交易者以交易为生。更好的交易体验需要在软件、硬件和网络解决方案上更加注重。 这些系统必须具有高机器智能、低实时延迟、高吞吐量、高适应性、高可扩展性、高可靠性和高追责能力。

通用解决方案（即公司可以直接购买的软件）并不是竞争优势。以次于第二名的方式将正确的订单发送到交易所是一种昂贵的赔钱方式。在高频交易领域的激烈竞争导致了一个永无止境的开发循环，建立了一流的全球交易基础设施。

这种情景可能听起来很熟悉。成功的交易系统的要求与成功的区块链相似。区块链需要是性能优越、容错性强、延迟低的网络。一条慢速的区块链是一种失败的技术，无法满足现代企业应用的需求，只会阻碍创新、可扩展性和真实世界的实用性。凭借二十多年的全球网络扩展和高性能系统开发经验，Jump 是创建独立验证器客户端的完美团队。Jump Trading 首席科学官 Kevin Bowers 负责全程监督构建过程。

光速为何太慢？

凯文·鲍尔斯（Kevin Bowers）详细阐述了光速过慢的问题。光速是一个有限的常数，它对单个晶体管可以处理的计算数量提供了自然限制。目前，比特通过电子在晶体管中传输来进行建模。香农容量定理（即可以在信道上发送的无误数据的最大量）限制了通过晶体管传输的比特数量。由于基本物理和信息理论的限制，计算速度受到电子在物质中移动的速度和可以发送的数据量的限制。当将超级计算机推向极限时，这些约束变得明显。因此，“计算机在处理数据方面的能力与传输数据的能力之间存在显著的不匹配”。

以 Intel Core i 9 13900 K CPU 为例。它拥有 24 个 x 86 核心，基础时钟频率为 2.2 GHz，最高睿频时钟频率为 5.8 GHz。最坏的情况是光线需要在 CPU 内总共传播约 52.0 毫米的距离。CPU 的曼哈顿距离（即沿直角轴测量的两点之间的距离）约为 73.6 毫米。在 CPU 的最高睿频时钟频率 5.8 GHz 下，光线可以在空气中传输约 51.7 毫米。这意味着在单个时钟周期内，信号几乎可以在 CPU 的任意两点之间完成一次往返。

然而，实际情况要糟糕得多。这些测量使用的是光在空气中的传播速度，而信号实际上通过二氧化硅（SiO 2）传输。在 5.8 GHz 的时钟周期内，光在二氧化硅中可以传播约 26.2 毫米。而在硅（Si）中，光在 5.8 GHz 的时钟周期内只能传播约 15.0 毫米，略高于 CPU 的长边的一半。

Firedancer 团队认为，近年来计算技术的发展更多地是关于将更多核心集成到 CPU 中，而不是提高它们的速度。当人们需要更高的性能时，他们被鼓励购买更多硬件。在吞吐量是瓶颈的情况下，这在目前是有效的。而实际上的瓶颈是光速。这种自然限制导致了决策的瘫痪。对于任何一种优化，系统中的许多组件都没有立即的回报，因为它们都没有进行良好的优化。未经优化的部分会随着时间的推移而恶化，因为它们可用的计算资源较少。那么，现在怎么办呢？

在高性能计算领域，一切最终都必须进行优化。结果是建立面向量化交易和量化研究的生产系统，以物理和信息理论的极限运行在全球范围内。这包括创建定制网络切换技术，以满足这些物理限制的无锁算法。Jump 既是一家科技公司，也是一家交易公司。在科幻和现实的最前沿，Jump 和 Solana 目前面临的问题有着惊人的相似之处，Jump 正在开发 Firedancer。

Firedancer 是什么

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 的构建系统遵循一组指导原则，以确保可靠性和一致性。它强调最小化外部依赖，并将构建过程中涉及的所有工具都视为依赖项。这包括将每个依赖项（包括编译器）固定到确切的版本。该系统的一个关键方面是在构建步骤期间进行环境隔离。环境隔离增强了可移植性，因为构建过程不受系统环境的影响。

为什么 Firedancer 的速度更快

先进的数据并行性

Firedancer 在加密任务（如 ED 25519 签名验证）中采用了现代处理器内部可用的先进数据并行性。现代 CPU 具有用于同时处理多个数据元素的单指令多数据（SIMD）指令，以及优化以每个 CPU 周期运行多个指令的能力。将单个指令并行地作用于数据元素的数组或向量通常在面积、时间和功耗上更为高效。在这方面，与纯粹的处理速度提升相比，并行数据处理的改进可以主导吞吐量的提升。

Firedancer 使用数据并行性的一个领域是优化计算签名验证。这种方法允许同时处理数组或向量中的数据元素，以最大化吞吐量并最小化延迟。ED 25519 实现的核心是伽罗瓦域运算。这种形式的运算非常适合密码算法和二进制计算。在伽罗瓦域中，加法、减法、乘法和除法等运算是根据计算机系统的二进制特性进行定义的。下面是一个由 2 ^ 3 定义的伽罗瓦域的例子：

唯一的问题是 ED 25519 使用由 2 ^（255-19）定义的伽罗瓦域。可以将域元素视为从 0 到 2 ^（255-19）的数字。基本运算如下：

加法、减法和乘法几乎是 uint 256 _t 数学（即使用无符号整数进行计算，其中最大值为 2 ^( 256-1)。除法计算是具有挑战性的。普通的 CPU 和 GPU 不支持 uint 256 _t 数学，更不用说“几乎 uint 256 _t 数学”，更不用说异常困难的除法了。实现这种数学并使其高性能是一个关键问题，取决于我们能够如何模拟这种数学运算。

Firedancer 的实现通过更灵活地处理数字来分解算术运算。如果我们应用普通长除法和乘法的原则，将数字从一列进位到下一列，我们可以并行处理这些列。最快模拟这种数学运算的方法是将 uint 256 _t 表示为六个 43 位数字，带有一个 9 位的“进位”。这样可以在 CPU 上进行现有的 64 位操作，同时为进位位提供足够的空间。这种数字排列减少了频繁进位传播的需求，并使 Firedancer 能够更有效地处理大数字。

该实现通过将算术计算重新组织为并行化列求和来利用数据并行性。并行处理列可以加速整体计算，因为它将原本可能成为顺序瓶颈的任务转化为可并行化的任务。Firedancer 还使用了矢量化指令集，如 AVX 512 和其 IFMA 扩展（AVX 512-IFMA）。这些指令集允许处理上述伽罗瓦域算术，从而提高速度和效率。

Firedancer 的 AVX 512 加速实现非常快速。在单个 2.3 GHz Icelake 服务器核心上，每个核心的时钟性能是其 2022 年 Breakpoint 演示的两倍以上。该实现具有 100% 的矢量通道利用率和大规模数据并行化。这是 Firedancer 团队的另一个出色演示，由于光速延迟，与一次只能处理一件事情相比，同时进行独立的并行任务要容易得多，即使使用了定制的硬件也是如此。

利用 FPGA 实现高速网络通信

CPU 每个核心每秒可以处理大约 30, 000 个签名验证。虽然它们是一种高能效的选择，但在大规模操作方面存在不足。这种限制源于它们的顺序处理方法。GPU 将这种处理能力提升到每个核心每秒约 1 百万个验证。然而，它们的功耗约为每个单位 300 W，并且由于批处理而具有固有的延迟。

FPGA 成为更好的选择。它们与 GPU 的吞吐量相匹配，但功耗显著降低，每个 FPGA 约为 50 W。其延迟也低于 GPU 的十毫秒延迟。FPGA 以大约 200 微秒的延迟提供了更响应的实时处理解决方案。与 GPU 的批处理不同，Firedancer 中的 FPGA 以流式处理的方式单独处理每个交易。Firedancer 使用 FPGA 的结果是，在功耗低于 400 W 的情况下， 8 个 FPGA 每秒可以处理 800 万个签名。

团队在 Breakpoint 2022 展示了 Firedancer 的 ED 25519 签名验证过程。该过程涉及多个阶段，包括在纯 RTL 流水线中进行 SHA-512 计算，并在自定义 ECC-CPU 处理器流水线中进行各种检查和计算。基本上，Firedancer 团队为他们的自定义处理器编写了一个编译器和汇编器，从 RFC（请求评论）中获取了 Python 代码，使用运算符重载的对象来生成机器代码，然后将机器代码放在 ECC-CPU 之上。

值得注意的是，Firedancer 采用了 AWS 加速器的形式因子样式，以在鲁棒性和网络连接性之间取得平衡。此选择解决了与直接网络连接相关的挑战，而这个特性在云提供商中通常受到限制。通过这种选择，Firedancer 确保在云基础设施的限制下，其先进能力能够无缝集成。

我们必须认识到，不同的操作需要有实际的物理空间，而不仅仅是概念上的数据空间。Firedancer 通过战略性地安排物理组件的位置，使其紧密且可重复使用。这种配置使 Firedancer 能够最大化其 FPGA 的效率，在 8 年前的机器上使用 7 年前的 FPGA 实现每秒 800 万个交易。

网络通信中的基本挑战是在全球范围内广播新交易

互联网的点对点性质、有限的带宽和延迟问题限制了实现使用网络进行直接广播等传统方法的可行性。将数据以环形或树形结构分布部分解决了这些问题，但在传输过程中数据包可能会丢失。

Reed-Solomon 编码是解决这些问题的优选方案。它引入了数据传输冗余（即奇偶校验信息）以恢复丢失的数据包。其基本概念是，两个点可以定义一条直线，并且在这条直线上的任意两个点可以重建原始数据点。通过基于数据点构建多项式，并将该函数的不同点分布在单独的数据包中，只要接收方至少收到两个数据包，就可以重构原始数据。

我们构建多项式是因为使用传统的直线上的点的公式（y = mx + b）在计算上比较慢。Firedancer 使用拉格朗日多项式（一种专门用于多项式构建的方法）来加快速度。它简化了 Reed-Solomon 编码所需的多项式创建过程。它还将该过程转化为了一种更高效的矩阵-向量乘法，适用于更高阶的多项式。这个矩阵具有高度结构化的特点，其模式以递归方式重复出现，使得这个模式的第一行能够完全确定它。这种结构意味着有一种更快的方法来进行乘法计算。Firedancer 使用了一种 O(n log n)的方法，它在 2016 年的一篇文章中介绍了如何使用这个矩阵进行乘法运算，这是目前已知的 Reed-Solomon 编码的最快理论方法。其结果是与传统方法相比，以高效的方式计算奇偶校验信息：

• 每个核心的 RS 编码速度超过 120 Gbps；

• 每个核心的 RS 解码速度高达 50 Gbps；

• 这些指标均与当前约 8 Gbps/核心 RS 编码 (rust-rse) 进行比较。

使用这种优化的 Reed-Solomon 编码方法，Firedancer 可以比传统方法快 14 倍地计算奇偶校验信息。这使得数据编码和解码过程快速可靠，对于在全球范围内保持高吞吐量和低延迟至关重要。

Firedancer 如何保证安全？

机会

所有的验证者目前都使用基于原始验证者客户端的软件。如果 Firedancer 与 Solana Labs 的客户端不同，那么 Firedancer 可以改进 Solana 的客户端和供应链多样性。这包括使用类似的依赖和使用 Rust 来开发他们的客户端。

Solana Labs 和 Jito 验证者客户端作为一个单独的进程运行。一旦在生产环境中运行，为单体应用程序添加安全性是困难的。运行这些客户端的验证者将不得不关闭以进行纯 Rust 的即时安全升级。Firedancer 团队可以从一开始就构建安全架构来开发他们的新客户端。

Firedancer 还具有从过往经验中学习的优势。Solana Labs 在创业环境中开发了验证者客户端。这个快节奏的环境意味着 Labs 需要快速行动，以便快速进入市场。这使得他们未来的开发前景堪忧。Firedancer 团队可以看看 Labs 做了什么，以及其他链上的团队做了什么，并询问如果他们可以从头开始开发验证者客户端，他们会做什么不同。

挑战

尽管与 Solana Labs 的客户端有所不同，但 Firedancer 必须密切复制其行为。如果未能做到这一点，可能会引入一致性错误，从而成为安全风险。可以通过激励一部分份额在两个客户端上运行来缓解这个问题，将 Firedancer 的总份额保持在总份额的 33% 以下的时间较长。无论如何，Firedancer 团队都需要实现协议的完整功能集，无论其实现的难度或安全性如何。一切都必须与 Firedancer 保持一致。因此，团队不能孤立地开发代码，必须根据 Labs 客户端的功能对其进行审查。由于缺乏规范和文档，这一情况变得更加严重，这意味着 Firedancer 必须引入协议中的低效构造。

Firedancer 团队还必须意识到他们正在使用 C 语言开发他们的新客户端。C 语言没有像 Rust 等语言那样本地提供内存安全性保证。Firedancer 代码库的主要目标是减少内存安全性漏洞的发生和影响。需要特别关注此目标，因为 Firedancer 是一个快节奏的项目。Firedancer 必须找到一种在不引入此类错误的情况下保持开发速度的方法。操作系统沙箱是将 Tile 与操作系统隔离的实践。Tile 只被允许访问其工作所需的资源和执行系统调用。由于 Tile 具有明确定义的目的，并且 Firedancer 团队大部分开发了客户端代码，根据最小特权原则剥离了 Tile 的权限。

 

 

实施深度防御设计

所有软件在某个时刻都会存在安全漏洞。从软件将存在错误的前提出发，Firedancer 选择限制任何一个漏洞的潜在影响。这种方法被称为深度防御。深度防御是一种使用各种安全措施来保护资产的策略。如果攻击者侵入系统的一部分，存在额外的措施来阻止威胁影响整个系统。

Firedancer 的设计旨在减轻漏洞和利用阶段之间的风险。例如，攻击者很难利用内存安全漏洞。这是因为防止这类攻击是一个经过深入研究的问题。在 C 语言中，关于内存安全性的深入研究导致了一系列加固技术和编译器功能，团队在 Firedancer 中使用了这些技术。即使攻击者能够绕过行业最佳实践，也很难通过利用漏洞来破坏系统。这是由于 Tile 隔离和操作系统沙箱的存在。

Tile 隔离是 Firedancer 并行架构的结果。由于每个 Tile 都运行在自己的 Linux 进程中，它们都有明确的、单一的目的。例如，一个 QUIC Tile 负责处理传入的 QUIC 流量，并将封装的交易转发到验证 Tile。然后，验证 Tile 负责进行签名验证。QUIC Tile 和验证 Tile 之间的通信是通过共享内存接口完成的（即 Linux 进程可以在彼此之间传递数据）。两个 Tile 之间的共享内存接口充当着隔离边界。如果 QUIC Tile 存在一个 bug，允许攻击者在处理恶意的 QUIC 数据包时执行任意代码，它不会影响其他 Tile。在一个单体进程中，这将导致立即被攻陷。如果攻击者利用这个漏洞对多个验证者进行攻击，他们可能会对整个网络造成伤害。攻击者可能会降低 QUIC Tile 的性能，但 Firedancer 的设计将其限制在了 QUIC Tile 上。

操作系统沙箱是将 Tile 与操作系统隔离的实践。Tile 只被允许访问其工作所需的资源和执行系统调用。由于 Tile 具有明确定义的目的，并且几乎所有的代码都是由 Firedancer 团队开发的，根据最小特权原则，Tile 的权限被剥减至最低限度。Tile 被放置在自己的 Linux 命名空间中，提供了对系统的有限视图。这种狭窄的视图防止了 Tile 访问大部分文件系统、网络和同一系统上运行的任何其他进程。命名空间提供了一个以安全为先的边界。然而，如果攻击者具有提升权限的内核漏洞，仍然可以绕过这种隔离。系统调用接口是内核中从 Tile 可达的最后一个攻击向量。为了防止这种情况，Firedancer 使用 seccomp-BPF 在内核处理系统调用之前过滤它们。客户端可以将 Tile 限制在一组选择的系统调用中。在某些情况下，可以过滤系统调用的参数。这一点很重要，因为 Firedancer 可以确保 read 和 write 系统调用只对特定的文件描述符操作。

采用嵌入式安全计划

在 Firedancer 的开发过程中，注重在每个阶段嵌入全面的安全程序。客户端的安全程序是开发团队和安全团队之间持续合作的结果，为安全的区块链技术树立了新的标准。

该过程始于自助模糊测试基础设施。模糊测试是一种自动检测崩溃或指示漏洞的错误条件的技术。通过对接受不可信用户输入的每个组件进行压力测试，包括P2P接口（解析器）和 SBPF 虚拟机，来进行模糊测试。在代码更改期间，OSS-Fuzz 保持持续的模糊覆盖率。安全团队还建立了一个专用的 ClusterFuzzer 实例，用于持续的覆盖引导模糊测试。开发人员和安全工程师还提供模糊测试的工具（即针对安全关键组件的特殊版本的单元测试）。开发人员还可以贡献新的模糊测试，这些测试会被自动接收和测试。目标是在进入下一个阶段之前对所有部分进行充分的模糊测试。

内部代码审查有助于发现工具可能忽略的漏洞。在这个阶段，重点放在高风险、高影响的组件上。这个阶段是一个反馈机制，为安全程序的其他部分提供反馈。团队将所有的经验教训应用在这些审查中，用于提高模糊测试的覆盖率，为特定的漏洞类别引入新的静态分析检查，甚至实施大规模的代码重构，以排除复杂的攻击向量。外部安全审查将由行业领先的专家和活跃的漏洞赏金计划进行补充，包括在发布前和发布后。

Firedancer 还经历了在各种测试网络上的广泛压力测试。这些测试网络将面临各种攻击和故障，如节点复制、网络链接失败、数据包洪泛和共识违规。这些网络承受的负载远远超过主网上任何实际情况。

所以，这就引出了一个问题：Firedancer 目前的状态如何？

Firedancer 的现状如何，Frankendancer 又是什么？

Firedancer 团队正在逐步开发 Firedancer，以模块化验证器客户端。这与他们对文档和标准化的目标一致。这种方法确保 Firedancer 与 Solana 的最新发展保持同步。这导致了 Frankendancer 的创建。Frankendancer 是一种混合客户端模型，Firedancer 团队将其开发的组件集成到现有的验证器客户端基础架构中。这种开发过程允许逐步改进和测试新功能。

Frankendancer 就像将一辆跑车置于交通中心。随着更多组件的开发和瓶颈的消除，性能将不断提升。这种模块化开发过程促进了可定制和灵活的验证器环境。在这里，开发人员可以根据自己的需求修改或替换验证器客户端中的特定组件。

实际运行的是什么

Frankendancer 实现了 Solana 验证器的所有网络功能：

• 入站：QUIC、TPU、Sigverify、Dedup

• 出站：块打包、创建/签名/发送 Shreds（Turbine）

Frankendancer 在 Solana Labs 的 Rust 运行时和共识代码之上使用了 Firedancer 高性能的 C 网络代码。

Frankendancer 的架构设计注重高端硬件优化。虽然它支持运行标准 Linux 操作系统的低端云主机，但 Firedancer 团队正在为高核心数服务器优化 Frankendancer。长期目标是利用云中已有的硬件资源来提高效率和性能。该客户端同时支持多个连接、硬件加速、用于负载分布的随机化流量导向（确保网络流量均匀分布）以及为各个组件之间提供额外安全性的多个进程边界。

技术效率是 Frankendancer 的基石。该系统避免在关键路径上进行内存分配和原子操作，所有分配在初始化时都经过 NUMA 优化。这种设计确保了最大的效率和性能。此外，异步和远程检查系统组件的能力，以及对 Tile 的灵活管理（异步启动、停止和重启），为系统增加了一层稳健性和适应性。

Frankendancer 的表现如何？

Frankendancer 每个 Tile 在网络入站端可以处理每秒 1, 000, 000 个交易（TPS）。由于每个 Tile 使用一个 CPU 核心，因此该性能与使用的核心数成线性比例。Frankendancer 通过仅使用四个核心，并充分利用每个核心上的 25 Gbps 网络接口卡（NIC）来实现了这一成就。

在网络出站操作方面，Frankendancer 通过其 Turbine 优化取得了显著的改进。目前的标准节点硬件每个 Tile 实现了 6 Gbps 的速度。这包括了在分片（即如何将块数据分割并发送到验证者的网络中）方面的大幅速度提升。与当前的标准 Solana 节点相比，Frankendancer 在没有 Merkle 树的情况下显示出了约 22% 的分片速度提升，而在使用 Merkle 树时几乎翻了一番。这对于当前验证者的块传播和交易接收性能来说是巨大的改进。

Firedancer 的网络性能表明它已达到硬件极限，实现了与当今标准验证器硬件相比的最大性能。这标志着一个重要的技术里程碑，展示了客户端有效高效地处理极端工作负载的能力。

Frankendancer 已上线测试网

Frankendancer 目前正在测试网络上进行质押、投票和出块。它与 Solana Labs 和 Jito 约 2900 个其他验证者兼容共存。这个实际部署展示了 Firedancer 在普通硬件上的强大性能。目前，它部署在一台 Equinix Metal m 3.large.x 86 服务器上，配备 AMD EPYC 7513 CPU。许多其他验证者也使用相同类型的服务器。它提供了一种经济实惠的解决方案，按需定价根据地点不同而有所变化，费率在每小时 3.10 美元至 4.65 美元之间。

Firedancer 朝着主网上线取得的进展为节点硬件带来了几个可能性：

• 当前验证器硬件可以实现更高的每个节点性能容量；

• Firedancer 的高效性使验证者可以使用更经济实惠、规格较低的硬件，同时保持类似的性能水平；

• Firedancer 的设计使其能够利用硬件和带宽的进步。

这些发展，以及其他一些倡议，如 Wiredancer（即 Firedancer 团队对硬件加速的实验）和基于 Rust 的模块化运行时/SVM，使 Firedancer 成为一种具有前瞻性的解决方案。

Firedancer 的进展也引发了关于是否让验证者在 Firedancer 旁边运行 Solana Labs 客户端的讨论，这被称为并行运行。这种方法可以通过充分利用两个客户端的优势，并减轻任一客户端在整个网络中的潜在影响，从而最大程度地提高网络的活跃性。此外，这也引发了关于像 Jito 这样的项目是否会考虑分叉 Firedancer 的推测。这可能会进一步优化 MEV 提取和交易处理效率。只有时间能告诉我们。

结论

开发人员通常将操作视为占据数据空间而不是物理空间。在光速作为自然限制的情况下，这种假设会导致系统变慢，无法正确优化其硬件。在一个高度对抗性和竞争性的环境中，我们不能简单地将更多的硬件投入到 Solana 中，并期望它表现更好。我们需要进行优化。Firedancer 革新了验证者客户端的结构和操作方式。通过构建一个可靠、高度模块化和高性能的验证者客户端，Firedancer 团队正在为 Solana 的大规模采用做准备。

无论您是初级开发人员还是普通的 Solana 用户，了解 Firedancer 及其意义是至关重要的。这一技术壮举使目前市场上最快、最高性能的区块链变得更加出色。Solana 旨在成为一个高吞吐量、低延迟的全球状态机。Firedancer 是朝着完善这些目标迈出的巨大一步。