The Libra Blockchain機翻及整理

The Libra Blockchain機翻及整理，若有侵權，馬上刪除!

Libra區塊鏈

摘要：Libra區塊鏈是一個去中心化、可編程的數據庫，其旨在支持一個低波動性的加密貨幣，可以做爲服務全世界數十億人的有效交易媒介。咱們提出了一個關於Libra協議的提議，它會實現Libra區塊鏈，旨在建立一個可促進創新、下降進入壁壘，並改善訪問金融服務機會的金融基礎設施。爲了驗證Libra協議的設計，咱們已構建了一個開源原型實現 —— Libra Core ，並在全球範圍內共同推動這一新生態系統。

Libra協議容許來自不一樣實體的一組副本，稱爲驗證者，共同維護一個可編程資源的數據庫。這些資源由通過公鑰加密驗證的不一樣用戶賬戶擁有，並遵照這些資源開發者指定的自定義規則。驗證者處理事務（transaction）並相互做用，就數據庫的狀態達成共識。事務是基於預約義的，在將來的版本中，用戶自定義的智能合約會使用一種稱爲Move的新編程語言編寫。

咱們使用Move語言定義區塊鏈的核心機制，例如貨幣和驗證者會員。這些核心機制可以建立一個獨特的治理機制，其創建在現有項目早期已創建的穩定基礎之上，但Libra系統會隨着時間的推移，徹底開放。

1、引言

互聯網的普及以及由此產生的產品和服務的數字化，提升了效率，下降了進入壁壘和大多數行業的成本。這種連通性讓更多的人進入金融生態系統，而且驅動了經濟賦權。儘管如此，對於那些最須要金融服務的人來講，得到金融服務的機會仍然有限，這是由成本、可靠性以及無縫發送資金的能力限制的。

這篇論文爲Libra協議提出了一個提議，旨在支持這個新生的 Libra生態系統，並解決這些挑戰，擴大資本准入，並做爲創新金融服務的一個平臺。這個生態系統將提供一種新的全球貨幣 — Libra幣，它將由優質的中央銀行銀行存款和國債充分支撐。這些基準貨幣都經歷了相對較低的通貨膨脹，所以，Libra繼承了穩定幣這一屬性，且其還擁有在地理上呈現多樣化的組合優點。Libra協議必須擴展，以支持其貨幣成長爲一個全球金融基礎設施，提供以實施經濟和治理的靈活性，支持其操做策略。Libra協議的設計從一開始就以總體解決這些需求，它創建在現有項目以及研究的基礎之上。Libra結合了新穎的方法以及已被普遍理解的技術。

金融服務業健康競爭和創新的一個關鍵前提，是依靠處理事務、維護帳戶以及確保跨服務和組織的互操做性公共基礎設施。經過下降進入壁壘和轉換成本，Libra協議將使初創企業和現有大型企業可以在公平競爭的環境中競爭，並試驗新的商業模式和金融應用。區塊鏈技術可以很好地解決這些問題，由於它能夠用於確保沒有單個實體可以控制生態系統或可單方塑造其進化優點^[2]。

Libra區塊鏈將是去中心化的，它由一組共同工做的驗證者組成，用於處理事務並維護區塊鏈的狀態。這些驗證者也構成了Libra協會的成員，這將爲網絡的管理以及支持貨幣的儲備提供一個框架。最初，該協會（驗證者）將由一組地理分佈普遍的創始成員組成。這些成員是根據客觀參與標準選擇出來的，包括它們在引導Libra生態系統和爲其成功而投入的權益。隨着時間的推移，成員資格將轉變爲徹底開放，只基於Libra的持有量。Libra協會已發表了報告，概述了其願景^[1]、提議的結構^[3]、貨幣的經濟學^[4]以及向無許可系統轉變的路線圖^[5]。

而本文，則是構建支持Libra生態系統的技術基礎設施的第一步。咱們發佈這份早期報告，是爲了徵求社區對Libra的初步設計、系統的發展計劃以及當前未解決的研究挑戰的反饋意見。所以，協會創建了一個開放源碼社區[6]以供你們討論以及支持項目的開發。

Libra協議。Libra區塊鏈是使用Libra協議進行維護的密碼學證實數據庫 ^{[7, 8, 9]}。該數據庫存儲了一個可編程資源（例如Libra幣）的帳本。資源（resource）遵循其聲明模塊指定的自定義規則，該模塊還存儲在數據庫中。資源由使用密碼學公鑰進行驗證的賬戶擁有。賬戶可表明系統的直接最終用戶以及實體（例如託管錢包），表明他們的用戶。賬戶的全部者可簽署對賬戶內的資源進行操做的事務（transaction）。

圖1顯示了使用Libra協議進行交互的兩種類型的實體：（1）驗證者（validactors），其負責維護數據庫，（2）客戶端（clients），它們對數據庫執行查詢，並提交事務以修改它。

驗證者維護這個數據庫，並處理由包含在數據庫1的客戶端提交的事務（transaction）。驗證者使用一個分佈式共識協議來商定不斷增加的，已提交到數據庫的事務列表，以及執行這些事務的結果。即便少數驗證者存在惡意或錯誤，此共識協議也必須是可靠的。驗證者輪流驅動接受事務的過程。當驗證者充當領導者時，它會向其餘驗證者 2提出客戶端直接提交給它的事務，以及經過其餘驗證者間接提交的事務。全部驗證者執行事務3並造成一個經驗證的數據結構，其中包含新帳本歷史記錄。做爲共識協議4的一部分，驗證者對該數據結構的確認者進行投票。做爲在版本i提交一個事務ti的一部分，共識協議在版本i輸出數據庫完整狀態的簽名（包括整個歷史），以確認對來自客戶端5查詢的響應。

客戶端能夠向驗證者發出查詢，以從數據庫中讀取數據。因爲數據庫是經驗證的，所以可保證客戶端對其查詢的響應的準確性。做爲對讀取查詢的響應的一部分，驗證者返回驗證者已知數據庫最新版本i的簽名驗證器。

此外，客戶端還能夠選擇經過與驗證者同步事務歷史，來建立整個數據庫的副本。在建立副本時，客戶端可檢查驗證者是否正確執行了事務，從而改善了系統的問責制和透明度。其餘客戶端能夠從保存副本的客戶端讀取副本，這和從驗證者處讀取副本以驗證響應真實性的方式相同。爲了簡單起見，本文的其他部分假設客戶端直接查詢一個驗證者，而不是副本。

組成（Organization）。

本文討論了Libra協議的組成部分：

邏輯數據模型 ：（第2節）描述了邏輯數據模型，該模型組織了對驗證者和客戶端可見的去中心化數據庫。

執行事務：（第3節）描述了Move ^[10]編程語言的使用，這是一種用於定義和執行數據庫事務的新編程語言。

經驗證的數據結構和存儲：（第4節）描述了基於Merkle樹的邏輯模型到經驗證數據結構的映射^[11]。

拜占庭容錯共識：（第5節）描述了HotStuff協議^[13]的變體LibraBFT ^[12]，容許具備潛在惡意驗證者的網絡，經過執行Move語言事務，並在使用經驗證的數據結構執行事務時達成一致，來維護一個單一的、一致的數據庫。

網絡：（第6節）描述了使驗證者能根據協商一致的須要，安全地相互通訊的協議。

而在以後，咱們展現了開源的Libra Core原型^[6]。第7節內容則討論了Libra Core如何結合Libra協議的組件來處理事務。第8節內容則探討了性能考慮。

最後，咱們將解釋如何使用該協議來支持Libra生態系統政策的經濟穩定和治理。第9節內容展現了咱們如何使用Move語言來實現低波動性、儲備支撐的Libra貨幣，以及反映 Libra協會治理的驗證者管理系統。第10節內容，討論了有關Libra生態系統的將來計劃，及其當前正面臨的挑戰，這也將是這篇文章的結尾。

2、邏輯數據模型

Libra區塊鏈中的全部數據都存儲在單一版本的數據庫當中^{[14, 15]}。版本號是與系統已執行的事務數相對應的無符號64位整數。在每一個版本i中，數據庫都包含一個元組 (Ti, Oi, Si) ，它們分別表示事務 (Ti)，事務輸出（Oi）以及帳本狀態 (Si)。給定一個肯定性執行函數Apply，這個元組的含義是：對帳本狀態Si−1執行事務Ti會產生輸出Oi以及新帳本狀態Si，即Apply(Si−1, Ti) → <Oi, Si>。

Libra協議使用Move語言來實現肯定性執行函數（請參見第3節內容）。在本節內容中，咱們將重點介紹版本化數據庫，它容許驗證者：

1.根據最新版本的帳本狀態執行事務；

2.響應客戶端有關當前和之前版本的帳本歷史記錄的查詢；

 

咱們首先解釋存儲在單個版本中的帳本狀態的結構，而後討論版本化帳本歷史視圖（History view）的目的。

2.1 帳本狀態

帳本狀態表明瞭有關Libra生態系統的基本事實，包括每一個用戶在給定版本中持有的Libra幣的數量。每一個驗證者必須知道最新版本的帳本狀態，以便執行新的事務。

Libra協議使用基於賬戶的數據模型^[16]對帳本狀態進行編碼。狀態被構造爲一個鍵值存儲，它將賬戶地址鍵映射到賬戶值。帳本狀態下的帳戶值是已發佈Move資源和模塊的集合。這個 Move資源存儲數據值，而模塊則存儲代碼。初始賬戶集及其狀態在創始帳本狀態中指定（見第3.1節）。

賬戶地址：賬戶地址是一個256位的值。要建立新賬戶，用戶首先爲簽名方案生成一個新的驗證/簽名密鑰對 (vk, sk)，並使用公共驗證密鑰vk的加密哈希做爲賬戶地址a = H(vk)。當從現有帳戶發送的事務調用這個create_account(a) Move指令時，則這個新帳戶就會在帳本狀態中建立。這一般發生在一筆事務嘗試將Libra發送到還沒有建立的地址a的賬戶時。

在地址a中建立新賬戶後，用戶可以使用私人簽名密鑰sk，簽署要從該賬戶發送的事務。該用戶還能夠在不更改其地址的狀況下，更改用於簽署交易的密鑰（例如，主動更改密鑰或響應密鑰可能被盜的狀況）。

