基于以太坊实际项目开发经验谈
项目简单介绍
这是个人和团队做的第一个基于以太坊的区块链项目。目前该项目在删档测试阶段http://fox.doyo.com,只要每日签到打卡官方还会送ETH和代币,喜欢薅羊毛的可以去看看。整个项目开发过程经历过相当多的坑。在文章内会一一提到。
项目整体过程
-
三月开始立项,一个月内学习并仿造加密猫开发一款游戏。这里要感谢加密猫项目,他也是ERC721的创始人之一。我们的智能合约大量仿造了该项目。为了减少开发工作量我们彻底抛弃了服务器端(因为在智能合约中map对象无法遍历,我们每出现一个map都要配套出现一个数组)。这里埋下了巨大的技术隐患。
前端技术我们使用react+truffle进行配合开发。团队也是第一次接触react框架,开发阶段一直使用Ganache网络。直到QA测试也只使用过Rinkeby网络(这里未上主网络测试也是一个技术隐患)。 三月底第一版本开发完毕。交付验收。 -
需求方提出需求不希望使用ETH进行宠物的购买操作,期望使用代币体系,并且之后代笔可由互动社区内充值进入。开始进入第一次改版,外挂ERC20合约,并且扩展了ERC20基础版,实现了可以使用ETH买卖ERC20代币。两周完成开发, 交付验收。
-
需求方变更需求不希望与ERC20合约进行挂钩,希望独立为游戏内自己的货币体系,并且不设置充值提现功能。全部由官方发放。再次修改合约,这时代币已经修改为游戏内的纯数字货币体系。(瓶颈1出现,智能合约居然限制部署的大小。此次修改后的合约可以编译,但无法部署,上网查无解决方案。只能删除合约内部分方法)。重构合约1周。此时已经到了四月底。
-
第一次基于rinkeby网络内部一周测试开始,一周后第一个隐患暴露。寄售商品列表最早上线的购买失败,最终排查为在合约内使用了数组,每次购买商品要删除数组内的数据,越靠前的删除GAS消耗越多,直到超过Limit失败。改版将部分数据写入MYSQL中。
-
五月初验收,需求方反馈游戏没有新意。建议增加PK环节。并对现有页面进行改版。团队苦思,最后构想出一个基于尾巴数量=战力值,继续打架可以提升战力值的体系。需求方审核通过开始进行开发。继续为期2周开发。并重新套版。
-
六月准备上线,基于运营考虑,需要给玩家发放代币,给玩家发放0代或1代狐狸。继续修改合约(充分使用上一个迭代删除数组留出的空间)。另外增加了一个PK赛功能。
-
七月开始部署主网络部署准备测试。面临第一个问题,线上环境的GETH无法同步完整个区块,线上发0代狐狸合约无法正常运行。到处搜文章没有太好的解决方案,只能提高机器性能,提高网络性能,然后死等。最终使用五天同步完整个主网络(在实际运营中geth还会经常跟不上主网区块产生节奏,会造成部分事件延迟到达,目前解决方案多几台机器跑GETH,多几个nodejs服务抓取事件,向数据库送。数据库使用txHash来保证只接收一次)所以准备从新机器部署主网络的,请至少留出一周时间。
-
因为受Foom3D类游戏影响主网络有半个月持续GAS都在60Gwei,基本处于测试不起的状态。这里也要佩服P3D和F3D的想法,能够调动整个以太坊的用户,造成以太坊的拥堵。
对于基于区块链项目的几点建议
- 不要心疼钱,公测前一定要上正式网络测试。可能会发现各位问题(主合约同步问题、GAS不稳定问题、服务器同步过慢问题)
//最常遇到的问题,本地区块追不上实时区块
> eth.syncing
{
currentBlock: 6227493,
highestBlock: 6227520,
knownStates: 189478353,
pulledStates: 189478353,
startingBlock: 6227405
}
> eth.blockNumber
6227493
- 尽量不要在智能合约内出现循环语句,不要在智能合约内对数组做排序操作,GAS可能会很高。
- 调用钱包插件支付时把limit写死,这样钱包调用会很快。多写的钱矿工操作后会退回
- 如果可能从写开始就不要让智能合约出现警告,消灭一切警告。
- 不要过分依赖智能合约,主要太慢。该上中心数据库还是要上的,多想想考虑下如何保证数据内数据和链上数据同步。多写event,能让尽可能多的数据同步出来。
- 一开始就要留出富裕,能拆开的尽量把合约拆成多个,互相使用地址调用,建立信任关系即可。
- 智能合约内没有浮点数,尽量不要计算百分比。
参考资料
如果觉得文章内容比较实用,期望获得更新通知,请关注公众号: