Facebook libra開發者文檔- 3 -Life of a Transaction交易生命週期

Life of a Transaction交易的生命週期

https://developers.libra.org/docs/life-of-a-transaction

爲了更深刻地瞭解Libra交易的生命週期，咱們將跟蹤一個交易從提交給Libra驗證器到提交給Libra區塊鏈的過程。而後，咱們將「放大」驗證器的每一個邏輯組件，並查看它與其餘組件的交互。

Client Submits a Transaction用戶提交一個交易

Libra用戶構建了一個原始交易(咱們稱之爲T₅raw)，將10個Libra從Alice的賬戶轉移到Bob的賬戶。原始交易包括如下字段。每一個字段都連接到其術語表定義：

• Alice的賬戶地址（account address）。
• 一個程序，指示Alice要執行的操做。它包含:

1. 一個Move字節碼點對點的交易腳本（peer-to-peer transaction script）。
2. 腳本的輸入列表(例如，Bob的賬戶地址和付款金額)。

• Gas價格（Gas price，以microlibra/gas單位表示)——即Alice願意爲執行交易而支付的每單位gas的價格。gas是區塊鏈中支付計算和儲存費用的一種方式。gas單位是計算的抽象度量，沒有固有的實際價值。
• 最大gas數量（Maximum gas amount）—— Alice願意爲這筆交易支付的最高自然氣金額。
• 過時時間（Expiration time）——交易的過時時間。
• 序號（Sequence number）-這裏設置爲 5

1. 序列號爲5的交易只能應用於序列號爲5的賬戶。

客戶端使用Alice的私鑰簽署交易T₅raw。已簽署的交易T₅包括:

• 原始交易。
• Alice的公鑰。
• Alice的簽名。

 

Assumptions假設

爲了描述交易T₅的生命週期，咱們假設:

• Alice和Bob在Libra的區塊鏈上都有帳戶（ accounts）。
• Alice的帳戶上有110個Libra。
• Alice帳戶的當前序列號（ sequence number）爲5(表示已經從Alice帳戶發送了5個交易)。
• 總共有100個驗證器——網絡上從V₁到V₁₀₀。
• 客戶端將交易T₅提交給validator V₁
• Validator V₁是當前輪的提議者/領導者。

 

Lifecycle of the Transaction交易的生命週期

在本節中，咱們將描述交易T₅的生命週期，即從客戶端提交到提交到Libra區塊鏈的過程。

在相關的遵循了生命週期中編號的步驟地方，咱們提供了到驗證器節點的相應組件間交互的連接，以下圖所示。在你熟悉了交易生命週期中的全部步驟以後，你可能想要參考每一個步驟對應的組件間交互的信息。

注意⚠️: 本文檔中全部圖形中的箭頭都起源於發起交互/操做的組件，並終止於正在執行操做的組件。箭頭不表示讀取、寫入或返回的數據。

Accepting the Transaction接受一個交易

 1 -客戶端向validator V₁提交交易T₅, validator V₁的許可控制(AC)組件接收交易。(client→AC，AC.1)

2 - AC將使用虛擬機(VM)組件執行驗證檢查，如簽名驗證、檢查Alice的賬戶是否有足夠的餘額、檢查交易T₅是否正在重播等(AC→VM， AC.2, VM.1)

3 -當T₅經過驗證檢查時，AC將T₅發送到V₁的內存池mempool。(AC→Mempool ，AC.3, MP.1)

 

Sharing the Transaction With Other Validators與其餘驗證器共享該交易

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

5 -使用共享內存池mempool協議，V₁將與其餘驗證器(V₂到V₁₀₀)共享其mempool中的交易(包括T₅)，並將從其餘驗證器接收到的交易放入本身的mempool中。(Mempool→Other Validators ，MP.2)

 

Proposing the Block 提議執行的區塊

6 -因爲validator V₁是一個提議者/領導者，它將從它的mempool中提取一個交易塊（包含n筆交易），並經過它的consensus組件將這個交易塊做爲提議proposal複製到其餘驗證器。(Consensus→Mempool MP.3, CO.1)

