ACM_Someone like you

第一版本的錢包的目的是實現熱錢包，所以創建錢包是在服務端創建，回執給客戶端助記詞,keystore,方便用戶備份，導入操作。這里有一個很大的質疑：服務端操作錢包安全嗎？相對于冷錢包而言，當然不那么安全，所以為了提高安全等級，

將要實現：交互加密，代碼混淆   //防破解數據

               開源交互api等方式    //本身沒有堅守自盜

第二周，還沒有做到安全防護的階段。。。就是可能會做的處理，先伏筆。

這周主要做的是導入和備份錢包相關功能。（目前先只考慮ETH，后續再學習BTC）

一 導入錢包

參考上一周做的總結三種導入錢包方式

1.助記詞導入     ：助記詞不要抄錯，哪怕一個單詞字母 單詞順序，如果一個錢包你只記住了這一種備份，還記錯了，那你復現恢復  

                         的概率極小，或者說宇宙數量級別的隨機 幾乎不可能復現。。。 

　　　　　　　?。˙IP39規范生成128~256位隨機數 必須是32的倍數，這里我們的助記詞是12個那么需要設置生成128位隨機數）

2.私鑰導入       ：私鑰是相當要注意安全問題的，誰知道你的私鑰，就擁有了這個錢包的絕對控制權

3.keystore導入 :  需要用戶記得解析keystore的密碼，沒有密碼 是不能導入的

二 備份錢包

當前需求只要求助記詞備份，

1.首先要求用戶輸入密碼，這個密碼是創建錢包時候，或者導入錢包時候輸入的或者更新后的密碼。

2.輸入密碼的目的是校驗能不能解開keystore,能解開得到私鑰，說明知道核心密碼即有權限備份。

3.這個在創建或者導入錢包完成時，服務端會回傳keystore和助記詞，存儲到本地，這里可以選擇存到keychain里，或者加密存沙盒也可（按需處理）

4.執行備份時候，執行第二步，在本地操作，我在github找了星星很多的開源TrustKeystore（參考4），很好用，有一點，期初，解析keytore時候花了大于30s甚至50s的時間。這個用戶得瘋了吧。。。我查了好多資料，原來是debug編譯模式下,編譯花費時間長，導致解密很慢，但是release默認選了編譯優化：Build Settings->Optimization Level有幾個編譯優化選項，release版應該選擇Fastest, Smalllest，這個選項會開啟那些不增加代碼大小的全部優化，并讓可執行文件盡可能小。但是debug默認是不會選的，目的是方便開發者積極調試發現存在的問題。所以要是單獨測試這個問題可以考慮在release模式下測試，或者是優化一下編譯選項吧?？纯茨膫€編譯執行效率比較滿足你的開發需求（參考2，3）

備注：這個我的選擇是對比了開源的TrustKeystore，的編譯配置寫的，應該沒有什么問題。優化效率達到了4秒左右，添加loading狀態后，可接受。

         網上越新越前沿的東西，幾乎都是用swift寫的，我主要寫OC項目順手，所以用了混編，這塊出了很多“第一次”的錯誤，熟練了就好了。

參考

1.https://www.liaoxuefeng.com/wiki/0015223693709562f80977e6c9549f0a1e17640a61433d6000/0015223800842062cc09cdd70dc45b8992c3b399386673a000

2.https://www.jianshu.com/p/099b520ba7a8

3.https://blog.csdn.net/understand_XZ/article/details/70224227 //iOS之編譯參數Optimization Level

4.https://github.com/TrustWallet/trust-keystore