Bitkeep黑客事件引发的思考:自托管钱包存在的问题及解决方案
来源:Haotian | Web3 DA推文
万万没想到,一次Bitkeep的**攻击事件,却让加密钱包这个最古老的行业赛道“共识”动摇了?钱包到底安全不安全,被**攻击是平台方的责任还是用户自己担责?开发加密钱包是不是个好生意? 接下来的Thread,本着科普的客观态度,来谈谈当前自托管钱包赛道存在的问题,以及未来潜在的变局。
众所周知,小白onboard加密行业一离不开交易所,二离不开自托管钱包。 交易所(CEX)一般都是平台代托管模式,用户下载注册都沿用传统的手机邮箱+密码+二次动态验证码的熟悉方式,且资产由交易所全权托管。因此用户惯性思维就是没事找平台算账,**攻击等外力侵犯默许都是由交易所平台担责。
然而自托管钱包却没有沿用小白熟悉的传统借记卡的运作逻辑(注册、挂失、补办等)。 钱包平台方只提供了生成私钥工具、管理资产的前端入口。用户的私钥存储于手机本地,每一次链上交易,都需要用户调用本地私钥签名再上链。 钱包平台方只充当生成私钥工具+资产管理前端+链上DApp入口的角色。
在自托管钱包开发者的叙事逻辑下,私钥保管于用户硬件终端本地,由用户全权保管私钥,且用户可以同时将一串私钥导入多个不同的平台。 故而默许了一个免责条款:因私钥丢失造成的资产损失由用户承担。 这样虽然技术上说得通,但钱包毕竟离用户资产近,也不符合小白出了问题找平台的惯性思维。
事实上除了私钥保管问题,还有很多非用户主观抗力丢失的可能:
1)用户移动终端被root,**通过木马病***获得了高级权限;
2)用户下载或更新App,软件APK包被**木马劫持;
3)用户下载APP的目标CDN网络被**劫持;
4)钱包私钥生成工具供应链被黑等等。因此,钱包大凡出现用户资产安全问题就会扯皮。
关键是,钱包之间也内卷。为了提升体验不停发新版、为了抢夺市场,覆盖浏览器插件移动端App等各条链路,而且为了赚钱,开发闪兑、swap、跨链等需要Approve授权的业务,导致出现安全问题的漏洞点越来越多。 这无疑增加了用户安全保管私钥的难度,这种前提下,出了安全问题就势必得查明且界定责任方。
然而类似于APK被劫持这类问题,责任主体往往厘不清。 站在用户的弱者受保护框架下,平台自然就成了要主动扛责的一方。然而不同于交易所,自托管钱包不直接接触用户资产,盈利能力太弱,除了闪兑跨链手续费收入,其作为DApp流量入口的商业前景没被打开。小问题还能cover,真遇大面积攻击,想赔都难。
即使这样,自托管钱包赛道一直都是开发者争抢的高地,毕竟Metamask的成功故事以及钱包作为一切链上入口的商业前景实在太迷人了,大部分开发者尽管知道可能会惹一身骚还是想All in。 况且,钱包赛道还是在持续演化发展ing。原先钱包纯做私钥生成和流量入口的叙事正在思变。
机会在哪里?简单说就是场景分化,人群分化。 普通小白,交易所就是最优解;略高知高资产群体:硬件钱包、自托管钱包,一冷一热搭配使用;重安全,就用安全级别较高的MPC钱包托管方案,想优化功能体验,就用场景更灵活的智能合约钱包,以及围绕账户抽象、法币入口等mass adoption的其他方案等等。
无论MPC还是CA钱包做的都是重塑"私钥"的事,私钥保管看似简单,但用户-硬件-软件-区块链等各个层级间总会因个体安全意识的差异而滋生安全隐患的漏洞太多了。千言万语一句话,整个市场用户以及生态开发者Builder还是得进一步提高安全意识,加强安全建设。 遇事扯皮互相指责的行业内耗毫无意义。
本文由某某资讯网发布,不代表某某资讯网立场,转载联系作者并注明出处:https://yuhuajia.cn/zixun/24704.html