共識機制EPOA實現(xiàn)基于BFT變種的異步算法

2019-07-19 09:41:21 來源：區(qū)塊網(wǎng)

隨著比特幣的成功，區(qū)塊鏈的概念慢慢得到了普及和?眾的認可。去中心化、不可篡改、改變生產(chǎn)關系，拋開這些區(qū)塊鏈想要實現(xiàn)的美好愿景，?今

隨著比特幣的成功，區(qū)塊鏈的概念慢慢得到了普及和?眾的認可。去中心化、不可篡改、改變生產(chǎn)關系，拋開這些區(qū)塊鏈想要實現(xiàn)的美好愿景，?今卻少見一款產(chǎn)生實際價值的基于區(qū)塊鏈技術的商用級別應用落地。我們認為除了針對可擴展性(scalability)，?效率(efficiency), 易于拓展(expansibility)等已知的技術缺陷做攻關，更應該做的是從理念(Philosophy)層?，重新審視區(qū)塊鏈的定位和實施路線。

目前普遍把區(qū)塊鏈技術類比為 tpc/ip 協(xié)議這種普適性的基礎協(xié)議或網(wǎng)絡，這種理念和策略使得眼花繚亂的區(qū)塊鏈技術層出不窮，?多數(shù)似乎也更加學術化，但相互之間卻又沒有本質(zhì)的區(qū)別，更為重要的是它們距離商用化的目標好像也越來越遠。

我們的理念是從業(yè)務出發(fā)，技術服務于業(yè)務，而不是反其道而行之，為了打造具備實際運營能力的區(qū)塊鏈應用系統(tǒng)，我們專注在下列問題：

• 區(qū)塊鏈能給哪些行業(yè)帶來創(chuàng)新和增值?

• 為了達到上述目標，區(qū)塊鏈應用系統(tǒng)應該如何搭建?

通過針對上述問題的細致的考察和思考，本?試著描述一個叫做GrayEagle 的通用區(qū)塊鏈架構和一個基于 GrayEagle 的開放式游戲平臺，叫做 EqualBets。我們意在指明一個路線和方法，并詳細闡述為什么這個方法是可合理的，并為目前正在進行的開發(fā)提供盡可能多的參考細節(jié)。

GrayEagle 區(qū)塊鏈基礎框架(infrastructure)

在本章中我們主要描述 GrayEagle 的三個主要特點：

• EPOA( Electing Proof Of Authority)：基于選舉式權威證明的治理模式

• 雙層架構: 治理層和業(yè)務層

• 模塊化和可插拔的技術目標和路線

本章分別闡述 EPOA 機制的具體設計、分層網(wǎng)絡的協(xié)作機制和具體的技術架構路線。其中 EPOA 是 GrayEagle 團隊經(jīng)過研究實踐提出的區(qū)塊鏈共識機制，1. 節(jié)會從模型設計和共識算法兩個?度對 EPOA 進行詳盡描述; 2. 節(jié)會著重描述 GrayEagle 的關鍵特性分層網(wǎng)絡;最后在3. 節(jié)，我們將具體的技術實施路線盡可能描述清楚。

1. EPOA

在本章中我們主要描述繼 POW 之后，多種區(qū)塊鏈的共識機制相繼被提出并應用，比較典型的有：

(1)pow 及其改造機制。

(2)pos 以及基于 pos 的一系列改造機制。例如 npos，Dpos 等

(3)poa(Proof of authority)

(4)BFT 變種，例如 PBFT, Graph BFT 等

在業(yè)內(nèi)，使用不同的共識機制往往就限定了區(qū)塊鏈的使用范圍，使用(1)(2)共識機制會被定義為“公鏈”，而使用了(3)(4)機制的會被定義為聯(lián)盟鏈。其中機制(3)由于需要 authority 存在，必然限制了成為公鏈的可能，而機制(4)是因為當共識節(jié)點超過一定數(shù)量之后算法性能的陡然下降限制了成為公鏈的可能。