7 - V₁的consensus部分負責協調全部驗證器之間關於proposed區塊中的交易的順序。(Consensus→Other ValidatorsCO.2)。有關咱們提議的共識協議LibraBFT的詳細信息，請參閱咱們在Libra區塊鏈中的技術論文狀態機複製（State Machine Replication in the Libra Blockchain）。

 

Executing the Block and Reaching Consensus執行區塊並達成共識

8 -做爲達成協議的一部分，交易塊(包含T₅)被傳遞給執行組件Execution。(Consensus→Execution CO.3, EX.1)

9 -執行組件Execution管理虛擬機(VM)中交易的執行。請注意，這種執行是在塊中的交易達成一致意見以前推測進行的。(Execution→VM ex2, VM.3)

10 -在執行塊中的交易以後，執行組件Execution將塊中的交易(包括T₅)附加到Merkle累加器(Merkle accumulator，帳本歷史記錄)。這是Merkle累加器的內存/臨時版本。執行這些交易的(提交的/推測的)結果返回給共識組件consensus。(Consensus→ExecutionCO.3, ex1)。

從「consensus」到「execution」的箭頭表示執行交易的請求是由consensus組件發出的。(爲了在整個文檔中一致地使用箭頭，咱們沒有使用箭頭來表示數據流)。

11 - V₁(共識領導者)試圖與其餘參與共識的驗證者就block的執行結果達成共識。(Consensus→Other Validators CO.3)

 

Committing the Block 提交區塊到區塊鏈

12 -若是塊的執行結果是被一系列驗證器的絕對多數選票贊成並簽名了的,驗證器V₁的執行組件Execution從推測執行緩存（speculative execution cache）中讀取區塊的執行結果，並提交區塊中的全部交易到持久性存儲（persistent storage）中。(Consensus→Execution CO.4, EX.3)，(執行→存儲ex4, ST.3)

13 -Alice的帳戶如今有100個天秤座，它的序號將是6，即下一個要執行的交易的序列號。若是Bob重播T₅，將被拒絕，由於Alice帳戶(6)的序列號大於重播交易(5)的序號。

 

Validator Component Interactions驗證器組件交互

在上一節中，咱們描述了一個示例交易的典型生命週期，從提交到提交到區塊鏈的分佈式數據庫。如今讓咱們更深刻地研究驗證器在處理交易和響應查詢時的組件間的交互。這些資料對下列人士最有用:

• 想要了解系統在幕後是如何工做的。
• 有興趣最終爲Libra的核心軟件作出貢獻。

在咱們的敘述中，咱們將假設客戶端向驗證器V_X提交一個交易T_N。對於每一個驗證器組件，咱們將在各自組件部分的子部分中描述其組件間的每一個交互。注意，描述組件間交互的子部分並無嚴格按照執行它們的順序列出。大多數交互與交易處理相關，少數與客戶機讀取查詢相關(查詢區塊鏈上的現有信息)。

讓咱們看看驗證器節點的核心邏輯組件:

• 許可控制Admission Control
• 內存池Mempool
• 共識組件Consensus
• 執行組件Execution
• 虛擬機Virtual Machine
• 存儲Storage

在每一個部分的最後，咱們提供了Libra核心（Libra Core）相應的「自述」連接。

 

Admission Control (AC)許可控制

許可控制是驗證器惟一的外部接口。客戶端向驗證器發出的任何請求都將首先到達AC。

Client → AC (AC.1)

客戶端向驗證器V_X的許可控制提交交易。這是經過: AC::SubmitTransaction()完成的。

AC → VM (AC.2)

許可控制訪問驗證器的虛擬機(VM)，對交易執行初步檢查，以便儘早拒絕格式不正確的交易。這是經過: VM::ValidateTransaction()完成的。

AC → Mempool (AC.3)

一旦 VM::ValidateTransaction()返回沒有錯誤，AC就經過 mempool::AddTransactionWithValidation() 將交易轉發給驗證器V_X的mempool。只有在T_N的序列號是大於或等於當前序列號發送方的帳戶中的序列號時，驗證器V_X的mempool纔會接受來自AC的交易T_N(注意，交易將不會經過共識,直到下一個序列號)。

AC → Storage (AC.4)

