Facebook幣Libra學習-2.交易生命週期

交易生命週期

爲了更加深刻的理解Libra的交易生命週期，咱們將跟隨一個交易的全過程，從其被提交到Libra validator始，直至其被添加到區塊鏈上止。咱們將「放大」來看每一個validator邏輯組件及與其餘組件之間的交互。

客戶端提交交易

Libra客戶端構造 原始交易 (此處稱爲T₅raw)，從Alice的帳戶中轉移10Libra幣到Bob的帳戶中。原始交易應包含如下字段：每一個字段都經過超連接關聯到詞彙定義表。

• Alice的帳戶地址.
• 一個代表Alice方將執行的操做的程序，包括:
  • 一個Move 點對點字節碼交易腳本.
  • 腳本輸入參數列表 (在這個例子中爲Bob的帳戶地址和付款金額等).
• Gas價格 (以microlibra/gas爲單位) — Alice願意爲執行本次交易所需的每單位Gas支付的價格。Gas用於支付區塊鏈上的計算和存儲費用。每一Gas單位是對計算量的抽象度量
• Alice願意爲爲這次交易支付的Gas上限
• 這次交易的有效期
• 序號 — 5
  • 序號爲5的交易，只能在包含5個交易的帳戶中發起。

客戶端使用Alice的私鑰對交易T₅raw 簽名 。簽名後的交易T₅ 包括下列內容：

• 原始交易
• Alice的公鑰
• Alice的數字簽名

交易前的假設

爲了描述交易T₅的生命週期, 咱們有以下假設:

• Alice和Bob在Libra區塊鏈上都擁有帳戶。
• Alice帳戶中有110Libra幣。
• Alice帳戶中當前的序列號 是5 (表示Alice的帳戶已經發送了5次交易).
• 網絡中共有100個validator—從 V₁ 到 V₁₀₀ 。
• 客戶端將交易T₅ 提交給validator V₁
• Validator V₁ 即爲本輪共識的倡議者或領導者

交易的生命週期

在本節中咱們將討論交易T₅的生命週期, 從其被提交到Libra validator始，直至其被添加到區塊鏈上止。

下圖展現了validator 節點相關組件之間的交互鏈的相關節點。在熟悉交易生命週期的全部步驟後，你能夠進一步瞭解各步驟中相應組件的交互信息。

注意:本圖標中的全部箭頭都起始於發起交互或操做的組件，終止於執行操做的組件。此處箭頭 不表示數據的讀取，寫入或返回。

FIGURE 1.1 交易生命週期

接收交易

1 — 客戶端將交易T₅ 提交給validator V₁ ，V₁ 的准入控制組件（AC）接受該交易。(客戶端 → AC AC.1)

2 — AC 利用虛擬機組件 (VM) 執行查驗，如簽名驗證，檢查Alice帳戶餘額是否充足，檢查交易V₁ 是否 被重複廣播等(AC → VM AC.2, VM.1)

3 — 當交易T₅ 經過查驗後， AC 將交易T₅ 發送到to V₁’的內存池(AC → 內存池 AC.3, MP.1)

發佈交易到其餘Validators

4 — 內存池將交易T₅ 保存在內存緩衝區中。內存池內可能已經包含了從Alice帳戶地址發送的多個交易。

5 — 利用內存池共享協議, V₁ 將發送其內存池中全部交易(包括交易T₅) 給其餘validator(V₂ to V₁₀₀) 並將從其餘validator接受到的交易存儲在自身的內存池中(Mempool →其餘 Validators MP.2)

交易區塊發起

6 — 做爲本輪共識發起者V₁ 將從其內存池中提取一個區塊，並經過共識組件複製分發給其餘的validator。(共識組件 → 內存池MP.3, CO.1)

7 — V₁ 的共識組件負責協調全部validator發送的區塊中交易的順序。(共識 → 其餘Validators CO.2).關於此處提出的共識協議LibraBFT,請參閱技術性文獻Libra區塊鏈中的狀態機複製

###區塊的執行和共識的達成

