3.2 技术架构

集成链交互游戏运行环境

3-2-1 Cocos-BCX链上游戏、应用的运行环境架构

3-2-1 Cocos-BCX链上游戏、应用的运行环境架构

多平台游戏集成运行环境

Cocos-BCX 认为未来的区块链游戏的运行环境应具备以下的特征:

  • 一致和完善的链互操作接口;
  • 向下透明的承接方式;
  • 封装的原子操作;
  • 多平台兼容。

为了简化开发者的使用过程,Cocos-BCX设计了一套可适配多种类型 APP 的集成运行环境,以及配套的互操作接口。和COCOS Creator结合,简化游戏程序和区块链的对接过程,使链内交互工作对开发者透明化,让传统游戏的开发者也能无门槛地开发或迁移区块链游戏。

Cocos-BCX 链上游戏运行 SDK被集成到 Cocos 引擎 Runtime 中,对游戏提供完整的链交互接口,游戏开发者基于 Cocos-BCX SDK完成游戏内容向区块链网络的接入,链交互过程透明化、结构化,游戏开发团队不再需要投入研发力量用于适配链网络和不同设备。

同时,运行环境将兼容原生 Android、iOS 和 PC Web、移动H5等系统和环境。运行环境内的游戏将具备原生的跨平台能力,实现链上游戏在多个平台无障碍运行的特性。

区块链交互接口

Cocos-BCX 提供链交互的开发环境,以便开发者能够通过这套环境便捷地与链交互。

Cocos-BCX 的区块链交互开发环境提供兼容多种工作平台的开发组件,包括适配 Android、iOS系统的SDK,适配前端 web 应用的 javascript 库,以及适配后端应用的 python、PHP库等。

开发者能够使用这些开发环境开发自己的区块链软件,实现数据交互,诸如用户注册、用户信息和资产操作、用户游戏数据操作等功能。链上数据接口允许用户在链上存储同质或非同质资产数据,并且为了提供最佳的兼容性和可定制特性,区块链系统不会强制要求资产数据以明文方式存储,游戏开发者可以更灵活的设计自己的链上数据存储结构,以便这些信息可以更为安全地通过游戏客户端和市场的插件解析。

目前链交互开发环境主要提供同质、非同质数字资产和道具查询、转移、所有权变更、事务提交、提议与表决等功能的封装。

支持同质/非同质资产和多链铆接的承兑网关

Cocos-BCX 中,同质、非同质资产和智能合约是分离的。可以预见的,Cocos-BCX 的网络中会存在大量的、持续发生的事务,需要尽可能降低资产解析和流转的运算成本,更容易实现非同质资产的跨链映射,并且“资产和合约分离”是更安全的设计。

3-2-2 承兑网关

3-2-2 承兑网关

Cocos-BCX 提供一套映射网关用于游戏金币和道具的自动化承兑,在统一的价值衡量体系下,实现链上不同游戏、不同平台间内容的平滑过度,可用于承兑的内容包括游戏金币、游戏装备数据等。

游戏数字资产的承兑

游戏数字资产与以太坊ERC20数字资产承兑如下图所示:

3-2-3 ERC20数字资产承兑关系

3-2-3 ERC20数字资产承兑关系

游戏金币支持通过承兑网关与其他联盟链以及独立链进行资产转移。
游戏非同质资产的承兑

3-2-4 Cocos-BCX与ERC721数字资产承兑关系

3-2-4 Cocos-BCX与ERC721数字资产承兑关系

BCX-NHAS-1808是COCOS应用中适用于去中心分布记账式网络的非同质数字资产标准,具备资产与合约分离的特性以及可扩展、可自定义的数据区域,可兼容其他非同质资产标准。
ERC875 和ERC721数字资产标准都是以太坊针对非同质数字资产的标准协议。在某种程度上,ERC875 更像是ERC721 的“简略缩水”升级版。ERC721创建了非同质数字资产的标准先河,其随后更新的ERC841 和ERC821 都是在其上某部分进行的优化修改;而ERC875标准则更加简单直接。其定义的函数包括name 、symbol、balanceOf、transfer、transferFrom,totalSupply、ownerOf、trade。对比ERC721标准,ERC875的函数更加简单。
通过进一步扩展承兑网关支持的数字资产技术,网关将能够在未来支持以ERC721、ERC875、BCX-NHAS-1808为代表的非同质复合型合约,承兑网关对游戏道具与非同质合约的承兑类似于一个专用编译器,通过对结构化数据的翻译和转换,实现非同质合约到链内游戏道具的双向承兑,兼容更多类型的链内外道具流转,提供更丰富的游戏内容和用户体验。

对已有区块链系统的优化和扩展

