如何确保强制交易模拟执行与真实执行的一致性

bitfinding
发布于 4小时前
阅读 49

文章讨论了在区块链交易中模拟执行与实际执行之间状态差异的问题。提出了一种通过在交易中附加状态约束来解决此问题的方法，这些约束在交易执行前进行检查，确保交易在符合预期状态的条件下进行，从而提高交易的安全性和可靠性。文章还探讨了EIP-7702等以太坊改进提案如何为此方法提供更好的用户体验和效率

想象一下，你即将在一个去中心化交易所 (DEX) 上将大量的 ETH 兑换成 USDT。你使用钱包的模拟功能，它显示你将收到 1000 USDT，这是一个不错的汇率！你签名并发送。但是当你的交易到达链上时，一笔大额交易已经改变了池子的储备，你的交易要么回滚，要么只能获得 950 USDT。这种令人沮丧（且可能代价高昂）的情况凸显了一个关键缺陷：**模拟提供的是一个快照，但区块链是一个不断变化的目标**。

![](https://img.learnblockchain.cn/2025/06/25/maybe_simulation.svg)

你的区块链交互的安全性越来越依赖于验证这些模拟结果。然而，核心问题是它们无法强制执行**模拟和实际执行之间的**状态一致性**。这种差距可能导致漏洞，尤其是在关键合约状态（如代理实现或 DEX 储备）意外更改时。

现在 Pectra 已经在一个交易中启用了多个批量调用，使得模拟变得更加复杂，这个问题只会变得更严重。

#### 核心问题：状态分歧

核心挑战是**状态分歧**：关键的智能合约状态可能会在你模拟交易和实际在区块链上挖掘交易之间发生内在或对抗性的改变。

> ```plaintext
> s0 = (calldata, contracts, state0)
> s1 = (calldata, contracts, state1)
> exec(s0) != exec(s1)
> ```

以下几种情况说明了这种风险：

1. **代理升级**：假设你正在与使用代理合约（允许逻辑升级）的 NFT 市场进行交互。你模拟列出一个 NFT。如果在模拟和执行之间，市场升级了它的实现合约，那么新的逻辑可能会以不同的方式解释你的数据或更改费用，从而导致意外的结果，例如资金丢失或不正确的列表。

2. **DEX 储备转移**：你模拟在 Uniswap 上将 1 ETH 兑换为 USDT，根据当前的储备，预计可获得 3000 USDT。如果在你的交易之前发生了一笔大额交易，导致池子储备发生转移，你的 1 ETH 可能只会产生 2950 USDT，或者该交易可能会因滑点而回滚。

3. **Oracle 值更新**：许多 DeFi 协议使用 Oracle 获取价格信息（例如，ETH/USD）。你模拟使用抵押品进行借款，并且模拟时的 Oracle 价格是有利的。如果由于市场波动或操纵，Oracle 在执行前更新了你的抵押品的较低价格，你的交易可能会失败或使你立即面临清算的风险。

#### 攻击对模拟的依赖

钱包和安全工具越来越依赖交易模拟来保护用户。通过预览复杂智能合约交互的结果，模拟旨在防止用户签署恶意交易。然而，这种依赖引入了其自身的一系列挑战和潜在漏洞。

![TODO](https://img.learnblockchain.cn/2025/06/25/63848474_image.jpg)

[Zengo 受以太坊基金会资助的一份白皮书](https://zengo.com/wp-content/uploads/Web3-Transaction-Simulation-White-Paper-Final.pdf)强调了关键的局限性。虽然模拟是一个有价值的工具，但它并非万无一失。攻击者可以利用理论上的限制和实际的实现问题。一个值得注意的漏洞是“红丸攻击”，在这种攻击中，恶意合约检测到它正在模拟环境中运行。它在模拟过程中表现得很温和，使使用者产生虚假的安全感，然后在实际的区块链上执行其恶意负载。这种欺骗可能导致用户批准他们认为安全的有害交易。

这强调了虽然模拟增强了安全性，但如果对其局限性没有被理解和解决，它们也会创建一个具有欺骗性的安全网。**模拟环境本身的完整性成为了复杂攻击者的目标**。

#### 进入状态约束

为了更稳健地弥合这种从模拟到执行的差距，我们建议交易不仅携带它们的执行数据（“做什么”），还携带一组紧凑的**状态约束**（“在这些条件下”）。这些约束充当链上的守卫：交易在继续之前声明它们，如果来自你的模拟的底层假设不再成立，则提前回滚。

这些约束可以使用一种特定领域语言 (DSL) 编写，该语言被设计为具有表现力但又简单：

| 约束 | 描述 |
| --- | --- |
| `TokenAddress.balanceOf($AccountAddress) >= 10000` | 检查预期的 Token 余额。 |
| `ProxyAddress.implementation() == $ExpectedImplementationAddress` | 验证代理的逻辑是否已更改。 |
| `block.timestamp < 1720000000` | 充当时间敏感型交易的软截止日期。 |
| `storageSlot($ContractAddress, $StorageSlot) == $ExpectedValue` | 确保特定存储槽保持不变，稍后会详细介绍！ |

在运行时，首先执行这些约束检查。**如果全部通过，则主交易逻辑继续执行。如果任何一个失败，整个交易都会回滚，从而防止意外的结果**。

#### 循序渐进：从模拟到可信执行

让我们通过我们的 DEX 交易和代理升级示例来了解这是如何工作的。

**1\. 交易模拟与意图表示**

当你发起一笔交易时，你的钱包软件会执行一次模拟。至关重要的是，该工具还会识别你的交易**依赖于**的关键区块链状态，例如**存储、环境、余额、nonce 等**。这些都使用 DSL 转换为条件。

• **DeFi 交易示例**：将 1 ETH 兑换为至少 2950 USDT。模拟显示基于当前储备为 3000 USDT。

• **代理升级示例**：以 5 ETH 的价格列出一个 NFT。模拟使用市场实现 `$GOOD_CONTRACT_V1`。

![TODO](https://img.learnblockchain.cn/2025/06/25/diagram.svg)

**2\. 提取状态约束**

模拟引擎分析依赖的状态并将其提取为显式约束。

• **DeFi 交易示例 DSL**：

> ```plaintext
> // 前置条件：确保 DEX 池状态符合预期
> 900 < WETH.balanceOf($PairAddress) < 1100
> 2,900,000 < USDT.balanceOf($PairAddress) < 3,100,000
> // 后置条件：确保用户收到最少的 USDT
> USDT.balanceOf($UserAddress) >= $oldBalanceOfUSDT + 3000
> ```

• **代理升级示例约束**：

> ```plaintext
> // 前置条件：确保代理实现与模拟匹配
> MarketProxyAddress.implementation() == $GOOD_CONTRACT_V1
> ```

**3\. 交易打包**

使用用户钱包提供的 multicall (ERC-4337 UserOperation) 或委托给合约 (EIP-7702) 打包最终的交易（带有约束）。这有效地将交易构造为：

> ```plaintext
> [约束预检查] -> [原始交易逻辑] -> [约束后检查（可选）]
> ```

**4\. 签署增强后的交易**

用户现在可以在不同的设置中模拟交易。结果将要么保持符合用户的预期，要么在链上条件不再与模拟匹配时回滚。用户会看到一个模拟结果，类似于钱包显示的内容，但是这个结果是可以信任的，因为约束与交易捆绑在一起。在用户签名之前，将显示包括约束在内的整个包以供审查。

**5\. 链上约束强制执行**

执行时：预检查将当前链上状态与你的约束进行比较。例如，如果 DEX 储备转移过多或代理已更改，则约束失败。如果发生任何违规，交易会在主逻辑运行**之前**回滚。如果全部通过，则执行主逻辑，然后进行后置条件检查。

#### 为什么这行得通（现在更好）

由于最近以太坊的改进，这种嵌入状态约束的方法变得特别强大且用户友好，提供了几个关键优势：

**• 原子性和改进的用户体验**：Pectra 升级通过 EIP-7702，**使智能账户功能可以通过委托供 EOA 访问**。 这允许将多个调用（约束检查**和**主要操作）捆绑到一个原子交易中，从而确保通过单个签名进行全有或全无的执行。

**• 向后兼容性**：此系统适用于现有的智能合约。约束检查逻辑存在于一个单独的合约中，该合约只需要使用要检查的约束进行额外的调用。

**• 成本效益**：在同一交易中多次读取存储或调用 `view` 函数相对便宜。这些检查的 Gas 费用通常是提高安全性的一个小代价。

**• 细粒度的控制**：你可以对关键状态（如代理的实现）强制执行完全匹配，并对可变状态（如滑点容差范围内的 DEX 储备）强制执行可接受的范围。

#### 梦想：底层存储检查

目前，状态检查通常依赖于公共 `getter` 函数。这是有限的，因为合约必须通过真实的取值函数公开状态，并且跨合约调用可能消耗大量 Gas。例如，如果代理没有公开 `implementation()` 函数，我们就无法检查它！

为了真正稳健、通用且 Gas 高效的强制执行，需要直接、底层地访问以从其他合约读取原始存储：**EXTSLOAD** 操作码的概念[如先前在本 EIP 中讨论的那样](https://eips.ethereum.org/EIPS/eip-2330)将解决所有这些挑战。

或者，像 **`IExtsload`** 这样的标准化接口（例如，在 UniswapX/Uniswap v4 研究中）也提供了 Gas 高效的批量状态读取：

> ```solidity
> interface IExtsload {
>     function extsload(bytes32 slot) external view returns (bytes32 value);
>     function extsload(bytes32 startSlot, uint256 nSlots) external view returns (bytes32[] memory values);
>     function extsload(bytes32[] calldata slots) external view returns (bytes32[] memory values);
> }
> ```

虽然仍然是合约调用，但标准化将提高效率。原生 EVM 支持将是最终目标。

#### 总结与下一步

在动态的区块链世界中，强制执行交易模拟的完整性对于用户安全至关重要。

• 模拟和执行之间的状态分歧至关重要。

• 将显式状态约束附加到交易充当链上安全保障，确保假设成立。

• EIP-7702、ERC-4337 和 EIP-5792 提供了理想的框架，用于以原子方式且具有良好的用户体验将约束检查与主交易逻辑捆绑在一起。

• 这种方法是向后兼容的，并且可以节省 Gas 成本，使其适用于广泛采用。

• 未来对直接外部状态读取的 EVM 改进将使这种方法更加强大和经济。

在 Bitfinding，我们是**低级 EVM 执行安全和优化的专家**。我们正在使用我们的[模拟引擎](https://learnblockchain.cn/article/17303)对这些状态约束原则进行原型设计。我们正在积极致力于推动 EVM 生态系统的发展，以通过研究和创新服务来防止黑客攻击。

**如果你有兴趣集成此解决方案来保护你自己或你的用户，或者想讨论如何使你的 dApp 交互更安全，我们欢迎你的反馈或探索合作。**

>- 原文链接： [bitfinding.com/blog/enfo...](https://bitfinding.com/blog/enforcing-transaction-simulation)
>- 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～

想象一下，你即将在一个去中心化交易所 (DEX) 上将大量的 ETH 兑换成 USDT。你使用钱包的模拟功能，它显示你将收到 1000 USDT，这是一个不错的汇率！你签名并发送。但是当你的交易到达链上时，一笔大额交易已经改变了池子的储备，你的交易要么回滚，要么只能获得 950 USDT。这种令人沮丧（且可能代价高昂）的情况凸显了一个关键缺陷：模拟提供的是一个快照，但区块链是一个不断变化的目标。

你的区块链交互的安全性越来越依赖于验证这些模拟结果。然而，核心问题是它们无法强制执行模拟和实际执行之间的状态一致性**。这种差距可能导致漏洞，尤其是在关键合约状态（如代理实现或 DEX 储备）意外更改时。

现在 Pectra 已经在一个交易中启用了多个批量调用，使得模拟变得更加复杂，这个问题只会变得更严重。

核心问题：状态分歧

核心挑战是状态分歧：关键的智能合约状态可能会在你模拟交易和实际在区块链上挖掘交易之间发生内在或对抗性的改变。

s0 = (calldata, contracts, state0)
s1 = (calldata, contracts, state1)
exec(s0) != exec(s1)

以下几种情况说明了这种风险：

代理升级：假设你正在与使用代理合约（允许逻辑升级）的 NFT 市场进行交互。你模拟列出一个 NFT。如果在模拟和执行之间，市场升级了它的实现合约，那么新的逻辑可能会以不同的方式解释你的数据或更改费用，从而导致意外的结果，例如资金丢失或不正确的列表。
DEX 储备转移：你模拟在 Uniswap 上将 1 ETH 兑换为 USDT，根据当前的储备，预计可获得 3000 USDT。如果在你的交易之前发生了一笔大额交易，导致池子储备发生转移，你的 1 ETH 可能只会产生 2950 USDT，或者该交易可能会因滑点而回滚。
Oracle 值更新：许多 DeFi 协议使用 Oracle 获取价格信息（例如，ETH/USD）。你模拟使用抵押品进行借款，并且模拟时的 Oracle 价格是有利的。如果由于市场波动或操纵，Oracle 在执行前更新了你的抵押品的较低价格，你的交易可能会失败或使你立即面临清算的风险。

攻击对模拟的依赖

Zengo 受以太坊基金会资助的一份白皮书强调了关键的局限性。虽然模拟是一个有价值的工具，但它并非万无一失。攻击者可以利用理论上的限制和实际的实现问题。一个值得注意的漏洞是“红丸攻击”，在这种攻击中，恶意合约检测到它正在模拟环境中运行。它在模拟过程中表现得很温和，使使用者产生虚假的安全感，然后在实际的区块链上执行其恶意负载。这种欺骗可能导致用户批准他们认为安全的有害交易。

这强调了虽然模拟增强了安全性，但如果对其局限性没有被理解和解决，它们也会创建一个具有欺骗性的安全网。模拟环境本身的完整性成为了复杂攻击者的目标。

进入状态约束

为了更稳健地弥合这种从模拟到执行的差距，我们建议交易不仅携带它们的执行数据（“做什么”），还携带一组紧凑的状态约束（“在这些条件下”）。这些约束充当链上的守卫：交易在继续之前声明它们，如果来自你的模拟的底层假设不再成立，则提前回滚。

这些约束可以使用一种特定领域语言 (DSL) 编写，该语言被设计为具有表现力但又简单：

约束	描述
`TokenAddress.balanceOf($AccountAddress) >= 10000`	检查预期的 Token 余额。
`ProxyAddress.implementation() == $ExpectedImplementationAddress`	验证代理的逻辑是否已更改。
`block.timestamp < 1720000000`	充当时间敏感型交易的软截止日期。
`storageSlot($ContractAddress, $StorageSlot) == $ExpectedValue`	确保特定存储槽保持不变，稍后会详细介绍！

在运行时，首先执行这些约束检查。如果全部通过，则主交易逻辑继续执行。如果任何一个失败，整个交易都会回滚，从而防止意外的结果。

循序渐进：从模拟到可信执行

让我们通过我们的 DEX 交易和代理升级示例来了解这是如何工作的。

1. 交易模拟与意图表示

当你发起一笔交易时，你的钱包软件会执行一次模拟。至关重要的是，该工具还会识别你的交易依赖于的关键区块链状态，例如存储、环境、余额、nonce 等。这些都使用 DSL 转换为条件。

• DeFi 交易示例：将 1 ETH 兑换为至少 2950 USDT。模拟显示基于当前储备为 3000 USDT。

• 代理升级示例：以 5 ETH 的价格列出一个 NFT。模拟使用市场实现 $GOOD_CONTRACT_V1。

2. 提取状态约束

模拟引擎分析依赖的状态并将其提取为显式约束。

• DeFi 交易示例 DSL：

// 前置条件：确保 DEX 池状态符合预期
900 &lt; WETH.balanceOf($PairAddress) &lt; 1100
2,900,000 &lt; USDT.balanceOf($PairAddress) &lt; 3,100,000
// 后置条件：确保用户收到最少的 USDT
USDT.balanceOf($UserAddress) >= $oldBalanceOfUSDT + 3000

• 代理升级示例约束：

// 前置条件：确保代理实现与模拟匹配
MarketProxyAddress.implementation() == $GOOD_CONTRACT_V1

3. 交易打包

使用用户钱包提供的 multicall (ERC-4337 UserOperation) 或委托给合约 (EIP-7702) 打包最终的交易（带有约束）。这有效地将交易构造为：

[约束预检查] -> [原始交易逻辑] -> [约束后检查（可选）]

4. 签署增强后的交易

5. 链上约束强制执行

执行时：预检查将当前链上状态与你的约束进行比较。例如，如果 DEX 储备转移过多或代理已更改，则约束失败。如果发生任何违规，交易会在主逻辑运行之前回滚。如果全部通过，则执行主逻辑，然后进行后置条件检查。

为什么这行得通（现在更好）

由于最近以太坊的改进，这种嵌入状态约束的方法变得特别强大且用户友好，提供了几个关键优势：

• 原子性和改进的用户体验：Pectra 升级通过 EIP-7702，使智能账户功能可以通过委托供 EOA 访问。这允许将多个调用（约束检查和主要操作）捆绑到一个原子交易中，从而确保通过单个签名进行全有或全无的执行。

• 向后兼容性：此系统适用于现有的智能合约。约束检查逻辑存在于一个单独的合约中，该合约只需要使用要检查的约束进行额外的调用。

• 成本效益：在同一交易中多次读取存储或调用 view 函数相对便宜。这些检查的 Gas 费用通常是提高安全性的一个小代价。

• 细粒度的控制：你可以对关键状态（如代理的实现）强制执行完全匹配，并对可变状态（如滑点容差范围内的 DEX 储备）强制执行可接受的范围。

梦想：底层存储检查

目前，状态检查通常依赖于公共 getter 函数。这是有限的，因为合约必须通过真实的取值函数公开状态，并且跨合约调用可能消耗大量 Gas。例如，如果代理没有公开 implementation() 函数，我们就无法检查它！

为了真正稳健、通用且 Gas 高效的强制执行，需要直接、底层地访问以从其他合约读取原始存储：EXTSLOAD 操作码的概念如先前在本 EIP 中讨论的那样将解决所有这些挑战。

或者，像 IExtsload 这样的标准化接口（例如，在 UniswapX/Uniswap v4 研究中）也提供了 Gas 高效的批量状态读取：

interface IExtsload {
    function extsload(bytes32 slot) external view returns (bytes32 value);
    function extsload(bytes32 startSlot, uint256 nSlots) external view returns (bytes32[] memory values);
    function extsload(bytes32[] calldata slots) external view returns (bytes32[] memory values);
}

虽然仍然是合约调用，但标准化将提高效率。原生 EVM 支持将是最终目标。

总结与下一步