为什么EOSBet不敢开源？

你好，我是不羁，一名程序员，带你玩转EOS智能合约开发。如果你对EOS智能合约感兴趣，欢迎关注我的专栏。

简介：我是一个一直以来倡导智能合约开源的人，不过最近看到EOSBet竟然不开源，甚是惊叹！竟然有那么多用户在玩一个无法自证公平的游戏！所以本文就和大家探讨一下项目方不开源的原因。

EOSBet是“谁”？

EOSBet是一个基于EOS做博彩类的团队，目前只有一个dice项目。

dice就是掷骰子游戏，但可别小看这个项目，它每天参与游戏的资金达到100万EOS以上，给EOSBet团队每天带来2万EOS的利润。真可谓日进斗金。

为什么博彩类游戏在EOS上会这么火呢？如果你问一个玩dice游戏的人，“你为什么玩这个dice游戏？”，我相信他会这么回答你：

• 第一，每个人都有以小博大的侥幸心理
• 第二，它是基于区块链的，透明公平，不像其他的赌博网站，站长可以幕后操纵结果

是的，人们认为区块链是透明可信的，所以只要基于区块链的游戏，就是透明公平的。

真的是这样吗？

答案是否定的。

每一个dapp都有一个与之交互的智能合约，我们在区块链浏览器上可以看到和智能合约的所有交互过程，而智能合约内部是一个黑匣子。以EOSBet的dice游戏为例来看，我们所能看到的是，我们给eosbetdice11合约转账，并在memo里填上2到96之间的任意一个数字，假设我们填的是50，过了一段时间，智能合约告诉我们说，随机生成的数字是51，我们这局输了。但我们是怎么输的？“不知道，只能从他们的官网上看到，他们会进行一些随机数的运算，但这些随机数怎么运算的，我们也不知道”。

这就是问题所在了，因为智能合约是个黑匣子，也就给了项目方藏匿猫腻的空间：

• 他们可以在智能合约里，把我们的盈利概率减少3-5个百分点，而我们却毫无察觉
• 即便我们统计一下历史记录，可以得出智能合约把玩家的盈利概率减少了3-5个点，官方也完全可以说“这是随机样本误差本来就存在，3-5点的误差很正常”；
• 如果项目方在智能合约里，增加小赌注玩家盈利的概率，而减少大赌注玩家盈利的概率，那么采用统计学来判断项目方有没有在智能合约里藏有猫腻的方法，也失效了。

总之，如果智能合约没有开源，我们根本无法判断一个dapp项目是否公平。

其实，在一个月以前，我听说EOSBet将要上线的时候，我想它一定会开源的，因为博彩类项目搬移到区块链上，相对于传统网上博彩游戏的优势，就是项目方可以通过开源以及源码验证的方式向用户自证清白，这样，人们可以不用去拉斯维加斯和澳门，就能玩公平的博彩游戏。

所以，当我发现EOSBet竟然没有开源，我几乎惊呆了。
要知道，博彩类游戏的随机性设计对于玩家的利益来说至关重要，它应该被精心设计并且公开出来，如果这么重要的部分都没有开源，玩家的利益还有何保障可言？与玩传统的网上博彩类游戏又有何区别？

那么EOSBet为什么不开源呢？

不开源的原因

我想，项目方可能有如下三点考虑：

• 第零，很可能项目方本身就想藏猫腻。关于这点我们就不展开了，总之，只要不开源，这种可能性总是存在的。
• 第一，怕被人发现漏洞
• 第二，怕代码公开了之后，别人抄袭
• 第三，存在不可公开的算法，怕开源之后，黑客利用该算法产生不利于项目方的结果

先说第一点，如果智能合约代码开源了，黑客发现漏洞就更容易了。如果代码真的存在漏洞，而黑客没有告知项目方，而是偷偷了利用这个漏洞盈利，那么项目方就损失了。

其实我觉得这个情况，可以通过机制设计来解决。

• 首先，智能合约应该设计安全检测能力，当发生异常情况时，应该自动锁住合约，暂停游戏。
• 其次，应该在上线之前，对发现漏洞的同学给予悬赏，这样，即便黑客在发现漏洞之后，就会有动力告知项目方，如果他想把漏洞隐瞒不报，那么其他的人报了，奖赏就会被其他人领走，所以各个“黑客以及白客”之间，就会产生一种良性的竞争关系。最终大家共同受益，黑客拿到了赏金，项目方提前修复了漏洞，避免了损失。

