BCX剖析,一键发布Dapp的游戏平台来了(2)
时间:2024-02-16 23:12 来源:网络整理 作者:墨客科技 点击:次
Cocos-BCX 中,所有的预定见证人都由所有的持股人从见证人中投票选举,预定见证人统称为活跃见证人,活跃见证人数量通常为 11~21 个。所有的活跃见证人在 DPOS 共识算法的见证人预定算法中具有相同的出块预定概率,这保证了所有见证人的出块概率和获取出块奖励是一致的。石墨烯投票更新时间通常为 24小时,但处于安全性、稳定性、公平性的考虑,项目初期网络投票更新时 间通常较短,可能为 12 小时甚至更短。 在 DPOS 算法中通过预定见证人和规定时间槽位来推测区块的生产者以及出块时间,主链的活 跃见证人总是多于支链,故此主链区块高度一定高于支链,同时全网投票机制避免了见认证人集中化,保证了网络的安全性,不同见证机制之间的优劣对比如图下所示。
另外,人们普遍关心的是交易处理能力,尤其是对于游戏应用场景,交易处理能力与速度都是很关键的。Cocos-BCX是通过“高效合约虚拟机”和“极小时延相应机制”两个实现的,这与大多数只关注吞吐性能的链项目有一些区别: 目前的绝大部分联网游戏,当用户规模达到一定程度时,其服务器需要在短时间内进行大量的 数据处理,而在现有的以太坊网络中是无法实现的。Cocos-BCX 采用改进的 DPOS 共识,理论吞吐量约 10 万 TPS,其高并发处理性能在合理的数据管理模式设计下足以支持现有游戏的开发与正常运行,理论上基本满足大型联网游戏在平台中的运营诉求,但想让用户的游戏体验与现有的中心化online游戏几乎没有区别,应该暂时无法在技术上实现。 由于大规模网络游戏的数据交互频率非常高,DNF 曾创下 60 万人同时在线的记录,Steam 游戏 平台更有 1420 万人同时在线的惊人数据。如果每一个在线用户提交数据的行为都视为发起了一次共识申请,Cocos-BCX 的极限吞吐能力不足以支撑这样级别的处理请求,开发团队按见证速度的需求 设计了不同的见证委托模式(Delegation Templates),使单一见证委托人不用对所有运行中的游戏 作同时见证和处理,而是专注于对复数个同类型游戏作见证和计入区块的工作。并且,在这一模式下,不同游戏的数据提交见证是相对异步的过程,每一个游戏会选择适合的委托模式,而异步模式下的数据验证则可以通过链上数据库服务来完成,即用户在链上验证并完成数据存取。这一过程非常高效,足够支撑大规模游戏场景下的玩家数据操作。
为了保障合约执行的效率足以向用户提供足够良好的游戏体验,Cocos-BCX 重新设计了一套针对链上游戏场景的基于 LUA 的高速合约虚拟机方案。不同于现有区块链的合约虚拟机方案,除了通过大幅定制和优化现有的区块链运行环境及合约虚拟机的执行效率外,Cocos-BCX 的虚拟机使用与 游戏 SDK 相同的语言和 API系统,并提供链和游戏执行环境的互操作接口,这将彻底改变区块链合约环境单一、灵活性差、定制能力差的现状。智能合约的应用场景将不再限制于作为货币描述,而是开始能够接纳更多与游戏直接相关的内容,包括可能的诸如:基础规则、设定、单位、场景、甚至地图等。改进后的虚拟机不仅支持更为复杂和灵活的合约形态,并且将大幅度提高现有智能合约的运行效率。
除此之外,Cocos-BCX较为引人注意的创新点还体现在支持语法级别的共识任务。 Cocos-BCX 提出了让合约在语法级别支持共识任务的设计,通过将脚本中需要共识的部分以特定的关键词修饰,使合约解释器能够识别并在运行全文扫描时将标记为需要共识的合约部分拆分出形成子合约发送至链网络的相关节点进行共识。 当合约运行时,合约整体在本地执行,到达需要共识的部分时,得到链网络返回的共识结果并继续执行,此时实际上合约主体的运行过程与共识过程是两个相对独立的异步过程,使游戏合约的运行更加流畅,可能发生的阻塞等待更低、时间更短。 (责任编辑:admin) |


