在以太坊生态系统的持续演进中,以太坊改进提案（EIP）扮演着至关重要的角色，它们是推动以太坊协议升级、扩容和功能完善的核心驱动力，EIP-665虽然不如EIP-1559（费用机制改革）或EIP-4337（账户抽象）那样广为人知，但它提出的一项关于智能合约调用机制的优化，对于提升以太坊网络效率和开发者体验具有潜在的重要意义，本文将深入探讨EIP-665的核心内容、目标及其可能带来的影响。

EIP-665的核心：引入“静态调用”（STATICCALL）指令

EIP-665的全称是“Add STATICCALL to the EVM”，其核心内容是在以太坊虚拟机（EVM）中引入一个新的操作码（Opcode）：STATICCALL。

在理解STATICCALL之前，我们需要先回顾一下EVM中已有的两种主要调用方式：CALL和DELEGATECALL。

  1. CALL：这是最通用的调用方式，允许一个合约调用另一个合约，并且可以在调用过程中发送以太坊（ETH）和修改状态（即写入区块链状态），被调用的合约会执行其代码，并将返回值传回调用者。
  2. DELEGATECALL：这种调用方式与CALL类似，但它是在调用者的上下文中执行被调用合约的代码，这意味着被调用合约可以修改调用者的存储，但不能接收发送的ETH，它主要用于库代码的重用。

在某些场景下,开发者需要一种方式来查询合约状态或执行某些计算，但绝对不希望这些操作意外或恶意地修改区块链的状态，一个合约需要查询另一个合约的某个公共变量值，或者验证某个交易数据是否符合特定规则，而不希望触发任何状态变更。

这正是STATICCALL旨在解决的问题。STATICCALL可以看作是CALL的一个“只读”版本，它允许一个合约调用另一个合约，但具有以下关键特性：

  • 禁止状态修改：在STATICCALL执行期间，被调用的合约以及任何通过STATICCALL间接调用的合约，都不允许执行任何会修改区块链状态的操作，这包括写入存储、发送ETH（除了使用SELFDESTRUCT，且通常也不推荐在静态调用中使用）、创建合约等。
  • 独立上下文：与DELEGATECALL不同，STATICCALL在被调用合约的独立上下文中执行，但调用者的存储状态是可见的（只是不允许修改），这意味着被调用合约可以读取调用者的状态，但不能修改它。
  • 错误处理：如果被调用的合约尝试执行任何状态修改操作，STATICCALL会立即失败，并回滚所有更改，同时返回一个错误。

EIP-665的目标与意义

引入STATICCALL的主要目标包括：

  1. 增强安全性：通过明确区分“可调用修改”和“只读调用”，STATICCALL为开发者提供了更安全的工具来构建复杂的智能合约系统，它可以有效防止意外的状态变更，特别是在需要查询多个合约状态或进行复杂验证的场景下，减少了因调用链中某个合约疏忽导致状态被修改的风险。
  2. 提高效率与确定性：由于STATICCALL保证不会修改状态，以太坊节点在执行时可以对其进行某些优化，更重要的是，只读操作不会产生“状态根”（state root）的变化，这对于某些轻客户端、状态同步工具以及需要频繁查询合约状态的DApp来说，意味着更高的效率和确定性。
  3. 简化开发者逻辑：在使用CALL时，开发者需要自行确保被调用合约不会修改状态，这可能需要仔细审计被调用合约的代码或采取额外的防护措施。STATICCALL将这种“只读”保证内置于EVM层面，简化了开发者的安全考虑，使得“安全查询”变得更加直接和可靠。
  4. 支持更复杂的智能合约模式：STATICCALL为构建更复杂的智能合约架构提供了基础，它可以用于实现“观察者”模式合约，这些合约只读取其他合约的状态并进行聚合或分析；也可以用于构建更安全的跨链桥或预言机系统，其中查询阶段与状态变更阶段明确分离。

EIP-665的实现与影响

EIP-665最初由以太坊开发者Alexey Akhunov提出，并在2017年左右进行了讨论，它最终被包含在以太坊君士坦丁堡（Constantinople）硬分叉升级中，该升级于2019年2月正式激活。

自激活以来,STATICCALL已经成为智能合约开发者工具箱中一个非常有用的操作码，它被广泛用于各种场景，

  • 查询代币余额：一个DeFi协议需要查询某个地址的代币余额，而不希望触发代币合约的转账逻辑（如果代币合约有此类钩子）。
  • 验证交易数据：一个合约需要调用另一个合约来验证某笔交易数据的合法性，确保验证过程不会改变任何状态。
  • 获取合约配置信息：如获取某个DAO的提案详情、某个市场的费率等。

挑战与局限性

尽管STATICCALL带来了诸多好处，但它也有一些需要注意的方面：

  • Gas成本：STATICCALL的gas消耗可能与CALL有所不同，开发者在使用时需要考虑gas成本优化。
  • 循环调用风险：虽然STATICCALL本身禁止状态修改，但如果设计不当，仍然可能导致无限循环的静态调用，最终耗尽gas，开发者仍需注意合约调用的深度和逻辑。
  • 与现有合约的兼容性：对于在STATICCALL引入之前部署的合约，如果它们在被调用时试图修改状态，STATICCALL会直接失败，这意味着开发者在使用STATICCALL调用旧合约时需要格外小心，确保旧合约在被调用时确实是“只读”的。