一笔 Gas 费，最终去了哪里？

00 · Orientation

先建立一张不会混乱的费用地图

“Gas 很贵”把计量单位、单价、上限与最终支出揉在了一起。先把它们拆开。

本课主线：以太坊主网执行 Gas 的 EIP-1559 费用模型

Gas 是计算工作量的计量单位；Gas Fee 是为这些单位支付的 ETH。第七章第三课继续向下拆：每单位 Gas 的实际价格由什么组成，谁决定它，最终又分别去了哪里。

一句精确定义

对常见的 EIP-1559 动态费用交易，实际执行单价等于区块 Base Fee 加上交易的实际 Priority Fee； Base Fee 被协议销毁，Priority Fee 记入执行载荷指定的费用接收地址。^[2]

Quantity

Gas Used

程序实际消耗了多少计算单位。简单 ETH 转账通常是 21,000，复杂合约调用可能高得多。

Unit price

Gwei / Gas

每单位 Gas 付多少。Base Fee、Priority Fee、maxFeePerGas 都是“每 Gas 的价格”。

Settlement

ETH

最终支出。把实际用量乘以实际单价，再把 Gwei 换算为 ETH：10⁹ Gwei = 1 ETH。

先记住四个“不要等号”

最常见的概念错位
看起来相近	为什么不能画等号
`gasLimit` ≠ `gasUsed`	前者是允许执行消耗的上限，后者是结算时的实际用量。
`maxFeePerGas` ≠ 实际单价	它是用户愿意承担的单价天花板；实际单价通常更低。
`maxPriorityFeePerGas` ≠ 实际小费	它也是上限；当总费用上限空间不足时，实际小费会被压低。
转账金额 ≠ 交易费	`value` 给接收者；Gas Fee 为执行与区块空间付费，两条账分开。

学习边界

本页所有数字都是离线教学示例，不代表实时主网价格，也不是手续费建议。钱包通常会自动估算；手动调费前应先理解本课的两个上限。

01 · The bill

先拆开一张交易账单

费用不是一笔钱从用户直接转给验证者，而是一场有上限、有结算、有分流的状态转换。

假设 Alice 发出一笔动态费用交易：Gas Limit 为 80,000， maxFeePerGas = 42 Gwei， maxPriorityFeePerGas = 2 Gwei。它进入的区块 Base Fee 是 28 Gwei，执行后实际用了 51,420 Gas。

实际优先费 = min(2, 42 - 28) = 2 Gwei

实际单价 = 28 + 2 = 30 Gwei / Gas

实际总费用 = 51,420 × 30 Gwei = 0.00154260 ETH

用户付款能力 余额需覆盖 value 加上 gasLimit × maxFeePerGas

按实际执行结算 只对结算后的 Gas Used 乘以 Effective Gas Price

Base Fee 51,420 × 28 Gwei · 销毁

Priority Fee 51,420 × 2 Gwei · fee recipient

同一笔示例交易的完整资金视图
项目	公式	结果	性质
可承受的 Gas 最高额	80,000 × 42 Gwei	0.00336000 ETH	结算保障，不是最终收费
基础费销毁	51,420 × 28 Gwei	0.00143976 ETH	从流通供给中移除
实际优先费	51,420 × 2 Gwei	0.00010284 ETH	执行层费用收入
未成为支出的余量	最高额 - 实际总费用	0.00181740 ETH	来自未用 Gas 与未触及的价格上限

这 0.00181740 ETH 不是“协议奖励”或“隐藏退款”。它只是用户事先允许的最坏情形与最终情形之间的差：有些 Gas 没用完，实际每 Gas 的价格也没触及 42 Gwei。

02 · London

EIP-1559 到底改了什么？

它没有让区块空间变得不稀缺；它把“大家都猜一个总价”改成“协议门槛 + 用户小费上限”。

伦敦升级在 2021 年把 EIP-1559 费用市场带入以太坊。此前，传统交易主要填写一个 gasPrice，区块生产者倾向选择报价更高的交易，用户面对的是一场第一价格式竞价：出高了容易多付，出低了可能长时间排队。^[2]

Before · legacy bid

一个总报价

