学习100篇 Web3 安全文章 多签架构 | 让智能合约安全超越私钥风险

原创

trailofbits
trailofbits

Ice ThirdSpace

2026年10月29日 11:30
广东

去阅读

让智能合约安全超越私钥风险

原文翻译：https://blog.trailofbits.com/2025/06/25/maturing-your-smart-contracts-beyond-private-key-risk/

“找出所有漏洞！”

这是大多数协议在部署智能合约前保障安全时的口号，也是主流方法。团队大量投入审计、竞赛、模糊测试和形式化验证，试图找出每一个漏洞。

但如果我告诉你，去年加密货币遭黑客攻击的最大原因，并不是智能合约漏洞呢？

给你一点提示：

答案是：私钥失陷！

攻击者滥用密钥材料盗取资产，这类私钥攻击是范围狭窄的智能合约审计和竞赛可能遗漏的威胁。

协议对这类攻击有多脆弱，取决于其设计，尤其是访问控制的成熟度。

本文将展示如何利用多签、时间锁、最小权限原则，以及从设计上减少私钥使用需求的方法，构建能够承受私钥失陷的协议。

私钥失陷已成为最有效的攻击方式

根据 Chainalysis 的 2024 年报告，黑客攻击所盗取资金中，高达43.8%源于密钥失陷，超过其他任何一种已确认攻击类型的五倍。

私钥失陷是一个明确的例子，说明工程师在设计新的智能合约和协议时，必须考虑这类危险威胁。

设计决定风险。然而，过去很少有区块链协议认真地将经过身份验证的智能合约访问，视为重大风险来源。

区块链安全生态的运作方式进一步加剧了这种忽视：区块链原生安全公司的审计，很少将架构层面的访问控制问题列为正式发现；竞赛平台则更倾向于代码级漏洞，并不鼓励提交此类架构问题。

这种狭窄的关注范围，与其他行业成熟的安全实践形成对比。在其他行业，权限提升和访问控制设计等架构风险，通常是安全工作早期就会处理的基础问题。

在 Trail of Bits，我们通过“代码库成熟度评估”识别架构层面的访问控制问题。

但大多数区块链协议直到软件开发生命周期的最后阶段，才寻求外部意见和审查。到了这个时候，修复系统性访问控制问题的时间和机会已经十分有限。

因此，我们需要把这项讨论提前到开发生命周期的更早阶段。本文旨在弥补这一差距，帮助开发者从第一天起，就设计出更能抵御私钥失陷的系统。

案例：超额抵押借贷协议

我们以一个假想的超额抵押借贷协议为例，说明访问控制成熟度的不同层级。

对于不熟悉借贷协议的读者，以下功能通常需要一定程度的高权限访问控制：

1.上架或下架支持的资产，包括抵押资产和可借资产。

2.设置风险参数、利率参数和预言机来源。

3.收取协议费用或储备金。

4.在紧急情况下暂停或恢复协议功能。

5.升级合约。

然而，这些访问控制机制的具体设计，会显著改变整个系统面对私钥攻击时的脆弱程度。

Level 1：高度暴露——单个 EOA 控制者

这是最不成熟、最基础的访问控制形式。

在这种架构中，单个外部拥有账户（EOA）拥有借贷协议全部管理功能的最高权限。

根据这把密钥的使用频率，以及紧急情况下需要多快使用，它可能必须保存在联网电脑上的软件钱包中。至少可以说，这并不理想。

【图片说明：一把签名密钥控制超额抵押借贷协议的全部管理功能。】

成熟度 Level 1：单点失效。一个 EOA 失陷，就意味着整个协议失陷。

这类系统的失陷风险极高，而且一旦失陷，后果会立即发生，并具有灾难性。

私钥一旦被攻陷，攻击者就可以升级合约、盗取抵押资产并摧毁协议。到那时，谁也别想靠它买上兰博基尼了。

如何提升至 Level 2

缓解这一单点失效最直接的方法，是改用多签钱包，要求多个密钥持有者共同批准操作。

需要注意：这能降低系统失陷的可能性，但如果足够多的私钥被攻陷，潜在损失范围并没有改变。

Level 2：基础缓解——中心化多签

认识到单个 EOA 控制者的巨大风险后，下一步是将管理权限转移给多签钱包，通常采用 M/N 门限的 Safe 钱包或类似机制。

