以太坊机制详解:Gas与Gas Prices深度解析

概述

读者可以前往我的博客获得更好的阅读体验。

在以太坊London升级后，以太坊启用了EIP1559进行gas计算。由于EIP1559引入的新的gas机制较为复杂，所以我写了此文介绍了以太坊的gas机制。

本文主要涉及以下内容:

  • EIP1559引入的新的gas price设置方式
  • 交易花费的具体计算方式

另，此文写作日期在以太坊即将进行合并时，所以我们在后文依旧使用了矿工这一称谓。

概念辨析

由于此篇是解析以太坊GAS机制的第一篇，所以我们首先在此处介绍gas与gas price的区别。

前者是以太坊转账或者合约操作的基准价值。你可以在此网站查询到每一个操作码的最小GAS消费。如下图:

OpCode GAS

理论上，我们可以通过合约字节码判断出合约操作所需要的gas值。当然，如果读者使用了Foundry作为智能合约开发工具链，可以在合约代码根目录运行forge test --gas-report获得gas报告，如下图:

Foundry Gas Report

上述表格也显示了合约部署消耗的gas值。当然，以太坊中也有一种不需要与智能合约交互的但非常重要的操作就是ETH转账，此操作被规定为21,000。可以参考此交易，如下图:

Transfer Gas

如果你自定义交易的gas最大限额，但设置的数量小于合约操作所需要的gas，就会出现错误。比如这个交易，如下图:

Gas Small Fail

上图由红框框出的部分就是此交易的gas限制和gas实际用量。此操作实际的gas用量为160,596，此处的最大限额小于合约操作的用量，所以出现了错误。正常的合约操作可以参考此交易。当然此交易虽然失败了，但仍打包到区块内并收取交易手续费并奖励矿工。因为矿工在接受交易时并不清楚交易的gas用量，矿工会运行交易直至gas耗尽，此部分需要补偿矿工。

当Gas的实际用量小于Gas Limit时，剩余部分会退还给用户。

但gas并不代表着进行这一操作所消耗的ETH数量。以太坊中存在大量的交易，我们需要根据网络情况调整手续费，为了有效调整手续费，以太坊引入了gas price价值作为计算手续费的单位，具体计算公式为
Transaction Fee = Gas * Gas Price，其中Transaction Fee就是交易手续费的意思。在后文中，我们会详细分析gas price的计算方法。

Gas Limit 的获取

对于Gas Limit的获取，以太坊客户端给出了一个专用的RPC API，被称为eth_estimateGas。

此API调用所需要的参数其实就是交易所需要的参数，我们在此处直接给出两个示例帮助大家使用。

在后文中，我们主要使用Cloudflare提供的公用以太坊网关作为RPC API服务商，其地址为https://cloudflare-eth.com/v1/mainnet。

为了方便读者学习，此处我们使用以太坊官方文档提供的线上测试功能。读者可以通过以下方法打开测试功能:

Test Console

首先，我们尝试获取转账交易的Gas消耗，在上图给出的测试栏的的左侧输入以下内容:

{
    "jsonrpc": "2.0",
    "method": "eth_estimateGas",
    "params": [
        {
            "from": "0x8D97689C9818892B700e27F316cc3E41e17fBeb9",
            "to": "0xd3CdA913deB6f67967B99D67aCDFa1712C293601",
            "value": "0x186a0"
        }
    ],
    "id": 0
}

输入完成后点击运行按钮，我们可以在右侧获得以下返回:

{
    "jsonrpc": "2.0",
    "result": "0x5208",
    "id": 0
}

其中，result就是此交易的gas，将其转为十进制，结果恰好为21000，与上文给出的结果相符。

当然，更常见的Gas估计是估计合约操作所消耗的Gas值，我们在此处以WETH合约(0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2)为例获取存储deposit()操作的Gas消耗。

使用此API的具体参数可以参考以下

{
    "jsonrpc": "2.0",
    "method": "eth_estimateGas",
    "params": [
        {
            "type": "2",
            "from": "0x8D97689C9818892B700e27F316cc3E41e17fBeb9",
            "to": "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2",
            "value": "0x186a0",
            "input": "0xd0e30db0"
        }
    ],
    "id": 0
}

其中各个参数意义如下:

  • from 调用合约的用户地址
  • to 目标合约地址
  • value 在调用合约时发送的ETH
  • input 调用合约时发送的Calldata

input可以在此网站获得。获得deposit()函数调用Calldata的形式如下图:

deposit CallData

由于此处deposit()没有参数，所以我们没有在此处使用Add argument增加参数。

发送上述请求，我们可以获得以下返回值:

{
    "jsonrpc": "2.0",
    "result": "0xafee",
    "id": 0
}

将result转换为十进制得到45038，这与我们在此页面查询得到的结果一致。

