案例研究:使用 Biconomy 编排实现一键 Gasless 仓位迁移

  • Biconomy
  • 发布于 9小时前
  • 阅读 77

本文介绍了如何使用Biconomy的MEE和AbstractJS SDK实现一键将Aave的仓位迁移到Venus协议。通过Fusion模式,用户只需一次签名即可完成包括转移利息、从Aave提款、授权Venus花费代币以及在Venus上铸造vToken等多个复杂操作,极大地简化了DeFi操作的用户体验.

案例研究:使用 Biconomy Orchestration 实现一键式 Gasless "Vampire" 流

本教程演示了如何利用 Biconomy 的模块化执行环境(MEE)和 AbstractJS SDK,以实现从 Aave 到 Venus Protocol 的一键式仓位迁移。该实现展示了可组合编排的强大功能,只需一个用户签名即可执行多个复杂的交易。

概述

此实现使用户能够:

  1. 将任何应计的 aToken 利息转移到他们的 Companion Account(通过 Fusion Mode)
  2. 提取他们在 Aave 的全部仓位
  3. 批准 Venus 池花费提取的代币
  4. 代表用户在 Venus 协议上 Mint vToken

所有这些操作都在单个交易流中原子地发生,从而抽象出多个批准和跨协议交互的复杂性。

了解 Fusion Mode

由于像 MetaMask 或 Rabby 这样的外部钱包无法直接在 EOA 上安装智能账户逻辑,因此此实现使用了 Fusion Mode - 一种透传机制,可通过 Companion 智能账户启用 MEE 编排。

Fusion Mode 的工作原理:

  1. 触发签名:用户签署一个触发交易,其中包含所有编排指令的哈希
  2. 资金转移:资金临时转移到用户拥有的非托管 Companion Account
  3. 指令执行:所有操作都使用 Companion Account 执行
  4. 返回 EOA:生成的资产自动返回到用户的 EOA
  5. 无状态设计:Companion Account 在执行后保持干净,没有 dust

Biconomy 可组合架构的强大功能

运行时余额解析

这里展示的最强大的功能之一是使用 runtimeERC20BalanceOf。此函数在执行时动态解析代币余额,而不是在签名时:

runtimeERC20BalanceOf({
  targetAddress: accountAddress,
  tokenAddress: position.aTokenAddress,
  constraints: [greaterThanOrEqualTo(100n)],
})

这对于 DeFi 操作至关重要,因为:

  • 在签名和执行之间会产生利息
  • 在执行时才知道确切的金额
  • 它可以防止交易因余额不足而失败

完整的实现

让我们研究一下 Fusion 触发器和可组合指令如何协同工作:

触发交易

触发器是启动整个编排的入口点:

trigger: {
  chainId,
  tokenAddress: position.aTokenAddress,
  amount: position.userATokenBalanceMantissa,
  approvalAmount: bufferAmount,  // 缓冲以考虑利息
  gasLimit: 500000n,
}

此触发器:

  • 将用户的 aToken 余额转移到 Companion Account
  • 仅转移“未来利息的权利” - 应计利息作为额外的 aToken 保留在 EOA 上
  • 使用缓冲的批准金额,以确保整个过程有足够的 allowance
  • 包含所有编排指令的哈希,从而通过一个签名授权整个序列

步骤 1:转移应计利息 (aToken)

const transferInterest = await nexusAccount.buildComposable({
  type: 'transferFrom',
  data: {
    recipient: nexusAccountAddress,  // Companion Account 地址
    sender: accountAddress,          // 用户的 EOA
    tokenAddress: position.aTokenAddress,
    amount: runtimeERC20BalanceOf({
      targetAddress: accountAddress,
      tokenAddress: position.aTokenAddress,
      constraints: [greaterThanOrEqualTo(100n)],
    }),
    chainId,
    gasLimit: 100000n,
  },
});