而我們認為區(qū)塊鏈不應該以某種方式分類為公鏈還是聯(lián)盟鏈，我們更希望看到的是有準?機制、選舉機制的公鏈，既滿?去中心化的特性，又可以真正達成商業(yè)化目標。因此我們提出了一種新的共識機制——EPOA。

如下圖 1 所?，在 EPOA 中存在三種不同的?? authority(權威節(jié)點)，recorder(記賬節(jié)點)，citizen(普通公民節(jié)點)。

1.1 Authority

Authority 是權威節(jié)點，類似于現(xiàn)實世界中的政府內(nèi)閣成員，它們最初由我們團隊??的少量節(jié)點擔任，并在主網(wǎng)上線后陸續(xù)邀請通過認證的監(jiān)管機構、合作實體公司成為 Authority。Authority 擁有執(zhí)政權，即除了可以參與出塊記賬外，還有權利審批游戲鏈節(jié)點的加?，莊家的申請，游戲開發(fā)者發(fā)布游戲的申請，隨機數(shù)種?生成等等。但Authority 并不都是由這種方式產(chǎn)生的，還有?量的 Authority 位置可以從 recorder 選舉出來，只要滿?條件：

(1)擁有?夠的 token 抵押。

(2)獲得?多數(shù) citizen 節(jié)點的選票。

(3)在?為 recorder 期間，擁有良好的服務記錄。

這種 Authority 我們稱之為 Elected Authority，它們會以類似于 pos 的方式進行?作，并獲得幣齡獎勵。recorder 成為 Authority 的過程對應圖 1中的動作 C。

1.2 Recorder

Recorder 是記錄節(jié)點，他們會參與出塊記賬，但沒有特殊的職權，因此任何一個 citizen 只要滿?如下條件就可以成為 Recorder：

(1)有提供穩(wěn)定服務的計算能力

(2)有?夠多的 token 抵押

(3)獲得 Authority 批準

(4)擁有賬本的完整信息。

成為 Recorder，不僅僅可以以類似 pos 的方式獲得幣齡獎勵，還有機會在定期的選舉中，成為 Authority。

1.3 Citizen

Citizen 是普通公民節(jié)點，可以同步賬本信息，但不要求計算能力和擁有完整賬本信息，Citizen 擁有三個重要的權利：

(1)舉報權，他們可以在發(fā)現(xiàn) Authority 或 Recorder 存在?法行為時(注：?法行為待列舉)向 Authority 團體舉報，一旦舉報通過，會以一種舉報獎勵機制獲得 token 獎勵。(獎勵 token從被舉報節(jié)點的懲罰 token 中分出，一部分懲罰 token 用于獎勵舉報者，剩余部分懲罰 token 直接燒毀)。這個過程對應圖1 動作 D。

(2)選舉權

可以在選舉期參與 Authority 的選舉投票。

(3)成為 Recorder

Citizen 可以向 Authority 申請成為 Recorder，只要滿?成為Recorder 的條件即可，這個過程對應圖 1 動作 B。為了防??巫攻擊，成為 Citizen 業(yè)務要提交少量的 token 作為押金。所以當一個節(jié)點 N 期望執(zhí)行動作 A 加?到 EPOA 網(wǎng)絡中時，它?先需要成為 Citizen。

1.4 小結

可以發(fā)現(xiàn)這種設計類似于現(xiàn)實世界中的社會運行機制，議會-公務員-公民，監(jiān)管機構和合作企業(yè)常任 Authority，同時任何個體都有機會成為Authority。這種設計很好的兼顧了去中心化和商用性。

更為底層的共識算法，我們已經(jīng)實現(xiàn)了一種基于 BFT 變種的異步算法。我們后續(xù)會逐步將共識算法模塊插件化。更多的細節(jié)不再本文討論范圍。

2. 雙層架構

GrayEagle基礎架構實現(xiàn)了2層區(qū)塊鏈：治理層和業(yè)務層

(1)治理層

治理層負責EPOA機制，從業(yè)務和監(jiān)管?度確保業(yè)務層的正常運行。具體而?，該層提供對監(jiān)管機構的開放訪問，包括節(jié)點設置和特定監(jiān)管合同部署; 業(yè)務層?的審計和驗證功能由部署在治理層的智能合約實施。

