跨鏈簡史：解釋九種不同的跨鏈解決方案

跨鏈解決方案是過去一年最受關注的話題。 隨著公鏈基礎設施的興起，人們對不同鏈如何對話和通訊產生了巨大的興趣。 解決方案已經被提出並實施，但沒有一個能夠在不進行激烈權衡的情況下解決根本問題。 現在，我們研究不同的跨鏈方法，並揭示它們為何以及如何塑造跨鏈基礎設施的未來。

首先，讓我們來討論一下什麼是跨鏈技術以及為什麼需要跨鏈技術。 使用原因：鍊是異質的，需要開發人員花費大量時間來追蹤資產轉移時的差異和挑戰。 橋樑的安全性較低，而且不能 100% 可信，因為它們通常由區塊鏈專案團隊擁有並且高度集中（混亂，每個團隊沒有協調）。 Layer-1 區塊鏈的目標是標準化，但 Layer-1 鏈的分割導致需要在 Layer-1 下的跨鏈基礎設施層。

必須對跨鏈機制的歷史進行梳理和比較，以了解跨鏈解決方案並比較它們的差異和屬性。

手動傳輸

 
第一個跨鏈解決方案是手動轉移資產。 這個過程首先讓用戶將資產轉移到鏈 A 上的特定錢包，然後中心化實體監視錢包的轉移情況並將其記錄在 Excel 中。 然後，經過一段有限的時間（通常用於監控目的），實體在驗證後將資產記入鏈 B。 這種方式的優點是易於實現，但容易出現人為錯誤，安全保證很低。 這種方法也沒有去中心化。

半自動轉移

下一次迭代的改進是讓用戶將資產轉移到鏈 A 上的特定錢包和/或智能合約。然後，中心化程序監視轉移地址。 這樣的程式在驗證後會自動將資產傳送到鏈B。 優點仍然是易於實施，無需太多複雜性或編碼，並且記錄可以保存在鏈上而不是本地。 缺點是集中式程式可能有錯誤或故障。 中央信用帳戶也可能耗盡資金。 安全保障也低，沒有去中心化。

集中交易

當簡單的跨鏈解決方案無法擴展時，中心化交易所就會因跨鏈需求而蓬勃發展。 他們的工作原理是讓用戶將資產轉移到中心化交易所，然後利用交易所的“內部”互換，透過記錄記帳將A鏈上的“資產X”變成B鏈上的“資產Y” 。 優點是顯而易見的——它是最容易使用的解決方案——無需編碼，並且在一級交易所上具有高可靠性。 但問題暴露了相反的缺點——集中控制何時可以存款/提款。 中心化交易所提供了很高的安全性，但其缺點是去中心化程度最低。

集中橋

下一個進步是透過擁有一個用於跨鏈轉移資產的獨立基礎設施——一座橋樑。 中心化橋的工作原理是讓使用者轉移資產，然後利用橋的轉移功能，將鏈 A 上的資產 X 轉移到鏈 B 上的資產 Y。中心化的（或一組）中繼者負責該過程：

將資產X鎖在A鏈上
確認
在鏈 B 上鑄造資產 Y
該橋的優點是全自動過程，無需任何手動中斷。 缺點仍然是存款/提款時間的集中控制。 此外，橋可能會被關閉或被駭客入侵，導致其有時無法正常工作。 所以安全性中等，還沒去中心化。

帶有 MPC 的去中心化橋

下一次迭代是分散驗證模型而不是集中式橋樑。 MPC（多方運算）橋首先讓使用者將資產轉移到其中。 利用網橋的轉移功能，它發起將鏈 A 上的資產 X 轉移到鏈 B 上的資產 Y 的操作。通常有一組去中心化的中繼者負責該過程：

使用 MPC 將資產 X 鎖定在鏈 A 上
使用 MPC 進行驗證
使用 MPC 在鏈 B 上鑄造資產 Y
MPC的優點是全自動過程，無需任何人工中斷，且中繼節點不需要中心化。 MPC 的缺點是計算和通訊成本較高。 此外，節點可能會受到損害或串通。 安全性是中等，而去中心化也是中等。

帶有 HTLC 的原子交換橋

另一類橋樑的出現取決於原子交換（閃電網路）技術。 其運作方式是：使用者將資產轉移到原子交換橋中，然後利用橋的轉移功能，發起將鏈 A 上的資產 X 轉移到鏈 B 上的資產 Y：

