aelf技術點解讀 | 跨鏈轉賬實現方式

買賣虛擬貨幣
跨鏈是當前區塊鏈領域最火熱的話題之一,由於鏈與鏈之間的天然隔離性以及鏈間資料互動的需求的急劇增加,跨鏈技術成為區塊鏈底層環境重要的技術需求。踐行區塊鏈互操作性(Interoperability)的發展理念也被認為是當下區塊鏈技術重要的探索方向。aelf作為自主研發的跨鏈專案,具有一套完整的跨鏈解決方案,本文將具體介紹aelf在跨鏈方面的重要特性和設計理念。跨鏈簡述進入主題之前,我們先了解一下什麼是跨鏈。A鏈上產生的資料或行為以某種形式應用在B鏈上,這個過程就稱為跨鏈。而互操作性是對上述跨鏈過程的一個屬性化描述。為了便於理解,下文將統一使用“跨鏈”來表示此過程和屬性。目前跨鏈應用場景包括但不限於跨鏈轉賬、跨鏈資產交換和鏈的擴容等。跨鏈的實現按照應用協議相容性可分為兩大類:第一類是在可互相相容應用協議的區塊鏈之間實現跨鏈, 第二類是在應用協議無法相容的區塊鏈之間實現跨鏈。跨鏈的定義是寬泛的,並沒有嚴格的跨鏈標準,但是所有跨鏈解決方案都是為了突破鏈間隔離、實現鏈間資料互動而設計。那麼是否可以完全摒棄鏈間隔離?當然不是。除了協議不相容導致天然隔離的區塊鏈專案之外,鏈間隔離更重要的一個意義在於實現資源隔離。資源隔離讓不同分散式應用場景執行在不同的鏈上,不同應用場景之間互不影響,跨鏈的過程就是在最大程度地確保資源隔離的前提下,實現鏈間資料關聯互動,這也是多鏈平臺aelf的設計理念。aelf 多鏈結構

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

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。

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

跨鏈驗證

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

· 父鏈與子鏈之間可以相互驗證
· 同級子鏈(兄弟鏈)之間可以相互驗證
· 其他關係的鏈之間不可以相互驗證

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

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

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

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

總結

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

免責聲明:

  1. 本文版權歸原作者所有,僅代表作者本人觀點,不代表鏈報觀點或立場。
  2. 如發現文章、圖片等侵權行爲,侵權責任將由作者本人承擔。
  3. 鏈報僅提供相關項目信息,不構成任何投資建議

推荐阅读

;