Libra協議不會將賬戶連接到用戶的真實身份（即沒有KYC）。用戶可經過生成多個密鑰對來自由建立多個賬戶。由同一用戶控制的賬戶沒有固有的相互聯繫。該方案參照了比特幣和以太坊，爲用戶提供了假名性 （又稱半匿名）^[19]。

資源值：所謂資源值或資源，是將命名字段綁定到簡單值（例如整數或複雜值）的記錄。

 

圖2：具備四個賬戶的帳本狀態示例。在這個圖中，橢圓表示資源，矩形表示模塊。從資源到模塊的定向邊，意味着該模塊聲明瞭資源的類型。地址爲0x12的賬戶，包含由貨幣模塊聲明Currency.T資源。該貨幣模塊的代碼存儲在地址0x56。地址0x34處的賬戶，同時包含了一個Currency.T資源以及StateChannel.T資源，這是由存儲在地址0x78的模塊聲明的。

每一個資源都有一個由模塊聲明的類型。資源類型是名義類型^[20] ，其由類型的名稱和資源的聲明模塊的名稱和地址組成。例如，圖2中的 Currency.T資源的類型是0x56。Currency.T這裏，0x56是存儲貨幣模塊的地址，Currency是模塊的名稱，而Currency.T則是資源的名稱。

要在賬戶地址0x12取回資源0x56.Currency.T，客戶端將請求0x12/resources/0x56.Currency.T.這種設計的目的，是讓模塊爲頂級賬戶值定義一個可預測的模式——也就是說，每一個賬戶都將其0x56.Currency.T資源存儲在同一路徑下。所以，每一個賬戶最多可存儲一個給定類型的資源。可是，這一限制是沒有約束的，由於程序員可定義包裝器（wrapper）資源，以自定義的方式組織資源。（例如，resource TwoCoin { c1: 0x56.Currency.T, c2: 0x56.Currency.T }）。

用於改變、刪除和發佈資源的規則，編碼在建立資源並聲明其類型的模塊當中。Move的安全和驗證規則，會阻止其餘代碼對資源進行修改。

 

 

模塊值：所謂模塊值或模塊，包含聲明資源類型和程序的Move字節碼（更多細節見第3.4節）。與資源類型同樣，模塊由聲明模塊的賬戶地址識別。例如，圖2中Currency模塊的標識符是0x56.Currency。

模塊必須在一個賬戶中惟一命名，每一個賬戶最多隻能聲明一個具備給定名稱的模塊。例如，圖2中地址0x56處的賬戶沒法聲明另外一個名爲Currency的模塊。另外一方面，地址爲0x34的賬戶能夠聲明Currency的模塊。此模塊的標識符將爲0x34.Currency。注意，0x56.Currency.T和0x34.Currency.T 是不一樣的類型，它們彼此不能互換使用。

在當前版本的Libra協議中，模塊是不可變的。一旦在賬戶地址下聲明模塊，就不能修改或刪除它，除非經過硬分叉的方式。咱們正研究在將來的版本中啓用安全模塊更新的方案選項。

2、2事務（Transactions）

Libra區塊鏈的客戶端是經過提交事務來更新帳本狀態的。從高維度來說，事務由事務腳本（以Move字節碼編寫）和事務腳本的參數（例如，接收方賬戶地址或要發送的Libra幣數量）組成。驗證者經過運行腳本及其參數和當前帳本狀態做爲輸入來執行事務，以生成徹底肯定的事務輸出。在共識（第5節）期間，經過贊成對事務輸出的約束性承諾（第4節），在事務被承諾以前，帳本狀態不會改變。咱們將在第3節中更詳細地討論事務的結構和執行。

事務輸出：執行一個事務Ti將生成新的帳本狀態Si以及執行狀態代碼、gas使用量以及事件列表（彙總在輸出Oi中）。執行狀態代碼記錄了執行一個事務的結果（例如，成功、因錯誤e退出、gas耗盡等）。gas使用，記錄了執行事務時使用的gas單位數量（有關如何使用gas，來管理與事務處理相關費用的詳細信息，請參見第3.1節）。

事件（Events）：事件列表，是由執行事務時產生的一組反作用。Move代碼可經過一個事件結構觸發事件。每一個事件都與一個惟一的key相關聯，它標識事件發出的結構，以及提供活動詳細信息的有效載荷。一旦按照共識協議提交了事務，事務生成的事件將添加到商定的帳本歷史記錄中，並提供成功執行事務致使特定效果的證據。例如，一筆付款交易會發出一個事件，容許接收方確認已收到付款並確認付款金額。

粗略一看，事件彷佛是多餘的。相比經過一筆事務Ti查詢事件，客戶端可詢問事務Ti是否包含在區塊鏈中。可是，這很容易出錯，由於包含Ti並不意味着成功執行（例如，gas用完後可能會中斷）。在事務可能失敗的系統中，事件不只提供了特定事務已執行的證據，並且還提供了它已以預期效果成功完成的證據。

事務只能生成事件-它們不能讀取事件。這種設計容許事務執行僅爲當前狀態的函數，而不是歷史信息（例如之前生成的事件）。

2、3 帳本歷史

帳本歷史記錄存儲已提交和已執行事務的序列，以及它們發出的關聯事件。帳本歷史的目的，是爲了記錄最近的帳本狀態是如何被計算的。帳本歷史中不存在一組事務的概念。共識協議將事務批處理至區塊，做爲優化並驅動這一共識協議（有關共識的詳細信息，請參閱第5節內容）。然而，在邏輯數據模型中，事務按順序發生，而不會區分哪一個區塊包含每一個事務。

儘管驗證者不須要知道帳本歷史就能夠執行新的事務，可是客戶端能夠對帳本歷史記錄執行經驗證的查詢，並使用帳本歷史來審覈事務執行。

響應客戶端查詢：驗證者可以使用帳本歷史來回答客戶端關於之前帳本狀態、事務和輸出的查詢。例如，客戶端可能會詢問有關特定版本的帳本狀態（例如，在第30個版本的地址x的賬戶餘額是多少？），或者特定類型事件的歷史（例如，Y地址的帳戶在最後20分鐘收到了哪些付款？）。 

審覈事務執行：客戶端可經過從新執行歷史記錄中的每一個事務Ti，並將計算的帳本狀態與版本數據庫中相應的帳本狀態Si和事務輸出Oi進行比較，來檢查帳本狀態是否正確。此機制容許客戶端審計驗證者，以確保正確執行事務。

3、執行事務

在Libra區塊鏈中，更改區塊鏈狀態的惟一方法是執行一個事務。本節內容概述了事務執行的要求，定義了事務的結構，解釋Move虛擬機（VM）如何執行一個事務，以及描述Move語言的關鍵概念。

在最第一版本的Libra協議中，只有有限的Move功能子集可提供給客戶端。雖然Move是用於定義核心系統概念，如 Libra貨幣，但用戶沒法發佈聲明本身資源類型的自定義模塊。這種方法容許Move語言和工具鏈在暴露給用戶以前可以變成熟。這種方法還推遲了事務執行和數據存儲中的可擴展性挑戰，而它們正是通用智能合約平臺所固有的問題。正如咱們在第10節中所討論的，咱們致力於經過Move語言來展現全面的可編程性。

3、1 執行要求

已知初始狀態：全部驗證者必須贊成系統的初始或創始帳本狀態。由於Libra區塊鏈的核心組件（好比帳戶邏輯、事務驗證，驗證者選擇以及Libra幣）是由Move模塊定義的，創始狀態必須定義這些模塊。創始狀態還必須具備這些核心組件的足夠實例化，以便事務可被處理（例如，至少有一個賬戶必須能支付第一個事務；必須定義驗證器集，以便集的法定數量的團體可對致力於第一個事務的確認者進行簽名）。

爲了簡化系統的設計，系統的初始狀態表示爲空狀態。而後經過定義特定模塊的特殊事務T0建立創始狀態，該事務定義要建立的特定模塊和資源，而不是經過正常事務過程。客戶端和驗證者被配置爲只接受以特定T0開頭的帳本歷史記錄，該T0是由其加密哈希標識的。這些特殊事務不能經過共識協議添加到帳本歷史中，只能經過配置。

肯定性：事務執行必須具備肯定性和密封性。這意味着事務執行的輸出是徹底可預測的，而且僅基於事務和當前帳本狀態中包含的信息。事務執行並不具備外部效應（例如與網絡交互）。肯定性和封閉性執行可確保多個驗證者能夠就同一事務序列產生的狀態達成一致，即便事務是由每一個驗證者獨立執行的。這也意味着區塊鏈的事務歷史可從創始區塊從新執行，以生成當前的帳本狀態（見第2.3節）。

計量：爲了管理對計算能力的需求，Libra協議收取以 Libra幣計價的交易費用。這參照了以太坊普及的gas模型 ^[16]。咱們採用的方法，是選擇具備足夠容量的驗證者來知足Libra生態系統的需求（見第8節內容）。這項費用的惟一目的，是在系統負載高於系統所提供承載能力時（例如，在遭到拒絕服務攻擊）減小需求，系統的設計是，當其處於正常運行期間，當有足夠的容量可用時，費用會是較低的。這種方法不一樣於一些現有的區塊鏈，這些區塊鏈有時處理事務的需求會大於吞吐量。在這些系統中，費用會在出現高需求時激增，這是驗證者的收入來源，但給用戶形成了成本方面的問題。

費用的大小由兩個因素決定：gas價格和gas消耗。每一個事務都規定了提交者願意支付的每單位gas的價格（以Libra爲單位）。事務的執行動態地說明了它以gas消耗的計算能力。當系統發生堵塞時，驗證者會優先執行gas價格更高的事務，並可能放棄價格較低的事務。這就減小了在系統高負荷狀態下，事務的發起需求。

此外，一筆事務還包含了一個最大gas量，它指定了提交者願意以規訂價格支付的最大gas單位數量。在執行期間，虛擬機會跟蹤使用的gas單位數量。若是在執行完成前達到最大gas限制，虛擬機將當即中止。這種事務所致使的部分更改都不會提交給狀態。可是，事務仍會出如今事務歷史記錄中，而發送者的帳戶仍然是要爲使用的gas付費的。

