工程速度：与 Alessandro Decina 深入了解 Anza 性能团队

引言

毫无疑问，技术乐观主义是 Solana 的文化时代精神。对无限速度、进步与创新的坚定信念，贯穿每一个部署到主网的 pull request。它的口号是 IBRL：增加带宽，降低延迟。这既是工程命令、文化暗语，也是一种世俗祈祷。如果说 Bitcoin 是一座供奉永恒的教堂，Ethereum 是一个追求中立的广场，那么 Solana 就是一条赛道：一个由可衡量的机械速度主宰的领域。

然而，这种速度从不会以注释整齐的 diff 从天而降。它由那些敢于整日凝视代码的人开采、打磨，并最终塑造成现实。很少有人比 Alessandro Decina 看得更久。他最初是一位 GStreamer 高手，把视频缓冲卡顿视为对自己的冒犯。如今，他领导着 Anza 的四人性能团队。在这个团队眼里，“自我关怀”就是凌晨 3 点删掉 validator trace 里的黄色条块。他们每天盯着火焰图、砍掉整套工作流，还会重写经过生产环境千锤百炼的代码——因为任何可以优化的东西，最终都会被优化。

我想了解以这种速度生活究竟意味着什么。于是，我与 Alessandro Decina 坐下来聊了聊，看看他如何继续让现有最快的区块链变得更快。下面这场访谈是对速度的一次解剖。我们从他开发多媒体流水线的经历，一直聊到让四名工程师的交付速度超过整个组织的文化护栏。

为使内容更清晰精练，本次对话经过编辑和删减。

访谈

起点与世界观

Ichigo：回顾一下过去，你最早钟爱的是 GStreamer 和多媒体流水线。那段时期带给你的最大延迟经验是什么？追求实时音视频的经历，对你在 Agave 上压缩毫秒级耗时有什么启发？

Decina：首先，你把我调查得很彻底，干得漂亮，哈哈。我开发 GStreamer 大概有 15 年，也许更久一点。我知道的一切，基本都是在那里学到的。我开始为这个项目贡献时，它还是开源项目，刚刚起步。我特别幸运，当时和创始人走得很近。那家伙大概比我大 15 岁，而且真的很厉害。他都有 Wikipedia 页面——那大概确实是个聪明人。不像我，我只是假装聪明。那家伙就这么决定了：“行吧，随便，我免费把知道的一切都教给你。”于是，我就开始做这方面的工作。

现在我们开发 Solana 时总在谈低延迟，这其实很有意思，因为这根本算不上低延迟。当你讨论音频处理、DPS 和多媒体硬件时，我们在 Solana 上做的事情延迟高得离谱。如果任何音频或视频的响应时间达到 400 毫秒，它基本就坏了，根本没法用。

后来，我开始接触 Linux 驱动，以及负责视频和音频编解码的硬件。我今天做的很多事情，本质上和当时做的一样。处理硬件时，延迟意味着某个地方存在队列。你要找到那个队列，尽量缩短它，让它越小越好，同时确保它永远不会欠载。

例如，我现在做的 XDP 工作就和音频环形缓冲区的工作方式非常相似。甚至我们此刻的通话也是如此：大量数据包以乱序方式抵达，某处有一个环形缓冲区负责重新排列所有数据包，而你肯定要确保它不会欠载。

感觉过去 20 年里，我一直在做同一件事。

也就是说，日子不同，做的还是那些事。我还注意到你也在 Spotify 工作过，也做过一点 Firefox——

啊，不是，Firefox 那部分只是为一次黑客松做的集成工作。哈哈，我老到什么程度呢？Firefox 最初那个使用 GStreamer 的 video 标签就是我写的。

厉害，哈哈。所以条条大路通向 GStreamer？

GStreamer 真正教会了我多线程编程。它也是我进入这个生态系统的原因。有些人写 Assembly，搞各种底层技巧。我会想，对啊，这些事我已经做了很久。而我学到的是：除非你使用一种具备强类型系统和优秀编译器的语言，否则最终只会搬起石头砸自己的脚。我相信，用 Assembly 也许能让某些东西快那么一点点，但我真的想用 Rust。