用户猜测每 Gas 愿意付多少；对下一块最低可接受价格缺少协议给出的公开锚点。钱包只能从近期市场行为推断。

After · EIP-1559

协议底价 + 两只上限

每块有可推导的 Base Fee；用户声明总单价上限和小费上限。实际结算无需把整个上限交出去。

它解决了什么，又没有解决什么？

EIP-1559 的能力边界
命题	结论	原因
让下一块基础费更可预测	是	当前块的 Base Fee 由父块数据按确定公式计算，单块变化有界。
吸收短时需求波动	是	区块可在目标用量与上限之间弹性扩张，之后用更高 Base Fee 把平均用量拉回目标。
保证 Gas 永远便宜	否	区块空间仍然稀缺；持续高需求会把 Base Fee 推高。
消灭交易排序竞争	否	Priority Fee 与其他经济激励仍会影响打包与排序。
让所有费用都归验证者	否	Base Fee 被销毁，只有实际 Priority Fee 属于执行层费用收入。

术语更新

EIP-1559 原文写于 PoW 时代，常使用 miner。The Merge 之后，以太坊由 PoS 验证者提议区块。本课用“区块生产者 / 提议者 / fee recipient”描述当前结算，引用规范历史语境时才保留 miner。

03 · Base fee

Base Fee 像一只区块空间恒温器

它不读取“还有多少人在排队”，而是用上一块真实消耗的 Gas 作为需求信号。

每个执行区块都有一个 baseFeePerGas。要进入这个区块，交易愿意承担的总单价至少要覆盖它；同一块中所有普通执行 Gas 都面对同一个 Base Fee。它不是由钱包、RPC 服务商或区块浏览器指定的。

低于目标

上一块空间偏空 → 下一块 Base Fee 下降

正好目标

上一块达到 target → 下一块 Base Fee 不变

达到上限

上一块为 2× target → 下一块约上涨 12.5%

目标与上限不是同一个数

EIP-1559 的弹性倍数为 2：目标 Gas 用量是区块 Gas Limit 的一半。当突发需求到来，单个区块可以临时从目标扩张到上限；若区块持续高于目标， Base Fee 会逐块上升，直到需求被价格抑制。低于目标时则反向下降。

gasTarget = parentGasLimit ÷ 2

若 parentGasUsed = gasTarget → nextBaseFee = parentBaseFee

若 parentGasUsed > gasTarget → nextBaseFee = parentBaseFee + max(floor[parentBaseFee × (parentGasUsed - gasTarget) ÷ gasTarget ÷ 8], 1 wei)

若 parentGasUsed < gasTarget → nextBaseFee = parentBaseFee - floor[parentBaseFee × (gasTarget - parentGasUsed) ÷ gasTarget ÷ 8]

规范以 wei 进行整数除法并向下取整；上涨分支至少增加 1 wei。完整判定以 EIP-1559 参考实现为准。^[2]

空块：在 Gas Limit 不变的前提下，用量为目标的 0%，下一块最多下降约 12.5%。
目标块：用量为目标的 100%，下一块保持不变。
满块：在 Gas Limit 不变的前提下，用量为目标的 200%，下一块最多上涨约 12.5%。
关键时序：第 N 块的交易改变的是第 N+1 块的 Base Fee，不会倒过来修改自己所在块的底价。

Interactive lab

转动 Base Fee 恒温器

改变父块 Base Fee 与相对目标用量，观察下一块如何调节。100% 是目标，200% 是上限。

父块 Base Fee 20 Gwei 父块用量 / target 100%

这里用小数展示直觉；客户端按 wei 进行整数运算。

父块正好达到目标，下一块 Base Fee 保持不变。

20.00
Gwei

0targetlimit

20.00
Gwei

变化方向不变

单块变化 0.00%

为什么钱包能留出“几块”的缓冲？

因为连续满块时每块最多上涨约 12.5%，所以未来几块的最坏路径可以估算。常见钱包会在当前 Base Fee 之上放入缓冲，再加小费上限；例如 2 × currentBaseFee + priorityCap 是一种常见启发式，能覆盖约五次连续满幅上调；到第六次时 1.125⁶ ≈ 2.03，已略高于两倍。它只是缓冲思路，不是“六块保证”，也不是协议强制公式。

