专访Anza性能团队的Alessandro Decina

工程速度：Anza 性能团队内幕，对话 Alessandro Decina

26 分钟阅读

2025 年 7 月 17 日

引言

毫无疑问，技术乐观主义是 Solana 的文化精神。对不受约束的速度、进步和创新的坚定信念贯穿于每一个提交到主网的 pull request。座右铭是 IBRL：增加带宽，减少延迟。它既是工程指令，又是文化试金石，也是世俗的祈祷。如果说比特币是不朽的殿堂，以太坊是中立的广场，那么 Solana 就是赛道：一个可衡量的、机械速度的领域。

然而，这种速度从来不是从天而降，变成一条注释清晰的 diff。它是那些敢于整天盯着代码的人开采、打磨和创造出来的。很少有人比 Alessandro Decina 更努力，他最初是一位 GStreamer 专家，将视频缓冲的卡顿视为对其个人的冒犯。如今，他领导着 Anza 的四人性能团队，这个团队的“自我关怀”是在凌晨 3 点从验证器的跟踪中删除黄色条。他们的日常工作包括盯着火焰图，删除整个工作流程，并重写经过实战考验的生产代码，因为任何可以优化的东西最终都会被优化。

我想了解在这种速度下生活意味着什么。因此，我与 Alessandro Decina 本人坐下来，了解他是如何让现有的最快区块链变得更快的。以下访谈是对速度的一次剖析。我们讨论了他使用多媒体管道的日子，以及使四名工程师能够胜过整个组织的文化保障。

为了清晰和简洁，对话已经过编辑和压缩。

访谈

起源和世界观

Ichigo：让我们回顾一下过去，你最初的爱好是 GStreamer 和多媒体管道。那个时代最大的延迟教训是什么？追逐实时音频和视频教会了你什么关于从 Agave 中减少毫秒级延迟的经验？

Decina：首先，你追踪我的行踪干得不错，哈哈。我已经在 GStreamer 上工作了大约 15 年，甚至更久。事实上，我所知道的一切都是在那里学到的。当它还是开源的，刚刚起步时，我就开始为这个项目做贡献。我非常幸运，当时我和创始人关系密切。那家伙比我大 15 岁左右，而且非常优秀。就像，这家伙在维基百科上都有记录——那家伙肯定很聪明。不像我——我只是假装聪明。那家伙决定，好吧，随便，我会免费教你我所知道的一切。所以，是的，我开始在那上面工作。

现在我们讨论在 Solana 上工作的低延迟时，这很有趣，因为这根本不是低延迟。比如，当你谈论音频处理、DPS 和多媒体硬件时，我们在 Solana 上所做的事情都是超高延迟。如果任何音频或视频的响应时间有 400 毫秒，那基本上就是坏了。这行不通。

在某个时候，我开始使用 Linux 驱动程序和硬件，这些硬件可以进行视频和音频的编码和解码。我今天做的很多事情本质上都与当时所做的事情相同。当你使用硬件时，延迟意味着某个地方有一个队列。你找到那个队列。你尝试最小化它，使其尽可能小，并确保它永远不会欠载。

例如，我现在正在做的 XDP 工作与音频环形缓冲区的工作方式非常相似。甚至我们正在进行的通话，你也会收到一堆乱序到达的数据包。某个地方有一个环形缓冲区正在重新排序所有的数据包，你肯定要确保它不会欠载。

感觉我过去 20 年都在做同样的工作。

可以这么说，同样的东西，不同的日子。因为我还注意到你也曾在 Spotify 工作过，还有一点 Firefox——

啊，不，Firefox 的工作只是为了黑客马拉松而做的集成工作。哈哈，我太老了，我为 Firefox 编写了使用 GStreamer 的原始视频标签。

该死，哈哈。所以条条大路通 GStreamer？

GStreamer 真的教会了我多线程编程。这就是我进入这个生态系统的原因。有些人编写汇编代码，做各种底层 hack。我心想，是的，我已经做了很长时间了。而且我了解到，除非你有一种具有强大的类型系统和良好的编译器的语言，否则你最终会搬起石头砸自己的脚。我确信你可以用汇编语言让某些东西稍微快一点，但我真的想要 Rust。

