链·游戏丨聚众互动CTO霍兴凯带你解读“棋牌游戏公链”

2018-08-02 - 公司动态  阅读量:6765

2018年中国国际数码互动娱乐展览会(ChinaJoy)于8月3日-6日在上海新国际会议中心隆重举行。今日,由ChinaJoy首设“中国区块链技术与游戏开发者大会”在上海浦东嘉里大酒店正式召开。该大会是中国最具前瞻性、国际性、专业性的游戏产业研发技术会议。


本届中国区块链技术与游戏开发者大会以“链·游戏”为主题。基于区块链技术开发游戏,已被全球游戏从业者视为重要发展方向之一,此次会议将从各个层面深度探讨如何将区块链技术与游戏技术相结合,让更多游戏开发者轻松将游戏上链,分享区块链技术带来的创新和利益。


本届大会,邀请到诸多海内外应用区块链技术的游戏企业及业界专业人士。其中,聚众互动作为国内棋牌游戏行业的“先行者”,其首席技术官霍兴凯先生应邀出席大会,并发表《棋牌游戏链的业务执行和VM设计》主题演讲,展示公司自进入区块链行业以来的研究成果,以及他个人对区块链技术在游戏行业应用中的独到见解。


霍兴凯,聚众互动CTO,Nexusguard 云平台创始团队成员,在电信运营商、游戏、网络安全等行业研发岗位任职多年。为多个东南亚互联网集团、银行提供防攻击服务,为多个国家的电信运营商提供安全服务方案和技术平台,是华为云安全在海外的技术提供方。



此外,霍兴凯先生是资深区块链游戏制作人,主导、参与数款区块链游戏研发;为全球十余款区块链游戏提供技术平台、安全服务方案及防攻击服务。 


以下为演讲内容实录:


“大家好,我是聚众互动CTO霍兴凯,也是KKGame区块链游戏开发平台的技术负责人。首先简单介绍一下,KKGame是基于区块链棋牌游戏的一个开发平台,它主要承载的是棋牌游戏业务,是棋牌游戏这个平台上面的一个基础价值体,它是一个一般等价物。”

 

棋牌业务的主要特点是:

1. 基于共识的区域化规则

2. 趋同性高、细节复杂、灵活度低

3. 价值流转频繁

 

“也许在坐的小伙伴们有人是做棋牌的,而棋牌游戏也非常符合整个区块链业务的模式,因为棋牌业务的本身是一个相对来讲可以发挥、或者可以创造的空间很窄的一个门类。棋牌业务其实是有一个基础共识的、是一个有玩家认知游戏规则的,而且在大量的棋牌游戏里面,实际上我们运营棋牌游戏的基本规则几乎是趋同的,它是一个特别完整的逻辑体系,逻辑本身是不可修改的,棋牌游戏本身最终承载的是一个价值流转,价值流转的过程会比一般游戏体现的更重要和明显。”


棋牌业务执行过程:

1. 可控的有限变量下执行的严格判定

2. 确定性的结果

3. 过程可追溯,结果可验证

 

“在具体的业务执行过程中,因为棋牌游戏几乎是在一个可控的变量下执行的一个逻辑过程,不像其他类型游戏有大量可以设计、可以规划、可以去发挥策划的空间。棋牌游戏是在非常有限的一些条件下执行的过程,最终业务的逻辑是确定的、结果是确定的。而且棋牌游戏的业务本身,对逻辑的完整性和最终价值的转移的确定性要求又比较高,并没有更多的发挥余地,也不能产生更多的错误。其他类型游戏包括有Bug或者回档,其实还是比较常见的,但是在棋牌游戏里,玩家对于这些Bug几乎是零容忍。”

 

公链待完善的基础技术:

1. VM&Contract language

2. 智能合约的结果验证

3. 智能合约隐私保护


