以太坊 - 标题 - Umaprotocol

概要

DVM 应该支持对 IS_RELAY_VALID 的价格请求。

动机

IS_RELAY_VALID 将允许 DVM 使用此处的桥接合约来验证来自 Optimism 或 Arbitrum 的 relay 请求。

该系统将允许 L2 上的用户快速将其资金转回 L1，并避免与 rollups 相关的长期提款等待期，只需支付一小笔费用，该费用将支付给愿意等待资金通过 canonical 桥转移的 LP。

数据规范和实现

投票者需要使用多个合约来评估 relay 的有效性。

每个价格请求都将来自部署在主网上的 BridgePool 合约。 这将使用键 requester 编码在辅助数据中。

一个 canonical BridgeAdmin 合约部署在主网上，地址为 0x30B44C676A05F1264d1dE9cC31dB5F2A945186b6。 投票者应验证 requester 的 l1Token 方法是否返回有效的 ERC20 token 地址。 在 relay 交易的同一区块号上调用 BridgeAdmin 合约上的 whitelistedTokens(tokenAddress, 10) (optimism) 或 whitelistedTokens(tokenAddress, 42161) (arbitrum) 时，至少其中一个调用的第二个返回值应为 requester 地址。 如果其中任何一项不为真，则应认为 relay 无效。

辅助数据还应包含字段 relayHash。 这应与 DepositRelayed 事件中 BridgePool 发出的 relayAncillaryData 字段匹配。 如果不存在具有该哈希的事件，则 relay 无效。

在同一事件中，投票者应看到一个包含 DepositData 结构的 depositData 字段。 DepositData 结构应包含一个 chainId 字段。 该字段应用于在 BridgeAdmin 合约上调用 depositContracts(chainId)（在 DepositData 结构中的 quoteTimestamp 字段的时间戳之前或之前的最新区块号调用），并获取结构中的 depositContract 值（第一个元素）。 这应该是 chainId（arbitrum 或 optimism）指定的链上的 deposit 合约地址。 投票者应查询此合约的 FundsDeposited 事件，以验证其字段是否与主网上相应的 DepositData 结构字段完全匹配。 如果有任何差异，则 relay 无效。

在之前查询的 DepositRelayed 事件中的 RelayData 结构中，有一个名为 realizedLpFeePct 的字段。 注意：RelayData 结构在事件中称为 relay，并且为了解码 realizedFeePct 字段，可能需要使用 web3.js/ethers 进行解码并提取第 4 个字段，因为结构有时被解码为元组而不是具有命名字段的结构。 该字段由 relayer 指定，需要使用 depositData 中指定的 quoteTimestamp 来计算。 计算 realizedLpFeePct 的算法如下：

• <img src="https://render.githubusercontent.com/render/math?math=X"> 表示某人寻求桥接的特定交易的大小
• <img src="https://render.githubusercontent.com/render/math?math=0 \leq U_t \leq 1"> 表示交易前流动性提供者的资本利用率，即当前交易前流动性提供者的资本使用量
• <img src="https://render.githubusercontent.com/render/math?math=0 \leq \hat{U}_t \leq 1"> 表示交易后流动性提供者的资本利用率，即如果用户选择执行其交易，则将使用的流动性提供者的资本量
• <img src="https://render.githubusercontent.com/render/math?math=\bar{U}"> 表示利率发生变化的“扭结利用率”
• <img src="https://render.githubusercontent.com/render/math?math=R_0, R_1, R_2"> 表示控制利率模型斜率的参数：
  • <img src="https://render.githubusercontent.com/render/math?math=R_0"> 是 0% 利用率时收取的利率
  • <img src="https://render.githubusercontent.com/render/math?math=R_0 %2b R_1"> 是在 <img src="https://render.githubusercontent.com/render/math?math=\bar{U}\%25"> 利用率时收取的利率
  • <img src="https://render.githubusercontent.com/render/math?math=R_0 %2b R_1 %2b R_2"> 是在 100% 利用率时收取的利率

任何给定利用率下的利率将由以下等式给出：

<img src="https://render.githubusercontent.com/render/math?math=R(U_t) = R_0 %2b \frac{\min(\bar{U}, U_t)}{\bar{U}} R_1 %2b \frac{\max(0, U_t %2d \bar{U})}{1 %2d \bar{U}} R_2">