【图片说明：一个由三名签名人组成的多签钱包，控制协议的管理功能。】

成熟度 Level 2：中心化多签模型。虽然需要多个签名人，但仍然只有一个控制点。

与 Level 1 相比，这是明确的进步，因为攻击者仅攻陷一名签名人的密钥，已不足以接管协议。

然而，如果足够多的签名人被攻陷、相互串通，或被诱导签署恶意交易，系统仍然面临重大风险：

执行速度：一旦获得第 M 个签名，恶意操作即可立即执行，安全团队没有响应时间。

单一控制点：虽然失效风险分散到了 M 把密钥上，但控制点仍然只有一个。多签作为整体，依然拥有协议的最高权限；即使是日常低风险交易，也需要使用与协议升级相同的签名权限。

Bybit、WazirX 和 Radiant Capital 等事件，都是高度保护的单一控制点遭到利用的案例。

在这些攻击中，尽管风险已经分散到多个失效点，攻击者仍然攻陷了那个关键控制点——多签。

如何提升至 Level 3

如果你觉得 Level 2 还不够，我完全理解。

从 Level 2 走向 Level 3，才是真正迈向成熟的开始。要达到下一层级，需要引入两类控制：时间锁和最小权限原则（PoLP）。

时间锁是一种合约，可以在操作获批与执行之间设置延迟，为审核和事件响应留出时间。

最小权限原则要求在逻辑上分离角色和职责，每个角色只获得完成自身功能所必需的最低权限。

这样，即使某个控制点失陷，损失也能被限制，攻击者不会因此获得其他无关关键功能的权限。

Level 3：增强控制——时间锁与角色分离

这一层级解决了 Level 2 的两个核心弱点：

用时间锁解决操作立即执行的问题。

用最小权限原则解决控制权集中的问题。

因此，安全成熟度得到显著提升。作者列举的 Level 3 协议包括 Aave、Compound Finance 和 Lido。

【图片说明：多个多签、时间锁和独立 guardian 角色组成基于角色的访问控制体系。】

成熟度 Level 3：时间锁与角色分离，为智能合约建立纵深防御。

如果获批操作能够立即上链执行，社区，尤其是安全团队，就没有时间响应。

时间锁合约允许引入一层额外控制：取消已经批准、但尚未执行的交易。

当获批交易仍在时间锁中等待时，团队可以使用 Tenderly 等链下工具进行监控，并与预期批准的操作进行比对。

如果一项非预期请求获得签名，时间锁就能给事件响应团队留出时间，审查、取消该操作，并启动事件响应流程。

对时间锁进行正确的监控和告警至关重要。如果没有监控，这项控制就失去了价值。作者以 Beanstalk 事件为例，认为其中未被监控的一天时间锁，导致了一次本可避免的攻击。

按照最小权限原则，我们至少可以划分出四个角色，将不同风险等级的职责分开：

与 Level 2 相比，Level 3 的架构风险大幅降低。

我们从一个控制点转变为四个控制点，并通过最小权限原则降低单个控制点失陷后的影响。此时，即使多签失陷，事件响应团队也有机会阻止攻击造成损失。

不过，风险依然存在：

复杂性风险：多个角色、多签和时间锁增加了系统复杂度。如果实现不谨慎、测试不充分，就可能引入新的漏洞或错误配置。

过度依赖暂停：暂停 guardian 虽然是必要的应急机制，但不是万能解法。攻击者越来越成熟，常通过私有交易池提交攻击，避免被提前发现。随着攻击手段发展，暂停机制降低损失的效果可能减弱。

如何提升至 Level 4

虽然多数协议通常满足于 Level 3，但复杂性风险，以及紧急暂停有效性可能下降的问题，促使我们考虑更高层级的访问控制成熟度。

Level 4 是作者设想的成熟协议终极形态：通过设计，彻底移除执行强大管理操作的需求，使协议真正去中心化。

Level 4：终极形态——彻底不可变与用户自主权

Level 4 代表访问控制设计成熟度的最高层级：彻底消除管理操作的必要性。

这是协议对去中心化和信任最小化最彻底的承诺，其好处是从根本上将访问控制风险移出协议的威胁模型。

【图片说明：通过工厂合约创建用户部署的借贷池，每个池采用不可变配置。】