我希望 Rust 编译器告诉我：你是个白痴——这里有 bug，所以根本跑不通。在 Rust 之前，我觉得自己只有 10% 是软件工程师，另外 90% 是人肉调试器。我一直都在调试。因此，我认为 GStreamer 和我对 Rust 的热爱，正是我开始开发 Solana 的原因。当时 Rust 越来越流行，但能让你全职使用它的工作并不多，而我已经决定只用 Rust 工作。

我年纪太大，不想再写 C 了。我不想使用内存不安全的语言，也不想浪费时间。所以，没错，我现在就在这里。

很好。那么，在转型之前，你对去中心化系统有什么误解吗？开始开发 validator 代码后，是什么让你相信 Solana 的架构真的能够扩展？

实际上，我差不多晚了两年才加入 Solana，因为当时我正忙着开发 Rust 编译器。Solana 有个人刚开始开发虚拟机，他给我发了一封邮件，说：“哦，我在做同样的事，看起来你的进度更领先一些，来和我们一起做吧。”我没有回复，因为我研究了 Bitcoin，接着又研究了 Ethereum，发现虽然你可以执行一些东西，但只有 10 TPS。这算不上一个正经项目，对吧？10 TPS 根本做不了任何现实世界里的事情。

所以收到那封邮件时，我没有回复。我只觉得，好吧，这些加密货币圈的人还不够认真。

两年后，Toly 联系了我，我查了一下 SOL 的价格。当时我就想，好吧，我真该打开那封邮件，哈哈。这次我确实和他聊了聊。聊天前，他给我看了一些代码。看完以后，说实话，那些代码糟透了，真的是非常烂的 Rust 代码。

但后来，我没搜过 Toly 就直接和他聊了，所以完全不知道他是谁。他很聪明，说的每句话也都很对。他说，我们正在构建这个东西。目前我们是这么做的。显然，这还不算最先进，但我们的目标是随硬件扩展。我们要构建性能最强的区块链，直到硬件成为瓶颈。我们的想法是，投入的硬件越多，它的扩展能力就越强。

这说服了我。我觉得这不只是一群区块链疯子对着第三次世界大战自我陶醉……我感兴趣的是技术。我是少数真正为了技术而进入加密货币领域的人之一。

Solana 有一种深受技术乐观主义影响的工程文化，也就是那套增加带宽、降低延迟的理念。你个人如何看待它？它怎样影响 Anza 的日常工作？

在我看来，Ethereum 从根本上抱有一种稀缺心态。他们的想法是，好吧，我们撞上了一些墙，所以要寻找绕过这些墙的方法。我们要发明所有这些基础设施，去弥补本质上只是我们自身的知识空白，因为我们觉得这些问题绝不可能修复，对吧？

而我觉得我们恰恰相反。我们的想法是，好吧，这里有个问题。除了违反物理定律的问题，没有什么问题无法解决。这就是巨大的文化差异。

如果有什么东西坏了，我们只会说，好，坐下来吧。做点性能分析，看看问题出在哪里。和交易员、做市商谈一谈，看看他们遇到了什么问题。最近，我们找到了一些非常具体的问题，也已经修复了其中大部分。说真的，两三个月内，我们就能把它们全部解决。

Solana 目前有很多东西还不能正常工作。我们知道这些问题，但从来没有坐下来宣布：“我们有完美的解决方案！而要想更进一步，就必须发明新东西，或者做研究、另寻他法。”不是这样的——这些都是具体问题。其中大多数都是非常愚蠢的问题。

而且，我们最近没有发生过宕机。就我个人而言，我觉得这是利空，对吧？因为我觉得有些人已经开始变得有点保守了。我们知道自己可以快得多。我们知道明天就能实现 1 亿 CU 的区块，对吧？我们只需要快速推进一些事情。而我主张所有事情都快速推进。

我们从根本上知道——不需要路线图也知道，我们可以把当前性能提升 10 倍。我们看得见实现路径，也知道该怎么做。要么代码已经写好但尚未完全完成，要么代码已经写好，却因为仍有一些边缘情况需要修复而无法部署。但我们完全知道该做什么。

我们知道如何扩展这个东西。

性能工程