“前面介绍的基本上是棋牌游戏的业务,这次主要讲的是我们在基于棋牌游戏这个业务上更多的去设计我们的公链。我认为现有的公链上有三个基础点其实是可以发挥或者说是待完善的,毕竟现在基础的基础点基本上都完善了。第一个是VM,在VM这个方向上,主流的VM其实是从以太坊开始引入了EVM这套虚拟机机制,这套机制初期并不是很完善,比如它的语言;第二个是合约的结果验证机制,以太坊的合约验证机制其实非常消耗资源,它用了一个几乎全网、全验证的方式去验证执行结果,这个结果可能对于基础性公链来讲会比较适合,但是对于一个业务性链来讲付出的资源成本太高了;第三个来讲智能合约的隐私保护问题,据我了解,现有的所有公链上能跑的大概只有四种VM,第一个就是EVM,EVM它发展了2-3年左右的时间以后相对比较成熟,但是它上面的语言不太成熟,EVM上面已经大概有4-5种开发的语言了,上个月又推出了一个新的语言,可以说VM上面过多的开发语言和过于频繁的这种勾叠实际上对开发者来讲是非常迷茫的,第二个是EOS引入了新的虚拟机和新的开发语言,EOS这边它主要的开发语言是C++,C++这个问题呢导致在EOS上面开发的合约很复杂,合约的复杂度从而引入了很多安全性的问题,对代码审计来说也是非常复杂、麻烦的,而且因为面对对象的整个开发合约的机制导致他的Review的成本非常高,引入了太多人为的不可控因素。国内现在有些开发的公链在用JavaScript的比较多,底层主要用的是V8,V8这个引擎在JavaScript引擎中它是一个比较好的,用V8这种引擎跑智能合约的话他有一个最核心的问题就是,V8这个引擎本身是带垃圾回收的,带垃圾回收之后引入了很多不确定性,因为合约的执行其实是在可控的时间内、可控的资源下完成自己的任务,但是垃圾回收实际上是对整个性能和整个合约执行影响非常大的一件事。Lua因为产品公开发布,就不具体说是哪一家了,他们现在准备用Lua做这件事情,Lua本身VM实现的还是不错的,但是它4.0和5.0差别比较大,不太确定是准备用Lua4还是Lua5来实现他们的VM,他们VM的问题就是怎么设计,相应的GAS机制有一定工作量,所以还是没有那么方便实现的。”


VM&language设计方向:

1. 增强EVM

2. DSL 解析器 语义模型 业务模版

3. 从ByteCode开始设计Virtual Machine


“下面来说一下VM整个的language的设计方向,现阶段在整个行业公链里面,除了EOS和以太坊很确定的实现了他们整个的合约机制和语言之外,其他很多公链其实还在探索和完善这件事情,第一个方向就是要增强EVM。很多公链宣称是兼容EVM,我认为他们就是整个fork了一下EVM这个代码,可能不是fork官方的代码,因为EVM有多种语言和有多套实现,他们用某一个实现完成了他们所谓的VM的底层的构建,或者是增强了他们的VM构建。其实在区块链当中设计一个VM不是很复杂的事情,但是要完善它的话工作量还是比较大的,说起来在整个国内实现过VM的人可能很少或者项目很少,反而很多做游戏的小伙伴大约在十年前,可能是最后一波做3D网游的这些兄弟们反而实现过自己的VM,在当年Lua和以太坊没有那么流行的时候,MMO上的3D游戏内其实是有自己的某种类似VM的机制的,有一点点自己的小脚本,几乎每一个大厂商都有自己的小脚本,这套东西其实在游戏行业里很多同学都实现过;第二个方向是做一个DSL,DSL我前面讲过,实际上很多做游戏的小伙伴实现过某种DSL,大部分DSL并不是图灵完备的,只是基于业务的实现了表述自己的业务,可能是根据策划的需求,可能是根据运营的需求,逐步完善了一套DSL,但是这个东西是根据业务生长的,不是一个完整规划的东西,但现在,在现有的方向做一个垂直行业的公链里边,实现language方向做DSL是一个好的方向,因为业务是确定的,而且DSL本身已经在游戏圈子里面有很多年的经验了;第三个方向是从bytecode开始重新设计一整套的VM,从bytecode开始设计呢其实不是太复杂,但是像现有的以太坊和EOS,他们想法太大了,他们要承载太多东西的时候,他们把整个的底层基础太开放了,这并不一定是个好事情。做行业链的话,如果不单参与设计的时候反而要收缩自己的想法,要抑制住自己想要承载一切的这种想法,设计一个更简单的东西出来可能会更好一些。”


KKGAME VM设计:

1. 从业务模版始设计

2. 由上至下的设计理念

3. 抽象语义受限表达性


