翻譯 - Proof of Previous Transactions (PoPT): An Efficient Approach to Consensus for JCLedger

Proof of Previous Transactions (PoPT): An Efficient Approach to Consensus for JCLedger

Abstract

JCLedger 是基於區塊鏈的分佈式賬本，用於 JointCloud，可以提高不同雲之間交換資源的可靠性和便利性。其實現最大的挑戰是共識機制。現存的共識機制，如：PoW 和 Pos，需要大量的計算資源，且低吞吐量並伴有壟斷的風險。

本文提出基於 PBFT 的共識算法 proof of previous transactions(POPT)，記賬人由特殊的 hash 算法從確定數量的候選人中獲得。獲選人來自參與 JointCloud POPT 共識過程的用戶。同時，本文針對並行計算提出了新的區塊鏈結構，用於提高 JCLedger 的吞吐規模。提出一致性共識算法爲不同記賬人分配交易。模擬實驗表明 PoPT 爲不同算力的用戶提供了同等的記賬機會，並行記賬可以使 JointCloud 中大規模和高頻交易處理更有效。

1. INTRODUCTION

JointCloud 是新一代雲計算模型，允許多雲服務提供商(CSPs)跨雲進行合作，促進小中型企業成爲雲服務顧客（CSCs）。

爲了讓 JointCloud 中雲資源和價值交換更可信和便利，前人提出了 JCLedger，一個基於區塊鏈的分佈式賬本。

共識算法從所有用戶/節點中爲每個區塊選擇記賬人。賬本/區塊鏈由記賬人打包的區塊組成。

記賬人選擇的兩條基本原則（爲 JCLedger 設計共識算法的核心要素）：

1. 選擇過程不能由少數人控制（不超過一半）

2. 選擇結果是不可預測的

JointCloud 中參與者包括 cloud services brokers（CSBs），CSCs，和 CSPs。

在滿足共識算法的基礎需求外，我們需要以下完成以下約束：

1. 避免浪費算力

2. 爲不同算力的用戶提供同等記賬的機會

3. 記賬激勵更合理

4. 處理大規模和高頻交易

之前，我們爲 JCLedger 提出過基於 POW 的共識算法 PoPF。本文我們提出另一個共識算法 proof of previous transaction（PoPT），滿足以上約束，且更適合 JointCloud。PoPT 基於 PBFT，比 PoPf 更高效。PoPF 使用哈希函數從獲選人中選擇記賬人，用新鏈結構進行並行記賬。

2. BACKGROUND AND RELATED WORK

除了滿足區塊鏈中共識算法的基本需求外，我們希望共識算法可以使系統更有效。讓系統更有效的主要因素是記賬人。記賬人的工作是打包區塊，包括在廣播區塊前收集和驗證交易。交易的驗證包括髮送人簽名的驗證，以及是否同其它交易衝突。區塊鏈系統的效率主要取決於記賬交易的處理速度。

3. DESIGN OF POPT

每個區塊記賬人根據用戶的排名選取，排名取決於用戶參與前一個交易的情況。

本章節包括：鏈結構，爲每個區塊確定區塊數量，記賬人選取，交易分配，區塊打包與驗證，基於 PBFT 的共識過程

3.1 Chain Structure

區塊鏈由區塊高度組成。不同區塊高度可能有不同區塊數。同一區塊高度的區塊有同樣的區塊頭，區塊頭是上一個區塊高度的哈希值。記賬人爲同一區塊高度並行打包區塊。同一區塊高度中的區塊排序取決於記賬人 id 的哈希值。同一區塊高度的區塊組成一個大區快。

3.2 Number of Blocks for Each Block Height

一個區塊對應一個記賬人，每個區塊高度的區塊數量等於記賬人的數量。由於交易數量會動態變化，所以不同區塊高度有不同區塊數量。儘管無法準確估計交易數量，但是我們可以可以通過前一個區塊高度分析趨勢，確定即將到來的區塊高度需要多少記賬人。

針對交易數量設置兩個值：$m_l$ 表示下限，$m_u$ 即上限。假設 n 是區塊中交易的數量，那麼規則爲：

1. n < $m_l$: 下一個區塊高度減少一個記賬人

2. n > $m_u$ ： 下一個區塊高度增加一個記賬人

3.3 記賬人選擇

1. $R(x)$: 用戶/結點 $x$ 排名

2. $F(x)$: 從上次成爲記賬人以來，用戶/結點 $x$ 支付的費用

3. $M(x)$: 用戶/結點 $x$ 成爲記賬人的次數

4. $hash(x)$: 字符串 $x$ 的哈希值