正如咱們在本節中討論的，Libra區塊鏈核心邏輯的不少部分，是使用Move定義的，這包括gas費用的扣除。爲了不循環，虛擬機在執行這些核心組件期間禁用gas計量。這些核心組件必須在創始狀態下定義。必須以防護性的方式編寫，以防止惡意事務觸發執行計算代價很高的代碼。執行此邏輯的成本，可包括在爲事務收取的基本費用中。

資產語義：正如咱們在第2.1節中所解釋的，帳本狀態直接對具備實際價值的數字資產進行編碼。事務執行必須確保，在未經受權的狀況下，不得複製、丟失或轉讓Libra幣等資產。Libra協議使用Move虛擬機（第3.4節）安全地執行事務以及具備這些屬性的自定義資產。

3、2 事務結構

所謂一筆事務，是指包含如下數據的簽名消息：

發送方地址：即事務發送者的帳戶地址。虛擬機會讀取序列編號、身份驗證密鑰以及存儲在地址的LibraAccount.T 資源的餘額；

發送方公鑰：與用於簽署事務的私鑰相對應的公鑰。此公鑰的哈希必須與發送方的LibraAccount.T資源存儲的身份驗證密鑰匹配。

程序：要執行的Move字節碼事務腳本、腳本輸入的可選列表以及要發佈的Move字節碼模塊的可選列表。

Gas價格：發送方願意支付每單位gas的數量，以便執行此事務。

最大Gas量：事務停止前容許消耗的最大Gas單位數量。

序列號：一個無符號整數，必須等於發送方LibraAccount.T資源中的序列號。執行此事務後，序列號會增長1。因爲對於給定的序列號只能提交一個事務，所以沒法重放事務。

3、3 執行事務

執行事務，是經過在虛擬機內執行六個步驟來實現的。執行獨立於帳本狀態的更新。首先，執行一個事務，是試圖就其順序達成共識嘗試的一部分。因爲執行是封閉的，所以它不會形成外部反作用。隨後，若是達成共識，則將其輸出寫入帳本歷史。執行一個事務，會執行如下這6個步驟：

1、覈對簽名：事務上的簽名必須與發送方的公鑰和事務數據匹配。此步驟只是事務自己的一個做用，它不須要讀取來自發送方賬戶的任何數據。

2、運行prologue：prologue對事務發送方進行身份驗證，確保發送方有足夠的Libra幣支付交易中規定的最大數量的gas單位，並確保該事務不是前一個事務的重播。全部這些檢查，都是經過LibraAccount模塊的prologue過程在Move語言中實現的。在prologue執行期間，Gas計量是被禁用的。具體來講，這個prologue會作以下這些工做：

（1）檢查發送方公鑰的哈希是否等於發送方賬戶下存儲的身份驗證密鑰：若是沒有這個檢查，虛擬機將錯誤地接受具備密碼學有效簽名的事務，即便沒有與賬戶相關聯密鑰的通訊。

（2）檢查gas_price * max_gas_amount <= sender_account_balance ：若是不進行此檢查，虛擬機將執行可能在epilogue中失敗的事務，由於它們將沒法支付gas費用。

（3）確保事務序列號等於存儲在用戶賬戶下的序列號：若是沒有這項檢查，惡意方可重放舊的事務（例如，Bob能夠重放Alice支付給他的10個Libra幣的這筆交易）。

3、驗證事務腳本和模塊：一旦事務prologue成功完成任務，虛擬機將使用Move字節碼驗證器對事務腳本和模塊執行良構的檢查。在實際運行或發佈任何Move代碼以前，這個字節碼驗證器檢查諸如類型安全（type-safety）、引用安全（reference-safety，即沒有懸空引用）和資源安全（resource-safety，即資源不會被複制、重複使用或意外銷燬）等關鍵屬性。

4、發佈模塊：事務的程序字段中的每一個模塊，都在事務發送方的賬戶下發布。重複的模塊名稱是被禁止的，例如，若是事務嘗試將名爲M的模塊發佈到已包含模塊名爲M的帳戶中，則該步驟將會失敗；

5、運行事務腳本：虛擬機將事務參數綁定到形式參數並執行事務腳本。若是此腳本執行成功完成，則腳本執行的寫入操做和腳本發出的事件將提交給全局狀態。若是腳本執行失敗（例如，因爲gas耗盡或runtime執行失敗），則腳本中的任何更改都不會提交到全局狀態。

6、運行epilogue：最後，虛擬機運行事務epilogue，向用戶收取所用gas的費用，並增長髮送方賬號序列號。就像prologue同樣，這個事務epilogue 是Move LibraAccount模塊的一個過程，且其是在禁用gas計量的狀況下運行的。若是執行躍了步驟（2），包括步驟（3）、（4）或（5）失敗，這一epilogue步驟也會始終運行。這個prologue步驟和epilogue步驟會一塊兒工做，以確保在帳本歷史中的全部事務都是經過付費gas完成的。而不超過步驟（2） 的事務，不會被附加到帳本歷史。若是一筆事務超過了步驟（2），這個prologue步驟會確保帳戶擁有足夠的Libra幣以支付事務容許的最大gas單位數量。 即便事務用光了gas，epilogue步驟也能夠按這個最大金額收取費用。

3、4 Move編程語言

正如咱們所看到的，一筆事務是圍繞一個Move字節碼程序，經證明的包裝器（wrapper）。Move ^[10]是咱們在設計Libra協議期間建立的一種新的編程語言，它在系統中扮演了三個重要的角色：

1. 經過事務腳本啓用靈活的事務；

2. 容許用戶定義的代碼和數據類型，包括經過模塊的「智能合約」；

3.支持Libra協議的配置和可擴展性（見第9節）；

Move語言的關鍵特色是可以定義自定義資源類型，這些類型是受線性邏輯[21]啓發的。用於編碼可編程資產的資源類型，其表現相似於普通程序值：資源能夠存儲在數據結構中，做爲參數傳遞給過程，等等。然而，這個Move類型系統爲資源提供了特殊的安全保障。資源沒法被複制，只能移動。此外，資源類型只能由聲明該類型的模塊建立或銷燬。這些保證，都是經過Move虛擬機靜態地強制執行的。這使咱們可以在Move語言中將Libra幣表示爲一種資源類型（這與以太幣和比特幣是不一樣的，它們在各自的語言中具備特殊的地位）。

咱們已發佈了一份關於Move ^[10]設計的更爲詳細的文章。在本節的其他部份內容中，咱們簡要地概述了用於事務執行的關鍵Move概念：開發Move事務腳本和模塊，並使用虛擬機執行Move字節碼。

編寫Move程序。Move程序有三種不一樣的表示形式：源代碼、優化中間代碼 (IR)以及字節碼。咱們目前正在設計Move源語言，這將是一種符合人體工程學的語言，旨在使編寫和驗證安全代碼變得容易。同時，程序員能夠在Move IR中開發模塊和事務腳本。Move IR足以用於編寫人類可讀的代碼，它也可直接轉換爲Move字節碼。將來的Move源語言和Move IR均可以編譯成Move字節碼，然後者是Libra協議所使用的格式。

咱們使用可驗證的字節碼做爲Move的可執行表示，緣由有兩個：

（1）上述安全保證必須適用於全部Move程序。執行這些編譯器中的保證是不夠的。惡意方老是可選擇經過直接使用字節碼編寫惡意代碼來繞過編譯器（做爲事務執行的一部分，運行編譯器會使執行速度變慢和更復雜，而且須要驗證者信任完整編譯器代碼庫的正確性），所以，該協議經過字節碼驗證（類型安全、引用安全和資源安全）來強制Move的全部安全保證，從而避免了對編譯器的信任。

（2）與高級源語言相比， Move基於棧的字節碼指令更少。此外，每一個指令都有簡單的語義，能夠經過更小的原子步驟來表示。這減小了Libra協議的規範足跡，並使得開發者更容易發現實現錯誤。

事務腳本：事務腳本是Libra協議的主要程序。事務腳本負責啓用靈活的事務，由於腳本是一個任意的Move字節碼程序。腳本可以使用條件邏輯，以及執行本地計算，調用在帳本狀態下發布的模塊的多個程序，這意味着腳本可執行富有表現力的一次性操做，例如爲特定的一組接收者支付。

咱們指望大多數事務腳本將執行一個包含通用函數的程序調用。例如，LibraAccount.pay_from_sender(recipient_address, amount) 程序封裝了執行一筆對等式支付的邏輯。以recipient_address（接收方地址）和amount（金額）爲參數並調用此過程的事務腳本與以太坊中的以太幣傳輸事務相同^[16]。

模塊：模塊是發佈在帳本狀態中的代碼單元。模塊負責聲明結構類型和程序。結構值包含可保存基元值的數據字段，例如整數或其餘結構值。

每一個結構必須標記爲資源或不受限制（即非資源）。不受限制結構不受上述複製和銷燬限制。可是，不受限制結構不能包含資源結構（直接或傳遞），而且不能在帳本狀態下的帳戶發佈。

從高維度來講，模塊/結構/程序的關係，相似於面向對象編程中的類/對象/方法的關係。可是，這裏有一些重要的區別。一個模塊能夠聲明多個結構類型（或零個結構類型）。在其聲明模塊以外不能訪問任何數據字段（即，沒有公共字段）。模塊的過程是靜態過程，而不是實例方法；過程當中沒有this或self的概念。Move模塊相似於沒有高階函數的有限版本的ML樣式模塊 [22]。

Move模塊與以太坊和其它區塊鏈平臺的「智能合約」概念相關，但也有不一樣。一個以太坊智能合約包含了帳本狀態下發布的代碼以及數據。而在Libra，模塊包含代碼值，資源包含數據值。在面向對象術語中，以太坊智能合約就像是在單個賬戶地址下發布的單例對象。模塊是建立資源的方法，它能夠建立任意數量的資源，這些資源能夠在不一樣的賬戶地址下發布。

Move虛擬機：Move虛擬機爲Move字節碼實現驗證程序和解釋程序任務。字節碼以基於棧的虛擬機爲目標，使用過程本地操做數棧和寄存器。非結構化控制流經過goto和標籤（label）進行編碼。

