上线imToken钱包踩过的坑，这篇全给你说清楚了

在上个月的时候, 我们刚刚协助团队把imToken钱包从开发环境部署到了生产环境, 整体的执行步骤比大家最初预估的情况得要复杂和耗费精力得多。

绝大多数人都觉得只要简单调整一下SDK就大功告成了, 但实际上, 无论是链上签名验证这一环节, 还是针对交易状态进行轮询检查时的超时处理机制, 每一个细小的部分都有可能直接导致项目上线的工作拖延好几天之久。

现在让我感觉到特别头痛的是在非托管钱包场景下的密钥流转问题。我们在系统架构里把私钥存放在用户自己的设备端。服务端只是负责进行签名的转发操作。但是在这中间一旦签名请求的连接出现断开的情况,那么相关的交易状态就会一直悬在半空中无法完成。

在系统正式上线之前, 大家特意去编写并部署了一套针对gaslimit弹性兜底策略的设计方案。这么做的根本原因在于, 如果用户恰好遇上了网络链路的拥堵情况发生。如果不采取这种预防性措施的话。整个交易确认的执行流程会直接陷入死锁状态无法进行下去。那到时候客服电话会被打爆的情况也是完全有可能发生的。

想知道咱们这个项目现在到底是用的自有节点还是第三方rpc。如果预算紧张的话, 免费层的那个小吞吐量能不能撑住高峰期。这个点我真的特别想听一听你们实际测试出来的数据结果。