(2) 業(yè)務層

業(yè)務層專注于實現(xiàn)業(yè)務邏輯并與管理層交互以完成業(yè)務操作。雙層體系結構為開發(fā)區(qū)塊鏈業(yè)務系統(tǒng)提供了一種一般范式。雙層體系結構背后的理念是區(qū)分業(yè)務邏輯和治理需求，并在各?的層上運行。在這種架構中，每層都是去中心化的并具有特定共識機制，并且通過層間通信機制相互協(xié)調(diào)。

3. 技術架構摘要

GrayEagle 的具體技術實施思路之一是盡可能時將功能插件化，如圖 2所?，其中部分已經(jīng)實現(xiàn)，部分有待于在后續(xù)?作中完成，整體規(guī)劃不變，部分細節(jié)可能會在研發(fā)進程中不斷調(diào)整。

3.1 基礎組件

Crypto：加密學密碼組件，主要包含基本 hash 運算、秘鑰生成算法、加解密算法、簽名驗簽算法等。完成系統(tǒng)內(nèi)部數(shù)據(jù)的 hash 摘要、數(shù)據(jù)的簽名驗簽、秘鑰的生成等。

Network：主要實現(xiàn)基本的網(wǎng)絡庫能力，包含但不限于 Endpoint 管理、網(wǎng)絡參數(shù)設置、網(wǎng)絡監(jiān)聽、網(wǎng)絡連接建?、網(wǎng)絡消息回調(diào)等。

RocksDB：對本地物理磁盤數(shù)據(jù)的 NoSQL 存儲引擎，提供基本的?向Key-Value 的?效數(shù)據(jù)讀寫能力?，F(xiàn)階段的主要選型基于 RocksDB 來實現(xiàn)，隨技術的演進可以做更?效和?容量的存儲方案替換。

MPT：系統(tǒng)數(shù)據(jù)一致性校驗的基礎組件，通過樹形結構完成對數(shù)據(jù)集中的數(shù)據(jù)兩兩 hash 迭代運算，直?計算出一個唯一的 hash 值來完成對數(shù)據(jù)集內(nèi)容的一致性校驗，并可基于 MPT 的分支路徑快速的驗證特定的數(shù)據(jù)內(nèi)容在數(shù)據(jù)集合中的存在性，成為了?向區(qū)塊鏈的輕客戶端的快速數(shù)據(jù)校驗算法。也可以應用于區(qū)塊鏈內(nèi)部節(jié)點間針對世界狀態(tài)的數(shù)據(jù)一致性檢測算法。

RLP：系統(tǒng)內(nèi)部針對數(shù)據(jù)結構的編解碼能力，通過流式的方式進行數(shù)據(jù)緊湊編碼，完成網(wǎng)絡字節(jié)序轉(zhuǎn)換和基本數(shù)據(jù)類型的合法性校驗。支持循環(huán)嵌套的方式完成復雜容器結構的數(shù)據(jù)編碼能力。

Logging：系統(tǒng)的?志庫，通過基本的 API 封裝開源系統(tǒng)的?志組件，提供多級別的?志記錄能力，同時可以設置不同組件的?志前綴，調(diào)整不同組件的分組?志。計劃加?針對特定的交易或者賬戶的 Trace 能力。

Configuration：用于系統(tǒng)內(nèi)部的配置文件解析和配置信息管理的邏輯處理對象。提供 ini 文件格式的配置信息解讀。

Utils：系統(tǒng)內(nèi)部的一些?具集，提供一些基本的格式轉(zhuǎn)換、格式校驗、基礎功能函數(shù)等的相關能力。以及系統(tǒng)內(nèi)部的一些基本宏定義和常量參數(shù)等。

3.2 緩存插件

Transaction Queue：實現(xiàn)系統(tǒng)接收到交易信息(來源于客戶端的交易請求和 P2P 網(wǎng)絡的交易?播)的緩存，實現(xiàn)對交易信息的隊列管理能力。

