7月份的链圈很热闹！
前有以太坊“博彩”游戏，后有EOS的“博彩”游戏。这两个号称最实诚的“赌博”，从上线起就迅速吸引大量用户参与，后面的情节，常在链圈走的老司机想必很清楚：
以太坊的游戏刚刚迎来最终章，奖池大奖被一位幸运玩家赢走；
EOS游戏运行到一周左右的后，账户遭遇溢出攻击，奖池里的7万柚子不翼而飞，最终通过EMAC的努力，由EMAC华语仲裁员发布紧急冻结令，暂时保住奖池中的EOS。
区块链技术起步伊始，参与生态建设的用户、开发者等热情高涨。两款游戏的火爆也引发很多专业人士，尤其是技术人员的思考：区块链技术处于快速发展、迭代的时期，区块链技术如果仅仅满足用户的娱乐需求，似乎是大材小用。
从另外一个角度来看，游戏、带有博彩性质的游戏，作为区块链生态建设的大胆尝试，为开发者提供宝贵的经验。
程序员的锅？
EOS游戏需要用户出让EOS账户的active给游戏指定的账户，这也是该游戏的主要槽点。该次设置使得用户的账户的active权限完全暴露在外，更令人崩溃的是，游戏方并没有做出对应的保护措施和Plan B。
综上可以看出，参与EOS游戏需要对参与同一个合约中的不同角色赋予不同的访问权限。围绕着EOS游戏首选的问题，Celes技术团队对该EOS游戏复盘后得出三种“安全策略”。
01
使用 active / owner权限
这种方案是现在所有合约的常规用法。
对于账号的active和owner权限，如果合约内没有做特殊的权限校验，默认支持访问合约里的所有方法，且传入的account_name可以为任意值。
这是EOS的默认行为，合约内不需要做特殊的处理。
02
使用授权给用户自定义权限访问游戏合约的权限
该方案建议结合用户授权用法，因为该方法比前一种方法要安全，用户不再将自己的
active权限交给游戏方。
EOS账号的自定义权限默认无法访问智能合约方法，如果需要自定义权限访问智能合约里的方法，需要设置账号的action权限。
1）给账号添加一给自定义权限hello.world
2）给hello.world设置访问hello合约 hi方法的调用权限
合约里不需要做特殊的修改，如果需要验证访问传入的account_name,需要在合约里调用require_auth方法进行校验。
3）使用者使用
使用者在调用Hi方法时传入的account_name必须和访问者授权信息匹配，否则无法访问。如：
因为传入的参数和test2账号不匹配，所以访问失败。
传入的参数和test2账号匹配成功后，访问成功！
03
EOS智能合约“特殊权限”设置
上面提到过账号的active和owner权限是默认可以访问所有的合约方法的，那么如果想要禁止这两个权限访问合约里的某个方法，可以采用以下策略。
如果需要指定合约里的某个方法只对某一个权限开发，需要在合约里调用require_auth2方法进行校验。
上面的hi方法除了hello.world权限（上文定义的hello.world权限）可以访问，其它任何权限均无法访问包括owner和active权限。如：
这个就厉害了。
针对EOS的这款游戏，除了账户本身的owner和active权限的设置，需要另外设置一个监管权限的第三方权限，暂且叫它监管权限。监管权限的公钥地址保存在账户手中，私钥权限由公信第三方掌握。
这样的方式，不用出让账户安全给游戏方，即可参与游戏。并且整个游戏引入第三方监管，保障游戏方、参与方的权益。
游戏以外，大有作为
区块链游戏为区块链在其他领域的应用落地提供了丰富的参考经验。
就拿金融行业来说，货币的超强流动性和它天生的特性，让金融监管一直是金融领域的头等大事。
综合来看金融行业的区块链应用的呼声最高。
将上面提及的“安全策略”的第三种方案，应用到金融领域的监管中，再合适不过。
以Celes OS举例，对于参与到金融业务的所有角色，在采用EOS的owner和active权限的基础上，增加监管权限。
根据合约规则，监管机构掌握对应监管权限的私钥，所有集基于Celes OS的金融机构和用户，进行必须接受监管的金融操作时，必须向监管机构发出申请，监管机构收到申请后查验合规情况，最后选择是否授予相应权限。
网友评论