说到性能工作，我觉得很多人并不知道 Anza 有一支专门的性能团队。它似乎一直不太受关注。能介绍一下团队结构吗？它和 Anza 的其他工程团队有何不同？

没错，Anza 确实有不同的团队。目前有专注于 Alpenglow 的共识团队，有主要专注于 Gossip 的网络团队，还有基本只负责账户数据库工作的 AccountsDB 团队。区块生产团队负责调度器。当然，还有其他所有被我漏掉的团队。

性能团队的不同之处在于，我们什么都做。我们进行性能分析，找到瓶颈，然后询问相关团队是否有时间和专业能力来处理，因为有时我们发现的问题并不是每个人都能修复。例如，如果你负责共识，就不一定擅长底层编程，因为你的专长在别处。所以遇到这种情况时，我们通常会直接介入，替他们修复代码。

所以，我们不会只开发某一样东西。我们只寻找下一个瓶颈。我们大约每两周同步一次，确定当前进展、下一步要做什么，以及如何让下个版本更快。

另一大区别是，Anza 倾向于招聪明人。比如，你不懂 Rust，没关系；不懂底层编程，也没关系。我们认为，只要你足够聪明，大多数技能都可以在工作中教会你。对于性能团队，我通常会招聘真正具备内核或其他底层工作经验的人，因为我们目前遇到的正是这类瓶颈。

以账户数据库为例，我们需要修复一些算法问题。但*,* 2.3 版本的账户数据库之所以比两个月前快大约十倍，是因为我们修复了它执行 I/O 的方式。要让它更快，你必须了解底层机制。如果你只是从较高层面理解数据库，并不真正了解磁盘如何工作，也不需要知道内核如何调度 I/O 请求。

所以，就我个人而言，我更倾向于为性能团队招聘底层人才。还是那句话，我甚至不在乎他们是否懂 Rust，但我确实希望他们曾使用 C 或 C++ 开发过其他更底层的东西。

性能团队不太为人所知，是因为我们实际上 12 月才成立。我最初受聘负责编译器，但在 2024 年 3 月左右那次宕机时转去做性能，并开始优化各种东西。大家当时不太高兴，因为有一天我直接告诉他们，我想做什么就做什么。所以，没错，哈哈，他们并不开心，但后来我们的成果非常好。于是有人来问我：“好吧，其实你想不想再招些人来做这件事？”随后在 12 月，我们正式确立了性能工作，并组建了团队。

说实话，我有偏见，但性能团队毫无疑问就是 Anza 最好的团队。

我毫不怀疑，哈哈。团队有多少人？

我们有四名全职成员，但我一直在 Twitter 上开玩笑，说 Brooks 和其他一些人也加入了，因为我开始把自己的性能分析器分享给更多人。大概两个月前，只有性能团队能使用它。现在每个人都有。比如 Brooks，自从我把性能分析器给他以后，他做的性能工作比我还多，哈哈。他彻底上瘾了，现在一心只想让所有东西都变得更快。

所以，现在还有 Brooks 和另外几个人非正式地参与，也做了大量性能工作。但全职负责性能的有四个人。

那么在性能工作中，做性能分析时有哪些大多数工程师都会忽略的“异味”？你如何判断什么需要优化？

有些问题非常明显。比如我刚开始分析 Agave 时，我们花在内核里的时间远多于执行用户空间代码的时间，这非常荒谬。我们并不是底层应用。如果我们是多媒体框架，大部分工作都在内核中完成还算合理，因为最终你需要把采样数据发送到硬件。但我们唯一真正算得上底层的工作就是 Turbine。

所以，我开始做性能分析时，最大的异味通常是火焰图里出现大量黄色，因为这意味着我们在内核中耗费了太多时间。很可能是有人使用了某个看起来无害的高层 API，但它在底层的性能表现糟糕透顶。

过去一年，我们将 Agave 的内存使用量减少到了原来的约十分之一，因为通常遇到的都是同一个问题。当内存分配次数太多时，最终就需要开始与内核交互。你可以在性能分析器中看到这种交互。你会看到，好吧，这是从哪里来的？你发现这条调用链一直在反复折腾内存。一路追溯到频繁释放并分配过多内存的位置，然后把它修好。

