学习100篇 Web3 安全文章 | 区块链运营私钥安全 ④ | 第四篇：区块链运营中的私钥安全现状——审批与策略

Ice ThirdSpace

2026年10月23日 10:00
广东

去阅读

原文地址：

https://www.nccgroup.com/research/state-of-the-art-of-private-key-security-in-blockchain-ops-4-approvals-and-policies/?utm\_source=chatgpt.com

欢迎阅读本系列第四篇，也是最后一篇。

本文聚焦审批与策略，其作用是确保交易、配置修改等敏感行为，只有在获得正确授权后才能执行。

我们将介绍策略如何定义、审批如何在链上和链下执行，以及帮助机构避免高成本错误和内部威胁的最佳实践。

本系列包括：

1.概念、钱包类型与签名策略。

2.常见托管方案架构。

3.私钥存储与签名模块。

4.审批与策略，即本文。

审批与策略

前面的文章多次提到审批策略。它是区块链运营基础设施中的关键组件。

这里需要区分两个可能结合、也可能分离的部分：

策略或规则：规定哪些行为允许、哪些拒绝，以及需要多少次审批。

审批流程：确保交易获得规定数量参与者的批准。

具体定义取决于方案，可以采用不同方式实现。部分能力可以放在链上，例如多签智能合约；其他能力可以放在链下，例如判断是否允许与某个合约交互。

下图展示了链下托管方案中一个简化的审批过程。

交易完成签名后，如何提交链上执行，取决于业务逻辑和系统架构。

确保系统有效的一个关键要求，是：修改策略或审批系统，也必须经过现有审批系统批准。

警告：如果某个高权限用户，例如数据库管理员，可以直接修改策略，系统就必须保证未经批准的新策略不会被接受。常见方法是由审批者使用自己的私钥对策略进行签名。

对于链下实现，还必须将审批与签名模块连接起来，确保签名模块只接受已经获得批准的消息。

警告：如果签名模块接受未审批交易，内部人员或被攻陷的组件就可能发送任意交易，绕过审批与策略。

策略

策略规定机构允许执行哪些行为，以及每类行为需要什么审批。

它们在一定程度上类似防火墙规则，应当默认拒绝，仅允许业务必需的行为。

策略不仅适用于链上交易，也适用于修改审批规则、增加白名单地址等操作。

例如：

• 向白名单地址转账，金额低于 X 美元时，不需要额外审批。
• 当日累计操作金额超过 X 美元后，不得自动批准。
• 只有具备 R 角色的用户可以发起或提出交易。
• 转账、添加白名单等敏感操作，需要两名运营、一名财务和一名安全人员批准。

策略还应理解智能合约交互及其参数，而不仅仅识别普通 ERC-20 转账。这样，机构才能为不同 DeFi 兑换等操作制定具体规则。

例如，拒绝过大的滑点，可以防止造成数十万美元损失的错误。

作者举出的案例中，Uniswap V3 的amountOutMinimum被设置为 0，相当于用户表示：即使卖出 220,806 USDT 后收到 0 USDC，也可以接受。这给了 MEV 搜索者实施三明治攻击的机会。

审批

最基本的审批要求通常是门限或法定人数：交易执行前，至少需要规定数量的人批准。

例如，五名参与者中至少三人必须签名或批准。

这可能足以满足小型机构，但较大机构通常需要更复杂的安排，涉及财务、运营、安全等不同部门，并为特定用户设置交易提案者或发起者角色。

审批流程中最重要的问题之一，是人的因素。

如果审批者没有合适工具理解自己正在批准什么，最终很可能出现错误，甚至导致合约控制权或数字资产被盗。

帮助审批者理解签名内容，主要有两种方法。

1.交易解码

交易，尤其是智能合约交易，应解码为实际行为。例如：

在 Uniswap V2 上，将 100,000 USDC 兑换为 99,587 USDT。还应展示相关地址，因为只有名称不足以准确识别对象。

