承接上一篇，详细写实现充值以太坊功能。
每个用户充值的时候会由服务器生成一个以太坊钱包，用户会把ETH充值到这个钱包，根据对其他交易所充值逻辑的观察，都是监听以太坊钱包的转账记录，并同步到用户账号余额，区别在于交易所是如何把充值进来的币集中到一个热钱包里，有的交易所会按照上一篇所说的那样，跑定时任务去转账，另一种比较有意思的就是用智能合约去转账，也就是服务器生成钱包的那一步，其实是部署了一个智能合约，合约里写好逻辑，币转进来就会被合约自动转账给热钱包，目前我实现的方法是第一种。
第一版实现，因为服务器资源有限，业务也是刚起步，就没浪费资源去自己运行以太坊节点，使用了infura.io的json rpc节点，好处是不需要担心维护以太坊节点，暂时可以相信这个节点是不会坏掉的，坏处就是以太坊json rpc的节点是不支持根据钱包地址查询全部转账记录的，所以第一版用了比较hack的手段监听余额数字。
同样是定时脚本，监听余额，发现有余额大于0的钱包地址，就把钱包里的钱转入热钱包，并在对应用户的余额上加对应的数字。这样做会出问题，一开始的想法是，每次监听都把钱包里的余额全都转到热钱包，这样保证钱包里的余额永远是0，每次充值都是加上钱包里的余额就好，这样做的前提是，要把gasLimit设置成21000，转账amount为钱包里的余额减去gas费用，但是这笔转账很容易因为gas不足就失败了，为了保证每笔转账能尽可能成功，要把gasLimit设置的大一点，这样做就会导致没用完的gas会返还给钱包，钱包里的余额就不再是0，所以又加了一段hack的代码，每次监听都会把余额的数字缓存起来，并且每次监听，如果监听到的余额小于这个缓存，就缓存这个小的数字，而逻辑上钱包里的余额是，以太坊钱包真实余额减去这个缓存的数字，这样做一看就漏洞百出，但是在充值频率正常的情况下，是work了。进度原因，用这种心惊肉跳的逻辑运行了很长一段时间。
第二版，就是用etherscan的api，拿到钱包地址的转账记录，提出转入的记录，写进数据库，不会同步进行链上转账，每天跑一次集中到热钱包的脚本就够了，这样的好处是不会出现充值出错的问题，逻辑也比较清晰，不需要hack，可能的坏处就是，etherscan挂掉了，我们的服务也就不能用了，可能etherscan坏掉的概率和infura坏掉的概率差不多吧。我想最好的解决办法就是自己运行一个以太坊节点吧，做etherscan相同的事儿，就能自己监控记录了，这就不会让自己的服务依赖别人的东西了。
本来打算这篇就写具体实现，包括代码，但是仔细回顾一下，也挺麻烦的，还是单开一篇写代码吧，下篇会记录如何实现转账功能