通過提供不同的管理隊列實現(xiàn)對不同狀態(tài)交易的緩存。提供給系統(tǒng)中的其他業(yè)務處理插件 Push 和 Pop 交易的訪問接又。同時通過事件能力，通知其他模塊交易的緩存變化，進而觸發(fā)其他模塊的相關動作。

Message Queue：系統(tǒng)中的消息緩存隊列，采用先進先出的方式提供異步處理消息的緩存能力。完成網(wǎng)絡層消息的接收和系統(tǒng)核心處理邏輯之間的解耦。

Synchronization Queue：系統(tǒng)中的同步數(shù)據(jù)緩存對象，主要用于 P2P 節(jié)點之間的區(qū)塊和交易同步緩存。提供更好的同步中間對象存儲和數(shù)據(jù)校驗能力。實現(xiàn)對同步處理插件的數(shù)據(jù)同步和區(qū)塊鏈插件之間的數(shù)據(jù)紐帶。

Accounts Cache：系統(tǒng)中的賬戶緩存組件，提供對 Account State 中的賬戶數(shù)據(jù)以及賬戶的 Storage 數(shù)據(jù)的緩存能力。通過鏈表的數(shù)據(jù)結構實現(xiàn)對熱點訪問數(shù)據(jù)的緩存，同時出于對空間存儲的考慮實現(xiàn)基本的 LRU策略。通過 Cache 機制滿?區(qū)塊鏈插件對賬戶數(shù)據(jù)的?效訪問能力。

3.3 驗證插件

Transaction Verify：通過基本的校驗驗證能力，包含：交易的有效性檢測、交易的雙花檢測、交易的簽名驗證、交易的權限檢查等。通過獨?的線程實現(xiàn)對緩存插件中緩存的接收交易合法性驗證，通過一定的預執(zhí)行能力提前檢測交易的數(shù)據(jù)影響集，給后續(xù)區(qū)塊鏈插件的交易并行執(zhí)行提供一定的參考數(shù)據(jù)。

Authority Verify：用于系統(tǒng)中的權限檢查功能，通過提供獨?的接又完成對系統(tǒng)治理部分的相關操作權限檢查，驗證特定的簽名用戶是否有?夠的權限訪問指定的合約能力。通過用戶-??-操作的三元關系來定義和檢查系統(tǒng)中的操作權限。

3.4 共識插件

PBFT：簡單拜占庭容錯共識協(xié)議，通過 PrePrepare、Prepare、Commit的三階段提交協(xié)議，提供 3F+1 個節(jié)點的情況下，只要系統(tǒng)中不超過 F個錯誤的節(jié)點，即可完成共識節(jié)點間系統(tǒng)數(shù)據(jù)一致性的達成，提供交易的快速確認和容錯機制。

HBBFT：一種異步的拜占庭容錯協(xié)議，同于 PBFT 一樣滿? 2/3 的節(jié)點一致性和 1/3 的節(jié)點容錯性。不同于 PBFT 的單一主節(jié)點發(fā)起提議，HBBFT 的每個共識參與節(jié)點均可以發(fā)起提議，基于一個 ACS 的階段協(xié)議來保證提議的全網(wǎng)?播，通過一個 BA 的協(xié)議來完成節(jié)點之間數(shù)據(jù)一致性。最終對所有節(jié)點的提議進行一個排序進而形成最終的提議內(nèi)容并在全網(wǎng)達成一致結果。

Graph BFT：系統(tǒng)中基于 DAG 技術的拜占庭容錯協(xié)議，能夠基于DAG 技術在共識節(jié)點本地形成 1/3 的容錯一致性結論。Graph BFT 通過協(xié)議保證在對網(wǎng)絡低依賴的情況下，通過本地的圖論基礎來達成系統(tǒng)中交易數(shù)據(jù)的一致性排序，提供更?的處理性能和更低的網(wǎng)絡負載。

3.5 虛擬機插件