5. $cur\_header$: 當前 big-block’s header 的哈希值

6. $str\_id_i$: 候選 $i$ 的 id（public key）

哈希函數 $hash(x + y)$ 中 “$+$” 表示字符串 $x$ 和 $y$ 的連接。這裏存在兩種類型的結點：普通結點和記賬結點。記賬結點需要存儲整個賬本。對於記賬結點，$F(x)$ 和 $M(x)$ 可以根據歷史數據簡單計算出。每個用戶的排名由下面公式計算：

$R(x)=\frac{F(x)}{M(x)+1}$

從該排名中將分數最高的 $n$ 個用戶設爲記賬候選人。假設當前區塊高度需要 $k$ 個記賬人，下面公式描述如何通過一個哈希函數從候選人中選擇 $k$ 個記賬人：

$h_{standard}=hash(cur\_header+str\_id_1+str\_id_2+...+str\_id_n)$

$h_{id}(i)=|hash(str\_id_i+R(i))-h\_{standard}|.$

最小的 $k$ $h_{id}(i)s$ 一旦被發現，對應的候選人將成爲記賬人。一旦候選 $x$ 成爲記賬人，我們設置 $F(x)=0$ 和 $M(x)=M(x)+1，這將致使 $R(x)=0$。因此 $x$ 將無法成爲候選人，直到他支付足夠的費用。該規則有效保證候選人輪詢，避免持續記賬。

3.4 Assignment of Transactions

交易通過一致性哈希算法分配給不同記賬人/區塊。分配分爲三步：

1. Hash Circle: 記賬人和交易被映射到一個值空間，在該值空間中可以行程一個首尾圓。SHA256 是映射用的哈希算法，保證值空間範圍從 $0$ - $2^{256}-1$

2. Map Accountants and Transactions to the Hash Circle: 函數值表示位於哈希圈中的位置。對記賬人，記賬人 id 和當前區塊高度是函數的參數。此外，函數參數是交易交易發送人的 id。映射函數保證，在同一高度，來自同一發送人的交易將被分配給同一記賬人。因此，雙花問題得以避免。

3. Map Transactions to Accountants: 根據哈希圈的位置，交易分配給據它順時針最近的記賬人。記賬人只能處理映射給它的交易。

圖四是交易分配的例子。虛擬結點用於避免不平衡分配問題。

3.5 區塊打包和驗證

在交易打包進區塊之前需要驗證，發送賬戶餘額以及簽名。一個區塊中交易數量是有限的。記賬人必須及時打包和廣播區魯哀，否者無法通過驗證，將被丟棄。

當用戶收到一個區塊，在添加區塊當賬本之前，需要先驗證區塊的合法性。驗證分 7 步。

1. 發送者是否是記賬人身份

2. 記賬人簽名是否正確

3. 根據分配規則判斷區塊中的交易是否屬於記賬人

4. block-header 是否是上一個區塊高度的 big-block 哈希值

5. 區塊中的所有交易是否合法

6. 交易的數量是否超出限制

7. 區塊廣播到達時間是否超出限制

如果區塊通過驗證，添加區塊至分佈式賬本中，否者丟棄，並廣播消息，取消打包區塊記賬人身份。我們將在之後討論如何處理無效記賬人。

3.6 PBFT_Based Consensus Process

BPFT 是容忍拜占庭錯誤的 replication 算法，可以處理 $1/3$ 惡意拜占庭 replicas。view 中選擇的 primary 負責將請求多播到其他 replicas。對 JCLedger 來說，候選人代表 replica， 區塊高度代表 view，記賬人代表 primary(關於 primary、view、和replica 的介紹可以參考：PBFT實用拜占庭容錯算法深入詳解)。圖 5 表示 JCLedger 中 PBFT 的用法：

假設候選人（包括記賬人）數量是 $n$，最大惡意拜占庭副本數是 $f$，那麼$f=(n-1)/3$。所有誠實結點將廣播合法區塊。如果一個誠實結點確定記賬人無效，那麼所有其它誠實結點都會認爲該記賬結點無效。所有誠實結點所做的決定都是相同的。當結點從其它 $f+1$ 個不同結點接受到同一消息，它可以確定該消息來自誠實結點，因爲惡意拜占庭結點數不超過 $f$。這裏的消息代表一個區塊或者是無效記賬人的判斷結果。

基於 PBFT 共識過程如圖 6. 記賬人向全網廣播打包好的區塊，然後獲選人驗證區塊並向其它候選人廣播驗證結果：如果候選人在約定的時間內收到 $f+1$ 個結論宣稱區塊有效，它可以向全網發送 commit。；否者，它發送消息宣稱記賬人無效。在接收到 $f+1$ 個 commit 之後，所有用戶將添加區塊至它們的 JCLedger 中，並宣稱區塊有效。記賬人無效存在兩種情況：

