最近用EVM做了不少智能合约的项目,有lotto,vote,dao等等,说说感受吧。

  1. 千万不要用合约写复杂的逻辑,GAS的消耗是你的限制,库的功能是你的限制,VM的性能是你的限制,VM的稳定性也是你的限制。
  2. 可以把现在的合约当成数据库的存储过程,区块链当成数据库来理解,也就是看起来什么都能干,但是如果真的什么都放在里面干,你会死得很难看。
  3. 并行什么的,还是算了吧,不要试图向合约发起并行修改请求,最好的方式是在合约增加批量处理方法或者调用批量处理请求。因为账户的nonce是需要按次增加的,而每次增加1,都需要等到交易打包到区块中。
  4. 千万别用Java来开发与合约的交互,首先Web3j没有完全实现能力(例如批量提交就没有),第二用了Java你还得写前端逻辑,不如直接使用Web3.js,前端直接搞定,所以正确的架构应该是。  client -> ETH-Node ,Server -> ETH-Node这样的模式,如果确实需要一点中心化的东西,那么最好也是使用NodeJS,Web3.js是官方出品,而且功能全面。
  5. 做合约的产品,千万别搞复杂的逻辑,害人害己害用户,大家的手续费都老高,而且还不稳定。简单粗暴的产品最好。
  6. GAS的设计说实话,在外面看还以为牛逼哄哄,一旦自己成为了开发者,就觉得完全限制了你的发挥,合约的发展任重而道远。
  7. 可能区块链合约的发展都进入了一个误区,就是ETH的GAS或者EOS的资源使用计算,不过好在BM是看到了问题的,他在想办法脱离GAS,但是不够彻底,还是有资源消耗给费用的问题,这些都是限制合约发展的东西,应该统统去掉,要什么费用,这样大家都可以自由发挥了。当然,你说不激励节点怎么运作,那就是区块链项目的事情了,你不能激励节点就干掉用户体验,限制你自己的发展空间,所以链外的计算环境现在应该是个不错的方向,沙盒空间,你爱怎么玩就怎么玩。

后面想到什么再持续更新吧。

一点感悟:当然,我们帮助NULS做的NVM也有一部分是借鉴了EVM的架构和理念,所以EVM有的问题,NVM同样也有,当然NVM不同的地方在于VM的能力更强,这并不是本质的改变,我们会积极思考NVM2.0,从架构上全面的超越现有的合约体系。

更新1

  1. GAS还是GAS,这次是GAS Limit。如果你帮助用户管理账户,那么一定要注意计算每次与区块链交互的GAS是不同的,GAS Limit的设置也不同,你不能统一设置了事,这样会很大,我们把转账也设置成和业务交互一样的GAS Limit,最后结果就是提现小于GAS * GAS Limit就直接报告失败,而业务Limit在600万,提现应该只要30万左右就可以了。
  2. 由于区块链的去中心化,打包区块时间限制,所以dapp尽量不要设计有定时任务的那种,否则你就只有使用外部定时来解决了。
  3. 如果是非dapp的标准模式,即client->chain, server->chain的模式,而是client->server ->chain的模式,那么就要注意了,geth尽量使用light模式,否则fast你得准备200G+,full你得准备800G+,而且还必须是SSD。最好是对接infura.io,这样你就不需要节点,不过也得注意的是,web3j不支持infura的filters,web3.js的1.0版本全部支持,之前的版本也不支持。
  4. 一切都是异步,与区块链交互最好都是异步,所以你的dapp一定要基于异步去设计和考虑,不是每一次调用都能够立刻得到结果,而是需要等待一段时间,可能很短,也可能很长,也可能很长时间后告诉你有错误。
  5. 在合约中设计的struct时注意一点,不能超过16个属性,超过就会报告stack too deep的错误,这是EVM的设计限制的。
  6. 避免在合约中使用多层for循环,如果必须要,保证迭代的数据不要太多,否则GAS费用承受不起
  7. 数据结构的使用十分十分非常非常受限,mapping和array。mapping是无法被删除的,也无法通过for遍历,而array可以通过for遍历,也可以通过delete array的方式进行删除。如果你一定要删除mapping,我们只能迂回的去清空mapping的数据,把它设置成不要的情况,例如{a->1,b->2},清空后面的数字为一个代表无意义的数字,例如{a->-1,b->-1},但是你没法遍历mapping不是,所以怎么清空?这时候一种办法就是利用array再把mapping的key复制一次放在array中,接上面的例子,这个时候你就有个数组存储{a,b}, array[0] = a,  array[1] = b,然后通过遍历这个key数组去清空mapping。
  8. 虽然从链上查询是不消耗GAS的,但是也要考虑机器的性能,总之尽可能的保持产品简单,不要太复杂。
  9. remix是一个非常好的开发工具,所以尽量用remix去做测试,truffle也不是不行的,但是truffle有时候编译出来的二进制数据和remix编译出来的有些许不同,而remix编译出来的就和你发布到以太坊网络中的二进制是一致的。还有就是,当你发布了合约之后,一定要做code的验证,因为验证前后的bin可能是不同的。我现在的猜想就是合约的编译版本造成的不同,truffle我还不知道怎么确定编译时选择版本,只能配置优化和次数(默认都是200次),remix是可以选择的。这个BIN主要是影响Web3j生成Java合约代理,容易出现一个叫empty(0x)的问题,这种问题一出现,就是因为二进制不对引起的(所以这也是为什么别用web3j的原因,用web3.js是不需要bin就能生成代理的)。