EIP-1559和EIP-4844所支持的当前热电气体模型
在 Ethereum的初始设计中，为了确定交易成本， Ethereum使用了简单的竞价机制，这就要求使用者对他们的交易进行竞价，即设定 gas价格，一般来说，因为使用者支付的交易成本属于开采者，因此开采者会基于价格的优劣，考虑到经济性，选择交易的先后次序，当然，这是不考虑 MEV的。在那个时候的核心开发人员看来，这个机制有4个缺陷：
·交易成本的波动程度与达成一致的交易成本不一致：对于处于活动中的区块来说，对交易的包装有足够的需要，这表示能够很容易地填充区块，但是这通常也表示总体成本的高度波动。例如，当平均气体价格是10 Gwei，则由于在块中接收另一事务所引起的网络的边际成本将是在平均气体价格是1 Gwei的情况下的10倍，因此这将是不能接受的。
·不需要的用户延迟：因为每一块的流量上限是刚性的，再加上历史流量的自然起伏，一个事务经常需要等上好几个块才能完成，但是这对于整个网络而言效率很低；也就是没有“放松”的机制，可以让一个区域变得较大，另一个区域变得较小，以适应不同区域的不同要求。
·无效率的定价：因为使用了简单拍卖系统，所以没有有效地找到公平的价格，这意味着使用者很难给出一个适当的价格，这意味着在很大程度上使用者会支付更高的费用。
·没有区块奖励的区块链会变得不稳定：如果不给矿工提供区块奖励，而采用纯粹的收费模式，将会产生许多不稳定的因素，比如鼓励矿工去挖出偷取交易金的“姊妹块”，以及激发更加强烈的“自我挖掘”的攻击。
直到EIP-1559的提出和实施， Gas模型才有了第一次的迭代，EIP-1559是 Vitalik和其他开发人员在2019年4月13日提出，在2021年8月5日伦敦地铁更新中采纳的 Gas模型，它抛弃了竞价的方式，而是采用了基础 fee和优先权 fee的双重定价模式，基础 fee是基于父块的 gas消耗量和浮动的递归 gas目标的关系，通过建立的数学模型进行量化，直观的表现是，如果上一块的 gas消耗量超出预先设定的 gas目标，那么基础 fee就会上升，如果低于 gas目标，那么基础 fee就会下降，这种方式不仅能更好地反映供给和需求，而且能更准确地预计 gas的用量，避免了 gas价格虚高的问题，毕竟基础 fee是由系统直接确定的，而不是由用户随意设定。具体的编码方式为：
其中，可知，当parent_gas_use大于parent_gas_target，则将当前块的基础 fee与先前块的基础 fee进行比较，并且将偏置值与先前块的基础 fee进行比较，所述偏置值是将parent_base_fee乘以先前块的 gas的总使用相对于 gas的目标的偏置，并且将 gas的目标与常数进行比较，在与1的余数中获得最大化。反之，逻辑也是如此。
另外， Base fee将不会再以奖金的形式发放到采矿者手中，而是会被直接销毁掉，这样 ETH的经济模式就会在通货紧缩的情况下运行，对价格的稳定性有利。另一方面， Priority fee用作可被任意地标价的、由用户给予挖掘器的奖励，这在某种程度上允许在某种程度上重用挖掘器的分类算法。
到了2021，此时 Rollup的开发已经渐渐步入了正轨，众所周知，不管是 OP Rollup，还是 ZK Rollup，都是将L2中的一些被压缩的论证数据，以呼叫数据的方式上载到链条中，以达到数据的可用度（Data Available)，或直接交付到链条中进行验证。这使得 Rollup解决方案面对维持L2的终极性质所需的大量气体费用，该费用最后会被传递给用户，使得大多数L2协议的使用不会像人们所认为的那样便宜。
另一方面， Ethereum也遇到了块空间争夺的问题，众所周知，每一个块都有一个气体上限，也就是说，当前块内的所有事务的气体消耗总和都不能超过这个上限，以目前的气体上限30000000为例，就是30000000/16=1875000字节，16是 EVM每调用一个字节的气体消耗，也就是，一个块内的数据大小大约是1.79 MB。另一方面，由L2分配器生成的与 Rollup有关的数据一般具有很大的数据大小，这使得它们与其它主节点的用户的事务确认相竞争，从而使得能够封装在一个块中的事务的数量减少，这反过来又会对主节点的 TPS造成影响。
为了解决该问题，在2022年2月5日由内核开发商提交了提议EIP-4844，并且在 Dencun在2024第二季度的早些时候更新之后被执行。该建议提供了被称为 Blob事务的新事务类型，与常规事务类型相比， Blob事务的核心概念是添加了被称为 Blob Data的新型元。与呼叫数据类型不同， Blob数据不能由 EVM直接访问，而是仅能访问其散列，也就是所谓的 VersionedHash。此外，与之配套的还有另外两个设计，第一，相对于正常的事务处理， blob事务处理的 GC循环时间要短一些，以确保区块不会过度膨胀，第二， blob信息的处理具有固有的气体机制，其整体的作用与EIP-1559的作用相似，但是由于采用了自然指数函数作为数学模型，因此，它在处理事务大小变动时的稳定性上更为出色，这是由于自然指数函数的斜率也是自然指数函数，也就是说，不管当时的网路事务大小处于何种状况，一旦事务大小急剧上升， blob气体的基本成分就会得到更加完全的响应，因此，能够有效地抑制事务的活动性，而且，这个函数有一个显著的特征，即在横座标为0的情况下，函数值是1。
base_fe_per_blob_gas=Min_base_fe_per_blob_gas*
e**（访问blob_gas/blob_base/FEE_UPDATE_FRACTION）
其中，MIN_BASE_FEE_PER_BLOB_GAS和BLOB_BASE_FEE_UPDATE_FRACTION是2个常数，通过TARGET_BACT_BLOB_GAS_PER_Block常数与父块内的全部blob_gas的消耗量的差，在全部 blob_gas消耗量大于目标值的时刻，也就是该差为 e**（excess_blob_g/）
Block_base_fee_UPDATE_fracTION）越大，base_fe_per_blob_gas越大，反之亦然。
这样，对于那些仅想要使用 Ethereum的一致性功能来保存一定数量的数据来确保其可用性的情况，就可以在不占用区块的事务封装功能的情况下，以低成本来实现。在 Rollup排序中，L2的密钥信息可以用 blob事务的形式封装在 blob数据中，在 EVM中，通过对 blob数据的巧妙处理，使用 versionedHash进行了链上校验，从而保证了 Rollup排序的正确性。
另外，TARGET_BLOB_GAS_PER_BLOCK和MAX_BLOB_GAS_PER_BLOCK的当前设置对主要网络产生了约束，该约束是，对于每个数据块，3个 Blob （0.375 MB）的平均处理目标和至多6个 Blob （0.75 MB）的约束。这些最初的约束被设计成使这种 EIP施加到网络上的应力最小化，并且被期望在将来的更新中增大，因为网络显示了更大块的可靠性。
EIP-7706：对运行环境中气体消耗量模型的进一步改进
在对目前 Ethereum的气体模式进行了说明之后，接下来我们将对EIP-7706建议的目的和实现进行详细说明。该建议是在20245月13日 Vitalik提交的。类似于 Blob数据，此建议将 Gas模型与另一个特定的数据域相分离，所述特定的数据域是呼叫数据。此外，对对应的编码执行逻辑进行了优化。
原则上，呼叫数据的基本功能运算逻辑与EIP-4844中用于 Blob数据的基本功能是一样的，都是使用索引功能，并且都是基于父块内的实际气体消耗量相对于目标量的偏离值，来计算当前基本功能的放大率。
该矢量LIMIT_TARGE_RATIOS=[2,2,4],LIMIT_TARGE_RATIOS=[0]为运算类 Gas的目标比，LIMIT_TARGE_RATIOS=[1]为 Blob数据类 Gas的目标比，LIMIT_TARGE_RATIOS=[2]为呼叫数据类 Gas的目标比，该矢量被用来计算相应于父块中的3种类型的 gas的 gas目标值，该运算逻辑为：
其中，gas_limit的设置逻辑是这样的：
gas_limit [{0}必须遵守已存在的自适应公式
gas_limit [%1]必须等于MAX_blob=gas_per_blob
gas_limit [2]必须等于gas_limit [0]/CALLDATA_gas_limit
已知目前的gas_限值[0]是30000000,CALLDATA_gas_LIMIT_RATIO是预先设定的4，这表示目前呼叫数据的 gas目标大约是30000000×4×4=1875000，由于根据目前呼叫数据的 gas运算逻辑，非零字节占用16 gas，零字节占用4 gas，假定呼叫数据片段中非的零与零字节的分配比例是50%，那么1字节的呼叫数据的平均处理成本是10 gas。因此，当前呼叫数据 gas目标应该相应于187500字节的呼叫数据，这是目前使用的平均量的大约两倍。
这具有显著地降低呼叫数据到达 gas极限的可能性的优点，并且利用经济模型将呼叫数据的使用量维持在相对恒定的水平，并且还防止了呼叫数据的过度使用。之所以如此设计，还是为了给L2的开发扫清道路，与 Blob数据相结合，从而使定序器的成本更低。