• <option id="cacee"><noscript id="cacee"></noscript></option>
  • <table id="cacee"><noscript id="cacee"></noscript></table>
  • <td id="cacee"></td>
  • <option id="cacee"></option>
  • <table id="cacee"></table>
  • <option id="cacee"><option id="cacee"></option></option>
  • <table id="cacee"><source id="cacee"></source></table><td id="cacee"><rt id="cacee"></rt></td>
    <option id="cacee"><option id="cacee"></option></option>
     找回密碼
     立即注冊

    掃一掃,登錄網站

    首頁 自媒體 查看內容
    • 1313
    • 0
    • 分享到

    似曾相識燕歸來——Libra初體驗

    2020-7-17 11:02

    來源: jingtumzs

    2019年6月18日,Facebook 旗下 Libra 官網上線,并發布了白皮書。根據白皮書,Libra 將建立一套簡單的、無國界的貨幣、服務于數十億人的金融基礎設施。Libra 一經推出就受到了廣泛關注,引發了激烈討論和各國監管層的擔憂。也有意見認為Libra融合了區塊鏈技術和比特幣的優勢,升級了技術和發行機制,實現了普惠金融。


    2020年4月16日,Libra 協會發布了新版白皮書,增加了大量關于合規方面的設計。


    本文無意去加入以上關于 Libra 的金融與政策層面話題討論,而是撥云去霧,希望從技術角度去理解 Libra 所構建的區塊鏈世界。全部資料來源于 Libra 項目白皮書,另外目前 Libra 還在開發過程中,討論僅限于白皮書中已經披露的技術細節。

     

    根據白皮書所述,Libra 區塊鏈是一個基于 Libra 協議的加密認證的分布式數據庫。我們簡略探討下 Libra 協議的核心概念,并將其與我們已經在應用的、純自主的井通 Jingtum 區塊鏈做一下簡單對比。

     

    交易和狀態                                                 



    Libra 協議的兩個核心基本概念為交易和狀態在任一時間點,區塊鏈都有一個所謂的狀態。狀態(或成為分布式賬本狀態)表示區塊鏈上數據此時的快照。交易的執行會改變區塊鏈的狀態。

    1.1 展示了執行交易時,Libra 區塊鏈的狀態變化。例如,在狀態"S(N-1)"時,Alice 的余額為 110 Libra 幣,Bob的余額為 52 Libra 幣。交易發生后,區塊鏈生成一個新的狀態。在狀態"S(N)"的前提下,交易"T(N)"發生,則狀態由"S(N-1)"變更為"S(N)"。Alice的余額減少 10 Libra 幣,Bob的余額增加了 10 Libra 幣新的狀態"S(N)"展示了狀態更新后的賬戶余額情況。在圖 1.1 中:


      A and B 分別代表Alice和Bob在區塊鏈上的賬戶。

    ●  S(N-1) 代表區塊鏈中第(N-1)個狀態。

    ●  T(N) 代表區塊鏈中執行的第N個交易。


    從圖中的例子可以看出,T(N)代表的交易是:從A賬戶中轉 10 Libra 幣到B賬戶中。


    ●  為一個確定性函數。在特定的初始狀態執行特定的交易, F 函數總會返回相同的最終狀態。如果當前區塊鏈狀態為S(N-1),執行交易 T(N),則返回的新狀態恒為S(N)

      S(N) 代表區塊鏈的第N個狀態。S(N)為將函數F應用于S(N-1)和T(N)的結果。

     

    此處,井通 Jingtum 的過程和 Libra 是一樣的,但是在第四步中確保交易的最終狀態略有不同。Libra 協議使用 Move 語言來實現函數 F 的確定性執行,可以理解為合約層;而 Jingtum 底層是通過 TX 層負責處理最基本的 transaction ,在此之上增加一個合約層,負責處理合約。我們將合約的要素(code,state, storage,transaction)分開,transaction 的執行下傳到 Jingtum TX 層,其他部分的執行在合約層實現。這樣使得合約的執行與產生的交易分開,使得合約和交易從各自的特點來匹配相應的協議,以達到最高的效率和最大的安全。


    交易


    Libra 區塊鏈客戶端通過提交交易請求來更新分布式賬本狀態。區塊鏈上一個簽名交易包括:

     

      發送方地址  — 交易發起者的賬戶地址。

      發送方公鑰  — 用于簽署交易的私鑰所對應的公鑰。

      程序  — 程序包括以下內容:

      > 一個Move語言的字節碼交易腳本;

      可選的輸入列表:在點對點交易中,輸入包括接受者信息及金額;

      可選的Move字節碼模塊部署列表;


      Gas價格  — 以 microlibra/gas 為單位—執行交易時,發送方愿意為一單位 Gas 所支付的價格。Gas 是用來支付在區塊鏈上計算和存儲費用。每一 Gas 單位是對計算量的抽象度量;

      Gas上限  — 交易允許消耗的 Gas 最大值;

      序號  — 無符號整型,必須和發送者賬戶中的序列號相等;

      有效期  — 交易的有效截止時間;

      簽名  — 發送者的數字簽名。

     

    交易腳本是任意包含對交易邏輯編碼的程序,能夠與 Libra 區塊鏈中發布的數字資產進行交互。

     

    :其中程序就是上文中指的 F 函數。不同點已在上文指出

     

    分布式賬本狀態


    分布式賬本狀態,又稱為 Libra 區塊鏈全局狀態,是區塊鏈上所有賬戶狀態的集合。想要執行交易,每個 Validator 必須獲得區塊鏈上分布式數據庫的最新全局狀態。


    此處與井通 Jingtum 區塊鏈一致。

     

    版本化數據庫


    Libra 區塊鏈上的所有數據都存儲在一個單一版本化的分布式數據庫上。版本號為無符號的64位整數,與系統內已經執行的交易數量相對應。

     

    版本化數據庫允許 Validator:


    ●  在最新的全局狀態下進行交易;

    ●  響應客戶端發送的對當前或歷史全局狀態的請求。

     

    此處與井通Jingtum區塊鏈一致。


    賬戶


    Libra 賬戶包括 Move 模塊和 Move 資源。由賬戶地址標識。這也意味著每個賬戶的狀態都包含代碼和數據兩方面。

     

      Move模塊  包含代碼(類型和過程聲明),但不包含數據。模塊中的子程序對區塊鏈全局狀態的更新規則進行編碼。

      Move資源  包含數據不包含代碼。每個資源的類型都應在區塊鏈的分布式數據庫中已發布模塊里聲明過。


    賬戶可以包含任意數量的 Move 資源和 Move 模塊。通俗點講,Move 資源就是該賬戶運行的合約,Move 模塊就是該賬戶的狀態。而 Jingtum 區塊鏈暫時沒有 Move 資源這個概念,只有賬戶的狀態。


    賬戶地址


    Libra 賬戶地址為一個256位的值。用戶可以使用電子簽名來聲明地址。對于一個賬戶,其地址由用戶的公鑰通過密碼學 Hash(或托管的客戶端)生成,用戶必須通過相應的私鑰簽名才能從此賬戶發起交易。

     

    Libra 對用戶的賬戶地址的數量不做限制。但申請新賬戶地址時,必須通過另一 Libra 幣充足的賬戶支付申請費用。

     

    此處,關于地址的規則,各種區塊鏈都大同小異;對于每個Libra賬戶,都需要支付申請費用,井通 Jingtum 區塊鏈同樣也是需要對每個地址進行激活,才能使用。

     

    證明


     Libra 區塊鏈上的所有數據都存儲在一個單一版本化的分布式數據庫上,存儲被用來對交易區塊和交易結果的持續確認。區塊鏈是一個不斷增長的 Merkle 交易樹. 每次區塊鏈上有新的交易執行,交易樹都會增加一片“葉子”。

     

    ●  證明是驗證 Libra 區塊鏈中數據真實性的一種方式;

    ●  區塊鏈上存儲的每個操作都可以進行加密驗證,結果性證明也可以證實沒有數據缺損。例如,如果客戶端發送了對最新的 n 筆交易的查詢請求,證明可以驗證查詢響應中沒有遺漏任何一筆交易記錄。

     

    在區塊鏈中,客戶端不需要信任接受數據的實體。客戶端可以查詢賬戶余額,以及特定交易的交易狀態等。與其他 Merkle 樹類似,分布式賬本記錄可以對特定的交易提供 O(log n)時間復雜度證明, n 為處理的交易總量。

     

    Validator 節點 (validator)


    Libra 區塊鏈的客戶端創建交易并提交到 Validator 節點。Validator 節點(和其他 Validator 節點共同)運行共識協議,執行交易,并將交易和執行結果存儲在區塊鏈中。Validator 節點判定哪些交易可以被添加到區塊鏈上,以及以何種次序添加。


    Validator 節點 包括以下邏輯組件:

     

    準入控制 (AC)


    ●  準入控制是 Validator 節點的唯一外部接口。客戶端向 Validator 節點發送的任何請求都將先轉入AC;

    ●  準入控制通過對請求進行初始檢查,來保護 Validator 節點的其他部件免受損壞或大量輸入的影響。

     

    目前井通 Jingtum 區塊鏈的準入控制是人工審核,這方面有待優化。

     

    內存池

     

    ●  內存池是一個緩存區,用于保存“等待”執行的交易。

    ●  當一個內存池中添加了新交易時,這個內存池會和系統中其他 Validator 節點的內存池共享此交易。


    井通 Jingtum 區塊鏈同樣也有內存池的概念,主要用于處理交易和快速查詢。

     

    共識

     

    ●  共識組件負責判斷交易區塊的順序,并與區塊鏈中其他的 Validator 節點在共識協議下共同決定執行結果。

     

    Libra 共識和井通 Jingtum 共識同屬 X-BFT 拜占庭容錯共識,效率問題得等Libra 上線之后再驗證了。

     

    執行

     

    ●  執行組件利用虛擬機(VM)交易。

    ●  執行組件的作用是協調一個區塊中的交易的執行,并維護一個可用于協商投票的瞬時狀態;

    ●  執行組件維護內存中執行結果,直至共識組件允許其被提交到分布式數據庫。

     

    Libra 的交易執行都放在了虛擬機中執行,即合約層;而井通 Jingtum 區塊鏈進行了分層,最基本的交易下沉到了交易層,其余交易在合約層執行。

     

    虛擬機 (VM)

     

    ●  準入控制和內存池借助虛擬機組件對交易進行校驗。

    ●  虛擬機用于運行交易中所包括的程序,并確定結果。

     

    存儲


    ●  存儲被用來持久化保存已確認的交易區塊和交易結果。

     

    小結

     

    從上文的探討中我們可以發現,Libra 從基本的設計結構和流程上,應該是選擇了一條積極穩妥的技術路線,立足于現有成熟技術進行部分創新,這也符合其超大規模應用的特點。通過與國內自主井通 Jingtum 區塊鏈底層的簡單比較,我們也有似曾相識燕歸來之感。


    也許對于超大規模應用,可選擇的路線并不太多,殊途終會同歸。

    版權申明:本內容來自于互聯網,屬第三方匯集推薦平臺。本文的版權歸原作者所有,文章言論不代表鏈門戶的觀點,鏈門戶不承擔任何法律責任。如有侵權請聯系QQ:3341927519進行反饋。
    相關新聞
    發表評論

    請先 注冊/登錄 后參與評論

      回頂部
    • <option id="cacee"><noscript id="cacee"></noscript></option>
    • <table id="cacee"><noscript id="cacee"></noscript></table>
    • <td id="cacee"></td>
    • <option id="cacee"></option>
    • <table id="cacee"></table>
    • <option id="cacee"><option id="cacee"></option></option>
    • <table id="cacee"><source id="cacee"></source></table><td id="cacee"><rt id="cacee"></rt></td>
      <option id="cacee"><option id="cacee"></option></option>
      妖精视频