跨链桥第三次被掏空，区块链跨域安全解决方案真能兜住吗

导读： 干了八年的跨链协议, 经历了从最开始那一个 Polkadot XCM 到近几年冒出来的 LayerZero...

干了八年的跨链协议, 经历了从最开始那一个 Polkadot XCM 到近几年冒出来的 LayerZero, 我实在是见到了太多所谓的“安全白皮书”最后竟然变成了让人无奈的事故通报。

说实在的, 区块链跨域安全解决方案这一件事情, 核心意思其实就是不要让你的信任链条发生断裂, 千万不要在任何具体的操作步骤里, 心照不宣地把验证那些事情的责任, 悄悄地推卸给了只有少数人才能控制的节点去承担。

跨域安全方案怎么选

我见过的那种项目方, 真的是让人感到最离谱的存在, 他们在自己的白皮书里面写明了要用上多重签名加上轻节点的验证方式, 最后还要把零知识证明这个环节也加进去, 这算是三件套了, 可是等到他们真正上线运营的时候, 却发现实际上只用了ECDSA签名这一个手段来支持两个签名。

如果你去问他们为什么会砍掉那个零知识证明的层面, 他们会给你一个理由说这是因为性能不够的原因。既然性能方面是远远不够的, 那就应该不要把它放到生产环境中去运行, 相反地, 却还拿着测试网的这种数据去忽悠那些用户, 这样做的话, 其实比完全不写任何东西还要危险得多。

真正靠谱的跨域安全解决方案, 它核心的关键并不是看技术有多么花哨, 而是看那个验证节点的分布式程度到底有多高。

不要来问我为什么知道得这么清楚, 因为某个公链的跨域桥连接被五个验证节点里面的三个联合起来做了不好的事情, 在两分钟之内转走了八千万美元的资产, 虽然链上的记录看起来干干净净, 但是你根本不知道应该向谁去追究责任呢。

跨域安全漏洞怎么防

我现在养成的习惯, 是要隔一个季度就逼着团队去做一次模拟推演。我们假定的场景是, 攻击者已经把管理员的私钥给搞到手了。在这种极端情况下, 我们要检查一下你们那份应急响应SOP到底行不行。重点就是要看它能不能在四十分钟的那个时间段内, 把那条桥给冻结住。

这事情不是做给什么审计人员去看的。在上一次进行的推演当中, 我们发现监控告警这个环节出现了延迟。那个延迟的时间足足有四十分钟。这个时间长度是干嘛的呢? 是足够一个攻击者把一条桥里面的资产掏空三次的。然后他还有余力把这些资产再洗到链上去。

另外还有一个坑, 这是很多人所忽略的, 那就是轻客户端同步偏差。你要是桥接的那一端所在的链, 如果在出块的节奏上面不太稳定, 那么验证的逻辑在遇到了边界条件的时候, 就很有可能发生错位的情况。

你不要等到真的出了事故了, 才发现去翻查日志记录。你应该在平时就把头节点切换这个操作里面的容错机制, 给写成固定的死的逻辑。

在网络安全这个领域里, 是不存在所谓的完美无缺和百分百安全的状况的, 现在的状态只是还没有遭到黑客的攻击而已。不过, 无论如何都必须把底线牢牢地守住，具体来讲就是使用的验证节点的数量不能少于三百个, 而特别关键的个人私钥绝对不可以存放在那种随时联网的热钱包里面。