美文网首页
自制eth dapp的心路历程

自制eth dapp的心路历程

作者: bluesky233 | 来源:发表于2018-09-10 00:53 被阅读0次

        前段时间做了一个eth的dapp(http://freeeth.club),趁着现在闲了总结一下这次开发的心得。 当时fomo3d挺火的,我干的第一个事情是把fomo3d合约发布到了测试网,然后再开始开发这个天天抽eth的合约,智能合约用的是solidity, 后台用的是nodejs。

    天天抽eth这款dapp的大致逻辑如下:

        1.  主要操作有:管理员充值,设置当日抽奖金额, 用户参入抽奖, 用户邀请其他人抽奖(非dapp行为,用户分享链接), 开奖 (管理员操作,每天操作一次)

        2. 奖池划分: 70%归当日中奖用户 , 30%归当日邀请用户最多的用户, 10%归中奖用户 (ps: ^_^ 这个奖池划分还是我这个coder想的)

    整体来说,这个项目工作量还好,但初次自己从头做dapp的我,也是遇到这里一个坑那里一个坑。

    第一坑编辑器:

        最开始用的线上remix:http://remix.ethereum.org/,这个时常打不开,还有compile找不到等一些问题,很是无赖。

        后来就用vscode下了solidity的插件做主编辑器,vscode有些语法报错检测不到,没办法就只能安装remix-ide(https://github.com/ethereum/remix-ide), 作为一些辅助检测。

    第二坑搭建开发测试私链:

        智能合约写好了,一般会选择发布到自己的私链上,最开始我选择是ganache,当时先跑的是fomo3d的合约,那个发布要800多万gas, ganache总是报out of gas, 我当时还啥逼逼的想是不是我用的ganache的姿势不对(⊙_⊙), 在google上搜索解决方法了半天,各种尝试就不管用。后来别人推荐说parity好,我立马用parity搭了个两节点的私链,fomo3d的合约发布在parity上妥妥的,parity带UI用户体验比较好,能看到每笔消耗的gas。至此我后面的自己的私链都是选择的parity.

    第三坑调试:

        eth的智能合约调试更像交易记录的回放,在remix下支持已完成的交易的debug,支持单步前进,单步回退等操作,能显示当前的local,全局变量,操作指令等信息。

        但是与传统编程的调试而言:1.操作滞后,必须是已完成的交易,不能实时进行 2.进行复杂逻辑测试的时候,要先构造很多先决交易。

    第四坑智能合约编写:

        智能合约的编写与其他编程的很大不同是,细节要注意的更多,合约一旦发出去就没法修改。我总结了以下几点:

        1. 前置条件判断,一定要考虑的周细,多用modifier, require, asset

        2. 权限的管理,一般会有些操作智能合约拥有者,管理员操做

        3. 合约和外界的交互,基本只能靠事件event

        4. 针对只读函数,可以用 view,pure进行修饰

        5.  多用一些验证的安全库,比如SafeMath

    第五坑随机数选择:

        现在随机数的方案有以下这几种:

        solidity文档(solidity.readthedocs.io) 推荐的方案RANDAO(https://github.com/randao/randao),是个线上合约, 这个方案比较复杂,先要交纳保证金而且还要经历三个阶段才能得到最终的随机数(ps:细节比我描述的复杂多啦),所以不是一个经济和使用的方案。

        fomo3d:  采用区块的特征作为随机的特征来进行随机数的种子,但是可以通过在另一个合约的构造函数内进行随机数逻辑的调用,从来达到刷空投的目的

        vdice: 采用orcalize service+ random.org的方式, 此方案成本过高

        dice2.win: 采用commit-reveal, 提交-揭示方法包括两个阶段,dice2.win第一阶段是玩家进行下注的时候提供存证信息(猜测服务器生成的),第二阶段是庄家进行结算根据存证+blockhash来作为随机种子,在进行判断玩家是否中奖,我做的dapp不适合按照这个方式来进行操作(参加抽奖有很多人,开奖只能是管理员,开奖时间间隔很长,dice.win开奖时间很短)。

        在写这篇文章的时候,发现随机数选取写的相当好的一篇文章(http://www.freebuf.com/vuls/179173.html

        综上,最后我在做这个dapp的时候,用了一个取巧的办法,采用和fomo3d一样的随机数方案,当时只有管理员能够控制,虽然减少被风险,但也显得不那么去中心化。

    第六坑定时触发:

        当时遇到的问题是,想每天定时一个事件开奖。

        在solidity文档中,找的方案是alarm clockhttps://www.ethereum-alarm-clock.com/),大致方案是alarm clock提供一个定时触发的服务,有几个公共的智能合约代我们运行这个定时触发,但是也不保证完全能够定时触发。 更为详细的介绍可以看(https://ethereum-alarm-clock-service.readthedocs.io/

        操作繁琐,且不一定成功,后来我们修改的结算方案,改为开奖结束后的24小时为结束时间,由管理员自己发起交易来触发开奖操作(此操作不频繁)。本来想做一个服务器后台还跑了检测结束时间的服务,来自动触发开奖,后来时间仓促就没弄啦。

    小结:

    综上,这是我开发的Dapp的一些心得体会,文中有不正确的地方,欢迎大家指出。

    合约工程地址:

    合约代码在https://github.com/tiankonglan/DayDrawEth

    技术交流:

    区块链技术QQ群:532655612

    相关文章

      网友评论

          本文标题:自制eth dapp的心路历程

          本文链接:https://www.haomeiwen.com/subject/eqdjgftx.html