Libra Blockchain論文閱讀筆記
==

URL : https://developers.libra.org/docs/assets/papers/the-libra-blockchain.pdf

:::success

:bookmark: 書籤

[TOC]

:::

## 1 Introduction 引言

* 網際網路促進了金融服務業的發展，但對於需要金融服務的人來說，因受到成本、可靠性以及跨國匯款能力的影響，獲得的服務仍是有限的．
* 論文提出了Libra協議。該協議支援Libra生態系統，解決上述問題，擴大資本進入．創造新的金融服務平台．
* Libra幣與信用良好的國家央行存款與國債綁定，因此繼承了普通貨幣的特性，有相對低的價格波動。
* Libra協議必須滿足大規模的交易量，還提供實現經濟與管理政策的靈活性。
* Libra從整體設計上解決了上述需求，並且建立在前人的專案與研究基礎，結合了新穎的方法與成熟的技術．
* 金融服務的良性競爭與創新的前提是倚賴共同的基礎設施處理交易、維持帳戶，確保不同組織與服務間能夠溝通。

### 認證者
* Libra是去中心化的區塊鏈，它由Libra協會的會員進行管理。這些會員進行驗證的工作，處理交易以及維護區塊鏈帳本的狀態。
* Libra協會的會員提供區塊鏈的管理以及Libra幣的儲備金。
* Libra協會的會員按照一定的標準選出，往後會員資格將會持續開放給所有Libra幣的持有者。
* Libra Blockchain是使用Libra協議維護的加密資料庫。
* 資源可以由某個帳戶持有，帳號由公鑰所認證。
* 資源是可以自定義規則的（可寫程式）。

### 區塊鏈
#### Libra Blockchain 有兩個核心角色：驗證器與客戶端。

1. 驗證器維護資料庫並且處理客戶端提交的事務。
2. 驗證者通過分散共識的演算法，驗證提交到資料庫中的交易與執行交易結果的共識。
* 驗證者的職責是維護資料庫，推動交易的進行，將用戶的交易存入資料庫，並且更新狀態。
* 驗證者中有領導者的存在，負責將收到的交易分配個其他的驗證者，這些交易可能來自用戶所提出的交易，或是其他驗證者提交給領導者的交易。
3. 所有驗證者都將執行事務。
4. 執行事務會形成帳本的歷史紀錄（一種資料結構），驗證者不管是否為領導者，都將會對它進行驗證。
5. 客戶端可以向驗證者提出讀取資料庫中的數據。當客戶端提出數據查詢時，驗證者將回傳他所記載最新的狀態與簽章。客戶端也可以通過驗證者同步整個資料庫（一個副本），檢查驗證者執行交易的正確性。

## 2 Logical Data Model 邏輯資料模型
比特幣通過時間戳將交易與時間綁定，讓每筆交易具有唯一性並且避免雙重花費的問題發生。
* Libra區塊練中所有資料都對應著資料庫的某個「版本號碼」。
* 版本號碼代表著當下資料庫的狀態。

Libra使用三元組代表交易狀態
1. Transaction ($T_i$)代表當前交易
2. Output ($O_o$)代表交易的執行結果
3. State ($S_i$)表示帳本狀態
> 例如，某個交易操作了Apply，在帳本$S_{i-1}$下執行$T_i$，執行結果為$O_i$新的帳本則為$S_i$。

> $Apply(S_{i-1},T_i)\to(O_i,S_i)$

* Libra協議通過MOVE語言進行交易時的操作。
* 通過版本號驗證的數據庫將允許驗證者執行下列操作：
1. 在最新版本的帳本下執行某個交易
2. 回應用戶查詢帳戶狀態的需求。
### 帳本狀態(Ledger State)
* 帳本狀態反映了Libra的狀態，例如某個時間點某個用戶持有多少Libra幣。
* 為了驗證交易，所有擔任驗證者都必須知道目前帳本的狀態。
* Libra採用使用者制制定帳本模型，與比特幣的UTXO不同。
> 帳本狀態透過「鍵-值」儲存於資料庫中，帳戶地址(key)將映射到帳戶值(value)。
* 帳戶值由MOVE語言所編寫的資源與模組組成，其中MOVE資源儲存的是資料的值，模組則儲存代碼。
* 帳本的初始狀態由創世區塊進行賦值。
### 帳戶地址(account addresses)
* 帳戶地址是一個長度為256bit的值。
* 產生公鑰與私鑰(vk&sk)，公鑰驗證私鑰簽章。
* 公鑰通過hash進行雜湊後產生的摘要就是地址。
> a = H(vk)

