本文探讨了区块链行业中事件响应的现状,重点关注可用于保护智能合约管理资产的技术响应机制。文章还讨论了有效事件响应的要求,例如监控与检测、合约中的响应机制以及内部策略,并分析了阻碍链上响应机制广泛应用的原因,例如 gas 优化、对审查的担忧等。
每周对区块链行业智能合约的攻击已经证明了一件事:审计不应该是保护资产安全和防止资金损失的唯一工具。需要额外的安全层。几十年来,事件响应在传统安全领域一直有效,可以减轻受损资产的损失并保护组织的声誉。现在,区块链行业正在采用更强大的事件响应实践,以与他们现有的监控堆栈集成,从而直接解决区块链技术的细微差别。
在这篇文章中,我们将探讨区块链行业事件响应的当前状态。接下来,我们将专门关注可用于保护智能合约管理的资产的技术响应机制。
尽管整个行业普遍缺乏事件响应实践,但仍有一些组织和协议在其现有安全堆栈之外实施了事件响应协议。当前事件响应层的主要组成部分包括:
目前最引人注目的事件响应小组是 SEAL911,这是一个由行业志愿者组成的小组,包括 OpenZeppelin 事件响应负责人的参与,他们帮助协议响应安全事件,并且 最近在事件发生前阻止了一项重大损失。其他社区白帽也在积极报告、分析和帮助通过在正在发生的事件中利用漏洞来防止损失,目的是归还资金。然而,对于需要通过利用对其协议有深入了解的内部团队来加速响应流程的协议来说,依靠社区志愿者的可靠性不足。
一些组织,如 Lido、Matter Labs 和 Curve,已经采用通过多重签名安全委员会进行去中心化安全治理的想法。控制其事件响应功能的多重签名包括安全专家,他们提供有关何时激活事件响应功能的指导。此模型提供了基于志愿者的白帽和内部团队之间的中间地带,但在紧急响应时,共识驱动模型仍然可能很慢。
自动化是快速事件响应的一个反复出现的主题,并且通常是有效事件响应策略的关键。通过定义事件响应功能(如暂停)应在何时使用的风险参数和安全策略,某些警报可以触发自动链上操作的执行。虽然及时检测构成了预防的基石,但链上响应自动化能够快速采取行动以预防或减轻正在进行的攻击。但是,自动化只有在警报经过良好调整以最大程度地减少误报率接近于零并且仅产生高保真警报时才有效。
在你能够在链上响应事件之前,需要满足一些先决条件:
第一个要求是通过监控对协议构成威胁的特定参数来识别事件的能力。许多供应商提供通用监控服务,并且他们倾向于以类似的方式使用启发式识别、信誉系统、模式匹配、异常检测和 AI 模型来检测威胁。例如,去中心化监控平台 Forta 在其 攻击检测器提要 中使用字节码匹配来检测资金被盗之前的攻击活动,从而使团队能够在损失发生之前做出反应。对特定协议的更多自定义监控涉及查看协议不变量并检测这些不变量何时被破坏,表明存在妥协。
一旦通过监控检测到,对事件的有效响应需要在智能合约级别具有功能。今天最常见的功能是暂停协议,例如下图所示的 USDC 使用的暂停。


我们将在后面的章节中更深入地扩展特定机制。
在技术组件到位后,组织面临着开发用例的任务,即何时以及如何使用这些链上技术机制。这有时通过 DAO、多重签名安全委员会或内部安全或开发团队来完成。例如,DeFi 协议 Compound 使用暂停守护者多重签名,其中包括社区成员、OpenZeppelin 等安全合作伙伴和 Compound Labs 团队的混合。OpenZeppelin 与多重签名成员和 Compound Labs 合作开发了一套 安全策略,用于管理多重签名的使用。安全策略应补充技术响应机制,以便尽可能有效地使用它们。
在了解了有效事件响应的要求之后,今天实际存在哪些链上响应机制?我们将研究以下最常见的技术响应机制:
暂停已成为默认的响应机制,并以两种方式实施。首先,在广泛的层面上暂停整个协议。其次,在细粒度的层面上暂停各个功能,Compound 中的一个示例在下面显示。
OpenZeppelin 的合约库包括在 Pausable.sol 合约 中暂停的标准化实现,该合约提供 whenPaused() 和 whenNotPaused() 函数修饰符。虽然在协议被利用之前执行是一种有效的措施,但它会为所有其他用户创建拒绝服务条件,并且在可以通过升级应用修复之前,会牺牲完整性来换取可用性。
目前社区正在讨论的一种暂停机制是 EIP-7625:断路器,它提供了一种合约标准,“当超过预定义指标的阈值时,触发协议范围内的代币流出的临时停止”。
以 Compound 为例,它们还可以修改供应上限、借入抵押品、清算因子和资产价格提要,以减轻安全事件造成的损害。下面显示了一些允许这些修改的功能示例。
允许列表最常见的是项目为一部分用户提供对协议的早期访问权限的机制,但它也可以成为将功能访问限制为一组受信任地址的有用工具。阻止列表与允许列表相反,它假设所有地址都是允许的,除非另有说明。像 USDC 这样的稳定币(代码如下所示)实施阻止列表以维持对 OFAC 制裁地址的合规性。


