那个这个设计对带有访问清单的事务有何影响？假设我们向合约A发送一条交易，而合约A调用了合约B，而我们在访问清单中写入这样的内容：

我们首先需要为在这条事务的访问清单中加入这个地址支付2400 gas，但对B使用的第一个操作码就只需要消耗100 gas而不是2600 gas，这就剩下了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）开始将包含一个新的eth_createAccessList RPC方法，你可以用它来生成访问清单，就像使用eth_estimateGas一样，只不过返回的不是Gas消耗量估计，而是形如这样的数据。

我估计随着时间推移，我们会越来越知道怎么利用这个功能，但我个人估计，方法的伪代码形式会像这样。

防止合约变砖

值得提醒，访问清单功能的主要目的不是节省Gas。如该EIP自身所述：

缓解由EIP-2929带来的合约变砖风险，因为事务可以预先指定、预先支付自身尝试范文的账户和存储槽，因此，在实际的执行中，SLOAD和EXT*操作码都只会消耗100 gas：这个值低到既足以防止2929打破某些合约，也可以“解封”被EIP-1884封印的合约。

原本，只要一个合约预设了执行的Gas开销，操作码的Gas消耗量变动就有可能导致它变砖。比如，如果一个合约预设另一个合约的someFunction只会用到34500 gas，因此总是用someOtherContract.someFunction{gas:34500}()调用那个合约，这个合约就有可能变砖。但只要你在事务中添加合适的访问清单，这个合约就还能工作。

自己验证

如果你想自己测试一下，克隆这个仓库，这里面有很多例子，可以使用Hardhat和Geth客户端来运行。请仔细阅读README。