> 當某個帳戶將一筆交易發送給某個用戶，地址a還未有帳戶的情況下。MOVE指令中的create_account(a)，將產生一個帳戶，帳戶將與目標用戶對應。

### 帳戶(account)
* Libra協議允許用戶建立多個帳戶。
* 為了防堵安全性的問題，用戶可以隨時替換新的公私鑰。
> 替換公私鑰後代表帳戶地址也會改變，所有Libra允許使用者在單一用戶中同使擁有多個帳戶地址。

### 資源(Resource value)
資源是字串與數值綁定的紀錄，數值可以是整數也可以是多個整數。資源也可以置入另一個資源中。每個資源都屬於一種類型，該類型由模組(modules)定義。
> 橢圓代表資源，矩形代表模組；從資源到模組的有向邊帶表資源的類型。
1. 0x12.Currency.T資源，其資源為0x56.Currency模組所定義。
2. 定義Currency模組的程式存在0x56位置。
3. 0X34儲存了Currency.T與StateChannel.T資源，其資源分別由0x56.Currency模組與0x78.StateChannel模組所定義。

#### 尋找資源
1. 要在帳戶地址0x12下尋找資源0x56.Currency.T，使用者端將請求0x12/resources/0x56.Currency.T。
2. 每個帳戶地址都可以使用相同的路徑存取0x56.Currency.T。
3. 每個帳戶最多儲存一個資源。
4. 工程師可以自定義封裝資源，例如：
`resource TwoCoin { c1: 0x56.Currency.T, c2: 0x56.Currency.T }`
6. 資源的鍵立與資源類型在模組中定義
7. 資源的轉換、刪除以及發布的規則也在模組中被定義
8. Mome將會對程式碼進行檢驗，以防惡意代碼對資源進行修改

### 模組(module)
1. 模組也稱為模組值(module value)
2. 模組包含Move對資源的編碼
3. Currency模組被標示為0x56.Currency，其中0x56就是帳戶的地址
4. 模組在一個帳戶中的命名是唯一的，每個名子只能被一個帳戶使用於一個模組。
5. 目前Libra不允許對模組修改，模組擁有不可竄改性。一旦模組在帳戶中被創建，便不被允許修改、刪除，除非分叉。

### 交易(Transactions)
1. 用戶在Libra區塊鍊中提交交易後，帳本狀態將會被更新。
2. 一個交易是由交易腳本（Move編寫）和事務腳本的參數（例如，收件人帳戶地址或要發送的Libra的數量）組成。
3. 交易發生後，在Libra區塊鍊經過共識，將交易的輸出結果達成一致的同意，最後把確認與交易結果綁定，帳本狀態才會被更新。
> 比特幣需要經過六個區塊確認後帳本才會確定更新。

#### 交易輸出
1. 執行一個交易Ti將會產生出新的帳本狀態Si與執行結果Oi（包含執行狀態代碼、gas使用量、事件列表）。
2. 執行狀態碼紀錄執行交易的結果，例如執行成功、因為某種原因失敗、gas使用量耗盡。
4. gas使用量記錄了本次交易gas的使用數量
> 智能合約實際執行程式的地方，是由區塊鏈中的眾多節點所協助完成，部署或呼叫合約的人，只需要負擔 Gas 作為交易手續費來支付花費區塊鏈資源的成本。交易手續費是由 gas limit 和 gas price 兩個值來決定，每筆交易都一定會包含這兩個值。

### 事件(Events)
1. 事件列表類似於以太坊中日誌與事件的概念，但使用目的不同。
> 以太坊的日誌與事件主要有四種用途：
> * 幫助客戶端讀取智能合約的回傳值
> * 智能合約非同步通知客戶端
> * 智能合約的儲存
> * 過濾歷史交易紀錄
2. Move程式透過事件結構(event structure)觸發事件。
3. 每個事件都會關聯唯一鍵(unique key)這個唯一鍵將會標示出事件結構，提供事件的詳細訊息。
4. 當交易被共識協議確認，該筆交易產生的事件將會被記錄在帳本中，為交易成功所產生的結果提供證明。
> 例如：某支付交易觸發了事件，允許接收者對交易的金額進行確認。

> 客戶雖可以通過查詢交易是否紀錄在區塊鍊中，來代替該交易觸發的事件查詢。但只上述方法即容易產生錯誤，因為交易存放在區塊鏈中並不代表交易成功執行，很有可能因為執行過程中的gas耗盡而中斷。因此在一個交易可能失敗的系統中，事件不只能夠對交易的執行提供證明，也能對交易的成功是否與預期相符提供證明。

