基于以太坊实际项目开发经验

项目简介

这是第一个由个人和团队完成的基于以太坊的区块链项目。 目前项目处于删档测试阶段。 只要你每天签到签到，官方还会给你ETH和token。 喜欢羊毛的可以去看看。 整个项目开发过程经历了相当多的坑。 文中会一一提到。

项目整体流程

3月份立项，不到一个月的时间，学习并模仿CryptoKitties开发了一款游戏。 在这里要感谢CryptoKitties项目，他也是ERC721的创始人之一。 我们的智能合约在很大程度上模仿了该项目。 为了减少开发工作量，我们完全放弃了服务器端（因为在智能合约中无法遍历地图对象，我们必须为每个地图创建一个数组）。 这里存在巨大的技术风险。 我们使用react+truffle进行前端技术开发。 团队也是第一次接触react框架，开发阶段一直使用Ganache网络。 直到QA测试，才使用了Rinkeby网络（主网测试也是这里的技术风险）。 第一个版本是在三月底开发的。 交货验收。 需求方提出不希望使用ETH购买宠物的需求，而是希望使用代币系统，然后代笔可以在互动社区进行充值。 开始进入第一次改版，插件ERC20合约，扩展ERC20基础版，让ETH可以用来买卖ERC20代币。 两周完成开发、交付和验收。 需求方不想挂钩ERC20合约，而是想在游戏中独立做自己的货币系统，不设置充值提现功能。 都是官方发的。 再次修改合约，token在游戏中修改为纯数字货币体系。 （瓶颈1出现，智能合约实际上限制了部署的大小，修改后的合约可以编译，但是不能部署，网上也没有解决方案。

只能删除合约中的部分方法）。 重构合约 1 周。 现在是四月底。 基于rinkeby网络的第一周内测开始，一周后第一个隐患暴露出来。 最早网购代销商品清单失败，最终调查是合同中使用了一个数组。 每次购买商品，都要删除数组中的数据。 越早删除，消耗的GAS越多，直到超过Limit而失败。 改版将一些数据写入MYSQL。 5月初验收，需求方反馈游戏不新。 建议增加PK环节。 并改造现有页面。 小队苦思冥想，最终构思出尾巴数量=战力的系统，持续战斗可以提升战力。 需求方审核通过，开始开发。 继续发育2周。 并重新注册。 它将于 6 月推出。 基于运营考虑以太坊年底会到多少，需要向玩家发放代币，向玩家发放0代或1代狐狸。 继续修改合约（充分利用上一次迭代删除数组留下的空间）。 此外，还增加了PK游戏功能。 7月，部署主网部署准备测试。 面临第一个问题，线上环境下的GETH无法同步整个区块，0代fox合约无法正常运行。 到处搜索文章，没有很好的解决方案。 只能提高机器的性能，提高网络的性能，然后死掉。 最终整个主网同步需要五天时间（在实际运行中，geth经常会跟不上主网出块节奏，导致一些事件延迟到达，目前的解决方案是有更多运行 GETH 和更多 nodejs 服务的机器抓取事件并将其发送到数据库。数据库使用 txHash 确保它只被接收一次）所以如果你计划从新机器部署主网络，请至少等待一周. 因为受到Foom3D游戏的影响以太坊年底会到多少，主网连续半个月有60Gwei的GAS，基本处于测试状态。 这里也要佩服P3D和F3D的思想，可以调动整个以太坊的用户，造成以太坊的拥堵。对基于区块链的项目的建议

钱不用愁，公测前一定要去官网测试。 你可能会发现问题（主合约同步问题、GAS不稳定问题、服务器同步问题太慢）

智能合约中尽量不要有循环语句，智能合约中不要对数组进行排序，GAS可能会很高。

调用钱包插件支付时硬写limit，这样钱包调用会很快。覆盖后矿工运行后返回

如果可能的话，从一开始就不要让智能合约有警告，并且消除所有的警告。

不要太依赖智能合约，主要是太慢了。 中央数据库仍然需要上传。 多想想如何保证数据中的数据和链上的数据是同步的。 写更多的事件来同步尽可能多的数据。

从一开始，我们就需要留出很多钱。 如果我们可以拆解，尝试把合约拆分成多个合约，用地址互相调用，建立信任关系。

智能合约中没有浮点数，尽量不要计算百分比。

参考