这个业务的出现场景的前提条件是因为要做一个多签钱包完全内部自用，
完全配合自己内部的多签业务流程，算法签名上自选，所以有了这么一个
kms-wallet 钱包签名的业务需求。

最近主要撸了unisat浏览器插件钱包的代码，这个钱包光一个btc业务，代码量就十分的巨大，不敢想象类似于okcoin那种聚合钱包要调用的代码量和使用各个链的包有多少。

好回归最基础的业务就拿登录部分来说，直接上一个流程图。

这个业务场景的加解密都在钱包本地进行操作，这段加解密的逻辑贯穿了整个钱包的业务链，都要加盐解密在对比，至于存储是存储在浏览器本地，而浏览器类似谷歌浏览器，将这个加盐的密钥存到硬盘里，这个东西的安全性问题是由谷歌浏览器本身保证的，也就是说每个钱包都在本电脑的内存插件的PC本地。你丢了这个本地钱的登录密码，而你的钱包的私钥没有导走，那么意味着钱就丢了。以上是业务层面的讨论。

下面就看一下核心API对比，Chrome.storage.local 尤其要注意的是，第一 API 类型是异步，不要按同步的方式去写，第二步是扩展仅限插件访问，第三是存储空间，空间为10M 这个还好，这个存储空间是足够使用了。

以上只是基本业务层面的探究下一篇我们研究详细代码。