改进的非同质数字资产数据结构
非同质数字资产是一种应用于分布式记账网络中的数字资产类型,资产实例具备唯一性,通过对非同质数字资产结构的优化可以使其更加灵活地服务于区块链网络游戏。
Project BCX重新设计数据结构,增加自定义数据存储,以容纳可能的游戏数据和扩展内容。同时也相应调整共识、见证、出块等关键流程,以匹配新的数据结构。BCX中的道具数据,只在生成和属性变动时在块数据中作完整记录,普通的事务和流转时,则仅记录哈希指针,确保块数据的体积不会因长期的事务过快的增长。

3-2-5 非同质数字资产各部关系与数据结构图

3-2-5 非同质数字资产各部关系与数据结构图

区块链网络中非同质数字资产数据结构分为固有数据区域和扩展数据区域。
其中固有数据区域存储非同质数字资产的基本信息,包括资产ID、世界观申明和基础数据区域三部分。资产ID,即资产实例在分布式账本网络中的唯一标识,是该资产在被访问、查询、修改时的唯一凭据;世界观申明,包括世界观ID以及该资产生效和支持的游戏类型、世界,以及此资产在网络中流通需要使用的世界流通货币类型;基础数据区域又分为资产基本描述、制作时间、制作者、所有者、使用者、使用权黑白名单等信息。
扩展数据区域是为非同质数字资产属性扩展设计的功能板块,包括组合关系数据和域数据两部分。组合关系数据描述资产组合、嵌套和从属关系。扩展数据区域支持非同质数字资产属性扩展,数据单位称为域,是该资产支持的世界观内游戏具体业务数据的存储区域,不同的游戏或者其他业务实体在域数据拥有专属的域标识和数据区,并且数据区相互隔离,每一个域绑定若干个仅对自己负责的合约,域数据以域标识和数据的键值对形式存储,代表该资产在具体游戏内的数据如攻击值、防御值、耐久度等。
此外,分离的使用权和所有权设计,使得基于链权限系统的租赁、抵押、典当等复杂金融模式的业务设计具备了可行性。
Cocos-BCX中非同质数字资产标准BCX-NHAS-1808与其他以太坊非同质数字资产标准相比,具备很多优势:具备资产与合约分离的特性以及可扩展、可自定义的数据区域,可兼容其他非同质资产标准。

3-2-6 现行的非同质数字资产标准对比

3-2-6 现行的非同质数字资产标准对比

资产与合约的数据分离

同质、非同质资产和智能合约数据在链上的存储是分离的。

Cocos 的网络中会存在大量的、持续发生的事务,需要尽可能降低资产解析和流转的运算成本,资产与合约分离可以实现合约的单独解析执行以及必要结果上链的操作。

在资产与合约数据存储分离的设计下,资产拥有者具备该资产的全部权限,资产的操作仅能由拥有者的授权完成。可以避免因资产合约不分离而出现通过修改合约内容而破坏资产属性或者调用他人资产的情况发生,并且不考虑合约因素的制约则更容易实现非同质资产的跨链映射,因此资产和合约分离是更安全的设计。

改进的DPoS共识机制

Cocos-BCX 测试链的共识层采用DPoS共识算法。

DPoS 算法通过预定见证人和规定时间槽位来推测区块的生产者以及出块时间,通常时间槽位间隔为5秒,在实际使用过程中为了更快的网络广播速度以及更大的网络吞吐量而将时间槽位间隔设置为3秒,如果预定的见证人在规定的时间槽到来时,因为网络原因或者设备硬件故障没有正常的出块,则该时间槽位不会出块,网络将等待下一个时间槽位到来选择另一个预定见证人进行出块。

Cocos-BCX 中,所有的预定见证人都由所有的持股人从见证人中投票选举,预定见证人统称为活跃见证人,活跃见证人数量通常为11~101个。所有的活跃见证人在DPoS共识算法的见证人预定算法中具有相同的出块预定概率,这保证了所有见证人的出块概率和获取出块奖励是一致的。石墨烯投票更新时间通常为24小时,但出于安全性、稳定性、公平性的考虑,项目初期网络投票更新时间通常较短,可能为12小时甚至更短。

3-2-7 现存共识机制优劣势对比

3-2-7 现存共识机制优劣势对比

在 DPOS 算法中通过预定见证人和规定时间槽位来推测区块的生产者以及出块时间,主链的活跃见证人总是多于支链,故此主链区块高度一定高于支链,同时全网投票机制避免了见认证人集中化,保证了网络的安全性,不同见证机制之间的优劣对比如图3-2-7 所示。

