【摘要】 共识机制EPOA实现基于BFT变种的异步算法
随着比特币的成功，区块链的概念慢慢得到了普及和⼤众的认可。去中心化、不可篡改、改变生产关系，抛开这些区块链想要实现的美好愿景，⾄今却少见一款产生实际价值的基于区块链技术的商用级别应用落地。我们认为除了针对可扩展性(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 的⾼效数据读写能力。现阶段的主要选型基于 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 亿。用于感谢提供阶段性资金支持的机构和个⼈。（GrayEagle）