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

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

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

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

? 為了達(dá)到上述目標(biāo)，區(qū)塊鏈應(yīng)用系統(tǒng)應(yīng)該如何搭建？

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

GrayEagle 區(qū)塊鏈基礎(chǔ)框架（infrastructure）

在本章中我們主要描述 GrayEagle 的三個(gè)主要特點(diǎn)：

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

? 雙層架構(gòu)： 治理層和業(yè)務(wù)層

? 模塊化和可插拔的技術(shù)目標(biāo)和路線

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

1. EPOA

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

（1）pow 及其改造機(jī)制。

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

（3）poa（Proof of authority）

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

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

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

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

1.1 Authority

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

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

（2）獲得?多數(shù) citizen 節(jié)點(diǎn)的選票。

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

這種 Authority 我們稱之為 Elected Authority，它們會(huì)以類似于 pos 的方式進(jìn)行?作，并獲得幣齡獎(jiǎng)勵(lì)。recorder 成為 Authority 的過(guò)程對(duì)應(yīng)圖 1中的動(dòng)作 C。

1.2 Recorder

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

（1）有提供穩(wěn)定服務(wù)的計(jì)算能力

（2）有?夠多的 token 抵押

（3）獲得 Authority 批準(zhǔn)

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

成為 Recorder，不僅僅可以以類似 pos 的方式獲得幣齡獎(jiǎng)勵(lì)，還有機(jī)會(huì)在定期的選舉中，成為 Authority。

1.3 Citizen

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

（1）舉報(bào)權(quán)，他們可以在發(fā)現(xiàn) Authority 或 Recorder 存在?法行為時(shí)（注：?法行為待列舉）向 Authority 團(tuán)體舉報(bào)，一旦舉報(bào)通過(guò)，會(huì)以一種舉報(bào)獎(jiǎng)勵(lì)機(jī)制獲得 token 獎(jiǎng)勵(lì)。（獎(jiǎng)勵(lì) token從被舉報(bào)節(jié)點(diǎn)的懲罰 token 中分出，一部分懲罰 token 用于獎(jiǎng)勵(lì)舉報(bào)者，剩余部分懲罰 token 直接燒毀）。這個(gè)過(guò)程對(duì)應(yīng)圖1 動(dòng)作 D。

（2）選舉權(quán)

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

（3）成為 Recorder

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

1.4 小結(jié)

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

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

2. 雙層架構(gòu)

GrayEagle基礎(chǔ)架構(gòu)實(shí)現(xiàn)了2層區(qū)塊鏈：治理層和業(yè)務(wù)層

（1）治理層

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

（2） 業(yè)務(wù)層

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

3. 技術(shù)架構(gòu)摘要

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

3.1 基礎(chǔ)組件

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

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

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

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

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

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

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

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

3.2 緩存插件

Transaction Queue：實(shí)現(xiàn)系統(tǒng)接收到交易信息（來(lái)源于客戶端的交易請(qǐng)求和 P2P 網(wǎng)絡(luò)的交易?播）的緩存，實(shí)現(xiàn)對(duì)交易信息的隊(duì)列管理能力。

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

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

Synchronization Queue：系統(tǒng)中的同步數(shù)據(jù)緩存對(duì)象，主要用于 P2P 節(jié)點(diǎn)之間的區(qū)塊和交易同步緩存。提供更好的同步中間對(duì)象存儲(chǔ)和數(shù)據(jù)校驗(yàn)?zāi)芰?。?shí)現(xiàn)對(duì)同步處理插件的數(shù)據(jù)同步和區(qū)塊鏈插件之間的數(shù)據(jù)紐帶。

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

3.3 驗(yàn)證插件

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

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

3.4 共識(shí)插件

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

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

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

3.5 虛擬機(jī)插件

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

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

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

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

3.6 合約插件

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

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

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

3.7 系統(tǒng)合約

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

User Contract：系統(tǒng)中用戶管理合約，用來(lái)管理系統(tǒng)中的賬戶創(chuàng)建和用戶擴(kuò)展信息的維護(hù)。通過(guò)特定的賬戶標(biāo)識(shí)來(lái)與系統(tǒng)中的 Account 對(duì)象進(jìn)行綁定和映射。如果系統(tǒng)需要控制賬戶的開戶權(quán)限，則可以通過(guò)管理員操作用戶管理合約來(lái)定義可開戶對(duì)象。

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

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

3.8 SDK 組件

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

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

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

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

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

Signature API：該部分是對(duì)客戶端中加密能力的統(tǒng)稱。通過(guò) Keystore 加載的私鑰來(lái)完成對(duì)數(shù)據(jù)的加解密、簽名驗(yàn)簽的能力。主要應(yīng)用在客戶端交易請(qǐng)求的簽名場(chǎng)景下。

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

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

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

1. 流通體系

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

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

（1）平臺(tái)管理者

負(fù)責(zé)維護(hù)平臺(tái)，管理記賬者，業(yè)務(wù)提供者，運(yùn)營(yíng)者，監(jiān)管押金池。

（2）監(jiān)管者

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

（3）記賬者

負(fù)責(zé)維護(hù)平臺(tái)賬本，業(yè)務(wù)監(jiān)管。

（4）見證者

負(fù)責(zé)記賬監(jiān)管。

（5）業(yè)務(wù)提供者

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

（6）運(yùn)營(yíng)者

業(yè)務(wù)的擁有者和運(yùn)營(yíng)者。

（7）用戶

被服務(wù)對(duì)象。

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

2 代幣分配

GrayEagle 平臺(tái)的代幣 GrayEagle Coin，簡(jiǎn)稱 GEC，發(fā)行量 20 億，分配機(jī)制如下：

生態(tài)激勵(lì)：

預(yù)留 1 億。用于獎(jiǎng)勵(lì)生態(tài)建設(shè)合作伙伴包括合作社群以及其它生態(tài)參與者，運(yùn)營(yíng)服務(wù)收益會(huì)納?其中統(tǒng)一分配。

業(yè)務(wù)支撐池：

8 億。用于運(yùn)營(yíng)商發(fā)行資產(chǎn)，生態(tài)參與者押金要求等。釋放規(guī)則由基金會(huì)制定。

GrayEagle 基金會(huì)：

3 億。用于獎(jiǎng)勵(lì)對(duì) GrayEagle 生態(tài)建設(shè)作出重?貢獻(xiàn)的機(jī)構(gòu)和個(gè)?。

創(chuàng)始團(tuán)隊(duì)激勵(lì)：

2 億。用于團(tuán)隊(duì)激勵(lì)，以及平臺(tái)的持續(xù)開發(fā)完善，拓展所支持業(yè)務(wù)種類，社區(qū)維護(hù)和網(wǎng)絡(luò)運(yùn)維。團(tuán)隊(duì)鎖倉(cāng)期 5 年，從 2019 年 9 月開始每月分批次解鎖。

階段性資金支持：

6 億。用于感謝提供階段性資金支持的機(jī)構(gòu)和個(gè)?。