Solana 本地费用市场的真相

可付诸行动的见解

• 本地费用市场（LFM）让 Solana 能够根据争用程度，为各个状态设置细粒度费用。交易根据其写入的特定状态支付费用，避免局部热点抬高整个区块链的费用。 
• LFM 对实现 Solana 的愿景至关重要：打造一个可扩展的统一基础层，让所有应用无缝共存。如果没有 LFM，链上某一部分的费用飙升会导致所有交易的费用上涨——这种问题在完全依赖全局费用市场为区块空间定价的其他网络中十分常见。
• 随着 Solana 上的经济活动在 2023 年末开始加速，LFM 初始实现中的几个关键缺陷逐渐显现，其中最突出的是调度器优先级排序不具确定性。交易主要按抵达区块构建者的时间排序，优先费仅作为次要考量。
• 2024 年 5 月发布 Agave 客户端 v1.18 更新时，引入了新的交易调度器和改进后的交易优先级公式。该调度器构建依赖关系图，以更好地管理各线程之间冲突交易的处理和优先级排序。这项重大更新显著提升了协议以确定性方式对交易排序的能力。
• 评估 LFM 是否有效运行的一项重要指标，是比较交易优先费的中位数和平均值。涉及无争用状态的费用（第 50 百分位中位数）应保持在较低水平。随着需求增加，争用状态的费用应大幅上涨，并拉高平均值。近期数据证实了这一模式。2024 年 11 月，非投票交易的平均费用创下历史新高，超过 0.0003 SOL。但费用中位数稳定在 0.00000861 SOL，约低 35 倍。
• 如今，Solana 的 LFM 已经可以运行，但仍有很大的改进空间。Anza 工程师对 banking stage 线程工作负载的分析表明，一个调度器 bug 阻止验证者客户端充分利用其全部容量。因此，Agave 客户端只能发挥一小部分潜力。此外，目前还没有关于交易应如何排序的正式规范。
• 当前的优先费 API 不够完善，无法为开发者提供确定性结果。每家主要 RPC 提供商都有自己的定制优先费 API，这可能形成一种软性的供应商锁定。核心开源 RPC API 实现没有考虑 Jito 的影响等关键网络动态，导致费用估算不准确。
• 由于缺乏计算优先费的确定性方法，开发者通常会采取谨慎策略，通过超额付费来确保交易得到处理。或者，他们可能过度使用 Jito 小费作为替代机制，即使交易并不需要抢占区块顶部位置。
• 为进一步改进 Solana 的费用结构，人们提出了多种策略，包括指数写锁费用和动态基础费。网络仍需找到既能通过经济反压遏制垃圾交易，又能为真实用户维持低费用的方法。

简介

费用市场是一种经济机制，通过动态调整交易费用，将稀缺的区块空间高效分配给价值最高的交易。交易愿意支付的费用可作为其价值的衡量指标。LFM 在这一通用概念的基础上进一步细化，根据争用程度为各个状态设置细粒度费用。当两笔交易访问相同状态时——无论是都写入同一账户，还是一笔读取、一笔写入同一账户——就会产生争用。

借助 LFM，交易根据其写入的特定状态支付费用，避免局部热点抬高整个区块链的费用。访问高需求或争用状态的交易费用较高，而与需求较低的状态交互的交易费用较低。这一点很重要，因为得益于并行执行，Solana 能更好地处理无争用交易。

相比之下，全局费用市场对访问网络状态收取统一费用，这意味着无论交易与哪些账户交互，所有交易都会平等竞争是否被纳入区块。EIP-1559 中实现的 Ethereum 费用模型是全局费用市场的典型例子。EIP-1559 根据网络需求调整动态基础费，以维持每个区块的最佳计算（gas）使用量。随着区块容量被填满，所有交易的费用都会上涨。钱包根据当前基础费和交易的 gas 上限计算费用。这种方法由协议强制执行，费用计算可预测；但它无法将高需求热点与整个网络隔离开来。一旦费用飙升，影响的是所有交易。

