如果在Near合同中，我写入存储中的密钥，然后在一个事务中全部删除同一密钥，那么与我写入密钥并在单独的事务中删除密钥相比，天然气成本是否更低？它可能更便宜的原因是，在运行时级别上，如果事务前后的状态相同(中间状态可能在内存内部(，则无需更改存储。
目前，成本是相同的。智能合同费用的一般规则是在操作发生前立即扣除天然气，因为否则，如果我们推迟了某项操作的成本，那么有人可以创建一个尝试10000次(或其他大量(操作的合同，而它只附带了一次天然气。然后，一旦试图扣除费用，合同将失败，但它将产生比实际支付的CPU成本多10000的CPU成本，这可以用来"；研磨"；区块链，通过发布廉价交易来堵塞所有区块。更糟糕的是，它将打破燃烧气体反映块执行时间的不变。在这种情况下，我们的区块将开始需要超过1秒的时间来执行，从而在共识中产生复杂的网络效果。
与其他合约操作相比，存储操作是特殊的，因为大部分CPU计算(将状态写入Rocksdb并重新计算merkle散列(不是在合约调用主机函数时发生的，而是在区块最终确定时发生的。这意味着我们可以将存储成本的扣除推迟到合同执行的最后，然后如果通过删除来恢复键值的写入，我们可以避免扣除大笔费用。然而，也有一些注意事项：
- 写键值的操作仍然需要花费一些成本，因为仅仅调用一个主机函数和"调度"；键值的写入仍然会产生一些CPU成本，即使这些成本很小。因此，我们需要将关键价值费用分为两类：即时费用和延迟费用。这将需要协议升级，并将使运行时更加复杂
- DevX可能会变得更加不可预测，因为我们正在打破常识不变。目前，合同可以要求
env::used_gas()燃烧了多少天然气，开发商知道这个数字只会增加。如果我们让键值成本变得懒惰，这个数字有时会减少(当键值被删除时(，或者它不会反映即将燃烧的气体
因此可以考虑协议升级以使键值写入成本延迟(只要符合https://gov.near.org/t/quality-control-for-protocol-api-changes/1941)但需要有一个适当的理由(例如，EVM将便宜得多(，因为这将是一种权衡：我们将以使运行时更加复杂(从而可能阻碍我们的速度(和使DevX更加混乱为代价来提高性能。