”KKGame现在整个平台目前还在研发中,讲一下我们从VM这个设计层面上考虑的方向。一般情况下的VM设计是由下而上的,很多真正做过VM的兄弟可能会更了解,比如先去看看CPU是怎么回事,因为CPU的设计是一个很完善的基础,再去看看内存分配、内存管理,然后由下而上的开始设计VM,语言和VM大部分是同时设计的。但是作为一个行业公链来讲,我们想的出发点是从上由下来设计,先定义我们的业务,然后抑制自己过多的想法,以最集中、最准的方式把业务抽象出来,由需求层面向下设计,所以我们在设计整个VM的时候实际上更多的不是由技术人员来做,而是由业务人员来讨论说我们需要技术,给我们提供最小的原型是什么,它应该能完善什么,基于这点我们再来设计,我们在VM这个层面上应该做什么。我指的是VM和language同时设计,VM本身的是图灵完备的,但是language我们抑制住,我们不想做那么图灵完备的东西,而且我们把更多的业务抽象成模板,由模板来实现基础业务而不是给开发人员更多的灵活性,让他们去自己实现业务。因为棋牌业务我前面讲过它的特点,它没有更多的可发展和可拓展的空间,该怎么执行是一个很确定性的东西,在这个基础业务层面上如果没有更多想法的时候,就把基础业务实现好然后抽象完整,保持基础业务的完整性就可以了。”


KKGame业务模版:

1. 通用规则的棋牌类业务模版

2. 区域性规则的业务模版

3. 自治共建的业务模版库


“我们在设计模板的时候,因为国内的棋牌业务种类非常多,比如牌类的斗地主,有大量的地方规则;麻将更多,几乎每个县都有自己的规则,甚至一个县里面会有两三种规则,导致通用模板的抽象层面做起来是非常麻烦的一件事。我们在做整个VM设计的时候,做了大量的调研工作,怎么可以完整的表述在基础的规则之上,可以在业务模板之上做一层更为灵活的表述。现阶段我们只基于在我们已有的业务上在完善这件事,所以我们在VM设计的时候有一定的开放性,给未来更多加入我们这个体系的厂商或者开发者提供了某种自定义的接口,提供了某种可继承、可实现自己的一些业务的空间,这可能需要由更多评审和本身生态里面的小伙伴们共同来决定是否接受这套东西,或者验证它是对的还是错的,因为其业务本身对于逻辑性要求太严格,如果逻辑本身不够正确的话玩家是不太接受的。”


Virtual Machine实现细节:

1. 256bit浮点数怎么处理

2. GC垃圾回收机制3.GAS机制


“设计这套VM的时候,我们在技术方面遇到了许多问题,第一个问题就是对于浮点数怎么处理,我认为目前所有说兼容EVM的这些链,他们没有真的考虑过256bit的问题,这是一个不太好去做业务表述上的数据类型,我认为他们去做这个事情是因为EVM承担了过多的金融资产。金融资产要求浮点数的计算要绝对精确,在这件事情上他们讨巧了,实际上他们是没有浮点数这个概念的,全部是用整数然后做移位,来去处理具体金融资产的小数。但是如果做行业链的时候,在除了金融资产以外,有大量业务逻辑的时候,用一个超长整数处理业务逻辑,首先这对开发者非常不友好。所以我们在设计VM的时候,把金融资产用类似于以太坊的解决方案,做了一个超长整数,但是对于业务数据来讲我们还是设计标准的,比如8位、16位、32位、64位的bit,但这只开放给了模板的开发者,而不是最终开放给了业务的开发者;第二个问题垃圾回收,我们把垃圾回收抑制在一个最小的范围里面,甚至我们想尽量不去做垃圾回收,在一个GAS机制,我认为GAS机制其实是一个对于链上资产的一个分配,或者资源分配的机制,这个机制其实是非常必要的。现有其他的链所谓的某种机制,其实最终会发现资源分配的成本过高,比GAS高非常多,并且对开发者和玩家很不友好。


智能合约结果验证:

全节点同步验证的非必要性


“合约验证的问题,简单讲一下最重要的一点,以太坊现有的链几乎都是全节点合约验证,对于大部分业务来说不需要去全节点的验证你的业务,对于其他人是没有意义的,只要有确定的参与者和非固定的验证节点来保证这个结果是可信的就可以了,并不需要全节点验证。棋牌游戏相对于业务来说就是一个小业务体。”


智能合约隐私保护:

1. 交易

2. 智能合约


“最后再讲一下隐私保护,棋牌业务相对于隐私保护比较敏感,到底隐私保护做到什么层面上,我们也在考虑,现在也有方案在做,棋牌业务很需要隐私保护,但是最终能否实现我们还在努力。”

 

“由于时间原因,今天就分享到这里,谢谢大家!”