关于 Solana 本地费用市场的真相

非常感谢 Eugene Chen 和 0xIchigo 对本工作的早期版本进行审阅。

可操作的见解

• 本地费用市场（LFMs）使 Solana 能够根据状态的竞争程度为单个状态设置细粒度费用。交易根据它们写入的特定状态支付费用，防止局部热点在整个区块链上提高费用。
• LFMs 对于实现 Solana 可扩展的统一基础层愿景至关重要，在这个层面上，所有应用程序无缝共存。如果没有 LFMs，链上某一部分的费用激增将导致所有交易的费用增加——这是其他仅依赖全球费用市场进行区块空间定价的网络常见的问题。
• 随着 2023 年底 Solana 经济活动的加速，LFMs 原始实现中的几个关键缺陷变得明显。最显著的是非确定性调度器优先级。交易主要根据到达区块构建者的时间排序，优先费用仅作为次要考虑。
• 在 2024 年 5 月的 Agave 客户端更新 v1.18 中，引入了新的交易调度器和改进的交易优先级公式。调度器构建依赖图，以更好地管理跨线程的冲突交易的处理和优先级。这一重大更新显著提高了协议以确定性方式排序交易的能力。
• 评估有效运行的 LFMs 的一个有价值的指标是比较中位数和平均交易优先费用。涉及无争议状态（50%百分位中位数）的费用预计将保持较低。争议状态的费用应随着需求的增加而激增，从而拉高平均费用。最近的数据证实了这一模式。在 2024 年 11 月，非投票交易的平均费用达到了超过 0.0003 SOL 的历史新高。然而，中位费用保持在 0.00000861 SOL，约为 35 倍低。
• 今天，Solana 的 LFMs 是功能性的，但仍有显著的改进空间。Anza 工程师对银行阶段线程工作负载的分析表明，调度器的错误阻止了验证者客户端充分利用其全部能力。因此，Agave 客户端仅以其潜力的一小部分运行。此外，尚无正式规范说明交易应如何排序。
• 当前的优先费用 API 缺乏提供确定性结果所需的复杂性。每个主要 RPC 提供商都提供自己的自定义优先费用 API，这可能导致一种软性供应商锁定。核心开源 RPC API 实现未考虑关键网络动态，例如 Jito 的影响，导致费用估算不准确。
• 在没有确定性计算优先费用的方法的情况下，开发者通常采取谨慎的方法，通过超额支付来确保他们的交易被处理。或者，他们可能会过度使用 Jito 小费作为替代机制，即使对于不需要确保区块顶部的交易也是如此。
• 已提出各种策略以进一步增强 Solana 的费用结构。这些包括指数写锁费用和动态基础费用。网络尚未找到施加经济反压力以抑制垃圾邮件的方式，同时保持对真实用户的低费用。

介绍

费用市场是经济机制，旨在通过动态调整交易费用有效分配稀缺的区块空间给最高价值的交易。交易愿意支付的费用是其价值的代理。LFMs 通过根据状态的竞争程度为单个状态设置细粒度费用来细化这一一般概念。当两个交易访问相同状态时（无论是两个写操作还是对同一账户的读写操作），则认为它们是有争议的。

通过 LFMs，交易根据它们写入的特定状态支付费用，防止局部热点在整个区块链上提高费用。访问高需求或有争议状态的交易会产生更高的费用，而与需求较低的状态交互的交易则支付较低的费用。这一点很重要，因为 Solana 在处理无争议交易方面表现更好，因为它支持并行执行。

相比之下，全球费用市场对访问网络状态施加普遍成本，这意味着所有交易无论与哪个账户交互都平等竞争纳入区块。 以太坊的费用模型，在 EIP-1559 中实施 ，是全球费用市场的一个相关示例。EIP-1559 根据网络需求调整动态基础费用，以保持每个区块的最佳计算（gas）使用。当区块容量填满时，所有交易的费用都会增加。钱包根据当前基础费用和交易的 gas 限制计算费用。这种方法在协议中强制执行，并提供可预测的费用计算；然而，它未能将高需求热点与更广泛的网络隔离。当费用激增时，所有交易的费用都会激增。

