向DVM添加对IS RELAY VALID价格请求的支持

摘要

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

动机

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

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

数据规范和实施

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

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

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

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

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

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

• $X$ 表示某人寻求桥接的特定交易的大小。
• $0 \leq U_t \leq 1$ 表示交易前流动性提供者资本的利用率，即当前交易之前正在使用的流动性提供者资本的金额。
• $0 \leq \hat{U}_t \leq 1$ 表示交易后流动性提供者资本的利用率，即如果用户选择执行其交易，则将使用的流动性提供者资本的金额。
• $\bar{U}$ 表示“扭结利用率”，即利率变化所在的点。
• $R_0, R_1, R_2$ 表示管理利率模型斜率的参数：
  • $R_0$ 是在 0% 利用率时收取的利率。
  • $R_0 + R_1$ 是在 $\bar{U}\%25$ 利用率时收取的利率。
  • $R_0 + R_1 + R_2$ 是在 100% 利用率时收取的利率。

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

$R(U_t) = R_0 + \frac{\min(\bar{U}, U_t)}{\bar{U}} R_1 + \frac{\max(0, U_t - \bar{U})}{1 - \bar{U}} R_2$

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

$R^at = \int{U_t}^{\hat{U}_t} R(u) du$

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

$R^w_t = \min \left( (1 + R^a_t)^{\frac{1}{52}} - 1, 1 \right)$

这将 LP 费用限制为小于或等于转移金额的 100%。

$U_t$ 可以在链上通过在 quoteTimestamp 之前或最接近的最新可用区块号调用 BridgePool 合约上的 liquidityUtilizationCurrent 方法来获取。$\hat{U}_t$ 可以通过在同一区块号调用 BridgePool 合约上的 liquidityUtilizationPostRelay 方法来获取，并将 DepositData 结构中的 amount 字段作为 relayedAmount 参数传递。通常，用于调用这些方法的 BridgePool 合约应该与 requester 相同，但在不太可能发生 BridgePool 在 L2 上迁移且存在未完成存款的情况下，应该在 quoteTimestamp 时处于活跃状态的 BridgePool 合约上计算利用率。为了识别先前的 BridgePool，应该查找由 L2 上的 deposit 合约在中继交易的 quoteTimestamp 之前发出的最后一个 WhitelistToken 事件，并使用事件的 bridgePool 字段中的地址。

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

请参阅示例 实现 获取更多详细信息。

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

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

• UBar 对应于 $\bar{U}$ rate model 参数；
• R0、R1 和 R2 分别对应于 $R_0$、$R_1$ 和 $R_2$ 参数。

上面获得的 Rate model 参数值应按 18 位小数缩小。

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

如果以上算法没有生成匹配的 realizedLPFeePct（在将结果（表示为小数）向下舍入为 18 位小数后），则该中继无效。如果 token 未在上表中列出，则该中继无效。

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

价格 Feed 实施

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

辅助数据规范

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

安全考虑

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

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