ERPC 发布《How to be faster on Solana?》（如何在 Solana 上更快？）——一份以网络距离的物理学可视化呈现"在 Solana 上速度由什么决定"的报告，并附实时数据
ERPC 发布《How to be faster on Solana?》（如何在 Solana 上更快？）——一份以网络距离的物理学可视化呈现"在 Solana 上速度由什么决定"的报告，并附实时数据
运营 ERPC 的 ELSOUL LABO B.V.（总部：荷兰阿姆斯特丹；CEO：Fumitake Kawasaki）与 Validators DAO，谨此宣布发布《How to be faster on Solana?》（如何在 Solana 上更快？）报告页面。它以一条自上而下、即便非专业开发者也能一眼把握的连贯脉络，讲清如何在 Solana 上变得更快。
近年来，越来越多的开发者与团队在区块链上、尤其是在 Solana 上投身于高频交易（HFT）与实时金融基础设施。然而，围绕那些最基本问题——为什么有人更快、又该如何变得更快——背后的知识，一直零散地分布在各篇技术博客与片段式的说明之中，能让人迅速把握全貌的资料寥寥无几。本报告将 ERPC 多年来发表的技术文章的核心，重新整理为一条连贯的"物理学脉络"。
本报告所分享的，是一种实用的理解：即便面对参与者遍布全球的去中心化网络，也能更高效、更高速地使用它。我们相信，系统性地分享"速度差异在何处、又因何而生"，将超越任何单一服务商的利益，为包括 Solana 在内的更广阔区块链生态的高效与健康成长作出贡献。
How to be faster on Solana?（报告页面）：https://erpc.global/zh/how-to-be-faster/
ERPC 官方网站：https://erpc.global/zh
ERPC 控制台：https://dashboard.erpc.global/zh
决定速度的不是你的代码或机器——而是那看不见的第三层
"跑的是同一套策略，偏偏只有我的 bot 成交得慢。""行情更新得好好的，可偏偏只有我的交易过不去。""换了 RPC 服务商，却什么都没变。"——在 Solana 上为速度而竞争的开发者们，发出的抱怨惊人地相似。
第一个被怀疑的，永远是"也许是我的代码慢了"或"也许是我的配置不够好"。优化代码与机器，当然有帮助。但在许多已经把两者都彻底调优的情形里，留到最后、又最容易被忽视的，是那看不见的第三层：你到 Solana 的网络距离。
当你的执行路径已经被很好地优化之后，指令级的 CPU 调优还能压榨出来的余量，已经处在纳秒到至多几微秒的世界里。相比之下，网络距离掌管的是数百毫秒——一个约 1000 倍量级的杠杆，正沉睡在人们最容易忽视的那一层。在你已经打磨好代码与机器之后，剩下最大的提升空间，就在那第三层。
在 Solana 上，"最快的位置"每个 slot 都在全球移动
在 Solana 上，一个 slot 大约每 400 毫秒推进一次，每个 slot 都会指派一个 validator 作为"leader"来构建那一段区块。leader 切换得很快（同一个 validator 可能连续持有若干个 slot），而离那个 leader 最近的服务器，会在那个 slot 上获得很大的优势。
正因如此，它与传统高频交易在根本上不同。在股票或外汇里，把你的服务器放在交易所那台唯一撮合引擎旁边——一个不会移动的固定点——就能长久领先。而在 Solana 上，leader 随每个 slot 在全球移动。最快的那个席位，每一次都在不同的地方。在某一个位置安营扎寨一次便万事大吉，在这里根本行不通。
在报告里，一个由 ERPC 的 Leader Slot Information API（getLeaderSlots）实时数据驱动的地球仪，会原样展现当前的 leader，以及它令人眼花缭乱的轮换。"最快的位置一直在移动"——这并非比喻，而是你可以实时观测到的事实。
距离即延迟——从同一网络内的约 0.1ms 到跨大洲的 100–300ms
光在光纤中的速度，以及路径上路由器跳数（hops）的多少，划定了一个任何硬件都无法突破的下限。距离大致以如下数量级产生作用：
- 同一网络：约 0.1ms
- 同一数据中心：约 0.3ms
- 同一城市：约 1ms
- 邻近国家：约 5–10ms
- 跨大洲：约 100–300ms
一个 slot 只有约 400 毫秒。跨越一片大洲所需的 100–300 毫秒，单凭自己就吃掉了一整个 slot 的窗口。当 leader 就在你家门口时，你赶得进窗口；当它在地球另一端时，还没等你发出，你就已经错过了。要为每一个 slot 都做到快，就意味着无论 leader 落在何处，你都始终"在近旁"。
需要说明的是，报告中的这组对比——"同一网络内约 0.1ms"对比"在绕远的路径上，中继跳数（hops＝信号经过的路由器）会升到约 7，延迟则扩大到约 70 倍"——是用来直观传达近路径与远路径之间差距的概数。那些经过实测的大幅波动，体现在 ERPC 的 Leader Slot Information API 的实时数据里：从某个给定节点到 leader 的实测延迟，会因 leader 所在之处（即哪一个 slot）而有很大变化，并且在近 slot 与远 slot 之间，已观测到数十倍量级的摆动。一个单一的"平均延迟"数字，往往不过是一个快 slot 和一个慢 slot 轮流出现而已；平均值经常掩盖了真实情况。
而一个"城市名"并不等于网络路径本身。即便在同一座城市内，只要插入了外部中转或额外的跳数，延迟就会仅仅因此而层层累加。这正是为什么你要凭实测到达时间（ping）、而不是凭地图上的距离，来选择最近的节点。
一座城市还不够——多区域，始终贴近 leader
Solana 的 validator 聚集得最密集的城市，是 Frankfurt。即便如此，在发布时的一次实测快照里，聚集在 Frankfurt 的 validator 也只占整个网络的约四分之一——无论按 validator 数量还是按 stake 来看都是如此。其余大约四分之三的 slot，是从 Frankfurt 以外的某处来领导（lead）的。
换言之，即便你把那台最好的机器单独放在最拥挤的城市，单凭这一点也永远无法让你"始终最快"。在若干区域同时待命（例如 Frankfurt / Amsterdam / New York / Tokyo / Singapore），在当前正活跃的那个 leader 附近接收，并随着 leader 的移动而接力交接——这才是为每一个 slot 都做到快的方法。
当你的交易落不了地，你就被困在了垃圾车道里
速度不只关乎你的服务器坐落于何处。你通过哪条车道投递交易，也同样决定着成败。
在接收交易的 TPU（Transaction Processing Unit）的容量中，leader 会把至多约 80% 分配给按 stake 加权的优先级——也就是分配给那些由已质押给某个 validator 的 SOL（stake）作为后盾的连接（SWQoS / Stake-Weighted Quality of Service）。其余大约 20% 则由所有其他连接共享。后者是一条挤满垃圾交易的拥挤车道。需要说明的是，这约 80% 的分配，是作为 Solana 协议的一部分在 leader 一侧决定的，并非由 ERPC 设定。
把交易径直射向 leader，感觉像是最快的做法。但若没有 stake 的后盾，那就意味着在拥挤的约 20% 车道里排队，一旦负载上来，你的交易最终就再也进不了区块。本质上的答案，是通过一条有 stake 作后盾的路径来发送——即从一个与 staked validator 连接的 RPC，经由 trusted peer 关系发出。ERPC 运营着一个顶级的 staked validator，并将其连接到高质量的 RPC 线路上，作为这一点的后盾（Shinobi Performance Pool）。
硬件只有在全力运转时才有意义
即便一台服务器被放在了正确的位置，倘若这台机器本身不全速运转，它也无法利用自己所获得的那份"近"。虚拟化的 VPS 共享一套 hypervisor，因此恰恰在最拥挤的时候，容易因"吵闹的邻居"而产生抖动和卡顿。专用的 bare metal 则没有这个问题。Solana validator 必须满足的时钟频率下限是 2.8GHz；而 ERPC 的 bare metal 运行在远高于此的高达 5.7GHz 级别的时钟上，同时把利用率维持在 30–40%——因为一颗被钉死在 95% 的 CPU 会像堵死的道路一样产生抖动。
这种差别并不限于顶级的 bare metal。在报告中，我们用一项真实的基准测试（node_bench），把 ERPC 的 VPS（VPS++）与一台配置相当的大型云虚拟机（两者皆为 AMD Turin / 4 vCPU）并排放在一起对比。这不是一场演出，而是一次任何人都能用同样方法复现的"测量"。ERPC 一贯强调：通过测量、而非通过主观主张或营销文案，来展示交付的质量与速度。
最终答案：同一网络＝零距离
这整条推理脉络抵达的，是同一个点：与 Solana 的基础设施——RPC、validator，以及交易所涉及的实时路径（如 Jito 与 Shredstream）——处在"同一网络"之上。在同一网络上是约 0.1ms，数据包根本完全不会穿越公共互联网。"经由公共互联网"，是大多数人的默认方式，而这恰恰正是大多数人之所以慢的原因。零距离，是把位置、机器与 stake 系到一起的那个结论。
ERPC——物理学所要求的每一项优化，都集于一个平台
对于报告作为物理学推导出的每一个答案，ERPC 都备有对应的手段：处在同一网络上的 VPS 与 bare metal（零距离）、在多个区域待命（FRA / AMS / NY / TYO / SGP）（始终最快）、基于实测 ping 的路由（凭路径、而非凭地图，连到真正最近的节点）、getLeaderSlots API（逐 slot 地知晓 leader 的位置），以及用开源的 SLV 调优过的 5.7GHz 级 bare metal（全力运转）。
ERPC 之所以诞生，首先是因为我们自己就需要它。在运营开源的 Epics DAO（一款 Solana 上的卡牌游戏）时，我们想买都买不到这样的基础设施，于是别无选择，只能自己动手把它建起来。如今，你可以站在同样的这块基石之上。
在 ERPC 上，你可以在单一平台上组合使用 Solana RPC、WebSocket、Solana Geyser gRPC、Solana Shredstream、Direct UDP Stream（Raw Shreds）、VPS、bare-metal 服务器、专用 RPC、SWQoS、支持 Pyth 的 Price API，以及 Jet Analytics & Indexed RPC。
更快、更高效地使用去中心化网络
速度中确实有一部分，可以通过恰当的基础设施投入来改善。但本报告自始至终想要传达的是：理解"差异在何处、又因何而生"，才是真正的优势所在。一旦你弄清自己正在哪里损失时间——位置、路径、机器，还是 stake——你便能由此选择恰当的资源，并把精力集中在你的核心工作上：策略、编码与开发。
即便是在去中心化网络上，网络也能被高效地使用。以系统化的方式分享这一事实，理应超越任何单一服务商的利益，为包括 Solana 在内的更广阔区块链生态的高效与成长作出贡献。
Solana 专用基础设施的研发与持续改进
ERPC 的背后，是 ELSOUL LABO 持续推进的、面向 Solana 专用基础设施的研究与开发。自 2022 年以来，ELSOUL LABO 已连续五年获得荷兰政府研发支持计划 WBSO 的认可。它持续就 Solana RPC 基础设施、validator 运营、实时数据交付，以及由 AI agent 辅助的运营与开发开展研发，而这些成果，正体现在包括 ERPC、SLV、SLV AI，以及 AS200261 这一 Solana 专用数据中心在内的各项服务之中。本报告的发布，同样是一项直接承接自这种持续研发的工作。ERPC 今后也将继续以系统化的方式发布其成果。
使用与咨询
如果您对本报告的内容有疑问、希望就提升自己这套配置的速度进行咨询、需要在资源选型或迁移规划上获得帮助，或对基准测试有疑问，请在 Validators DAO 官方 Discord 上创建一张支持工单。
How to be faster on Solana?（报告页面）：https://erpc.global/zh/how-to-be-faster/
ERPC 控制台：https://dashboard.erpc.global/zh
ERPC 官方网站：https://erpc.global/zh
Validators DAO 官方 Discord：https://discord.gg/C7ZQSrCkYR
衷心感谢各位用户一直以来对 ERPC 的使用与支持。
链接
- How to be faster on Solana?（报告页面）：https://erpc.global/zh/how-to-be-faster/
- ERPC 官方网站：https://erpc.global/zh
- ERPC 控制台：https://dashboard.erpc.global/zh
- ERPC 价格：https://erpc.global/zh/price/
- SLV 官方网站：https://slv.dev/zh
- SLV GitHub：https://github.com/validatorsDAO/slv
- Validators DAO 官方 Discord：https://discord.gg/C7ZQSrCkYR