特定状态的高需求问题并非区块链所独有。这一挑战与热点关键问题相似，通常被称为“名人问题”，在 Web2 社交应用中常见。

通过本文，我们旨在提供对 Solana LFMs 的可访问分析。该工作分为以下几个部分：

• Solana 费用基础知识： 为读者建立对 Solana 当前交易处理方式的基本理解。
• 本地费用市场的早期问题： 探讨 LFMs 早期实现中的初始问题及其缺陷。
• 中央调度器 v.1.18 更新： 突出 2024 年一个重要更新，显著改善了 LFMs 的功能。
• 衡量本地费用市场的有效性： 提供与理解 LFMs 在 Solana 上运行状态相关的数据。
• 持续问题和改进领域： 本节讨论未解决的问题和需要关注的领域，以使 LFMs 实现其全部潜力。
• 提议的解决方案： 回顾提议的解决方案，以细化 LFMs 并引入更好的经济激励，以实现更细致的区块空间定价。

已经熟悉 Solana 交易费用结构的读者可能希望跳过以下关于费用基础知识的部分。

Solana 费用基础知识

Solana 交易由两部分费用组成——基础费用和优先费用。 基础费用目前固定为每个签名 5,000 lamports。大多数 Solana 交易只有一个签名。优先费用以微 lamports（即 lamport 的百万分之一）为单位，按请求的计算单位（CU）计算。费用从费用支付者账户（签名者）中扣除。如果支付者的 lamports 不足以支付交易费用，则交易将被丢弃。在撰写本文时，基础费用和优先费用的 50%由区块构建者保留，作为将交易纳入区块的激励。其余 50%被销毁。在去年 5 月成功的治理投票后， 提案 SIMD-096 将改变为 100%的优先费用由区块构建者保留 。例如：

一笔交易有一个签名并请求 500,000 CUs。发送方设置的优先费用为每请求的 CU 50,000 微兰波特。该交易的总费用为 5,000 兰波特 + (500,000 请求的 CUs * 50,000 微兰波特每请求 CU) = 25,000 兰波特，或 0.000025 SOL。

验证者的计算资源是有限的，协议将每个区块的总计算资源限制为 4800 万 CUs。这个数字是根据验证者能够合理处理的量经验性选择的，以达到 400 毫秒的区块时间。每个账户每个区块的最大 CUs 限制为 1200 万，而每笔交易的最大计算限制设定为 140 万 CUs。交易消息的大小也限制为最大 1,232 字节，这是 IPv6 的最小传输单元（1280 字节）减去头部。

为了防止计算资源的滥用，Solana 为每笔交易分配了计算预算。默认情况下，网络为每条指令设置的最大限制为 200,000 计算单位（CU）。然而，交易可以通过包含 **SetComputeUnitLimit** 指令来指定自定义的计算单位限制，从而实现更高效的资源分配。Agave 客户端代码库列出了各种操作的 CU 成本 。

Solana 要求所有交易都必须指定在交易过程中将被读取或写入的账户地址的完整列表。该列表的最大大小为 35 个地址，可以通过链上地址查找表进行扩展。构建地址列表为开发者带来了额外的开销，但这是解锁 Solana 许多优化的关键，包括并行交易执行和本地化费用市场。

Solana 本地费用市场的早期问题

“本地费用市场是一个谎言。” - Ben Coverston， 联合创始人，Temporal

随着 2023 年底 Solana 上经济活动的加速，原始 LFMs 实现中的几个关键缺陷变得显而易见。此时，Ellipsis Labs 的 Eugene Chen 提供了对这些挑战的全面分析，见于 Umbra Research 文章，Solana Fees, Part 1。以下是 Chen 提出的关键点摘要。

缺乏准确请求 CUs 的激励