可验证事实

Base Fee 写在区块头中；EIP-3198 又为 EVM 增加了 BASEFEE (0x48)， Solidity 中可通过 block.basefee 读取当前执行区块的基础费。^[4]

04 · Two caps

你填写的不是价格，而是两只上限

一只限制“无论如何最多付多少”，另一只限制“其中最多给多少小费”。

Total ceiling

maxFeePerGas

每单位 Gas 的总付款上限，必须同时容纳 Base Fee 和实际 Priority Fee。 Base Fee 高到超过它时，交易无法进入该区块。

Tip ceiling

maxPriorityFeePerGas

每单位 Gas 愿意给出的最大小费。它表达紧迫度，但实际小费还会被 maxFeePerGas - baseFeePerGas 的剩余空间截断。

effectivePriorityFeePerGas = min(maxPriorityFeePerGas, maxFeePerGas - baseFeePerGas)

effectiveGasPrice = baseFeePerGas + effectivePriorityFeePerGas

等价写法 = min(maxFeePerGas, baseFeePerGas + maxPriorityFeePerGas)

两个例子就能看出“上限”为什么重要

Tip cap binds

总上限空间充足

Base Fee 28，maxFee 42，Priority Cap 2。剩余空间 14，足以容纳 2，所以实际小费是 2，实际单价 30 Gwei。

Fee cap binds

总上限挤压小费

Base Fee 39，maxFee 40，Priority Cap 3。总上限只剩 1，所以实际小费降为 1，实际单价正好 40 Gwei。

协议还要求 maxFeePerGas ≥ maxPriorityFeePerGas。即使当前 Base Fee 很低，写出“小费上限高于总上限”的交易也是字段关系无效，不能靠结算公式自动修好。^[2]

Priority Fee 为什么存在？

Base Fee 被销毁，不能直接补偿区块生产者纳入交易的执行与机会成本。 Priority Fee 为纳入和排序提供协议内的经济信号：在其他条件相近时，更高的有效小费通常更有吸引力。零小费交易在协议层可以有效，但不保证有生产者愿意及时纳入。^[3]

不要把排序想成单一排行榜

实际区块构建还受 nonce 依赖、交易有效性、私有订单流、捆绑交易、MEV、本地策略和区块容量影响。“小费最高者必定最先”不是协议保证。

05 · Settlement

最终结算：先确定能不能进，再确定用了多少

费用计算有两个时间点：交易进入区块前看上限，执行结束后看实际用量。

字段先合法：maxFeePerGas ≥ maxPriorityFeePerGas。
余额先覆盖：发送者需要有能力覆盖 value + gasLimit × maxFeePerGas。
区块先可进入：maxFeePerGas ≥ block.baseFeePerGas。
执行再计量：EVM 从 Gas Limit 中扣除每一步的 Gas，得到结算后的 Gas Used。
按实际单价收费：gasUsed × effectiveGasPrice。
最后分流：Base Fee 部分销毁，Priority Fee 部分记入 fee recipient，未用余量不成为最终费用。

未触及的价格上限 maxFee - effectiveGasPrice

实际 Priority Fee fee recipient

Base Fee burn

Interactive lab

亲手拆一笔 EIP-1559 账单

调整六个参数，观察交易是否能进入区块、实际小费是否被截断，以及 ETH 最终如何分流。

Gas Limit 80,000 Gas Used 51,420 Block Base Fee 28 Gwei maxFeePerGas 42 Gwei maxPriorityFeePerGas 2 Gwei

可进入该区块；总上限空间充足，实际小费为 2 Gwei。

实际 Gas 单价 30.00 Gwei

实际 Priority Fee 2.00 Gwei

最终 Gas Fee 0.00154260 ETH

Base Fee 销毁 0.00143976 ETH

Fee Recipient 0.00010284 ETH

最高额与实付之差 0.00181740 ETH

51,420 × min(42, 28 + 2) Gwei；这里未加入 value、Blob Fee 或 Layer 2 的其他费用项。

为什么余额检查按上限，最终收费却按实际？