當客戶端對Libra區塊鏈執行讀查詢(例如，獲取Alice賬戶的餘額)時，AC直接與存儲組件交互，以得到請求的信息。

 

Admission Control README許可控制的自述

有關實現細節，請參閱Admission Control README。

 

 

Virtual Machine (VM)虛擬機

Move虛擬機(Move virtual machine，VM)驗證並執行用Move字節碼編寫的交易腳本。

AC → VM (VM.1)

當validator V_X的許可控制從客戶機接收交易時，它調用VM上的VM::ValidateTransaction()來驗證交易。

VM → Storage (VM.2)

當AC或mempool經過VM::ValidateTransaction()請求VM去驗證交易時，VM從存儲（storage）中加載交易發送方的賬戶，並執行如下驗證:

• 檢查已簽名交易上的輸入簽名是否正確(拒毫不正確簽名的交易)。
• 檢查發送方的賬戶身份驗證密鑰是否與公鑰的散列相同(對應於用於簽署交易的私鑰)。
• 驗證交易的序列號不小於發送方賬戶的當前序列號。執行此檢查可防止對發送方的賬戶重播相同的交易。
• 驗證已簽名交易中的程序program是否格式錯誤，由於格式錯誤的程序不能由VM執行。
• 驗證發送方賬戶中是否有足夠的餘額來支持交易中指定的最大gas量，從而確保交易能夠爲其使用的資源支付費用。

 

Execution → VM (VM.3)

執行組件Execution經過調用函數VM::ExecuteTransaction()去使用VM來執行交易。

重要的是要理解，執行交易不一樣於更新帳本的狀態和將結果保存在存儲中。首先執行一個在達成共識期間，做爲區塊達成協議嘗試的一部分的交易T_N。若是與其餘驗證器就交易的順序及其執行結果達成一致，則這些結果將保存在存儲器storage中，並更新帳本的狀態。

Mempool → VM (VM.4)

當mempool經過共享mempool從其餘驗證器中接收交易時，mempool調用VM上的VM::ValidateTransaction()來驗證交易。

VM README

有關實現細節，請參考Virtual Machine README。

 

Mempool內存池

Mempool是一個共享緩衝區，它保存「等待」執行的交易。當向mempool添加新交易時，mempool與系統中的其餘驗證器共享該交易。爲了減小「共享mempool」中的網絡消耗，每一個驗證器負責將本身的交易交付給其餘驗證器。當驗證器從另外一個驗證器的mempool接收交易時，該交易將添加到接收驗證器的mempool中。

AC → Mempool (MP.1)

• 執行初始驗證檢查後，驗證器的AC將交易發送到驗證器的mempool。
• 驗證器V_X的mempool僅在T_N的序列號大於或等於發送方賬戶的當前序列號時才接受發送方賬戶的交易T_N。

Mempool → Other Validators (MP.2)

• 驗證器V_X的mempool與同一網絡上的其餘驗證器共享交易T_N。
• 其餘驗證器與V_X的mempool共享其mempool中的交易。

Consensus → Mempool (MP.3)

• 當validator V_X成爲領導者時，它的共識組件consensus將從它的mempool中提取一個交易塊，並將這個交易塊複製到其餘驗證器。它這樣作是爲了就交易的順序和塊中交易的執行結果達成共識。

注意，僅僅由於一個交易T_N包含在一個協商一致塊中，它並不保證T_N最終會被持久化到區塊鏈的分佈式數據庫中，由於塊中有些出錯的交易會被丟棄。

Mempool → VM (MP.4)

當mempool從其餘驗證器接收交易時，mempool調用VM上的VM::ValidateTransaction()來驗證交易。

Mempool README

有關實現細節，請參考Mempool README。

 

Consensus共識

共識組件負責排序交易塊，並經過與網絡中的其餘驗證器參與共識（consensus protocol
）協議，就執行結果達成一致。

Consensus → Mempool (CO.1)

當驗證器V_X是領導者/提議者時，V_X的共識經過: mempool::GetBlock()從它的mempool中提取一個交易塊，並造成一個提議proposal。

Consensus → Other Validators (CO.2)

若是V_X是一個提議者/領導者，它的共識組件會將提議的交易塊複製到其餘驗證器。

