承接上一篇，詳細寫實現充值以太坊功能。

每個使用者充值的時候會由伺服器生成一個以太坊錢包，使用者會把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相同的事兒，就能自己監控記錄了，這就不會讓自己的服務依賴別人的東西了。

本來打算這篇就寫具體實現，包括程式碼，但是仔細回顧一下，也挺麻煩的，還是單開一篇寫程式碼吧，下篇會記錄如何實現轉賬功能