使用现代密码学保障的安全性
现代密码学技术是一门基于数学原理的密码学技术,目前已经广泛应用于互联网领域的多种行业,常见的对称加密技术包括WiFi使用的AES加密,以及不对称加密算法(公私钥密码体系)RSA、ECC等,其中ECC(椭圆加密算法)是区块链领域常用的加密算法。这些算法通过数学原理设计出一种不可接受解算消耗的加解密体系来防止加密被攻破。在没有正确获得密钥的前提下,对此类加密算法的破解尝试均会因为计算量过大导致实施时间过长(通常需要花费近百年的时间用于尝试破解/猜解密钥体系)而失去破解行为的价值。
ECC算法全称Elliptic curve cryptography(椭圆曲线加密算法),于1985 年由Neal Koblitz 和Victor Miller 分别提出。
低分叉风险
在比特币和以太坊网络中的工作量证明机制下,矿工遵循相同的机制,当矿工同时挖出了两个区块时,就出现了分叉现象。在遵循“最长链”原则的共识机制下,分叉的链会在6个区块后,短的链就会被废弃。但是当矿工不遵循同样的机制时,就会出现两种会产生深远影响的分叉结果,软分叉和硬分叉。相对而言,软分叉就是区块链系统的旧版本与新版本的区别,当原有旧系统完全升级后,软分叉现象就会消失;硬分叉是原本同一区块链主链的矿工,选择采取不同的共识机制进行挖矿,同一条主链将会被分成同源但却分离的两条链。2016年7月份的“The DAO”事件就是最著名的以太坊网络硬分叉案例。而当以太坊分叉为以太坊和以太坊经典后,其对应原有主链的算力就会降低,进而对整个主链网络的安全性产生重大影响。
Cocos-BCX使用DPoS共识机制,不需要矿工使用矿机进行挖矿,可以有效避免中心化算力对整个基础链的影响,进而降低分叉风险。在DPoS机制下,若有见证人想要通过投票进行分叉,则需要保证1/3以上的见证人都同时违背机制才有可能。与此同时,用户也可以通过票选罢免活跃见证人来降低可能的分叉问题。相比较比特币和以太坊网络的PoW共识机制下的高分叉风险,Cocos-BCX的分叉风险更低,可以有效保证游戏开发者和用户的数据安全。
多链挂接
除跨链承兑网关外,Cocos-BCX将在未来支持更加直接的多链挂接方案,例如,在下一阶段的升级中,Cocos-BCX将支持使用IPFS存储大段的合约与一些游戏数据。
合并多个操作确保事务原子性
区块链游戏的道具制作是原子性的,道具制作者根据玩家提交的需求和材料、资产打造道具,打造完成后,道具转移给玩家。在这一过程中包含一系列操作(OP):数字资产生成、设置道具属性、变更资产所有权到用户等,为了保证过程中所有操作结果的一致性,我们将这一系列操作合并为了一个事务,即一次原子操作,事务中的所有操作只会同时成功或同时失败。

3-2-8 多操作原子合并示意

3-2-8 多操作原子合并示意

原子合并的另一个应用是Project BCX的去中介资产流转,目的是让卖家多获益、买家少消耗。去中介流通平台本身不存储用户的资产数据,而仅作为点对点请求的撮合媒介,游戏厂商可以灵活的设计自己的游戏资产数据结构,可流转的内容不局限于游戏内的同质资产,也涵盖道具、装备、游戏数据等非同质资产。用户在游戏内容流通平台上提交出让请求时,请求对应的游戏资产(金币或道具等)将被锁定,暂时无法继续在游戏中使用,直到取消本次请求。请求包含出让人的主链ID以及出让资产的内容,当出让请求达成时,系统自动完成资产所有权的变更,并且向出让人转移购入请求人支付的资产,完成整个流转请求。
发生资产流转行为时,出让/求购以请求的形式提交至流通平台,资产转移与资产的所有权变更被视为一次不可分割的操作,即双方的行为均需被共识认可,如果任意一方资产变更动作不被主链区块认可,则整个事务将被回滚。即在整个流转过程中资产的所有权变更或资产转移等行为将打包在一笔事务内,两个动作的状态具有一致性,事务正常完成后将产生唯一链上可查的事务ID。

3-2-9 原子事务状态判定机制

3-2-9 原子事务状态判定机制

BCX测试链:高效链网络与高速合约虚拟机

Cocos-BCX拥有足够的高并发处理能力。
目前的绝大部分联网游戏,当用户规模达到一定程度时,其服务器需要在短时间内进行大量的数据处理,而在现有的以太坊网络中是无法实现的。
Cocos-BCX采用改进的DPoS共识,理论吞吐量约10万TPS,其高并发处理性能在合理的数据管理模式设计下足以支持现有游戏的开发与正常运行,基本满足大型联网游戏在平台中的运营诉求,保证用户的游戏体验与现有的中心化游戏几乎没有区别。
由于大规模网络游戏的数据交互频率非常高,DNF曾创下60万人同时在线的记录,Steam游戏平台更有1420万人同时在线的惊人数据。如果每一个在线用户提交数据的行为都视为发起了一次共识申请,Cocos-BCX的极限吞吐能力不足以支撑这样级别的处理请求,开发团队按见证速度的需求设计了不同的见证委托模式(Delegation Templates),使单一见证委托人不用对所有运行中的游戏作同时见证和处理,而是专注于对复数个同类型游戏作见证和计入区块的工作。并且,在这一模式下,不同游戏的数据提交/见证是相对异步的过程,每一个游戏会选择适合的委托模式,而异步模式下的数据验证则可以通过链上数据库服务来完成,即用户在链上验证并完成数据存取。这一过程非常高效,足够支撑大规模游戏场景下的玩家数据操作。

