# Multichain 倒下了，拿什么拯救跨链桥？ By [0xmiddle](https://paragraph.com/@0xmiddle) · 2023-09-02 --- Multichain 出事了，现在事件的进展还扑朔迷离，真相还未完全浮出水面。可以确定的是，为 Multichain 提供流动性的 LP 们、以及持有 Multichain 发行的映射资产 anyToken 的用户，恐怕是要遭殃了。这回受影响的资产数额太大，不知道会不会有人出来兜底。 7月6日，超过 1.26 亿美元的资产从 MPC 托管地址中被人为转出，根据合约审计团队 Beosin 的分析，资金的转出完全是人为操作，与合约漏洞无关，证明 Multichain 的MPC 托管地址私钥已经被外力掌控。 ![](https://storage.googleapis.com/papyrus_images/1aa96ed6476400a9fd4b73b987a7cf32f97739ce0a9e2b22816c32dbabefd20b.png) 在 7月 14日 Multichain 发布的官方声明中，明确宣布了 Multichain 创始人 zhaojun 已经在 5 月 21 日被警方带走的消息。然而令人大跌眼镜的是，声明中提到，Multichain 的 24 个 MPC 节点私钥全部由 Zhaojun 掌握，且所有节点服务完全在其个人服务器中运行！ ![](https://storage.googleapis.com/papyrus_images/20a7b1555d5567e6bf610a87db6b029b564b7c2256036a5d25065ff300b27870.png) WTF!!!!!!!!!!!!!!! ![](https://storage.googleapis.com/papyrus_images/a201c1ad80d831ec902b00f214ad49dcb21a8b4422c9b369387e81552b003ae3.png) 现在事件的进展还扑朔迷离，真相还未完全浮出水面。可以确定的是，为 Multichain 提供流动性的 LP 们、以及持有 Multichain 发行的映射资产 anyToken 的用户，恐怕是要遭殃了。多签桥的中心化风险，就像一只肥硕的灰犀牛，它就在那里，大家都能看到，但又选择性的忽略。关键这头犀牛还驮着数百亿美金的巨额资产！ ![](https://storage.googleapis.com/papyrus_images/6f20810e467e4a89c22348d45922f4ba67a36d7fbeda8b60af8780fe3f5cca8e.png) 目前，市面上 TVL 靠前的跨链桥几乎全部都是多签桥。在 Multichain 之前，已经发生过 Axie Infinity 官方桥 Ronin Bridge、Harmony Chain 官方桥 Horizen bridge 因私钥泄露而爆雷的事件，分别造成 6.2 亿美金和近 1 亿美元的损失。 多签桥为什么不值得信任？ ------------ 一般而言，跨链桥分为三种，分别是轻客户端型（原生验证）、见证人型（外部验证）、基于哈希时间锁的原子交易型（本地验证）。 其中基于哈希时间锁的原子交易，由于其用户体验欠佳（需要用户进行2次以上的操作），以及无法支持任意消息传递，鲜有采用。轻客户端型跨链桥则由于其工程实现上相对困难、兼容新链的成本较高，目前仅被应用在一些仅需支持少数链的专用桥当中。见证人型跨链桥则开发实现较为简单、可以轻易的进行多链适配，且性能较好（速度快，费用低），而成为大多数项目的选择。 见证人型桥通过一组外部的 Bridge Nodes 对跨链消息进行共识签名，以此来验证消息的真实性，因此我们也称之为多签桥。跨链桥一般采用 lock-mint 逻辑来链间传递资产，用户通过 lock 源链上原生资产（例如 USDC ），来 mint 目标链上的映射资产 （例如 anyUSDC），这些 lock 的资产会成为桥的 TVL，一旦被盗，用户或者 LP 手中的映射资产将与原生资产脱锚，无法足额赎回。但这些外部的 Bridge Nodes 如果串谋，或者他们没有保管好自己的私钥碎片导致其中2/3以上被黑客获取，这样的事情就会发生！ 大多数多签桥，少则只有个位数的 Bridge Nodes，多则也就 2 0多个。在 TVL 较低时，这些主体可能不会去串谋作恶，但当多签桥的 TVL 达到数亿美金时，没有人保证他们不会动心。如果利益足够大，串谋 20 个节点，并不算很困难。这还没有考虑到，很多跨链桥的诸多节点往往都是利息高度相关的“友商”，甚至一些跨链桥存在一个主体控制多个节点的情况，例如，Ronin Bridge 的 9 个节点中有4 个控制在 Star Mavis 公司手中， Multichain 的情况则更加过分，1 人掌握所有的 24个节点 ！ 一个成年人的标志是，不再相信人性经得起考验。 跨链桥将如何改进？ --------- Mulitichian 的事件对于跨链桥领域，或许将成为一个转型的契机。当大家都不再愿意容忍中心化带来的安全风险时，“多签桥”自然就玩不下去了。 如果说“多签桥”主导的时代是跨链桥的 1.0 时代，那么1.0 时代正在加速离去，跨链桥 2.0 时代的主角必然属于更加安全的跨链桥。 那我们应该用什么样的跨链桥呢，跨链桥如何改进，才能在保证性能可接受的情况下，消除中心化风险呢？我们观察到，业内主要有三个方向，分别是 ZKbridge、Optimistic Brige 和 TEE Bridge。 ![](https://storage.googleapis.com/papyrus_images/191eaf9a7c82276b506f2b690c721b2ba1c0f1d89688587a310d392332b7598a.png) ### ZK Bridge 由于 ZK 叙事的升温，近期将 ZK 技术用于跨链的探索也倍受关注，已经有不少该方向的项目获得融资。 ZKBridge 是一种将 ZK 技术用于轻客户端扩容的跨链桥方案。我们知道，轻客户端跨链桥有着极高的安全性，其本质是由目标链的共识层直接验证来自源链的消息，不引入任何第三方的信任假设，但轻客户端需要不断维护源链的区块头序列，此间需要对每个新区块头执行验证，这带来两大难点： * 巨大的链上开销，可能会使得桥不具备经济可行性 * 如果要做一个通用桥，每新增支持一条链，都需要至少开发两个新的轻客户端，兼容新链的成本较高，很难做成真正的通用桥。 引入 ZK 技术之后： * 可以在链下验证新区块头，并将新区块头及其有效性证明（Zk Proof）一并提交到链上，链上可以直接验证 ZK Proof，即可等效于验证新区块头，但开销可以大幅缩减。更进一步，还可以把用区块头对交易执行 SPV 验证的过程也放到链上； * ZK技术简化了轻客户端的开发，链上轻客户端仅需验证 ZK proof，比验证新区块头的合约逻辑要简单许多。 但 ZKbridge 的性能极限依旧弱于多签桥，以 EVM 为例，验证一个 ZK proof 的成本最低也在 500k gas，和多签桥只需验证一个签名的 21k Gas 相比，高了了将近25倍，这最终还是会转化为前端用户高昂的跨链费用。尽管通过批处理，可以让多笔交易分摊一次处理的成本，但这又会带给用户较长的等待时间。 此外，Zkbridge 作为轻客户端桥，需要接入链支持智能合约，BTC 类的非智能合约链是无法接入的。 ### Optimistic Bridge Optimistic 桥是对多签桥信任根的改良。Optimistic 桥在多签桥的基础上，引入了挑战窗口期的概念和一个名为“挑战者”的角色。 我们知道，一个消息在多签桥中的传递过程是这样的 ① 发起：用户在源链通过与 Source dApp 交互，发起跨链消息传递 ② 链下签名：消息被传递给 Bridge Nodes，完成共识签名之后传递到目标链 ③ 链上验证签名：目标链验证该消息是否由正确的 Bridge Nodes 的签名 ④ 执行：验证后的消息被提交给 Taregt dApp 进行执行 在Optimistic Bridge 中，消息在完成第 ③ 步之后，不会立刻进入第 ④ 步，而是会进入一个计时环节，计时结束后，如果没有挑战者对该消息提出质疑，该消息才会进入执行环节，被 Taregt dApp 执行。 如果挑战者对消息进行质疑，那么该消息将被标记为“不可信”，“不可信”消息将不会进入执行环节，挑战者将会把它提交会源链，由源链的仲裁合约进行仲裁，如果消息在源链真实存在则证明挑战者误报，如果消息在源链并不存在则证明 Bridge Nodes 欺诈，签名了虚假的消息。仲裁结束后，会给诚实的一方奖励，而惩罚不诚实的一方。 通过该机制，Optimistic bridge 将多签桥的信任根从 m-of-n，提升到了 1-of-n，只需要有一个诚实的挑战者，桥就是可靠的。 Optimistic Bridge 的缺点在于增加了用户的等待时间，该时间一般会在 30min 左右，用户必须等待挑战窗口期的结束，才能完成完成跨链操作，这在很多场景下都是行不通的，用户并没有这个耐心。实践中， Optimistic Bridge 往往采用双模型机制，小额转账或是非敏感操作会直接跳过挑战窗口期，只有大额转账或者敏感操作，才会有挑战窗口期，具体阈值可以由应用程序自定义，或是由用户在前端自己选择。 Optmistic Bridge 的机制无疑是对多签桥的巨大改良，既保障了安全，也兼顾了性能。但可惜的是安全和性能并没有真正意义上兼得，只是把安全优先还是性能优先的选择权交给用户，不能算是完美的解决方案。 此外，由于必须通过合约实现链上仲裁，该方案依旧不能支持BTC 类的非智能合约链。 ### TEE Bridge TEE Bridge 是指在多签桥的基础上，要求所有节点必须使用 TEE 设备接入网络。TEE 全称为可信执行环境 (Trusted Execute Environment)，它是给定设备上运行的与主操作系统隔离的计算环境，就像一块飞地 (Enclave)，这种隔离是通过硬件强制实现的。 在 TEE Bridge 中，节点使用 TEE 设备保管私钥碎片，签名程序也完全在 TEE 中运行，外部黑客将很难窃取。与 ZKbridge、Optimistic Bridge 不同的是，TEE Bridge 是通过节点硬件来提升跨链桥的安全性，而非改变链上的验证机制。 TEE Bridge 的优势在于 * 在提升安全性的同时，完全没有在多签桥的基础上牺牲性能 * 可以兼容 BTC 类的非智能合约链 但 TEE Bridge 依然存在内部串谋的风险。2/3 多数的节点如果串通，依然可以对桥发起攻击。 ### BOOL ：ZK-TEE Bridge 接下来，我要介绍一种更加巧妙的的跨链桥范式：ZK-TEE Bridge，它由跨链桥项目 Bool Network 首创。Bool Network 在 TEE Bridge 的基础上，结合 ZK 技术，实现了节点的完全匿名，从而无法串谋，保障了桥的超高安全性。 Bool Network 本身是一个众多 TEE 节点构成的非许可网络，任何主体都可以通过 Bool Network 申请建立一个或多个 DHC（Dynamic Hidden Committee）。如果某个主体需要建立一座支持 10 条链的跨链桥，那就申请 10 个对应的 DHC 就可以了，每个 DHC 都管理着一组 MPC 私钥分片，他们将会负责验证和签名跨链消息。 一个 DHC 一般会包含 10 到 20 个TEE 节点成员，具体由 DHC 的创建者来设置，签名阈值一般是2/3，但 DHC 的创建者也可以设置更高的阈值。 Bool Network 会随机的为所有 DHC 分配成员，并且会定期洗牌，重新分配。借助 ZK 技术，Bool Network 可以实现分配成员的过程是完全随机的，且分配完成之后，每个 TEE 节点都不知道自己被分配到了哪个 DHC，也不知道自己和哪些节点分到了一个 DHC，更不知道别的节点被分配到了哪个 DHC。这种感觉，就像参加假面舞会一样，谁也不知道谁是谁！ ![](https://storage.googleapis.com/papyrus_images/2ed834b2ec61c9960e1d8e79b0bc1203dc84226e43b96b1c8d7bd7c4f0e36c68.png) 这是通过 Bool Network 的 Ring VRF 算法实现的。具体来说，Ring VRF 在 DHC 分配节点成员的时候，会赋予每个 TEE 节点一个临时身份，该临时身份表现为一个 ZK proof，可以证明某个节点属于当前 DHC，但不暴露节点的具体信息。DHC 成员之间将通过临时身份相互识别，并通过加密通讯完成 MPC 签名的工作。在当前 Epoch 结束之后，Ring VRF 会重新洗牌所有 DHC 的成员，此时所有临时身份都会失效，Ring VRF 将为每个节点分配新的临时身份。 总之，Bool Network 通过 ZK 技术与 TEE 技术的巧妙结合，实现了节点之间的完全匿名，杜绝了串谋的可能，在 TEE Bridge 的基础上进一步提升了安全性。 小结 -- ZKbridge、Optimistic Bridge、TEE Bridge 都是很不错的方案，它们都在试图构建更加 Trustless 的跨链桥，消除中心化风险，提高跨链桥的安全性。但 ZKBridge、Optimistic 依旧存在性能上的牺牲和可扩展性上的短板，TEE-Bridge 则存在串谋攻击的可能。 BOOL Network 提出的 ZK TEE-Bridge 则是一个从各方面都无可挑剔的方案，它的优势包括： * 不牺牲的性能，跨链消息传递的速度和费用保持和“多签桥”同一水平 * 支持非智能合约链，且适配新链的工程量较低 * 杜绝了 TEE 桥中可能存在的串谋风险，实现了不亚于轻客户端桥的超高安全性 ![](https://storage.googleapis.com/papyrus_images/b24ca49d6b94c2ee0c7f2dd288fd11dbe69e781efea125e5b9a111246655d5e4.png) --- *Originally published on [0xmiddle](https://paragraph.com/@0xmiddle/multichain)*