可验证的EVM脚本：从交易到可组合的多链程序

尽管以太坊工具在过去几年取得了进展，但构建用户友好的、可用于生产环境的 dApp 仍然感觉不必要地困难。自托管钱包的用户体验非常复杂，而智能合约的约束、安全审计和有限的可升级性也减慢了开发工作流程。当前的堆栈是可用的，但已过时——开发者们正在感受到这种摩擦。

让我们从用户体验问题开始。一个常见的 DeFi 流程，比如向借贷市场提供 token，通常需要多个步骤：

• 首先，用户批准 token。
• 然后他们签署供应交易。
• 如果操作涉及另一条链，他们可能需要桥接，再次确认，并支付目标网络上的 gas 费用。

每次签名和钱包交互都是一个摩擦点。在第二次交互后，完成率会急剧下降。如果用户在正确的链上缺少 ETH 怎么办？流程完全中断。

现在考虑一下开发者的体验。假设你想把这个多步骤的流程简化为一键操作。你可能会编写和部署新的智能合约。这意味着：

• 跨多条链的测试和 QA
• 发布前的审计周期
• 智能合约的重新部署，以便进行任何更新或修复错误

在实践中，这会将一个简单的功能变成数周的开发——仅仅是为了改善用户体验。

为什么目前的模型存在不足

这些挑战的根源在于以太坊的交易模型。每笔交易都是一个 {to, value, data} 元组：

• 它在单个合约上执行单个函数调用
• 发送者必须支付 gas 费
• 它只对一条链有效

因此，捆绑多个依赖的操作（例如，swap + supply）需要一个 Solidity 实用程序合约或应用层编排。这两种选择都不灵活且难以维护。

ERC-4337：有意义的一步

ERC-4337（账户抽象）旨在将交易发送者与 gas 支付者分离，并启用更高级的功能：

• 批量执行：一个签名下的多个操作
• Gas 抽象：赞助交易或使用 ERC-20 token 支付

这些功能使得改善用户体验和减少用户摩擦成为可能，通过捆绑批准和操作。然而，ERC-4337 在几个关键方面仍然受到限制。

为什么批量处理模型存在不足

ERC-4337 批量处理模型是静态的、顺序的。批处理中的每个操作都必须提前知道并进行编码，而无法响应先前调用的结果。在构建流程时，如果早期步骤的输出会影响下一步，这是一个重大的限制。

例如，考虑常见的 DeFi 工作流程：

1. 在 Uniswap 上将 WETH 兑换为 USDC
2. 将收到的 USDC 提供给 Aave

在 ERC-4337 批处理中，你需要硬编码要提供的 USDC 数量。但是这个数量不是提前确定性地知道的——它取决于运行时的条件，比如滑点或 MEV 效应。实际收到的金额可能与预期有很大差异。

如果你编码的供应金额大于收到的金额，交易将会回滚。如果你保守地猜测，你可能会让价值闲置在智能账户中。

像在批处理之外链接交易或部署自定义合约以在运行时计算输出这样的变通方法，又带回了 4337 旨在消除的复杂性和摩擦。在批处理中，没有对动态注入参数、流控制或提前终止的本地支持。

此外，4337 仅限于单链环境。跨链批量处理、排序执行以及链之间的状态依赖关系不在范围内。因此，虽然 4337 改进了单链交互的基本用户体验，但它没有解决多步骤、动态或多链 DeFi 操作的核心复杂性。

更好的模型：可验证的多链脚本

可验证的脚本将智能账户模型提升到了一个新的水平。开发者可以编写动态的、有条件的和可组合的执行脚本，而不是将交易编码为静态元组。这些脚本可以：

• 读取运行时值（例如，余额、预言机价格）
• 注入计算后的参数
• 使用控制流（if、else、提前退出）
• 在单个逻辑操作中跨越多条链

脚本使用链上函数的抽象，用 TypeScript 编写。结果被编译成可验证的、经过 Merkle 哈希处理的字节码，可以由 relayer 签名和执行。

示例：限价单 + 供应

1. 在 Uniswap 上将 WETH 兑换为 USDC（在 Optimism 上）
2. 如果输出 < 2500 USDC，则回滚
3. 否则，将所有 USDC 提供给 Aave

这个流程过去需要一个自定义合约。现在它是一个脚本，可以编写、测试和推送，而无需任何链上部署。开发者可以在执行前使用测试网或主网分叉来模拟流程。

扩展到多链工作流程

可验证脚本的真正威力体现在多链环境中。现代 dApp 在 L1、L2 和 AppChain 之间进行交互。通过脚本，开发者可以将多链流程编码为一个逻辑单元，并通过以下方式强制执行排序：

• Merkle 编码：每个函数调用指令都被哈希；然后将哈希值哈希到 Merkle 树中。用户通过使用其私钥签署 Merkle 树根哈希来批准整个序列。
• 前提条件：每个指令的执行都受到链上可验证条件（例如，balanceOf(token) > X）的限制。
• 异步 Relayer：Relayer 模拟直到满足前提条件，然后执行指令。

示例：跨链收益流程

1. 在 Optimism 上将 WETH 兑换为 USDC
2. 通过 Across 将 USDC 桥接到 Base
3. 在 Morpho 上供应（Base）
4. 质押产生收益的 token

此流程中的每个步骤可能发生在不同的链上，在不同的时间——但整个过程都是预先签名和授权的。

图灵完备和存储感知

可验证脚本中的所有执行都完全在链上发生。每个条件分支、循环和运行时变量解析都被编码到提交给区块链的 callData 中。没有脱链执行逻辑、模拟回退或隐式客户端编排。整个脚本都是编码和可验证的。

Relayer 不会自己执行逻辑——它们通过调用一个特殊的 execute 函数，将 callData 直接发布到用户的智能账户。这意味着执行发生在用户自己的账户的沙盒环境中，完全与外部副作用隔离，并受到与任何智能合约调用相同的保证的保护。

这种架构确保：

• 逻辑是防篡改的和公开可验证的
• 所有运行时条件都在链上强制执行
• 状态转换和输出是确定性的

脚本引擎可以执行条件分支、循环和变量存储——使用智能账户本身的存储槽。这使得以下操作成为可能：

• 重用中间值（例如，步骤 1 中使用的 token 数量用于步骤 3）
• 根据运行时状态执行自适应逻辑

脚本引擎可以执行条件分支、循环和变量存储——使用智能账户本身的存储槽。这使得以下操作成为可能：

• 重用中间值（例如，步骤 1 中使用的 token 数量用于步骤 3）
• 根据运行时状态执行自适应逻辑

使用简单的构建块，这可以实现完全的图灵完备性——完全从客户端进行编程。

Gas 抽象和用户体验的简单性

从用户的角度来看，一切都发生在一个步骤中：

• 一个签名授权完整的操作（跨多条链）
• 任何链上都不需要 ETH
• 无需额外的批准或交互

Relayer 赞助 gas，用户可以选择以任何支持的 token 支付——甚至是 LP 或产生收益的 token。这消除了当今以太坊中最大的用户体验陷阱之一。

可验证脚本不是一个小的改进——它代表了智能账户、交易流程和用户交互的设计方式的转变。以太坊已经超越了单链、单步交互。现在工具正在赶上。

EIP-7702 编排

可验证脚本最初是为通过智能账户执行而设计的。然而，随着 EIP-7702 的引入，现在可以直接在用户的外部拥有账户（EOA）上执行这些相同的脚本。

EIP-7702 能够将智能账户逻辑安装到 EOA 本身——这意味着脚本不再需要通过单独的合约路由。执行发生在用户控制的同一个地址中，同时仍然保留了安全性和隔离保证。

这使得编排更加简单：无需额外的部署，无需资助智能账户，并且设置最小。

ERC-7715 → 通过沙盒实现安全

在 EOA 上执行脚本虽然可行，但可能不是最聪明的做法。由于脚本可以访问用户的所有资金，因此在其上运行任意脚本可能被认为是危险的。

然而，这可以通过 ERC-7715 标准解决，该标准允许伴随账户请求特定数量的资金，脚本可以访问这些资金。

你可以想象这个账户请求例如 500 USDC 和 1000 USDT 用于特定的脚本操作——脚本不会在用户的主 EOA 上运行，但它会在一个单独的、沙盒化的智能账户上运行，该账户只能访问通过 ERC-7715 请求的资金！

浏览文档并构建你的第一个可验证脚本：https://docs.biconomy.io

• 原文链接： blog.biconomy.io/eip-770...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～