EVM：以太坊的虛擬機實現(xiàn)，支持使用 Solidity 程序語?編寫智能合約，提供基于堆棧方式的指令解析邏輯來完成智能合約代碼的執(zhí)行和結果輸出。通過 Gas 機制來保證合約的有效執(zhí)行和可終?性，同時提供一定的指令跟蹤和調(diào)試能力。

PVM：一種支持 Python 編程語?指令執(zhí)行的圖靈完備虛擬機執(zhí)行引擎。能夠解析和執(zhí)行 python 智能合約編譯后的指令代碼集，提供基本的數(shù)據(jù)類型定義和訪問能力。PVM 是系統(tǒng)中在編程語?上使一種更簡潔和友好的選擇方式。

WASM：WebAssembly 虛擬機是一個可擴展的?效虛擬機執(zhí)行引擎，可以支持 C 或者 C++語?編寫智能合約，然后編譯生成 WASM 虛擬可識別的中間狀態(tài)，通過 WASM 加載并?效的執(zhí)行。WASM 在系統(tǒng)中提供了更?的處理性能，是一種在需要滿??吞吐的場景下的更優(yōu)選擇。

WREN：是一個精煉的虛擬機執(zhí)行引擎，支持通過類 C++的編程語?編寫智能合約，編譯生成 WREN 的指令集。WREN 在實現(xiàn)的復雜度上和精煉程度上提供了更好的方式。

3.6 合約插件

Precompile Command：系統(tǒng)中用來擴展智能合約能力的相關系統(tǒng)指令，采用原生語?的方式內(nèi)嵌于平臺之中，提供給智能合約特定的功能接又實現(xiàn)。通過特定的地址來標識接又訪問?又，通過內(nèi)置在創(chuàng)世區(qū)塊中的相關數(shù)據(jù)來保證多節(jié)點的功能一致性。

Native Contract：系統(tǒng)中支持采用原生語?的方式來定義和實現(xiàn)智能合約功能，提供更好的智能合約能力和更加?效的指令執(zhí)行。同預編譯指令一樣，采用特定的地址來標識原生合約的?又。Native 合約提供標準統(tǒng)一的 Apply 接又，通過將交易的參數(shù)傳遞給 Apply 接又來完成數(shù)據(jù)的解析和分發(fā)處理，并返回交易執(zhí)行的結果。

Upgrade Control：用來管理系統(tǒng)中的合約升級能力，完成在合約在發(fā)生缺陷后更新升級的能力。同時支持智能合約的數(shù)據(jù)遷移功能。

3.7 系統(tǒng)合約

Contract Template：系統(tǒng)中的合約模板，隨平臺系統(tǒng)發(fā)布，提供一些基本的業(yè)務合約模板，?向特定的業(yè)務場景，支持業(yè)務系統(tǒng)的快速定制，通過修改特定的模板參數(shù)來按照模板重新定義業(yè)務應用合約。

User Contract：系統(tǒng)中用戶管理合約，用來管理系統(tǒng)中的賬戶創(chuàng)建和用戶擴展信息的維護。通過特定的賬戶標識來與系統(tǒng)中的 Account 對象進行綁定和映射。如果系統(tǒng)需要控制賬戶的開戶權限，則可以通過管理員操作用戶管理合約來定義可開戶對象。

Node Contract：系統(tǒng)中的節(jié)點管理合約，用來管理系統(tǒng)中的所有 P2P網(wǎng)絡節(jié)點信息，節(jié)點信息可以包含：節(jié)點標識、節(jié)點類型(共識節(jié)點和?共識節(jié)點)、節(jié)點公鑰、節(jié)點的接?點信息等等。通過管理員發(fā)送特定的交易來維護這些節(jié)點列表用于系統(tǒng)中的節(jié)點發(fā)現(xiàn)和網(wǎng)絡維護。Authority Contract：系統(tǒng)中的權限管理合約，用來定義和維護系統(tǒng)中的相關權限許可信息，標識特定的用戶或者節(jié)點擁有特定的訪問操作權限。