3-2-10 Cocos-BCX的合约

3-2-10 Cocos-BCX的合约

合约是一段可以自动执行的程序,同时作为系统参与者,按照环境的基本规则(编译器规则)执行预设的任务,合约可以定义输入和输出,能够接受和存储价值,同时向外发送信息和价值。智能合约是以“不信任原则”为前提设计的,每一个节点均认为彼此不可信任。由于区块链的分布式保存特性,链上的每一个节点均保存有同样的合约执行代码,合约的运行结果由全网算力共同见证,并通过全体表决形式决定运算结果是否被认可。Cocos-BCX的合约支持见证委托的定义。
为了保障合约执行的效率足以向用户提供足够良好的游戏体验,Cocos-BCX重新设计了一套针对链上游戏场景的基于LUA的高速合约虚拟机方案。不同于现有区块链的合约虚拟机方案,除了通过大幅定制和优化现有的区块链运行环境及合约虚拟机的执行效率外,Cocos-BCX的虚拟机使用与游戏SDK相同的语言和API系统,并提供链和游戏执行环境的互操作接口,这将彻底改变区块链合约环境单一、灵活性差、定制能力差的现状。智能合约的应用场景将不再限于作为货币描述,而是开始能够接纳更多与游戏直接相关的内容,包括可能的诸如:基础规则、设定、单位、场景、甚至地图等。改进后的虚拟机不仅支持更为复杂和灵活的合约形态,并且将大幅度提高现有智能合约的运行效率。

链上游戏的分布式记账体系深度开发

在上文中我们提到链上游戏的最终形态是实现游戏整体逻辑的上链运行,但现有的区块链技术尚不满足承载游戏完整逻辑所必须的最低限度特性,其中最为关键的几点包括:
 节点数据同步的数据量与时间成本
只有完整节点具备执行合约的能力,但完整节点存储有全网的所有事务数据,其数据量之大显而易见,且新建一个节点时同步这些数据的时间消耗也非常惊人;
 游戏逻辑完整上链需要能够支持大型合约
若实现游戏完整逻辑上链,那么合约本身将包含游戏的全部后台逻辑,合约将可能变得非常大,甚至超过一般区块的块大小,而在现有区块链技术的设计下,无法被块容纳的合约是永远无法运行并得出结果的;
 合约持续执行
游戏逻辑完整上链则意味着一个游戏应用在结束前,游戏合约将会持续运行,也即是游戏合约的运行时间是远大于出块周期,跨块执行的,现有任何区块链技术都无法支持这样的合约运行模式;
 事务执行延迟
游戏完整上链意味着链上处理了所有游戏中可能会执行的事务,其中不乏要求高速响应的部分,而传统区块链的事务响应取决于出块行为,而最快确认速度也受限于出块周期限制,难以满足游戏合约对事务即时响应的需求;
 随机过程无法共识
链上随机过程规则由智能合约描述,而合约的过程是公开的,若需要产生无法被第三方推算的随机结果,则需要合约运行时有节点的噪声参与这一过程的输入,但不同节点的噪声不可能一致,即其他节点无法通过再次运行这份合约来验证这次随机过程的结果是否正确,最终导致无法完成共识;
 链内实现的定时器与心跳
定时器与心跳机制是所有链上合约、游戏内容实现定时运行、自动运行、条件运行的前提条件,而这一特性的时候背后还隐含了时间同步、同步防伪等过程,这对现有区块链技术来说是完全空白的区域;
 数字资产权限
传统区块链数字资产记录在合约数据区域内,资产不能脱离合约,因此合约所有者有权修改数字资产数据,可能导致资产拥有者受到损失。
针对这些问题,Cocos-BCX提出了对现有的分布式记账体系进行深度改造的设想,提出了下述的多种特性、机制设计,以最终实现链上游戏能够具备实际落地运行的目标:
 减少数据量和时间成本;
 在语法级别支持共识任务;
 合约持续执行;
 极小的事务延迟执行;
 链内可信随机过程;
 链内实现定时器与心跳;
 非同质数字资产数据结构中增加权限观念。

轻量级节点