Consensus → Execution, Consensus → Other Validators (CO.3)

• 要執行一個交易塊，consensus與執行組件Execution進行交互。共識組件經過Execution:ExecuteBlock()來執行一個交易塊(引用Consensus → Execution)
• 在執行塊中的交易以後，執行組件將執行這些交易的結果響應到共識組件。
• 共識組件對執行結果進行簽名，並試圖與參與共識的其餘驗證器就該結果達成一致協議。

Consensus → Execution (CO.4)

若是有足夠多的驗證器投票支持相同的執行結果，V_X的consensus組件將經過execution::CommitBlock()通知執行組件Execution，這個塊已經準備好提交到區塊鏈中。

Consensus README

有關實現細節，請參閱 Consensus README。

 

Execution執行組件

執行組件的工做是協調一個交易塊的執行，並維護一個能夠經過共識組件進行表決的臨時狀態。

Consensus → Execution (EX.1)

• Consensus組件經過調用函數execution::ExecuteBlock()請求執行組件Execution執行一個交易塊。
• 執行組件維護一個「暫存板scratchpad」，它在內存中保存Merkle累加器（Merkle accumulators）相關部分的副本。此信息用於計算區塊鏈當前狀態的根哈希。
• 當前狀態的根哈希值與塊中交易的信息相結合，以肯定累加器的新根哈希值。這是在持久化任何數據以前完成的，並確保在驗證器仲裁達成一致協議以前不會存儲任何狀態或交易。
• 執行組件計算推測的根哈希值，而後V_X一致對這個根哈希值進行簽名，並嘗試與其餘驗證器就這個根哈希值達成一致協議，即肯定該新狀態是正確的。

Execution → VM (EX.2)

當consensus組件經過調用函數execution::ExecuteBlock()請求執行組件Execution執行交易塊時，執行組件使用VM來肯定執行交易塊的結果。

 

Consensus → Execution (EX.3)

若是驗證器仲裁贊成塊執行結果，每一個驗證器的共識組件將經過調用execution::CommitBlock()通知其執行組件Execution該塊已準備提交。這個對執行組件Execution的調用將包括贊成驗證器的簽名，以提供其一致協議的證實。

Execution → Storage (EX.4)

執行組件從它的「暫存板scratchpad」中獲取值，並經過調用storage::SaveTransactions()將它們發送到存儲區storage以進行持久性存儲。而後執行組件從「暫存板」中刪除再也不須要的舊值(例如，不能提交的並行塊)。

Execution README

有關實現細節，請參閱Execution README。

 

Storage存儲

 

存儲組件保存商定的交易塊及其執行結果。當下列狀況發生時，一塊/組的交易(包括交易T_N)會被存儲到storage中:

• 數量超過2f+1的驗證器就下列各項達成協議:

1. 要包含在塊中的交易。
2. 交易的順序。
3. 要包含在塊中的交易的執行結果。

有關如何將交易附加到表示區塊鏈的數據結構的信息，請參閱Merkle accumulators。

VM → Storage (ST.1)

當AC或mempool調用VM::ValidateTransaction()來驗證交易時，VM::ValidateTransaction()從存儲組件storage中加載發送方的賬戶，並對交易執行只讀有效性檢查。

Execution → Storage (ST.2)

當共識組件調用Execution::ExecuteBlock()時，執行將從存儲組件和內存中的「暫存板」數據中讀取當前狀態，以肯定執行結果。

 

Execution → Storage (ST.3)

• 一旦對交易塊達成共識，執行組件就經過storage::SaveTransactions()調用storage組件來保存交易塊並永久記錄它們。這還將存儲來自贊成此交易塊的驗證器節點的簽名。
• 該區塊的「暫存板」中的內存數據被傳遞到更新的存儲組件中並保存交易。
• 更新存儲組件時，每一個交易修改的全部資源的序列號將相應地更新。
• 注意:Libra區塊鏈上的賬戶序列號對來自該賬戶的每一個提交交易遞增1。

 

AC → Storage (ST.4)

對於從區塊鏈中讀取信息的客戶機查詢，AC直接與存儲組件交互來讀取請求的信息。

Storage README

有關實現細節，請參閱Storage README。