学习100篇 Web3 安全文章 | 区块链运营私钥安全 ① | 第一篇：区块链运营中的私钥安全现状——概念、钱包类型与签名策略

原创

nccgroup
nccgroup

Ice ThirdSpace

2026年10月19日 10:37
广东

去阅读

原文地址：

https://www.nccgroup.com/research/state-of-the-art-of-private-key-security-in-blockchain-ops-1-concepts-types-of-wallets-and-signing-strategies/?utm\_source=chatgpt.com

欢迎阅读本系列的第一篇文章。本系列讨论区块链运营、加密资产托管，以及每个区块链相关项目都需要面对的私钥管理问题，面向开发者、安全专业人员和数字资产管理机构，介绍最佳实践及架构设计中的注意事项。

最近的事件再次提醒我们，这个话题有多么重要：Bybit 遭遇了截至当时规模最大的加密货币盗窃事件，超过 14 亿美元的资产在几秒内被盗走。

但这并不是新问题，也不会是最后一次。仅一个月后，Zoth 又因私钥问题损失了 840 万美元。这只是众多案例之一：私钥被盗、机构误将资金发送至错误地址，以及不同平台的漏洞，已在近几年造成累计超过 50 亿美元的资产被盗。

这一数字包括中心化平台遭入侵以及 DeFi 漏洞利用，反映出不同区块链生态普遍面临的风险，甚至还没有计入普通用户日常遭遇的诈骗、三明治攻击等较小规模的 DeFi 攻击。

本系列将介绍不同的托管与签名策略、托管方案的典型架构组件，以及常见的托管架构，共分为四篇：

1. 概念、钱包类型与签名策略，即本文。
2. 常见托管方案架构。
3. 私钥存储与签名模块。
4. 审批与策略。

第一篇将介绍核心概念，包括托管方案类型、钱包类型、签名策略和私钥常见存储位置。

当一个项目需要与区块链交互时，必须对如何管理用于签名操作的私钥作出一系列决定。

托管与非托管

机构首先需要决定采用托管方案还是非托管方案。

托管方案：由第三方管理和保存私钥。相应风险转移至第三方，而不再完全依靠机构自身资源承担。

非托管方案：机构自行负责私钥的存储及访问管理。

混合方案：许多数字资产托管服务商采用混合方式：大部分基础设施由第三方管理，但私钥保存在机构自己控制的环境中，例如 HSM。这适合希望保留私钥控制权、同时不愿自行处理区块链交互的机构。

对于混合方案，必须弄清楚：即使第三方没有保存私钥，它是否仍拥有足够权限，能够使用机构的密钥签署任意交易？

热钱包与冷钱包

在托管场景中，“热钱包”和“冷钱包”通常用于区分日常操作的钱包，以及存放较大金额、需要更严格安全策略的钱包。主要区别在于可以施加的保护程度。

热钱包：用于日常操作，通常可由自动化流程访问。由于需要持续使用，而且经常被其他流程自动触发，因此更容易遭到入侵，需要采用不同于低频使用私钥的安全措施。

冷钱包：不需要频繁使用，可以保持离线。在托管场景中，通常保存不用于日常提现等操作的大额资金。根据机构策略及使用频率，还可以采用物理隔离，使系统与任何网络断开，使用时需要人工介入。

“温钱包”有时用于描述类似冷钱包、但使用更频繁的情况。具体实现取决于限制和策略，例如密钥仍处于联网环境，但必须通过更严格的人工审批才能使用。

运营密钥

托管场景中冷热钱包的区别比较明确。但有些密钥并不直接持有加密资产，而是用于操作智能合约，例如 DeFi 协议。这些密钥称为“运营密钥”。

我倾向于把运营密钥比作公司的门禁卡：有的只能进入大厅，有的可以打开机房。如果每个人都有万能门禁，整个系统都会面临风险。

这些密钥的用途取决于智能合约的业务逻辑及其授权机制。

建议在智能合约中划分角色时，除了考虑功能，也要考虑操作风险和执行频率。角色越细，越容易将不同权限分配给独立私钥。

冷热钱包的思路也适用于运营密钥。例如，许多合约支持升级，能够升级合约实现的密钥高度敏感。由于升级通常很少发生，可能只用于紧急情况或周期性更新，因此应采用与冷钱包相当的保护措施。

另一方面，某些操作风险较低、执行频繁，例如自动向合约写入外部信息，对应密钥可以采用类似热钱包的保护方式。

签名授权机制

涉及区块链交易的操作，可能需要多个有效签名。对于合约升级等关键操作，要求多个签名是常见且非常推荐的做法。

你可以把多签想象成电影中的核武器发射流程：多名军官分处不同地点，必须同时转动各自的钥匙。

这样可以防止任何一个人独立行动，这正是合约升级、大额资金转移等敏感操作所需要的保护。

根据区块链网络和系统不同，多签可以采用不同实现方式。

链上多签

区块链原生支持的多签，例如 Bitcoin。这种方式直接由区块链实现，机构无需自行实现多签机制。但作者指出，某些原生多签方式可能需要广播多笔交易，从而增加成本，并可能在第一个签名出现时泄露交易意图。

通过智能合约实现的多签，例如 Ethereum。以太坊不在协议层直接提供这种多签功能，但可以通过合约实现。签名认证可以使用网络内置验证能力，或 EIP-712 等结构化消息签名方式。

通过合约实现时，彻底审计至关重要，因为漏洞可能允许攻击者绕过认证。

一个广为人知的例子是 Gnosis Safe，现称 Safe{Wallet}。它最近因参与截至当时最大的加密货币盗窃事件而受到关注。智能合约钱包提供了灵活性，但也应限制攻击面，因为更多功能意味着更多潜在漏洞。

链下签名机制

自定义链下机制中的审批策略：链下组件可以基于权限、私钥或其他机制建立审批规则，控制交易签名能力。这是托管系统的常见组成部分，也可以与其他多签机制结合。

从设计角度看，作者认为这种方式一般弱于其他多签方案，因为能够访问私钥并签署消息的模块，至少构成一个潜在的单点失陷位置。

MPC，多方计算：多个参与方可以在不向彼此暴露各自输入的情况下，共同计算有效签名。Fireblocks、MPCH 等平台采用这一技术。

签名过程发生在链下，完整私钥不会在单一位置生成或保存，也不依赖某一条特定区块链。只需全部份额中的一个子集，例如 N 个份额中的 M 个，即可完成签名；份额还可以在不改变原始密钥的情况下轮换或更新，提供一定灵活性。

签名授权机制比较

不同机制的优缺点可以互补：将链下机制的灵活性与链上强制执行结合，并用自动化检查辅助人工审核，检查那些无法直接从链上获得的信息。

结语

选择正确的密钥管理策略，是任何区块链项目最重要的决定之一。

还需要注意：使用第三方托管私钥时，你所管理的 API 密钥，很多情况下具有与私钥相近的权限，因此也应采用同等安全措施保护。

下一篇将介绍托管方案的核心组件，包括签名模块、审批策略、结算与存储。

本篇总结

1.私钥分类应结合业务权限、影响范围和使用频率，不能只看钱包是否持币。

2.合约升级密钥、管理员密钥等，可能比普通资金钱包密钥影响更大。

3.选择托管、MPC 或多签之后，仍要明确谁实际拥有签名能力。

4.托管平台 API Key 可能是资金操作凭据，应纳入高敏感凭据管理。

5.不同授权机制可以叠加，不能只凭“用了多签或 MPC”判断整个系统安全。