EOS vs 以太坊：一位游戏开发者的对比实测

本文作者为 Dexaran，他是一位智能合约开发者及安全工程师，创立了 EthereumCommonwealth 以及 Callisto，同时，他也是 ERC223 的创建者。Dexaran 在以太坊等多条链上测试开发，最近他开始尝试在 EOSIO 上开发游戏，并将实测体验记录了下来。他从游戏开发过程、智能合约经济系统、EOSIO在不同类型游戏中的适用性等方面进行了分析，同时将 EOSIO 与 Ethereum、EthereumCLassic、ADA、CLO、UBQ、EXP 进行了对比评价。

背景介绍

很久以前，还没有区块链技术的时候，我就已经是一位业余的游戏开发者了。

在以太坊出现后，我曾经在上面试着开发游戏。那时我亲身体会到，受限于以太坊平台的架构，开发者是不可能在以太坊上开发出有深度的游戏，以太坊最大的缺陷是：交易手续费。

现在 EOS 出现了，它是目前在技术上最领先的智能合约开发平台，而且目前看来 EOS 的领先优势将持续多年，我还没有看到其他的竞争对手能与 EOS 的开发平台相匹敌。

我已经在 EOS 主网上开发出了一款游戏。本文中，我将描述我在 EOS 上开发所遇到的问题，以及我从开发者的角度评估 EOS 平台。

开发此游戏的主要目的是研究 EOS 智能合约开发平台的优点与缺点。因此，游戏性与游戏平衡并没有进行优化，用户界面的参考设计主要用于测试 Scatter 与其他 EOS 钱包的功能。我有计划在未来开发更复杂的游戏，如果你想参与其中，请与我联系：[email protected]

参考资料

在这里可以找到游戏的详细说明
智能合约的源代码在这个资料库中
上链 EOS 主网的智能合约是 dexaraniiznx
用户界面 https://sparke2.github.io/universex-ui/

游戏开发

时间投入占比：

游戏核心开发：20%
(!) 储存清理功能：13%
故障排查：61%
制作游戏开发所需的工具：6%

智能合约经济

我尽可能让游戏合约为玩家支付主网资源。

这个简单的游戏需要约 1MB RAM（90 EOS），以支持 20 名玩家，默认一般的玩家在游戏中控制地图中的 5 格。

游戏中，700 KB 用于合约代码，300 KB 用户储存玩家资料。如果有更多玩家加入，合约将需要更多 RAM。

简单算了一下，如果这个游戏要给 5,000 名玩家玩，开发团队需要准备好 6,000 EOS，平均一名玩家需要用到 1.2 EOS 的资源。

预设游戏需要在每 X 分钟刷新一次游戏状态，以更新游戏中的资源收入及完成进行中的任务并且自动显示最新状态。不巧的是，目前 EOS 主网有 30ms 交易执行的硬限制，这样，游戏的地图不能在一次交易中完整更新，所以游戏在每次交易中，只能更新 100 格。游戏每 6 分钟刷新 100 格地图，需要消耗 2 秒的 CPU（相当于 15 EOS），这样能实现智能合约的永久自动更新，但在网络阻塞的期间，自动更新将会失效。

基于 EOS 智能合约做游戏设计的几个要点

EOS 主网只适合部分游戏的开发，这些游戏要避免：即时反应、同时处理大量输入。所以，EOS 最适合以下几类游戏：

回合制策略类

“菠菜类”
桌游类
玩家输入少的持续性游戏
在开发游戏界面时，我们搭配 Scatter 使用。我们发现在 “ 决策 ” 与 “ 执行 ” 之间有很大的时间差。

虽然 EOS 每半秒出一个区块，但在玩游戏时，用户界面的操作会带来延迟。即时在 Scatter 中把交易列入了白名单，在玩家点击按钮到游戏执行交易上链也需要花将近 3 秒钟的时间。

如果玩家的反应速度在游戏中是个因素，那么 EOS 将不适合这个游戏的部署。

Scatter 节点与一半的 EOS 节点在俄罗斯是受到屏蔽的，在俄罗斯，用户很难连上 EOS 主网，一般需要通过使用 VPN。

合约存储的清理是很繁琐的工作。我花了很多时间在开发合约存储的清理功能上，因为命令执行都需要从合约内执行，所以代码的逻辑很复杂，同时要不断的重复测试此功能。如果改变了数据结构，合约将会停止更新或清理，开发者将不得不回滚合约，清理存储，重新更新合约，再次初始化数据结构。清理大型数据结构将超过 30ms 交易 CPU 限制，让清理工作保持迭代至关重要。