開發人員在Move IR中編寫事務腳本或模塊，而後將其編譯成Move字節碼。編譯將結構化控制流構造（例如，條件、循環）轉換爲非結構化控制流，並將複雜表達式轉換爲少許的字節碼指令，以控制一個操做數棧。這個Move虛擬機經過驗證而後運行這個字節碼來執行一筆事務。

這個Move虛擬機支持少許類型和值：布爾運算（booleans）、無符號64位整數，256位地址、固定大小字節數組、結構（包括資源）和引用。結構字段不能是引用類型，這將阻止在帳本狀態中存儲引用。

這個Move虛擬機並無堆（heap）：本地數據在棧（stack）上分配，並在分配程序返回時釋放。全部持久性數據必須存儲在帳本狀態中。

4、經驗證的數據結構和存儲

在執行事務以後，驗證者將對邏輯數據模型的更改，轉換爲用於表示數據庫的已驗證數據結構^[7、8、9]的新版本。此數據結構的簡短驗證器是對帳本歷史的約束性承諾，其中包括新執行的事務。

與事務執行同樣，此數據結構的生成也是肯定性的。共識協議使用這個驗證器來贊成事務的順序及其結果的執行（咱們將在第5節內容詳細討論共識）。做爲提交事務區塊的一部分，驗證者將短驗證器集體簽名至結果數據庫的新版本。

使用這種集體簽名，客戶端可信任數據庫版本表明數據庫帳本歷史的完整、有效和不可逆狀態。

客戶端可查詢任意驗證者（或數據庫的第三方副本）來讀取特定的數據庫值，並使用驗證器以及簡短的證實來驗證結果。所以，客戶端不須要信任執行查詢的一方，以確保結果讀取的正確性。

Libra協議中的數據結構基於Merkle樹，並受到其餘區塊鏈的啓發；可是，在某些狀況下，咱們作出了一些稍微不一樣的決定，下面咱們會進行強調。首先，咱們簡要討論建立驗證器的Merkle樹方法。而後咱們描述經驗證的數據結構，從數據結構的根開始，而後咱們討論其中的子結構。圖3描述了數據結構，並提供了本節內容的可視化指南。

 

圖片3: 1帳本歷史結構的根哈希是系統完整狀態的驗證器，即2由法定人數驗證者簽署。當事務添加到數據庫時，提交到帳本歷史的驗證器（第4.2節）將增加（用虛線箭頭表示）。帳本歷史的每一個子葉都提交至一個3TransactionInfo結構。此結構承諾4簽署的事務（Ti），5該事務（Ei,第4.5節）期間產生的事件列表，以及6該事務 (Si, 第4.3節)執行後的狀態。該狀態是一顆稀疏Merkle二叉樹，其中每一個子葉上都有一個7賬戶斑點。

4、1 認證數據結構的背景

認證數據結構容許驗證者V控制一個簡短的驗證器a，它對更大的數據結構D造成了約束承諾。一個不受信任的證實者P，其控制了數據結構D，計算f(D) → r並向驗證者返回r （數據結構D上某些函數f的計算結果）以及π（正確計算結果的證實）。驗證者V能夠運行Verify(a, f, r, π)，當且僅當 f(D) = r時返回真（true）值。在Libra區塊鏈的背景中，證實者一般是驗證者，而驗證者是執行讀取查詢的客戶端。可是，客戶端（即便只有部分數據庫副本的客戶端）也能夠充當驗證者，併爲其餘客戶端執行經驗證的讀取查詢。

 

圖片4:一顆存儲D = {0 : s0, . . .}的 Merkle樹。若是f是獲取第三項（用虛線顯示）的函數，則 r = s2 ，π = [h3, h4] （這些節點用虛線顯示）。Verify(a, f, r, π) 會驗證 a?= H(h4∥H(H(2∥r)∥h3)).

Merkle樹^[11]是一種常見的認證數據結構形式，其用於存儲整數和字符串之間的映射。在一顆大小爲2^k的Merkle樹中，結構D將每個整數鍵i ∈ [0, 2^k)映射到一個字符串值si。驗證器由字符串建立的完整二叉樹的根組成，將子葉標記爲 H(i||si),將內部節點標記爲H(left||right)，其中H是一個加密哈希函數（咱們稱之爲哈希）。證實者但願驗證的函數f，是一個包含鍵值對 (k, v)在映射D中的證實。

P經過返回由節點i的每一個祖先的兄弟姐妹的標籤組成的證實π，來驗證對D中項目i的查找。圖4顯示了對大小爲4的Merkle樹中項目3的查找。項目3的節點用虛線表示，π中包含的節點用虛線表示。

4、2 帳本歷史

從比特幣 ^[24]開始的大多數區塊鏈，用一個包含單個祖先哈希的區塊，維護一個共識一致的每一個交易區塊的連接列表。這一結構就致使了客戶端效率低下。例如，信任某區塊B並但願驗證祖先塊B’中的信息的客戶端，須要獲取和處理全部的中間祖先區塊。

Libra協議使用單個Merkle樹，爲帳本歷史提供一個經驗證的數據結構。圖3解釋了支持Libra數據庫的完整數據結構，包括包含事務的帳本歷史，這些記錄依次包含有關數據庫狀態、事件和賬戶的信息。帳本歷史表示爲一顆Merkle樹，它將順序數據庫版本號i映射到一個TransactionInfoi結構。每一個TransactionInfoi結構都包含一個已簽名的事務 (Ti), 執行Ti（Si，在第4.3節中討論）後的狀態驗證器，以及 Ti（Ei,在第4.5節中討論）生成的事件驗證器。與其餘Merkle樹同樣，這個帳本歷史支持O(log n)大小的證實（其中n是已處理的事務總數），以驗證一個特定TransactionInfoi的查詢。

當客戶端但願查詢版本I的狀態，或查找在版本I中生成的事件時，它將使用包含的狀態或事件列表驗證器對TransactionInfoi 執行已驗證的查找。

具體來講，帳本歷史使用Merkle樹累加器^[25，26]方法來造成Merkle樹，其還提供有效的附加操做。此操做頗有用，由於能夠經過將新事務附加到舊帳本歷史來進行遞增計算。Merkle樹累加器還能夠生成一個有效的證實，證實在給定驗證器a提交到事務I以前的帳本信息時，驗證器a′提交到帳本信息最多 j > i具備與事務i相同的歷史。換句話說，這證實了a是a′的前綴。這些證實可有效地驗證一個帳本歷史承諾是另外一個承諾的延續。

修剪存儲：帳本歷史Merkle累加器的根哈希，是系統完整狀態的驗證器。它在系統的每一個現有版本、發送的每一個事務以及生成的每一個事件上提交狀態。雖然第4.3節中描述的狀態存儲容許有效地存儲帳本狀態的多個版本，但驗證者可能但願減小之前版本佔用的空間。驗證者可自由地刪除舊狀態，由於它們不是處理新事務所必需的。Merkle樹累加器支持修剪歷史數據，其只須要O(log n)大小的存儲來附加新記錄^[25]。

系統的任何副本均可以自由保留整個狀態，並能夠將其數據的真實性跟蹤到由共識協議簽名的根哈希。副本比驗證者更易於擴展。副本不須要獲得保護，由於它們不參與共識，可建立多個副原本並行處理讀取查詢操做。

4、3 帳本狀態

一個帳本狀態Si表示版本i中全部帳戶的狀態，做爲鍵值對的映射。密鑰基於256位賬戶地址，它們的對應值是帳戶確認者（在第4.4節中討論）（7）。使用相似於圖4的表示法，將映射表示爲大小爲2^256 的一棵Merkle樹，

 

圖5 ： 一棵稀疏Merkle樹存儲D = {01002 : A, 10002 : B, 10112 : C}的三個版本

雖然一棵大小爲2^256的樹是一種難以處理的表示，但能夠應用優化來造成一棵稀疏Merkle樹。圖5顯示了兩種用於將簡單實現1轉換爲有效實現的優化方法。首先，徹底由空節點組成的子葉將替換爲證書透明度系統（certificate transparency system） ^[27]中使用的佔位符值2 。這種優化建立了一個可跟蹤大小的表示，而沒有實質性地改變Merkle樹的證實生成。然而，子葉老是存儲在二叉樹的底層，這意味着結構須要在每次子葉修改時計算256個哈希。第二種優化，用單個節點3替換由一個子葉組成的子樹。預期中，任何給定項的深度都是O(log n)，其中n是二叉樹中項目數。這種優化減小了在映射上執行操做時要計算的哈希數。

有效實現，如Libra Core，能夠優化它們的磁盤佈局和節點的批處理層，以免在查找過程當中的請求^（8）。

當稀疏Merkle樹在執行事務後更新時，新的樹將重用上一版本的未更改部分，造成一個持久的數據結構^[28，29]。若是一個事務修改了系統中n個賬戶中的m個賬戶，則在與之前版本不一樣的新帳本狀態樹中平均建立了O(m · log n) 個新分支和子葉。這種方法容許驗證者有效地存儲帳本狀態的多個版本。此功能還容許在處理事務後高效地重計算帳本狀態驗證器。

咱們考慮過基於AVL樹結構，它比稀疏Merkle二叉樹結構提供了更優的最壞狀況證實長度^[30]。然而，稀疏Merkle樹方法容許實現者進行優化，例如跨服務器共享存儲以及並行根哈希計算。

 

4、4 帳戶

從邏輯層來說，賬戶是存儲在賬戶地址下的資源與模塊的集合。從物理層來說，賬戶被視爲字節數組值訪問路徑的有序映射。訪問路徑是一個分隔字符串，相似於文件系統中的路徑。

在協議的第一次迭代中，咱們將一個賬戶序列化（serialize）爲按訪問路徑排序的訪問路徑和值列表。賬戶的驗證器是此序列化表示的哈希。注意，此表示要求在對賬戶進行任何修改以後，對整個賬戶從新計算驗證器。這個操做的開銷是O（n），其中n是完整賬戶的字節表示長度。此外，從客戶端讀取，須要完整的賬戶信息來驗證其中的任何特定值。

