Solana资源费草案会改变什么？

“Solana要让资源大户多付费”是一句方向正确但容易误导的概括。SIMD-0553仍是草案，它重写的不是单一价格，而是费用由什么组成、哪部分给验证者、哪部分被燃烧，以及应用应按实际消耗还是请求上限做预算。上线判断必须从提案状态和特性门开始。

第一行先写Draft，而不是已经涨价

SIMD-0553当前状态为Draft，不能把提案规则写成主网已全面生效。

SIMD是协议改进文件，不是主网状态公告。即使代码里出现特性ID，也要确认目标集群、bank所在epoch及特性是否激活。钱包或媒体若把示例费率直接展示成“当前费率”，会让用户在尚未启用的网络上得到错误账单。

草案把现有每签名5000 lamports费用拆为每笔2500 lamports基础纳入费与按请求成本计算、100%燃烧的资源费，优先费规则不变。

草案把基础纳入费设为每笔2500 lamports并全部给leader；优先费继续给leader；新增资源费按请求成本计算并全部燃烧。旧的每签名5000 lamports逻辑不能直接套在新公式上，多签交易、零优先费交易和计算密集交易的变化方向可能不同。

总费用应理解为基础纳入费加优先费加资源费，而不是“原费用再加一次燃烧”。费率变化影响的是资源费部分，优先费市场仍有独立波动。界面若只给一个总数，分析者也不能仅凭总数反推出燃烧额。

资源费率拟通过三个特性门分阶段采用每请求成本单位1/10、1/4和1/2 lamports，并在同一bank上取已激活的最高费率。

资源费依据执行前requested_cost_units而非实际消耗量；过宽的计算单元或加载账户数据上限会直接抬高费用。

requested_cost_units由签名、写锁、指令数据、请求的计算单元上限和请求的加载账户数据规模等组成。最重要的产品含义是：把Compute Unit Limit设得很宽，即使程序最后只消耗一小部分，也可能按更大的请求成本付资源费。

因此“仿真成功”不等于“费用已经优化”。发送器要记录模拟消耗、加安全余量、再次估费，并在程序或账户集合改变时重做预算。固定写死一个极高上限虽然减少计算不足失败，却可能成为持续成本。

草案设计1/10、1/4、1/2 lamports每请求成本单位的三个特性门，按阶段观察影响。同一客户端同时识别多个已激活门时使用有效的最高费率。跨epoch的仿真和发送如果落在不同bank，估计值可能变化，应用应允许重新报价。

不要把终局1/2费率乘在所有历史交易上做回测，也不要把提案示例中的某类swap当作所有同类交易的固定涨幅。账户写锁、请求上限、签名数和优先费都会改变结果。

第一，确认客户端版本能识别全部特性门；第二，保存当前交易样本的请求成本与总费；第三，在相同bank上用getFeeForMessage或simulateTransaction重算；第四，收紧Compute Budget并保留失败回退；第五，在epoch边界和费率阶段切换时做回归测试。

收费不足错误不能只提示“余额不够”。产品应展示此次估费所用区块、费率阶段和安全余量，并允许用户在交易内容不变时重新估计。后台则分别监控费用估算失败、预检失败和链上实际费用偏差。

总费估算可参考getFeeForMessage费用估算，优先费样本口径见getRecentPrioritizationFees闭环，模拟边界见Solana模拟成功仍失败。三者解决估价、优先费参考和执行不确定性，不能互相替代。

本文只解读SIMD-0553草案，不预测激活时间，也不构成SOL价格或交易建议。真正发送前，以目标集群的当前特性状态、RPC返回和钱包最新版本为准。

资料访问时间为2026-08-14。仍需保留的边界：特性门的实际激活时间和最终参数仍可能变化；发布时只将其写作草案并要求检查当前集群状态。