Solana 的费用结构按签名收取基本费用，而不考虑使用或请求的计算单位（CUs）。与此同时，优先费用在拥堵期间仅提供有限的激励来减少 CU 使用。这种设计使得交易发送者几乎没有动力来优化计算使用或将其 CU 请求与实际需求匹配。因此，交易经常过度请求 CUs，导致网络调度过程中的低效。

激励使用协议外的优先机制

燃烧 50% 的优先费用激励交易发送者通过与区块构建者串通并安排链下支付以获得优先访问，从而绕过协议。这种行为在 Jito 拍卖的日益增长中显而易见。运行 Jito-Agave 客户端的验证者从更高的费用收入中受益，并可以通过 Jito MEV 佣金奖励有效地将这些利润分配给委托的质押者。随着 Jito-Agave 客户端的采用增加，Jito 套餐在许多场景中证明是一种更优的交易交付服务。

非确定性调度器优先级

Solana 的共识和调度器都没有根据优先费用强制执行严格的交易排序。交易主要按到达区块构建者的时间排序，优先费用仅作为次要考虑因素。更高的优先费用可以增加在争议状态下被包含的可能性，但排序过程仍然是非确定性的。在到达交易处理单元（TPU）之前的网络抖动和调度器内部的抖动进一步增加了不可预测性。

这种缺乏确定性降低了交易执行的可预测性和可靠性，促使用户通过交易垃圾泛滥网络以提高更快包含的机会。然而，提高优先费用在某个阈值之后收益递减，削弱了其作为更好交易放置机制的有效性。Solana 的共享区块空间最终成为经典的“公地悲剧”的受害者。个体行为者出于自身利益，导致了这一公共资源的过度利用和低效。

中央调度器 v1.18 更新

Agave 客户端调度器的初始实现仅提供了一个松散的保证，即高优先费用的交易在特定区块中被包含的机会更大。领导者的交易处理单元（TPU）使用六个并行线程运行：四个处理非投票交易，两个保留用于投票交易。每个非投票交易线程维护自己的队列，待处理的交易在此队列中等待分组以执行。之前，交易是随机分配到这些线程的，队列独立优先处理数据包，而不考虑其他线程处理的数据包。

在这个系统中，每个线程循环其队列，尝试锁定并执行交易。一旦线程完成当前循环，它会收集额外的数据包并重新开始该过程。这种结构为优先费用的有效使用带来了挑战。例如，虽然高优先级交易可能在一个线程的队列顶部，但另一个线程可能同时处理涉及同一账户的低优先费用交易，且该交易在其队列的末尾。优先费用仅在单个线程内（线程内）影响交易排序，而不跨所有线程（线程间）。因此，每个队列应用了一种混合排序机制，将先进先出（FIFO）处理与优先费用考虑相结合。然而，没有在线程之间强制执行全局排序。

当一个线程准备执行交易时，必须首先获取所需的账户锁。如果所需的写锁不可用，则该交易会被重新排队。交易随机分配到线程的问题加剧了这一问题，因为同一交易类型可能在多线程调度系统中处于不同的位置。这种调度器的随机性引入了抖动，造成交易在区块中的放置位置的可变性。

随着 Agave 客户端更新 v1.18 于 2024 年 5 月推出了新的交易调度器，即中央调度器。在这个修订结构中，中央调度器构建了一个依赖图，称为优先图，以更好地管理跨所有线程的冲突交易的处理和优先级。这一重大更新显著提高了 Solana 确定性排序交易的能力；优先费用更高的交易更有可能被包含在区块中。

优先图是一个有向无环图（DAG），随着新交易的添加而动态更新。交易在图中组织成按时间优先级顺序处理的执行链。对于冲突交易，优先费用决定插入顺序。这种方法最小化了锁争用，使得交易批次能够顺利执行，并减少因资源冲突造成的延迟。交易预编译验证已被卸载到工作线程，以提高性能并实现更高效的处理。