8 — 做爲共識達成過程的一個步驟，交易區塊(包括交易 T₅) 被提交給執行組件。(共識 → 執行CO.3, EX.1)

9 — 執行組件經過虛擬機(VM)管理交易的執行。應注意，此處的執行是在達成共識前的推測性執行。(執行→ VM EX.2, VM.3)

10 — 在上述執行完成後，執行組件將交易區塊將(包含T₅)附加到 (分佈式帳本的歷史)Merkle累加器 上，造成內存/臨時版本Merkle累加器。執行（發起和推測）交易的結果會返回到共識組件。(共識 → 執行CO.3, EX.1).從共識指向執行的箭頭表示該執行請求由共識組件發起。(爲了減小歧義，本文中將不使用箭頭表示數據流).

11 — （共識發起者）V₁ 試圖與其餘共識參與者，即其餘validator就該區塊的執行結果達成共識。(共識→ 其餘 Validators CO.3)

###區塊的提交

12 — 當對區塊的執行結果達成共識並簽名的validator數量上具備絕對優點時，V₁'的執行組件將從緩存中讀取區塊的推測性執行結果，並將區塊中的全部交易提交到永久存儲中。(共識 → 執行CO.4, EX.3), (Execution → Storage EX.4, ST.3)

13 — Alice帳戶如今的餘額爲100Libra幣，序列號爲6.如T₅ 被Bob重複廣播，該交易將被拒絕，由於Alice帳戶的序列號（6）大於被重複廣播的交易的序號（5）

Validator 組件交互

在上一部分中, 咱們舉例說明了一個典型的交易生命週期，從其被提交到Libra validator始，直至其被添加到區塊鏈上止。如今咱們將更加深刻的探究validator處理交易並響應請求時，組件間的交互。對下述人員，這些信息可能十分值得參考：

• 想要全面瞭解底層系統是如何運做的；
• 有興趣爲Libra Core軟件作出貢獻的

爲敘述方便，咱們假設客戶端提交一個交易T_N 給一個validatorV_X.對每一個validator組件，咱們將在其相對應子章節中具體描述組件之間的交互。此處應注意，用以描述組件間交互的子章節順序並未嚴格按照其執行順序。組件間的大部分交互都與交易的執行有關，少數與客戶端發出的（查詢區塊鏈上的已知信息）請求有關。

咱們先來看validator 節點的核心邏輯組件：

• 准入控制
• 內存池
• 共識
• 執行
• 虛擬機
• 存儲

每一小節結尾都附有Libra Core中的相應文檔。

准入控制(AC)

