解讀 aelf 跨鏈轉賬實現方式

原文標題：《aelf 技術點解讀 | 跨鏈轉賬實現方式》

原文來源：aelf 

跨鏈是當前區塊鏈領域最火熱的話題之一，由於鏈與鏈之間的天然隔離性以及鏈間數據交互的需求的急劇增加，跨鏈技術成爲區塊鏈底層環境重要的技術需求。踐行區塊鏈互操作性（Interoperability）的發展理念也被認爲是當下區塊鏈技術重要的探索方向。aelf 作爲自主研發的跨鏈項目，具有一套完整的跨鏈解決方案，本文將具體介紹 aelf 在跨鏈方面的重要特性和設計理念。

跨鏈簡述

進入主題之前，我們先了解一下什麼是跨鏈。A 鏈上產生的數據或行爲以某種形式應用在 B 鏈上，這個過程就稱爲跨鏈。而互操作性是對上述跨鏈過程的一個屬性化描述。爲了便於理解，下文將統一使用「跨鏈」來表示此過程和屬性。目前跨鏈應用場景包括但不限於跨鏈轉賬、跨鏈資產交換和鏈的擴容等。跨鏈的實現按照應用協議兼容性可分爲兩大類：第一類是在可互相兼容應用協議的區塊鏈之間實現跨鏈，第二類是在應用協議無法兼容的區塊鏈之間實現跨鏈。

跨鏈的定義是寬泛的，並沒有嚴格的跨鏈標準，但是所有跨鏈解決方案都是爲了突破鏈間隔離、實現鏈間數據交互而設計。那麼是否可以完全摒棄鏈間隔離？當然不是。除了協議不兼容導致天然隔離的區塊鏈項目之外，鏈間隔離更重要的一個意義在於實現資源隔離。資源隔離讓不同分佈式應用場景運行在不同的鏈上，不同應用場景之間互不影響，跨鏈的過程就是在最大程度地確保資源隔離的前提下，實現鏈間數據關聯交互，這也是多鏈平臺 aelf 的設計理念。

aelf 多鏈結構

aelf 是一個基於多級主-側鏈體系的多鏈結構網絡。首先對 aelf 的多鏈結構進行解析：一主鏈、多側鏈、多層級。圖 1 表示的是鏈與鏈之間的從屬關係，各個側鏈都是基於上一級鏈創建出來的，下文將用父鏈和子鏈表達這種結構關係。該結構關係意味着每一條鏈都可創建自己的子鏈。aelf 的多鏈結構的優勢不僅在於可實現不同應用場景的鏈間隔離，同時可利用鏈間從屬關係創建更多子鏈以擴展應用場景。

圖 1

aelf 的多鏈結構是基於一鏈一場景這一核心理念設計的。主鏈僅支持共識模塊，經濟系統模塊和跨鏈模塊等系統合約，aelf 社區並不建議在主鏈上部署過多的場景，而是將豐富多樣的場景部署到側鏈。每條側鏈的場景複雜度都是 O(1)，可將不同場景的 DApp 部署在不同的側鏈上。基於這樣的設計理念，aelf 實現了前文提到的資源隔離。目前一些公鏈經常遇到一個問題：單個爆款應用即可能導致整條鏈堵塞，導致短時間內鏈上交易費提高數倍，根本原因就在於所有應用和資產都部署在同一條鏈上，但是一鏈一場景的設計機制可有效避免這個問題，一條鏈的堵塞並不會影響到其他鏈的正常運行。

鏈的生命週期

主鏈是 aelf 生態系統的中樞，也是整個生態啓動運行的第一條鏈。主鏈上部署了若干系統合約，其他具體的應用場景需申請創建側鏈並在側鏈上進行部署。創建側鏈時需要向社區提出申請，同時需抵押一定的 ELF token，並提供索引費用和相關資源 token 使用計劃等信息，等待社區審批通過。側鏈創建申請通過後，即可創建側鏈並啓動運行，該側鏈也隨即被主鏈索引（有關索引的內容將在後文介紹）。側鏈申請通過後可以對該鏈進行索引費充值，以保證主鏈提供穩定索引服務。如需停止對該側鏈的索引時，同樣需向社區提出申請，審批通過後主鏈正式停止對該側鏈的索引。基於側鏈創建下級子鏈的過程和上述過程一致，此時側鏈將充當父鏈的角色。

跨鏈索引

索引是指按照定義好的結構從某條鏈將數據傳遞給其他鏈。跨鏈索引是實現任何跨鏈功能的前提。aelf 採用「聯合挖礦」的理念，即由礦工自主完成索引過程。

aelf 這樣的設計能夠有效解決兩個問題：

第一個問題是某條鏈是否可以被信任。這是在跨鏈過程存在的一個常見問題，只有有效運行的區塊鏈才被認爲可以安全索引。aelf 採用的「聯合挖礦」理念從根本上解決了這個問題，可兼顧到主鏈與側鏈的正常運行，而不需要對鏈自身設計冗餘的信任機制。