也有一些更棘手的问题。例如，我们发现了一个根本性的设计问题，而我正在修复它。众所周知，Solana 采用流水线设计，包含不同阶段，而且按理说应该全部并行化，让各种工作并行运行。

实际上，由于架构方式的缘故，我们虽然采用了流水线设计，但流水线中存在太多停顿。我们的确有不同阶段，却没有最大限度发挥每个阶段的吞吐量，因为一些愚蠢的设计 bug 在多个环节引入了延迟。当人们无法发送交易，或声称系统存在抖动时，通常抱怨的就是这种延迟。这种抖动并非由任何根本因素或硬件造成，只是因为我们的实现不够理想。

但坦率地说，我们处理的都是些愚蠢问题。有些 bug 明显得不能再明显，而我们只是在修复这些显而易见的 bug。

你如何判断这些 bug 应该使用微基准测试，还是应该完整重放主网流量？

我认为，我们的大多数性能问题都源于有人编写了微基准测试。他们让微基准测试跑得更快，单独对其进行测试，但把一切整合进 Agave 后，没有任何东西能像微基准测试里那样运行。

所以我个人会告诉大家：任何事情都不要使用微基准测试。即使是重放交易——过去一年我大概也只做过三次。因为即使重放主网流量，速度也不会与真正执行主网流量时完全相同，所以很多条件都会发生变化。

这也是我们大幅加快启动速度的部分原因。否则，每次想确认修复是否有效都要等半个小时，实在令人烦躁。

当 Agave 发展到我们现在这个阶段时，你不能只为某个组件钻进无底洞。这类工作在智力层面或许很有趣，但如果不考虑整个系统，就毫无用处。它实际上推动不了任何进展。

那么，从整个系统来看，把 Turbine 重写为使用 XDP 为什么如此重要？

加入 Solana 前，我正在做网络相关的工作。当时我就职于一家从事深度数据包检测的初创公司。他们基本会拦截进入 NIC 的所有流量，实时分析并阻止恶意流，然后重新注入内核。我们实际上使用 Rust、Tokio，当然还有 XDP，在用户空间中编写了一整套 TCP 和 UDP 协议栈。

加入 Anza 时，很明显，我们迟早需要使用 XDP。Firedancer 刚开始时，他们说：“我们要从 Turbine 的 XDP 实现开始。”而我告诉他们，这很愚蠢，完全不合理。这样做需要更多时间，因为客观来说，XDP 是个糟糕透顶的 API。所以应该尽可能久地避免使用它，直到整个系统真的要散架。

然后你就会说，哦，[已隐去]，现在我不得不用 XDP 了，而这正是我们遇到的情况。我们一直在消除流水线中的其他所有瓶颈，直到开始负载测试的那天，发现 Turbine 彻底停止工作。

于是我们意识到，好吧，这显然已经不可行了。实际上，我真的非常、非常努力地避免使用 XDP，因为我以前用过，知道它有多糟糕。我尝试构建一个基于 io_uring 的 Turbine 实现，随后在 io_uring 中发现了一些 bug。我开始修复这些 bug。现在仍有一些内核补丁想要提交，但到了某个时刻，我意识到，好吧，我不能要求所有 validator 运营者都使用我的自定义内核来运行 Solana。

我只能使用 XDP，我们也确实用了。现在它可以正常工作。

答案是：找到下一个瓶颈，然后修复它。不断修复发现的所有瓶颈。明天的问题可以留到明天再考虑。这是我的座右铭。你当然可以只担心明天，但那样今天就会一团糟。Solana 的今天就很糟。区块太小，Turbine 引入的延迟太高，调度器仍然存在问题。我们必须在今天解决问题，否则就没有那个能跑得如此之快的明天。

你们如何防止性能回退？又如何与 Firedancer 协作？

性能回退很棘手。我个人每天都会对 Agave 中的某些东西进行性能分析，每天至少几次，而我们经常遇到性能回退，因为编写高性能代码本身就是一项专业工作。你需要知道如何编写高性能代码。如果写 Rust 代码，平均来说，它的性能会高于 Node.js、Python 或其他代码。但如果你负责 AccountsDB，要处理包含数百万条目的集合，就不能只是简单地写代码。要高效构建算法并处理大型数据集并不容易。