1. 廣播的區塊被證實非法

2. 存在來自同一記賬人的兩個不同合法區塊（不同區塊可能來自雙花問題）。

如果有結點確定記賬人無效，它們可以丟棄來自無效記賬人的區塊並全網廣播。無效記賬人將被懲罰（剝奪記賬權力和清空財產），已分配給它的交易將再下一個區塊高度被處理。惡意拜占庭候選人可以只廣播虛假 commit，但是它起不了任何作用，因爲數量不超過 $f$。PoPT 是由 PBFT、記賬人選取、交易分配組成的混合協議。根據算法，記賬人選取和交易分配是本地處理的兩步。結點計算誰將成爲記賬人，並且根據它們持有的區塊鏈分配交易，而不需要任何網絡通信。如果兩個結點擁有同樣的數據，他們將計算獲得同樣的結果，包括記賬人和交易分配方案。因此不需要考慮這兩個步驟上的網絡攻擊（DDos 或者 poor network latency）。PoPT 中的網絡攻擊可以被防禦，因爲在假設下 PBFT 是安全的，這一點將在 Section V 討論。儘管 PBFT 模型容易收到 Sybil 攻擊（單節點可以創建或者操縱網絡中大量身份，威脅網絡），但是 PoPT 中 Sybil 攻擊無法成功。這是因爲結點在成爲記賬候選人之前需要支付足夠的 fees。

根據我們的設計，每一個區塊高度至少存在 4 個候選人。儘管每個區塊都需要 PBFT 共識過程，但是產生一個區塊高度的時間與並行執行的的區塊數量不成正比。與傳統鏈結構相比，吞吐量將增加。

4. SIMULATION EXPERIMENTS

JCLedger 中模擬了 250 個區塊高度的生成。實驗中，記賬結點數 250，隨機彼此發送交易。記賬候選人 50，區塊中最大交易數 200， $m_l=50$，$m_u=150$ 。每個區塊高度，我們爲每個結點生成三個隨機數來決定它們的行爲。詳細見表 1

模擬實驗開始之前，沒有歷史數據。我們爲每個結點隨機設置 $F(x)$ 和 $M(x)$，第一個區塊高度的記賬人數設爲 6。

4.1 記賬人分佈

根據設計，PoPT 可以爲不同算力的參與者提供同等記賬的權利，確保記賬分配更加合理。用戶支付費用和成爲記賬人的次數決定用戶是否成爲記賬候選人。對候選人來說，成爲記賬人是完成隨機的。圖 7 表示每個用戶/結點支付的費用總和和初始 $R(x)$ 值。圖 8 表示每個用戶在 250 個區塊高度分別成爲記賬人和候選人的次數。

大多數用戶成爲記賬人的次數爲 3 - 10。兩個用戶 3 次成爲記賬人。9 個用戶 10 次成爲記賬人。一旦用戶成爲候選人，存在兩種情況：成爲記賬人，或者被其它 50 個用戶超越排名。

圖 9 表示 250 個區塊高度中記賬人分佈情況。所有用戶都有平等記賬的機會，意味着 PoPT 解決了不平等算力問題，提供合理的物質激勵。此外，選取過程由所有參與者操縱，結果不可預測。

4.2 Omnet++ for Network Simulation

Objective Modular Network Testbed in C++ (Omnet++) 是由 C++ 模擬庫和框架組成的模塊，最初用於構建網絡模擬。當前場景中，Omnet++ 用於模擬 PBFT 三階段並行處理。根據實驗設定，公式過程中存在 50 個候選人。我們分別爲區塊高度設置區塊/記賬人數量（1 - 50）。假設模擬中拜占庭容錯參與者不超過 $f(f=(50-1)/3)，因爲我們的目的是當系統運行正常時分析並行記賬的不同之處。最後一個參與者達成共識的時間即系統達成共識的時間。

第一個網絡模擬中，發送消息的網絡延遲範圍隨機在 50 - 100 ms，拜占庭容錯參與者數量設爲 16，意味結着點在做出決定之前需要收到超過 33 個 commits。如圖10，當區塊高度中去快數小於 10，區塊數越多，區塊高度所需時間越多，區塊達成共識的時間越少。區塊數超過 10 ，效果相反。

第二個網絡模擬中，隨機發送消息的網絡延遲在 100 - 200. 拜占庭容錯參與者數量也設爲 16。圖 11 表明，轉折點從最初的 10 變爲 12. 雖然 PBFT 需要考慮網絡資源確認區塊或者改變記賬人，但是，如果並行規模根據網絡延遲合理設置，並行記賬可以降低區塊達成共識的平均時間。