在Cocos-BCX设计中,轻量级节点(下文简称为“轻节点”)本质上是一个具备与链互操作能力的环境,与全节点不同,轻节点不需要同步全网数据,取而代之的是同步运行必须的合约信息与环境数据,这样的设计可以大幅减少节点同步的数据量和同步时间,使链上游戏端软件具备了实际使用的容量、时间成本可行性。
Cocos-BCX开发的游戏整体以合约形式在轻节点上本地化运行,但合约中标识出需要共识的部分将被单独拆分为一个或多个子合约发布至相关节点进行共识(详细介绍见4.5.4 在语法级别支持共识任务),这样的设计能够让巨大的游戏合约以更具效率、几乎无延迟的方式运行,分别处理合约的共识与非共识部分也能够在尽可能保障用户体验的前提下保持与传统区块链一样,数据具有可靠性。同时,对于轻节点的验证也不再像传统区块链一样进行过程和结果的验证,而是对节点运行环境和输入数据的验证(可信执行环境验证),进一步提高了整体的运行效率。
合约的持续执行
通过轻节点的方式,游戏整体作为一个合约运行的设想得到了实现可能,本地运行的游戏合约能够长期、持续地在轻节点中运行,这一过程与出块周期或块大小都无关,与之相关的仅是游戏合约中包含共识的子合约内容。
游戏合约与子合约根据语法级别的共识优先级标识,在持续运行的同时也不断完成关键步骤的验证和同步,实现了游戏合约持续运行以及结果共识见证的机制。
合约会话机制
链上提供会话建立接口,该接口在合约公共数据区建立一个具有有效限制的用户会话列表,会话区间的用户将有权限向同会话区间的其他用户推送事务,其他用户收到数据变动通知时,可及时获取对应数据。
在语法级别支持共识任务
Cocos-BCX提出了让合约在语法级别支持共识任务的设计,通过特定的关键词修饰脚本的共识优先级,使合约解释器能够识别并在运行全文扫描时将有标记的需要共识的合约部分拆分出形成子合约发送至链网络的相关节点进行共识,共识优先级别从低到高包括不需共识、正常共识、即时响应、立即确认等。

3-2-11 轻节点与合约拆分运行原理

3-2-11 轻节点与合约拆分运行原理

合约整体在本地执行,到达需要共识的部分时,根据语法级别的优先级标识来确认共识方法,不同优先级采用不同共识步骤,游戏合约的运行更加流畅,可能发生的阻塞等待更低、时间更短。
被标记为优先级最高的立即确认的合约主体的运行过程与共识过程是两个相对独立的异步过程;被标记为即时响应的合约部分,事务在提交的同时,节点会立即回复信息被提交的回执,即事务hash值(Tx ID);正常共识的合约事务则按区块链事务执行的正常流程被执行;被标记为不需共识的合约内容仅在轻节点上运行。
此外,需要被共识的合约部分是拆分后以子合约方式分发执行的,这些子合约内容应该具备完整的上下文关系和无额外依赖的设计,以便在其他节点上也能正确的得到结果。
合约的优先共识
Cocos-BCX设计链上处理所有游戏中需要共识的事务,其中不乏要求高速响应和即时确认的部分,而传统区块链的事务响应取决于出块行为,而最快确认速度也受限于出块周期限制,难以满足游戏合约对事务即时确认的需求。
 事务的快速异步确认
合约支持语法级别的共识标记,合约运行时,被标记为立即确认的事务将被抽出并立即广播,当任意节点收到后会立即运行该过程得到结果并广播运行结果,同时本周期的出块人将把广播的结果存入结果池,当相同的结果数量达到判定通过的阈值时,出块人立即广播事务确认的结果并将此事务写入出块缓存,整体流程如图3-2-12。

3-2-12 异步共识下数据处理示意图

3-2-12 异步共识下数据处理示意图

在这个设计下,节点会在第一时间完成事务提交、处理、广播,而区块生成与事务执行过程成了相互异步的操作,达到事务的快速异步确认。
 即时响应
Cocos-BCX设计中,优先级标记为即时响应的合约,当用户向节点发出事务请求,节点将立即向网络发出事务广播,并同时向用户返回事务hash值。在这个设计下,其实事务最终记录周期与传统设计并没有太大差异,但事务的响应却几乎是没有延迟的,节点会在第一时间完成事务提交,大幅提高了事务的响应速度。
进一步的,用户可通过事务hash值跟踪事务状态,同时事务信息将更新到用户历史事务数据表中动态向用户推送,用户不必等待事务在链网络中验证、应用之后的回调再响应。我们借鉴了以太坊的hash跟踪特性,并在此之上加入了用户事务动态推送的机制。
极小延迟的事务响应
传统区块链的事务执行确认是在节点接收到区块数据,完成事务内容解析,运行并得到正确结果验证通过写入块数据时确认的,当一个事务被提交时这个事务实际进入了pending队列,而此时事务仍并未执行,直到下一个出块周期,这样的机制导致事务始终无法更及时地得到响应和处理。
 优先级共识
