以太坊共同创办人「V神」VitalikButerin在2024年5月13日发布了EIP-7706提案，提出了对现有Gas模型的补充方案，将Calldata的Gas计算单独剥离出来，并定制了类似BlobGas的BaseFee定价机制，进一步降低Layer2的运转成本引言：以太坊共同创办人「V神」VitalikButerin在2024年5月13日发布了EIP-7706提案，提出了对现有Gas模型的补充方案，将Calldata的Gas计算单独剥离出来，并定制了类似BlobGas的BaseFee定价机制，进一步降低Layer2的运转成本。与之相关的提案还需要追溯到2022年2月提出的EIP-4844，相隔时间甚久，因此查阅相关资料，希望对最新的以太坊Gas机制做一个综述，方便大家快速了解。目前已支援的以太坊Gas模型：EIP-1559和EIP-4844在最初的设计中，以太坊采用了一个简单的拍卖机制对交易费用进行定价，这需要用户主动为自己的交易出价，也就是设定gasprice，通常情况下，由于用户付出的交易费将归属于矿工，所以矿工将根据经济最优的原则，按照出价高低来决定交易打包顺序，注意这是在忽略MEV的情况下。在当时核心开发者看来这个机制面临以下四个面向的问题：l交易费用水准的波动性与交易的共识成本之间的不匹配：对于处在活跃状态的区块链中，交易的打包需求充足，这意味著区块可以被轻易填满，但这往往也意味著整体费用的波动性极大。例如当平均GasPrice为10Gwei时，网路因在一个区块中再接受一笔交易而产生的边际成本是平均GasPrice为1Gwei时的10倍，这是不可接受的。l对用户来说不必要的延迟：由于每个区块有gaslimit的硬性限制，加上历史交易量的自然波动，交易通常会等待几个区块才能被打包，但这对整体网络来说是低效的；即不存在允许一个区块更大而下一个区块更小的「松弛」机制来满足逐个区块的需求差异。l定价效率低：由于采用简单的拍卖机制导致了公允价格发现的效率较低，这意味著对于用户来说，给出一个合理的定价将是困难的，这也意味著有非常多情况下，用户付高了手续费。
l无区块奖励的区块链将不稳定：当取消挖矿带来的区块奖励并采取单纯的手续费模型时，可能会导致很多不稳定，例如激励挖掘窃取交易费用的「姐妹区块」，开启更强大的自私挖矿攻击向量等。直到EIP-1559的提出与执行，Gas模型有个第一次迭代，EIP-1559时Vitalik等核心开发者在2019年4月13日提出的，并在2021年8月5日的London升级中被采用，该机制摒弃了拍卖机制，转而采用了一种Basefee和Priorityfee的双重定价模型，其中Basefee将根据父区块中已产生的gas消耗情况与一个浮动且递归的gastarget之间的关系透过一个既定的数学模型定量计算，直观的效果为若上一个区块中gas使用情况超过了预定的gastarget时，则上调basefee，若不及gastarget，则下调basefee，这样做既可以比较好的反应供需关系，又可以使得对于合理gas的预测变得更加精准，不至于出现由于误操作导致的天价GasPrice，因为basefee的计算是直接由系统决定的而非用户自由指定。具体的程式码如下：其中可知当parent_gas_used大于parent_gas_target时，那么当前区块的basefee将相较于上一个区块的basefee加上一个偏移值，至于偏移值则是取parent_base_fee乘以上一个区块gas总用度相对gastarget的偏移量并对gastarget与一个常数取余与1的最大值。反之逻辑类似。另外Basefee将不再作为奖励分配给矿工，而是直接销毁，从而时ETH的经济模型处于通货紧缩的状态，有利于价值的稳定。而另一方面Priorityfee则相当于用户给矿工的打赏，可以自由定价，这一定程度上可以让矿工的排序演算法得到一定程度的复用。随著时间推进到2021年，那时Rollup的发展逐渐进入佳境，我们知道无论OPRollup还是ZKRollup都意味著需要将L2的数据做压缩处理后的某些证明数据通过calldata上传至链上实现数据可用性（DataAvailable）或直接交由链上做验证。
这就让这些Rollup解决方案在维护L2的最终性时面临著很大的Gas成本，而这些成本最终都将转嫁到用户的身上，因此那时大部分的L2协议使用成本并没有想像那么低。同时以太坊也面临著区块空间竞争的窘境，我们知道每个区块存在一个GasLimit，这意味著当前区块中的所有交易的Gas消耗加总不可以超过该值，按当前的GasLimit为30000000来计算，理论上存在30,000,000/16=1,875,000字节的限制，其中16指的是EVM处理每个calldata位元组需要消耗16单位的Gas，也意味著单一区块最多可以承载的资料规模约1.79MB。而L2排序器所产生的Rollup相关资料通常资料规模较大，这就使其与其他主链使用者的交易确认产生竞争，导致单一区块可以打包的交易量变小，进而影响主链的TPS。为了解决这个窘境，核心开发者们于2022年2月5日提出了EIP-4844提案，并在2024年第二季初的Dencun升级后得到了实施。该提案提出了一种新的交易类型，名为BlobTransaction，相较于传统类型的Transaction，BlobTransaction的核心思想是补充了一个新的资料类型，即Blobdata。区别于calldata类型，blobdata不可以被EVM直接，而只能存取其hash，也称为VersionedHash。另外还有两个相伴而来的设计，其一相较于普通交易，blobtransaction的GC周期更短，从而保证区块数据不至于过于臃肿，其二blobdata的具有原生的Gas机制，总体上所呈现的效果与EIP-1559类似，但在数学模型上选择自然指数函数，使其在应对交易规模波动时稳定性上表现较好，因为自然指数函数的斜率亦为自然指数函数，这意味著无论此时网路交易规模处在什么状态，当交易规模快速飙升时，blobgas的basefee反应的更充分，从而有效遏制交易活跃度，同时该函数还有一个重要的特性，当横坐标为0使，函数值为1。
base_fee_per_blob_gas=MIN_BASE_FEE_PER_BLOB_GAS*e**(excess_blob_gas/BLOB_BASE_FEE_UPDATE_FRACTION)其中MIN_BASE_FEE_PER_BLOB_GAS和BLOB_BASE_FEE_UPDATE_FRACTION为两个常数，而excess_blob_gas则由父区块中总的blobgas消耗于一个TARGET_BLOB_GAS_PER_BLOCK常数之间的差值来决定，当总的值差值时，e**(excess_blob_gas/BLOB_BASE_FEE_UPDATE_FRACTION)大于1，则base_fee_per_blob_gas变大，反之则变小。这样对于一些只希望利用以太坊的共识能力为某些规模较大的资料做存证以保证可用性的场景就可低成本的执行，同时不会挤占区块的交易打包能力。以Rollup排序器为例，可以透过blobtransaction将L2的关键资讯封装到blobdata中，并在EVM中透过精巧的设计，利用versionedHash实作链上验证的逻辑。需要补充的是当前TARGET_BLOB_GAS_PER_BLOCK和MAX_BLOB_GAS_PER_BLOCK的设定为主网带来了一个限制，即每个区块的平均处理3个blob(0.375MB)的目标和最多6个blob(0.75MB)的限制。这些初始限制旨在最大限度地减少该EIP对网路造成的压力，并且随著网路在较大区块下展现可靠性，预计将在未来的升级中增加。对于执行环境Gas消耗模型的再细化：EIP-7706在明确了目前以太坊的Gas模型后，我们来看看EIP-7706提案的目标与实施细节。该提案由Vitalik在2024年5月13日提出。
与Blobdata类似，该提案对另一个具有特殊性的资料栏位对应的Gas模型进行了剥离，这个资料栏位即为calldata。并且优化了对应的程式码实作逻辑。从原理上calldata的basefee计算逻辑与EIP-4844中basefeeforblobdata相同，均采用了指数函数并根据父区块中的实际gas消耗值与目标值的偏差值来计算对当前basefee的缩放比例。值得注意的是一个新的参数设计，LIMIT_TARGET_RATIOS=[2,2,4]，其中LIMIT_TARGET_RATIOS[0]表示了执行操作类Gas的目标比率，LIMIT_TARGET_RATIOS[1]表示Blobdata类Gas的目标比率，LIMITIOS_TARGET_RATIOS[1]表示Blobdata类Gas的目标比率，LIMITIOS2]表示calldata类Gas的目标比率，这个向量用来计算父区块中三类gas对应的的gastarget值，计算逻辑如下，即分别使用LIMIT_TARGET_RATIOS对gaslimit做整除操作：其中gas_limits的设定逻辑如下：gas_limits[0]必须遵循现有的调整公式gas_limits[1]必须等于MAX_BLOB_GAS_PER_BLOCKgas_limits[2]必等于gas_limits[0]//CALLDATA_GAS_LIMIT_RATIO我们知道目前gas_limits[0]为30000000，CALLDATA_GAS_LIMIT_RATIO被预设为4，这表示目前calldatagastarget约为30000000//4//4=1875000，又因为以目前逻辑的calldata来计算，零Bytes消耗16Gas，零Bytes消耗4Gas，假设某段calldata中非零与零Bytes的分布各占50%，则平均处理1Bytes的calldata需要消耗10Gas。因此目前的calldatagastarget应对应187500bytes的calldata数据，约为目前平均用量的2倍。这样做的好处在于大幅减少了calldata达到gaslimit的情况发生的机率，透过经济模型使calldata的用量保持在一个较为始终的状态，同时也杜绝了对calldata的滥用。之所以做这样的设计还是为L2的发展扫平障碍，搭配blobdata，使得排序器成本进一步降低。