5. 交易只能夠產生事件不能讀取事件，這種設計允許交易的執行基於當前狀態，而不是歷史訊息。

### 帳本歷史(Ledger History)
1. 帳本歷史保存交易的提交與執行的順序，以及他們所觸發的事件。
2. 在帳本歷史中並沒有「區塊」的概念。
> 共識協議將交易打包成區塊，只是一種在執行時得以優化共識的手段。但在邏輯資料模型中，順序產生，並不需要區分哪個區塊包含了哪個交易。
3. 驗證者執行交易驗證時不需要了解帳本歷史，但客戶端可以對帳本歷史提出確認查詢。

#### 客戶端響應
驗證者透過帳本歷史來回應客戶對帳本狀態、交易以及輸出提出的查詢。
> 例如：在版本30下，地址X的帳戶餘額是多少？
> 或者是查詢某種特定類型的歷史事件：地址為Y的帳戶在最近20分鐘內接收了那些支付？

#### 交易執行的審核

客戶端對帳本的驗證為通過重新執行每一筆交易Ti，將執行結果與資料庫中的帳本Si和交易輸出的Oi進行比較。

## 3 Executing Transactions 執行交易

* 在Libra協議中，改變區塊鍊狀態的唯一方式就是執行交易。
* 在Libra協議的初始版本中，使用者只能使用一小部分的Move語言功能。
* Move語言用於定義系統核心概念，但不允許使用者發佈模組宣告自己的資源類型。

### 執行要求(Execution Requirements)
* Libra系統在一開始就設置好了創世狀態，並且所有驗證者都默認它存在。
> 對比特幣來說創世區塊即是區塊鍊中的第一個塊。
* 在Lirbra創世狀態中，通過模組定義了系統核心的組件。
> 例如：帳戶間的邏輯關係、交易驗證、驗證者的選擇、Libra幣等。
* 創世狀態必須對核心組件進行實例化(instantiations)。
> 例如：至少有一個帳戶，能夠支負起第一筆交易產生的費用；或是，必須要有一些驗證者，能夠對交易的認證進行簽名確認。
* 創世狀態是系統的原始狀態，也是系統開始第一筆交易的狀態，剛啟動系統時的狀態。
* 為了簡化系統的設計，初始狀態為「空(empty state)」。
* 創世狀態為特殊的交易T0所創建，並定義了所需要的模組與資源。
* 創世狀態並不是透過正常交易來創建，而是系統默認執行的特殊交易T0。
* 客戶端與驗證器也被設定成只接受T0開始的分類帳歷史紀錄。
* T0通過雜湊函數產生摘要進行標記。
* T0這樣的特殊交易，只能通過設定加入帳本記錄，不能通過正常的共識協議加入帳本記錄。

> 可能是因為凡是都透過共識達成效率較低，所以透過這種「中心化」的手段執行創世狀態的紀錄。在比特幣中可以看到「十分鐘產出一個新的區塊」這類透過博奕手段爭取形成的共識協議；但在Libra為了效率以及穩定性，所以規範的更清楚。

#### 確定性(Deterministic)
* 交易的執行具有確定性與封閉性(hermetic)，這讓交易的結果輸出是可以預期的。
* 交易的執行僅依賴於該次交易所包含的訊息與當前帳本的狀態，交易的執行不受外部影響。
* 相同序列號的交易下，因為確定性與封閉性的因素，讓不同的驗證者都能產生相同的結果。
> 因此，從創世區塊開始執行交易一直到當前帳本，都可以重複獲得相同區塊鍊的歷史交易紀錄。

#### 可計量(Metered)
* Libra協議會對每一筆交易收取交易費，通過Libra幣支付這個費用。
> 這個方法參考以太坊的Gas概念
* Libra將會採用具足夠能力的驗證者滿足Libra生態系統的需求(第八節)。
* 收取費用的目的在於，當資源的需求超過系統所能提供的資源時，降低系統資源的需求量，保證系統可以正常運行。
* 系統正常運行時，對正常的操作收取低廉的費用。
> 這和一般的區塊鍊不同，驗證者可能不具備充分的運算資源，並且，當資源需求變高，驗證費用將會急遽增加，驗證者將能獲得可觀的回報，但對使用者來說將會是筆龐大的支出。
* 一筆交易的執行以Gas的消耗成本來表示所消耗的運算資源的多寡，成本是動態的，因每個使用者的需求而不同。
* 驗證者將會優先執行Gas高的交易，並且當系統擁擠時將會放棄價格低的交易，以減少高負荷下的需求。
* 交易中包含一個Gas的最大值，說明在某個具體的Gas價格下，請求者願意支付的最大數量Gas。
* 在交易執行期間虛擬機(VM)會追蹤Gas的使用量，如果在執行完成前，最大的Gas數量用完，則虛擬機會立刻中止。該交易不會影響到當前的帳本狀態，但會出現在交易歷史中，並且向請求者收取交易費。