对特定状态的高需求并非区块链独有的问题。这一挑战类似于 Web2 社交应用中常见的热点键问题，也经常被称为“名人问题”。

本文旨在以通俗易懂的方式分析 Solana 的 LFM。全文分为以下几个部分：

• **Solana 费用基础：**帮助读者建立对 Solana 当前交易处理方式的基本认识。
• **本地费用市场的早期问题：**探讨 LFM 早期实现中的初始问题及其不足。
• **中央调度器 v.1.18 更新：**重点介绍 2024 年的一项关键更新，该更新显著改善了 LFM 的功能。
• **衡量本地费用市场的有效性：**提供有助于了解 LFM 当前在 Solana 上运行状况的数据。
• **持续存在的问题和改进领域：**讨论尚未解决的问题，以及 LFM 要充分发挥潜力仍需关注的领域。
• **提议的解决方案：**评估用于完善 LFM 的提议方案，并引入更好的经济激励，以实现更精细的区块空间定价。

已经熟悉 Solana 交易费用结构的读者可以跳过下面的费用基础部分。

Solana 费用基础

Solana 交易包含两种费用——基础费和优先费。目前，基础费固定为每个签名 5,000 lamports。大多数 Solana 交易只有一个签名。优先费以每个请求计算单元（CU）对应的 microlamports（即百万分之一 lamport）计价。费用从费用支付者账户（签名者）中扣除。如果支付者没有足够的 lamports 支付交易费用，交易将被丢弃。在撰写本文时，基础费和优先费各有 50% 由区块构建者保留，作为将交易纳入区块的激励，另外 50% 则被销毁。随着去年 5 月提案 SIMD-096 的治理投票成功通过，这一比例将改为区块构建者保留 100% 的优先费。例如： 

一笔交易有一个签名，并请求 500,000 CU。发送者将优先费设为每个请求 CU 50,000 microlamports。该交易的总费用为 5,000 lamports +（500,000 个请求 CU * 每个请求 CU 50,000 microlamports）= 25,000 lamports，即 0.000025 SOL。

验证者的计算资源有限，协议将每个区块的总计算资源限制为 4,800 万 CU。这个数值是根据验证者在合理情况下能够处理的工作量，通过经验确定的，以实现 400 毫秒的出块时间。每个账户在每个区块中的 CU 上限为 1,200 万，每笔交易的最大计算量设为 140 万 CU。交易消息的最大大小也限制为 1,232 字节，即 IPv6 的最小传输单元（1280 字节）减去标头。

为防止计算资源被滥用，Solana 上的每笔交易都会分配一个计算预算。默认情况下，网络将每条指令的最大上限设为 200,000 个计算单元（CU）。不过，交易可以通过加入 `SetComputeUnitLimit` 指令指定自定义计算单元上限，从而更高效地分配资源。Agave 客户端代码库列出了各种操作的 CU 成本。

Solana 要求所有交易完整列出交易期间将读取或写入的账户地址。该列表最多可包含 35 个地址，并且可以通过链上地址查找表扩展。构建地址列表会增加开发者的额外工作，但这是释放 Solana 诸多优化能力的关键，包括并行执行交易和本地费用市场。

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

随着 Solana 上的经济活动在 2023 年末开始加速，LFM 初始实现中的几个关键缺陷逐渐显现。大约在同一时期，Ellipsis Labs 的 Eugene Chen 在 Umbra Research 文章《Solana 费用，第一部分》中全面分析了这些挑战。以下是 Chen 所提要点的总结。

缺乏准确请求 CU 的激励

Solana 的费用结构按签名收取基础费，不考虑实际使用或请求的计算单元（CU）。与此同时，在拥堵期间，优先费只能提供有限的激励来促使交易减少 CU 用量。这种设计让交易发送者几乎没有动力优化计算用量，或使其 CU 请求与实际需求相符。因此，交易经常会过量请求 CU，降低网络调度流程的效率。

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