咱們在帳戶中存儲數據的策略與其餘系統（如以太坊）不一樣（9）。咱們的方法容許Move語言經過將賬戶表示爲訪問值路徑的有序映射，以提供更好的編程抽象。這種表示容許Move經過虛擬機有效地管理資源的保護。Move鼓勵每一個用戶在他們本身的帳戶當中持有資源。在最初發布的Libra當中，咱們針對小客戶進行了優化。而在將來的版本中，咱們可能會考慮支持更高效的結構來表明更大的帳戶，好比說Merkle AVL二叉樹結構 ^[30]。

帳戶收回和重加工：咱們預計，隨着系統的使用，最終與賬戶相關的存儲增加可能會成爲一個問題。正如gas鼓勵負責任地使用計算資源（見第3.1節），咱們預計存儲可能須要一種租賃機制。咱們正在評估最適合生態系統的租賃機制。咱們討論了一個可應用於任何肯定過時時間的策略選項，在時間到期以後，數據就能夠被收回。

在每一個影響帳戶的事務執行以後，虛擬機計算邏輯過時時間，在該時間內，爲賬戶分配的存儲可被釋放。虛擬機可自由地應用任何肯定性方法來肯定到期時間。這種政策的一個例子是收取以Libra幣計價的費用，該費用是基於帳戶的存儲時間及其大小肯定的。賬戶的驗證器表示爲H(H(AccountBlob)||（ExpirationTime)，它對賬戶的過時時間進行編碼。到期後，虛擬機拒絕訪問賬戶，從而引起一個錯誤。因爲AccountBlob是不可訪問的，所以在ExpirationTime以後，驗證者能夠自由刪除此數據。然而，驗證者容許事務在過時後經過從新計算其內容來從新激活賬戶。該事務必須包含AccountBlob的預映射（preimage），並具備包含進一步存儲成本的關聯交易費用。經過從新計算和檢查與賬戶關聯的哈希值（不刪除）來確保從新獲取內容的真實性。這種租賃實現方法是對現有賬戶收回方案的改進，而現有方法要求第三方發送一個事務來刪除賬戶的存儲。

4、5 事件

Ei 是Ti執行期間發出的事件列表，每個事件都以一個子葉存儲在Merkle樹中，該二叉樹Ei造成一個驗證器。事件被序列化爲 form (A, p, c)的一個元組，它表示發出事件（A）、數據有效負載（p）以及計數器值（c）的事件結構訪問路徑。這些元組按Ti執行期間發出的事件順序j進行索引。根據慣例，咱們把事件j→（a，p，c）包含在Ei中，表示爲 (j,(A, p, c)) ∈ Ei。Ei的驗證器包含在TransactionInfoi中，所以，驗證者可構造一個包含證實，證實在第i個事務中，第j個事件是 (A, p, c)。

包含在每一個事件中計數器c，在容許客戶端檢索給定訪問路徑A的事件列表方面發揮了特殊做用。客戶端也能夠確保列表是完整的。在Move語言中，表示具備訪問路徑A的事件的事件結構，爲其已發出的事件總數維護一個計數器C。此計數器存儲在帳本狀態中，並在每次事務執行，在訪問路徑A上發出事件後進行遞增。客戶端可獲取最近帳本狀態的驗證器，查詢與事件結構關聯的計數器以獲取訪問路徑A，並檢索事件總數C。

而後，客戶端能夠查詢不受信任的服務，以獲取訪問路徑A上的事件列表。查詢響應由一組元組(i, j, A, p, c)組成，每一個元組對應一個事件，其中i是發出事件的事務序列號，j是此事務中事件發出的順序。能夠爲每一個事件提供 (j,(A, p, c)) ∈ Ei的關聯包含證實。因爲客戶端知道訪問路徑A發出的事件總數，所以它們可確保不受信任的服務提供了此數量的不一樣事件，並按其序列號0 ≤ c < C對其進行排序。這使客戶端確信爲A返回的事件列表是完整的。

此方案容許客戶端保存對訪問路徑A上事件的已驗證訂閱。客戶端可按期爲事件訪問路徑A觸發總計數器C，以肯定訂閱是不是最新的。例如，客戶端可以使用它在監視的地址上維護對傳入付款事務的訂閱。不受信任的第三方服務可爲按訪問路徑索引的事件提供源，而客戶端可有效地驗證返回的結果。

5、拜占庭容錯共識

拜占庭容錯共識協議容許一組驗證者建立單個數據庫的邏輯層次。這種共識協議在驗證者之間複製提交的事務，對當前數據庫執行潛在的事務，而後就事務順序和結果執行的綁定承諾達成一致。所以，全部驗證者均可以按照狀態機器複製範式^[31]爲給定的版本號維護相同的數據庫。Libra 區塊鏈使用了一種HotStuff ^[13]共識協議的變體，叫作LibraBFT協議。在傳統的DLS^[32]和PBFT^[33]以及更新的Casper^[34]和Tendermint^[35]的部分同步模型中，它提供了安全性和活力。本節概述LibraBFT共識機制中的關鍵決策。LibraBFT的完整報告^[12]中包含了更詳細的分析，包括安全性和活性的證實。

即便存在拜占庭錯誤^[36]，驗證者之間也必須就數據庫狀態達成一致。拜占庭錯誤模型容許一些驗證者不受約束地任意偏離協議，除了在計算上的界限（所以不能破壞密碼學假設)。拜占庭錯誤是最壞的狀況下的錯誤，在這種狀況下，驗證者惡意串通，惡意破壞系統。一種能夠容忍由惡意或被黑客攻擊的驗證者引發的拜占庭錯誤的共識協議，也能夠減輕任意的硬件和軟件故障。

LibraBFT假設一組3f + 1的投票分佈在一組驗證者中，這些驗證者多是誠實的，也多是拜占庭式的。當最多f票由拜占庭驗證者控制時，LibraBFT仍然是安全的，它能夠防止雙重支出和分叉等攻擊。LibraBFT保持活性——向客戶端提交事務，只要存在一個全球穩定時間（GST）以後，誠實的驗證者之間的全部消息將在一個最大的網絡延遲δ(這是引入的部分同步模型^[32]發送到其餘誠實的驗證者。除了傳統的保證以外，LibraBFT還在驗證者崩潰和重啓時維護安全性——即便全部驗證者同時重啓。

LibraBFT的概述：驗證者接收來自客戶端的交易，並經過一個共享的mempool協議來彼此共享這些事務。而後LibraBFT協議按順序進行。在每輪中，都有一個驗證者會扮演領導者（leader）的角色，並提出一個事務區塊來擴展一個包含完整的之前事務歷史的經認證的區塊序列（請參閱下面的法定人數證書quorum certificate)。驗證者接收提議的區塊並檢查其投票規則，以肯定是否應投票支持對該區塊進行驗證。這些簡單的規則確保LibraBFT的安全性——它們的實現能夠被清晰地分離和審計。若是驗證者打算爲這個區塊投票，它將執行該區塊的事務，而不受外部影響。這將致使驗證器對數據庫的計算，從而促成了區塊的執行。這個驗證者而後發送一個爲這個區塊和數據庫驗證人進行的投票給這個leader。leader收集這些投票，造成一個法定人數證書（quorum certificate（QC）），它爲這個區塊提供2f +1票的證據，並將該QC廣播給全部驗證者。

當知足連續的3-chain提交規則時，區塊就會被提交。若是在第k輪有QC，而且在第k + 1輪和第k + 2輪有兩個區塊和QC確認，則區塊被提交。提交規則最終容許誠實的驗證者提交一個區塊。LibraBFT保證全部誠實的驗證者最終都將提交該區塊（以及從它連接的區塊的序列)。一旦提交了一個區塊序列，執行事務所產生的狀態就能夠持續下去並造成一個複製的數據庫。

HotStuff範例的優勢：咱們針對驗證者的性能、可靠性、安全性、健壯實現的易用性和運營開銷等方面評估了幾個基於BFT的協議。咱們的目標是選擇一種協議，該協議最初將支持至少100個驗證者，而且可以隨着時間的推移發展到支持500 – 1000個驗證者。選擇HotStuff協議做爲LibraBFT的基礎有三個緣由：(1)安全性參數的簡單性和模塊化；(2)容易將共識與執行相結合；(3)早期實驗中的性能表現良好。

這個HotStuff協議分解爲安全模塊（投票和提交規則）以及活性模塊（pacemaker）。這種解耦提供了獨立開發和並行測試不一樣模塊的能力。因爲投票和提交規則簡單，協議安全性易於實現和驗證。將執行做爲共識的一部分進行集成是很簡單的，以免在基於領導者的協議中由非肯定性執行引發的分叉問題。最後，咱們的早期原型證明了HotStuff中獨立測量的高吞吐量和低事務延遲^[13]。咱們沒有考慮基於工做量證實（PoW）的協議，由於它們的性能差，能源（和環境）成本高^[24]。

HotStuff擴展及修改：在LibraBFT中，爲了更好地支持Libra生態系統的目標，咱們擴展和調整了核心HotStuff協議，並以多種方式進行實現。重要的是，咱們從新制定了安全條件，並提供安全、活力和樂觀反應的擴展證實。咱們還實現了一些附加功能。首先，咱們讓驗證者集體簽署區塊的結果狀態，而不只僅是事務序列，從而使協議更能抵抗不肯定性錯誤。這還容許客戶端使用QC來驗證從數據庫中讀取的內容。第二，咱們設計了一個傳出明確超時的pacemaker資源管理器，驗證者依賴於這些pacemaker中的法定數量來進入下一輪，而不須要同步時鐘。第三，咱們設計了一個不可預測的leader選舉機制，其中一輪的leader由最新提交區塊的提議者使用可驗證隨機函數（VRF） ^[37]肯定。

這種機制限制了惡意方對leader發起有效拒絕服務攻擊的時間窗口。第四，咱們使用聚合簽名^[38]來保留簽署QC的身份驗證者。這使咱們可以向有助於QC的驗證者提供激勵（詳見9.3節內容）。它也不須要複雜的閾值密鑰設置^[39]。

驗證者管理：Libra協議使用了一個Move模塊管理一組驗證者。這在共識系統和定義可信驗證者集的密碼學經濟系統之間建立了一個清晰的分離。咱們將在第9.2節中討論Libra區塊鏈對該合約的實施。以這種方式抽象驗證者管理，是經過定義Move中的核心區塊鏈原語而得到的靈活性的一個例子。

