本文作者 Jameson Lopp 是比特幣核心開發者裏最愛和公衆進行溝通的一位佈道者,在他眼裏 Libra 是什麼樣的?

原文標題:《一位比特幣開發者對 Libra 的思考》
作者:Jameson Lopp
編譯:BixinWallet

我深入研究了 26 頁技術文檔,它描述了用作 Libra 幣(等等)平臺的協議。它有着令人印象深刻的 53 位作者!

摘要

Libra 協議允許來自不同的權威機構一組副本(replicas)——被稱爲驗證者——來共同維護可編程資源數據庫。

好吧,這裏沒有文字上的裝腔作勢 —— 該系統將由一系列權威機構以自上而下的方式進行控制。但請注意,它表示數據庫是針對「可編程資源」而不僅僅是數字貨幣。

這些資源將由公鑰加密認證過的不同用戶帳戶擁有,並遵守這些資源的開發者所指定的自定義規則 。

使用諸如「資源」之類的通用詞語使我懷疑這遠遠不止是一個穩定幣。

交易基於以一種名爲 Move 的新編程語言預定義的(在未來的版本中是用戶定義)的智能合約。我們使用 Move 來定義區塊鏈的核心機制,例如貨幣和驗證者成員資格

好的,現在它變得有趣了。使用定製智能合約的語言會導致很多問題,關於語言的功能有多豐富,以及 —— 作爲結果 —— 系統對抗敵對合約也有多健壯。對開發者的友好性以及 Libra 如何保護智能合約開發人員免於陷入困境,也會有一些問題。

這些核心機制使得創建一種獨特的治理機制成爲可能,該機制在早期會基於現有制度的穩定性和聲譽,但隨着時間的推移會過渡到一個完全開放的系統。

聽起來 Libra 協會將是一個聯邦,可以通過投票和某種聲譽來自我進化。

引言

這個生態系統將提供一種新的全球貨幣——Libra 幣——它將得到一籃子銀行存款和高質量央行債券的全額支持。

Libra 是一種通用的加密資產協議,第一個資產將是一種穩定幣。

隨着時間的推移,會員資格將轉變爲完全開放,並且,僅基於會員持有的 Libra。

聽起來非常像權益證明(Proof of Stake)。顯然,計劃是在 5 年後開放會員資格,希望他們到那時能搞明白權益證明 …… 我認爲他們會遇到與以太坊相同的問題!

該協會發布的報告概述了……轉爲一種無需許可系統的路線圖 。

我很確定這將是世界首次有分佈式網絡從需要許可轉爲無需許可。也許整個網絡可以轉換爲 PoS,但爲了維持穩定幣錨定 / 籃子,一些實體必須保持對傳統金融系統的橋樑。這將是通過 Libra 協會來中心化控制的持續點。

驗證者們輪流推動接受交易的過程。當一位驗證者扮演領導者時,它向其他驗證者提出交易,其中即包括客戶直接提交給他們的交易,也包括通過其他驗證者間接提交的交易。所有驗證者都執行交易,並形成一個包含新賬本歷史的身份驗證過的數據結構。作爲共識協議的一部分,驗證者對該數據結構的驗證者進行投票。

這聽起來像實用拜占庭容錯(Practical Byzantine Fault Tolerance),這是一個 20 年前很好理解的算法,儘管他們可能做了一些調整。我們在白皮書的第 5 節中瞭解到它被稱爲 LibraBFT,它是 HotStuff 共識協議的變體。

作爲在版本 i 處提交一筆交易 Ti 的一部分,共識協議在版本 i 處在數據庫的完整狀態上輸出一個簽名——包括它的整個歷史——來驗證對客戶端查詢的響應。

這主要是因爲它意味着新的驗證者應該能夠加入網絡並快速同步,而不必重放區塊鏈的整個歷史記錄,假設它們信任現有的驗證者。

邏輯數據模型

Libra 協議使用基於帳戶的數據模型來編碼帳本狀態。

