Across 跨链桥合约解析 #158

qiwihui · 2022-03-18T10:00:34Z

什么是 Across

以太坊跨链协议 Across 是一种新颖的跨链方法，它结合了乐观预言机（Optimistic Oracle）、绑定中继者和单边流动性池，可以提供从 Rollup 链到以太坊主网的去中心化即时交易。目前，Across 协议通过集成以太坊二层扩容方案Optimism、Arbitrum和Boba Network支持双向桥接，即可将资产从L1发送至L2，亦可从L2发送至L1。

存款跨链流程

来源于：https://docs.across.to/bridge/how-does-across-work-1/architecture-process-walkthrough

Across 协议中，存款跨链有几种可能的流程，最重要的是，存款人在任何这些情况下都不会损失资金。在每一种情况下，在 L2 上存入的任何代币都会通过 Optimism 或 Arbitrum 的原生桥转移到 L1 上的流动池，用以偿还给流动性提供者。

从上面的流程中，我们可以看到 Across 协议流程包括以下几种：

即时中继，无争议；
即时中继，有争议；
慢速中继，无争议；
慢速中继，有争议；
慢速中继，加速为即时中继。

Across 协议中主要包括几类角色：

存款者（Depositor）：需要将资产从二层链转移到L1的用户；
中继者（Relayer）：负责将L1层资产转移给用户，以及L2层资产跨链的节点；
流动性提供者（LP）：为流动性池提供资产；
争议者（Disputor）：对中继过程有争议的人，可以向 Optimistic Oracle 提交争议；

项目总览

Across 的合约源码地址为 https://github.com/across-protocol/contracts-v1，目前 Across Protocol 正在进行 v2 版本合约的开发，我们这一篇文章主要分析 v1 版本的合约源码。首先我们下载源码：

git clone https://github.com/across-protocol/contracts-v1
cd contracts-v1

合约源码的主要的目录结构为：

contract-v1
├── contracts // Across protocol 的合约源码
├── deploy // 部署脚本
├── hardhat.config.js // hardhat 配置
├── helpers // 辅助函数
├── networks // 合约在不同链上的部署地址
└── package.json // 依赖包

在这篇解析中，我们主要关注 contracts 和 deploy 目录下的文件。

合约总览

合约目录 contracts 的目录结构为：

contracts/
├── common
│   ├── implementation
│   └── interfaces
├── external
│   ├── README.md
│   ├── avm
│   ├── chainbridge
│   ├── ovm
│   └── polygon
├── insured-bridge
│   ├── BridgeAdmin.sol
│   ├── BridgeDepositBox.sol
│   ├── BridgePool.sol
│   ├── RateModelStore.sol
│   ├── avm
│   ├── interfaces
│   ├── ovm
│   └── test
└── oracle
    ├── implementation
    └── interfaces

其中，各个目录包含的内容为：

common：一些通用功能的库方法等，包括：
- AncillaryData.sol：用来编码和解码 DVM价格请求的数据的库；
- FixedPoint.sol：定点数运算；
- Lockable.sol：防止重入攻击的一些函数修改器；
- MultiCaller.sol ：可以在当个调用中调用合约的多个方法；
- Testable.sol：测试时修改时间；
- Timer.sol：获取时间方法；
external：外部合约，主要用于实现在管理员合约中对不同 L2 的消息发送；
insured-bridge 合约主要功能，我们会在接下来的章节章节中重点分析；
oracle：主要是 Optimistic Oracle 提供功能的方法接口，在这篇文章中我们不对 Optimistic Oracle 的原理实现进行介绍，主要会介绍 Across 协议会在何处使用 Optimistic Oracle。

接下来我们会重点分析 insured-bridge 中的合约的功能，这是 Across 主要功能的合约所在。

在 insured-bridge 目录中：

BridgeAdmin.sol ：管理合约，负责管理和生成生成 L2 上的 DepositBox 合约和 L1 上的 BridgePool 合约；
BridgeDepositBox.sol ：L2 层上负责存款的抽象合约，Arbitrum，Optimism 和 Boba 网络的合约都是继承自这个合约；
BridgePool.sol ：桥接池合约，管理 L1 层资金池。

BridgeAdmin

这个合约是管理员合约，部署在L1层，并有权限管理 L1 层上的流动性池和 L2 上的存款箱（DepositBoxes）。可以注意的是，这个合约的管理帐号是一个多钱钱包，避免了一些安全问题。

首先我们看到合约中的几个状态变量：