我希望 Rust 编译器告诉我：你是个白痴——这行不通，因为你这里有 bug。在 Rust 之前，我觉得我 10% 是软件工程师，90% 是肉体调试器。我只是在调试东西。所以，我认为 GStreamer 和我对 Rust 的热爱是我开始在 Solana 上工作的原因。Rust 越来越受欢迎，没有太多的工作允许你全职投入，我决定我只会使用 Rust。

我太老了，不想写 C 代码了。我不想要一种内存不安全的语言。我不想浪费我的时间。所以，是的，我在这里。

非常好。那么，当你做出转变时，在从事验证器代码之前，你对去中心化系统有什么误解吗？是什么让你相信 Solana 的架构实际上可以扩展？

事实上，我加入 Solana 晚了将近两年，因为我当时忙于开发 Rust 编译器。Solana 的一位刚开始从事虚拟机工作的人发了一封电子邮件说：“哦，我在做同样的事情，看起来你稍微领先一步，来和我们一起工作吧。” 我没有回复那封邮件，因为我研究了比特币，然后是以太坊，我意识到你可以执行一些东西，但你只有 10 TPS。这不是一个严肃的项目，对吧？ 你无法用 10 TPS 做任何现实世界的事情。

所以，当我收到那封邮件时，我没有回复。我就想，好吧，这些加密货币的人们还没有认真起来。

Toly 两年后联系了我，我查了一下 SOL 的价格。我想，好吧，我应该打开那封邮件的，哈哈。这次我确实和他聊了一下。在聊天之前，他给我指了一些代码。我看了看，说实话，代码很糟糕。这是非常糟糕的 Rust 代码。

但后来我和 Toly 聊了聊，没有在谷歌上搜索他，所以我不知道他是谁。他很聪明，说对了所有的事情。他说我们在构建这个东西。目前，我们这样做。这显然不是最先进的，但我们的目标是随着硬件的扩展而扩展。我们构建性能最高的区块链，然后瓶颈就变成了硬件。我们的想法是，你投入到这个东西上的硬件越多，它就能扩展得越多。

这对我来说很有说服力。这感觉不像是一群区块链狂热者在为第三次世界大战自慰......我对技术很感兴趣。我是少数真正为了技术而从事加密货币的人之一。

Solana 拥有这种工程文化，技术深受技术乐观主义的影响——那种 增加带宽，减少延迟 的文化。你个人是怎么看待它的？这如何影响 Anza 的日常工作？

对我来说，以太坊从根本上来说有一种稀缺心态。他们会说，好吧，我们已经遇到了一些障碍，我们将找到解决这些障碍的变通方法。我们将发明所有这些基础设施，本质上是为了我们拥有的知识差距，以及我们觉得我们不可能修复的差距，对吧？

相反，我觉得我们是相反的。就像，好吧，有一个问题。除了违反物理定律的事情之外，没有无法解决的问题。这只是一个巨大的文化差异。

如果有什么东西坏了，我们只会说，好吧，让我们坐下来。让我们稍微分析一下，看看问题是什么。让我们和交易员、做市商谈谈。让我们看看他们的问题是什么。最近，我们发现了一些非常具体的问题。而且我们已经修复了其中的大部分。而且，真正地，在两到三个月内，我们可以修复所有这些问题。

现在 Solana 中有很多东西不起作用。我们知道这些问题，而且我们从来没有坐下来，然后说：“我们有完美的解决方案！现在，为了进一步发展，我们需要发明一些新的东西，或者我们必须研究和做一些其他的事情。” 不——这些都是具体的问题。其中大部分都是非常愚蠢的问题。

而且，我们最近没有任何中断。我个人认为那是看跌的，对吧？因为我认为有些人已经开始变得有点保守了。我们知道我们可以更快。我们知道我们明天可以做 1 亿 CU 的区块，对吧？我们只需要加速一些事情。我支持加速一切。

我们从根本上知道——我们不需要路线图就能知道我们可以将当前性能提高 10 倍。我们看到了如何做到这一点。我们知道如何做到这一点。我们要么编写了代码，但它还没有完全完成，要么我们编写了代码，但无法部署它，因为仍然有一些需要修复的边缘情况。但我们确切地知道该怎么做。

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

性能工程

说到性能工作，我不认为很多人真正知道 Anza 有一个专门的性能团队。它有点默默无闻。请告诉我一些关于团队结构的信息。它与 Anza 的其他工程团队有何不同？