第二点顾虑，很可能是项目方最主要的顾虑，不过我觉得其实没太大必要，有没有源代码，都可以一样被“抄”，没有代码，可以抄界面，抄交互设计，只是抄的速度慢一点而已。就EOSBet而言，技术上没有多少难点，形成不了门槛，真正形成门槛的是运营和社区认同。EOSbet的营销做的很到位，但因为没有开源，我预计社区认同会越来越弱。

再说项目方的第三点顾虑。你可能会惊讶，“还存在这种漏洞？”。是的，是存在的；当然解决方案不是没有，只是项目方可能没想到，或者担心用户使用起来太复杂。

要解释这个顾虑，需要费一番功夫，我们一步步来看。

随机数之“伤”

我们就以随机数的生成为例吧。随机数生成算法几乎对于各类游戏来说，都是至关重要的。
好的随机数，有两个主要特点：

• 结果是零散的
• 结果是不可预测的

其实，准确来说，第二个特点包含着第一个特点。不可预测性是优良的随机数的基本特征，这里的不可预测，不仅指任何人都无法对每次结果进行精准预测，还包括任何人都不能对每个结果的倾向性进行预测。就像仍硬币，如果仍的人有个习惯性动作，这个动作能让你在他仍硬币之前，就能判断出结果是正面的概率大于50%，那么此人仍硬币的过程，就不是一个好的随机过程。

你可能会说，“生成随机数吗？so easy，C++上面有一堆生成随机数的库，拿过来用就好了！”，

对不起，在EOS智能合约上用不了。智能合约中能够使用的C++接口都是通过webassembly虚拟机提供的，暂时没有random接口。另一方面，因为区块链产生的每个区块，都要求是可被其他的节点验证的，也就是说，一个智能合约的执行结果，在不同的节点上执行，结果必须是相同的，这种确定性与随机数的不可预测性存在一定的冲突。

一个随机数的例子

我在stackoverflow上搜索到了这样一个内容，是EOS knight实现的一个随机数生成器：

Screen Shot 2018-09-20 at 11.13.52.png

我去EOS knight的github中搜索了一下，现在已经没有这部分代码了，也没有任何其他的智能合约部分的源码了。

这部分代码很好懂，我就不解释了。你可以看到，它生成的随机数的确是零散的，但并不能满足不可预测性。
为什么呢？
因为这个随机过程的结果完全依赖于当前的时间和玩家的账户，那么我就可以在交易产生之前，提前预测某个时间，该随机过程产生的随机结果。你可能会说，“这个current_time()返回的是毫秒级别的，你怎么可能把你的交易时间控制的那么准确？刚好就在你预测的时间完成交易呢？”。

实际上current_time()是秒级别的，虽然文档中说返回的毫秒，但后面都带有3个0。
即便将来EOS可以精确返回毫秒级别的结果了，我也可以跟就上面算法，预测某一秒钟内，所产生的结果的倾向性，或者说，可以预测产生的结果在什么范围之内，这样我就可以利用这个特点来盈利了。

再回到EOSBet的dice游戏，如果它采用了上面的随机数生成器，对于普通玩家来说，没有任何问题，这个随机过程挺好的，很零散。但黑客就可以根据时间提前预测骰子的点数的概率，从而稳定盈利了。这样的话，项目方就亏损了。

EOS knight最初应该也是把智能合约开源了的，后来又不开源了，想必也是这个原因吧。

的确，在智能合约上产生一个不可预测的随机数是一个难题，不过不代表项目方必须把智能合约藏起来，其实可以通过在机制上解决随机数的生成问题，早前在ETH上人们就想出了解决办法，不过解决办法不是很完美，但完全能应对dice合约的需求了。至于如何做，我们明天再聊。

留一个问题给大家思考，学过C++的都知道，向系统请求开辟一块内存时，该内存的地址是不确定的，那你觉得可以利用这个特点，在智能合约中生成随机数吗？

欢迎留言探讨。