节点不能先执行完整交易、再发现发送者付不起最坏情形。因此接纳与执行前，必须确认余额足以覆盖 Gas Limit 乘以单价上限；最终只按实际 Gas 用量和有效单价收费，未使用的 Gas 与未触及的价格空间不成为净支出。把它理解为“先满足余额前提、后按实际结算” 即可，不要误画成发送给某个账户后又原路退回的一笔普通转账。

Gas Used 的精度

区块浏览器中的 Receipt gasUsed 已反映交易级执行结算。计算真实交易费用时优先使用 Receipt 的 gasUsed 与 effectiveGasPrice，不要拿钱包的 Gas Limit 直接相乘。

06 · Burn

Base Fee 为什么必须销毁？

销毁首先是费用市场的机制设计，其次才产生 ETH 供给层面的结果。

如果区块生产者能保留 Base Fee，它就可能通过塞入自己的交易、链下返还或其他安排，扭曲协议试图建立的公开底价。把 Base Fee 从收入中拿走并销毁，可以削弱生产者操纵这条底价的动机。^[2]

Neutral floor

让底价更中立

Base Fee 是网络的拥挤信号，不应成为单个区块生产者可以给自己返还的收入。

Native asset

把区块空间与 ETH 相连

协议要求用 ETH 支付并销毁基础费，不能让某个应用代币取代全网统一结算资产。

Supply

形成供给反作用力

网络使用越旺盛，被销毁的 ETH 越多；它与 PoS 发行共同决定净供给变化。

“销毁”不是转到一个没人知道私钥的地址

从协议会计看，Base Fee 是从发送者余额扣除，却不计入任何普通账户余额；它在状态转换中被移出供给。把它说成“打进黑洞地址”会让人误以为链上存在一笔可查询的普通转账，甚至理论上仍有某把未知私钥——那不是 EIP-1559 的结算方式。

本块执行 Gas 销毁量 = block.baseFeePerGas × block.gasUsed

某时段净供给变化 = PoS issuance - protocol burn

所以“每笔交易都销毁 ETH”不等于“ETH 每天都通缩”。只要某时段发行量高于销毁量，净供给仍增长；销毁量高于发行量时，净供给才下降。价格涨跌也不是“供给通胀/通缩” 这一术语的同义词。^[7]

Interactive lab

把发行与销毁放到同一架天平

用抽象的每日 ETH 数量建立关系。这里只讲净供给算术，不预测价格，也不读取实时数据。

示例每日发行 1,800 ETH 示例每日销毁 1,200 ETH

现实中的 PoS 发行与 Gas 销毁都会变化；这里的数值只服务于概念。

发行高于销毁：示例净供给每天增加 600 ETH。

发行 +

1,800

销毁 −

1,200

净变化：+600 ETH / 日

分析纪律

“销毁使剩余 ETH 更稀缺”是供给机制描述，不自动推出投资结论。资产价值还涉及需求、风险、监管、竞争、流动性与宏观环境；第十九章才会系统建立经济分析框架。

07 · Failure & refund

失败了为什么还要付？“退款”又退什么？

状态回滚不等于计算没有发生；Gas 退款也有两个完全不同的含义。

Success

成功执行

状态改变被保留；按结算后的实际 Gas Used 收费，未用的 Gas Limit 不收费。

Revert

主动回滚

本次调用的状态改变回滚，但节点已经执行过路径；消耗的 Gas 仍收费，剩余 Gas 可返回。

Out of gas

Gas 耗尽

顶层交易因 Gas 不足失败时，提供的执行 Gas 被耗尽；状态回滚，交易费仍支付。

第一种“退”：Gas Limit 没用完

Gas Limit 只是执行预算。交易成功且只用了 51,420 / 80,000 Gas，剩余 28,580 Gas 不会按实际单价收费。日常界面把这说成“退回未用 Gas”没有问题，但更准确地说，它没有成为最终净支出。

第二种“退”：EVM 的 Refund Counter

某些清理存储等操作会积累 Gas refund counter，在执行完成后减少结算用量。这不是把过去付过的 ETH 原路退回，也不能无限抵扣。EIP-3529 移除了 SELFDESTRUCT 的 Gas refund，并把单笔交易可抵扣的上限降为执行 Gas 的五分之一。^[5]