是的，所以我们在 Anza 确实有不同的团队。我们现在有共识团队，他们专注于 Alpenglow。我们有网络团队，他们主要专注于 Gossip。有 AccountsDB 团队，他们基本上只做帐户数据库工作。还有区块生产团队，他们负责调度程序。当然，还有我忘记的所有其他团队。

性能团队的不同之处在于，我们处理所有事情。我们进行性能分析，找到瓶颈，并尝试询问相关团队是否有时间和专业知识，因为有时我们会发现并非所有人都能解决的问题。例如，如果你是一个共识人员，你就不一定是最好的底层编程人员，因为你的专业知识在其他地方。因此，在这些情况下，我们通常会直接介入并为他们修复代码。

因此，我们不只是处理一件事。我们只是找到下一个瓶颈。我们大约每两周同步一次，并决定我们现在在哪里，接下来需要做什么，以及如何使下一个版本更快。

另一个很大的不同是，Anza 倾向于招聘聪明的人。比如，如果你不懂 Rust，没关系。如果你不懂底层编程，也没关系。我们认为，如果你很聪明，那么我们可以在工作中教你大部分这些技能。对于性能团队，我通常会聘用那些实际具有内核或其他底层经验的人员，因为我们现在遇到的瓶颈就是这样。

例如，对于帐户数据库，我们有一些必须修复的算法问题。但是，AccountsDB 在 2.3 版本中比两个月前快了十倍的原因是，我们只是修复了它执行 I/O 的方式。你需要知道它是如何工作的才能使其更快。比如，如果你只是对数据库有更高层次的理解，你并不真正了解磁盘是如何工作的，你也不需要了解内核如何调度 I/O 请求。

因此，就我个人而言，对于性能团队，我倾向于聘用更多底层人员。同样，我甚至不在乎他们是否懂 Rust，但我确实希望他们用 C 或 C++ 处理过其他底层的东西。

性能团队不太出名的原因是，我们基本上是从 12 月份开始的。我最初受聘从事编译器工作，但在 2024 年 3 月的中断前后转到了 perf，并开始优化事物。人们不是很开心，因为我有一天告诉他们，我会做任何我想做的事情。所以，是的，哈哈，他们不开心，但是我们获得了非常好的结果。因此人们走过来对我说：“好吧，实际上，你想雇更多的人来做这件事吗？” 然后在 12 月份，我们正式启动了 perf 工作并组建了团队。

老实说，我比较偏颇，但性能团队绝对是 Anza 中最好的团队，肯定的是。

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

我们有四个人全职，但是我在 Twitter 上开玩笑说 Brooks 和其他人会加入，因为我开始更广泛地与人分享我的分析器。直到大约两个月前，只有性能人员才能访问分析器。现在每个人都有分析器。比如，Brooks，自从我给了他分析器以来，Brooks 做的性能工作比我还要多，哈哈。他完全沉迷了。他现在只是让一切都变得更快。

所以现在非官方地有 Brooks 和其他一些人也在做很多性能方面的事情。但是我们有四个人全职负责性能。

那么，在处理性能时，你在进行性能分析时会注意到哪些大多数工程师会错过的“气味”？你如何决定哪些需要优化？

有一些非常明显的事情。比如，当我第一次开始分析 Agave 时，我们花费在内核中的时间比执行用户空间代码的时间要多得多，这太荒谬了。我们不是一个底层的应用程序。如果我们是一个多媒体框架，那么你在内核中完成大部分工作是有意义的，因为最终你需要将样本发送到硬件。但是我们所做的唯一真正的底层工作是 Turbine。

因此，通常，当我开始进行性能分析时，最大的“气味”是我开始在我的火焰图中看到很多黄色，因为这意味着我们在内核中花费的时间太多了。这可能意味着有人在使用一些看起来无辜的高级 API，但在底层，它的性能非常糟糕。

在过去的一年中，我们将 Agave 使用的内存量减少了大约 10 倍，因为我们通常会遇到相同的问题。当你进行过多的内存分配时，在某个时候，你需要开始与内核进行交互。你可以在分析器中看到与内核的交互。你可以看到，好的，这来自哪里？你看到这个链一直在搅动内存。你一路追踪到你正在搅动和分配过多内存的地方，然后你去修复它。

有些事情更难。例如，我们发现并正在修复这个根本的设计问题。因此，众所周知，Solana 是流水线的，并且有不同的阶段，并且应该全部并行化，以便事物并行运行等等。

