我們系列文章的第三部分將解釋融合模式，重點介紹交換解析的鏈上組件。

在本系列之前的兩篇文章中，我們分別討論瞭解析器的概念和交換解析過程的鏈下組件。

讓我們從上次中斷的地方繼續講。我們正處於交換解析過程的某個階段，解析器的後端已“決定”在某個區塊中填寫從 1inch 中繼器服務收到的 Fusion 訂單，並將一定數量的交換資產返還給用戶。現在，我們將介紹交換解析過程的鏈上部分。但首先，我們將描述此過程中的參與者。

Fusion 交換執行的鏈上部分涉及以下區塊鏈實體之間相當複雜的交互：

一個非常重要的注意事項：在某些情況下（並非總是如此），解析器會在一批中進行多次填充，最多 32 次。通常，解析器的工作合約中有多個代幣餘額，後端可以從中繼器提供的“流”中獲取多個訂單，並進行一系列填充。

我們將討論以下場景。

解析器從中繼器中選擇了 3 個可能有利可圖的訂單來執行：

• 100 DAI 至少兌換 0.6 WETH

• 0.6 WETH 兌換至少 100 DAI

• 0.01 WBTC 至少兌換 36 UNI

解析器的業務目標是執行所有 3 筆交換，使用戶至少獲得他們預期的金額。我們將忽略解析器可能的盈利策略並簡化計算，以便您瞭解總體思路。

現在，後端向工人合約提供有關選定訂單的信息。接下來會發生什麼？

注意：此圖表是專門討論交換解析的鏈下組件的文章的延續。但爲了便於理解，我們從步驟 1 開始。

步驟1

工作合約（或錢包）調用 1inch 結算合約的 settleOrders() 方法，以輕量級壓縮字節格式傳遞訂單信息；calldata 和 tokensAndAmounts 參數用於存儲此信息。

這裏，你可能會注意到一些有趣的細節：

• rateBump 來自報價方，可有效確定回報。它是當前拍賣金額與最低拍賣金額之間的百分比差。例如，如果 rateBump 值爲 4_000_000 且 auctionEndAmount（最低迴報）爲 500，則當前拍賣金額爲 700。

• totalFee 是所有解析器必須向 1inch 基金會支付的費用（重要提示：目前此功能未使用 - 解析器不向 1inch 基金會支付任何費用）。

• limitOrderProtocol 是通過相應的 Solidity 接口在結算合約中聲明的協議的一個實例。它用於從結算合約調用此合約。

第2步

結算合約調用限價訂單合約的 fillOrderTo() 方法，提供列表中 3 個訂單之一的數據 - 比如 100 DAI，至少 0.6 WETH：

• 交互——這包含以下信息：批量訂單中還有 2 個訂單需要隨後執行。

• 製作或收取金額 - 字面意思是支付多少或獲得多少。這些金額中只有一個可以是非零的。如果您設置了製作金額，則表示您希望作爲解析器接收多少金額。或者，通過設置收取金額，您可以確定您希望作爲解析器出售多少金額。一個金額將根據另一個金額進行計算。

• 目標——將接收源代幣的工作合約的地址。

步驟 3-4

限價訂單合約調用源代幣合約，使用 ERC20 Solidity 接口將交換金額從用戶轉移到解析器的工作合約。

組裝部分不太易於理解，形成調用數據並調用代幣合約。合約的組裝部分是爲了提高 gas 效率和傳遞複雜數據而創建的。

步驟 5-6

限價訂單合約使用名爲 fillOrderInteraction() 的方法回調結算合約，併發送 interactiveData ，其中包含有關批次中後續訂單的信息（先前在交互中收到的信息）。在結算方面，代碼解碼 interactiveData 並將其轉換回交互。

如果批次不再包含訂單（下面的場景 1），它將完成交互並調用解析器的工作合約“告訴”它解析訂單。這是可能的，因爲工作合約將導入我們稱爲 IResolver 的接口。在 Solidity 中，跨合約交互通常以這種方式完成。我們將在下面的步驟 16-17 中介紹工作器的作用。

如果批次中還有任何其他訂單，結算合約將再次調用限價訂單合約。這兩個合約將繼續交換數據，直到所有訂單都已結算，並且所有資金都已從用戶賬戶中收取（在我們的示例中爲 100 DAI、0.6 WETH 和 0.01 WBTC）。

步驟7

我們快完成了。工作者解析器合約已通過 1inch 結算和限價訂單合約從用戶那裏收到所有資金。現在，是時候實際解決訂單了！

以下是訂單的屬性：

• 訂單 1：100 DAI，至少 0.6 WETH

• 訂單 2：0.6 WETH，至少 100 DAI

• 訂單 3：0.01 WBTC，至少 36 UNI

看起來我們實際上可以匹配訂單 1 和訂單 2，而無需採取任何額外措施。因此，我們只需將從提交訂單 2 的用戶那裏收集的 0.6 WETH 安全地發送給提交訂單 1 的用戶，反之亦然。因此，3 個訂單中的 2 個已使用用戶自己的資金解決。

最後剩下的訂單是 0.01 WBTC 兌換 36 UNI。工作合約的餘額中沒有任何 UNI。因此，工作合約調用 1inch 聚合路由器合約的方式與任何用戶在傳統交換中執行的方式相同。解析器的後端可以調用我們的聚合 API 來獲取最佳路由並將其傳遞給工作器進行執行。路由器執行此交換並將 36 UNI 交付給解析器。

在這個簡化的例子中，解析器沒有賺到任何錢，只是花費資金在合約之間傳輸數據。在現實生活中，如上所述，解析器的後端會考慮所有費用，並確保交易對他們有利可圖，並保持在報價服務提供的框架內。解析器還會嘗試使交換對用戶來說利潤最大化。

步驟 8-11

現在，在工作解析器獲得目標代幣後，他們必須響應回調並將其轉移到結算合約。但是等等……爲什麼他們不能直接將代幣發送給用戶？

不可以，因爲架構的實施方式。請記住，此流程的第 5 步是結算合約調用的 fillOrderTo() 方法回調至限價訂單合約。因此，該函數仍在執行中！

由於調用者是結算合約，因此在此配置中，它被視爲訂單的接受者。因此，此實例應該從解析器和轉移的代幣中接收響應。然後，它向限價訂單合約提供批准，限價訂單合約又調用 transferFrom() 到目標代幣合約，交換金額最終進入用戶的錢包。我們完成了！

一個真實的 Etherscan 示例

作爲最後的練習，讓我們回顧一下 Fusion 交換的真實案例：由 Seawise 解析器解析的 1INCH 到 DAI，以及其 ERC20 代幣轉移。爲了獲得最佳體驗，您需要交叉參考下圖和上圖，並匹配步驟。

在步驟 4 中，限價訂單合約調用 1INCH 代幣合約上的 transferFrom() 將源代幣從製造商地址（0x90…9044）轉移到解析器地址。

步驟 5 和 6 未反映在此列表中，因爲它們不涉及任何 ERC20 代幣轉移。

在第 7 步，Seawise 作爲解析器將 1INCH 兌換成 Uniswap 池中的 DAI 作爲流動性來源。

在第 8 步，Seawise 將 DAI 轉移到 1inch 結算合約。

這裏也跳過了步驟 9 和 10，因爲這些是解析器和 1inch 合約之間的內部回調響應。

最後，在步驟 11，1inch 結算合約將目標代幣轉移給製造商。

歡迎在 Etherscan 上探索此交易：

https://etherscan.io/tx/0x55e621337837f4f69f0c398ad5e9072a24811bbfd8cb2b208d621b940c9689b5