Cocos-BCX在语法级别对事务增加了优先级标识的设计,当事务被标记为立即确认时节点会在第一时间完成事务提交、处理、广播,而区块生成与事务执行过程变成了相互异步的操作,达到事务的快速异步确认;即时响应为另一种共识优先级,在这种模式下事务的响应却几乎是没有延迟的,节点会在第一时间完成事务提交,大幅提高了事务的响应速度。
 分区见证
为了进一步提高节点利用率和处理效率,Cocos-BCX在委托见证的基础上提出了分区见证的设计,即某些节点专注处理特定类型的合约请求,其原理如图3-2-13所示。

3-2-13 合约的分区见证机制

3-2-13 合约的分区见证机制

分区见证在游戏行业应用的意义在于能够针对不同请求类型针对性优化相关节点的处理能力,例如对浮点运算集中型请求重点加强核心算力,对结构数据处理集中型请求重点加强存储IO能力等,最终达到整体的效率、效益最优配置。
委托型事务机制
委托型事务主要用于处理随机性高,不同节点执行会产生不同结果的事务类型(如产生一组随机数),但此类型事务仅限于非个人数据关联的事务请求。合约中的共识标记允许定义需要委托参与共识的节点簇 (节点组) 名称,指明事务需要由哪一类节点处理。当数量只有一件时(N=1),被指名的节点簇会随机选择簇内任意一个当前在线的节点分配处理该事务,例如处理随机事件;当委托节点数量大于一件(N>1)或为一个簇时,被指名的簇内的多个节点将被分配至处理该事务。通过可信执行环境认证的受托人收到委托事务之后,会验证事务的可行性并执行委托,完成后将事务结果加密并打包向链上广播。
指定委托节点簇名的设计出发点有两个:一是出于安全性的考虑,只指定委托节点簇名,簇内随机选择节点处理事务,委托方不知道所委托的具体节点,这样可很好地防止作弊;二是从运行可靠性出发,指名节点簇可保证簇里分配事务到当前在线的节点。

3-2-14 基于委托的分区共识

3-2-14 基于委托的分区共识

内源可信随机过程实现
外源随机指随机过程的不确定性因素发生在区块链系统以外,内源随机则反之,外源随机无法保证随机因素的生成过程是能被链系统信任的,因此链系统如何实现合理的随机,其实就是要解决如何保证随机过程及结果可信的问题。
 实际完成随机过程执行的节点不应知晓此随机信息被使用的场景和对象,以免这部分信息被利用在作弊行为上;
 随机过程在调用其的业务行为结束前不应被链上公示,以免进行中的业务过程因随机过程的公示失去公正性(例如一局斗地主中各方手牌的构成等);
 内源随机过程应具备抵抗BP/开发者作弊的特性。
目前Cocos-BCX已经成功在链内实现了可信的随机过程,并将随机过程调用以接口的形式供合约开发者调用。只需在合约中以一般开发的方式调用random函数即可获取内源的随机数据。

3-2-15 链内可信随机过程

3-2-15 链内可信随机过程

链内的可信随机过程
区块链游戏规则上链能否具有实际应用价值与能否在链上实现随机过程密切相关。通过研究发现,完整的链上随机过程需要解决一个关键问题:链上随机过程规则由智能合约描述,而合约的过程是公开的,若需要产生无法被第三方推算的随机结果,则需要合约运行时有节点的噪声参与这一过程的输入,但不同节点的噪声不可能一致,即其他节点无法通过再次运行这份合约来验证这次随机过程的结果是否正确,最终导致无法完成共识。
要解决这个问题,我们提出了三种可实施的方案:
方案一
 在区块链动态数据区维护一个或若干随机数据池,出块人将随机过程的结果包裹在区块的加密数据段中并且加密过程的代码以闭源、不公开的形式发布。此时,所有节点将拥有同一套随机数据池。随机数据池的数据结构呈管道形态,具有读端和写端的封装,且仅允许符合规则的读写端访问,具有先进先出的特性。
 因为区块链的所有节点事务处理具有一致性,应用在申请随机过程结果时可从随机数据池中读取。在该随机过程产生、分配机制下,过程与结果的安全性能够满足区块链网络对随机过程的安全性需求:
 任意一种访问(读、写)行为都将导致随机数据池发生变化且无法复原;
 写入随机数据的行为由动态加密函数库完成,且函数库闭源、不公开;
 随机数据的生产者无法获知此次随机过程的结果将放入随机数据池的位置以及这一随机过程将会被谁使用;
