用户组合 DeFi 功能、移动代币和 NFT,以及在各种生态系统的 dApp 之间执行任何类型的多链调用。 Axelar 通过部署多层防御来解决复杂的网络安全问题。其安全堆栈始于 POS 共识和多样化的节点技术堆栈。 图 2 Axelar 技术堆栈图 Axelar network 本身是一条基于 Pos 共识的L1区块链,Axelar 由去中心化网络的验证人、安全网关合约、统一翻译、路由架构以及一套适用于协议和应用的编程接口(APIs)组成。 Axelar 通过其网络的验证者运行不同链的节点获取并同步各个区块链系统中的状态信息。验证者由 Token 持有者选举产生,并按比例获得投票权,投票权重由委托权益加权计算得出。目前 Axelar 网络已经激活的验证者有 70 个,并且必须获得超过 66.67% 的多数投票才能签署消息。 此外,投票权偏斜会降低PoS系统的安全性。Axelar 为 PoS 为缓解验证者的不均衡性问题,防止投票权利过于集中,采用了二次方投票的方案,签名权重将与验证人质押的 Token 数量的平方根成正比。当验证者不断增加质押数量,投票权累计变得更加困难。 2.Celer IM Celer IM 是 Celer Network 面向开发者的工具和基础设施,cBridge 可以看作是建立在 Celer IM 上的资产桥梁。 Celer 为所有用户设置了双重安全保障。 首先是 cBridge 的安全由 State Guardian Network( 简称 SGN)保障。SGN 是一个基于 tendermint 的 PoS 区块链,Celer Network 旗下的其他产品,包括 cBridge 和 Celer IM,在跨链交易中都高度利用了 SGN 的 PoS 安全性、快速确认和低成本的特征。 SGN 有 21 个验证者,一条信息必须由 2/3 的验证者批准,想要成为 SGN 的验证者需要质押代币 CELER。此外 Axelar 设置了质押和罚没机制。如果验证着出现故障或者被恶意破坏,将承担罚没的风险,质押 CELR 的数量越多,网络越安全。 目前,Celer 状态守卫者网络 2.0 已成功升级。相较于 SGN 1.0 ,SGN 2.0 着重优化了其从交易中捕获价值的能力:对于 cBridge 而言,SGN 捕获的价值基于其在 cBridge 资金池模式中每次处理交易量的大小;对于 Celer IM 而言,价值捕获基于跨链消息的大小。 中间延迟是 Celer 为 Dapps 专门设置的一个额外保障。即使大部分 SGN 被黑,如果没有资产真实发送,Celer 可以通过中间延迟的方式打断在目标链上的铸造,Dapps 可以在延迟的抉择上做出不同的选择与权衡。在这个延迟期间,dApps 可以实现或委托 SGN 节点作为一个监护人服务,对消息进行双重认证,在这个过程中监护人需要保持诚实和功能。 3.Layerzero LayerZero 是一种全链互操作性协议,专注于链与链之间的数据消息传递 LayerZero 也是一个传输层协议,并没有应用层,LayerZero 的架构主要包含端点(Endpoint),中继节点(Relayer)和预言机(Oracle)。 图 3 Layerzero 的通信过程 (来源:Layerzero 白皮书) LayerZero 通过将消息及消息证明传递和验证 Relayer 传递交易两者做分割,确保跨链过程的安全。Relayer 负责传递消息及消息证明,Oracle 负责根据消息所在区块,按需从源链获取区块头,然后目标链上的终端根据 Oracle 获取的区块头验证 Relayer 传递的交易。layerzero 对区块头本身的验证由作为外部验证人的第三方 Oracle 网络来完成的,验证过程发生在链下,本质上仍是需要信任第三方的一种行为。此外 Layerzero 跨链消息的有效传送需要其中继节点和预言机互相独立,需要假设预言机和中继器之间不窜在恶意的勾结。 4.Multichain anyCall Multichain 的前身是 Anyswap,是一个专注于跨链赛道的基础设施,致力于成为 Web 3 的终极路由器。 anyCall 是 Multichain 在其 Bridge 和 Router 产品基础上抽象出的新一代综合消息跨链交互协议。 Multichain 的跨链技术方案采用了安全多方计算(Secure Muti-party Computation,简称 SMPC)解决方案,通过独有的密钥分片技术,密钥分片分布在不同的节点上,每个节点独立拥有部分私钥,完整的私钥在整个 MPC 网络生命周期内都不会出现,通过 SMPC 安全多方计算+TSS 门限签名技术,确保密钥生成、存储和验签的全程安全,并在这种安全保证基础上实现节点之间的互操作。 根据 anyCall 白皮书内容,anyCall 由位于下层的链外信任机制和上层的部署在链上的调用/触发 API 组成。 其中由链外信任机制负责对源链“消息”鉴证共识,并按照指定的逻辑执行目标链寻址,并构建相应操作。 图 4 anyCall 技术架构(来源 anyCall 白皮书) 底层 fastMPC 去中心化的信任机确保了 anyCall 的综合消息跨链交互协议的去中心化属性。目前 Multichain 网络由 21 个节点组成,由不同的机构运行,并且需要大多数节点来共同验证消息。Multichain 的安全性依赖于节点的声誉。SMPC 节点成员不需要质押,且相对固定,AnyCall 的安全建立在对 SMPC 节点的信任假设基础上。 目前 Multichain 已经将底部信任层从 SMPC 网络升级到了 fastMPC Network。fastMPC 节点的执行速度比原有的 SMPC 1.0 快 4-5 倍,是更快速、更流畅的跨链解决方案,同时由于 fastMPC 向社区公众开放,这种开放式的模式去中心化优势更加突出。 5.Wormhole Wormhole 是一种通用的消息传递协议,Wormhole 的信任层采用 PoA 机制构建,由一组受信任的 Guardians(守护者)负责链间消息的验证、传输和处理从一个区块链到另一个区块链的消息。Guardians 是特定的具有资本背书和声誉背书的主体,包括 Jump Crypto、Everstake 和 Chorus One 等知名机构。 目前守护者网络有 19 名守护者,守护者负责 Wormhole 网络上的交易验证, 2/3 的守护者需要共同验证,一旦共识达成, 证明将会发送至目标网络进行交易或者特定合约执行。 图 5 跨链解决方案带来的安全性 值得说明的是,基于 SMPC 的跨链方案和多重签名方案相比更具有去中心化的特性。多重签名方案需要验证者拥有完整的私钥对交易进行签署,而在基于 SMPC 的方案中,整个密钥管理周期内,完整的私钥从未真正出现过,验证时并不独立拥有完整的私钥,签名确认交易只需凑齐几个私钥分片的签名即可,不存在泄露完整私钥的问题。 二、安全事件应对政策 跨链项目自身的跨链解决方案不意味着可以规避所有的风险,为积极防范和应对安全风险需要增加其他安全政策。安全政策的设计可以为用户提供更加强大的安全保障 ,安全政策应贯穿安全事件发生前、发生中和发生后。 安全事件发生前:这个阶段项目可能存在安全隐患,但没有被发现或利用。项目按照事先确定的安全政策开展项目的安全性运营。 安全事件发生中:这个阶段安全事件正在发生,但项目方可能还未察觉,采取何种措施让项目及时发现该安全事件非常重要。 安全事件发生后:这个阶段可能涉及资产损失,项目在知悉攻击发生且了解到漏洞存在后需要进一步采取的措施以减少攻击波动的范围,避免造成更多的损失出现。用户补偿方案的确定,如何更快地让业务恢复正常运营以及反思安全过程中存在的问题并提出进一步的安全保障机制,也发生在这一阶段。 1.Axelar Axelar 的安全事件应对政策主要集中在安全事件发生前,主要要措施包括进行安全审计,开启漏洞赏金、频繁的密钥轮换和进行速率限制。 (1 )安全审计。目前 Axelar 的安全审计覆盖涵盖其核心协议、智能合约、密码库、前端和后端代码等,从 2021 年 8 月到 2022 年 8 月,Axelar 已进行 27 余次审计,审计机构包括 Ackee Blockchain、Chaintroopers、Certik 等。详见https://github.com/axelarnetwork/audits。 (2 )漏洞赏金。自 2022 年 3 月 10 日开始,Axelar 与 Immunefi 的合作,设立了最高 225 万美元的赏金计划,详见https://immunefi.com/bounty/axelarnetwork/。Axelar 还在其官方文档中,明确了提交漏洞的方式,但是通过提交至security@axelar.network的漏洞,Axelar 明确表示最高奖励 100 美元 详见https://docs.axelar.dev/bug-bounty。 (3 )频繁的密钥轮换。攻击者可能会尝试通过依次破坏验证器来积累恶意密钥 密钥轮换可以保护 Axelar 网络免受顽固的攻击者的攻击。 (4 )速率限制。Axelar 的 ERC-20 合约具有速率限制功能,Axelar 可以对在给定时间间隔内可以传输多少资产设置上限。这可以最大限度地减少攻击,能减少攻击时可能被盗的资金数量。 2.Celer Network Celer Network 的安全事件应对政策主要集中在安全事件发生前和安全事件发生中。 安全事件发生前 Celer 的主要要措施包括进行安全审计、开启漏洞赏金、搭建风控系统、应用层限流、 24 小时监控和主动前端和 DNS 完整性检查。 (1 )安全审计。针对 Cbridge,Celer 目前只进行了 3 次审计,合作的审计机构为 CertiK、PeckShield 和 SlowMist。详见https://cbridge-docs.celer.network/reference/audit-reports。针对 Celer IM,Celer 目前进行了 2 次审计,合作的审计机构为 PeckShield 和 SlowMist。详见https://im-docs.celer.network/audit-reports。 (2 )漏洞赏金。自 2021 年 11 月 18 日,Axelar 与 Immunefi 的合作,设立了最高 200 万美元的赏金计划。详见https://immunefi.com/bounty/celer/。 (3 )搭建风控系统。通过风控系统可以监控桥的整体流动性,资产信息以及变化。 (4 )限流功能。Celer 在应用层设置的安全屏障,使单位时间内不能超过某一个特定的阈值,超过了会顺延时递 。 (5 ) 24 小时监控机制。可第一时间发现可疑问题。 (6 )主动前端和 DNS 完整性检查。这是 Celer 针对 2022 年 8 月发生的攻击事件添加的功能,以防止类似事件再次发生。 在发现安全事件的过程中,根据慢雾安全团队对 2022 年 8 月对 cBridge 跨链桥事故真相的分析,可以发现除了自身的 24 小时监控机制,Celer 联合了慢雾安全团队。详见https://mp.weixin.qq.com/s/SInU_o 3 Ct-7 A 6 pFbKLqzHQ。 3.Layerzero Layerzero 的安全事件应对政策主要集中在安全事件发生前,主要要措施包括进行安全审计和开启漏洞赏金。 (1 )安全审计。LayerZero Labs 表示其已经委托了 35 次以上的审计,但 LayerZero 在代码部署方面相对不透明,且其安全审计内容在其 Github 上也不能公开查询,详见https://github.com/LayerZero-Labs/Audits。 (2 )漏洞赏金。在 layerero 官方文档中表示将设立最高赏金为 1500 万美元实时漏洞赏金计划,并给出了报告提交地址。详见 https://layerzero.gitbook.io/docs/bug-bounty/bug-bounty-program。 此外,LayerZero 曾在 2022 年 4 月宣布与 Immunefi 合作,设立 1500 万美元漏洞赏金计划。但迄今为止在 Immunefi 平台上仍未能检索到改项目。 4.Multichain 2022 年 8 月,Multichain 算法&安全官 X Chang 曾在其官方博客中明确提到 Multichain 的安全策略,以黑客攻击事件发生的时间点分为三个阶段,即:发生前,发生时,发生后,且每个阶段都有对应的应对步骤与策略。 安全事件发生前的安全措施包括安全公司审计与内部开发者审计、开启漏洞赏金、安全事件舆论监测和跨链金额限制及链资金流量和总量限制。 (1 )全公司审计与内部开发者审计。截至目前,Multichain 累计进行了大量外部审计,外部审计 的合作伙伴包括 BlockSec、Certik、Dedaub、PeckShield、SlowMist、TrailofBits、Verichain 等多家知名机构。Multichain 上线的 anyCall、Router V 7、VeMulti、Multichain V 6、Threshold-DSA、 V 5 ERC 20、Cross Chain-Bridge 等产品都经历了严格的外 部审计。 详见https://github.com/anyswap/Anyswap-Audit/。同时 Multichain 团队设置了周期性的内部审计会议,至少为每月 1 次。 (2 )漏洞赏金。Multichain 运行着两个漏洞赏金计划,首先是自 2022 年 3 月 16 日起,Multichain 正式与 Immunefi 建立合作,设立了最高 200 万美元的赏金计划,且根据提交漏洞的严重程度具体分析,赏金上不封顶。详见https://immunefi.com/bounty/multichain/。此外 Multichain 还提供了一个可选择的漏洞赏金方案,Multichain 将为符合条件的漏洞发现提供最高 100 万 美元的奖励。详见https://docs.multichain.org/getting-started/security/bug-bounty-alternative。 (3 )安全事件舆论监测。通过设置关键词在主要媒体平台进行舆论监测,以期第一时间能够获取到行业内最新发生的安全事件,并举一反三,反思 Multichain 产品是否存在有类似的问题,及时作出事件应对反应。 (4 ) 跨链金额限制及链资金流量和总量限制。对于大额资金的跨链交易,平台采取延迟到账的规则。对于新开发链或安全评级略低的链,限定在某一时间段内,跨入或跨出的总量限制在一定范围内。 安全事件发生中的安全措施包括链上异常情况监测和调动社区、DAO的力量,反馈平台产品的异常行为。 (1 )链上异常情况监测。通过设置了一系列链上监测策略 Watchdogs,希望及时监测到数据异常行为。 (2 )调动社区、DAO 的力量,反馈平台产品的异常行为。分调用社区用户、DAO 的力量,对 Multichain 产品的异常情况进行反馈,团队在分析异常行为验证后做出及时响应措施。 安全事件发生后的安全措施包括 暂停所有相关平台产品以及安全基金兜底用户资产风险。 (1 )暂停所有相关平台产品。第一时间了解到漏洞存在后,及时、有效的关闭产品。 (2 )安全基金兜底用户资产风险。Multichain 设置了安全基金,约定将跨链手续费的 10% 拿出,用以补偿用户在特殊情况下受到的资金损失,给平台用户的资产带来安全保障。Multichain 安全基金于 2022 年 3 月设立,截至 2023 年第一季度,Multichain 安全基金已累计金额超 144 万美元。 具体安全政策详见https://medium.com/multichainorg/detailed-disclosure-of-multichain-security-policy-bde 0397 accf 5 。 5.Wormhole Wormhole 的安全事件应对政策主要集中在安全事件发生前和安全事件发生后。 安全事件发生前的安全措施包括安全审计、开启漏洞赏金、社交媒体监控、设置异构监控策略和推出 Governor 功能。 (1 )安全审计。Wormhole 也非常重视安全审计,与 Certik,Coinspect,Hacken,Halborn,Kudelski,Neodyme,OtterSec,Trail of Bits,Zellic 展开安全审计方面的合作。 详见https://medium.com/@wormholecrypto/wormhole-security-program-end-of-year-update-212116 ecfb 91 。 (2 )漏洞赏金。Wormhole 项目也运行两个漏洞赏金计划,首先是自 2022 年 2 月 11 日开始与 Immunefi 的合作,设立了最高 250 万美元的赏金计划。详见https://immunefi.com/bounty/wormhole/。另外也可在其官网上浏览相关信息并提交报告。详见 https://wormhole.com/bounty/。另外 Wormhole 提供了使用 Wormhole 的策略列表,这可以降低白帽黑客在 Wormhole 中发现安全漏洞的门槛。 (3 )社交媒体监控。Wormhole 维护着一个社交媒体监控程序,以便 Wormhole 项目获悉依赖项中的漏洞可能会对 Wormhole、其用户或 Wormhole 所连接的链产生负面影响。 (4 )设置异构监控策略。Wormhole 在 Guardian 中设置异构监控策略,增加检测欺诈活动的可能性。Wormhole 期望所有守护者都开发和维护自己的安全监控策略。 (5 )推出 Governor 功能。创建和部署此功能的核心原因是帮助防范智能合约或 L1 妥协的存在风险。此功能允许 Wormhole Guardians 具有可选功能,可以在每条链的基础上对任何已注册的资产的名义价值流量进行速率限制。 Wormhole 在安全事件发生中的安全措施不明确,但是在 2022 年 2 月的 Wormhole 攻击事件是虫洞网络贡献者在例行检查中注意到未偿资金的差异,并立即开展调查确定的漏洞。 安全事件发生后的安全措施包括建立事件响应机制和紧急暂停。 (1 )事件响应机制。Wormhole 维护着一个事件响应程序,以响应对 Wormhole、其用户或其连接的生态系统的漏洞或活动威胁。 (2 )紧急暂停。Wormhole 项目评估了具有安全功能的概念,允许 Wormhole 智能合约在存在危机状态期间暂停而无需合约升级。 此外,在针对 2022 年 2 月 2 日遭黑客攻击事件发布的报告中, Wormhole 提到将进一步加强跨链消息传递和桥接的安全措施,主要包括隔离各个链风险的会计机制、动态风险管理、持续监控和早期发现事件。 三、更去信任化的方案探索 目前跨链市场上验证方式可以分为三种,即原生验证、本地验证和外部验证。这三类验证方式都有自身的局限性,难以兼顾去信任化、可拓展性和通用性。 外部验证方案是通用性非常高且可扩展的跨链计算方案,可以支持更复杂的跨链应用。本文中所提到的 Axelar、Celer Network、Layerzero、Multichain 和 Wormhole 都属于外部验证者一类,他们可以在链下完成验证,可拓展性较高,能覆盖不同技术架构的区块链,并且可以实现通用的消息跨链。但是由于用户必须信任这一组外部节点构成的中继网络,其在安全程度上要弱于无需信任的本地验证和原生验证方案。 最安全的跨链桥设计应该是最小化信任。但目前市面上存在的原生验证方案,如 Hop 和 Connext 通用性差,不适用于通用消息跨链, Cosmos IBC 和 Polkadot XCMP 这类原生验证方案可拓展性较弱,更多适用于同构区块链,难以兼容 Ethereum、Solana等众多异构链。 ZKP技术则为安全的跨链通信带来了新的路径。ZKP 跨链作具有去信任化,通用性强,成本低等优势。相对于目前通过信任第三方实现的跨链通信的跨链方案,ZKP 跨链不引入任何信任假设,用户只需要信任源链共识和目标链共识,属于原生验证方案一类。而且 ZKP 通过生成简洁的 ZKP 证明,减少 Gas 费用的需求,使得目标链可以高效地验证目标链交易,链上验证成本降低。 Hyper Oracle、Succinct、Nil.foundation 等通过 ZKP 技术入局跨链市场也印证了 ZKP 技术用于实现更安全跨链方案的潜力。目前 Multichain、Celer Network 和 Wormhole 已经开始布局 ZKP 跨链。 图 7 ZKP 跨链新布局 此外,通过 Axelar、Celer、Layerzero、Multichain 和 Wormhole 公开的信息,梳理其对安全事件的应对政策,可以发现存在以下几点问题。 (1 )创新性方案非常匮乏。Multichain 设立安全基金,用于补偿用户因多链系统和服务漏洞而造成的任何潜在损失。这种具有兜底性质的安全方案在行业中尚不多见。 (2 )并不是每一个跨链项目都覆盖事前事中事后的安全政策。在本文所选的 5 个项目中,只有 Multichain 明确了事前事中事后的安全政策。 (3 )安全保障机制尚不完善。开启漏洞赏金和进行安全审计是安全事件发生前的常见操作。但跨链项目缺少全面的综合性的安全应对解决方案和安全机制,相关的安全措施往往是在安全事故发生后才提出,事先并没有完整性的安全标准和危机应对流程。如 Wormhole、Multichain 是在安全事件发生后才与 Immunefi 合作开启漏洞赏金计划。 跨链技术目前仍处于初步探索阶段,行业内也尚未形成统一的跨链标准和稳定的跨链体系。虽然跨链项目对于跨链安全付出了很多努力,但依赖于跨链项目本身的解决方案以及采取的非技术安全措施无法一劳永逸解决跨链安全的难题。防范安全攻击是一项永无止境的任务,虽然 ZKP 给予了解决跨链安全问题的新思路,但整体来看,ZK 跨链项目普遍没有经历大规模的市场检验,合约的安全性仍需要进一步跟踪和观察。各种跨链方案在在发展过程中也会遇到各种安全性挑战,如网络安全挑战、技术本身存在的挑战、无法避免出现的智能合约漏洞等。跨链安全的道路任重而道远! 参考文献: https://axelar.network/blog/an-introduction-to-the-axelar-network https://axelar.network/blog/security-at-axelar-core https://docs.axelar.dev/learn/security https://celer.network/technology#top https://twitter.com/CelerNetworkcn/status/1560911682339508224 https://mp.weixin.qq.com/s/SInU_o3Ct-7A6pFbKLqzHQ https://blog.celer.network/2023/03/21/brevis-a-zk-omnichain-data-attestation-platform/ https://layerzero.network/pdf/LayerZero_Whitepaper_Release.pdf https://drive.google.com/file/d/1NFFFecAjStbGMyvJVDez3xmsGSHYvNYv/view https://medium.com/multichainorg/detailed-disclosure-of-multichain-security-policy-bde0397accf5 https://medium.com/multichainorg/multichain-contract-vulnerability-post-mortem-d37bfab237c8 https://drive.google.com/file/d/1ibuHChcYcYCN6JelRAQPnM4rkaB9EgAM/view https://github.com/wormhole-foundation/wormhole/blob/dev.v2/SECURITY.md#3 rd-party-security-audits https://wormholecrypto.medium.com/wormhole-incident-report-02-02-22-ad9b8f21eec6 https://medium.com/@wormholecrypto/wormhole-security-program-end-of-year-update-212116ecfb91 来源:金色财经lg...