这是否意味着我们在使用带有访问列表的交易时总是能节省gas消耗？并非如此，因为我们还要为访问列表中的地址支付gas成本（在我们的示例中是""）

已访问地址

以上，我们只讨论了SLOAD和SSTORE操作码，但这些并不是柏林硬分叉之后唯一改变的操作码。例如，原先调用操作码的固定成本为700 gas。但是在实施EIP-2929之后，如果地址不在访问列表中，则开销就是2600 gas，但如果是在已访问列表中，则开销就是100 gas。而且，与已访问存储密钥一样，之前访问该地址的操作码并不重要（例如，如果先调用EXTCODESIZE，则该操作码将花费2600 gas，使用相同地址的任何后续EXTCODESIZE、CALL、STATICCALL将花费100 gas）。

这是如何受到访问列表交易的影响的？例如，如果我们将一笔交易发送至合约A，而该合约调用另一个合约B，那么我们可以包含如下访问列表：

我们必须支付2400 gas的费用才能将这个访问列表包含在交易中，但是第一个使用B地址的操作码将花费100 gas（而不是2600gas）。所以我们这样做就节省了100 gas，如果B以某种方式使用它的存储，并且我们知道它将使用哪些密钥，那么我们还可以将它们包括在访问列表中，并为每个密钥节省100/200的gas（取决于第一个操作码是SLOAD还是SSTORE）。

但我们为什么要谈另一个合约呢？我们调用的合约怎么了？我们为什么不这样做？

我们可以这样做，但这是不值得的，因为EIP-2929指定了被调用的合约地址（即tx.to）总是包含在accessed_addresses列表中，因此这只会白白浪费2400 gas。

让我们再次分析上一节的示例：

这实际上是浪费，除非我们包含多个存储密钥。如果我们假设一个SLOAD总是首先使用一个存储密钥，那么我们至少需要24个存储密钥才能实现收支平衡。

显然，分析并创建这样的一个访问列表是没有意义的。幸运的是，我们有更好的方法。

eth_createAccessList RPC方法

Geth（从1.10.2版本开始）包含了一个新的ethu createAccessList RPC方法，其可以用来生成访问列表。它的用法类似于eth_estimateGas，但它不是用于估算gas，而是返回如下内容：

也就是说，它为你提供了该交易将使用的地址和存储密钥的列表，以及如果包含访问列表，则会消耗的gas。（而且，与eth_estimateGas一样，这是一种估计值，在实际进行交易时，列表可能会更改。）

我想，随着时间的推移，我们会发现执行此操作的正确方法是什么，而我的伪代码猜测是： (责任编辑：admin)