所以，我们偶尔确实会遇到性能回退。直到大约一个月前，我基本一直在冲所有人大喊大叫，哈哈。比如负责 AccountsDB 的 Brooks——我觉得他有一阵子很讨厌我。我们的关系很好，但直到一个月前，我们大约一半的交流都是我冲他喊，因为 AccountsDB 里有东西变慢了。

在协议方面，与 Firedancer 合作改善了这一点，因为我觉得协议的许多部分最终都是为应对不同挑战而自然生长出来的。协议开发始于一个想法；他们把它投入生产，而和大多数想法一样，第一次不会奏效。随后，他们开始在上面不断叠加东西。从性能角度看，许多后来叠加的东西都是非常糟糕的主意。

例如，Gossip 中曾有一种叫 epoch slots 的东西，集群基本会向所有人广播哪些 validator 看到了哪些 slot。就在六个月前，我随手分析其他东西时，注意到这个 epoch slots 在 CPU 上花费的时间竟然超过了实际执行交易的时间。而在带宽方面，它占用的带宽是 Turbine 的四倍。这只是在某个时间点为了缓解某个问题，临时叠加到协议上的随机补丁。

现在已经不会再发生这种事了。这部分要归功于 Firedancer。现在有人提出方案时，我们必须与 Firedancer 合作。他们显然在开发另一个客户端，哈哈，所以必须为这项工作安排资源。他们需要判断实现这个方案要花多长时间，它的优先级是什么。于是，无论是好是坏，他们都会提出异议；他们会反对我们做出的许多、甚至几乎所有改动。而且，他们非常擅长阻止那些极其糟糕的改动。

Turbine 的 XDP 版本发布后，如果给你一个没有会议、没有冲突的月份，让你完全自由地做任何事情，你最先会优化或重新设计 Agave 的哪个部分？

我真的很想——我真的会梦到这件事——大概两年来，我一直想重写 AccountsDB。我只知道，一旦开始做，它肯定会占用我一两个月的生命。而目前，这并不是最值得我投入时间的方式。但我会做的。我一直试图逼 Brooks 去做，但如果他不做，我迟早会自己动手。

未来发展

展望未来，面对异步执行或多并发领导者等规划中的功能，什么会成为性能团队最大的难题？

凭直觉来说，我讨厌异步。现在的模型非常简单：拿到一些交易，飞快地重放，然后投票。概念上特别容易理解。异步会让设计变得更难，但也会让链的实际使用体验好得多。

我也讨厌多并发领导者的设计，哈哈。我明白，尤其是想进行高速交易时，你需要多个领导者，别无选择。但就我个人而言，这至少 12 个月内不会实现，所以我不想太过分心。

一年内实现 Alpenglow 很重要，但下个月做到 1 亿 CU 同样重要。我们需要专注于让现有系统变快，因为 Alpenglow 是新代码，多并发领导者也是新代码。其中存在未知的未知。假设出于某种原因，Alpenglow 像 Firedancer 一样落后于计划，那该怎么办？难道要继续使用现在这条又烂又慢的链吗？不，我们必须专注于今天就跑得更快。

性能工程建议

对于有 Rust 经验、想进入高性能编程和性能分析领域的人，你会推荐哪些资源？

首先，我建议使用一个优秀的性能分析器，但现在还不存在，哈哈。不过，希望我很快就会发布自己的。然后，我确实认为，学习任何东西的最佳方式，就是在你真正关心的对象上亲手实践。

所以，我给想学习性能工作的人建议是：找一个你每天使用并且喜爱的软件，对它进行性能分析，让它变得更快，因为很多软件都非常慢。即便很多已经很快的软件，也还能快得多。计算机真的很快。也正因为它们太快了，你很容易做出运行缓慢的东西，却甚至完全没有察觉。

我看到很多人上瘾的过程都是：找到自己使用的东西，对它做性能分析，让它更快，提交 pull request。我保证，它们会被接受。然后你会彻底上瘾。

