本文深入探讨了 Wormhole 如何防止 VAA 重复攻击,确保每个 VAA 只能成功使用一次。文章详细介绍了在 Solana 和 Ethereum 上的实现机制,包括如何利用全球标记保持已完成的 VAA 的唯一性,从而防止恶意用户通过重复使用相同 VAA 来窃取代币。
本文深入探讨了区块链跨链交易中的最终性风险,解释了其产生的原因以及对用户的影响。文章重点介绍了 Across 如何通过将其风险转移给中继者并利用 UMA 的乐观预言机来缓解最终性风险。文章还对比了不同桥的设计方案,强调选择将最终性风险从用户处移除的平台的重要性。
Multichain于2022年1月10日意识到其流动性池合约和路由合约存在关键漏洞,影响了WETH、WBNB等八种代币。漏洞被修复后,仍有部分用户未撤销对受影响路由合约的授权,面临风险。Multichain发布公告敦促用户立即采取行动,并提出补偿计划,对已撤销授权并提交申请的用户100%赔偿损失。团队还向报告漏洞的安全公司Dedaub支付了高额漏洞赏金。
文章主要讨论了 Nomad 跨链桥遭受攻击后的应对措施和未来计划。文章分析了 Nomad 桥被黑的独特性,例如:黑客人数众多,被盗资金构成复杂,以及黑客攻击后的交易验证问题。Nomad 团队提出了三个阶段的恢复计划:资金追回、桥升级和桥重启及资金分配,旨在公平有序地让用户 "解桥"。
2022年2月2日,Wormhole网络遭受攻击,攻击者利用签名验证漏洞在Solana上铸造了12万枚无抵押wETH,并将其中93,750枚转移到以太坊。Jump Crypto已为合约注资以确保所有wETH都有足额抵押。Wormhole网络已恢复运行,并悬赏1000万美元寻求有关追捕黑客或追回被盗资产的信息。
本文深入探讨了以太坊多链互操作性的难题,将互操作性协议分为原生验证、外部验证和本地验证三种类型,并提出了互操作性三难困境:信任性、可扩展性和通用性不可兼得。Connext 的 NXTP 协议旨在实现安全和可扩展性,并通过协议栈的方式,在 NXTP 基础上添加原生验证协议,以实现通用性。
本文深入探讨了 Hyperlane,一个专注于安全性的跨链开发者工具 Arbitrary Messaging Bridge (AMB)。文章详细介绍了 Hyperlane 的设计、安全特性和信任假设,包括其工作原理、经济安全、应用特定安全以及审查抵抗性等,并讨论了团队和社区资源。
deBridge 是一个通用的跨链消息传递和互操作性协议,允许用户和开发者在不同链之间传递简单消息和复杂数据。文章详细介绍了 deBridge 的架构设计、交易生命周期、安全特性和信任假设,并探讨了其跨链互操作性的潜力及应用。
本文介绍了区块链领域中原生资产和非原生资产的区别,原生资产是由区块链网络或智能合约直接发行的代币,如ETH和AAVE。非原生资产是需要第三方包装或验证的代币,如wBTC。文章还讨论了如何通过规范桥、原子交换和LI.FI等方式实现原生资产的跨链转移,并强调了持有原生资产通常比持有非原生资产更安全且流动性更好。
本文讨论了多链未来面临的挑战,即流动性分散和互操作性问题,并介绍了LI.FI作为解决方案。LI.FI通过桥聚合协议,连接不同的桥和DEX,实现跨链的任意资产交换,简化用户在多链生态系统中的操作流程,提高效率,旨在解决多链环境下的流动性问题。
本次审核了across-protocol/contracts代码仓库,主要关注L3支持、ZkStack支持、可预测的中继哈希、支持最新版本的ERC-7683以及World Chain支持。发现了多个安全问题,包括缺少访问控制、错误的函数调用、不正确的ETH传输处理,以及潜在的重放攻击等。建议改进代码,增加测试,并确保代码符合最新的ERC-7683标准。
该文档是对Across协议的SVM Spoke Pool的审计报告,该协议将跨链桥接网络扩展到Solana生态系统。审计期间发现了19个问题,包括高、中、低严重性级别,涉及强制使用Claim Accounts、成本不对称利用、事件日志记录过度使用等,提出了改进建议。
本文分析了 Across Protocol 如何使用 UMA 的 Optimistic Oracle 来结算基于意图(Intents-based)的跨链交易,偿还中继者(relayers),并解决争议。Across 通过 UMA 的 optimistic oracle 实现了无需信任的跨链桥,验证跨链消息和结果,而无需依赖特权验证者或多重签名,为其他互操作协议提供了一个参考模型。
本次OpenZeppelin对Across协议的代码变更进行了差异审计,主要集中在pull request 941 和 pull request 944。
OpenZeppelin 对 Across Protocol 的 contracts-v2 代码仓库进行了安全评估,发现了多个问题,包括客户端报告的 refunds 处理不当、slow fill 潜在的支付不足以及 recipient/message 功能失效等问题。