实际上，由于事物的架构方式，我们确实有一个流水线设计，但是我们的流水线中有很多停顿。因此，我们确实有不同的阶段，但是由于愚蠢的设计错误导致在各个部分引入了延迟，因此我们没有最大化所有阶段的吞吐量。当人们无法发送交易或说系统存在抖动时，人们通常抱怨的是这种延迟。这种抖动不是由任何基本的东西引起的，也不是由硬件引起的——只是我们做事不够优化。

但是，坦率地告诉你，我们所做的事情都是愚蠢的。就像，有一些非常明显的错误，而我们只是在修复这些明显的错误。

你如何决定这些错误是否需要微基准测试，还是完全重放主网流量？

我认为我们遇到的大多数性能问题都来自于人们编写微基准测试的事实。他们使微基准测试变得更快。他们孤立地对其进行了测试。然后，当你将所有东西放在 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 中发现了一些错误。我开始修复这些错误。我仍然有一些想要发送的内核补丁，但是在某个时候，我意识到，好吧，我不能告诉我们所有的验证器运营商使用我的自定义内核来运行 Solana。

我必须使用 XDP，我们做到了。现在它可以工作了。

答案是：你找到下一个瓶颈，然后修复它。你不断修复你发现的所有瓶颈。你可以明天再考虑明天的问题。这是我的座右铭。你只能担心明天，但是今天会很糟糕。Solana 的今天很糟糕。区块太小，Turbine 增加了太多的延迟，调度程序仍然存在问题。我们必须在今天解决这些问题。否则，明天就没有那么快了。

在 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 上告诉我，我们将创建一个问题，我们会将它分配给你，然后你修复它。

我想让人给我发送补丁。我确实想通过发送补丁来发展我们的社区。

快速问答

你今年解决的最难的 bug 是什么？

几个月前，一些阻止 2.2 发布的浮点代码的错误编译。这不是最难的，但这是最繁琐的事情，因为我不得不花几天的时间阅读汇编代码。

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

通常是 house 或 minimal techno。Stephan Bodzin 通常是循环播放。

你最喜欢的 Linux 发行版是什么？

肯定是 Debian。它是唯一一个不是超级烦人的发行版，哈哈。

Alpenglow 中最好的优化是什么？

我们不会执行投票。投票交易是 [已编辑]。整个投票不再是交易，这太好了。

你对 ZK 的看法是什么？

这是一项很棒的技术，但我认为它在扩展区块链方面仍处于研究阶段。所以我不是很感兴趣。

2026 年 7 月，一年后，你对你的 slot time 有什么预测？

就我个人而言，希望能早于这个时间，我希望有 200 毫秒的 slot time。我一直在告诉 Toly，他需要通过迷因让它存在。所以希望到那时，它会发生。我认为我们今天也可以做到。我认为这将是最小值，从某种意义上说，超过这个值将是一个失败，但我们可以低于这个值。

Agave 什么时候能达到传说中的 100 万 TPS？

哈哈，我不会对这个问题进行快速回答。我一直问人们，“100 万笔交易将从哪里来？”

当人们有 100 万笔 TPS 要发送时，我们将会实现 100 万笔 TPS，但我认为这不会很快发生，可悲的是。我说过，如果 Agave 在 10 月份之前没有实现 100 万笔 TPS，我就会辞职。所以我可能不得不瞎编一个演示，哈哈。

结论

Alessandro Decina 代表了 Solana 性能文化的核心——对基于务实的工程而不是理论上的完美的对速度的执着追求。他的绩效团队的表现远远超出了他们的重量级，他们发现并修复了“愚蠢的错误”，这些错误共同加剧了系统性的速度减慢。

在一个许多团队迷失在宏伟的架构愿景中的世界中，Anza 的性能团队始终专注于他们眼前的瓶颈。性能分析、识别、修复、重复。这是一项不吸引人的工作，但会产生迷人的结果：一个实际上随着硬件扩展而不是围绕硬件扩展的区块链。

上面的对话揭示了构建高性能系统的基本真相：速度不仅仅是关于巧妙的算法或尖端的硬件。这是关于一种文化承诺，即在“伟大”在技术上可以实现时，永远不要接受“足够好”。对于 Solana 而言，这意味着 200 毫秒的 slot time、异步执行、多个并发领导者和维持超过 100 万的 TPS 不仅仅是技术里程碑——它们是必然的。

• 原文链接： helius.dev/blog/solana-p...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～