这一随机过程的实现方案适用于链网络对事务处理顺序具有一致性的场景,例如RPG游戏中玩家开启地图宝箱获取随机道具的过程。
方案二
 通过委托机制,允许部分事务委托至某可信节点簇完成处理,节点簇中随机分配当前在线的可信节点执行事务,可信节点完成处理后记录随机过程结果,并由通知或轮询机制让委托方获取结果。
 因为该方案基于链事务委托机制,对链的改动会小于方案一,但要保证方案的可行性,应满足以下需求:
 受托方应通过可信执行环境验证,确保自身可信;
 受托方运行随机过程并发布结果时,应采用同样具备安全性的加密函数库完成;
 加密数据的传递需通过“零知识证明”或其他可靠证明方案证明受托方身份并能够被委托方识别,确保委托方得到的数据不是由第三方伪造。
此随机过程实现方案适用于事务具有多方参与但仅需要同一批随机结果的应用场景,例如棋牌游戏中每一局的洗牌顺序等。
方案三
 当前的区块生产者接收到随机事务,通过随机函数生成一个随机结果并将随机过程与随机结果通过加密函数加密写入区块数据,并打包发送到全网,其余普通节点接受该随机结果并应用,以此完成随机事务的共识。
这一随机过程的实现方案已经完成,适用于游戏中的抽奖场景等,如掷骰子产生一个随机结果。
定时器和心跳
几乎所有的游戏与应用都需要实现在线检测,而在Cocos-BCX设计区块链游戏时,为了解决用户的状态检测与持续的会话机制,提出了定时器与心跳的概念。
在区块链网络中实现定时器首先需要实现时间同步机制,而传统的时间同步机制通常是由外部授时或信任中心实现的,而在区块链去信任的逻辑下,外部授时或信任中心都存在无法自证的缺陷,因此链上时间的同步只能由链内完成。
Cocos-BCX提出的时间同步方案是:利用块数据时间戳,出块节点在发布块时即等效的进行了时间同步广播,各节点收到块广播后完成时间同步操作,最终全网在一个块同步周期中完成了一次时间同步过程。
基于这个设计,Cocos-BCX提供两种形态的定时器技术支持:
 定时器以块周期为最小计时粒度,按照预先设定的计时目标工作,由区块数据时间戳为标准时间计数,可认为是全网统一的计时标准,计时器可以在任意网络区域、时区以同样的计时规则正常执行;
 采用与内源可信随机过程类似的消息传递机制,以委托方式将定时器所需参数提交至随机节点,并由该节点上的实现层执行定时器的初始化与到期通知等行为。
心跳与定时器相近,其心跳的时间脉冲同样来自于区块的时间戳,一个心跳周期中,节点/端会提交自己的连接更新信息,如果发现某一周期没有特定的端/节点更新信息,则证明这个端/节点掉线,定时器和心跳为用户状态检测和未来的会话机制提供了应用基础。
标准化的非同质数字资产
非同质数字资产扩展数据区域支持非同质数字资产属性扩展,是该资产支持的世界观内游戏具体业务数据的存储区域。非同质数字资产中扩展数据区域的结构设计非常灵活,允许游戏或其他业务场景对其进行扩展。随着游戏增加,资产在不同的游戏中迁移时域数据必然逐渐追加,若追加太多则会影响区块链链运行效率,同时为了防止合约恶意写入大量数据导致用户资产数据冗余,因此我们增加资产合约权限控制观念:
 用户有权删除但不能修改该资产中某一个域的数据,可减少数据冗余的同时防止如自定义增强版的道具等作弊行为;
 合约能且仅能修改自己所负责的域数据。合约可以读取非同质数字资产扩展数据中所有数据,但是修改权限仅限于当前合约所处的域中。例如在区块链游戏世界中,合约可以读取《风暴英雄》和《魔兽世界》的相关资产数据,但是《风暴英雄》中“霜之哀伤”不会在《魔兽世界》中被“灰烬使者”真正斩断,而只是在《魔兽世界》呈现“斩断状态”。
既定规则设计工具
在真实的游戏应用场景中存在这种情况,用户认可某款游戏公开的规则并选择参与,在游戏开始之前开发者临时修改合约代码更改游戏规则来使自己受益,或者将众筹的资产转移之后不再为用户提供游戏服务,这些行为都会给用户带来资产损失,既定规则设计工具就是为防止此类现象而开发的。游戏开发者可以选择使用针对区块链游戏的既定规则设计工具来设计区块链游戏以增加用户的信任,其原理是由智能合约实现将一定数量的同质资产锁定,并且设置解锁的条件、时间以及数量,合约代码中加入资产在锁定期间内不能对游戏规则代码进行修改的工具函数,资产在锁定期合约代码无法进行任何修改,因此游戏只能按照最开始设定的规则进行。

防止BP/开发者作弊的事务验证机制