對驗證者組的每次更改，都定義了一個新的epoch期。若是一個事務致使驗證者管理模塊更改驗證者集，該事務將是當前epoch期提交的最後一個事務。該區塊或該epoch期之後的區塊中的任何後續事務，都將被忽略。一旦事務被提交，新的驗證者集就可開啓共識協議的下一個epoch期。

在一個epoch期內，客戶端不須要同步每一個QC。因爲已提交的QC包含對全部之前狀態的綁定承諾，客戶端只須要同步到當前epoch期的最新可用QC。若是此QC是其epoch期的最後一個，則客戶端能夠看到新的一組驗證者，更新其epoch，而後再次同步到最新的QC。若是驗證者選擇按照第4.2節的描述刪減歷史記錄，那麼它須要保留至少足夠的數據，以向客戶端提供驗證者集更改的證實。

驗證者管理合約，必須提供知足由共識協議要求的安全屬性的驗證者集。拜占庭驗證者不能控制超過 f的投票權。投票權必須在epoch期間以及epoch以後的一段時間內保持誠實，以容許客戶端與新配置同步。離線時間超過此時間段的客戶端須要使用一些外部真實性源從新同步，，以獲取他們信任的檢查點（例如，從其用於接收更新軟件的源從新同步）。此外，驗證者集不能過於頻繁地轉動，以至於破壞系統的性能，或者致使客戶端爲過多數量的epoch期下載QC。咱們計劃研究最佳的epoch期長度，預計這個時間會小於1天。

6、網絡設計

Libra協議，與其餘去中心化系統同樣，須要一個網絡基層來支持其成員之間的通訊。驗證者之間的共識和共享的mempool協議都須要經過互聯網進行通訊，如第5節和第7節所述。

這個網絡層在設計上是通用的，靈感來自libp2p ^[40]項目。它目前提供了兩個主要接口：（1）遠程過程調用(RPC)和（2）DirectSend，實現了向單個接收方發送「即發即棄」（fire-and-forget）類型消息。

驗證者之間的網絡實現爲一種點對點系統，使用了Multiaddr ^[41]方案進行對等（peer）尋址，使用TCP用於可靠傳輸，Noise^[42]用於身份驗證和完整的端到端加密，Yamux^[43]用於在單個鏈接上的多路複用子流，push式gossip用於對等節點發現。每一個新的子流都被分配了一個由發送方和接收方都支持的協議。每一個RPC和DirectSend類型都對應一個這樣的協議。

這個網絡系統使用與共識系統相同的驗證者集管理智能合約，做爲當前驗證者集的一個真實性來源。這種合約持有每一個驗證者的網絡公鑰和共識公鑰。一個驗證者經過監視這個智能合約中的更改來檢測驗證者集中的更改。要加入這個驗證者間網絡，一個驗證者必須使用這個合約定義的最新驗證者集中的網絡公鑰進行身份驗證。啓動一個驗證者則須要一組種子對等節點（peers），首先對要加入的驗證者進行身份驗證，使其成爲驗證者間網絡的合格成員，而後與這個新對等節點共享它們的狀態。

Libra協議中的每一個驗證者都維護着系統的徹底成員關係視圖，並直接鏈接到須要與之通訊的任何驗證者。不能直接鏈接的驗證者則被假定爲屬於系統拜占庭錯誤的範圍。

 

圖6：寫入事務經過Libra Core內部組件的流程

每一個驗證者的健康信息，使用週期性活性試樣來肯定，不會在各驗證者之間進行共享；相反，每一個驗證者直接監視它的對等節點驗證者的活動。咱們指望這種方法在須要部分紅員視圖、複雜的故障檢測器或通訊中繼以前，能夠擴展到幾百個驗證者。

7、Libra Core實現

爲了驗證Libra協議，咱們構建了一個開源的原型實現 Libra Core^[6]。這個實現是用Rust語言編寫的, 咱們選擇Rust是由於這種語言專一於實現安全的編碼實踐，及其對系統編程的支持和高性能屬性。咱們將系統的內部組件拆分爲gRPC ^[44]服務。模塊化容許更好的安全性;例如，共識安全組件能夠在單獨的進程中運行，甚至能夠在不一樣的機器上運行。

Libra 區塊鏈的安全性取決於驗證者、Move程序和Move 虛擬機的正確實現。目前，咱們正在解決Libra Core存在的這些問題。這包括隔離代碼中有助於一個驗證者在共識期間簽署一個事務區塊的部分，並應用措施來加強這些組件正確性的保證（例如，普遍的測試、正式規範和正式驗證)。高保證性方面的工做，還包括確保代碼依賴項的安全性（例如，代碼評審過程、源代碼控制、開源庫依賴項、構建系統和版本發佈管理)。

7.1 寫入請求生命週期

圖6展現了Libra Core中支持對去中心化數據庫進行寫入操做的事務的生命週期。本節深刻研究事務如何經過驗證者的內部組件進行流動。

當客戶端但願向數據庫提交事務時，就會發起一個請求（request）。咱們目前假設客戶端有一個帶外機制來查找要提交事務的驗證者地址——這一機制的最終版本還沒有設計出來。

准入控制（Admission control）。在接收一筆事務時，一個驗證者的准入控制組件會執行初始語法檢查1拋棄那些永遠不會被執行的畸形事務。儘早進行這些檢查可避免把資源用在垃圾事務上。准入控制可能訪問VM2，VM使用存儲組件執行檢查，如確保帳戶有足夠的餘額支付事務所需的gas。接納控制組件設計,組件的驗證器能夠運行多個實例。這種設計容許驗證者處理規模的事務和減輕拒絕服務攻擊。這個准入控制組件的設計，能夠使一個驗證者運行多個組件實例。這種設計容許驗證者擴展傳入事務的處理，並減小拒絕服務攻擊。

Mempool。經過准入控制組件的檢查的事務將被送入驗證者的Mempool，Mempool容納着等待在內存緩衝區被執行的事務3。Mempool中可能容納着來自同一個地址的多筆事務。由於Mempool能夠一次處理多筆事務，它能執行檢查，好比驗證同一地址上的一系列操做是否都可以支付准入控制系統沒法支付的gas。使用這個共享Mempool協議4，一個驗證者能夠在本身的Mempool中與其餘驗證者共享事務，將從其餘驗證者接收的事務放到本身的Mempool中。

Conesensus共識。驗證者經過從其Mempool中選擇一系列事務來建立區塊。當驗證者充當共識協議的領導者（leader）時，它從其Mempool5中組成一個事務區塊。它將此事務區塊做爲一個提議發送給其餘驗證者6。共識組件負責協調全部驗證器之間關於這些事務區塊的順序及其使用LibraBFT協議的執行結果的協議(第5節)。

事務執行。做爲達成協議的一部分，事務區塊被傳遞給執行器組件7 ,負責管理VM8中事務（第3節）的執行。這種執行發生在事務達成協議以前。這種早期執行是安全的，由於事務是具備肯定性的，而且沒有外部影響。在執行區塊中事務以後，執行組件會構建一個這些事務的帳本歷史（第4.2節）。這個帳本歷史驗證者將返回到共識組件9。

這個leader而後將嘗試組成一個法定數量證書鏈（第5節）來就這個帳本驗證者達成共識，其中每個證書都由一組驗證者來進行簽名，至少得到2f+1個投票。

提交一個區塊。一旦共識算法達成一致，任何誠實的驗證者都能確保全部其餘誠實的驗證者最終將提交一個一致的帳本歷史。驗證者能夠從執行組件的緩存中讀取區塊執行的結果並更新其本地數據庫存儲（10）。

7.2 讀取請求生命週期

客戶端還能夠提交讀取請求，爲去中心化數據庫中賬戶的內容查詢驗證者。讀取請求不會改變狀態，能夠在本地處理，而不須要通過共識。讀取請求被提交到驗證者的准入控制組件。准入控制組件執行初步檢查，從存儲中讀取數據，而後將結果發送回客戶端。這個響應附帶一個法定數量證書（如第5節中描述），其中包含一個根哈希（如第4節中描述)。QC容許客戶端對查詢的響應進行身份驗證。這個客戶端使用與虛擬機相同的技術，使用邏輯數據模型（第2節）來解釋賬戶的原始字節。例如，要讀取地址a 的帳戶餘額，客戶端須要解碼嵌入到該賬戶的原始字節中的LibraCoin.T資源。

8、 性能

Libra協議的使命是支持一個全球金融基礎設施。性能是實現這一目標的一個組成部分。咱們將討論區塊鏈性能的三個組成部分:

1. 吞吐量：區塊鏈每秒可處理的事務數；
2. 延遲：客戶端向區塊鏈提交事務與另外一方看到這筆事務之間的時間；
3. 容量：區塊鏈存儲大量賬戶數的能力；

Libra協議還處於原型階段，所以咱們尚未具體的性能指標，但咱們預計Libra協議在最初發布時可支持每秒1000筆支付事務，事務提交到確認的最終時間爲10秒。隨着時間的推移，咱們但願可以增長系統的吞吐量，以知足網絡的需求。咱們預計，許多支付事務將發生在鏈下進行，例如，在託管錢包內或經過使用支付通道^[45]。所以，咱們認爲鏈上每秒支持1000筆事務，將知足生態系統的初始需求。Libra協議旨在經過如下幾種方式來實現這些目標:

協議設計：Libra協議的不少元素都是基於性能挑選的。例如，LibraBFT算法在三輪網絡通訊中得到共識結果，不須要任何實時延遲就區塊進行提議或投票。這使得提交延遲只受驗證者之間的網絡延遲的限制。