成熟度 Level 4：系统不可变，控制点极少，甚至不存在。

实现 Level 4，需要采用与前几个层级截然不同的设计方式。多数以 Level 4 为目标的协议，也并不是“纯粹的 Level 4”。

Uniswap 和 Liquity 是努力接近这一目标的代表：它们的正常运行不依赖管理员持续管理，但仍保留极其有限的管理权限，例如费用或激励分配。

不要将 Level 4 理念与“把控制权交给 DAO 或其他组织”混为一谈。Level 4 协议的正常运行，不需要任何形式的管理控制。

对许多使用场景而言，从 Level 3 转向 Level 4，几乎难以实现。

以中心化交易所冷钱包为例：除非整个交易所都转变为去中心化协议，否则钱包就必须保留某种管理访问能力，才能向用户转移资金。

对于完全链上的协议，Level 4 虽然可能实现，但依然十分困难。

以本文的超额抵押借贷系统为例，需要从根本上重构设计：对于每个原本依赖管理员的组件，都必须设计一种完全不需要管理的替代方案。

1．可升级性

在 Level 3 及以下层级中，智能合约可以通过升级修复漏洞或增加功能。

在 Level 4 中，合约完全不可变。增加新功能时，必须部署一整套新合约，由用户自行将资金迁移过去。

由于无法通过升级修复安全漏洞，合约必须简单、精炼，并经过极其充分的测试、验证和审查。

2．资产上架与下架

大多数超额抵押借贷协议将资产上架与下架设为管理操作，因为如果允许任何人添加抵押资产，恶意代币就可能被用于盗取其他抵押资金。

要实现 Level 4，借贷协议可以支持彼此独立的市场部署。

在这种模式下，要增加一种新资产，就必须部署并配置一个完全独立的协议实例，明确绑定该资产或资产组合。

用户自行选择与该实例交互，还是使用支持其他资产的另一个实例。

3．风险参数

风险参数通常也由管理员配置。

在 Level 4 借贷协议中，这些参数要么在新资产市场部署时永久确定，要么被永久设定为遵循某种算法规则。

由于这些设置无法随意更改，必须通过严格建模、测试和验证，充分掌握它们的行为。

设计 Level 4 协议，需要接受重大权衡：

1.无法进行紧急干预。

2.系统一旦部署，就缺乏灵活性。

3.前期需要投入大量工作，验证设计的安全正确性和经济合理性。

尽管如此，作者认为，这种设计范式可以从根本上消除管理访问控制风险。其中许多设计模式，也能改善系统其他方面的安全性。

Level 4 体现了一种纯粹的去中心化赛博朋克理念：相比管理灵活性，更优先考虑不可变性和用户自主权。

为韧性而设计，而不只是事后响应

从单个 EOA 控制者的简单粗放设计，到 Level 4 激进的不可变设计，访问控制成熟度的演进揭示了一点：

协议的设计方式，从根本上决定了它面对私钥失陷时的脆弱程度。

2024 年，被盗资金中有 43.8% 源于私钥失陷，因此不能再忽视架构层面的访问控制。

传统漏洞挖掘仍然必不可少，但这类设计决策必须在开发早期作出，才能充分发挥作用。

可以采取以下行动：

根据成熟度框架评估协议。诚实判断当前所处层级；多数项目从 Level 1 或 Level 2 起步。

为最高风险的管理功能引入时间锁。即使只有这一项改变，也能显著改善安全状况。同时必须充分监控，确保非预期交易进入队列时能够及时响应。

梳理协议中的高权限函数。按照最小权限原则，将它们分配到逻辑清晰的不同角色。

考虑哪些组件适合采用不可变设计。即使整体系统仍需要管理权限，部分组件也可能从 Level 4 的设计模式中受益。

Trail of Bits 倡导这种整体性的安全视角。因此，我们提供面向开发生命周期早期项目的设计审查和设计阶段咨询。

这些服务让团队能够尽早获得专业建议，主动处理基础架构问题，并与开发后期侧重实现漏洞的传统代码审计形成互补。

最终，构建安全的去中心化系统，不仅需要寻找漏洞，还需要从第一天起，就将运营韧性纳入设计。

理解成熟度模型，并有意识地选择能够减少信任、限制失陷影响的设计模式，才能构建出既有创新性，又能抵御去中心化世界不断演变威胁的协议。