> 在Libar區塊鍊中，大部分的核心邏輯都是使用Move進行定義。為了避免重複扣除費用，虛擬機禁止在核心組件執行期間扣除Gas費用，並且這些核心模組都是在創世狀態下定義的，核心模組具有寫入保護防止惡意代碼觸發高額交易費用。執行核心模組的費用將包含在交易的手續費中，是一項基本費用。

#### 資產語意(Asset semantics)

[正如帳本狀態中所提到的](#帳本狀態Ledger-State)
分類帳的狀態直接透過現實世界的數值對數位資產進行編碼。交易執行中必須保證Libar幣不能夠被複製、丟失以及非法轉移。Libar協議只用Move虛擬機安全地實現交易和定義使用者資產。

### 交易結構(Transaction Structure)
一個交易是通過數位簽章認證的訊息，其內容如下：
* 發送者的地址：交易請求者的帳戶地址，虛擬機通過儲存在發送者地址下的LibraAccount.T資源，來讀取許列號、認證公鑰、餘額等內容。
* 發送者的公鑰：該公鑰與交易數位簽章所使用的私鑰呼應。公鑰的雜湊值儲存在LibraAccount.T資源中。
* 程式：包括用於執行交易腳本的Move程式碼，腳本所需的輸入參數列表，所需的模組列表。
* Gas價格：為了執行交易，請求者需要給出願意支付每一Gas為單位的Libra幣數量。
* Gas數量的最大值：執行交易允許被消耗的最大Gas數量值。
* 序列號：一個無符號的整數，與發送者在LibraAccount.T資源的序列號相同。交易執行完後，序列號將遞增一，由於美一個交易有唯一的序列號，所以不能重複交易。

### 執行交易(Executing Transactions)
執行交易通過虛擬機內部的六個步驟順序進行，其中的執行是封閉的，不受任何因素完成。若執行結果達成共識，則將其寫入分類帳歷史紀錄。
1. 檢查簽章
* 交易中的簽名必須與請求者的公鑰匹配。
* 這個步驟是交易本身的功能，不需要從請求者的帳戶中讀取任何資料。
2. 執行序幕(Run prologue)
* 驗證請求者有足夠的Libra幣支付交易中所指定的最大Gas單位數。
* 檢查交易是否曾被執行過。
* 所以檢查都是通過LibraAccount模組，並且在MOVE中實現。
* 在執行中禁用Gas記量。
* prologue將執行以下操作:
1. 檢查請求者公鑰的雜湊值是否等於請求者帳戶下儲存的身分驗證私鑰。
2. 執行檢查:
>gas_price * max_gas_amount <= sender_account_balance

如果沒有這個檢查，虛擬機將可能執行會失敗的交易。因為請求者無法支付Gas的費用。
3. 確保交易序號等於使用者帳戶下儲存的序列號。如果沒有這個檢查，攻擊者就可以重新重複執行已執行過的交易。
3. 驗證交易腳本與模組
* VM將驗證交易腳本與模組以及MOVE位元組碼符合形式完善(Well-formedness)。
* 在實際運行或發布任何MOVE代碼前位元組碼驗證器將會檢查所有關鍵屬性。
1. 類型安全性
2. 參考安全性
> 沒有空參考(dangling references)的存在
3. 資源安全性
> 資源不會被複製或無意中被破壞。
4. 發布模組
* 交易程式中的每個模組都必須在發送人的帳戶下發布。
* 禁止使用重複的模組名稱。
> 如果交易嘗試將命名為M的模組發佈到已經包含命名為M模組的帳戶，將會失敗。
5. 執行交易腳本
* 虛擬機將綁訂於交易腳本中的參數以形式參數(formal parameters)的方式執行他。
> 即直接使用參數內容不另外保存。
* 如果腳本執行成功，則腳本執行的寫入以及腳本發處的事件，都將提交到全域狀態之中。
* 如果腳本執行失敗(例如：耗盡GAS)，則全域狀態將不會發生任何改變
6. 執行結語(Run epilogue)
* 虛擬機運行交易結束，向使用者收取GAS 費用，並增加交易發送人的帳戶序列號。
* 和prologue一樣，交易結尾也是LibraAccount模組中執行。並且是在禁用GAS的狀態下運行的。
* 如果執行步驟超過步驟2後發生失敗，則會運行Run epilogue。
* prologue 和 epilogue的執行將會確保所有交易都能收取到正確的GAS交易費。
* 若交易在步驟2後發生失敗，將不會被附加到帳本歷史紀錄中。
* 若是交易步驟超過2，代表帳戶內有足夠的Libra幣來支付交易允許的最大GAS數。即使在交易過程中耗盡了GAS，還是能夠以最好的金額收取到手續費。

### Move程式語言(The Move Programming Language)
* Move是Libra協議設計過程中創造的新程式語言，它是系統中三個重要角色：
1. 通過交易腳本使交易更加靈活。
2. 允許使用者定義代碼和資料類型，包括模組的「智能合約」。
3. 支持Libra協議的配置與一定程度的可擴展性。
* Move能夠自定義資源類型，資源可以儲存在資料結構中，做為參數傳遞給程式使用。
* Move中的資源將依系統的安全規定獲得保障，永遠不能複製資源，但可以移動資源。
* 在Move中只能由宣告該資源類型的模組才可以對其創建與銷毀。
* 保證安全的規則將是靜態(statically)並且於Move虛擬機中強制執行。

#### 撰寫Move程式
* Move 程式語言分為三個主要部分：
1. 原始碼
* 高階語言
* 目前正在設計中
2. 中間語言( intermediate representation IR)
* 撰寫事務腳本
* 開發模組
3. 位元組碼
* 原始碼與IR將會被轉換成位元組碼
* 雖然MOVE在編譯器層有許多的安全防護，在驗證節點完全信任編譯器的情況下，仍不能防禦被植入惡意代碼的位元組碼。因此，Libra協議將會驗證位元組碼是否符合合法性。

#### 交易腳本
* 交易腳本是Libra協議中的主要程序，透過交易腳本的加入，可以讓交易更加地靈活。
* 腳本可以呼叫使用分類帳底下的模組，或是執行邏輯條件或計算。這讓腳本可以有更複雜的操作，比如說支付Libar幣給予一組特定的收件人。
* 在交易腳本的構想上，預計大部分的腳本都將執行一個程序並且呼叫一個經過封裝的通用功能。例如：
>LibraAccount.pay_from_sender(recipient_address, amount)

將程序的傳入值設計為recipient_address與amount，這樣子的用法基本與乙太坊的transfer transaction相同。

#### 模組
* 模組是在分類帳狀態下所宣告的代碼單元。
* 使用者可以在模組下宣告「結構(struct)」，就像C語言的結構一樣，他是一組由基本型別所組成的自訂資料型別。
* 每個結構可以宣告為資源或非資源。但非資源的結構不可包含資源結構，也不能在帳本宣告。
* 「模組、結構、程序」三者的關係類似於物件導向中的「類別、物件、方法」。兩者最大的不同在於，模組可以宣告零或多個結構型別。並且，結構不可被除聲明模組以外存取(即模組不存在public特性)。
* 模組中的程序是靜態程序(static procedures)的而不是實例方法(instance methods)
* Move 中的模組與乙太坊的智能合約有相似的概念卻不完全相同。
1. 乙太坊智能合約包含代碼與資料；Move中模組代表代碼、資源包含資料。
2. 以物件導向的觀念來看，乙太坊的智能合約就像在單個帳戶地址下宣告單個物件；Move的模組就像是創建資源的配方(recipe)，它可以在不同的帳戶地址下宣告任意數量的資源。

#### 虛擬機
* 虛擬機是位元組組碼的驗證器及解釋器。
* 透過gotos和labels實現非結構化的流程控制。
* 開發人員利用Move IR 編寫交易腳本或模組後會執行：
* 編譯成Move位元組碼。
* 編譯會將結構化的流程控制(條件或迴圈)，轉換為非結構化的流程控制．
* 將複雜的表達式(complex expressions)轉換為運算元棧(operand stack)。
> 基本上處理方式與JVM相同。
> https://www.itread01.com/content/1548020907.html
* 支援少量的類型與值：布林、64-bit整數、256-bit 位置、固定大小的位元陣列、結構(包含資源)。
* 結構體中不能引用類型，這將導致分類帳狀態中儲存引用。
* 虛擬機中不存在堆積，區域數據將在stack分配，並在分配中的程序回傳後釋放。
* 持久性數據都將儲存在分類帳狀態中。

## 4 認證過的資料結構及儲存(Authenticated Data Structures and Storage)