更新后的调度器设计显著增强了可扩展性和灵活性，允许在不增加锁冲突风险的情况下潜在地增加线程数量。此外，集中调度方法改善了奖励生成，提高了许多验证者运营商的收益。

有关中央调度器的更详细信息，读者可以参考我们之前的 Helius 博客文章，涵盖 Agave 1.18 更新 。

更有效的优先级计算

与调度器更新一起，交易优先级公式经过改进，给予计算需求较低的交易优势，惠及开发者和资源使用最少的交易。

优先级 = (优先级费用 * 请求的计算单位) + 基础费用 / (1 + 请求的执行计算单位 + 签名计算单位 + 写锁计算单位)

这一新计算考虑了与交易相关的所有计算和操作成本，确保优先级水平准确反映实际资源消耗。因此，简单的代币转移或没有额外优先级费用的原生 SOL 交易在队列中保证有一个基线优先级水平。对于更复杂的交易，未能使用 SetComputeUnitLimit 指令指定自定义计算单位限制的开发者在交易优先级上处于劣势。

衡量本地费用市场的有效性

本节将考察与 Solana 的本地费用市场相关的数据。

中位数与平均交易费用

在有效运作的本地费用市场中，涉及无争议状态的交易费用（如简单的稳定币转移）预计将保持较低。同时，访问争议状态的交易费用（如投机性低流动性代币）应随需求激增。评估这一动态的一个有价值指标是中位数和平均交易优先级费用的比较。中位数费用代表第 50 百分位用户支付的费用，反映典型成本，而平均费用则是所有费用除以交易总数，突显整体趋势。

最近的数据证实了这一预期模式。2024 年 11 月，Solana 的经济活动达到了迄今为止的最高水平，非投票交易的平均费用达到了超过 0.0003 SOL 的历史新高。尽管如此，中位数费用仍保持在 0.00000861 SOL，约低 35 倍。这与 2024 年 4 月形成对比，当时经济活动的类似激增导致平均费用超过 0.0002 SOL，同时中位数费用也相应上升至 0.00001862 SOL，约低 10 倍。这一差异突显了费用隔离在高需求期间保护典型用户免受成本激增影响的有效性，并维护了非投机驱动用例的用户体验。

当分析来自 EVM 基础网络（如 Coinbase 运营的 Ethereum L2 Base，缺乏本地费用市场）的类似数据时，我们观察到中位数和平均交易费用之间存在强相关性。由于需求增加，全球基础费用上升，平均和中位费用相对同步移动。此外，中位数和平均交易费用之间的差距明显较小。例如，在 2024 年 12 月 5 日，Base 上的平均交易费用飙升至 0.1115 美元，而中位数费用也上升，达到 0.0228 美元——约低五倍。

回滚交易率

另一个值得考察的趋势是回滚交易的比率。在 2024 年 4 月和 5 月的高经济活动期间，Solana 用户广泛报告了用户体验下降，因为链在大量垃圾交易的压力下受到了影响。缺乏确定性降低了交易执行的可预测性和可靠性，促使用户向网络发送交易垃圾，以提高更快纳入的机会。

搜索者经常提交交易以进行机会交易，而不考虑成功的概率。优先级费用过低的套利交易仍然有效。协议将在其他高优先级费用交易之后处理它们，并且由于滑点逻辑，它们可能会回滚。

回滚交易在 2024 年 4 月达到了顶峰，占所有非投票交易的 75.7%。在关键更新（包括 Agave 1.18 中央调度器）推出后，这一比例显著下降。

来自 Blockworks Research 的一项群体分析涵盖了过去七天（2024 年 1 月 6 日至 13 日）的数据，显示不同活动水平的回滚率各异。每天进行 1-5 笔交易的地址（主要是零售用户）回滚率为 1.4%，而每天进行 6-50 笔交易的地址回滚率增加至 4.6%。值得注意的是，每天进行超过 10,000 笔交易的地址回滚率飙升至 66.7%。此外，每天进行超过 100,000 笔交易的高活动地址（机器人）占所有回滚交易的 95.2%。在 2024 年 12 月，所有非投票交易的整体回滚率为 41.2%，这表明网络的大部分计算资源被用于处理失败的套利交易。