三种经常被都叫作“退款”的东西
项目	发生原因	是否属于链上 Gas Refund Counter
未用完 Gas Limit	执行提前结束，仍有 Gas remaining	不是
未触及 maxFeePerGas	实际单价低于用户价格上限	不是
存储清理带来的抵扣	特定 EVM 操作累积 refund counter	是，且受上限约束

安全操作

不要为了“省一点 Gas”把 Gas Limit 设得贴着估算值。估算依赖当时状态；合约分支、存储状态或被调用合约可能变化。Gas Limit 太高不会自动多收，太低却可能让交易 Out of Gas，并付出已经耗尽的费用。

08 · Boundaries

别把所有“Gas 费”塞进同一个公式

主网执行 Gas、Blob Gas、Layer 2 账单和 MEV 可能同时出现，但它们不是同一层机制。

Legacy

旧式 `gasPrice`

旧交易仍可存在。伦敦之后，它的单一 gasPrice 同样必须覆盖区块 Base Fee；其中 Base Fee 被销毁，剩余部分形成有效优先费。不要因此以为旧交易绕过了销毁。

Blob market

Blob Gas

EIP-4844 为 Blob 数据引入独立 Gas 与独立 Base Fee。Blob 交易既可能支付普通执行费，也支付 Blob Fee；Blob Base Fee 同样销毁，但其调节规则和上限字段是另一套。^[6]

Rollup bill

Layer 2

L2 用户账单常包含 L2 执行、向 L1 发布数据、运营者附加项等。不能只拿主网的 gasUsed × (base + tip) 就解释全部费用。

Blob Fee 为什么要单独提醒？

它最容易制造“同一笔交易为什么有两个 Base Fee”的困惑。普通执行 Gas 衡量 EVM 计算与状态访问；Blob Gas 为临时数据可用性定价。EIP-4844 类型交易包含 maxFeePerBlobGas，Blob Base Fee 从独立的拥挤状态计算。当前机制没有独立的 Blob Priority Fee。Blob Fee 在执行前按 Blob 数量结算并销毁，交易执行失败也不退还；网络升级可以调整 Blob 参数，因此本课不把某个时点的 Blob 数量或具体阈值写成永久常量。

Priority Fee 也不是区块生产者全部经济收入

从执行层协议账本看，实际 Priority Fee 记入区块中的 feeRecipient。但现实中的区块构建可能经过 proposer-builder separation 相关基础设施，还可能有构建者支付、捆绑交易或 MEV 收益。因此：

“交易 Receipt 可算出的优先费”是协议内费用项；
“提议者最终经济收益”可能还受协议外或其他链上支付影响；
不能仅凭所有交易的 Priority Fee 总和，还原一个区块的完整经济分配。

合约看到的 `tx.gasprice` 是什么？

EIP-1559 要求 GASPRICE (0x3a) 返回实际 effectiveGasPrice，而不是用户的 maxFeePerGas。当前块 Base Fee 则由 EIP-3198 的 BASEFEE 提供。因而合约可以推导实际优先费，但不能把 tx.gasprice 当成用户填写的总上限。

一条分层口诀

执行 Gas 看 EIP-1559；Blob 数据看独立 Blob 费用市场；L2 用户账单看该 Rollup 的费用组成；完整区块经济再额外考虑构建与 MEV。先分层，再计算。

09 · Read a transaction

怎样从真实数据还原这张账单？

一笔交易、一个区块、一个 Receipt，三处数据拼起来才是完整答案。

费用审计所需字段
数据来源	关键字段	回答的问题
Transaction	`gas`、`maxFeePerGas`、`maxPriorityFeePerGas`、`value`	用户允许的执行上限、价格上限、小费上限与转账金额是什么？
Block	`baseFeePerGas`、`gasUsed`、`gasLimit`、执行载荷 `feeRecipient`（常由 JSON-RPC `miner` 暴露）	本块底价、拥挤程度与协议内费用接收地址是什么？
Receipt	`status`、`gasUsed`、`effectiveGasPrice`	交易成功吗？结算用量与实际每 Gas 单价是多少？

Interactive lab

字段从哪里来？

切换数据对象，突出显示属于它的字段。示例值与本课账单一致。

Transaction：先看用户签名承诺了哪些上限；它不告诉你最终用了多少 Gas。

