跨链桥的风险：验证者集合、多签与消息重放

2026-08-12

跨链桥并不搬运任何东西。它是在一条链上做出一个声明，再让另一条链据此行动；而每一次桥被打穿，都是第二条链采信了一个本该拒绝的声明。所以给跨链桥的风险分类，靠谱的做法是按信任假设，而不是按产品名字：目的链究竟在相信什么，以及要让它相信一件假事需要付出什么。本文按这条线索走五个结构性来源，从外部验证者集合一直讲到升级权限。

先问一句：到底谁在验证

以太坊官方开发者文档把跨链桥的安全性压成了一个问题：谁来验证这套系统？手续费、速度、能连多少条链，全都在这个问题的下游。

机制本身很少变花样。源链上发生了某件事。某个角色出具证明说它发生了。目的链上的合约拿这份证明去对一条规则，通过就放币或铸币。攻击者想要的一切，都在这条规则的另一头。

该文档把设计分成两族。受信任型的桥由外部验证：一个带多签的联盟、一套多方计算系统，或者一个预言机网络。无需信任型的桥依托它所连接的两条链和这两条链自己的验证者，不新增信任假设。前一族买到的是连通性与速度，代价记在安全性上——由外部验证者保障的桥，通常弱于由链本身原生保障的桥。

押在上面的钱让这笔交换不留情面。截至 2022 年 8 月，Chainalysis 统计到 13 起独立的跨链桥被盗事件，合计约 20 亿美元，约占当年到那时为止全部被盗金额的 69%。桥之所以吸引攻击，是因为它把抵押品堆在了那条规则被检查的同一个点上。

所以下面几节按假设排列，而不是按事件排列。两座名字不同、验证模型相同的桥，会以相同的方式失败；而记住名字，并不能告诉你手上这一座是什么。

外部验证者集合是一套你没审计过的系统

最常见的受信任设计，是在两条链之间放一组 N 个角色。他们盯着源链，为发生过的事件签名出证；目的链的合约只要验到其中至少 M 个签名，就予以接受。除此之外，这份合约对现实没有任何别的看法。

结论很直白：谁控制了 M 把密钥，谁就能铸币。设一组 9 人、门槛为 5。攻击者拿到 5 把密钥，不需要合约漏洞，不需要任何一条链出问题，也不需要再过别的检查。他把桥掏空的整个过程，桥都在严格按设计行事。

留意你真正买到的是什么安全性。验证者集合是它自己的一套系统，有自己的运营方、机器与激励，从它连接的两条链那里什么都继承不到。由外部集合验证的桥，强度就等于这组集合的强度，不会更高——两侧的网络再大也一样。

所以值得问的是成员问题。这 N 个是谁，有没有公开过？他们是彼此独立的机构，还是一家机构开着九台机器？M 是多少？成员手里有没有押着一旦签了假消息就会被没收的东西？以及，谁能改这份名单——因为一把密钥就能改写的集合，本质上是一座披着委员会外衣的单签桥。

门槛有没有用，取决于密钥会不会一起失效

M-of-N 是一句关于独立性的话，不是一道算术题。九选五比一选一更难，前提是这九把密钥能以九种互不相关的方式失效。

而它们常常做不到。同一家公司里的密钥，共用一套入职流程、一份笔记本装机镜像、一条 VPN、一个云端密钥服务和一个签名界面。如果同一封钓鱼邮件能同时够到九个持有人，或者其中五把就放在同一个云账户里，那么 N 只是仪表盘上的一个数字，真实的 N 更接近 1。

把门槛往上调修不好这件事，而且要付代价。M 定得高，丢掉几把密钥就会让桥根本签不出字：钱没被偷，但也没人动得了，资产卡在错误一侧的人只能等。每一个门槛，都是在「太容易被偷」和「太容易被冻住」之间选一个位置。

签名环节值得和托管一样多的注意。签名者批准的是他们基本读不懂的载荷；如果界面显示的是一句友善的摘要，而底下的字节说的是另一回事，那么诚实的签名者也会产出一个有效的恶意签名。盲签会把 M-of-N 的委员会变成 M-of-N 的橡皮图章，而门槛对此毫无防护。

轻客户端与乐观验证赌的不是同一件事

最小化信任的那几种设计去掉了外部集合，但它们没有去掉信任，只是把信任挪了个地方。挑大梁的是两族。

轻客户端验证，是把源链的一个客户端放进目的链里。目的链保存源链的共识状态，再检查被声称的事件能否对着它给出证明。在 IBC 里，连接的每一侧都用对方链的轻客户端来验证进来的消息，于是假设收缩成两条：源链的共识，加上客户端代码本身写得对。IBC 的新版本把话说得更明白——所谓客户端只是一种验证模型，它同样可以是轻客户端、多签，或者一个证明验证器。名字不等于假设，客户端类型才是。

