Weiroll 与 ERC-8211：DeFi 智能批处理深度对比

Biconomy
发布于 8小时前
阅读 33

本文对 DeFi 交易链执行方案 Weiroll 与 ERC-8211（智能批处理）进行了深入的技术对比。文章分析了 Weiroll 的轻量级虚拟机机制及其局限性，并详细介绍了 ERC-8211 如何通过声明式编码、运行时参数注入和内置安全约束，解决 DeFi 交易中的滑点与多步操作问题，同时探讨了其在原生账户抽象（EIP-8141）背景下的未来前景。

![Image](https://img.learnblockchain.cn/2026/04/16/65224942_image.jpg)

Weiroll 和 ERC-8211 的技术对比 —— 以及为什么声明式执行是 DeFi 的未来。

如果你曾尝试在单笔交易中将兑换 (swap) 链接到借贷存款中，你已经知道问题所在了。你签署了一个批处理，内容是“将 100 USDC 兑换为 WETH，然后将 0.05 WETH 供应给 Aave”。当交易落地时，兑换仅返回了 0.0495 WETH。你硬编码的 0.05 数额失败了。批处理回滚 (revert)。你的 Gas 消耗殆尽。

这并非小众的极端情况。这是当今以太坊上多步 DeFi 的默认体验。兑换输出取决于价格影响、滑点和 MEV。借贷提取取决于可变的份额率。跨链桥交付带有不可预测的费用。每一个触及实时状态的参数在你签署的那一刻都变成了一种猜测。

两个项目从完全不同的角度解决了这个问题。Weiroll 是 2021 年的先驱，为在 EVM 上链接合约调用引入了一个轻量级虚拟机。ERC-8211 是来自 Biconomy 和以太坊基金会的 2026 年标准轨道提案，它引入了“智能批处理 (smart batching)” —— 一种声明式编码，其中每个参数描述了如何在执行时获取其值，以及该值必须满足什么条件。

## Weiroll：先驱

Weiroll 是超越简单 Multicall 的最早严肃尝试之一。Multicall 允许你批处理独立的调用，而 Weiroll 允许你链接它们 —— 调用 A 的返回值可以成为调用 B 的输入。通过这种方式，它在以太坊开发工具包中建立了一个全新的原语：可组合的链上脚本。

### 工作原理

Weiroll 是一个微小的链上虚拟机。你给它两样东西：一个命令数组（每个命令打包成 32 字节）和一个状态值数组（你的工作寄存器）。虚拟机逐一运行命令。每个命令都会说：“在某个合约上调用此函数，从这些状态槽中提取输入，并将输出写入那个状态槽。”

![Image](https://img.learnblockchain.cn/2026/04/16/94759882_image.png)

它的美妙之处在于其简洁性。在约 200 行 Solidity 代码中，Weiroll 可以链接任意合约调用，在它们之间传递返回值，并处理固定长度和可变长度的参数。`weiroll.js` TypeScript SDK 为开发者提供了一个 Planner 抽象：

```typescript
const planner = new weiroll.Planner();
const wethOut = planner.add(router.exactInputSingle(usdc, weth, 500, amount, 0));
planner.add(aavePool.supply(weth, wethOut, self, 0));
const { commands, state } = planner.plan();
```

Planner 处理状态槽分配，因此开发者无需考虑寄存器索引。一些生产系统已经采用了 Weiroll，包括 Enso Finance 和 Royco Protocol。

### Weiroll 的优势

*   **Gas 效率：** Weiroll 的编码非常紧凑。一个命令就是一个 `bytes32`。CommandBuilder 库使用汇编级内存操作，并尽可能避免动态分配。
*   **极小的表面积：** 整个虚拟机只有约 200 行 Solidity 代码。需要审计的代码非常少，且现有代码非常直观。
*   **真正的通用性：** Weiroll 对你链接的内容没有偏见。它支持 `DELEGATECALL`、`CALL`、`STATICCALL` 以及带 value 的 `CALL`，涵盖了每种 EVM 调用类型。
*   **生产验证：** Enso Finance 和 Royco Protocol 使用它来定义链上交易“配方 (recipes)”，在对抗性环境中处理真实价值。
*   **低采用门槛：** 任何可以进行 `delegatecall` 的合约都可以使用 Weiroll 虚拟机，而无需实现复杂的接口。

### Weiroll 的局限性

Weiroll 是作为通用的管道构建的。它没有分支，没有循环，也没有内置的安全检查。如果兑换返回的金额少于预期，下一个调用要么成功要么回滚；如果没有部署自定义断言合约，就无法断言“输出必须至少为 X”。

链上编码是不透明的。`bytes32[]` 命令数组不携带任何语义信息。确定一个 Weiroll 程序实际执行的操作需要解码每个命令并交叉引用 ABI。此外，Weiroll 没有跨链协调的概念；它是一个单交易、单链的虚拟机。

## ERC-8211：智能批处理

ERC-8211 从一个不同的前提开始。它不问如何高效地链接函数调用，而是问 DeFi 执行计划实际需要声明什么。该标准确定了三个核心需求：

1.  **动态值解析：** 如何在执行时获取每个值。
2.  **内联约束：** 该值必须满足什么条件。
3.  **路由：** 将值路由到何处（目标、ETH 数额或 calldata）。

### 三个原语

*   **运行时参数注入：** 每个参数都携带一个“获取器类型 (fetcher type)”（例如 `RAW_BYTES`、`STATIC_CALL` 或 `BALANCE`）。与其硬编码数额，你可以编写 `supply(BALANCE(WETH))`。执行器会在执行时解析出确切的余额。
*   **前置和后置断言：** 每个解析出的值都可以携带内联约束（EQ、GTE、LTE、IN）。这提供了内置的 MEV 保护；你可以断言兑换输出大于最低阈值，而无需编写自定义 Solidity。
*   **多交易上下文：** 一个共享的存储合约允许条目写入值，后续条目或随后的 `UserOperations` 可以读取这些值，从而允许数据在步骤之间流动而无需自定义合约。

### 编写 ERC-8211 批处理

TypeScript SDK 将高级意图编译为链上编码：

![Image](https://img.learnblockchain.cn/2026/04/16/31880104_image.jpg)

在这种模型中，每个数额都会动态解析。内联谓词 (predicate) 确保兑换返回了足够的金额，消除了硬编码值和剩余的粉尘 (dust)。

## 关键区别

### 可读性：打包字节 vs. 结构化数据

Weiroll 的链上表示是一个打包的二进制数组。它虽然高效，但需要专门的工具才能理解。ERC-8211 的编码是结构化数据。每个条目包含获取器类型和约束的类型化字段。钱包或区块浏览器仅从编码本身就能重建批处理的意图，增强了终端用户的透明度。

### 静态分析与验证

Weiroll 程序是自定义虚拟机的字节码。分析它们需要一个理解命令编码的符号执行引擎。ERC-8211 批处理是声明式元数据。静态分析器可以检查 `InputParam` 并立即知道其来源和约束。这使得中继器 (relayer)、捆绑器 (bundler) 和 AI Agent 能够进行意图层面的分析。

### DeFi 优先 vs. 通用设计

Weiroll 是一个通用的“胶水”层。它可以链接任何合约调用，但对于 DeFi 特有的需求（如余额查询或滑点检查），需要自定义辅助合约。

ERC-8211 是从头开始为 DeFi 构建的。诸如 `BALANCE` 获取器和约束系统之类的原语被直接编入标准中。对于大多数 DeFi 流程，ERC-8211 消除了部署和审计自定义辅助合约的需求，简化了开发生命周期。

### 跨链能力

Weiroll 是单链虚拟机。多链流程必须在外部编排。ERC-8211 将跨链编排视为一等公民。用户可以签署一个覆盖多个链上批处理的单个 Merkle root。谓词条目可以根据跨链状态控制执行，例如等待跨链桥交付完成。

### 安全模型

Weiroll 的安全性依赖于其极小的代码库和顺序命令的可预测性。然而，它没有内置验证；安全性必须由目标合约处理。

ERC-8211 使用标准的 `CALL` 语义，并将内联约束作为主要的安全性机制。安全不变性是编码本身的一部分，使其对钱包可见且在链上可验证。

## Gas 效率对比

由于采用了打包的 `bytes32` 编码，Weiroll 在每个命令的基础上更精简，使其在 L2 上的简单链式调用中非常高效。然而，对于需要余额断言或滑点保护的生产级 DeFi 流程，Weiroll 需要额外的辅助合约调用。

ERC-8211 的内联约束避免了进行安全性检查时的跨合约调用开销。虽然结构化编码比 Weiroll 的大，但对于复杂且安全的 DeFi 操作，其总 Gas 成本极具竞争力。

## 兼容性与以账户为中心的愿景

Weiroll 与账户层无关。集成者必须为不同的智能账户架构构建自己的适配器。

ERC-8211 以账户为中心，并为主要标准定义了规范的集成模式：
*   **ERC-7579：** 执行器模块。
*   **ERC-6900：** 插件注册。
*   **EIP-7702：** EOA 的委托目标。
*   **ERC-4337：** 与智能账户和捆绑器基础设施的原生兼容性。

### 为原生账户抽象 (EIP-8141) 做准备

EIP-8141 (Frame 交易) 引入了一种新的交易类型，将验证、执行和 Gas 支付拆分为单独的框架 (frame)。ERC-8211 被明确设计为在该架构内作为执行负载工作。Frame 交易可以在发送者账户上调用 `executeComposable()`，以原生方式运行具有运行时解析参数的智能批处理。

## 声明式执行的未来

Weiroll 开创了链上脚本的概念，证明了轻量级虚拟机可以在调用之间传递数据。对于需要具有最大 Gas 效率的轻量通用执行层的开发者来说，它仍然是一个有价值的工具。

然而，ERC-8211 解决了生态系统的现代需求。通过使执行计划默认可读、可分析且安全，它将智能批处理定位为以太坊未来的核心组件。它将行业从“安全性是开发者的问题”推向“安全性被编码在批处理中”。

ERC-8211 目前处于 Draft（草案）状态。规范可在 [erc8211.com](https://www.erc8211.com/) 查看，ERC 拉取请求位于 [ethereum/ERCs #1638](https://github.com/ethereum/ERCs/pull/1638)。Weiroll 的源码可在 [github.com/weiroll/weiroll](https://github.com/weiroll/weiroll) 获得。

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

Weiroll 和 ERC-8211 的技术对比 —— 以及为什么声明式执行是 DeFi 的未来。

Weiroll：先驱

工作原理

它的美妙之处在于其简洁性。在约 200 行 Solidity 代码中，Weiroll 可以链接任意合约调用，在它们之间传递返回值，并处理固定长度和可变长度的参数。weiroll.js TypeScript SDK 为开发者提供了一个 Planner 抽象：

const planner = new weiroll.Planner();
const wethOut = planner.add(router.exactInputSingle(usdc, weth, 500, amount, 0));
planner.add(aavePool.supply(weth, wethOut, self, 0));
const { commands, state } = planner.plan();

Planner 处理状态槽分配，因此开发者无需考虑寄存器索引。一些生产系统已经采用了 Weiroll，包括 Enso Finance 和 Royco Protocol。

Weiroll 的优势

Gas 效率： Weiroll 的编码非常紧凑。一个命令就是一个 bytes32。CommandBuilder 库使用汇编级内存操作，并尽可能避免动态分配。
极小的表面积： 整个虚拟机只有约 200 行 Solidity 代码。需要审计的代码非常少，且现有代码非常直观。
真正的通用性： Weiroll 对你链接的内容没有偏见。它支持 DELEGATECALL、CALL、STATICCALL 以及带 value 的 CALL，涵盖了每种 EVM 调用类型。
生产验证： Enso Finance 和 Royco Protocol 使用它来定义链上交易“配方 (recipes)”，在对抗性环境中处理真实价值。
低采用门槛： 任何可以进行 delegatecall 的合约都可以使用 Weiroll 虚拟机，而无需实现复杂的接口。

Weiroll 的局限性

链上编码是不透明的。bytes32[] 命令数组不携带任何语义信息。确定一个 Weiroll 程序实际执行的操作需要解码每个命令并交叉引用 ABI。此外，Weiroll 没有跨链协调的概念；它是一个单交易、单链的虚拟机。

ERC-8211：智能批处理

ERC-8211 从一个不同的前提开始。它不问如何高效地链接函数调用，而是问 DeFi 执行计划实际需要声明什么。该标准确定了三个核心需求：

动态值解析： 如何在执行时获取每个值。
内联约束： 该值必须满足什么条件。
路由： 将值路由到何处（目标、ETH 数额或 calldata）。

三个原语

运行时参数注入： 每个参数都携带一个“获取器类型 (fetcher type)”（例如 RAW_BYTES、STATIC_CALL 或 BALANCE）。与其硬编码数额，你可以编写 supply(BALANCE(WETH))。执行器会在执行时解析出确切的余额。
前置和后置断言： 每个解析出的值都可以携带内联约束（EQ、GTE、LTE、IN）。这提供了内置的 MEV 保护；你可以断言兑换输出大于最低阈值，而无需编写自定义 Solidity。
多交易上下文： 一个共享的存储合约允许条目写入值，后续条目或随后的 UserOperations 可以读取这些值，从而允许数据在步骤之间流动而无需自定义合约。

编写 ERC-8211 批处理

TypeScript SDK 将高级意图编译为链上编码：

在这种模型中，每个数额都会动态解析。内联谓词 (predicate) 确保兑换返回了足够的金额，消除了硬编码值和剩余的粉尘 (dust)。

关键区别

可读性：打包字节 vs. 结构化数据

静态分析与验证

Weiroll 程序是自定义虚拟机的字节码。分析它们需要一个理解命令编码的符号执行引擎。ERC-8211 批处理是声明式元数据。静态分析器可以检查 InputParam 并立即知道其来源和约束。这使得中继器 (relayer)、捆绑器 (bundler) 和 AI Agent 能够进行意图层面的分析。

DeFi 优先 vs. 通用设计

Weiroll 是一个通用的“胶水”层。它可以链接任何合约调用，但对于 DeFi 特有的需求（如余额查询或滑点检查），需要自定义辅助合约。

ERC-8211 是从头开始为 DeFi 构建的。诸如 BALANCE 获取器和约束系统之类的原语被直接编入标准中。对于大多数 DeFi 流程，ERC-8211 消除了部署和审计自定义辅助合约的需求，简化了开发生命周期。

跨链能力

安全模型

Weiroll 的安全性依赖于其极小的代码库和顺序命令的可预测性。然而，它没有内置验证；安全性必须由目标合约处理。

ERC-8211 使用标准的 CALL 语义，并将内联约束作为主要的安全性机制。安全不变性是编码本身的一部分，使其对钱包可见且在链上可验证。

Gas 效率对比

由于采用了打包的 bytes32 编码，Weiroll 在每个命令的基础上更精简，使其在 L2 上的简单链式调用中非常高效。然而，对于需要余额断言或滑点保护的生产级 DeFi 流程，Weiroll 需要额外的辅助合约调用。

兼容性与以账户为中心的愿景

Weiroll 与账户层无关。集成者必须为不同的智能账户架构构建自己的适配器。

ERC-8211 以账户为中心，并为主要标准定义了规范的集成模式：

ERC-7579： 执行器模块。
ERC-6900： 插件注册。
EIP-7702： EOA 的委托目标。
ERC-4337： 与智能账户和捆绑器基础设施的原生兼容性。

为原生账户抽象 (EIP-8141) 做准备

EIP-8141 (Frame 交易) 引入了一种新的交易类型，将验证、执行和 Gas 支付拆分为单独的框架 (frame)。ERC-8211 被明确设计为在该架构内作为执行负载工作。Frame 交易可以在发送者账户上调用 executeComposable()，以原生方式运行具有运行时解析参数的智能批处理。

声明式执行的未来

ERC-8211 目前处于 Draft（草案）状态。规范可在 erc8211.com 查看，ERC 拉取请求位于 ethereum/ERCs #1638。Weiroll 的源码可在 github.com/weiroll/weiroll 获得。

原文链接： x.com/biconomy/status/20...

登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～

翻译
学分: 0
分类: 以太坊
标签: Weiroll ERC-8211 智能批处理账户抽象 DeFi 执行 EIP-8141

本文参与登链社区写作激励计划，好文好收益，欢迎正在阅读的你也加入。