從數據結構的角度來看,Libra 更像是以太幣或瑞波幣而不是比特幣。UTXO 模型有利有弊,例如,由於基於輸出的歷史的簡單性,它有更好的隱私和更健壯的交易歷史,但是可能更難使用複雜的智能合約。因此,帳戶模型是言之有理的,因爲 Facebook 不太可能關注隱私,而它確實對智能合約感興趣。

Libra 協議不會將帳戶與現實世界的身份相關聯。用戶可以通過生成多個密鑰對來自由創建多個帳戶。由同一用戶控制的帳戶彼此之間沒有內在聯繫。該方案遵循了比特幣和以太坊的例子,因爲它爲用戶提供了假名。

令人驚訝的好,但我想知道 Libra 幣的資產情況是否也是如此 …… 觀察這個系統對於想要構建更保護隱私的應用程序的開發者有多開放是很有趣的。

每個資源都有一個模塊聲明的類型。資源類型是名義類型,由類型的名稱以及資源聲明模塊的名稱和地址組成。

聽起來您可以生成一個地址,只要每個資產都有一個唯一的名稱,該地址就可以分配任意數量的資產。

執行一筆交易 T i 產生有一個新的賬本狀態 S i 並執行狀態代碼、gas 使用情況和事件清單。

好吧,現在我們知道如何通過類似於以太坊的資源成本系統來保護系統免受資源耗盡攻擊了。

賬本歷史中沒有交易區塊的概念。

Libra 協議中並沒有實際的區塊鏈數據結構 ——區塊更多是一種虛擬 / 邏輯構造,用於協調系統狀態的已確認快照。現在該部分的第一句話更有意義:

Libra 區塊鏈中的所有數據都存儲在一個單一版本的數據庫中。版本號是無符號型 64 位整數,對應於系統執行的交易數。

我熟悉的每個加密資產網絡都以相同的方式在非常高的層次上運作:存在一個系統狀態,然後執行一筆交易(實際上是執行一次狀態轉換函數),然後存在一個新的系統狀態。

比特幣核心開發者深度解讀 Libra 白皮書

將批量交易放入容器(區塊)的目的,是爲了排序 / 加時間戳。這對於無需許可的網絡來說非常重要,在這種網絡裏數據是通過動態多方會員簽名來進行身份驗證的——驗證者可以自由加入和離開網絡。由於 Libra 運行着一個需要許可的系統,它可以使用更有效的共識算法,而不需要批量處理交易,因爲交易的歷史更不可能被重寫。

在 Libra 協議的最初版本中,用戶只能使用 Move 功能的有限部分。雖然 Move 用於定義核心系統概念,例如 Libra 幣,但用戶無法發佈聲明自己資源類型的自定義模塊。這種方法允許 Move 語言和工具鏈在暴露給用戶之前成熟 —— 由實現核心系統組件的經驗得知。該方法還延遲了通用智能合約平臺所固有的事務執行和數據存儲中的可擴展性挑戰。

這聽起來與前面提到的“開放驗證者成員資格”計劃非常相似。聽起來,Facebook 好像還沒有解決以太坊多年來一直在努力解決的任何大問題。

爲了管理對計算容量的需求,Libra 協議會收取交易費用,以 Libra 幣計價。

有趣的是,聽起來 Libra 幣實際上是協議的原生單位,就像 ETH 是以太坊的原生單位一樣。這導致了更多關於 Libra 假名性質的問題;你可以在沒有 AML/KYC 的情況下獲得幣嗎?如果不能,那麼您似乎無法匿名使用任何系統功能。從有關 Calibra 錢包的閱讀來看,它將需要 AML/KYC,因此我想知道最終是否會進入不受嚴格控制的系統中。

該系統被設計爲:在正常運行期間,當有足夠的容量時,費用較低。

這真的很模糊,引發了很多問題——什麼是低費用?什麼是正常運行?什麼是足夠的容量?

執行交易

……區塊鏈核心邏輯的許多部分(包括 gas 費的扣除)是用 Move 來定義的。爲了避免循環,VM 在執行這些核心組件期間禁用了 gas 計量。