乐观验证走的是反方向：先临时接受这条消息，再给任何人一个时间窗去证明它是假的。它的假设是，至少有一个监督者在跑、有钱，并且能在窗口关闭前把挑战交易送上链。一个在窗口期间掉线、没手续费或被审查的监督者，和没有监督者是一回事。

两族都不免费，而且代价是结构性的，不是偶然的。轻客户端对每一对链都要花 gas 和工程量，客户端里的一个 bug 就是规则本身的 bug。乐观设计接起来便宜，但会让每一个诚实用户白等一段由设计者定下的延迟。以太坊文档把两边的代价都写明了：轻客户端型的桥受限于连通性，乐观型的桥受限于速度。

重放：同一条有效消息被算了两次

一条跨链消息就是一份授权。重放这种攻击，是把一份确实签发过的授权再拿出来用一次：可能是在同一个地方来第二次，也可能是拿到一个它压根没打算适用的地方去用第一次。没有任何东西被伪造，只是同一串有效字节被重复使用。

以太坊自己的历史里就有那个标准答案。EIP-155 把 chain ID 折进了参与哈希与签名的数据，于是为一条链做出的签名，在另一条链上验不过。留意它是怎么落地的：旧的六元素格式仍然有效——也就是说，这层保护是签名方选择加入的，而不是格式本身给的保证。

而对于跨链桥真正在传的那类结构化消息，EIP-712 定义了一个域分隔符。它可以携带名称、版本、chain ID 和验证合约的地址，外加一个作为最后手段的 salt；标准里还写明，当 chain ID 与用户当前所在的链对不上时，钱包应当拒绝签名。换一条链、换一个合约、换一个版本，就是另一条消息。这就是「域分隔」在实践中的意思：把目的地放进被签的内容里。

域分隔仍然拦不住同一条消息被送到同一个目的地两次。EIP-712 自己就这么说：这份标准只管签名，不含重放保护，所以应用必须自己拒绝重复的那一条，或者把被授权的动作做成幂等的。这份活归 nonce、序列号，或者一份已消费消息的记录来干。

IBC 展示的是拼完整之后的样子。恰好一次投递是协议明写的性质：每个数据包带一个序列号，接收链在这个序列号下写一条回执，回执已经存在的数据包会被拒收。规范里点明，这就是签名消息那套序列号问题，只不过签名者的位置换成了轻客户端。只验证、不去重，那只是半座桥。

跨链桥风险按信任假设分类：外部验证者集合、多签门槛、轻客户端与乐观验证、消息重放、升级权限

升级权限凌驾于其余所有假设之上

上面说的全都是一座桥今天在执行的那条规则。升级权限决定的是：明天谁能把这条规则换掉。

多数跨链桥合约是代理合约，而 ERC-1967 把代理的接线位置标准化了：一个存储槽放它委托过去的实现地址，另一个存储槽放被允许更换这个实现的 admin 地址。admin 发一笔交易，代理就指向新代码，而新代码想怎么定义「有效」都行。

这让升级权限成了本文其余所有风险的超集。九把密钥的验证者集合、轻客户端、挑战窗口——控制着 admin 槽的那一方都能把它们换掉。一座桥的安全上限，老实说等于验证模型和升级路径里更弱的那一个。

让人安心的是，这一条是可以自己查的。标准告诉了你去哪里看，并要求这些槽位发生变化时发出事件：实现变了发 Upgraded，admin 变了发 AdminChanged。去读那个 admin 槽。看看它放的是一个外部账户、一个多签，还是一个时间锁；如果是时间锁，再看延迟多长、谁有权取消。

暂停权与参数调整权值得同样读一遍。叫停一座桥、或者调高一档转账上限，比重写规则的权力小，但它同样是握在某个人手里的一把钥匙；而一座能被暂停的桥，也能在你的转账走到一半时被暂停。

结语

一旦问出「谁在验证」，跨链桥的风险就分得很干净。外部验证者集合是一套独立的系统，它的门槛就是它的安全预算；而这个门槛能不能立住，取决于背后的密钥会不会一起失效。轻客户端把假设挪到源链的共识和客户端代码的正确性上；乐观设计把假设挪到至少有一个监督者在整个窗口期里活着且没被拦住。重放保护是与验证并列的另一项要求：目的地必须是被签内容的一部分，每条消息都需要一个序列号或一条回执。而凌驾在这一切之上的是升级权限，它一笔交易就能把其余部分全部替换。你过桥时真正信任的，是这五个答案，而不是界面上的那个品牌。

风险披露：本文为 Bitbase（币贝）学院的科普内容，仅供教育与信息参考，不构成任何投资、交易、税务或财务建议。加密资产波动剧烈，请自行评估风险。本文撰写于 2026 年 8 月，请以官方最新信息为准。