咱們還考慮採用並行化和分片（sharding）來選擇協議的元素。計算驗證者的稀疏Merkle樹方法容許跨多臺機器對數據庫進行分片（(這增長了容量）或並行處理更新（這增長了吞吐量）。初始事務驗證（包括計算昂貴的簽名驗證）也能夠實現並行化。

驗證者挑選：與大多數服務同樣，Libra區塊鏈的性能取決於操做它的底層驗證器的性能。去中心化與性能之間存在着一種妥協。對資源很是充足的驗證者須要，限制了可執行該角色實體的數量。然而，資源極度不足的驗證者的存在，將限制整個系統的性能。

咱們傾向於採起一種平衡的方法，將目標鎖定在能夠在商用硬件上運行的節點，許多實體都能買到這些硬件。可是，咱們假設了這些節點運行在服務器級別硬件上，而且與數據中心可以鏈接良好。根據咱們進行的一次近似分析顯示，該系統極可能能知足每秒1000筆事務的需求。

帶寬：若是咱們假設每筆事務須要5 KB的流量——包括經過mempool接收事務、重播事務、接收來自leader的區塊以及複製到客戶端的成本——那麼驗證者須要40 Mbps的網絡鏈接來支持每秒1000筆事務。這種級別的帶寬仍是可以普遍得到的。

CPU：簽名驗證是與支付轉換操做相關的重要計算成本。咱們設計了容許並行驗證事務簽名的協議。採用Modern簽名方案，一個普通商用CPU就能夠支持每秒1000多個事務驗證。

磁盤：從大型服務器供應商那裏，咱們能夠得到16TB SSD存儲的服務器。因爲當前狀態是驗證者處理事務所需的唯一信息，因此咱們估計，若是賬戶大小約爲4 KB(包括全部形式的開銷)，那麼這將使得驗證者可存儲40億個賬戶。咱們預計，磁盤存儲的發展、驗證器向多個分片的擴展，以及經濟激勵措施將容許商用系統保持使用這個系統。

歷史數據的增加可能會超出單個服務器所能處理的數量。驗證者可隨意丟棄那些在處理新事務的過程當中所不須要的歷史數據(參見第4.2節)；可是，那些但願查詢來自過去事務事件的客戶端可能對這些數據感興趣。因爲驗證者簽署了對該數據的綁定承諾，客戶端可自由地使用任何系統訪問數據，而沒必要信任交付數據的系統。咱們但願這種類型的讀取流量可以很容易地經過並行進行擴展。

9、 用Move來實施Libra的生態系統政策

Libra 區塊鏈是一個獨特的系統，它平衡了傳統金融網絡的穩定性和由加密經濟手段管理的系統所提供的開放性。正如咱們在第1節中討論的，Libra協議旨在支持Libra生態系統實現新的經濟^[4]和治理^[3]策略。該協議指定了一個靈活的框架，該框架在關鍵系統組件（如本地貨幣、驗證者管理和事務驗證）中是參數化的。在本節中，咱們將討論Libra 區塊鏈如何使用Move編程語言定製這些組件。咱們的討論集中在協調網絡參與者和驗證者激勵的挑戰，以及支持Libra生態系統的運行、治理和演化的挑戰。

9.1 Libra幣

許多加密貨幣沒有真實世界資產的支持。所以，投資和投機一直是這些加密貨幣主要用例。投資者購買這些貨幣時，每每認爲它們會大幅升值，而後能夠以更高的價格賣出。對這些貨幣長期價值的信念波動，致使了相應的價格波動，有時會致使價值的大幅波動。

爲了推進普遍採用，Libra被設計成一種貨幣，任何用戶都會知道，Libra今天的價值與明天甚至更遠將來的價值都是接近的。儲備是實現價值保值的關鍵機制。經過儲備，每枚幣都有一套穩定的流動資產做爲後盾。有了與儲備掛鉤的一羣具備競爭力的流動性提供者的存在，用戶就能夠放心，他們所持有的任何一枚幣均可以以高於或低於底層資產價值的狹窄價差，以法訂貨幣出售。這從一開始就賦予了Libra內在價值，並有助於防範現有加密貨幣所經歷的投機性波動。

Libra的儲備資產是一個低波動性資產的集合，包括來自穩定且聲譽良好的國家央行發行的法幣和政府證券。因爲Libra的價值實際上與一籃子法訂貨幣掛鉤，從任何特訂貨幣的角度來看，Libra的價值都會有波動。儲備金的組成旨在減輕這些波動的可能性和嚴重性，特別是在負面方向（例如，經濟危機中)。爲此，該貨幣籃子的結構考慮到了資本保值和流動性。

該儲備由Libra協會管理（見第9.2節），該協會發布了一份關於該儲備運行的詳細報告^[4]。用戶不直接與儲備接口。相反，爲了支持更高的效率，會有一些受權轉售商，他們是由Libra協會惟一受權的實體，來處理大量的法訂貨幣和Libra在儲備中的流入和流出。這些受權轉售商與事務所和其餘買賣加密貨幣的機構相結合，爲那些但願將現金與Libra進行來回兌換的用戶提供流動性。

爲了實施這一計劃，Libra的合約容許Libra 協會在需求增長時鑄造新的Libra幣，以及在需求減小時銷燬它們。該協會不制訂貨幣政策。它只能根據受權經銷商的要求鑄造和銷燬幣。用戶沒必要擔憂這種關聯會致使通脹或貨幣貶值：要鑄造新硬幣，必須有相應的法定存款準備金。

使用Move自定義Libra合約的能力，容許在不修改底層協議或實現該協議的軟件的狀況下定義此計劃。此外，還能夠建立其餘功能，好比須要多個簽名來鑄造貨幣和建立有限數量的密鑰來提升安全性。

 

9.2 驗證者管理和治理

共識算法依賴於驗證者集管理Move模塊來維護當前的驗證者集，並管理驗證者之間的投票分配。這種合約負責維護一個驗證者集，其中3f + 1的總投票中最多有f票由拜占庭驗證者控制。

最初，Libra區塊鏈只向創始成員（Founding Members）授予投票權，這些實體：（1）知足一組預約義的創始成員資格標準^[46]，（2）擁有Libra投資代幣（Libra Investment Tokens）。這些規則有助於確保對擁有一個安全且活動的驗證者集的安全性需求。使用創始成員資格標準確保了創始成員都是已創建起聲譽的組織，使其不太可能出現惡意行爲，並暗示他們將勤奮地捍衛本身的驗證者來抵禦外部攻擊。Libra投資代幣表明對準備金利息回報的預期，進一步激勵驗證者去維持系統的運行。因爲儲備中的資產風險低、收益低，只有當網絡成功、儲備規模大幅增加時，早期投資者才能得到超額回報。

雖然這種評估驗證者資格的方法是對傳統許可區塊鏈（一般造成一組封閉的業務關係）的改進，但咱們但願Libra 區塊鏈徹底沒有許可。爲此，咱們計劃逐步過渡到權益證實（PoS）^[47]系統，在該系統中，驗證者的投票權與他們所持有的Libra幣數量成正比。這將把生態系統的治理移交給它的用戶，同時經過要求驗證者持有稀缺資源並將它們的動機與健康系統操做結合起來，以防止Sybil攻擊^[48]。這種過渡須要（1）生態系統足夠大，以防止單個壞行爲者形成破壞；（2）爲不想成爲驗證者的用戶提供一個具備競爭性和可靠的委託市場；（3）解決Libra在Staking過程當中面臨的技術和可用性挑戰。

Libra生態系統治理的另外一個獨特色是驗證者造成了一個真實世界的實體，即非盈利的Libra協會，由一個驗證者委員會管理。該協會的每個理事會成員表明着每一個驗證者。理事會中成員的投票權重與共識協議中驗證者的投票權重相同。協會執行的任務包括管理儲備、評估驗證者資格標準以及指導Libra協議的開源開發。

Move使將驗證器管理和治理規則編碼爲一個模塊成爲可能。Libra投資代幣能夠使用Move資源來實現。Move經過將投資代幣或Libra幣包裝在資源中，從而防止得到底層資產，從而容許對它們進行抵押。已抵押的資源可用於計算驗證者的投票權。這個合約能夠配置變動生效的時間間隔，以減小驗證者集的變更。

Libra 協會的運做也獲得了Move的幫助。因爲該協會是儲備的運營商，它能夠建立Move模塊，將Libra的鑄造和銷燬權力委託給與受權經銷商進行交互的操做部門。該業務部門還能夠評估潛在創始成員是否符合資格標準。Move容許靈活的治理機制，好比容許理事會行使其權力，經過投票收回其受權。

該協會發布了一份詳細的文件，概述了其擬議的結構^[3]。協會中的全部治理都源於驗證者理事會——該理事會擁有最終的權利來維護提供給協會的任何受權。所以，隨着驗證者集從最初的創始成員集更改成基於PoS的集，整個Libra生態系統的治理也在不斷髮展。

9.3 驗證者的安全與激勵

在初始設置中，使用創始成員做爲驗證者，咱們認爲每一個驗證者的機構聲譽和經濟激勵足以確保拜占庭驗證器控制的投票不超過f。然而，在將來，一個以幣全部權爲表明的開放系統將須要一個徹底不一樣的市場設計。咱們已開始瞭解基於利益相關者和消費者對錢包和其餘表明的信心的區塊鏈系統的治理和均衡結構。在這個過程當中，咱們在Libra方法和更成熟的方法（如工做量證實（PoW））之間肯定了新的市場設計妥協。

然而，要肯定如何在確保網絡安全和效率的同時，還能最好地保持生態系統中的長期競爭，這須要更多的研究。此外，因爲基於份額（stake）的治理引入了對影響力的路徑依賴，所以有必要探索保護較小利益相關者和服務提供者的機制。

Move容許靈活界定相關激勵計劃，如gas訂價或staking。例如，一般討論的stake slashing機制能夠在Move中實現，方法是鎖定stake一段時間，若是驗證者違反LibraBFT算法的規則，影響安全性，則自動懲罰驗證器。

相似地，當驗證者在LibraBFT算法中投票時，這些投票能夠記錄在數據庫中。該記錄容許Move模塊基於算法中的參與度來分發獎勵，從而激勵驗證者保持活動。Libra儲備的利息和gas支付也能夠做爲激勵的來源。這兩個來源都由Move模塊管理，這增長了它們分配的靈活性。雖然須要更多的研究來設計一種方法來支持Libra生態系統的進化，但Move的靈活性確保了所需的方法能夠在對Libra協議進行不多（若是有的話）更改的狀況下實現。

10、 Libra接下來要作什麼？

咱們爲Libra協議提出了一個提案，容許一組驗證者提供一個去中心化數據庫來跟蹤可編程資源。咱們討論了Libra協議的一個開源原型——Libra Core，並展現了爲智能合約引入的Move編程語言如何容許Libra協議實現Libra生態系統的獨特設計。