Configuration Contract：系統(tǒng)中的配置管理合約，通過特定的數(shù)據(jù)結構來定義和維護系統(tǒng)中的相關配置和治理參數(shù)，通過有特定管理維護權限的用戶發(fā)起交易請求來維護配置信息，實現(xiàn)系統(tǒng)中所有節(jié)點需要使用的全局配置參數(shù)。

3.8 SDK 組件

Keystore API：主要用來管理客戶端的用戶私鑰信息，內(nèi)容涵蓋用戶交易簽名的用戶?份公私鑰，用于網(wǎng)絡鏈路的 CA 證書等。提供相關的函數(shù)接又來完成數(shù)據(jù)的加載和存儲。

Network API：客戶端的網(wǎng)絡交互能力，通過提供不同的網(wǎng)絡完全能力，來實現(xiàn)多樣性的網(wǎng)絡交互和接?。通過簡單的封裝，提供給客戶端應用開發(fā)系統(tǒng)與區(qū)塊鏈平臺的同步、異步交互能力。屏蔽掉與區(qū)塊鏈平臺交互的底層網(wǎng)絡交互細節(jié)。

Encoder：客戶端的消息編碼器，主要根據(jù)協(xié)議要求完成對客戶端請求的編碼邏輯。實現(xiàn)基本的 RLP 編碼能力和智能合約的 ABI 編碼能力。

Decoder：客戶端的消息編碼器，主要根據(jù)協(xié)議要求完成對客戶端請求的解碼邏輯。實現(xiàn)基本的 RLP 解碼能力和智能合約的返回信息解碼能力。

Transaction API：客戶端的交易請求相關 API，實現(xiàn)基本的交易請求的類型和格式定義。實現(xiàn)交易的封裝的和解析。用于快速的交易構建。

Signature API：該部分是對客戶端中加密能力的統(tǒng)稱。通過 Keystore 加載的私鑰來完成對數(shù)據(jù)的加解密、簽名驗簽的能力。主要應用在客戶端交易請求的簽名場景下。

Event API：客戶端的事件 API，主要封裝客戶端與區(qū)塊鏈平臺交互的事件接又，給客戶端提供相關的事件訂閱和處理機制。通過同步、異步的機制來完成對區(qū)塊鏈平臺相關交易、區(qū)塊、網(wǎng)絡、共識等的事件訪問能力。

Privacy API：客戶端的隱私操作 API，主要用于擴展平臺中的數(shù)據(jù)隱私保護能力，實現(xiàn)對交易數(shù)據(jù)、賬戶數(shù)據(jù)的信息保護，防?交易的監(jiān)聽和賬戶的匿名。

GrayEagle 經(jīng)濟系統(tǒng)

1. 流通體系

GrayEagle 基礎框架的內(nèi)生代幣稱為 GEC - GrayEagle Coin。 GEC 流通總量取決于業(yè)務需求量。 GEC 用作生態(tài)系統(tǒng)參與者的?作通證和使用通證。 GEC 也是衡量服務價值的單位和用于平臺激勵機制。

GrayEagle 生態(tài)的主要參與者有：

(1)平臺管理者

負責維護平臺，管理記賬者，業(yè)務提供者，運營者，監(jiān)管押金池。

(2)監(jiān)管者

代表政府，行業(yè)等外部監(jiān)管。

(3)記賬者

負責維護平臺賬本，業(yè)務監(jiān)管。

(4)見證者

負責記賬監(jiān)管。

(5)業(yè)務提供者

負責提供業(yè)務運行環(huán)境和資源，包括算力，存儲，網(wǎng)絡等。

(6)運營者

業(yè)務的擁有者和運營者。

(7)用戶

被服務對象。

在這個生態(tài)中以 GEC 作為流通介質(zhì)。記賬者，見證者，業(yè)務提供者需要繳納一定量押金以獲得參與生態(tài)的資格。運營者發(fā)行的資產(chǎn)，需要等額 GEC 背書流通額，以及一定比例的運營押金。記賬者，見證者和業(yè)務服務者獲得兩方?收益，生態(tài)收益和業(yè)務服務收益。