JSON-RPC 数值通常以十六进制 wei 返回；区块浏览器会代为换算。审计时要确认单位。

gas0x13880 · 80,000

maxFeePerGas42 Gwei

maxPriorityFeePerGas2 Gwei

baseFeePerGas28 Gwei

feeRecipient / miner0xfee…cafe

status0x1 · success

gasUsed0xc8dc · 51,420

effectiveGasPrice30 Gwei

一套可重复的审计顺序

先用 Receipt 的 status 判断成功或失败。
用 Receipt 的 gasUsed × effectiveGasPrice 得到最终执行 Gas Fee。
从所在区块读取 baseFeePerGas。
计算销毁：gasUsed × baseFeePerGas。
计算实际优先费：gasUsed × (effectiveGasPrice - baseFeePerGas)。
回到 Transaction 对照两个上限，解释为什么实际单价没有超过它们。
把 value、Token 转移、Blob Fee 或 L2 额外费用另列，不混入执行费。

burned = receipt.gasUsed × block.baseFeePerGas

priorityPaid = receipt.gasUsed × (receipt.effectiveGasPrice - block.baseFeePerGas)

钱包如何估算优先费？

执行客户端提供 eth_feeHistory：它可返回一段区块范围内的 Base Fee、 Gas 使用率，以及按 Gas 加权的有效优先费分位数。钱包可以据此估计近期市场，再结合用户希望的确认速度设置上限。结果仍是估计，不是对下一块排序的承诺。^[9]

看到 “Gas Price” 先问：界面展示的是上限、建议价，还是 Receipt 的 effectiveGasPrice？
看到 “Transaction Fee” 先问：它是否只含执行 Gas，是否另有 Blob 或 L2 数据费用？
看到 “Burned” 先核：是否等于 Gas Used 乘以所在区块 Base Fee？
看到 “Validator Tip” 先核：是否使用实际单价减 Base Fee，而非直接拿 maxPriorityFeePerGas？

10 · Synthesis

把整套机制压缩成一条因果链

从父块拥挤，到下一块底价；从用户两只上限，到执行后分流。

父块 Gas 用量相对 target 的高低，决定下一块 Base Fee 上调、持平或下调。
用户签署 maxFeePerGas 与 maxPriorityFeePerGas，限定每 Gas 最坏支出和最大小费。
交易要进入某块，总费用上限必须至少覆盖该块 Base Fee。
实际小费取“小费上限”和“总上限减 Base Fee”两者较小值。
EVM 执行并得到结算后的 Gas Used；成功与失败都可能消耗 Gas。
最终费用等于 Gas Used 乘以实际单价；Base Fee 销毁，实际 Priority Fee 进入 fee recipient。
净 ETH 供给还要把协议销毁与 PoS 发行放在同一时段比较。

最终心智模型

Base Fee 回答“这块空间的协议底价是多少”， Priority Fee 回答“我愿意给多少纳入激励”， 两只 max 上限 回答“最坏情形我承担到哪里”， Gas Used 回答“执行最终用了多少”， Burn 回答“基础费为何不成为生产者收入”。

六题校准

1. 谁直接决定某个区块的 Base Fee？

请选择一个答案。

2. Base Fee 39、maxFee 40、Priority Cap 3，实际小费是多少？

请选择一个答案。

3. 一笔普通 EIP-1559 执行费中，哪一部分被销毁？

请选择一个答案。

4. 合约调用 Revert 后，哪句话正确？

请选择一个答案。

5. Blob Fee 与普通执行 Gas Fee 的关系是什么？

请选择一个答案。

6. “每笔交易都销毁 Base Fee”能直接推出什么？

请选择一个答案。

11 · Reference

术语与一手资料

把钱包界面的简称，重新连回协议字段与官方定义。

核心术语