contract BridgeAdmin is BridgeAdminInterface, Ownable, Lockable {

    address public override finder;

    mapping(uint256 => DepositUtilityContracts) private _depositContracts;

    mapping(address => L1TokenRelationships) private _whitelistedTokens;

    // Set upon construction and can be reset by Owner.
    uint32 public override optimisticOracleLiveness;
    uint64 public override proposerBondPct;
    bytes32 public override identifier;

    constructor(
        address _finder,
        uint32 _optimisticOracleLiveness,
        uint64 _proposerBondPct,
        bytes32 _identifier
    ) {
        finder = _finder;
        require(address(_getCollateralWhitelist()) != address(0), "Invalid finder");
        _setOptimisticOracleLiveness(_optimisticOracleLiveness);
        _setProposerBondPct(_proposerBondPct);
        _setIdentifier(_identifier);
    }

...

其中：

finder 用来记录查询最新 OptimisticOracle 和 UMA 生态中其他合约的合约地址；
_depositContracts 该合约可以将消息中继到任意数量的 L2 存款箱，每个 L2 网络一个，每个都由唯一的网络 ID 标识。要中继消息，需要存储存款箱合约地址和信使（messenger）合约地址。每个 L2 的信使实现不同，因为 L1 --> L2 消息传递是非标准的；
_whitelistedTokens 记录了 L1 代币地址与对应 L2 代币地址以及桥接池的映射；
optimisticOracleLiveness 中继存款的争议时长；
proposerBondPct Optimistic Oracle 中 proposer 的绑定费率

管理员可以设置以上这些变量的内容，以及可以设置每秒的 LP 费率，转移桥接池的管理员权限等。

同时，管理员还可以通过信使设置 L2 层合约的参数，包括；

setCrossDomainAdmin ：设置 L2 存款合约的管理员地址；
setMinimumBridgingDelay ：设置 L2 存款合约的最小桥接延迟；
setEnableDepositsAndRelays：开启或者暂停代币 L2 存款，这个方法会同时暂停 L1 层桥接池；
whitelistToken：关联 L2 代币地址，这样这个代币就可以开始存款和中继；

对于消息发送，管理员合约通过调用不同的信使的 relayMessage 方法来完成，将 msg.value == l1CallValue 发送给信使，然后它可以以任何方式使用它来执行跨域消息。

    function _relayMessage(
        address messengerContract,
        uint256 l1CallValue,
        address target,
        address user,
        uint256 l2Gas,
        uint256 l2GasPrice,
        uint256 maxSubmissionCost,
        bytes memory message
    ) private {
        require(l1CallValue == msg.value, "Wrong number of ETH sent");
        MessengerInterface(messengerContract).relayMessage{ value: l1CallValue }(
            target,
            user,
            l1CallValue,
            l2Gas,
            l2GasPrice,
            maxSubmissionCost,
            message
        );
    }

不同L2的消息方法分别在对应链的 CrossDomainEnabled.sol 合约中，比如：

Arbitrum: contracts/insured-bridge/avm/Arbitrum_CrossDomainEnabled.sol；
Optimism，Boba: contracts/insured-bridge/ovm/OVM_CrossDomainEnabled.sol；

BridgeDepositBox

接下来我们看到 BridgeDepositBox.sol，抽象合约 BridgeDepositBox 合约中主要有两个功能。

`bridgeTokens`

第一个是 bridgeTokens 方法，用于将 L2 层代币通过原生代币桥转移到 L1 上，这个方法需要在不同的 L2 层合约上实现，目前支持的 L2 层包括 Arbitrum，Optimism 和 Boba，分别对应的文件为：

Arbitrum: contracts/insured-bridge/avm/AVM_BridgeDepositBox.sol
Optimism: contracts/insured-bridge/ovm/OVM_BridgeDepositBox.sol
Boba: contracts/insured-bridge/ovm/OVM_OETH_BridgeDepositBox.sol

以 Arbitrum 链上的 bridgeToken 为例：

    // BridgeDepositBox.sol 文件中
    function canBridge(address l2Token) public view returns (bool) {
        return isWhitelistToken(l2Token) && _hasEnoughTimeElapsedToBridge(l2Token);
    }

		// AVM_BridgeDepositBox.sol文件中
    function bridgeTokens(address l2Token, uint32 l1Gas) public override nonReentrant() {
        uint256 bridgeDepositBoxBalance = TokenLike(l2Token).balanceOf(address(this));
        require(bridgeDepositBoxBalance > 0, "can't bridge zero tokens");
        require(canBridge(l2Token), "non-whitelisted token or last bridge too recent");

        whitelistedTokens[l2Token].lastBridgeTime = uint64(getCurrentTime());

        StandardBridgeLike(l2GatewayRouter).outboundTransfer(
            whitelistedTokens[l2Token].l1Token, // _l1Token. Address of the L1 token to bridge over.
            whitelistedTokens[l2Token].l1BridgePool, // _to. Withdraw, over the bridge, to the l1 withdraw contract.
            bridgeDepositBoxBalance, // _amount. Send the full balance of the deposit box to bridge.
            "" // _data. We don't need to send any data for the bridging action.
        );

        emit TokensBridged(l2Token, bridgeDepositBoxBalance, l1Gas, msg.sender);
    }

bridgeTokens 上有一个装饰器 canBridge 包含两个判断， isWhitelistToken 用于判断对应 L2 层代币是否已经在 L1 层上添加了桥接池， _hasEnoughTimeElapsedToBridge 用来减少频繁跨连导致的费用消耗问题，因此设置了最小的跨链接时间。

bridgeTokens 主要就是调用了 L2 层原生的跨链方法，比如 outboundTransfer。

`deposit`

第二个是 deposit 方法用于将 L2 层资产转移到以太坊 L1 层上，对应与前端页面 Deposit 操作。对应代码为：

    function bridgeTokens(address l2Token, uint32 l2Gas) public virtual;

    function deposit(
        address l1Recipient,
        address l2Token,
        uint256 amount,
        uint64 slowRelayFeePct,
        uint64 instantRelayFeePct,
        uint64 quoteTimestamp
    ) public payable onlyIfDepositsEnabled(l2Token) nonReentrant() {
        require(isWhitelistToken(l2Token), "deposit token not whitelisted");

        require(slowRelayFeePct <= 0.25e18, "slowRelayFeePct must be <= 25%");
        require(instantRelayFeePct <= 0.25e18, "instantRelayFeePct must be <= 25%");

        require(
            getCurrentTime() >= quoteTimestamp - 10 minutes && getCurrentTime() <= quoteTimestamp + 10 minutes,
            "deposit mined after deadline"
        );
        
        if (whitelistedTokens[l2Token].l1Token == l1Weth && msg.value > 0) {
            require(msg.value == amount, "msg.value must match amount");
            WETH9Like(address(l2Token)).deposit{ value: msg.value }();
        }
        else IERC20(l2Token).safeTransferFrom(msg.sender, address(this), amount);

        emit FundsDeposited(
            chainId,
            numberOfDeposits, // depositId: the current number of deposits acts as a deposit ID (nonce).
            l1Recipient,
            msg.sender,
            whitelistedTokens[l2Token].l1Token,
            l2Token,
            amount,
            slowRelayFeePct,
            instantRelayFeePct,
            quoteTimestamp
        );

        numberOfDeposits += 1;
    }

其中，合约区分了 ETH 和 ERC20 代币的存入方式。

存入资产后，合约产生了一个事件 FundsDeposited，用于中继者程序捕获并进行资产跨链，事件信息包含合约部署的 L2 链ID，存款ID numberOfDeposits，L1层接收者，存款者，L1和L2层代币地址，数量和费率，以及时间戳。

BridgePool

BridgePool 合约部署在 Layer 1 上，提供了给中继者完成 Layer2 上存款订单的函数。主要包含以下功能：

流动性提供者添加和删除流动性的方法 addLiquidity， removeLiquidity；
慢速中继： relayDeposit
即时中继： relayAndSpeedUp， speedUpRelay
争议： disputeRelay
解决中继： settleRelay

构造器

在合约初始时，合约设置了对应的桥管理员地址，L1代币地址，每秒的 LP 费率，以及标识是否为 WETH 池。同时，通过 syncUmaEcosystemParams 和 syncWithBridgeAdminParams 两个方法同步了 Optimistic Oracle 地址信息，Store 的地址信息，以及对应的 ProposerBondPct ， OptimisticOracleLiveness 等参数。

    function syncUmaEcosystemParams() public nonReentrant() {
        FinderInterface finder = FinderInterface(bridgeAdmin.finder());
        optimisticOracle = SkinnyOptimisticOracleInterface(
            finder.getImplementationAddress(OracleInterfaces.SkinnyOptimisticOracle)
        );

        store = StoreInterface(finder.getImplementationAddress(OracleInterfaces.Store));
        l1TokenFinalFee = store.computeFinalFee(address(l1Token)).rawValue;
    }

		function syncWithBridgeAdminParams() public nonReentrant() {
        proposerBondPct = bridgeAdmin.proposerBondPct();
        optimisticOracleLiveness = bridgeAdmin.optimisticOracleLiveness();
        identifier = bridgeAdmin.identifier();
    }

		constructor(
        string memory _lpTokenName,
        string memory _lpTokenSymbol,
        address _bridgeAdmin,
        address _l1Token,
        uint64 _lpFeeRatePerSecond,
        bool _isWethPool,
        address _timer
    ) Testable(_timer) ERC20(_lpTokenName, _lpTokenSymbol) {
        require(bytes(_lpTokenName).length != 0 && bytes(_lpTokenSymbol).length != 0, "Bad LP token name or symbol");
        bridgeAdmin = BridgeAdminInterface(_bridgeAdmin);
        l1Token = IERC20(_l1Token);
        lastLpFeeUpdate = uint32(getCurrentTime());
        lpFeeRatePerSecond = _lpFeeRatePerSecond;
        isWethPool = _isWethPool;

        syncUmaEcosystemParams(); // Fetch OptimisticOracle and Store addresses and L1Token finalFee.
        syncWithBridgeAdminParams(); // Fetch ProposerBondPct OptimisticOracleLiveness, Identifier from the BridgeAdmin.

        emit LpFeeRateSet(lpFeeRatePerSecond);
    }

添加和删除流动性

我们首先看到添加和删除流动性，添加流动性即流动性提供者向连接池中提供 L1 代币，并获取相应数量的 LP 代币作为证明，LP 代币数量根据现行汇率计算。

    function addLiquidity(uint256 l1TokenAmount) public payable nonReentrant() {
				// 如果是 weth 池，调用发送 msg.value，msg.value 与 l1TokenAmount 相同
				// 否则，msg.value 必需为 0
        require((isWethPool && msg.value == l1TokenAmount) || msg.value == 0, "Bad add liquidity Eth value");

			  // 由于 `_exchangeRateCurrent()` 读取合约的余额并使用它更新合约状态，
				// 因此我们必需在转入任何代币之前调用
        uint256 lpTokensToMint = (l1TokenAmount * 1e18) / _exchangeRateCurrent();
        _mint(msg.sender, lpTokensToMint);
        liquidReserves += l1TokenAmount;

        if (msg.value > 0 && isWethPool) WETH9Like(address(l1Token)).deposit{ value: msg.value }();
        else l1Token.safeTransferFrom(msg.sender, address(this), l1TokenAmount);

        emit LiquidityAdded(l1TokenAmount, lpTokensToMint, msg.sender);
    }

由于合约支持 WETH 作为流动性池，因此添加流动性区分了 WETH 和其他 ERC20 代币的添加方法。

此处的难点在于 LP 代币和 L1 代币之间的汇率换算 _exchangeRateCurrent 的实现，我们从合约中提取出了 _exchangeRateCurrent 所使用的函数，包括 _updateAccumulatedLpFees 和 _sync ：

	
		function _getAccumulatedFees() internal view returns (uint256) {
        uint256 possibleUnpaidFees =
            (undistributedLpFees * lpFeeRatePerSecond * (getCurrentTime() - lastLpFeeUpdate)) / (1e18);
        return possibleUnpaidFees < undistributedLpFees ? possibleUnpaidFees : undistributedLpFees;
    }

    function _updateAccumulatedLpFees() internal {
        uint256 unallocatedAccumulatedFees = _getAccumulatedFees();

        undistributedLpFees = undistributedLpFees - unallocatedAccumulatedFees;

        lastLpFeeUpdate = uint32(getCurrentTime());
    }

		function _sync() internal {
        uint256 l1TokenBalance = l1Token.balanceOf(address(this)) - bonds;
        if (l1TokenBalance > liquidReserves) {
            
            utilizedReserves -= int256(l1TokenBalance - liquidReserves);
            liquidReserves = l1TokenBalance;
        }
    }
    
		function _exchangeRateCurrent() internal returns (uint256) {
        if (totalSupply() == 0) return 1e18; // initial rate is 1 pre any mint action.

        _updateAccumulatedLpFees();
        _sync();

        int256 numerator = int256(liquidReserves) + utilizedReserves - int256(undistributedLpFees);
        return (uint256(numerator) * 1e18) / totalSupply();
    }

换算汇率等于当前合约中代币的储备与总 LP 供应量的比值，计算步骤如下：

更新自上次方法调用以来的累积LP费用 _updateAccumulatedLpFees
1. 计算可能未付的费用 possibleUnpaidFees ，等于未分配的 Lp 费用 undistributedLpFees * 每秒 LP 费率 *（当前时间-上次更新时间），目前 WETH 桥接池中每秒LP费率为 0.0000015。
2. 计算累积费用 unallocatedAccumulatedFees ，如果 possibleUnpaidFees 小于未分配的 Lp 费用，则所有未分配的 LP 费用都将用于累积费用；
3. 当前未分配 LP 费用 = 原先未分配 LP 费用 - 累积费用；
计算由于代币桥接产生的余额变化
1. 当前合约中的代币储备=当前合约中的代币数量 - 被绑定在中继过程中的代币数量；
2. 如果当前合约中的代币储备大于流动储备 liquidReserves，则被使用的储备 utilizedReserves = 原先被使用的储备 -（当前合约中的代币储备 - 流动储备）；
3. 当前流动性储备 = 当前合约中的代币储备；
计算汇率：
1. 经过更新之后，汇率计算的分子：流动储备 + 被使用的储备 - 未被分配 LP 费用；
2. 分子与LP 代币总供应量的比值即为换算汇率。

利用换算汇率，可以计算得到添加 l1TokenAmount 数量的代币时所能得到的 LP 代币的数量。

对于移除流动性，过程与添加流动性相反，这里不再赘述。

    function removeLiquidity(uint256 lpTokenAmount, bool sendEth) public nonReentrant() {
        // 如果是 WETH 池，则只能通过发送 ETH 来取出流动性
        require(!sendEth || isWethPool, "Cant send eth");
        uint256 l1TokensToReturn = (lpTokenAmount * _exchangeRateCurrent()) / 1e18;

        // 检查是否有足够的流储备来支持取款金额
        require(liquidReserves >= (pendingReserves + l1TokensToReturn), "Utilization too high to remove");

        _burn(msg.sender, lpTokenAmount);
        liquidReserves -= l1TokensToReturn;

        if (sendEth) _unwrapWETHTo(payable(msg.sender), l1TokensToReturn);
        else l1Token.safeTransfer(msg.sender, l1TokensToReturn);

        emit LiquidityRemoved(l1TokensToReturn, lpTokenAmount, msg.sender);
    }

慢速中继

慢速中继，以及之后要讨论的即时中继，都会用到 DepositData 和 RelayData 这两个数据，前者表示存框交易的数据，后者表示中继交易的信息。

		// 来自 L2 存款交易的数据。
    struct DepositData {
        uint256 chainId;
        uint64 depositId;
        address payable l1Recipient;
        address l2Sender;
        uint256 amount;
        uint64 slowRelayFeePct;
        uint64 instantRelayFeePct;
        uint32 quoteTimestamp;
    }

		// 每个 L2 存款在任何时候都可以进行一次中继尝试。 中继尝试的特征在于其 RelayData。
    struct RelayData {
        RelayState relayState;
        address slowRelayer;
        uint32 relayId;
        uint64 realizedLpFeePct;
        uint32 priceRequestTime;
        uint256 proposerBond;
        uint256 finalFee;
    }

下面我们看到 relayDeposit 方法，这个方法由中继者调用，执行从 L2 到 L1 的慢速中继。对于每一个存款而言，只能有一个待处理的中继，这个待处理的中继不包括有争议的中继。

    function relayDeposit(DepositData memory depositData, uint64 realizedLpFeePct)
        public
        onlyIfRelaysEnabld()
        nonReentrant()
    {
				// realizedLPFeePct 不超过 50%，慢速和即时中继费用不超过25%，费用合计不超过100%
        require(
            depositData.slowRelayFeePct <= 0.25e18 &&
                depositData.instantRelayFeePct <= 0.25e18 &&
                realizedLpFeePct <= 0.5e18,
            "Invalid fees"
        );

        // 查看是否已经有待处理的中继
        bytes32 depositHash = _getDepositHash(depositData);

				// 对于有争议的中继，relays 中对应的 hash 会被删除，这个条件可以通过
        require(relays[depositHash] == bytes32(0), "Pending relay exists");

				// 如果存款没有正在执行的中继，则关联调用者的中继尝试
        uint32 priceRequestTime = uint32(getCurrentTime());

        uint256 proposerBond = _getProposerBond(depositData.amount);

        // 保存新中继尝试参数的哈希值。
        // 注意：这个中继的活跃时间（liveness）可以在 BridgeAdmin 中更改，这意味着每个中继都有一个潜在的可变活跃时间。
				// 这不应该提供任何被利用机会，特别是因为 BridgeAdmin 状态（包括 liveness 值）被许可给跨域所有者。
				RelayData memory relayData =
            RelayData({
                relayState: RelayState.Pending,
                slowRelayer: msg.sender,
                relayId: numberOfRelays++, // 注意：在将 relayId 设置为其当前值的同时增加 numberOfRelays。
                realizedLpFeePct: realizedLpFeePct,
                priceRequestTime: priceRequestTime,
                proposerBond: proposerBond,
                finalFee: l1TokenFinalFee
            });
        relays[depositHash] = _getRelayDataHash(relayData);

        bytes32 relayHash = _getRelayHash(depositData, relayData);

				// 健全性检查池是否有足够的余额来支付中继金额 + 提议者奖励。 OptimisticOracle 价格请求经过挑战期后，将在结算时支付奖励金额。
        // 注意：liquidReserves 应该总是 <= balance - bonds。
        require(liquidReserves - pendingReserves >= depositData.amount, "Insufficient pool balance");

				// 计算总提议保证金并从调用者那里拉取，以便 OptimisticOracle 可以从这里拉取它。
        uint256 totalBond = proposerBond + l1TokenFinalFee;
        pendingReserves += depositData.amount; // 在正在处理的准备中预订此中继使用的最大流动性。
        bonds += totalBond;

        l1Token.safeTransferFrom(msg.sender, address(this), totalBond);
        emit DepositRelayed(depositHash, depositData, relayData, relayHash);
    }

可以看到，存款哈希与 depositData 有关，中继哈希与 depositData 和 relayData 都有关。最后我们可以看到， relayDeposit 还未实际付款给用户的 L1 地址，需要等待中继者处理，或者通过加速处理中继。

加速中继

speedUpRelay 方法立即将存款金额减去费用后转发给 l1Recipient，即时中继者在待处理的中继挑战期后获得奖励。

    // 我们假设调用者已经执行了链外检查，以确保他们尝试中继的存款数据是有效的。
		// 如果存款数据无效，则即时中继者在无效存款数据发生争议后无权收回其资金。
		// 此外，没有人能够重新提交无效存款数据的中继，因为他们知道这将再次引起争议。
		// 另一方面，如果存款数据是有效的，那么即使它被错误地争议，即时中继者最终也会得到补偿，
		// 因为会激励其他人重新提交中继，以获得慢中继者的奖励。
		// 一旦有效中继最终确定，即时中继将得到补偿。因此，调用者在验证中继数据方面与争议者具有相同的责任。
		function speedUpRelay(DepositData memory depositData, RelayData memory relayData) public nonReentrant() {
        bytes32 depositHash = _getDepositHash(depositData);
        _validateRelayDataHash(depositHash, relayData);
        bytes32 instantRelayHash = _getInstantRelayHash(depositHash, relayData);
        require(
            // 只能在没有与之关联的现有即时中继的情况下加速待处理的中继。
            getCurrentTime() < relayData.priceRequestTime + optimisticOracleLiveness &&
                relayData.relayState == RelayState.Pending &&
                instantRelays[instantRelayHash] == address(0),
            "Relay cannot be sped up"
        );
        instantRelays[instantRelayHash] = msg.sender;

        // 从调用者那里提取中继金额减去费用并发送存款到 l1Recipient。
				// 支付的总费用是 LP 费用、中继费用和即时中继费用的总和。
        uint256 feesTotal =
            _getAmountFromPct(
                relayData.realizedLpFeePct + depositData.slowRelayFeePct + depositData.instantRelayFeePct,
                depositData.amount
            );
        // 如果 L1 代币是 WETH，那么：a) 从即时中继者提取 WETH b) 解包 WETH 为 ETH c) 将 ETH 发送给接收者。
        uint256 recipientAmount = depositData.amount - feesTotal;
        if (isWethPool) {
            l1Token.safeTransferFrom(msg.sender, address(this), recipientAmount);
            _unwrapWETHTo(depositData.l1Recipient, recipientAmount);
            // 否则，这是一个普通的 ERC20 代币。 发送给收件人。
        } else l1Token.safeTransferFrom(msg.sender, depositData.l1Recipient, recipientAmount);

        emit RelaySpedUp(depositHash, msg.sender, relayData);
    }

即时中继

relayAndSpeedUp 执行即时中继。这个方法的函数内容与 relayDeposit 和 speedUpRelay 方法是一致的，这里就不具体注释了，可以参考前文中的注释。这个函数的代码几乎是直接将 relayDeposit 和 speedUpRelay 的代码进行了合并，代码冗余。

    // 由 Relayer 调用以执行从 L2 到 L1 的慢 + 快中继，完成相应的存款订单。
    // 存款只能有一个待处理的中继。此方法实际上是串联的 relayDeposit 和 speedUpRelay 方法。
		// 这可以重构为只调用每个方法，但是结合传输和哈希计算可以节省一些 gas。
		function relayAndSpeedUp(DepositData memory depositData, uint64 realizedLpFeePct)
        public
        onlyIfRelaysEnabld()
        nonReentrant()
    {
        uint32 priceRequestTime = uint32(getCurrentTime());

        require(
            depositData.slowRelayFeePct <= 0.25e18 &&
                depositData.instantRelayFeePct <= 0.25e18 &&
                realizedLpFeePct <= 0.5e18,
            "Invalid fees"
        );

        bytes32 depositHash = _getDepositHash(depositData);

        require(relays[depositHash] == bytes32(0), "Pending relay exists");

        uint256 proposerBond = _getProposerBond(depositData.amount);

        RelayData memory relayData =
            RelayData({
                relayState: RelayState.Pending,
                slowRelayer: msg.sender,
                relayId: numberOfRelays++, // Note: Increment numberOfRelays at the same time as setting relayId to its current value.
                realizedLpFeePct: realizedLpFeePct,
                priceRequestTime: priceRequestTime,
                proposerBond: proposerBond,
                finalFee: l1TokenFinalFee
            });
        bytes32 relayHash = _getRelayHash(depositData, relayData);
        relays[depositHash] = _getRelayDataHash(relayData);

        bytes32 instantRelayHash = _getInstantRelayHash(depositHash, relayData);
        require(
            instantRelays[instantRelayHash] == address(0),
            "Relay cannot be sped up"
        );

        require(liquidReserves - pendingReserves >= depositData.amount, "Insufficient pool balance");

        uint256 totalBond = proposerBond + l1TokenFinalFee;

        uint256 feesTotal =
            _getAmountFromPct(
                relayData.realizedLpFeePct + depositData.slowRelayFeePct + depositData.instantRelayFeePct,
                depositData.amount
            );
        uint256 recipientAmount = depositData.amount - feesTotal;

        bonds += totalBond;
        pendingReserves += depositData.amount;

        instantRelays[instantRelayHash] = msg.sender;

        l1Token.safeTransferFrom(msg.sender, address(this), recipientAmount + totalBond);

        if (isWethPool) {
            _unwrapWETHTo(depositData.l1Recipient, recipientAmount);
        } else l1Token.safeTransfer(depositData.l1Recipient, recipientAmount);

        emit DepositRelayed(depositHash, depositData, relayData, relayHash);
        emit RelaySpedUp(depositHash, msg.sender, relayData);
    }

争议

当对待处理的中继提出争议时，争议者需要想 Optimistic Oracle 提交提案，并等待争议解决。

    // 由 Disputer 调用以对待处理的中继提出争议。
		// 这个方法的结果是总是抛出中继，为另一个中继者提供处理相同存款的机会。
		// 在争议者和提议者之间，谁不正确，谁就失去了他们的质押。谁是正确的，谁就拿回来并获得一笔钱。
		function disputeRelay(DepositData memory depositData, RelayData memory relayData) public nonReentrant() {
        require(relayData.priceRequestTime + optimisticOracleLiveness > getCurrentTime(), "Past liveness");
        require(relayData.relayState == RelayState.Pending, "Not disputable");
        // 检验输入数据
        bytes32 depositHash = _getDepositHash(depositData);
        _validateRelayDataHash(depositHash, relayData);

        // 将提案和争议提交给 Optimistic Oracle。
        bytes32 relayHash = _getRelayHash(depositData, relayData);

        // 注意：在某些情况下，这会由于 Optimistic Oracle 的变化而失败，并且该方法将退还中继者。
        bool success =
            _requestProposeDispute(
                relayData.slowRelayer,
                msg.sender,
                relayData.proposerBond,
                relayData.finalFee,
                _getRelayAncillaryData(relayHash)
            );

				// 放弃中继并从跟踪的保证金中移除中继的保证金。
        bonds -= relayData.finalFee + relayData.proposerBond;
        pendingReserves -= depositData.amount;
        delete relays[depositHash];
        if (success) emit RelayDisputed(depositHash, _getRelayDataHash(relayData), msg.sender);
        else emit RelayCanceled(depositHash, _getRelayDataHash(relayData), msg.sender);
    }

其中， _requestProposeDispute 的函数内容如下：

    // 向 optimistic oracle 提议与 `customAncillaryData` 相关的中继事件的新价格为真。
		// 如果有人不同意中继参数，不管他们是否映射到 L2 存款，他们可以与预言机争议。
    function _requestProposeDispute(
        address proposer,
        address disputer,
        uint256 proposerBond,
        uint256 finalFee,
        bytes memory customAncillaryData
    ) private returns (bool) {
        uint256 totalBond = finalFee + proposerBond;
        l1Token.safeApprove(address(optimisticOracle), totalBond);
        try
            optimisticOracle.requestAndProposePriceFor(
                identifier,
                uint32(getCurrentTime()),
                customAncillaryData,
                IERC20(l1Token),
                // 将奖励设置为 0，因为在中继提案经过挑战期后，我们将直接从该合约中结算提案人奖励支出。
                0,
                // 为价格请求设置 Optimistic oracle 提议者保证金。
                proposerBond,
                // 为价格请求设置 Optimistic oracle 活跃时间。
                optimisticOracleLiveness,
                proposer,
                // 表示 "True"; 及提议的中继是合法的
                int256(1e18)
            )
        returns (uint256 bondSpent) {
            if (bondSpent < totalBond) {
                // 如果 Optimistic oracle 拉取得更少（由于最终费用的变化），则退还提议者。
                uint256 refund = totalBond - bondSpent;
                l1Token.safeTransfer(proposer, refund);
                l1Token.safeApprove(address(optimisticOracle), 0);
                totalBond = bondSpent;
            }
        } catch {
            // 如果 Optimistic oracle 中出现错误，这意味着已经更改了某些内容以使该请求无可争议。
						// 为确保请求不会默认通过，退款提议者并提前返回，允许调用方法删除请求，但 Optimistic oracle 没有额外的追索权。
            l1Token.safeTransfer(proposer, totalBond);
            l1Token.safeApprove(address(optimisticOracle), 0);

            // 提早返回，注意到提案+争议的尝试没有成功。
            return false;
        }

        SkinnyOptimisticOracleInterface.Request memory request =
            SkinnyOptimisticOracleInterface.Request({
                proposer: proposer,
                disputer: address(0),
                currency: IERC20(l1Token),
                settled: false,
                proposedPrice: int256(1e18),
                resolvedPrice: 0,
                expirationTime: getCurrentTime() + optimisticOracleLiveness,
                reward: 0,
                finalFee: totalBond - proposerBond,
                bond: proposerBond,
                customLiveness: uint256(optimisticOracleLiveness)
            });

        // 注意：在此之前不要提取资金，以避免任何不需要的转账。
        l1Token.safeTransferFrom(msg.sender, address(this), totalBond);
        l1Token.safeApprove(address(optimisticOracle), totalBond);
        // 对我们刚刚发送的请求提出争议。
        optimisticOracle.disputePriceFor(
            identifier,
            uint32(getCurrentTime()),
            customAncillaryData,
            request,
            disputer,
            address(this)
        );

        // 返回 true 表示提案 + 争议调用成功。
        return true;
    }

最后，我们来看看 settleRelay。

    // 如果待处理中继价格请求在 OptimisticOracle 上有可用的价格，则奖励中继者，并将中继标记为完成。
	  // 我们使用 relayData 和 depositData 来计算中继价格请求在 OptimisticOracle 上唯一关联的辅助数据。
		// 如果传入的价格请求与待处理的中继价格请求不匹配，那么这将恢复(revert)。
		function settleRelay(DepositData memory depositData, RelayData memory relayData) public nonReentrant() {
        bytes32 depositHash = _getDepositHash(depositData);
        _validateRelayDataHash(depositHash, relayData);
        require(relayData.relayState == RelayState.Pending, "Already settled");
        uint32 expirationTime = relayData.priceRequestTime + optimisticOracleLiveness;
        require(expirationTime <= getCurrentTime(), "Not settleable yet");

        // 注意：此检查是为了给中继者一小段但合理的时间来完成中继，然后再被其他人“偷走”。
				// 这是为了确保有动力快速解决中继。
        require(
            msg.sender == relayData.slowRelayer || getCurrentTime() > expirationTime + 15 minutes,
            "Not slow relayer"
        );

        // 将中继状态更新为已完成。 这可以防止中继的任何重新设处理。
        relays[depositHash] = _getRelayDataHash(
            RelayData({
                relayState: RelayState.Finalized,
                slowRelayer: relayData.slowRelayer,
                relayId: relayData.relayId,
                realizedLpFeePct: relayData.realizedLpFeePct,
                priceRequestTime: relayData.priceRequestTime,
                proposerBond: relayData.proposerBond,
                finalFee: relayData.finalFee
            })
        );

        // 奖励中继者并支付 l1Recipient。
         // 此时有两种可能的情况：
         // - 这是一个慢速中继：在这种情况下，a) 向慢速中继者支付奖励 b) 向 l1Recipient 支付
         //   金额减去已实现的 LP 费用和慢速中继费用。 转账没有加快，所以没有即时费用。
         // - 这是一个即时中继：在这种情况下，a) 向慢速中继者支付奖励 b) 向即时中继者支付
         //   全部桥接金额，减去已实现的 LP 费用并减去慢速中继费用。
				//    当即时中继者调用 speedUpRelay 时，它们存入的金额相同，减去即时中继者费用。
				//    结果，他们实际上得到了加速中继时所花费的费用 + InstantRelayFee。

        uint256 instantRelayerOrRecipientAmount =
            depositData.amount -
                _getAmountFromPct(relayData.realizedLpFeePct + depositData.slowRelayFeePct, depositData.amount);

        // 如果即时中继参数与批准的中继相匹配，则退款给即时中继者。
        bytes32 instantRelayHash = _getInstantRelayHash(depositHash, relayData);
        address instantRelayer = instantRelays[instantRelayHash];

        // 如果这是 WETH 池并且即时中继者是地址 0x0（即中继没有加速），那么：
        // a) 将 WETH 提取到 ETH 和 b) 将 ETH 发送给接收者。
        if (isWethPool && instantRelayer == address(0)) {
            _unwrapWETHTo(depositData.l1Recipient, instantRelayerOrRecipientAmount);
            // 否则，这是一个正常的慢速中继正在完成，合约将 ERC20 发送给接收者，
						// 或者这是一个即时中继的最终完成，我们需要用 WETH 偿还即时中继者。
        } else
            l1Token.safeTransfer(
                instantRelayer != address(0) ? instantRelayer : depositData.l1Recipient,
                instantRelayerOrRecipientAmount
            );

        // 需要支付费用和保证金。费用归解决者。保证金总是归到慢速中继者。
        // 注意：为了 gas 效率，我们使用 `if`，所以如果它们是相同的地址，我们可以合并这些转账。
        uint256 slowRelayerReward = _getAmountFromPct(depositData.slowRelayFeePct, depositData.amount);
        uint256 totalBond = relayData.finalFee + relayData.proposerBond;
        if (relayData.slowRelayer == msg.sender)
            l1Token.safeTransfer(relayData.slowRelayer, slowRelayerReward + totalBond);
        else {
            l1Token.safeTransfer(relayData.slowRelayer, totalBond);
            l1Token.safeTransfer(msg.sender, slowRelayerReward);
        }

        uint256 totalReservesSent = instantRelayerOrRecipientAmount + slowRelayerReward;

        // 按更改的金额和分配的 LP 费用更新储备。
        pendingReserves -= depositData.amount;
        liquidReserves -= totalReservesSent;
        utilizedReserves += int256(totalReservesSent);
        bonds -= totalBond;
        _updateAccumulatedLpFees();
        _allocateLpFees(_getAmountFromPct(relayData.realizedLpFeePct, depositData.amount));

        emit RelaySettled(depositHash, msg.sender, relayData);

        // 清理状态存储并获得gas退款。
				// 这也可以防止 `priceDisputed()` 重置这个新的 Finalized 中继状态。
        delete instantRelays[instantRelayHash];
    }

    function _allocateLpFees(uint256 allocatedLpFees) internal {
        undistributedLpFees += allocatedLpFees;
        utilizedReserves += int256(allocatedLpFees);
    }

至此，我们分析完了 Across 合约的主要功能的代码。

合约部署

部署合约目录 deploy 下包含 8 脚本，依次部署了管理合约，WETH 桥接池，Optimism，Arbitrum和Boba的信使，以及 Arbitrum，Optimism 和 Boba 的存款合约。由于过程比较简单，这里就不仔细分析了。

deploy/
├── 001_deploy_across_bridge_admin.js
├── 002_deploy_across_weth_bridge_pool.js
├── 003_deploy_across_optimism_wrapper.js
├── 004_deploy_across_optimism_messenger.js
├── 005_deploy_across_arbitrum_messenger.js
├── 006_deploy_across_boba_messenger.js
├── 007_deploy_across_ovm_bridge_deposit_box.js
└── 008_deploy_across_avm_deposit_box.js

总结

Across 协议整体结构简单，流程清晰，支持了 Across 协议安全，快速的从 L2 向 L1 的资金转移。

代码中调用了 Optimistic Oracle 的接口来出和解决争议，对应的逻辑有空之后详说。

The text was updated successfully, but these errors were encountered:

qiwihui added the 区块链区块链相关 label Mar 18, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Across 跨链桥合约解析 #158

Across 跨链桥合约解析 #158

qiwihui commented Mar 18, 2022 •

edited

Loading

Across 跨链桥合约解析 #158

Across 跨链桥合约解析 #158

Comments

qiwihui commented Mar 18, 2022 • edited Loading

什么是 Across

存款跨链流程

项目总览

合约总览

BridgeAdmin

BridgeDepositBox

bridgeTokens

deposit

BridgePool

构造器

添加和删除流动性

慢速中继

加速中继

即时中继

争议

合约部署

总结

qiwihui commented Mar 18, 2022 •

edited

Loading

`bridgeTokens`

`deposit`