对于获取gas的估计值，我们也可以使用cast获得，在此处，我们仍使用WETH合约。

在终端内输入

cast estimate 0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2 
	--value 1.1ether "deposit()" 
	--rpc-url https://cloudflare-eth.com/v1/mainnet

我们可以获得返回值为27938。读者可以发现此交易的gas正是27938。

上述两者的不同原因是在EIP2929。简单来说，SSTORE操作符的gas决定方式较为特殊。此操作符用于向合约特定的存储槽内写入数据。其gas决定方法如下:

  • 当写入存储槽本来无数据时，使用SSTORE写入数据消耗22100。如果读者的地址未持有WETH时，我们需要消耗此数值的gas
  • 当写入存储槽内存在非零数据时，使用SSTORE写入数据消耗5000。

当我们使用cast estimate评估gas时，默认使用的地址内存在WETH，而在我们上文使用的 RPC API 时，使用的地址内不持有WETH。更加详细的Gas分析我们会在后面几篇内给出。

Gas Price计算

我们主要考虑在London升级后的符合EIP1559标准的交易，这些交易均被标记为type 2。

名词解释

在此处，我们给出一个交易的实例:

Tx Example

我们主要考察Gas Price这一栏。内部由以下构成:

  • Gas Limit & Usage by Txn 我们在上文进行了解释，前者表示合约操作的Gas限额，后者表示本次交易的Gas用量
  • Gas Fees 给出Gas Price的各个计算参数
    • Base 基础Gas Price
    • Max 最大Gas Price
    • Max Priority 支付给以太坊节点矿工的Gas Price
  • Burnt & Txn Savings Fees 燃烧掉的手续费和给予矿工的手续费
    • Burnt 燃烧的手续费。EIP1559规定了每次交易的手续费部分进行燃烧，这一行为有效避免了ETH通货膨胀
    • Txn Savings 给予矿工的手续费

我们会在下文给出每个参数的计算方法。

Base Fee

此参数由以太坊网络计算得到，在同一区块内是固定的。如果你设置的Base Fee小于当前网络的Gas Fee，则交易永远不会被打包。

我们在此处给出go-ethereum的源代码:

// CalcBaseFee calculates the basefee of the header.
func CalcBaseFee(config *params.ChainConfig, parent *types.Header) *big.Int {
	// If the current block is the first EIP-1559 block, return the InitialBaseFee.
	if !config.IsLondon(parent.Number) {
		return new(big.Int).SetUint64(params.InitialBaseFee)
	}

	parentGasTarget := parent.GasLimit / params.ElasticityMultiplier
	// If the parent gasUsed is the same as the target, the baseFee remains unchanged.
	if parent.GasUsed == parentGasTarget {
		return new(big.Int).Set(parent.BaseFee)
	}

	var (
		num   = new(big.Int)
		denom = new(big.Int)
	)

	if parent.GasUsed > parentGasTarget {
		// If the parent block used more gas than its target, the baseFee should increase.
		// max(1, parentBaseFee * gasUsedDelta / parentGasTarget / baseFeeChangeDenominator)
		num.SetUint64(parent.GasUsed - parentGasTarget)
		num.Mul(num, parent.BaseFee)
		num.Div(num, denom.SetUint64(parentGasTarget))
		num.Div(num, denom.SetUint64(params.BaseFeeChangeDenominator))
		baseFeeDelta := math.BigMax(num, common.Big1)

		return num.Add(parent.BaseFee, baseFeeDelta)
	} else {
		// Otherwise if the parent block used less gas than its target, the baseFee should decrease.
		// max(0, parentBaseFee * gasUsedDelta / parentGasTarget / baseFeeChangeDenominator)
		num.SetUint64(parentGasTarget - parent.GasUsed)
		num.Mul(num, parent.BaseFee)
		num.Div(num, denom.SetUint64(parentGasTarget))
		num.Div(num, denom.SetUint64(params.BaseFeeChangeDenominator))
		baseFee := num.Sub(parent.BaseFee, num)

		return math.BigMax(baseFee, common.Big0)
	}
}

其中parent为上一区块的区块头。我们在此处不再详细解释此结构体内的变量，读者可自行查找对应源代码。此处用到的一个重要参数为parent.GasLimit，含义为区块内各个交易的Gas累加最大值，读者可以通过此网站查看历史上的GasLimit变化。目前(2022年8月)，此值大概为3千万。

Miner: miner.Config{
        GasCeil:  30000000,
        GasPrice: big.NewInt(params.GWei),
        Recommit: 3 * time.Second,
    }

当然，区块的GasLimit并不是固定不变的，会在小范围内波动，具体的计算逻辑位于go-ethereum内的CalcGasLimit(parentGasLimit, desiredLimit uint64)函数，此函数使用的参数desiredLimit即为 3千万 。限于篇幅且此计算函数较为简单，我们不对计算函数进行详细解释，读者有兴趣可以自行研究此函数。