销毁 50% 的优先费，会激励交易发送者通过与区块构建者合谋并安排链下付款来获得优先访问，从而绕过协议。Jito 拍卖使用量的增长清楚体现了这种行为。运行 Jito-Agave 客户端的验证者能够获得更高的费用收入，并可通过 Jito MEV 佣金奖励将这些利润高效分配给委托质押者。随着 Jito-Agave 客户端的采用率上升，Jito bundle 已在许多场景中证明自己是更优的交易交付服务。 

非确定性的调度器优先级排序

Solana 的共识和调度器都没有根据优先费强制执行严格的交易排序。交易主要按抵达区块构建者的时间排序，优先费仅作为次要考量。更高的优先费可以提高涉及争用状态的交易被纳入区块的可能性，但排序过程仍不具确定性。交易到达交易处理单元（TPU）前的网络抖动，以及调度器内部的抖动，都会进一步增加不可预测性。

这种非确定性降低了交易执行的可预测性和可靠性，促使用户用大量垃圾交易淹没网络，以提高交易更快被纳入区块的概率。然而，当优先费超过某个阈值后，继续提高费用的回报会递减，削弱其作为改善交易位置机制的有效性。Solana 的共享区块空间最终沦为经典的“公地悲剧”。各参与者为追求自身利益，导致这一公共资源被过度使用且效率低下。

中央调度器 v.1.18 更新

Agave 客户端调度器的初始实现只能粗略保证支付高额优先费的交易更有可能被纳入某个区块。领导者的交易处理单元（TPU）使用六个并行线程运行：四个处理非投票交易，两个保留用于投票交易。四个非投票交易线程分别维护自己的队列，传入交易在其中等待分组为条目以供执行。此前，交易会被随机分配到这些线程，各队列独立确定数据包的优先级，并不了解其他线程正在处理的数据包。

在该系统中，每个线程循环处理自己的队列，尝试锁定并执行交易。线程完成当前周期后，会收集更多数据包并重新开始这一过程。这种结构给优先费的有效使用带来了挑战。例如，一笔高优先级交易可能位于某个线程队列的顶部，而另一个线程却可能同时处理其队列末尾一笔涉及同一账户但优先费更低的交易。优先费只能影响单个线程内部（线程内）的交易排序，无法影响所有线程之间（线程间）的排序。因此，每个队列都采用一种混合排序机制，将先进先出（FIFO）处理与优先费考量相结合，但线程之间没有强制执行全局排序。

当线程准备执行一笔交易时，必须先获取所需的账户锁。如果必要的写锁不可用，交易将被重新加入队列。交易随机分配到线程会进一步加剧这个问题，因为同一种交易在多线程调度系统中的位置可能各不相同。调度器的这种随机性会引入抖动，导致交易在区块中的位置出现变化。

2024 年 5 月发布的 Agave 客户端 v1.18 更新带来了新的交易调度器，也称中央调度器。在改进后的结构中，中央调度器会构建一种称为 prio-graph 的依赖关系图，以更好地管理所有线程之间冲突交易的处理和优先级排序。这项重大更新显著提升了 Solana 以确定性方式对交易排序的能力；优先费更高的交易更有可能被纳入区块。

prio-graph 是一种有向无环图（DAG），会随着新交易的加入而动态更新。交易在图中组织成按时间优先级顺序处理的执行链。对于冲突交易，优先费决定插入顺序。这种方法可以最大限度减少锁争用，让批量交易顺畅执行，并减少资源冲突引起的延迟。交易预编译验证已转移到工作线程，以提升性能并实现更高效的处理。 

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

如需进一步了解中央调度器，读者可以参阅我们之前介绍 Agave 1.18 更新的 Helius 博客文章。

更有效的优先级计算

在更新调度器的同时，交易优先级公式也得到改进，让计算需求较低的交易更具优势，使开发者和资源用量较少的交易从中受益。 

修订后的公式如下：

优先级 =（优先费 * 请求的计算单元）+ 基础费 / 

（1 + 请求的执行 CU + 签名 CU + 写锁 CU）