向某地址转账 300 ETH。

2.交易模拟

除了交易解码，还应该进行模拟，突出危险行为，并提供交易的调用轨迹。

并非所有审批者都有能力理解全部细节，因此机构可能需要不同部门参与审批。

有用的模拟输出包括：合约发起的全部call和delegatecall。

发出的事件，例如

1.OWNER从旧地址变更为新地址。

2.具体状态变化。

3.其他解码后的操作。

将交易解码与模拟结合，可以在批准之前详细审查交易将执行什么，从而显著提高安全性。

审批分发器、协调器或编排器

为了让需要审批的方案可用，系统必须能够自动将待签消息或交易发送给各审批者。

具体实现取决于方案：可能是 API，也可能是消息队列；可以集成在审批模块内部，也可以独立部署。

某些方案，例如链上多签 Safe{Wallet}，使用 API 提交交易提案。

无论如何实现，都必须确保只有授权主体可以提交消息：

在链下认证系统中，可以是具有特定角色的用户。

在链上多签系统中，可以是具有提案者角色的授权地址。

也可以结合两种方式。

警告：如果审批分发器接受未授权主体提交的任意消息或交易，就可能把恶意操作发送给审批者，诱使他们批准。

链下与链上审批及策略

本文主要讨论链下审批，但这些能力也可以通过链上智能合约实现。

主要限制是实现依赖具体区块链，某些场景可能无法实现。作者以 Bitcoin 为例，指出它支持门限批准，但复杂策略存在限制。

作者认为，在链上实施策略能够确保规则得到执行，减少相关单点故障。

结语

本文及整个系列说明，区块链运营安全远远超出私钥存储。

审批策略与执行机制，使密钥托管具有实际的风险控制意义：管理风险、分散责任并防止滥用。

通过清晰策略、可靠审批流程，以及参与者和组件间的安全通信，机构可以提高对外部攻击、内部威胁及普通操作错误的抵御能力。

作者以 2025 年 10 月 15 日 Paxos 意外铸造价值 300 万亿美元的 PYUSD、随后将其销毁的事件为例，强调额度限制和多人审批的重要性。

无论链上还是链下执行控制，关键都在于：任何敏感操作都应经过充分审核与授权。

将私钥托管外包给第三方，也不会让风险消失，只会改变风险所在的位置。相关凭据应遵循最小权限、轮换和监控要求；审批与交易策略如何配置，决定了能否有效防止事故和滥用。

作者认为，实际事件很多源于权限过大的密钥和宽松策略，而非密码学被攻破。应像保护私钥一样加固这些控制，因为从运营效果上看，它们具有类似的重要性。

本系列至此结束，希望能够帮助读者设计和构建更安全、可信的区块链基础设施。

本篇总结

审批规则本身的修改，也必须受现有规则约束。

策略要覆盖转账、白名单变更、权限变更、合约调用和敏感配置。

审批者需要看懂实际行为，交易哈希或“审批通过”提示不足以支持判断。

解码解释调用内容，模拟辅助观察调用结果与状态变化。

审批入口需要授权，签名出口必须验证批准结果。

多人审批应体现职责分离，并按操作风险设置要求。

四篇合起来，应该记住什么

这套系列描述的是一套完整的资金操作控制体系：

甲方项目方安全工作，我认为最值得落地的五项检查是：

• 画出签名调用链。从业务申请、审批、队列、签名服务一直追到广播，找出任何能够跳过审批的入口。
• 审查高权限配置。确认数据库管理员修改白名单、审批人数、角色或地址簿后，是否能直接影响资金操作。
• 验证审批内容绑定。检查实际签署的交易是否与获批交易一致，防止批准后更换地址、金额、合约或参数。
• 检查重复执行。验证并发提现、消息重投、失败重试和重复回调是否可能造成重复支付。
• 补上链上与链下核对。持续检查内部账本、业务记录、链上余额与实际执行结果是否一致。