游戏合约无法实现自动更新，开发者无法让游戏每 X 分钟自动更新一次状态，这就是为什么 EOS 只适合一部分游戏开发的原因。

唯一能更新合约的方式是执行合约动作的交易，在 EOS 主网上唯一能预约交易的方法是提交一个延期交易（deferred transaction)。理论上，开发者可预约一个延期交易，让智能合约执行动作，以造出（同时创建）下一个延期交易，如此反复执行。如此，合约的状态就能定期自动更新，但 EOSIO 的官方文件中有提到 “开发者不应该默认延期交易必定会执行，软件设计不能依赖于此”。

我设计的游戏是含有自动定期更新的功能，在 EOS 主网阻塞时，游戏的自动更新会中断，在游戏测试期间，平均每一周遇到过一次因主网阻塞而导致游戏更新失败。

来自于 EOSIO 的官方文件：

原来 EOS 主网不适合做持续性的流程执行，这让我很担忧。

理论上，我们能设置一个侦测服务器，以检测所有需要持续更新的合约。当合约自动更新失败了，这个侦测服务器能再次启动合约的运作。但这会造成另一个问题：如果我们需要一个中心化的服务器以确保合约的运行，那为何不抛弃 EOS 主网，回到主流的客户端服务器架构（client-server arcitechture）？

我是个游戏开发者，我为什么要在 EOS 上做开发？

坦白说，用区块链平台做游戏开发只有一个理由，那就是区块链带来的收益机制，而且这是足够吸引开发者的理由。但从另一方面来看，EOS 有几个严重的缺陷，其中最大的问题是平台不能做交易执行的安排，这样将不适合很多去中心化软件的部署。

而且，在 EOS 上开发游戏会增加开发的复杂性和开发费用。EOS 主网上有许多额外的限制，还有安全性的疑虑。

EOS vs 以太坊

在以太坊很早期的时候，我就在开发以太坊的智能合约了，我对以太坊平台的缺点了如指掌。

很高兴今天我们有了更好的选择，也有在之前的文章中提及。EOS 是智能合约平台的领先者，它带来了许多以太坊缺少的必备功能：

C++。说实话，真的没有必要为了开发智能合约而去创造一个新的电脑语言，尤其当市面上已经有了实战经验丰富，开发者认可的编程语言，完善的工具库及可靠的编译器。Solidity 是个失败的案例。
可升级的智能合约。毕竟在复杂的软件中，代码都会有漏洞，能让智能合作做升级，有效的提升了合约的安全性。
免费交易。小额交易是许多区块链会遇到的问题，只有让交易免费才能解决这个问题，EOS 就是如此。
通信模型。以太坊的 ERC20 代币缺少了响应事件的机制，这意味着所有的 ERC20 代币都是不安全的，我们也看到以太坊社区因此丢失了巨额资金，目前看来以太坊没办法解决这个问题，唯一的解决方案是打造出全新的平台、标准、开发方式。
性能。EOS 能实现软件开发，以太坊慢到实行循环指令会让人看不出逻辑。

对 TRX 的看法

虽然我不是很喜欢 TRX，但看来它已成为今天第二大的智能合约平台。TRX 有针对一些以太坊的问题做改进，其平台也算是能用。

我看过许多 TRX 的智能合约，我们 Callisto 也做了几个合约审计。

有几个 DAPP 是有活跃用户的，包括 WINK 在内（虽然其价值体现在优秀的用户体验上，而不是游戏玩法）

我不喜欢 Solidity，也不觉得 EtherrumVM 有什么价值，但我做的 GalaxEOS 游戏可以在 TRX 上开发出来。

对 Cardanno (ADA) 的看法

社区对 ADA 的讨论一直很热烈，虽然项目点子很好，但目前开发者还不能在 ADA 上做智能合约的开发。

结语

EOS
我的游戏能在 EOS 主网上开发出来，但需要其他系统的支持，我需要一个中心化的服务器以确保合约会持续运作。

如果我还需要这个额外的服务器，那么我需要评估是否用 EOS 或主流的客户端服务器架构。我认为在 EOS 上开发唯一的好处就是：收益模式。我将持续在 EOS 上做合约开发，我相信我上述提及的问题将会被 EOS 或其他区块链平台解决。

TRX
我的游戏能在 TRX 主网上开发出来。

以太坊、以太经典、ADA、CLO、UBQ、EXP
我的游戏不能在这些平台上开发出来。