在我们的贷款案例中，我们必须在一定范围的利用率上进行积分，因为贷款的每一美元都会提高下一美元的利率。 这种影响是使用积分捕获的：

<img src="https://render.githubusercontent.com/render/math?math=R^a_t = \int_{U_t}^{\hat{U}_t} R(u) du">

为了获得这些贷款的真实利率，我们需要将其去年度化以获得百分比：

<img src="https://render.githubusercontent.com/render/math?math=R^w_t = (1 %2b R^a_t)^{\frac{1}{52}} %2d 1">

<img src="https://render.githubusercontent.com/render/math?math=U_t"> 可以通过在 quoteTimestamp 之前或之前的最新可用区块号上调用 BridgePool 合约上的 liquidityUtilizationCurrent 方法在链上获取。 <img src="https://render.githubusercontent.com/render/math?math=\hat{U}_t"> 可以通过在同一区块号上调用 BridgePool 合约上的 liquidityUtilizationPostRelay 方法，将 DepositData 结构中的 amount 字段作为 relayedAmount 参数传递来获取。 通常，用于调用这些方法的 BridgePool 合约应与 requester 相同，但在 BridgePool 在 L2 上迁移时存在未决存款的极不可能的情况下，应在 quoteTimestamp 时处于活动状态的 BridgePool 合约上计算利用率。 为了识别之前的 BridgePool，应该查找 L2 上 deposit 合约在 relay 交易的 quoteTimestamp 之前发出的最后一个 WhitelistToken 事件，并使用事件 bridgePool 字段中的地址。

由于与其他 L2 链相比，block.timestamp 的概念在主 ethereum L1 EVM 上可能有所不同，因此 L2 上的 deposit 合约允许在当前时间的 10 分钟范围内设置 quoteTimestamp。 为了确定性地根据池利用率计算 LP 费用，relayer 应该等到 L1 区块时间戳达到 quoteTimestamp。 任何早于 DepositRelayed 事件中 DepositData 结构的 quoteTimestamp 字段挖掘的 relay 交易都应无效。

有关更多详细信息，请参见示例实现。

上述计算使用的费率模型参数应从部署在主网上的 0xd18fFeb5fdd1F2e122251eA7Bf357D8Af0B60B50 的 RateModelStore 合约中在链上获取，并由 Across 协议 多签名帐户 管理。 费率模型参数应通过在 RateModelStore 合约上调用 l1TokenRateModels 方法获取，并在时间戳对应于或相对于 quoteTimestamp 字段可用的最新区块上将其 l1Token 地址作为其参数传递。

对 l1TokenRateModels 的调用应返回一个字符串化的 JSON 对象，其中包含以下键值对：

• UBar 对应于 <img src="https://render.githubusercontent.com/render/math?math=\bar{U}"> 费率模型参数；
• R0、R1 和 R2 分别对应于 <img src="https://render.githubusercontent.com/render/math?math=R_0">、&lt;img src="https://render.githubusercontent.com/render/math?math=R_1"> 和 <img src="https://render.githubusercontent.com/render/math?math=R_2"> 参数。

上面获得的费率模型参数值应按 18 个小数位缩小。

如果对 l1TokenRateModels 的调用返回的任何内容都无法解析为上述确切的键值对（例如，缺少或包含额外的参数），则应认为 relay 无效。

如果上述算法不产生匹配的 realizedLPFeePct（在将结果表示为十进制数向下取整到 18 位小数后），则 relay 无效。 如果该 token 未在上面的表中列出，则 relay 无效。

如果 relay 无效，则价格应为“0”。 如果 relay 有效，则应为“1”。 注意：所有价格值都应按 1e18 缩放。

价格 Feed 实现

请参阅 UMA 价格 feed 目录中的 InsuredBridgePriceFeed.ts。

辅助数据规范

辅助数据应指定两个值：relayHash 和 requester。 前者是用于标识 relay 的哈希，后者是启动请求的 BridgePool 合约。

安全考虑

这是一个新的标识符，只要所有请求都有明确的答案，这应该不会对 UMA DVM 产生安全影响。

• 原文链接： github.com/UMAprotocol/U...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～