这一新计算方式纳入了与交易相关的所有计算和运营成本，确保优先级准确反映实际资源消耗。因此，无需额外优先费的简单代币转账或原生 SOL 交易也能保证在队列中拥有基础优先级。对于更复杂的交易，与使用 `SetComputeUnitLimit` 指令指定自定义 CU 上限的开发者相比，忽略这一设置的开发者在交易优先级排序中会处于劣势。

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

本节将研究与 Solana LFM 相关的数据。 

交易费用中位数与平均值

在有效运行的 LFM 中，涉及无争用状态的交易（例如简单的稳定币转账）费用应保持在较低水平。与此同时，访问争用状态的交易（例如投机性的低流动性代币）费用应随着需求大幅上涨。评估这一动态的重要指标，是比较交易优先费的中位数和平均值。费用中位数代表第 50 百分位用户支付的费用，反映典型成本；平均费用则是所有费用除以交易总数，用于呈现整体趋势。

近期数据证实了这一预期模式。2024 年 11 月，Solana 上的经济活动达到当时的历史最高水平，非投票交易的平均费用创下历史新高，超过 0.0003 SOL。尽管如此，费用中位数仍稳定在 0.00000861 SOL，约低 35 倍。相比之下，2024 年 4 月类似的经济活动激增曾导致平均费用升至 0.0002 SOL 以上，费用中位数也相应升至 0.00001862 SOL，约低 10 倍。这种差异凸显了费用隔离的有效性：在高需求时期，它可以保护普通用户免受成本飙升的影响，并保障非投机用例的用户体验。

在分析基于 EVM 的网络（例如由 Coinbase 运营且没有 LFM 的 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 对 banking stage 线程工作负载进行的分析揭示了现有的低效之处和改进空间。

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

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

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

**QUIC 摄取线程：**当验证者担任领导者时，Tokio 线程通过 QUIC 协议管理交易摄取。在 2024 年初的拥堵期，这些线程曾是一个显著瓶颈。

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

这种行为表明，一个调度器 bug 阻止验证者客户端充分利用其全部容量。因此，系统只能发挥一小部分潜力。这意味着，如果该问题得到解决，验证者可处理的负载最高可达当前的四倍。

可观测性

当前用于估算交易能否如期上链的费用 API 不够完善，无法提供确定性结果。每家主要 RPC 提供商都有自己的定制优先费 API，而核心开源 RPC API 实现仍未达到最佳状态。它没有考虑 Jito 的影响等关键网络动态，导致费用估算不够准确。 

Helius 提供 `getPriorityFeeEstimate` RPC 方法，该方法基于全局费用市场和 LFM 的历史数据提供费用建议。开发者可以输入一笔经过序列化并签名的交易，也可以输入交易涉及的账户密钥列表。该方法支持自定义优先费级别，并分为六个百分位：最低、低、中、高、很高和不安全的最高值。默认建议为中等水平（第 50 百分位）。费用根据最近 50 个 slot 的数据计算。

{
 "jsonrpc": "2.0",
 "id": "helius-example",
 "method": "getPriorityFeeEstimate",
 "params": [
   {
     "transaction": "LxzhDW7T...", // Base58 encoded serialized transaction
     "options": {
       "recommended": true
     }
   }
 ]
}

上面是使用 base58 编码的序列化交易调用 getPriorityFeeEstimate 的示例 payload。

由于缺乏计算优先费的确定性方法，开发者通常会采取谨慎策略，通过超额付费来确保交易得到处理。或者，他们可能过度使用 Jito 小费，即使交易并不需要抢占区块顶部位置。这些小费经常被用作优先费的替代品。值得注意的是，2024 年观察到的大多数小费并不与套利或三明治攻击等传统 MEV 活动相关，而是为了让交易更快被纳入区块。验证者则从这种低效中获益，收取更高的区块奖励和 MEV 佣金。

另一个挑战是，开发者没有实现根据不断变化的链上状况动态调整优先费的逻辑。在市场大幅波动等重大事件期间，访问特定状态账户的费用可能急剧上涨。缺乏动态费用机制的应用在这些场景中会举步维艰，因为静态费用设置不足以确保及时执行。

提议的解决方案