此指令:

  • 将用户 EOA 中剩余的任何 aToken(代表应计利息)转移到他们的 Companion Account
  • 使用运行时余额来捕获触发交易后剩余的所有可用 aToken
  • 设置一个约束,确保至少转移 100 个单位(防止 dust 交易)
  • 与触发器结合使用,这可以确保用户的整个 aToken 仓位(本金 + 所有利息)移动到 Companion Account

步骤 2:提取整个 Aave 仓位

const withdrawFromAave = await nexusAccount.buildComposable({
  type: 'default',
  data: {
    to: aaveV3PoolContractAddress,
    abi: aaveV3PoolAbi,
    functionName: 'withdraw',
    args: [\
      position.tokenAddress,        // 要提取的资产\
      MAX_UINT256.toFixed(),       // 数量(MAX = 整个仓位)\
      nexusAccountAddress,         // 接收者\
    ],
    chainId,
    gasLimit: 100000n,
  },
});

关键见解:

  • 使用 MAX_UINT256 提取整个仓位,包括在交易处理期间产生的任何利息
  • default 类型允许调用任何智能合约功能
  • 提取的资金进入 Nexus 帐户以进行进一步操作

步骤 3:批准 Venus 花费代币

const approveVenus = await nexusAccount.buildComposable({
  type: 'approve',
  data: {
    tokenAddress: position.tokenAddress,
    spender: vToken.address,
    amount: runtimeERC20BalanceOf({
      targetAddress: nexusAccountAddress,
      tokenAddress: position.tokenAddress,
      constraints: [greaterThanOrEqualTo(100n)],
    }),
    chainId,
    gasLimit: 100000n,
  },
});

这展示了 MEE 的另一个强大功能:

  • 批准从 Aave 提取收到的确切金额
  • 无需过度批准或猜测金额
  • 运行时解析确保批准与可用余额完全匹配

步骤 4:在 Venus 上 Mint vToken

const mintVTokens = await nexusAccount.buildComposable({
  type: 'default',
  data: {
    to: vToken.address,
    abi: vBep20Abi,
    functionName: 'mintBehalf',
    args: [\
      accountAddress,  // 代表用户的 EOA 进行 Mint\
      runtimeERC20BalanceOf({\
        targetAddress: nexusAccountAddress,\
        tokenAddress: position.tokenAddress,\
        constraints: [greaterThanOrEqualTo(100n)],\
      }),\
    ],
    chainId,
    gasLimit: 100000n,
  },
});

这里的魔力:

  • mintBehalf 允许 SCA 为用户的 EOA Mint 代币
  • 再次使用运行时余额 Mint 可用的确切金额
  • 用户直接在其主钱包中收到 vToken

创建 Fusion Quote

Fusion Quote 将所有内容与触发交易打包在一起:

// 缓冲批准金额以考虑利息增加
const approvalAmount = buffer({
  amountMantissa: position.userATokenBalanceWithInterestsMantissa,
});

const fusionQuote = await meeClient.getFusionQuote({
  trigger: {
    chainId,
    tokenAddress: position.aTokenAddress,
    amount: position.userATokenBalanceMantissa,
    approvalAmount,  // 缓冲金额
    gasLimit: 500000n,
  },
  instructions: [\
    transferInterest,\
    withdrawFromAave,\
    approveVenus,\
    mintVTokens\
  ],
  sponsorship: true,  // 启用 gasless 执行
});

主要特点:

  • 触发器:启动整个流程的初始 aToken 批准。这将创建用户签署的 Fusion 触发交易
  • 触发器类型:SDK 会自动检测 aToken 是否支持 ERC20Permit 以进行 gasless 执行,否则使用标准批准
  • 缓冲:考虑在签名和执行之间产生的利息
  • 赞助:使交易对用户来说是 gasless 的(绕过 Fusion 约束,即执行代币必须支付 gas 费用)
  • 原子执行:所有指令按顺序执行,否则都不执行
  • Fusion 约束:每个用户签名仅使用一种代币类型 (aToken)

了解缓冲策略

buffer 函数在处理 Aave 的利息增加机制方面起着至关重要的作用。以下是需要它的原因:

将 aToken 转移到 Companion Account 时,Aave 处理利息的方式存在细微差别:

  1. 触发交易将用户的 aToken 余额转移到 Companion Account,但这仅转移了获得未来利息的权利
  2. 应计利息保留在 EOA 上 - 它作为未包含在初始转账中的额外 aToken 留在那里
  3. 第一条指令transferInterest)然后将这些剩余的 aToken(应计利息)提取到 Companion Account

缓冲可确保我们批准足够的 aToken 来覆盖:

  • 初始余额
  • 签名和执行之间产生的任何利息

这个两步过程确保了整个 aToken 仓位(本金 + 所有应计利息)都被捕获以进行迁移。该实现有效地允许用户将他们所有的 aToken 和所有应计利息转移到 Companion Account,从而确保 EOA 上不会留下任何价值。

展示的高级概念

1. 跨协议可组合性

此实现在一个交易中无缝桥接了两个主要的 DeFi 协议(Aave 和 Venus)。MEE 处理所有复杂性,包括:

  • 协议特定的接口
  • 代币批准和转账
  • 操作之间的状态管理

2. 动态金额处理

传统的交易需要预先知道确切的金额。借助 MEE 的运行时值:

  • 在执行时解析金额
  • 由于轻微的余额变化而没有失败的交易
  • 完美效率,没有剩余的批准

3. 智能合约帐户的优势

Nexus 帐户充当中间人,可以:

  • 在操作期间临时持有资金
  • 代表用户执行操作
  • 实现从 EOA 无法实现的复杂流程

3. Companion Account 的优势(Fusion Mode)

Companion Account 充当无状态中间人,可以:

  • 在编排期间临时持有资金
  • 代表用户执行所有复杂操作
  • 自动将所有资产返回到用户的 EOA
  • 保持非托管 - 用户保持完全所有权
  • 执行后不留下 dust 或残留状态

4. 约束系统

constraints: [greaterThanOrEqualTo(100n)]

约束确保仅在满足条件时才执行操作,从而防止:

  • Dust 交易
  • 余额不足错误
  • 在会失败的操作上浪费 gas

为什么这很重要

传统方法(多次交易)

  1. 用户批准 aToken 转账
  2. 用户转账 aToken
  3. 用户从 Aave 提取
  4. 用户批准 Venus
  5. 用户在 Venus 上 mint

问题:5 个签名,5 次 gas 支付,部分执行的风险,复杂的 UX

Biconomy MEE 方法(Fusion Mode)

  1. 用户签名一次(触发交易)

优点

  • 单个签名用于整个编排
  • 适用于任何外部钱包(MetaMask、Rabby 等)
  • 可选的 gas 赞助(如果 aToken 支持 ERC20Permit,则完全 gasless)
  • 原子执行,失败时自动清理
  • 无缝 UX,资产直接返回 EOA

结论

此实现展示了 Biconomy 的 MEE 与 Fusion Mode 如何将复杂的 DeFi 操作转化为简单的、用户友好的体验。通过利用可组合指令、运行时值并通过 Companion Account 进行原子执行,开发人员可以构建与任何外部钱包一起使用的复杂的跨协议集成。

展示的主要创新:

  • Fusion Mode 编排:通过无状态 Companion Account 在标准 EOA 上启用 MEE 功能
  • 运行时可组合性:适应不断变化的链上状态的动态值
  • 跨协议编排:不同 DeFi 协议之间的无缝交互
  • 单签名执行:以最小的用户摩擦实现复杂的流程
  • Gas 抽象:可选赞助,实现真正的 gasless 体验(使用 ERC20Permit 代币自动实现)
  • 自动资产返回:所有生成的代币都会返回到用户的 EOA,无需手动干预

这种模式可以应用于任何多步骤 DeFi 操作,从收益优化到投资组合再平衡,使其成为构建与主流钱包配合使用的高级 Web3 体验的强大工具。

  • 原文链接: blog.biconomy.io/case-st...
  • 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
点赞 0
收藏 0
分享
本文参与登链社区写作激励计划 ,好文好收益,欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
Biconomy
Biconomy
江湖只有他的大名,没有他的介绍。