Base Fee: 每个执行区块的协议底价，按父块拥挤程度变化；对应部分被销毁。
Priority Fee: 实际给 fee recipient 的每 Gas 小费；不一定等于用户填写的小费上限。
maxFeePerGas: 用户签署的每 Gas 总付款上限，覆盖 Base Fee 与实际 Priority Fee。
maxPriorityFeePerGas: 用户签署的每 Gas 最大小费上限。
effectiveGasPrice: 交易所在区块实际结算的每 Gas 单价；Receipt 可直接返回。
Gas Limit: 用户允许该交易消耗的 Gas 上限，不是最终 Gas Used。
Gas Used: 执行和 refund 结算后的实际计费用量。
Gas Target: EIP-1559 希望长期回归的区块 Gas 用量，通常是区块 Gas Limit 的一半。
Fee Recipient: 执行载荷中接收实际优先费的地址，不等同于协议全部经济收益的最终归属。
Burn: 从协议供给中移除 ETH；不是向普通黑洞账户发起一笔转账。
Blob Gas: 为 Blob 数据可用性单独计量的资源，拥有独立 Base Fee。
eth_feeHistory: 执行层 JSON-RPC 方法，返回 Base Fee、Gas 使用率与有效优先费分位数据。

官方与标准原文

ethereum.org · Gas and fees Gas、Base Fee、Priority Fee、Max Fee、区块目标与费用示例的官方技术概览。
EIP-1559 · Fee market change 动态费用交易字段、Base Fee 调节、实际优先费、销毁与参考实现。
ethereum.org · Priority fee (tips) 优先费为何为纳入交易提供激励，以及它与 Base Fee 的关系。
EIP-3198 · BASEFEE opcode EVM 读取当前区块 Base Fee 的 0x48 操作码。
EIP-3529 · Reduction in refunds 移除 SELFDESTRUCT refund、调整 SSTORE refund 并把抵扣上限降为 Gas Used 的五分之一。
EIP-4844 · Shard Blob Transactions Blob 交易字段、独立 Blob Gas、Blob Base Fee 与销毁结算。
ethereum.org · How The Merge impacted ETH supply PoS 发行、EIP-1559 销毁与净供给变化的关系。
ethereum.org · Transactions 交易字段、类型化交易与执行费用相关概念。
Ethereum Execution APIs · eth_feeHistory Base Fee 历史、Gas 使用率与有效优先费分位数的标准 RPC 接口。
EIP-2718 · Typed Transaction Envelope EIP-1559 类型 0x02 与 Blob 类型 0x03 所依赖的类型化交易封装。
ethereum.org · Blocks 执行区块字段、Gas Limit、Gas Used 与 Base Fee 的背景。
ethereum.org · Scaling Ethereum Layer 2 与主网之间的分层关系，帮助区分 L1 执行费和 Rollup 用户账单。

一笔 Gas 费，最终去了哪里？Base Fee · Priority Fee · 销毁机制

Gas Used

Gwei / Gas

ETH

先记住四个“不要等号”

一个总报价

协议底价 + 两只上限

它解决了什么，又没有解决什么？

目标与上限不是同一个数

为什么钱包能留出“几块”的缓冲？

maxFeePerGas

maxPriorityFeePerGas

两个例子就能看出“上限”为什么重要

总上限空间充足

总上限挤压小费

Priority Fee 为什么存在？

为什么余额检查按上限，最终收费却按实际？

让底价更中立

把区块空间与 ETH 相连

形成供给反作用力

“销毁”不是转到一个没人知道私钥的地址

第一种“退”：Gas Limit 没用完

第二种“退”：EVM 的 Refund Counter

旧式 gasPrice

Blob Gas

Layer 2

Blob Fee 为什么要单独提醒？

Priority Fee 也不是区块生产者全部经济收入

合约看到的 tx.gasprice 是什么？

一套可重复的审计顺序

钱包如何估算优先费？

六题校准

1. 谁直接决定某个区块的 Base Fee？

2. Base Fee 39、maxFee 40、Priority Cap 3，实际小费是多少？

3. 一笔普通 EIP-1559 执行费中，哪一部分被销毁？

4. 合约调用 Revert 后，哪句话正确？

5. Blob Fee 与普通执行 Gas Fee 的关系是什么？

6. “每笔交易都销毁 Base Fee”能直接推出什么？

核心术语

官方与标准原文

你支付的不是一个模糊的“Gas 价”，而是一套可验证的结算。

一笔 Gas 费，
最终去了哪里？Base Fee · Priority Fee · 销毁机制

旧式 `gasPrice`

合约看到的 `tx.gasprice` 是什么？