建立一個新的HTLC – 哈希鎖定時合約
將資產 X 存入鏈 A 上的合約中
產生哈希鎖密鑰+加密秘密，以便在鏈B上的時間T內最終提款
將加密秘密提供給鏈 B 上的合約以提取資產 Y
或者時間T已經過去，並使用加密的秘密從A鏈上的合約中恢復資產X
顯著的優點是沒有集中節點/進程控制橋傳輸。 而且缺點也比較常見——部署 HTLC 和運行 HTLC 呼叫的成本很高。 由於無需信任，維持高安全性和審計追蹤具有挑戰性。 鑑於上述缺點，此方法的安全性很高，去中心化程度也很高。

輕客戶端+Oracle跨鏈互通

在高成本橋接方案出現之後，更多的實現方案誕生了，以降低這種成本。 輕客戶端技術已成為簡化跨鏈驗證的最新規範。 流程如下：

首先，用戶將資產X轉移到A鏈上的跨鏈互通協議的合約中
傳輸訊息在合約上設定並由去中心化中繼節點接收
節點將證明發送到鏈 B 上的協定合約
區塊頭（輕客戶端）更新由 Oracle 網路處理，以確保交付和有效性
用戶在驗證後從鏈 B 上的協議合約中提取資產 Y
這種方法的優點是從轉移到完成不需要中間代幣或鏈。 塊頭更新後可以立即確認。 缺點是 1) 來自預言機的共謀風險，2) 由於無需信任，需要保持高安全性，並且審計追蹤具有挑戰性。 這種方式的安全性中等，而去中心化程度較高。

與中繼鏈的跨鏈互通性

根據 Oracle 方法的經驗教訓，也出現了純中繼鏈解決方案。 過程略有不同：

用戶將資產X轉移到A鏈上的跨鏈互通協議的合約中
傳輸訊息在合約上設定並由去中心化中繼節點接收
節點將證明發送到中繼鏈的合約
底層中繼鏈驗證器處理區塊更新以確保交付和有效性
驗證後，中繼節點將傳輸訊息轉送到鏈 B 上的協定合約
用戶從鏈 B 上的協議合約中提取資產 Y
與簡單的 Oracle 解決方案相比，這種方法的優點是來自消耗大部分成本的中繼鏈的成本更便宜。 區塊更新後可以即時確認，這對於解決較長的延遲時間至關重要。 問題在於協議本身可能不支援全鏈生態系統。 安全性高（生態內），去中心化程度也高。

輕客戶端+中繼鏈的跨鏈基礎設施層

下一代解決方案專注於跨鏈基礎設施層，解決上述所有基本問題。 它將輕客戶端技術與中繼鏈結合以合併所有鏈：

用戶將資產X轉移到A鏈上的跨鏈基礎設施層的互通合約中
傳輸訊息在合約上設定並由去中心化中繼節點接收
節點將證明發送到中繼鏈的互通性合約
區塊頭（輕客戶端）更新由分散的維護者節點處理，以確保交付和有效性
驗證後，中繼節點將傳輸訊息轉送到鏈 B 上的互通合約
用戶從鏈B上的互通合約中提取資產Y
由於中繼鏈的實施，該解決方案以非常便宜的費用確保了互通性。 它也會在區塊頭更新後立即進行確認。 最大的挑戰是在中繼鏈上優化輕客戶端的高度複雜性。 透過進行足夠的研究和工程，這些優化應該能夠帶來其他優化無法解決的好處。 安全性非常高，去中心化程度也很高。

關於 MAP 協議

在跨鏈解決方案中，我們還沒有看到一個能夠解決上述所有問題的方案。 直到MAP協議實作。 經過3年的複雜研發，MAP Protocol最終毫不妥協地實現了輕客戶端+中繼鏈技術的Omnichain層。 MAP 實作了具有以下屬性的 Omnichain 原則：

開發人員就緒
全鏈覆蓋
最低費用
安全確定性
即時確認

MAP 協定是支援建構橋樑、DEX、互通性協定等的基礎設施層。 它支援輕客戶端直接在 MAP 中繼鏈上進行驗證—以降低成本。 它為 dapp 開發者提供內建於每個元件中的激勵措施，以賺取或呈現給最終用戶。 MAP支援EVM和非EVM鏈－協定層與所有鏈同構。

未來，MAP是所有鏈背後的基礎設施，將成為新的基礎層。 開發者不再受到選擇鏈的限制，可以專注於 dapp 產品本身。 未來是全鏈，更模組化和激勵化是必由之路。