它最常用于阻止已知的恶意地址与协议交互或转移代币。允许列表比阻止列表更安全,但也可能是一种过于繁琐和限制性的工具,会阻止合法用户与协议交互。
项目使用速率限制(特别是提款速率限制)来最大限度地减少损害,从而限制用户一次可以提取的资金量。Chainlink CCIP 实施速率限制,通过 AggregateRateLimiter.sol 合约“在源区块链和目标区块链上强制执行速率限制,以实现最大安全性”。这最大限度地减少了攻击者在给定时间段内能够提取的资金量,迫使他们通过多次提款,并让协议有时间识别事件并做出反应。但是,这也影响了受限制在定义的时间段内可以移动的资金量的普通用户,并且会在用户体验中引起摩擦。
诸如 Matter Labs 之类的一些 L2 rollup 项目实施结算时间锁,其中 L2 块在经过设定的时间段之前不会在 L1 上最终确定。这使协议有机会在 L2 批处理在 L1 上最终确定之前识别事件并回滚 L2 批处理。应该注意的是,Matter Labs 计划最终删除结算时间锁。
借助区块链技术,攻击通常会在几秒钟或几分钟内发生,并且数百万美元会在一次交易中消失。交易抢跑交易涉及监视公共 mempool,以查找利用交易,然后提交具有更高 gas 价格的交易,以便在原始利用交易之前被矿工拾取,从而赶在攻击者有机会之前利用该协议。这主要由各个社区白帽完成,但在某些情况下,公司能够在 攻击者之前抢跑利用交易。抢跑交易的有效性受到私有 mempool 和诸如 flashbots 之类的服务的可用性的限制。
有了所有这些可用的机制,是什么阻止了更多项目实施链上响应机制?目前,使这些机制更广泛存在一些障碍:
对 gas 优化的日益关注已推动协议朝着安全功能和检查的最低限度实施而发展,而事件响应机制通常会被牺牲以节省每笔交易中少量 wei 的 gas。额外的安全层的安心和好处超过了 gas 的少量增加。在 L2 网络上,廉价的 gas 成本降低了影响,但随着对区块空间的需求相对于供应的增长,这种情况可能会改变。最终,我们可以期望用户和协议愿意为更安全的资金和交易支付更多的 gas。
其他协议认为,由于这些功能通常无法完全防止利用,而是作为缓解措施,因此不值得将其包含在合约中。然而,今年发生的一些最大的黑客攻击发生在多次交易中。快速响应本可以防止在第一次恶意交易发生后损失数亿美元的被盗资金。
我们已经听到一些协议说“如果我可以预测威胁,我可以在合约代码中处理它”。虽然有时是这样,但我们继续看到审计代码的利用这一事实证明有必要为意外威胁做好准备并引入多层安全性。某些威胁(例如私钥泄露)无法通过链上代码完全消除,因此需要技术(和非技术)响应机制。
某些事件响应策略可能类似于中心化的 rug pull。例如,将资金转移到备份钱包、撤销访问权限和阻止列入名单可能是事件响应策略,但也可能表明中心化项目或合约正在促进恶意活动。用户对具有这些类型机制的项目持谨慎态度,这是理所当然的。随着时间的推移,协议将获得用户的信任,并且额外的技术机制将使用户更加放心,这些控制措施用于保存他们的资金,而不是窃取他们的资金。
区块链协议的主要优势之一是它们的可组合性:能够与其他去中心化组件无缝集成以创建更大、更复杂的系统。当系统的某个部分被暂停或其行为以其他协议所依赖的方式发生更改时,可能会导致下游效应,这些效应会变得混乱并可能阻止构建者。实际上,当协议面临攻击并随后被暂停时,它可以充当其他集成协议的保护盾。定向到这些集成协议的任何交易都将被回滚,从而降低了此类攻击的实际复杂性和潜在的后果。
链上事件响应机制越来越受欢迎,并且已经显示出减轻资金损失的能力。今天,虽然没有防止黑客攻击的万能药,但项目确实可以使用工具。如果实施得当(并作为总体计划的一部分),它们可以形成多层防御。结果:强大的安全态势,可以始终实时运行。技术响应机制只是更广泛的事件响应策略和计划的一部分。最佳实践事件响应计划包括培养强大的内部安全文化,为处理事件做好准备和计划,利用工具和专业知识,以及致力于通过模拟测试不断改进。我们将在以后的博客文章中介绍更多构成强大事件响应计划的内容。要了解更多关于如何更好地保护你的协议并获得有关浏览事件响应过程的帮助,请 在此处 与我们联系。
- 原文链接: openzeppelin.com/news/sm...
- 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!