params.ElasticityMultiplier值已经在源代码进行了硬编码为2。通过parentGasTarget := parent.GasLimit / params.ElasticityMultiplier代码，我们可以计算出目前目标区块容量为1.5千万。

params.InitialBaseFee此值为EIP1559启动时区块的baseFee，从后文我们可以看到计算baseFee依赖于上一区块的baseFee，而初始区块的上一区块没有通过此属性，所以我们需要进行初始化。此变量被初始化为const InitialBaseFee untyped int = 1000000000，1000000000的单位为wei，即1 gwei。

if parent.GasUsed == parentGasTarget {
    return new(big.Int).Set(parent.BaseFee)
}

此代码说明，当目前区块交易Gas累加值为1.5千万时，区块与上一区块的Base Fee相同。这也意味着当前Gas Price很好平衡了交易数量与交易费用，不需要进行调整。

除了这种相同的情况，还有大于和小于的情况，下面先展示上一区块没有大于目标Gas总量的情况。

// If the parent block used more gas than its target, the baseFee should increase.
// max(1, parentBaseFee * gasUsedDelta / parentGasTarget / baseFeeChangeDenominator)
num.SetUint64(parent.GasUsed - parentGasTarget)
num.Mul(num, parent.BaseFee)
num.Div(num, denom.SetUint64(parentGasTarget))
num.Div(num, denom.SetUint64(params.BaseFeeChangeDenominator))
baseFeeDelta := math.BigMax(num, common.Big1)

return num.Add(parent.BaseFee, baseFeeDelta)

在注释中，我们可以看到当前区块的baseFee的计算公式为

parent.BaseFee + 
max(1, parentBaseFee * gasUsedDelta / parentGasTarget / baseFeeChangeDenominator)

其中各个参数意义如下:

  • parentBaseFee为parent.BaseFee，即上一区块的baseFee
  • gasUsedDelta为parent.GasUsed - parentGasTarget，即上一区块的Gas总量与目标总量之间的差额
  • parentGasTarget为上一区块的目标值，在一定时期内可以认为是常量，目前为1.5千万Gas
  • BaseFeeChangeDenominator，定义为const BaseFeeChangeDenominator untyped int = 8

我们计算极限情况，即当前区块的上一区块的Gas总量到达限额3千万，此时gasUsedDelta为1.5，parentGasTarget为1.5，简单计算可以得出当前区块的BaseFee应为上一区块的112.5 %。

接下来我们使用Etherscan Blocks提供的真实数据进行计算。

Base Fee Calc

我们计算15406316区块的BaseFee，我们需要参照该区块的上一区块15406315的参数进行计算，我们可以看到上一区块的gasUsedDelta/parentGasTarget为+ 11%，计算得到此时15406316的BaseFee的值应为6.38 Gwei * 0.11 / 8，计算得到0.885225 gwei，即15406316的baseFee应为6.38 * 0.11 / 8 + 6.38，计算得到结果为6.467725，与etherscan给出的相同。

以下给出上一区块Gas总量小于目标总量的代码:

// Otherwise if the parent block used less gas than its target, the baseFee should decrease.
// max(0, parentBaseFee * gasUsedDelta / parentGasTarget / baseFeeChangeDenominator)
num.SetUint64(parentGasTarget - parent.GasUsed)
num.Mul(num, parent.BaseFee)
num.Div(num, denom.SetUint64(parentGasTarget))
num.Div(num, denom.SetUint64(params.BaseFeeChangeDenominator))
baseFee := num.Sub(parent.BaseFee, num)

return math.BigMax(baseFee, common.Big0)

根据代码，我们可以得出计算公式如下:

parent.BaseFee - 
max(1, parentBaseFee * gasUsedDelta / parentGasTarget / baseFeeChangeDenominator)

这意味着如果上一区块的Gas总量为0，则当前区块的baseFee为上一区块baseFee的87.5 %。我们不再给出具体的计算过程，读者可自行使用Etherscan Blocks提供的数据进行验算。

BaseFee的动态调整可以很好平衡以太坊网络流量，一旦单一区块的交易Gas到达1.5千万，那么根据上述机制，下一区块就会提高BaseFee以增加用户的交易手续费，抑制用户交易。反之，当交易需求不足时，以太坊网络则会降低交易手续费以提高用户的交易欲望。

BaseFee List

在上图中，我们可以明显考到这一趋势。在15406535区块出现了交易Gas为0的情况，导致BaseFee下降，在下一区块15406536则出现了大量交易。

我使用了部分区块的数据绘制了以下图像:

Gas Block Size