這聽起來很危險,但作者們指出,核心組件必須以防禦性方式編寫來預防 DoS 攻擊。

Move 的關鍵特性是能夠定義自定義資源類型 …… Move 類型系統爲資源提供了特殊的安全保證。永遠不能複製資源,只能移動資源。這些保證由 Move
VM 靜態強制執行。這允許我們將 Libra 幣表示爲 Move 語言中的資源類型。

這消除了先前的問題,即 Libra 幣是不是 ETH 或 BTC 這樣的原生資產。我希望這些幣只是系統啓動時允許的默認 / 唯一資源類型,其他資源將在以後出現。

相比一個更高級別的源語言,Move 基於棧的字節碼指令更少。此外,每條指令都具有簡單的語義,可以通過更小的原子步驟來表示。這減少了 Libra 協議的規範足跡,並且更容易發現實現錯誤。

這聽起來經過了深思熟慮;希望這意味着他們的腳本語言安全性將比以太坊更好。

經過身份驗證的數據結構和存儲

Libra 協議使用單個 Merkle 樹爲賬本歷史提供經過驗證的數據結構 … 具體而言,賬本歷史使用 Merkle 樹累加器方法來形成 Merkle 樹,這也提供了有效的附加操作。

我們再一次看到“Libra 區塊鏈”實際上並不是區塊鏈。這個協議似乎設計得非常好,但當賬本歷史的數據結構是一組簽名過的賬本狀態時,它們仍然稱它爲區塊鏈,這真的很奇怪。驗證者正在爲每個賬本狀態進行承諾,並且所有歷史賬本狀態也都在 Merkle 樹中得到承諾,但我還沒有真正看到形成一條鏈的任何反向鏈接數據列表,更不用說是一條鏈的區塊。

帳戶的身份驗證器是此序列化表示的哈希。請注意,這表示要求在對帳戶進行任何修改後重新計算整個帳戶的身份驗證器。這一操作的成本爲 O(n),其中 n 是完整帳戶的字節表示長度。

哈,如果對給定帳戶存儲的數據量沒有限制,聽起來像 DoS 向量。

我們預計,隨着系統的使用,最終與帳戶相關的存儲增長可能會成爲一個問題。正如 gas 鼓勵負責任地使用計算資源,我們期望存儲可能需要一種類似的基於租金的機制。我們正在評估各種最適合生態系統的基於租金的機制。

另一個未解決的問題。等不及看「租金太高了!」的表情包。

投票權必須在 epoch 期間以及 epoch 之後的一段時間內保持誠實,以允許客戶端同步新配置。離線時間超過這個時間段的客戶端需要使用一些外部事實源重新同步,以獲取他們信任的檢查點。

哎喲。目前尚不清楚「這個時間段」有多長,但如果一個 epoch 不到一天,我猜它也不到一天。看起來這個共識協議沒有健壯到參與者可以按照自己的意願離開並重新加入網絡。

拜占庭容錯共識

LibraBFT 假設一組 3f + 1 選票在一組可能誠實的驗證者(拜占庭人)之間分配。當拜占庭驗證者最多控制 f 票時,LibraBFT 保持安全,能防止雙花和分叉等攻擊。

與 PBFT 非常相似,這種共識算法可以容忍 33%的驗證者不誠實。 HotStuff 修改聽起來很好:

  1. 通過讓驗證者對一個區塊的狀態而不僅僅是交易序列進行簽名,來抵抗不確定性錯誤。
  2. 我們採用了一個發出明確超時的 pacemaker,驗證者依靠其中的法定人數來進入下一輪——這應該可以改善活性。
  3. 運用了一個不可預知的領導者選舉機制,以限制針對領導者的 DoS 攻擊。
  4. 使用聚合簽名來保存簽名法定人數證書的身份驗證者,以對區塊接受進行投票。

聯網

Libra 協議中的每個驗證者都維護系統的完整成員顯示,並直接連接到需要與之通信的任何驗證器。無法直接連接的驗證者將被系統列入拜占庭容錯的配額範圍。

需要大量工作才能將系統擴展到數百個驗證者。