第二個問題是數據索引是否去中心化。這是跨鏈過程中一個比較棘手的問題。如何保證去中心化是跨鏈解決方案的一大挑戰。aelf 的策略是礦工自主完成索引，並且索引數據作爲普通數據參與共識等驗證過程，因此 aelf 的索引過程和數據源是完全去中心化的，可最大程度地保障索引數據的安全。

aelf 跨鏈索引分爲兩部分：父鏈索引子鏈和子鏈索引父鏈

父鏈從子鏈獲取數據。父鏈對其需要索引的子鏈請求數據，如圖 2 示，子鏈將區塊內的 Transaction status merkle tree root 傳遞給主鏈。

父鏈將索引的所有子鏈數據進行處理，生成 Merkle tree，並存儲在鏈內部，如圖 3 示。至此，該子鏈區塊即已被父鏈索引，只需等待該數據得到網絡的確認。

子鏈索引父鏈區塊，即從父鏈請求數據。如圖 4 示，子鏈返回的數據：1. 已計算好的 merkle tree root;2. Merkle path。

上述步驟包含了父鏈索引子鏈區塊及子鏈再索引父鏈區塊的完整過程。這裏有一點需要強調的是隻有不可逆轉的區塊才能被其他鏈索引。這是因爲區塊鏈是去中心化的分佈式賬本，數據在被確認前是可能被逆轉的，只有被確認成爲不可逆轉的數據纔是可信的，這樣可以有效的保護跨鏈的安全性，確保有足夠多的節點處於相同的狀態，避免跨鏈數據對本鏈的影響。

圖 2

圖 3

圖 4

跨鏈驗證

跨鏈驗證直觀上理解爲在 A 鏈上驗證 B 鏈上發生的事。aelf 多鏈結構的設計理念是一鏈一場景，並不是所有鏈之間都有聯繫。鏈與鏈之間的驗證關係也符合場景部署相關的原則，具體如下：

父鏈與子鏈之間可以相互驗證

同級子鏈（兄弟鏈）之間可以相互驗證

其他關係的鏈之間不可以相互驗證

aelf 應用的是常見的的數據結構：默克爾樹。上述索引過程也提到過這個數據結構，它是一個普通的樹的結構，葉子結點包含某些特定數據進行哈希運算所得結果值，再由葉子結點向上兩兩進行 Hash 運算直到根節點。在這裏 aelf 使用的是 SHA256 的加密算法。

圖 5

之所以選擇默克爾樹是因爲在於僅需付出很小的成本即可完成上述過程。如圖 6 示，提取樹中紅色葉子結點到根節點的計算路徑，設爲 Merkle Path。Merkle Path 可以很方便地從樹裏提取出來，如圖 6 中的綠色節點所示。上文提到的索引過程中的 Merkle tree root 是一個 32 字節的定長數據結構，而 Merkle path 也僅需付出 log(n) 的空間複雜度，這極大的降低了跨鏈數據傳輸負載壓力，保障跨鏈效率。

這棵樹的結構和 SHA256 算法共同確保了這樣的特性：通過根節點的一致性可以確保整棵樹的正確性。跨鏈驗證也是基於這樣的特性進行設計。根據默克爾樹的特性，僅利用葉子結點和提取出來的 Merkle Path 就可以計算出最終的黃色根節點。在跨鏈驗證過程中，只需要利用 Merkle Path 進行一次從葉子結點到根節點的計算，即可驗證數據準確性，時間複雜度 log(n)，確保驗證效率。

利用上述結構可以高效完成數據存在性證明，從而實現跨鏈驗證。存在性證明是 aelf 跨鏈機制的核心。aelf 跨鏈模塊並不侷限於某一項特定的應用場景，而是利用存在性證明來提供一個開發跨鏈應用的高效平臺。基於存在性證明，aelf 在未來可以發掘、實現更多的應用場景。

圖 6

總結

aelf 致力於通過提供可行的跨鏈解決方案來實現去中心化跨鏈平臺的構建。基於「一鏈一場景」的設計理念，aelf 跨鏈機制可高效安全地實現跨鏈數據交互，同時可確保鏈間資源的有效隔離。由主鏈出塊節點提供索引服務，可確保其去中心化程度；索引數據負載低，可確保跨鏈高效；只有不可逆轉的區塊才能被其他鏈索引的機規則， 則保障了跨鏈的安全性；經典的 Merkle Proof 驗證方法，則可保障跨鏈的驗證效率。

原文地址:https://mp.weixin.qq.com/s/JdsW-Ulc10mMPQmqfXThnw

歡迎加入律動 BlockBeats 官方社群：

Telegram 訂閱群：https://t.me/theblockbeats

Telegram 交流群：https://t.me/BlockBeats_App

Twitter 官方帳號：https://twitter.com/BlockBeatsAsia