这篇文章将介绍一些可以考虑删除的功能的例子。

功能列表

2300 gas 津贴

这是什么？

当一个合约调用另一个合约时，被调用的合约会得到 2300 gas 用于执行非常有限的操作（足够做一点计算和生成一条日志，但不够写满一个存储槽）

为何引入？

最初是为了让智能合约钱包在收钱时能自动生成一条日志。后来还被用于实现 「守卫」 功能以防止合约收到 ETH。

有何问题？

• 由于它设置的是固定的 gas 数量，因此只要 gas 价格可以调整，人们就没有办法确定这些 gas 到底能支持什么类型的计算。

• 它并没有很好地满足设计意图，有两个原因。首先，很多用户仍然在使用外部账户，而外部账户并不会生成日志。其次，SELFDESTRUCT 操作码绕过了津贴机制。从长远来看，通过账户抽象化，外部账户的作用将被弱化，并且 SELFDESTRUCT 操作码可能将被移除，但是在这两件事完成之前，它都只是一个不充分的解决方式。

如何移除？

有两种可能 —— 要么将 2300 改成 0 （不支持子执行（child execution））要么不限制数量（子执行可以从父执行中获得全部的 gas 可用额度）

移除有何副作用？

• 如果我们移除子执行，那么这将需要在合约调用中添加一个笨拙的二分处置（two-clause mechanic），即 0 gas 解释为 0，任何其他数字解释为 「发送所有的 gas」。它还会破坏反接收守卫功能和日志记录。

• 如果我们在执行中允许子执行获得全部的 gas，那么通过调用发送 ETH 会变成一个需要信任的操作，恶意合约可能会借此扰乱一些应用。不过，Solidity 文档已经建议大家用 withdrawal 模式代替 transfer，这样就不会有任何风险了。

如何消除顾虑？

• 让所有的 ETH 转账，无论是来自调用还是 SELFDESTRUCT（如果保留的话），都生成一条日志，这样钱包就不需要生成日志了

• 增加一条规则，对于提供 0 gas 的调用，可看做是一个 「可以生成日志的 STATICCALL」。这样就复制了在 gas 津贴的执行环境里实际做到的功能。

剩余 Gas 额度可见性

这是什么？

GAS 操作码允许合约查看当前的执行环境中还剩多少 gas 可用。CALL 允许调用者为子上下文提供固定数量的 gas。

为何引入？

反对让 CALL 将父环境中剩余的全部 gas 都交给子环境的最主要原因是避免 「不可信任的调用」：即发送者不信任接受者的调用。一个简单的例子是发送 ETH 给参与方的金融机制。另一个例子是 M-of-N 外部价格信息的输入机制（oracle），通过调用一些合约，在获得所有合约回复后取中位数作为输出。 (责任编辑：admin)