内核和其他依赖项没什么区别。就像你开发某个东西并使用一个库时，如果有东西无法工作、运行缓慢或出现其他问题，迟早都要深入查看这个库。内核只是另一个库。所以，, 去读内核代码。内核代码是我见过最简单的一类代码。如果你查看内核里的调度器，从概念上说，它比 Solana 上的调度器更简单。

直接去读 Linux 代码就好。它是 C，不太理想，而且任何涉及硬件的东西通常都很邪门，哈哈，但 Solana 的大部分代码并不直接和硬件打交道。如果找到每天都会使用的通用东西，比如 syscall、Tokio 或文件系统代码，那就非常简单。直接去读。如果花一周阅读，你就能像学习其他代码一样掌握它。然后你会觉得自己他妈就是个天才。你会想，啊，现在我也能做内核工作了，懂吧？

如今开始贡献的最佳方式是什么？

我更希望大家加入 Discord，进入 Solana Tech Discord 的开发频道。例如，有个人一直在做一些网络相关工作，前几天刚发起了一场有关 TPU 代码的讨论。说实话，他对这段代码工作原理的理解，比 Anza 的大多数人都更深入。你完全可以贡献。如果你和那个人一样优秀，并向我提交补丁，我就会合并。

我们很少进行内部的非开放开发。所以，如果你认为某段代码很慢，自己又很了解*,* 并且想修复它，但没有看到相关 pull request，那就在 Discord 上告诉我。我们会创建 issue，把它分配给你，然后由你修复。

我希望大家向我提交补丁。我确实希望通过提交补丁来壮大我们的社区。

快问快答

你今年解决过最棘手的 bug 是什么？

就在几个月前，一段浮点代码发生了错误编译，阻碍了 2.2 版本发布。它不是最难的问题，却最为繁琐，因为我不得不连续几天只读汇编代码。

盯着火焰图时，你会循环播放什么音乐？

通常是浩室或极简科技舞曲。一般会循环播放 Stephan Bodzin。

你最喜欢哪个 Linux 发行版？

肯定是 Debian。只有它没那么烦人，哈哈。

Alpenglow 将带来的最佳优化是什么？

我们不再执行投票。投票交易就是[已隐去]。整个投票机制不再使用交易，这实在太棒了。

你如何看待 ZK？

这是一项很棒的技术，但我觉得用它扩展区块链目前仍处于非常早期的研究阶段，所以我不是特别感兴趣。

到一年后的 2026 年 7 月，你预测 slot 时间会是多少？

就我个人而言，希望能更早实现。我希望 slot 达到 200 毫秒。我一直告诉 Toly，他需要不断玩这个梗，直到它变成现实。所以，希望到那时已经实现。我认为，即使今天我们也能做到。我的意思是，这应该是最低要求，任何高于这个数字的结果都算失败，但我们还可以进一步降低。

Agave 何时才能达到命中注定的 100 万 TPS？

哈哈，这个问题我不会快速回答。我一直在问大家：“这一百万笔交易要从哪里来？”

等人们真的有 100 万 TPS 要发送时，我们就会实现 100 万 TPS，但遗憾的是，我觉得短期内不会发生。我确实说过，如果 Agave 到 10 月还做不到 100 万 TPS，我就辞职。所以我可能得胡扯出一个演示，哈哈。

结语

Alessandro Decina 代表着 Solana 性能文化跳动的心脏——不追求理论上的完美，而是以务实工程为基础，不懈追求速度。他领导的性能团队以远超自身规模的实力，持续发现并修复那些叠加后导致系统整体变慢的“愚蠢 bug”。

在许多团队迷失于宏大架构愿景的世界里，Anza 性能团队始终紧盯眼前的瓶颈。分析、识别、修复、重复。这项工作并不光鲜，却能带来耀眼的成果：一条真正随硬件扩展，而不是绕着硬件限制打转的区块链。

上面的对话揭示了构建高性能系统的一项基本事实：速度不只关乎聪明的算法或尖端硬件。它还需要一种文化承诺——只要技术上可以做到“卓越”，就绝不接受“足够好”。对 Solana 而言，这意味着 200 毫秒的 slot、异步执行、多并发领导者，以及持续超过 100 万 TPS，都不只是技术里程碑，而是必然会实现的未来。