BP作为全网的事务处理与通信核心,能够先于一般节点获知最近事务的处理结果,因此对于某些具备时效性或机密性的信息,BP拥有较一般节点更高的优先权,因此具备了从信息获取方面作弊的可能,例如提前获知一个随机过程的结果并利用合约提前预测运行结果等,这对链上的游戏无疑是不公正的,也是不安全的。
开发者在这里包括链网络的底层开发者以及合约开发者等一切有能力进行一定程度链交互/改造能力的个人或组织,开发者具备深度解析/控制链内信息的能力,并且有理由相信开发者能够通过阅读代码等方式获知传输过程中可能会使用的加密/隐蔽通信技术细节从而使之能够针对性的设计代码从而以非法方式获知这部分信息(随机过程、敏感信息数据等)。
因此BCX方案中设计了一套针对BP和开发者可能作弊环节的事务执行、消息传递、运行机制,将在下文中简要介绍。
动态加密传输
为防止敏感信息在广播传输过程中被监听并解析,BCX链网络通信针对这类信息增加了使用动态加密的安全通信方式,如图3-2-16所示。

3-2-16 动态加密传输机制

3-2-16 动态加密传输机制

以随机种子的产生为例,当一个随机种子被产生后,生产者将把一段与时间、块高度、其他噪声输入等相关的动态数据作为AES密钥加密这段随机种子信息并广播加密后的信息。由于所有的节点拥有同样的动态密钥生成算法,因而可以正确的解出种子信息,而非法窃听的第三方无法解出,保证了敏感防止自定义节点接入网络
保证信息的传输安全并不能防止节点开发者通过修改程序来达到输出收到并解密后的信息,因此本方案中设计了一套身份验证机制用以防止修改后的节点程序接入链网络,如图3-2-17所示。

3-2-17 节点接入验证机制

3-2-17 节点接入验证机制

BCX节点程序将在发布时内嵌一个不包含在公开源代码中且与版本号关联的验证信息,当节点试图连接链网络和其他节点时,其他节点将会验证这一信息是否与链网络中记录的校验信息一致,并会主动拒绝无法通过验证的节点连接,防止修改后的节点程序连入链网络进行恶意行为。同时二次开发者也可以通过自定义源代码中的这一身份验证信息,发布属于自己的链网络,并将同样具备防止非官方节点接入的特性。
隐藏过程变量
由于合约自身是一套图灵完备的状态机系统,因此固定的输入一定会得到固定的输出,并且在事务机制下将结果广播至全网同步,而如果广播的信息是一系列行为的中间过程,则可能导致一些不适宜被获知的过程变量被公开。因此本方案针对这类情况,提出了使用隐藏过程变量的合约执行逻辑,如图3-2-18所示。
通过合理的合约设计,将涉及敏感数据的过程变量放在同一个操作(OP)过程中执行,由于执行过程在执行节点内存中完成,最终广播的是操作结果,因此过程变量在整个周期中是被隐藏的,不会存在暴露的风险。

3-2-18 过程变量隐藏机制

3-2-18 过程变量隐藏机制

带有执行身份验证的合约机制
为了防止恶意的开发者通过测试性调用合约接口来预测合约的可能输出,本方案的合约系统中增加了执行身份验证机制,即合约特定的接口需要具备授权的账户才能够执行,如图3-2-19所示。

3-2-19 带有执行身份验证的合约机制

3-2-19 带有执行身份验证的合约机制

当合约收到执行请求时,会验证请求信息中的签名信息,与合约中规定的执行者权限验证,验证通过的执行者请求才会正常执行合约函数,否则合约将直接结束,并且不会返还请求者支付的费用,在这套机制下, 即便开发者知道链与合约的代码,了解执行过程和原理,也无法恶意调用特定的接口,保证了合约无法被随意调用推测其执行结果。
敏感过程通过内部可信环境执行
对于在一定时间内持续敏感的信息或操作过程(例如一场牌局),本方案允许阶段内的执行逻辑在TEE(Trusted Execution Environment, 可信执行环境)机制保障下以黑盒模式运行,平时链网络通过TEE保障机制对这些黑盒环境发起周期性的挑战/验证以保证环境的可信,并在需要执行持续性敏感过程时随机选择一个其中一个环境运行,过程执行完成后将向链上提交足以回溯执行过程的记录信息与结果信息,以保证链网络上记事的公正、公开、透明。其原理如图3-2-20所示。

3-2-20 敏感过程内部执行机制

3-2-20 敏感过程内部执行机制

在这一机制的保障下,开发者与BP均无法参与黑盒过程的执行,因此可以有效的避免两者从中作弊的可能,结合上述各个保障设计,可以让Cocos-BCX以可信、可靠、安全的执行环境运行所有支持的业务过程。


3.2 技术架构


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.