为进一步改进 Solana 的费用结构，人们提出了多种策略。这些提案旨在优化网络资源分配，并减少发送垃圾交易的激励。

指数写锁费用

SIMD-0110 由 Tao Zhu（Anza）和 Anatoly Yakavenko 于 2023 年 1 月提出，建议采用一种新机制，通过对争用账户收取动态费用来管理拥堵。该机制跟踪被写锁账户的计算单元（CU）利用率指数移动平均值（EMA），并提高持续表现出高利用率的账户的写锁成本。

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

该机制会动态调整写锁费用。如果账户 CU 利用率的 EMA 超过目标阈值，写锁费率就会上升。反之，如果利用率低于目标，费率就会下降。初始参数包括：

• 目标利用率为账户 CU 上限的 25%。
• 初始写锁费率为每 CU 1,000 micro-lamports。
• 每个区块的费率调整幅度为 1%。

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

SIMD-0110 发布时曾在社区引发热烈讨论。不过，该提案目前已不再活跃，后来也被标记为已关闭。

动态基础费

改进 Solana LFM 的另一个长期解决方案，是引入全局和按账户计算的动态基础费（DBF）。Ellipsis Labs 的 Jarry Xiao 和 Eugene Chen 是这一方法的重要支持者。

优先费是可选的，但基础费是强制性的。目前，Solana 的基础费固定为每个签名 5000 lamports。提交简单代币转账的用户，与执行复杂多场所兑换的用户或尝试执行复杂 MEV 套利的搜索者，支付相同的基础费。基础费无法准确反映交易的计算用量。

采用动态基础费后，基础费设置不当的套利交易可被视为无效，并在到达调度器之前被丢弃。提高基础费会促使垃圾交易发送者减少交易数量。

基础费最终会达到均衡，交易将根据区块空间市场的价值定价。由于基础费持续上升，它最终会达到边际成本，此时发送交易所付出的机会成本将不再值得。费用不能过高，否则用户活动会受到影响。理想的上限应对机器人而言过高，但对用户而言通常可以接受。在这种系统下，通过垃圾交易争取被纳入区块的账户最终会烧光其所有 SOL。

Solana 极短的出块时间支持使用激进算法来设定基础费。在高需求期间，费用可以迅速调整——甚至可能每个区块翻倍——以反映网络拥堵状况。反之，随着需求下降，费用可以更缓慢地降低。得益于 Solana 较短的出块时间，费用仍能相对快速地下降，确保网络迅速适应不断变化的状况。

类似形式的经济反压机制是 Metaplex Candy Machine program，该 program 于 2022 年引入机器人税作为反垃圾交易机制。机器人税是针对无效交易收取的可选费用。通常，该费用会保持在合理的较低水平，以免影响真正出错的真实用户。这项税收被证明行之有效；铸造狙击机器人的资金很快被耗尽，垃圾交易也随之停止。

结论

Solana 的 LFM 已经可以运行，但仍有很大的改进空间：

• **增强优先费机制：**优先费 RPC 调用需要改进。理想情况下，开发者应能通过一种简单、确定性的方法设置费用，确保交易在接下来的几个区块内被纳入。
• **从经济上遏制垃圾交易：**网络必须找到方法，在经济活动高涨期间对机器人施加经济反压，同时为真实用户维持低费用。
• **帮助开发者建立正确认知：**开发者需要停止为应用交易设置静态费用，并减少在常规交易中对 Jito 等协议外机制的依赖。
• **进一步优化调度器：**交易调度器需要进一步优化，以确保在高需求期间利用所有工作线程。

正如 Solana 联合创始人 Anatoly Yakovenko 所指出的，这些挑战主要“只是工程问题”——只要投入适当的技术精力，就能解决。

更多资源

• Solana 费用，第一部分 - Umbra Research
• 迈向多维 Solana 费用 - Umbra Research
• 本地费用市场是扩展 Ethereum 的必要条件 - Eclipse Labs
• Solana 的本地费用市场并不真实 | Eugene Chen - Lightspeed Podcast
• Solana Banking Stage 与调度器 - A.Fitzgerald