第一版本的钱包的目的是实现热钱包，所以创建钱包是在服务端创建，回执给客户端助记词,keystore,方便用户备份，导入操作。这里有一个很大的质疑：服务端操作钱包安全吗？相对于冷钱包而言，当然不那么安全，所以为了提高安全等级，
将要实现：交互加密，代码混淆 //防破解数据
开源交互api等方式 //本身没有坚守自盗
第二周，还没有做到安全防护的阶段。。。就是可能会做的处理，先伏笔。
这周主要做的是导入和备份钱包相关功能。（目前先只考虑ETH，后续再学习BTC）
一 导入钱包
参考上一周做的总结三种导入钱包方式
1.助记词导入 ：助记词不要抄错，哪怕一个单词字母 单词顺序，如果一个钱包你只记住了这一种备份，还记错了，那你复现恢复
的概率极小，或者说宇宙数量级别的随机 几乎不可能复现。。。
（BIP39规范生成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