ERC-7540 vs ERC-4626：RWA金库的异步结算

标准的 ERC-4626 通过为生息 金库 提供统一的接口，彻底改变了 DeFi。然而，它依赖于一个基本假设：原子流动性。在 ERC-4626 金库 中，存款和赎回发生在同一笔交易中。这适用于 Aave 的 aTokens 或 Lido 的 stETH 等链上资产，因为底层流动性是 EVM 内生的。

现实世界资产 (RWA) 打破了这个假设。当你将美国国债或私募信贷代币化时，你处理的是 外生流动性——存在于链下经纪账户、银行账本 (Fedwire/Swift) 或手动 KYC 注册表中的资产。这些系统以 T+1 或 T+2 结算周期运行，这与以太坊的 12 秒区块时间不兼容。

ERC-7540 是旨在弥合这一差距的技术扩展，它形式化了一个异步请求/声明模式。

摩擦：为什么原子交易对 RWA 失败

如果你试图强制将 T+2 结算流程纳入标准的 ERC-4626 deposit 函数中，你将面临三个主要的架构性失败：

• 无抵押代币发行：在链下电汇清算之前铸造份额，会产生 金库 在技术上抵押不足的时期。
• 结算回滚：如果发出 withdraw 调用，但 金库 缺乏直接的链上流动性（由于资产被锁定在到期债券中），则交易会回滚，从而导致用户的拒绝服务 (DoS)。
• 合规性僵局：机构资产需要 KYC/AML 检查，这些检查通常通过链下 API 或手动验证进行。这些无法在单个同步交易的 gas 限制内执行。

机制：将意图与执行分离

ERC-7540 通过引入一个状态机来解决这个问题，该状态机将请求与完成分离。它将 金库 从“推送”模型转变为“拉取”模型。

异步操作的生命周期遵循三个不同的状态：

1. 待处理：用户调用 requestDeposit。资产被转移到 金库（或锁仓器），并生成一个 requestId。用户已锁定资金，但尚未收到份额。
2. 可声明：链下运营商或预言机确认结算（例如，电汇已清算）。他们更新 金库 状态，将请求从“待处理”移至“可声明”。
3. 已声明：用户（或委托的机器人）调用 deposit（在 7540 中重载）以最终将份额铸造到他们的钱包中。

技术深入：关键接口更改

ERC-7540 不会取代 ERC-4626；它扩展了它。以下是开发人员必须实施的关键补充：

1. 请求流

用户不是调用 deposit，而是与以下内容交互：

• requestDeposit(assets, controller, owner)
• requestRedeem(shares, controller, owner)

请注意添加了 controller 参数。这允许委托管理，即机构托管人可以代表所有者管理请求流，而无需完全托管底层资产。

2. 用于状态跟踪的视图函数

由于状态不再是二进制的，因此前端必须查询细粒度状态：

• pendingDepositRequest(requestId, controller)：返回等待结算的资产。
• claimableDepositRequest(requestId, controller)：返回准备好最终确定的资产/份额。

3. 处理远期定价

在 ERC-4626 中，汇率在交易时已知。在 ERC-7540 中，汇率通常在完成时确定（远期定价）。这降低了套利风险，但要求开发人员仔细管理净资产价值 (NAV) 更新，通常通过基于 epoch 的批处理。

实施模式：防止原子回退

为确保集成商不会意外地将异步 金库 视为同步 金库，该标准建议覆盖原始 ERC-4626 函数，以便在无法立即操作时回滚：

1// 示例：强制执行异步流
2function deposit(uint256 assets, address receiver) public override returns (uint256) {
3    // 回滚以表明用户必须使用 requestDeposit
4    revert("ERC7540: Use requestDeposit for async flow");
5}
6

7function previewDeposit(uint256 assets) public view override returns (uint256) {
8    // 向 UI 发出信号，表明原子估计不可用
9    revert("ERC7540: Vault is asynchronous");
10}

机构用例和批处理

requestId 是 RWA 集成商最强大的工具。它允许批量结算 (Epochs)：

