您的位置: 首页 > DAPP开发 > 正文

开发区块链上的Dapp,你必须知道智能合约的这6大坑

时间: 2021-10-04 12:58:37 浏览: 分类: DAPP开发

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



1629099765897595.jpg


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

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

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

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


第一坑编辑器

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

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


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

智能合约写好了,一般会选择发布到自己的私链上,最开始我选择是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(github.com/randao/randa),是个线上合约, 这个方案比较复杂,先要交纳保证金而且还要经历三个阶段才能得到最终的随机数(ps:细节比我描述的复杂多啦),所以不是一个经济和使用的方案。

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

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

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

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

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


第六坑定时触发:

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

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

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


小结:

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


来源: https://dapp.skpseo.com