尧图网页设计 
Solana 状态验证交易费用机制State-Validation Transaction Fees 的经济设计与 FeeRateGovernor 实现【免费下载链接】solanaWeb-Scale Blockchain for fast, secure, scalable, decentralized apps and marketplaces.项目地址: https://gitcode.com/GitHub_Trending/so/solana本文围绕 Solana 早期经济设计ED提案中的「状态验证交易费用」文档展开讲解 Solana 为何要为每笔状态验证交易强制收取费用、费用如何按固定比例销毁burn、以及如何通过类难度调整的拥塞驱动机制动态调节最低费用。结合仓库中 fee_calculator.rs 与 fee_distribution.rs 的源码读者可以掌握该费用模型从协议经济学到运行时落地的完整链路。交易费用的经济作用Solana 的早期经济设计文档 State-validation Transaction Fees 开宗明义每笔通过网络发送、由当前 leader 验证客户端validation-client处理并确认为全局状态交易的交易都必须携带交易费用。文档列举了费用在 Solana 经济设计中的四重价值资源补偿为验证者网络提供单位补偿覆盖处理状态交易所需的 CPU/GPU 资源成本抑制垃圾交易通过引入真实的经济成本来减少网络层面的 spam激励交易市场为交易市场开辟空间激励验证客户端在担任 leader 时积极收集并处理已提交的交易长期经济稳定通过协议层面捕获的每笔交易最低费用为网络提供潜在长期经济稳定这也是下文费用销毁机制的基础。这一设计与多数区块链经济形成对照。文档指出比特币、以太坊等当前的区块链经济在短期内依赖协议奖励protocol-based rewards支撑经济运转并假设交易费用产生的收入将在协议奖励结束后长期支撑经济。Solana 的取向是让协议奖励 交易费用共同构成可持续经济每笔交易费用中固定的一部分被销毁剩余部分归当前处理该交易的 leader而一个按计划的全局通胀率则作为奖励来源按前述流程分配给验证客户端。拥塞驱动费用类难度调整的费用调节器文档的第二部分将费用定价交给网络的拥塞状态来决定交易费用由集群基于最近的历史吞吐量设定且费用中协议捕获的最低部分可以根据历史 gas 使用情况动态调整。其控制逻辑可以概括为协议指定一个期望的 gas 用量目标target usage持续监测实际 gas 用量相对目标的偏差用量偏高则调高最低费用用量偏低则调低最低费用费用变化反过来压制/抬高每块的 gas 用量直至回归目标——目标是让交易处理硬件的利用率被引导到一个期望水平。文档明确把这一过程类比为比特币的难度调整算法difficulty adjustment只不过调节对象是最低交易费用而非出块难度。在源码中这一拥塞驱动机制由 FeeRateGovernor 结构体承载字段与文档描述一一对应字段含义源自源码注释lamports_per_signature当前每个签名的费用可随集群处理负载上下浮动运行时动态字段#[serde(skip)]target_lamports_per_signature当集群吞吐接近target_signatures_per_slot时期望的每签名费用target_signatures_per_slot用于估计集群期望处理容量的签名目标值低于/高于该值时费用下/上调取 0 则禁用动态调整min_lamports_per_signature/max_lamports_per_signature动态费用的上下界burn_percent收取的费用中被销毁的比例以 100 为分母的百分比默认值定义在 fee_calculator.rsDEFAULT_TARGET_LAMPORTS_PER_SIGNATURE 10_000目标每签名 10,000 lamportsDEFAULT_TARGET_SIGNATURES_PER_SLOT 50 * DEFAULT_MS_PER_SLOT即按每毫秒 50 个签名的目标吞吐量乘以默认 slot 时长DEFAULT_BURN_PERCENT 50默认销毁 50% 的交易费用——正是文档中固定比例销毁的具体实现。费用如何随拥塞变化看 new_derived() 的调节算法当target_signatures_per_slot 0时费用被约束在目标值的50%1000%区间内min max(1, target/2)max target * 10先按最近一个 slot 的实际签名数线性外推期望费用再与当前费用比较得到 gapgap 为零时直接到位否则每次只朝目标移动目标费用的 5%target_lamports_per_signature / 20以实现文档所说的平滑、渐进的费用升降当target_signatures_per_slot 0时退化为固定费用min/max 均等于目标值。此外FeeCalculator结构体fee_calculator.rs保存lamports_per_signature即单笔交易计费所需的每签名单价其上的calculate_fee()方法已在 1.9.0 起标记为 deprecated说明旧版按签名数计费的入口已退出主线计费语义收敛到由治理器导出的每签名单价。固定比例销毁防止避税攻击文档第三部分解释了销毁burn比例的意图一方面保留 leader 尽可能在 leader-slot 时间内塞入更多交易的激励另一方面提供一个限制通胀的机制抵御税 evasion攻击即通过侧信道私下支付费用来绕过协议捕获的费用部分原文引用 ed_references.md 中的外部文献说明该攻击背景。运行时对该设计的实现见 runtime/src/bank/fee_distribution.rs 的distribute_transaction_fees()读取本 slot 累计的collector_fees调用fee_rate_governor.burn(collector_fees)把总费用拆分为(deposit, burn)两部分。拆分逻辑在 FeeRateGovernor::burn()burned fees * burn_percent / 100返回(fees - burned, burned)——与DEFAULT_BURN_PERCENT 50配合即各占一半将 deposit 部分记入collector_id即当前 leader的账户并写入RewardType::Fee类型的奖励记录无论成功与否销毁部分都会通过self.capitalization.fetch_sub(burn, ...)从总资本化全网络 lamport 总量中扣除真正完成销毁若向 leader 账户注资失败账户 owner 非法、rent 状态不允许、lamport 溢出等见 deposit_fees() 中的DepositFeeError分支deposit 部分也会被追加到 burn 中一并销毁并打bank-burned_fee指标告警——保证任何情况下未发给 leader 的费用都不会滞留或回流。文件内注释同样呼应文档的激励设计每个验证者因 leader 机会由 stake 加权调度公平轮换而产生赚取费用的机会多处理交易 多赚费用而缺席 leader slot 则无所得因此在线性本身也被费用间接激励。该流程有完整测试佐证位于 fee_distribution.rs 的 tests 模块test_distribute_transaction_fees正常注资、非法 owner、rent-paying 三种场景下验证 deposit/burn 拆分与capitalization扣减test_distribute_transaction_fees_burn_all将burn_percent设为 100 时全部费用被销毁、无任何奖励发放、总量精确减少test_distribute_transaction_fees_overflow_failureleader 账户余额为u64::MAX时注资溢出费用整体转为销毁。销毁费用与分支选择对审查型 leader 的惩罚文档最后一部分将销毁机制延伸到了共识层销毁的费用可以作为分支选择fork selection的考量。设想一个 PoH 分叉上出现恶意的、审查censoringleader 的场景由于被审查交易的费用损失恶意分叉上总销毁费用会低于可对比的诚实分叉。如果审查型 leader 想弥补这部分丢失的协议费用就必须用自己的资金在自己分叉上垫付被销毁的费用——这本身就削弱了其进行审查的动机。从文档表述看这是一个利用费用销毁在分叉竞争中天然歧视审查行为的机制使诚实出块在经济学上比审查出块更划算。小结从设计文档到运行时的映射文档概念仓库中的实现位置每笔交易强制携带费用、剩余部分归 leaderruntime/src/bank/fee_distribution.rs 中distribute_transaction_fees()向collector_id注资拥塞驱动的最低费用动态调节类难度调整sdk/program/src/fee_calculator.rs 中FeeRateGovernor::new_derived()的 5% 平滑步进算法固定比例销毁默认 50%FeeRateGovernor::burn()与DEFAULT_BURN_PERCENT销毁通过capitalization扣减完成销毁费用进入分支选择考量早期 ED 设计文档中的经济论证该文档标注 Subject to change属设计期提案需要说明的前提该文档属于 Solana 的早期经济设计ED提案目录文首标注Subject to change其中validation-client等术语为当时的命名与后来实现中的 validator/Bank 体系相对应拥塞驱动费用与费用销毁两项核心机制已在上述源码中落地。此外原文档指向的transaction-fees.mdCongestion Driven Fees 章节在当前仓库的 docs/src 目录下已不存在其内容思想对应即FeeRateGovernor的实现阅读时以源码为准。【免费下载链接】solanaWeb-Scale Blockchain for fast, secure, scalable, decentralized apps and marketplaces.项目地址: https://gitcode.com/GitHub_Trending/so/solana创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Solana 状态验证交易费用机制：State-Validation Transaction Fees 的经济设计与 FeeRateGovernor 实现
Solana 状态验证交易费用机制State-Validation Transaction Fees 的经济设计与 FeeRateGovernor 实现【免费下载链接】solanaWeb-Scale Blockchain for fast, secure, scalable, decentralized apps and marketplaces.项目地址: https://gitcode.com/GitHub_Trending/so/solana本文围绕 Solana 早期经济设计ED提案中的「状态验证交易费用」文档展开讲解 Solana 为何要为每笔状态验证交易强制收取费用、费用如何按固定比例销毁burn、以及如何通过类难度调整的拥塞驱动机制动态调节最低费用。结合仓库中 fee_calculator.rs 与 fee_distribution.rs 的源码读者可以掌握该费用模型从协议经济学到运行时落地的完整链路。交易费用的经济作用Solana 的早期经济设计文档 State-validation Transaction Fees 开宗明义每笔通过网络发送、由当前 leader 验证客户端validation-client处理并确认为全局状态交易的交易都必须携带交易费用。文档列举了费用在 Solana 经济设计中的四重价值资源补偿为验证者网络提供单位补偿覆盖处理状态交易所需的 CPU/GPU 资源成本抑制垃圾交易通过引入真实的经济成本来减少网络层面的 spam激励交易市场为交易市场开辟空间激励验证客户端在担任 leader 时积极收集并处理已提交的交易长期经济稳定通过协议层面捕获的每笔交易最低费用为网络提供潜在长期经济稳定这也是下文费用销毁机制的基础。这一设计与多数区块链经济形成对照。文档指出比特币、以太坊等当前的区块链经济在短期内依赖协议奖励protocol-based rewards支撑经济运转并假设交易费用产生的收入将在协议奖励结束后长期支撑经济。Solana 的取向是让协议奖励 交易费用共同构成可持续经济每笔交易费用中固定的一部分被销毁剩余部分归当前处理该交易的 leader而一个按计划的全局通胀率则作为奖励来源按前述流程分配给验证客户端。拥塞驱动费用类难度调整的费用调节器文档的第二部分将费用定价交给网络的拥塞状态来决定交易费用由集群基于最近的历史吞吐量设定且费用中协议捕获的最低部分可以根据历史 gas 使用情况动态调整。其控制逻辑可以概括为协议指定一个期望的 gas 用量目标target usage持续监测实际 gas 用量相对目标的偏差用量偏高则调高最低费用用量偏低则调低最低费用费用变化反过来压制/抬高每块的 gas 用量直至回归目标——目标是让交易处理硬件的利用率被引导到一个期望水平。文档明确把这一过程类比为比特币的难度调整算法difficulty adjustment只不过调节对象是最低交易费用而非出块难度。在源码中这一拥塞驱动机制由 FeeRateGovernor 结构体承载字段与文档描述一一对应字段含义源自源码注释lamports_per_signature当前每个签名的费用可随集群处理负载上下浮动运行时动态字段#[serde(skip)]target_lamports_per_signature当集群吞吐接近target_signatures_per_slot时期望的每签名费用target_signatures_per_slot用于估计集群期望处理容量的签名目标值低于/高于该值时费用下/上调取 0 则禁用动态调整min_lamports_per_signature/max_lamports_per_signature动态费用的上下界burn_percent收取的费用中被销毁的比例以 100 为分母的百分比默认值定义在 fee_calculator.rsDEFAULT_TARGET_LAMPORTS_PER_SIGNATURE 10_000目标每签名 10,000 lamportsDEFAULT_TARGET_SIGNATURES_PER_SLOT 50 * DEFAULT_MS_PER_SLOT即按每毫秒 50 个签名的目标吞吐量乘以默认 slot 时长DEFAULT_BURN_PERCENT 50默认销毁 50% 的交易费用——正是文档中固定比例销毁的具体实现。费用如何随拥塞变化看 new_derived() 的调节算法当target_signatures_per_slot 0时费用被约束在目标值的50%1000%区间内min max(1, target/2)max target * 10先按最近一个 slot 的实际签名数线性外推期望费用再与当前费用比较得到 gapgap 为零时直接到位否则每次只朝目标移动目标费用的 5%target_lamports_per_signature / 20以实现文档所说的平滑、渐进的费用升降当target_signatures_per_slot 0时退化为固定费用min/max 均等于目标值。此外FeeCalculator结构体fee_calculator.rs保存lamports_per_signature即单笔交易计费所需的每签名单价其上的calculate_fee()方法已在 1.9.0 起标记为 deprecated说明旧版按签名数计费的入口已退出主线计费语义收敛到由治理器导出的每签名单价。固定比例销毁防止避税攻击文档第三部分解释了销毁burn比例的意图一方面保留 leader 尽可能在 leader-slot 时间内塞入更多交易的激励另一方面提供一个限制通胀的机制抵御税 evasion攻击即通过侧信道私下支付费用来绕过协议捕获的费用部分原文引用 ed_references.md 中的外部文献说明该攻击背景。运行时对该设计的实现见 runtime/src/bank/fee_distribution.rs 的distribute_transaction_fees()读取本 slot 累计的collector_fees调用fee_rate_governor.burn(collector_fees)把总费用拆分为(deposit, burn)两部分。拆分逻辑在 FeeRateGovernor::burn()burned fees * burn_percent / 100返回(fees - burned, burned)——与DEFAULT_BURN_PERCENT 50配合即各占一半将 deposit 部分记入collector_id即当前 leader的账户并写入RewardType::Fee类型的奖励记录无论成功与否销毁部分都会通过self.capitalization.fetch_sub(burn, ...)从总资本化全网络 lamport 总量中扣除真正完成销毁若向 leader 账户注资失败账户 owner 非法、rent 状态不允许、lamport 溢出等见 deposit_fees() 中的DepositFeeError分支deposit 部分也会被追加到 burn 中一并销毁并打bank-burned_fee指标告警——保证任何情况下未发给 leader 的费用都不会滞留或回流。文件内注释同样呼应文档的激励设计每个验证者因 leader 机会由 stake 加权调度公平轮换而产生赚取费用的机会多处理交易 多赚费用而缺席 leader slot 则无所得因此在线性本身也被费用间接激励。该流程有完整测试佐证位于 fee_distribution.rs 的 tests 模块test_distribute_transaction_fees正常注资、非法 owner、rent-paying 三种场景下验证 deposit/burn 拆分与capitalization扣减test_distribute_transaction_fees_burn_all将burn_percent设为 100 时全部费用被销毁、无任何奖励发放、总量精确减少test_distribute_transaction_fees_overflow_failureleader 账户余额为u64::MAX时注资溢出费用整体转为销毁。销毁费用与分支选择对审查型 leader 的惩罚文档最后一部分将销毁机制延伸到了共识层销毁的费用可以作为分支选择fork selection的考量。设想一个 PoH 分叉上出现恶意的、审查censoringleader 的场景由于被审查交易的费用损失恶意分叉上总销毁费用会低于可对比的诚实分叉。如果审查型 leader 想弥补这部分丢失的协议费用就必须用自己的资金在自己分叉上垫付被销毁的费用——这本身就削弱了其进行审查的动机。从文档表述看这是一个利用费用销毁在分叉竞争中天然歧视审查行为的机制使诚实出块在经济学上比审查出块更划算。小结从设计文档到运行时的映射文档概念仓库中的实现位置每笔交易强制携带费用、剩余部分归 leaderruntime/src/bank/fee_distribution.rs 中distribute_transaction_fees()向collector_id注资拥塞驱动的最低费用动态调节类难度调整sdk/program/src/fee_calculator.rs 中FeeRateGovernor::new_derived()的 5% 平滑步进算法固定比例销毁默认 50%FeeRateGovernor::burn()与DEFAULT_BURN_PERCENT销毁通过capitalization扣减完成销毁费用进入分支选择考量早期 ED 设计文档中的经济论证该文档标注 Subject to change属设计期提案需要说明的前提该文档属于 Solana 的早期经济设计ED提案目录文首标注Subject to change其中validation-client等术语为当时的命名与后来实现中的 validator/Bank 体系相对应拥塞驱动费用与费用销毁两项核心机制已在上述源码中落地。此外原文档指向的transaction-fees.mdCongestion Driven Fees 章节在当前仓库的 docs/src 目录下已不存在其内容思想对应即FeeRateGovernor的实现阅读时以源码为准。【免费下载链接】solanaWeb-Scale Blockchain for fast, secure, scalable, decentralized apps and marketplaces.项目地址: https://gitcode.com/GitHub_Trending/so/solana创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考