• Centrifuge：使用 7540 管理 分级。请求在一个 epoch 内收集（例如，24 小时）。在 epoch 结束时，单个 NAV 更新以相同的价格处理所有请求，确保参与者之间的公平性并防止链下数据的前端运行。
• Ondo Finance / Superstate：这些协议使用请求阶段来触发链下订阅表和银行电汇。“可声明”状态只有在托管人（例如，BNY Mellon）确认购买底层国债后才会达到。

安全注意事项：“裸赎回者”风险

开发人员必须意识到裸赎回者问题。当用户调用 requestRedeem 时，他们的份额通常会被烧毁或锁定。如果 金库 资不抵债或链下资产在“待处理”窗口期间未能清算，则用户将失去份额（所有权证明）和资产。

缓解措施：实施 cancelRedeem 函数（或类似的扩展）对于允许用户在异步完成窗口超过特定超时时收回其份额至关重要。有关取消的标准化方法，请参阅 ERC-7887。

实施的后续步骤

如果你要为非流动资产构建 金库，请不要强行将其放入标准 ERC-4626 中。这会创建一个脆弱的 UX 和潜在的安全漏洞。

• 查看规范：研究正式的 EIP-7540 提案。

• 参考实施：浏览 Centrifuge ERC-7540 GitHub 存储库，了解异步状态管理的生产级示例。

• 审计重点：如果审计这些 金库，请关注 pending 和 claimable 之间的转换逻辑，以确保没有“灰尘”攻击会阻止完成队列。

• • *

保持联系

在 Zealynx，我们知道代币化现实世界资产需要的不仅仅是 Solidity——它需要一个强大的架构来弥合法律框架和区块链状态之间的差距。无论你是在构建 RWA 平台、实施 ERC-7540 进行异步结算，还是在 审计代币化资产基础设施，我们的团队都已准备好提供帮助——联系我们。

想要通过更深入的分析保持领先地位吗？订阅我们的新闻通讯，确保你不会错过未来的见解。

常见问题解答：ERC-7540 和异步 金库

1. 为什么不直接使用 ERC-4626？

ERC-4626 假设原子（即时）流动性，这意味着资产必须在提款的确切时刻在合约中可用。现实世界资产通常依赖于 T+2 结算周期（电汇、债券销售），这使得它们与原子标准不兼容。ERC-7540 扩展了 4626 以优雅地处理这些延迟。

2. 什么是“裸赎回者”风险？

当用户请求赎回并且他们的份额被锁定或烧毁，但在发送法币之前链下结算失败或 金库 资不抵债时，就会发生这种情况。ERC-7540 实施必须包括保护措施（如 cancelRedeem），以允许用户在结算失败时收回他们的份额。

3. ERC-7540 可以用于完全链上的资产吗？

可以，但通常没有必要。对于完全流动的链上资产（如 ETH 或 DAI）使用异步模式会引入额外的复杂性和 gas 成本，而不会带来好处。最好将其保留给具有固有结算延迟或速率限制的资产。

4. T+2 结算对代币化资产意味着什么？

T+2（交易日后两天）是指传统的金融结算周期，其中交易在交易日后两个工作日完成。例如，通过经纪人购买美国国债时，所有权的实际转移和付款会在 2 天后发生。这与以太坊的即时最终性不兼容，这就是为什么需要 ERC-7540 的请求/声明模式来弥合区块链交易和 Fedwire 或 SWIFT 等链下结算系统之间的时间差距。

5. 什么是远期定价，为什么 ERC-7540 使用它？

远期定价意味着汇率（你每次存入资产所收到的 金库 份额）在完成时确定，而不是在请求时确定。在 ERC-7540 中，当你调用 requestDeposit 时，你还不知道确切的份额数量。价格会在 金库 的净资产价值 (NAV) 更新时计算，通常在 epoch 结束时计算。这可以防止套利攻击，在这种攻击中，用户可以通过在了解链下资产价格变化的情况下通过前端运行 NAV 更新来利用过时的定价。

6. ERC-7540 中的 controller 参数是什么？

requestDeposit(assets, controller, owner) 等函数中的 controller 参数支持机构托管的委托管理。它将发起请求的实体（controller）与最终资产所有者分开。例如，像 BNY Mellon 这样的受监管托管人可以充当 controller，代表所有者管理存款/赎回工作流程，处理 KYC 验证和合规性检查，而无需完全托管所有者的代币或股份。

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