Libra Core 實現

Libra 區塊鏈的安全性取決於驗證者、Move 程序和 Move VM 的正確實現。我們正在解決 Libra Core 中的這些問題。

幾乎總結了這一部分,儘管他們是用 Rust 來實現的,這似乎是性能和安全性的良好開端。

性能

我們預計 Libra 協議的初次發佈能支持每秒鐘 1000 次付款,一筆交易提交和指派之間的最終化時間爲 10 秒。

由於只有 100 個左右的驗證者並且它們都直接相互連接,因此 10 秒的“區塊時間”聽起來可行。

最低節點要求:

  • 40 Mbps 互聯網連接
  • 1 個普通 CPU
  • 16 TB SSD

之前有一些參考文獻要求保持驗證者從頭開始執行初始同步,而不是信任來自其他驗證器的簽名狀態的能力。我認爲如果 Libra 得到充分使用,那麼執行這樣的同步將很快變得非常不切實際,因此節點安全模型將高度依賴於信任驗證者。

用 Move 實現 Libra 的生態系統政策

[Libra 幣] 儲備是實現價值保值的關鍵機制。通過儲備,每個幣都有一系列穩定而有流動性的資產完全背書。Libra 幣合約允許協會在需求增加時製造新幣,並在需求收縮時銷燬它們。該協會並不制定貨幣政策。它只能根據授權經銷商的要求鑄造和銷燬幣。用戶無需擔心協會將通脹引入系統或使貨幣貶值:對於要製造的新幣,儲備中必須有相應的法定存款。

好的,但現在我們談論的是網絡外部的事件。如白皮書前面所述,網絡無法執行使用網絡狀態外部數據輸入的腳本。因此,上述片段中的“能”和“必須”的修飾語肯定是指網絡不知道的 Libra 協會政策或合同義務。

共識算法依賴於驗證者集管理 Move 模塊來維護當前的驗證者集並管理驗證者之間的投票分配 。最初,Libra 區塊鏈僅向創始成員授予選票。

假設驗證者就更改驗證者集進行投票,聽起來這會導致類似於我們在權益證明系統中看到的問題——遠程攻擊。如果創始成員私鑰的足夠閾值受到損害,攻擊者是否可以從創世塊開始寫一個新的賬本歷史?如果是這樣,其他節點會接受嗎?目前尚不清楚共識協議是否允許重寫舊狀態,還是它只能添加。

我們計劃逐步過渡到權益證明。

如果他們能解決尚未解決的問題。

未解決的問題

治理如何運作?

我們可以在 這裏 看到,Libra 協會是一個成員委員會,需要 2/3 絕對多數人來做出改變。他們是唯一允許製造或銷燬 Libra 幣的人,但如果有足夠的共識(agreement),他們可能會做出他們想要的改變。

是否需要 AML/KYC?

在協議層顯然不需要,但 Calibra 錢包聲明,所有用戶將通過政府頒發的 ID 進行驗證。這聽起來像 Calibra 錢包將是至少一段時間內唯一可用的錢包,所以目前還不清楚開發人員和用戶能否在 Libra 網絡上運行不遵守與 Calibra 相同標準的 App。

什麼是低費用?什麼是正常操作?什麼是足夠的容量?

Calibra 錢包 FAQ 承諾低費用,但似乎這可能與底層協議在高負荷時的操作相沖突。

交易費將是低成本和透明的,特別是如果您在進行國際匯款。Calibra 將削減費用,以幫助人們留下更多的錢。

Libra 真的會對開發者開放嗎?

根據實現無需許可的共識的計劃:

Libra 區塊鏈將向所有人開放——任何消費者、開發者或企業都可以使用 Libra 網絡,在其上構建產品,並通過其服務增加價值。開放獲取確保了進入和創新的低門檻,並鼓勵有利於消費者的健康競爭。

我懷疑開發人員能夠在這個平臺上運行他們夢寐以求的任何技術上有效的應用程序。我沒有讀到任何內容能讓我相信這個系統會是抗審查的,但只有時間會證明!

來源鏈接:medium.com