持续问题和改进领域

尽管取得了显著进展，Agave 验证者客户端调度器仍面临挑战。Anza 工程师 Alessandro Decina 进行的银行阶段线程工作负载分析突显了现有的低效和改进领域。

调度器线程： 这是生成区块的最关键线程。调度器接收所有入站交易，然后对其进行排序和调度以执行。

投票交易线程： 两个专用线程处理投票交易，确保它们与用户交易分开处理。

非投票交易线程： 四个线程根据调度器的调度接收交易并处理用户交易。

QUIC 吞吐线程： 当验证者是领导者时，Tokio 线程管理通过 QUIC 协议的交易吞吐。在 2024 年初的拥堵期间，这些线程是一个重要的瓶颈。

上述可视化显示，尽管所有工作线程在领导者的第一个区块开始时并行执行交易，但这种并行性很快退化为顺序执行。具体而言，只有一个非投票交易线程（线程三）继续处理交易，其余线程处于闲置状态。

这种行为表明调度器存在缺陷，导致验证者客户端无法充分利用其全部能力。因此，系统仅以其潜力的一小部分运行，这表明如果问题得到解决，验证者可以处理当前负载的四倍。

可观察性

当前用于估算可预测交易落地的费用 API 缺乏提供确定性结果所需的复杂性。每个主要 RPC 提供商都提供自己的自定义优先级费用 API，而核心开源 RPC API 实现仍不理想 。它未能考虑关键的网络动态，例如 Jito 的影响，导致费用估算不够准确。

Helius 提供了 `getPriorityFeeEstimate` RPC 方法，该方法根据全球和 LFM 的历史数据提供费用建议。开发者可以输入序列化的签名交易或参与交易的账户密钥列表。该方法支持自定义优先费用级别，分为六个百分位数：min, low, medium, high, very high, 和 unsafe max. 中位数（第 50 百分位）被设定为默认建议。费用是使用最近 50 个槽的数据计算的。

{
 "jsonrpc": "2.0",
 "id": "helius-example",
 "method": "getPriorityFeeEstimate",
 "params": [
   {
     "transaction": "LxzhDW7T...", // Base58 编码的序列化交易
     "options": {
       "recommended": true
     }
   }
 ]
}

以上：使用 Base58 编码的序列化交易的 getPriorityFeeEstimate 示例负载。

由于没有确定性的方法来计算优先费用，开发者通常采取谨慎的方法，通过超额支付来确保他们的交易被处理。或者，他们可能会过度使用 Jito 小费，即使在不需要确保区块顶部的交易中。这些小费通常被用作优先费用的替代品。值得注意的是，2024 年观察到的大多数小费与传统的 MEV 活动无关，例如套利或夹击 ，而是旨在实现更快的交易包含。验证者通过收取更高的区块奖励和 MEV 佣金来获得这种低效的收益。

当开发者未能实现逻辑以动态调整其优先费用以应对链上条件波动时，另一个挑战就出现了。在重大事件（如市场大幅波动）期间，访问特定状态账户的费用可能会急剧飙升。缺乏动态费用机制的应用程序在这些情况下将面临困难，因为其静态费用设置不足以确保及时执行。

提出的解决方案

已经提出了各种策略，以进一步增强 Solana 的费用结构。这些提案旨在优化网络资源分配并减轻垃圾邮件的激励。

指数写锁费用

由 Tao Zhu (Anza) 和 Anatoly Yakavenko 于 2023 年 1 月提出的 SIMD-0110 提出了通过对有争议账户施加动态费用来管理拥堵的新机制。该机制跟踪写锁定账户的计算单元 (CU) 利用率的指数移动平均 (EMA)，并提高持续高利用率的写锁定账户的费用。