![Figure 1.2 准入控制(assets/illustrations/admission-control.svg) FIGURE 1.2 准入控制

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

客戶端→ AC (AC.1)

一個客戶端將交易提交給V_X的准入控制組件。此步驟經過: AC::SubmitTransaction()完成。

AC → VM (AC.2)

准入控制組件訪問validator的虛擬機並對交易進行預查驗，以便儘早拒絕格式錯誤的交易。此步驟VM::ValidateTransaction()完成。

AC → 內存池(AC.3)

一旦VM::ValidateTransaction() 沒有返回錯誤, AC 就經過Mempool::AddTransactionWithValidation().將交易轉發到V_X的內存池。當且僅當T_{N的序號大於或等於發送者帳戶的序號時，V}X_{的內存池纔會接受來自AC的交易T}N（注意：在交易序號和帳戶的下一個序號相等前，交易沒法達成共識）

AC → 存儲(AC.4)

當客戶端對Libra區塊鏈執行查詢時（例如獲取Alice帳戶餘額）。AC直接與存儲組件交互，以獲取所請求的信息。

准入控制文檔

更多實現細節，請參閱准入控制文檔。

##虛擬機(VM)

FIGURE 1.3 虛擬機

Move虛擬機 (VM) 驗證並執行Move字節碼編寫的腳本。

AC → VM (VM.1)

V_X的准入控制組件接收到交易請求時， 將調用虛擬機上的VM::ValidateTransaction() 程序驗證交易。

VM → 存儲 (VM.2)

當準入控制組件或內存池經過VM::ValidateTransaction(), 向虛擬機提交驗證交易請求時虛擬機加載存儲中保存的交易發起者帳戶，並執行如下驗證：

• 檢查交易中的簽名是否正確（並拒絕簽名錯誤的交易）；
• 驗證發起者的帳戶身份驗證密鑰是否與其（簽署交易私鑰對應的）公鑰的哈希值一致；
• 覈查交易的序號是否不小於發起者帳戶當前的序列號。 此檢查可防止發起者帳戶發出的交易被重複執行；
• 驗證簽名交易的程序代碼是否有格式錯誤，虛擬機沒法執行格式錯誤的程序代碼；
• 驗證發起者帳戶是否有充足的餘額支付專用於此交易的Gas上限，以確保交易有支付資源使用費的能力。

執行 → 虛擬機 (VM.3)

執行組件經過調用虛擬機的VM::ExecuteTransaction()函數執行交易。

此處應重點注意，執行交易不一樣於更新分佈式帳本狀態或存儲執行結果。首先，在共識期間，執行交易T_N 以得到區塊的共識。當與其餘validator就交易順序和執行結果達成共識後，執行結果才被永久存儲，分佈式帳本狀態也隨之更新。

內存池 → 虛擬機(VM.4)

當內存池經過其餘validator共享內存池接收到交易請求時，內存池隨即調用虛擬機上的VM::ValidateTransaction()來驗證交易

虛擬機README

更多實現細節，請參閱 虛擬機文檔.

內存池

FIGURE 1.4 內存池

內存池是一個共享緩衝區，用於保存等待執行的交易。當一筆新交易添加到內存池時，內存池與系統的其餘validator共享此交易。爲減小網絡消耗，在共享的內存池系統中，每一個validator僅負責傳遞本身的交易，當validator從其餘validator內存池發送的交易時，該交易將會被添加到接受者的內存池中。

AC → 內存池(MP.1)

• 執行初始查驗後，validator的准入控制組件將交易發送到其內存池；
• 當且晉檔收件人帳戶發來的交易T_N的序號大於或等於發件人帳戶的序列號時，V_X的內存池才接收此交易。

內存池→其餘Validators (MP.2)

• V_X 的內存池將交易T_N 共享給同一網絡中的其餘validator； *其餘validators將其內存池中的交易共享給 V_X的內存池；（即相互共享內存池中的交易）

###共識→內存池(MP.3)

• 當 V_X 爲共識發起者時，其共識組件將從其內存池中提取一個交易區塊並複製轉發給其餘validator，以就交易順序和交易結果達成共識。
• 此處注意，儘管T_N 此時在交易區塊中，但 T_N 並不必定最終能被永久存儲在區塊鏈的分佈式數據庫中。

內存池 → 虛擬機(MP.4)

當內存池接收到其餘validator發送的交易時，將在虛擬機上調用VM::ValidateTransaction()來驗證交易。

內存池README

更多實現細節，請參閱內存池文檔.

共識

FIGURE 1.5 共識

共識組件用於與網絡中參與共識協議其餘validator就交易區塊結果和順序達成共識

共識 → Mempool (CO.1)

當 V_X 爲交易發起者時 V_X 調用Mempool::GetBlock(), 從其內存池中提取交易區塊併發起提議。

共識→ 其餘Validators (CO.2)

若V_X 爲共識發起者，其共識組件將所提取的交易區塊複製轉發給其餘validator

共識 → 執行, 共識 → 其餘Validators (CO.3)

• 交易區塊內的執行要求共識和其餘組件進行交互。共識經過調用Execution:ExecuteBlock() (參考 共識 → 執行)執行交易；
• 區塊內的交易執行後，執行組件返回交易的執行結果； *共識簽署執行結果，並試圖與參與協商的其餘validator達成共識。

共識 → 執行(CO.4)

當對區塊的執行結果達成共識的validator數量上具備絕對優點時，V_X 的共識組件經過Execution::CommitBlock() 通知執行組件該交易塊已準備好被提交。

共識README

更多實現細節，請參閱共識README.

執行

FIGURE 1.6 執行

執行組件用於協調交易區塊的執行以及維持可供共識協商的瞬時狀態。

共識 → 執行(EX.1)

• 共識經過Execution::ExecuteBlock()請求執行組件執行交易區塊。
• 執行組件維護一個「暫存器」，該暫存器用以保存內存中Merkle 累加器相關部分的副本；此信息用以計算區塊鏈當前狀態的根哈希。
• 根哈希和區塊中交易信息共同肯定累加器的新根哈希。此步驟在永久保存新數據前執行，用以確保在得到共識前，全部交易或狀態都不被存儲。
• 執行組件計算推測性執行的根哈希後， V_X 的共識組件簽署並試圖就此根哈希與其餘validator達成共識。

執行 → 虛擬機(EX.2)

當共識組件調用Execution::ExecuteBlock()請求執行組件執行一個交易區塊時， 執行組件調用虛擬機肯定交易區塊的執行結果。

共識→ (EX.3)執行

當對區塊的執行結果達成共識的validator數量上具備絕對優點時，V_X 的共識組件經過Execution::CommitBlock() 通知執行組件該交易塊已準備好被提交。 此請求包含簽署共識的validator的簽名做爲其贊成共識的證實。

執行 → 存儲(EX.4)

執行組件從其暫存器提取值，並經過Storage::SaveTransactions()將值發送到存儲以進行永久保存。以後，執行組件會刪除無用值(如因重複沒法提交的區塊)。

執行README

更多實現細節，請參閱 執行README.

存儲

FIGURE 1.7 存儲

存儲組件用以永久性保存交易區塊及其執行結果。在下列狀況下，一個交易區塊/交易組(包括 T_N)將被永久保存：

• 網絡中超過2f+1的validators 就如下幾點達成共識：
  • 區塊中包含的交易；
  • 區塊中交易的順序；
  • 區塊中交易的執行結果。

有關如何將交易附加到區塊鏈上的數據結構信息，請參閱Merkle 累加器

虛擬機 →存儲(ST.1)

當準入控制或內存池調用VM::ValidateTransaction() 來驗證交易時，VM::ValidateTransaction() 加載存儲中的發送人帳戶，並經過只讀模式檢查交易的有效性。

執行 → 存儲(ST.2)

當共識組件調用Execution::ExecuteBlock(), 執行組件讀取當前狀態和內存中的暫存器數據來肯定執行結果。

執行 → 存儲(ST.3)

• 一旦交易共識達成，執行組件調用Storage::SaveTransactions() 來保存交易區塊並永久保存相關記錄。同時，網絡中籤署共識的validator的簽名也將被保存；
• 暫存器的內存數據將更新到存儲中並永久保存交易。
• 存儲更新後，全部參與交易的資源的序列號都會相應更新；
• 注意: Libra區塊鏈帳戶的序列號隨着交易數量等量增長。

AC → 存儲(ST.4)

當客戶方發送對區塊鏈中信息的查詢請求時，准入控制組件和存儲直接交互以讀取所相應信息。

存儲README

更多實現細節，請參閱 存儲README.

參考：

• Welcome page.
• Libra Protocol: Key Concepts — Introduces you to the fundamental concepts of the Libra protocol.
• My First Transaction — Guides you through executing your very first transaction on the Libra Blockchain using the Libra CLI client.
• Getting Started With Move — Introduces you to a new blockchain programming language called Move.
• Libra Core Overview — Provides the concept and implementation details of the Libra Core components through READMEs.
• CLI Guide — Lists the commands (and their usage) of the Libra CLI client.
• Libra Glossary — Provides a quick reference to Libra terminology.
• State Machine Replication in the Libra Blockchain — Provides a detailed look into our consensus protocol LibraBFT.

翻譯：Jadris Lau 校對：Zhe Wang

 

Libra國內開發者微信交流羣:

不能入羣請加管理微信，拉你進羣=>