在此图像中，条形图展示了区块的大小，而折线图展示了Base Fee的变化，我们可以很明显的看出Base Fee对区块大小的调整作用。

此图主要使用了eth_getBlockByNumberAPI方法获得区块数据。

根据EIP1559规定，baseFee不归属于矿工而会被直接燃烧。这种燃烧行为有效避免ETH通货膨胀。通过Etherscan EIP1559 Dashboard可以获得对应的数据，如下图:

Gas Burn Chart

在作者写作此文的过程中，ETHW项目作为以太坊合并后的POS分支废除了EIP1559，很明显，EIP1559没有将所以的手续费分配给矿工的行为不被部分以太坊矿工认可。

Max Priority Fee

在此交易的实例中，我们可以看到Max Priority为1 Gwei。相比于上文给出的BaseFee而言，此变量完全由交易者自己规定，而不涉及计算问题。Max Priority Fee与Base Fee不同，此手续费完全交给矿工。所以此值越高则意味着被提前打包的概率越大。

此数值可以通过交易内存池(mempool)中的交易数据进行推测，目前市面由很多网站提供Max Priority Fee的参考数值，比如:

我们在此处以BlockNative提供的数据为例，如下图:

BlockNative Gas

BlockNative显示了在当前区块确认交易所需要的Priority Fee和Max Fee以及当前区块的Base Fee。关于Max Fee的设置，我们会在下文进行介绍。

此处我们以MetaMask为例(版本为10.18.3)，给出EIP1559的设置方法。在进行转账或其他操作时，我们可以点击编辑，如下图:

MetaMask Edit Gas

在弹出页面内选择高级选项，我们就可以手动调整各个参数，如下图:

MetaMask Advance

由于此处为转账操作，所以燃料限制，即Gas Limit为21000。其他数值我们可以自行调整。一般来说，MetaMask填入的默认数值是可以直接使用的，但当遇到铸造NFT等场景时，我们可以手动调高Max Priority Fee以提高铸造成功率。

有了以上参数，我们可以计算具体的交易手续费。我们仍是使用示例交易为大家介绍。

我们可以看到此交易的Base为7.326319867 Gwei，而Max Priority为1 Gwei。将上述两个数累加即gas price，此处计算得到8.326319867 Gwei。然后我们将gas price * gas，即8.326319867 * 45038，得到此交易的手续费为375000.79416994605 Gwei，基本与Transaction Fee的值一致。

Max Fee

我们最后介绍Max Fee。此数值规定交易的最大gas price。可能有读者会疑惑，我们已经设置了Base Fee和Max Priority Fee，为什么还需要Max Fee？

原因在于用户提交给以太坊节点的交易不一定在下一个区块内完成。如果读者还记得上文给出的BaseFee就知道此数值是随着区块Gas总量不断变化的。假如我们根据区块0计算出下一区块1的BaseFee为7 Gwei，同时手动设置了Max Priority Fee为1 Gwei，由于我们给出的矿工小费太少，我们的交易会进入打包序列但可能无法在区块1内打包。只能等待区块2进行打包，但极有可能出现区块2的BaseFee为7.875 Gwei高于区块1，我们给出的BaseFee小于区块2的BaseFee，此时交易会被直接抛弃，造成交易失败。

如果我们给出Max Fee参数为9 Gwei，当交易进入区块2时，区块2会根据Max Fee计算出我们可以承受的Base Fee为Max Fee - Max Priority Fee即8 Gwei，此数值大于区块2的Base Fee，交易仍会保存在序列中等待打包。

简单来说，Max Fee的设置可以保证交易不会在未来几个区块内因为Base Fee设置过低问题而被抛出打包序列。此数值设置越高，你的交易会在打包序列中保存的时间越长，避免因手续费问题而交易失败。

比如这个Binance的交易给出了超高的Max Fee，彻底避免在因Base Fee而出现交易失败的问题。

读者可以估计以下自己目标交易在几个区块内完成，然后设置Max Fee。当然，BlockNative提供了一种简单的计算方法，公式如下:

Max Fee = (2 * Base Fee) + Max Priority Fee

这种计算方法可以保证即使用户遇到连续6个满区块(即区块Gas总额均达到3千万)仍可以保证交易不会被提出打包序列。

连续6个满区块会导致相对于当前的BaseFee的(1.125)^6，计算可知此倍数为2.027

读者可以根据自己的情况设置Max Fee。但不建议Max Fee与Base Fee的值差距较小，这可能会导致交易无法完成。

总结

本篇主要介绍了以下内容:

  • 以太坊中的Gas、Gas Price、Transaction Fee之间的区别
  • EIP1559 中各个参数的计算方法和功能

我们可以通过下图简单总结本文:

Gas Price

如果读者可以很好的理解本篇文章，且想进一步了解以太坊交易，可以参考以太坊机制详解:交易与交易池