我们将需要支付 2400 gas 以把这个访问列表加入到交易里，但之后使用 B 地址的第一个操作码只消耗 100 gas，而不是2600。因此，我们通过这样做节省了 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。（像 eth_estimateGas，这是一个估值，当交易实际上被挖的时候，这个列表可能会改变。）但，这并不代表 gas 消耗量会低于在没有访问列表情况下发送同一笔交易所消耗的！
我想我们会随着时间推移发现使用它的正确方法，但我猜的伪代码如下：
给合约松绑
值得一提的是，访问列表的主要目的不在于使用 gas。如 EIP 所解释：
减轻由 EIP-2929 引入的合约断裂风险，因为交易可以提前指定交易计划访问的账户和存储 slot 并提前支付；最终在实际执行中，操作码 SLOAD 和 EXT*只消耗 100 gas：这个低 gas 消耗不仅可以防止由该 EIP 引起的断裂，还可以“松开”任何因 EIP-1884 而受限的合约。
这意味着如果一个合约对执行某事务的成本做了假设，gas 成本的增加就可能使它停止运作。例如，一个合约调用另一个合约，像这样someOtherContract.someFunction{gas: 34500}()，因为它假设someFunction 会准确消耗 34500 gas，这样它会出问题。但如果你添加了一个合理的访问列表，那么合约会再次运作。
自己做检验
如果你像自己去测试，复制这个代码库，里面由多个可以用 Hardhat 和 geth 执行的实例。在 README 查看说明。
参考文献
EIP-2929 和 EIP-2930 是与本文相关的两个柏林硬分叉 EIP。
EIP-2930 依赖于柏林硬分叉的另一部分： EIP-2718，它又叫类型交易。
EIP-2929 参考了很多 EIP-2200，因此如果你想深入了解 gas 成本，你可以从那里开始。