Hyperliquid 原生桥接：确保 4.44 亿美元资产安全的机制解析

将资金转移到 Hyperliquid 的 L1 是通过 Arbitrum 的原生桥接实现的，目前该桥接持有高达 4.44 亿美元的资产。这座桥完全由 Hyperliquid 团队从头开始构建——但它是如何工作的呢？

Hyperliquid 桥的核心组件是部署在 Arbitrum 上的 Bridge2 合约，地址为 0x2df1c51e09aecf9cacb7bc98cb1742757f163df7。这个合约持有所有桥接到 Arbitrum 的资金，并负责在用户提款时将资金返还给用户。

像任何原生桥接一样，Hyperliquid 桥有两个核心功能：存款和提款。

如何存款

• 用户在 Arbitrum 上调用 Bridge2 合约的 depositWithPermit 方法。该方法将 USDC 从用户的钱包转移到桥接合约。
• Hyperliquid L1 验证者监控合约的存款情况。一旦 2/3 的验证者（按股份计算）监听到存款事件，用户的 Hyperliquid L1 钱包（使用相同的 0x 地址）就会被记账 Credited。

如果你在想函数名中的“permit”是什么意思，它指的是 Permit2 授权方案，这是一个扩展了基本 ERC20 授权功能的智能合约。顺便说一句：虽然桥接目前只支持 USDC，但这可以很容易地更换为任何其他 ERC20 代币。

如何处理提款

现在让我们来看一下桥接的提款部分，这稍微复杂一些。如果有人能够进行恶意提款（或某人无法提取他们之前存入的资金），这可能导致资金损失——因此在提款端会进行更多的检查。

提款生命周期从 Hyperliquid L1 上的用户发起提款开始。相应的资金会立即被锁定，以防止用户发送或将其用作交易的抵押品。

一旦 Hyperliquid 验证者检测到提款，他们会使用他们的（热钱包）私钥签署提款消息并保留这些签名。一旦 2/3 的验证者签署了提款，任何人——但最有可能是其中一个验证者——都可以在 Arbitrum 上调用 Bridge2 合约的 batchedRequestWithdrawals 方法，传递验证者签名。

*（注意，我们不知道验证者如何检测到提款，或他们如何在自己之间传递签名，因为 Hyperliquid L1 的二进制文件尚未公开。）

无论如何，你会看到在桥接合约上调用的方法中包含“batched”一词，因为它支持批量处理多个提款。查看桥接合约，我们可以看到每隔大约 2 分钟就会处理一批提款。

一旦调用了批量方法，它会内部调用 requestWithdrawal 方法处理每个提款——实际上是一个一个地处理。该方法依次通过检查最初传递给桥接合约的验证者签名来验证每个提款 1）是否有效，2）是否对应至少 2/3 的验证者股份。

争议期

如果 requestWithdrawal 方法中的检查通过，就会开始一个争议期。争议期是一个可定制的参数（目前设置为 200 秒），在此期间被称为“锁定者”的批准地址可以投票锁定桥接，如果他们对提款的有效性有异议。为此，他们调用桥接合约的 voteEmergencyLock 方法。

要实际触发桥接的锁定，至少需要 lockerThreshold 个锁定者投票。目前，这个参数设置为 2。你可能会问：谁扮演锁定者的角色？最初，所有验证者的热钱包都是锁定者，但验证者也可以投票添加额外的锁定者。

如果投票通过锁定桥接，只能由验证者的冷钱包法定人数解锁。这里的关键词是“冷”——如果恶意提款真的进入争议期，网络必须假设至少 2/3 的验证者股份的热钱包已被攻破。依靠冷钱包互动来解锁桥接，确保有时间进行人工检查和干预。

完成提款

一旦争议期结束，在将资金返还到用户的 Arbitrum 钱包之前还有最后一步：完成提款。这是 Hyperliquid 实施的额外安全措施，因为理论上争议期应该能防止恶意提款通过。

争议期可能不够的情况可能包括审查攻击或严重的网络退化，这会阻止紧急锁定投票在资金释放前到达桥接合约。最终步骤通过让一个特定角色（你猜对了——一个最终确定者）主动调用 batchedFinalizeWithdrawals，传递指向相关提款的数据，从而触发资金释放来解决这个问题。

如前所述，你可能会问最终确定者是谁。根据智能合约中的内联文档，最初是一部分受信任的验证者，尽管目标是所有验证者的热地址都注册为最终确定者。

这就是 Hyperliquid 如何通过一个自定义桥接合约来确保其 TVL 的全部安全性的简短或不那么简短的总结。

翻译：老码农不上班

https://x.com/abhiii53/status/1819397976990650496