为了实现这样的系统，Solana 运行时维护一个有争议账户的公共密钥的 LRU（最近最少使用）缓存及其相应的计算单元定价器 (CUP)。CUP 监控账户的 EMA CU 利用率，并在查询时提供更新的费用率。

该机制动态调整写锁费用。如果账户的 EMA CU 利用率超过目标阈值，则写锁费用率增加。相反，如果利用率低于目标，则费用率降低。初始参数包括：

• 账户最大 CU 限制的 25% 的目标利用率。
• 初始写锁费用率为每 CU 1,000 微拉波特。
• 每个区块的费用调整率为 1%。

账户的写锁费用通过将其费用率乘以交易请求的 CU 来计算。在该系统下，总交易费用是三个组成部分的总和：基本签名费用、优先费用和写锁费用。写锁费用将 100% 被销毁。

在发布时，SIMD-0110 在社区内引发了热烈的讨论。然而，该提案目前处于非活跃状态，并已标记为关闭。

动态基本费用

改善 Solana 的 LFM 的另一个长期解决方案是引入全球和每个账户的动态基本费用 (DBF)。Ellipsis Labs 的 Jarry Xiao 和 Eugene Chen 是这一方法的著名支持者 。

虽然优先费用是可选的，但基本费用是强制性的。目前，Solana 的基本费用固定为每个签名 5000 拉波特。提交简单代币转账的用户支付的基本费用与进行复杂多场所交换或试图执行复杂 MEV 套利的搜索者支付的基本费用相同。基本费用并未准确反映交易的计算使用情况。

通过动态基本费用，具有不当基本费用的套利交易可以被视为无效，并在到达调度器之前被丢弃。提高基本费用会鼓励垃圾邮件发送者发送更少的交易。

基本费用最终将达到均衡，交易将根据区块空间市场的价值定价。由于基本费用在上升，最终将达到边际成本，此时发送交易不再值得交易的机会成本。费用不能过高；否则，用户活动将受到影响。对于机器人来说，过高的最大值但对用户普遍可接受是理想的。在这样的系统下，为了包含而发送交易的账户将烧掉他们所有的 SOL。

Solana 的快速区块时间使得激进的算法能够设定基本费用。在高需求期间，费用可以迅速调整——每个区块可能翻倍——以反映网络拥堵。相反，随着需求的减少，费用可以更逐渐地降低。由于 Solana 的短区块时间，费用减少仍然相对迅速，确保网络快速适应变化的条件。

类似的经济反压力的例子是 Metaplex Candy Machine 程序 ，该程序在 2022 年作为反垃圾邮件机制实施了机器人税。机器人税是对无效交易的可选收费。通常，这将是一个相对较小的金额，以避免影响真正的用户，他们可能犯了一个真正的错误。这个税收证明是有效的；铸造狙击手很快被耗尽，垃圾邮件也停止了。

结论

Solana 的 LFM 是功能性的，但仍有很大的改进空间：

• 增强优先费用机制： 优先费用 RPC 调用需要改进。理想情况下，开发者应该有一种简单、确定性的方法来设置费用，以确保交易在接下来的几个区块内被包含。
• 经济上抑制垃圾邮件： 网络必须找到在高经济活动期间对机器人施加经济反压力的方法，同时保持对真正人类用户的低费用。
• 教育开发者： 开发者需要停止设置静态应用程序交易费用，并减少对 Jito 等协议外机制的依赖，以进行常规交易。
• 进一步优化调度器： 交易调度器需要进一步优化，以确保在高需求期间所有工作线程都得到利用。

正如 Solana 联合创始人 Anatoly Yakovenko 所指出的，这些挑战主要是“工程问题”——通过适当的技术关注可以解决。

其他资源

• Solana Fees, Part 1 - Umbra Research
• Toward Multidimensional Solana Fees - Umbra Research
• Local Fee Markets are Necessary to Scale Ethereum - Eclipse Labs
• Solana's Local Fee Markets Aren't Real | Eugene Chen - Lightspeed Podcast
• Solana Banking Stage and Scheduler - A.Fitzgerald