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

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

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

? 區塊鏈能給哪些行業帶來創新和增值？

? 為了達到上述目標，區塊鏈應用系統應該如何搭建？

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

GrayEagle 區塊鏈基礎框架（infrastructure）

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

? EPOA（ Electing Proof Of Authority）：基于選舉式權威證明的治理模式

? 雙層架構： 治理層和業務層

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

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

1. EPOA

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

（1）pow 及其改造機制。

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

（3）poa（Proof of authority）

（4）BFT 變種，例如 PBFT， Graph BFT 等

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

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

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

1.1 Authority

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

（1）擁有?夠的 token 抵押。

（2）獲得?多數 citizen 節點的選票。

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

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

1.2 Recorder

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

（1）有提供穩定服務的計算能力

（2）有?夠多的 token 抵押

（3）獲得 Authority 批準

（4）擁有賬本的完整信息。

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

1.3 Citizen

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

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

（2）選舉權

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

（3）成為 Recorder

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

1.4 小結

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

更為底層的共識算法，我們已經實現了一種基于 BFT 變種的異步算法。我們后續會逐步將共識算法模塊插件化。更多的細節不再本文討論范圍。

2. 雙層架構

GrayEagle基礎架構實現了2層區塊鏈：治理層和業務層

（1）治理層

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

（2） 業務層

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

3. 技術架構摘要

GrayEagle 的具體技術實施思路之一是盡可能時將功能插件化，如圖 2所?，其中部分已經實現，部分有待于在后續?作中完成，整體規劃不變，部分細節可能會在研發進程中不斷調整。

3.1 基礎組件

Crypto：加密學密碼組件，主要包含基本 hash 運算、秘鑰生成算法、加解密算法、簽名驗簽算法等。完成系統內部數據的 hash 摘要、數據的簽名驗簽、秘鑰的生成等。

Network：主要實現基本的網絡庫能力，包含但不限于 Endpoint 管理、網絡參數設置、網絡監聽、網絡連接建?、網絡消息回調等。

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

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

RLP：系統內部針對數據結構的編解碼能力，通過流式的方式進行數據緊湊編碼，完成網絡字節序轉換和基本數據類型的合法性校驗。支持循環嵌套的方式完成復雜容器結構的數據編碼能力。

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

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

Utils：系統內部的一些?具集，提供一些基本的格式轉換、格式校驗、基礎功能函數等的相關能力。以及系統內部的一些基本宏定義和常量參數等。

3.2 緩存插件

Transaction Queue：實現系統接收到交易信息（來源于客戶端的交易請求和 P2P 網絡的交易?播）的緩存，實現對交易信息的隊列管理能力。

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

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

Synchronization Queue：系統中的同步數據緩存對象，主要用于 P2P 節點之間的區塊和交易同步緩存。提供更好的同步中間對象存儲和數據校驗能力。實現對同步處理插件的數據同步和區塊鏈插件之間的數據紐帶。

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

3.3 驗證插件

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

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

3.4 共識插件

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

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

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

3.5 虛擬機插件

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

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

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

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

3.6 合約插件

Precompile Command：系統中用來擴展智能合約能力的相關系統指令，采用原生語?的方式內嵌于平臺之中，提供給智能合約特定的功能接又實現。通過特定的地址來標識接又訪問?又，通過內置在創世區塊中的相關數據來保證多節點的功能一致性。

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

Upgrade Control：用來管理系統中的合約升級能力，完成在合約在發生缺陷后更新升級的能力。同時支持智能合約的數據遷移功能。

3.7 系統合約

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

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

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

Configuration Contract：系統中的配置管理合約，通過特定的數據結構來定義和維護系統中的相關配置和治理參數，通過有特定管理維護權限的用戶發起交易請求來維護配置信息，實現系統中所有節點需要使用的全局配置參數。

3.8 SDK 組件

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

Network API：客戶端的網絡交互能力，通過提供不同的網絡完全能力，來實現多樣性的網絡交互和接?。通過簡單的封裝，提供給客戶端應用開發系統與區塊鏈平臺的同步、異步交互能力。屏蔽掉與區塊鏈平臺交互的底層網絡交互細節。

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

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

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

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

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

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

GrayEagle 經濟系統

1. 流通體系

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

GrayEagle 生態的主要參與者有：

（1）平臺管理者

負責維護平臺，管理記賬者，業務提供者，運營者，監管押金池。

（2）監管者

代表政府，行業等外部監管 。

（3）記賬者

負責維護平臺賬本，業務監管。

（4）見證者

負責記賬監管。

（5）業務提供者

負責提供業務運行環境和資源，包括算力，存儲，網絡等。

（6）運營者

業務的擁有者和運營者。

（7）用戶

被服務對象。

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

2 代幣分配

GrayEagle 平臺的代幣 GrayEagle Coin，簡稱 GEC，發行量 20 億，分配機制如下：

生態激勵：

預留 1 億。用于獎勵生態建設合作伙伴包括合作社群以及其它生態參與者，運營服務收益會納?其中統一分配。

業務支撐池：

8 億。用于運營商發行資產，生態參與者押金要求等。釋放規則由基金會制定。

GrayEagle 基金會：

3 億。用于獎勵對 GrayEagle 生態建設作出重?貢獻的機構和個?。

創始團隊激勵：

2 億。用于團隊激勵，以及平臺的持續開發完善，拓展所支持業務種類，社區維護和網絡運維。團隊鎖倉期 5 年，從 2019 年 9 月開始每月分批次解鎖。

階段性資金支持：

6 億。用于感謝提供階段性資金支持的機構和個?。