Poly Network 攻击暴露了跨链桥代理调用的高权限风险

看了慢雾对 Poly Network 的分析，又顺手翻了下源码后，我觉得这次攻击如果只理解成“多签出了问题”，其实会抓不住重点。

Poly Network 想解决的并不只是简单的资产跨链，而是更一般化的跨链调用。

任何跨链，本质上都包含两步：

1. 在 A 链上发生一个交易。
2. 在 B 链上根据这个事实，再执行另一个交易。

如果你只做资产转移，这套机制已经够复杂了。但 Poly 进一步想把它抽象成“通用的跨链执行框架”，也就是不仅告诉对面链“有一笔资产该释放”，还告诉它“该调用哪个方法、带什么参数”。

这套思路从功能上很强，因为未来跨链需求确实不止转账。比如同一个借贷协议部署在不同链上，就会自然想做跨链抵押、跨链借款，或者更一般的跨链合约调用。

问题就出在：一旦跨链桥承担了“通用代理执行”的角色，它自己就开始拥有非常高的权限。

Poly 的链上合约为了支持验证节点（keeper）变更，还提供了更新 keeper 公钥的管理方法。这本来是内部治理逻辑，只有满足门限签名条件时才能执行。

但与此同时，跨链桥又支持根据外部跨链消息，在目标链上代理执行指定方法。

攻击者利用的正是这两个机制叠在一起后的缝隙：

1. 在 A 链上构造一个跨链请求。
2. 请求的目标不是普通业务方法，而是目标链跨链合约里那个“更新 keeper 公钥”的高权限方法。
3. keeper 节点只验证这是不是一条有效跨链请求，并不审查“这个方法本身是不是桥不应该替用户执行的私有方法”。
4. 结果目标链上的跨链合约就替攻击者执行了本来只有自己才有资格执行的管理操作。

攻击者并不是直接拿到了那个私有方法的权限，而是借跨链桥这层身份，完成了一次“狐假虎威”。

所以这次事故真正暴露的问题是：

• 当你提供任意代理调用能力时，系统权限边界会急剧变得模糊。
• 如果高权限管理方法和外部可驱动的代理执行机制共存，就必须显式隔离。
• 仅靠“有多签”“有验证节点”并不能自动保证安全，因为验证的是消息真实性，不一定验证调用语义的合法性。

这也是为什么我一直觉得，动态调用像一种魔法。它极大增强了系统的可组合性，但只要边界没画清，魔法往往也会把本来隔离得很好的权限结构一起打穿。

DeFi 和跨链世界大量创新都建立在这种可组合性之上，但正因为如此，安全模型更不能只看密码学签名是否成立，还要看“谁在替谁执行什么”。

原微博中的媒体