上面實驗說明，當拜占庭容錯參與者數量爲 $f$ 時，區塊高度達成共識所需時間的最糟情況。然後，如果 JointCloud 中不存在拜占庭容錯參與者，結點在做決定前只需要收到 17 個 commit，這縮短了達成共識的時間。圖 12 表示在網絡延遲爲 100 - 200 時，最好和最壞情形的對比。如果拜占庭容錯參與者數量不超過 $f$，區塊和區塊高度達成共識的時間沒有大的區別。

總結：

1. 模擬實驗 A 證明 PoPT 可以爲不平等算力之間提供平等的記賬權力，同時提供合理的激勵分配。

2. 模擬實驗 B 證明，如果並行規模可以根據真實系統合理設置，並行計算可以提高系統性能。

5. DISCUSSION AND FUTURE WORK

5.1 Security Assumptions

正如 PBFT，假設存在 n 個結點，2/3 以上是誠實結點，少於 1/3 非誠實（長時間存在下線結點或者產生分叉）。假設非對稱算法對數字簽名是安全的，簽名無法被僞造。此外，hash 函數是安全的，hash 衝突不會發生。假設網絡是“部分同步的”，這意味着消息延遲 $d(t) 不會無限比 $t$ 增長的更快。

5.2 Tamper Block

PoPT 中，選擇第一批記賬人，記賬人開始打包區塊，意味着攻擊者無法篡改一個不是由他打包的區塊，除非該攻擊者擁有記賬人的私鑰。此外，篡改一個區塊意味着需要篡改該鏈的所有其它已有的區塊，所以攻擊者需要有所有用戶的私鑰。如果攻擊者有所有私鑰，那麼他可以肆意花費這些用戶中的所有錢，而不是篡改區塊。最糟的情況是攻擊者成功篡改了一個區塊，但是也沒有用，因爲網絡中出現來自同一用戶的兩個區塊，該區塊將被認定爲非法，被丟棄。

5.3 Where the Crypto-Currency Comes From?

crypto-currency provider (CCP) 提供和回收 在 JointCloud 中流通的 crypto-currency/coins，並且承擔 coins 價值證明。CPSs 和 CSCs 可以用流通貨幣（Chinese Yuan 或者 U.S. Dollars）從 CCP 購買 coins，或者使用 coins 兌換法幣。購買和兌換是 JCLedger 中兩種特殊交易類型。此外，CCP 提供超過一種類型的 ctypto-currency，JCLedger 支持 multictypto-currency 流通。圖 13 表示 JointCloud 中三種主要參與者。

5.4 Computing Power

PoPT 基於 PBFT，這意味着我們不需要大量算力挖礦達成共識。PoPT 中，計算資源主要用於計算 $R(x)$，驗證區塊和交易。任何 PC 或者手機都可用，因此消除了不同算力的問題。

5.5 Future Directions

未來工作主要關注 PoPT 應用、 JCLedger 實現、智能合約。結合並行記賬、off-chain micropayment channels和分片技術解決大規模問題。區塊大小和間隔是區塊鏈設計中兩個重要的參數，需要結合系統實際狀態動態調整。可以引入深度學習調整這兩個參數。引入側鏈技術完成跨鏈交換。

6. CONCLUSION

本文，提出基於 PBFT 共識算法 PoPT，用於 JointCloud 中分佈式賬本進行並行記賬。PoPT 中，記賬人選取來自確定數量的候選人，候選人根據用戶排名選取。排名由用戶參與前一個交易計算獲取（包括用戶支付的費用和成爲記賬人的次數）。隨着系統交易的增加，排名持續發生變化，導致記賬候選人動態變化，中心化危險得以避免。使用 hash 函數從候選人中選取記賬人可以節約算力。爲了解決大規模問題，提出並行記賬，不同於 micropayment channels 和分片。機型計算意味着並行選取超過一個記賬人處理交易。設計新 區塊鏈結構用於並行記賬。新結構中，多個區塊在每個區塊高度同時添加到區塊鏈中。交易通過一致性哈希算法分配給不同記賬人/區塊，使用虛擬結點避免不平衡分配。因爲 JointCloud 中交易數量不穩定，每個區塊高度的區塊數量需要動態調整。我們根據歷史數據預測交易數量，判斷下一個區塊高度需要多少區塊。需要注意的是，並行記賬和 micropayment channels 以及分片技術並不衝突，這三種技術均可以同時解決大規模問題。