本文描述的協議和實現目前都處於原型階段。咱們但願重新成立的Libra協會和更普遍的社區收集反饋，把這些想法變成一個開放的金融基礎設施。咱們目前正在運行一個測試網絡，以容許社區對這個系統進行試驗。

咱們正致力於這個系統的首次啓動，爲了將其保持在可管理的範圍內，咱們計劃在第一個版本中進行幾個簡化。在系統的早期，使用一組外部承認的創始成員減小了對共識激勵系統的需求，並容許更快的更新速度。咱們預計只對系統定義的模塊使用Move語言，而不是讓用戶定義本身的模塊，這將使Libra生態系統可以在徹底造成Move語言以前啓動。這還容許在不損害使用Move定義核心系統行爲所帶來的靈活性的狀況下中斷所作的更改。然而，咱們打算在Libra協議的將來版本中提供對Move語言的開放使用。

最後，咱們目前正在Libra協會的框架內工做，以啓動這個新生態系統背後的技術基礎設施。咱們發佈了一個路線圖^[50]的工做，咱們計劃爲支持這個啓動作出貢獻。Libra協會的首要目標之一是將Libra的生態系統遷移到一個沒有許可的系統中。咱們已經記錄了^[5]在進行此遷移時所面臨的技術挑戰。該協會的開源社區^[6]提供了有關如何開始使用Libra測試網、試用Move語言和爲Libra生態系統作出貢獻的信息。

致謝：感謝如下人士對本文的討論和反饋：

Adrien Auclert，Morgan Beller，Tarun Chitra，James Everingham，Maurice Herlihy，Ravi Jagadeesan，Archana Jayaswal，Scott Duke Kominers，John Mitchell，Rajesh Nishtala， Roberto Rigobon，Jared Saia，Christina Smedley，Catherine Tucker， Kevin Weil，David Wong，Howard Wu，Nina Yiamsamatha，和Kevin Zhang。

引用

[1] The Libra Association, 「An Introduction to Libra,」 https://libra.org/en-us/whitepaper.

[2] C. Catalini and J. S. Gans, 「Some simple economics of the blockchain,」 WP No. 22952, National Bureau of Economic Research, 2016.

[3] The Libra Association, 「The Libra Association,」 https://libra.org/en-us/association-council-principles.

[4] C. Catalini et al., 「The Libra reserve,」 https://libra.org/about-currency-reserve.

[5] S. Bano et al., 「Moving toward permissionless consensus,」 https://libra.org/permissionless-blockchain.

[6] The Libra Association, 「Libra developers,」 https://developers.libra.org/.

[7] P. T. Devanbu et al., 「Authentic third-party data publication,」 in Data and Application Security,Development and Directions, IFIP TC11/ WG11.3 Fourteenth Annual Working Conference onDatabase Security, Schoorl, The Netherlands, August 21-23, 2000, 2000, pp. 101–112.

[8] M. Naor and K. Nissim, 「Certificate revocation and certificate update,」 IEEE Journal on Selected Areas in Communications, vol. 18, no. 4, pp. 561–570, 2000.

[9] R. Tamassia, 「Authenticated data structures,」 in Algorithms – ESA 2003, 11th Annual European Symposium, Budapest, Hungary, September 16-19, 2003, Proceedings, 2003, pp. 2–5.

[10] S. Blackshear et al., 「Move: A language with programmable resources,」 https://developers.libra.org/docs/move-paper.

[11] R. C. Merkle, 「A digital signature based on a conventional encryption function,」 in Advances in Cryptology – CRYPTO ’87, A Conference on the Theory and Applications of Cryptographic Techniques, Santa Barbara, California, USA, August 16-20, 1987, Proceedings, 1987, pp. 369–378.

[12] M. Baudet et al., 「State machine replication in the Libra Blockchain,」 https://developers.libra.org/docs/state-machine-replication-paper.

[13] M. Yin et al., 「Hotstuff: BFT consensus in the lens of blockchain,」 2018. [Online]. Available:https://arxiv.org/abs/1803.05069

[14] P. A. Bernstein, V. Hadzilacos, and N. Goodman, 「Concurrency control and recovery in database systems.」 Addison-Wesley, 1987.

[15] D. P. Reed, 「Naming and synchronization in a decentralized computer system,」 Ph.D. dissertation, Massachusetts Institute of Technology, Cambridge, MA, USA, 1978.

[16] G. Wood, 「Ethereum: A Secure Decentralised Generalised Transaction Ledger,」 http://gavwood.com/paper.pdf, 2016.

[17] G. Bertoni et al., 「Keccak,」 in Advances in Cryptology – EUROCRYPT 2013, 32nd Annual

International Conference on the Theory and Applications of Cryptographic Techniques, Athens,

Greece, May 26-30, 2013. Proceedings, 2013, pp. 313–314.

[18] S. Josefsson and I. Liusvaara, 「Edwards-curve digital signature algorithm (EdDSA),」 RFC, vol.8032, pp. 1–60, 2017.

[19] A. Pfitzmann and M. Köhntopp, 「Anonymity, unobservability, and pseudonymity—a proposal

for terminology,」 in Designing privacy enhancing technologies, 2001, pp. 1–9.27

[20] B. C. Pierce, 「Types and programming languages.」 MIT Press, 2002, ch. 19.

[21] J. Girard, 「Light linear logic,」 Inf. Comput., vol. 143, no. 2, pp. 175–204, 1998.

[22] R. Milner, M. Tofte, and R. Harper, 「Definition of standard ML.」 MIT Press, 1990.

[23] 「Leaf-node weakness in Bitcoin merkle tree design,」 https://bitslog.com/2018/06/09/leaf-nodeweakness-in-bitcoin-merkle-tree-design/.

[24] S. Nakamoto, 「Bitcoin: A Peer-to-Peer Electronic Cash System,」 https://bitcoin.org/bitcoin.pdf,2008.

[25] S. A. Crosby and D. S. Wallach, 「Efficient data structures for tamper-evident logging,」 in 18thUSENIX Security Symposium, Montreal, Canada, August 10-14, 2009, Proceedings, 2009, pp.317–334.

[26] L. Reyzin and S. Yakoubov, 「Efficient asynchronous accumulators for distributed PKI,」 in Security and Cryptography for Networks – 10th International Conference, SCN 2016, Amalfi, Italy,August 31 – September 2, 2016, Proceedings, 2016, pp. 292–309.

[27] B. Laurie, A. Langley, and E. Käsper, 「Certificate transparency,」 RFC, vol. 6962, pp. 1–27,2013.

[28] J. R. Driscoll et al., 「Making data structures persistent,」 J. Comput. Syst. Sci., vol. 38, no. 1,pp. 86–124, 1989.

[29] C. Okasaki, 「Purely functional data structures.」 Cambridge University Press, 1999.

[30] L. Reyzin et al., 「Improving authenticated dynamic dictionaries, with applications to cryptocurrencies,」 in Financial Cryptography and Data Security – 21st International Conference, FC 2017,Sliema, Malta, April 3-7, 2017, Revised Selected Papers, 2017, pp. 376–392.

[31] F. B. Schneider, 「Implementing fault-tolerant services using the state machine approach: A tutorial,」 ACM Computing Surveys (CSUR), pp. 299–319, 1990.

[32] C. Dwork, N. Lynch, and L. Stockmeyer, 「Consensus in the presence of partial synchrony,」Journal of the ACM (JACM), vol. 35, no. 2, pp. 288–323, 1988.

[33] M. Castro and B. Liskov, 「Practical Byzantine fault tolerance,」 in USENIX Symposium on

Operating Systems Design and Implementation (OSDI), 1999, pp. 173–186.

[34] V. Buterin and V. Griffith, 「Casper the friendly finality gadget,」 CoRR, vol. abs/1710.09437,2017.

[35] E. Buchman, J. Kwon, and Z. Milosevic, 「The latest gossip on BFT consensus,」 CoRR, vol.

abs/1807.04938, 2018.

[36] L. Lamport, R. Shostak, and M. Pease, 「The Byzantine generals problem,」 ACM Transactions on Programming Languages and Systems (TOPLAS’82), vol. 4, no. 3, pp. 382–401, 1982.

[37] S. Micali, M. Rabin, and S. Vadhan, 「Verifiable random functions,」 in 40th Annual Symposium on Foundations of Computer Science (FOCS’99). IEEE, 1999, pp. 120–130.

[38] D. Boneh, B. Lynn, and H. Shacham, 「Short signatures from the Weil pairing,」 in Advances in Cryptology (ASIACRYPT 2001). Springer-Verlag, 2001, pp. 514–532.

[39] A. Kate and I. Goldberg, 「Distributed key generation for the internet,」 in IEEE International Conference on Distributed Computing Systems (ICDCS’09), 2009, pp. 119–128.

[40]「The libp2p project,」 https://libp2p.io/.28

[41]「The multiaddr project,」 https://multiformats.io/multiaddr/.

[42]  T. Perrin, 「The noise project,」 https://noiseprotocol.org/noise.html, 2018.

[43]「The yamux project,」 https://github.com/hashicorp/yamux/blob/master/spec.md, 2016.

[44]「The gRPC project,」 https://grpc.io/.

[45] L. Gudgeon et al., 「SoK: Off the chain transactions,」 IACR Cryptology ePrint Archive, vol. 2019,p. 360, 2019.

[46] The Libra Association, 「Becoming a Founding Member,」 https://libra.org/becoming-foundingmember.

[47] I. Bentov, A. Gabizon, and A. Mizrahi, 「Cryptocurrencies without proof of work,」 in Financial Cryptography and Data Security – FC 2016 International Workshops, BITCOIN, VOTING, and WAHC, Christ Church, Barbados, February 26, 2016, Revised Selected Papers, 2016, pp. 142–157.

[48] J. R. Douceur, 「The sybil attack,」 in Peer-to-Peer Systems, First International Workshop, IPTPS 2002, Cambridge, MA, USA, March 7-8, 2002, Revised Papers, 2002, pp. 251–260.

[49] C. Catalini, R. Jagadeesan, and S. D. Kominers, 「Market design for a blockchain-based financial system,」 SSRN Working Paper No. 3396834, 2019.

[50] The Libra Association, 「The path forward,」 https://developers.libra.org/blog/2019/06/18/thepath-forward.