学习100篇 Web3 安全文章 | 区块链运营私钥安全 ② | 第二篇：区块链运营中的私钥安全现状——常见托管方案架构

原创

nccgroup
nccgroup

Ice ThirdSpace

2026年10月20日 10:00
广东

去阅读

原文地址：

https://www.nccgroup.com/research/state-of-the-art-of-private-key-security-in-blockchain-ops-2-common-custody-solutions-architectures

欢迎阅读区块链运营私钥管理系列的第二篇文章。本系列包括：

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

上一篇介绍了托管与区块链运营的关键概念。这一篇将介绍常见架构，以及托管方案中最常见的组件。

我们在架构审查与威胁建模中重点关注的问题之一，是单点失陷：某个组件或高权限角色，例如身份提供商的管理员，一旦被攻陷，是否会导致整个平台被控制，或全部客户资金损失？

为应对这一问题，许多现代托管方案采用零信任模型，对每个请求持续进行身份认证、授权与验证，以确保数据完整性并降低系统性失陷风险。

无论采用什么架构，都应该特别关注零信任原则如何落实，以及是否有效消除了单点故障或单点失陷。

链下中心化架构

下面用一个简化架构展示链下中心化方案中常见且必要的组件。

签名模块

签名模块能够使用私钥签署区块链交易，但这不一定意味着它能够获取明文私钥。

具体访问方式取决于实现和架构。例如，私钥可能由 HSM 或 KMS 保护，而签名模块只有调用权限；也可能由安全 Enclave 中的模块在隔离环境内部解密并使用。

作为能够使用密钥的组件，签名模块是区块链运营架构中最关键的部分之一。设计或实现漏洞可能危及私钥安全。

在这种架构中，它是主要的单点故障位置。下一篇将详细分析私钥存储与签名模块。

审批与策略

这是任何区块链运营方案中另一个必要的关键组件，包括：

● 策略：规定允许执行什么操作、谁可以执行，以及不同操作所需的审批数量或门限。

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

这个主题值得单独讨论，后续将专门介绍。

数据库或其他存储

大多数应用都需要数据库保存配置。

评估托管架构中的存储组件时，应针对每项关键资产检查：未经授权的修改，例如数据库管理员直接改数据，是否可能危及整个方案？

例如，白名单地址保存在数据库中，如果攻击者把它们替换为其他地址，是否会破坏交易完整性？在这种情况下，白名单地址应由审批者签名保护。

再进一步，如果数据库保存的是为地址提供名称的地址簿，篡改它是否足以欺骗审批者？审批者可能以为自己正在批准向常用地址转账，实际上却批准了另一个地址。

对每项配置或资产都应提出同样的问题：攻击者修改它之后，能否危及整个方案？

交易管理器

区块链系统通常还需要交易管理器，或承担类似职责的代码。它连接区块链节点，既向链上提交交易，也读取状态、事件和交易信息。

根据架构，可以按用途划分模块，负责：

● 处理已发送至网络的交易。

● 监控交易是否确认。

● 执行交易备用处理机制。

● 取消或放弃交易。

● 决定 Gas 费用。

● 提高费用并重新提交交易。

● 监控事件。

● 检查状态。

区块链节点

有些机构自行运行节点，有些使用第三方节点服务。

需要考虑的主要风险，是是否向某一方赋予了过多控制权。如果节点提供商遭遇拒绝服务，项目可能无法连接区块链。

如果提供商被攻陷，它还可能返回恶意数据，隐藏或篡改项目看到的信息。如果节点与托管服务由同一提供商提供，风险可能进一步增加。

因此，通常建议使用多个提供商，并在可行时采用不同节点软件，以便在单个提供商故障或某款节点软件出现 DoS 漏洞时维持可用性。

结算：托管场景

当不同主体的资金集中存放于同一个钱包时，需要结算机制。

许多中心化交易所就是如此：它们维护一本账，记录每位用户持有多少种、多少数量的加密资产。

在这种架构中，我们经常观察到的严重问题是竞态条件：用户可能通过重复转账或重复提现，使资产被重复支付，造成资金损失。

消息队列

消息队列广泛用于现代架构，尤其是微服务架构，用来连接不同模块。

最重要的是正确实施身份认证，并遵循最小权限原则。

如果设计存在缺陷，消息队列也可能成为单点失陷位置：队列本身，或任何能够访问队列的微服务被攻陷后，攻击者可能提交任意待签消息，进而危及整个方案。

链下 MPC 架构

下图展示了一个 MPC 方案的基础组件。

它与前述中心化方案的主要区别，是密钥材料分布在审批者及其他系统之间。

在 MPC 正确实现的前提下，这种架构可以消除主要的潜在单点故障，因为签名需要分布式份额中的规定数量共同参与。

以 Fireblocks 为例，作者描述其不同审批者在移动应用中分别持有密钥材料，交易需要达到规定门限才能获得密码学意义上的批准。

不过，热钱包和运营钱包的许多操作需要无人值守的自动签名。因此 Fireblocks 提供了名为 Co-Signer 的组件，在图中简化为 MPC 签名模块。

它与中心化方案的签名模块概念相近，但位于不同的信任边界内，可以由不同主体控制。

这些自动签名组件还可以在签名前执行特定检查，帮助阻止人工审批中的操作错误。

链上托管

下图展示典型链上多签的基础组件，这里以智能合约钱包为例。

可以把它理解为 Safe{Wallet} 的简化版本。不过，图中“分发基础设施”的两个组件，在实际 Safe 基础设施中涉及超过十个微服务，功能也复杂得多。

其中可能中心化的主要基础设施，是与智能合约交互的 Web3 应用。

另一个组件称为审批分发器。在通过多笔链上交易完成操作的情况下，它可能不是必需的；但对于 Safe{Wallet} 使用的 EIP-712 等链下签名消息，则需要此类组件。

与所有 Web3 应用一样，客户端漏洞具有重要影响。跨站脚本攻击可能篡改发送给钱包的签名相关数据，或修改 Web 应用显示的信息。

审批分发器负责收集待签消息或交易，并展示给其他签名者。实现不当时，未授权主体可能提交恶意交易提案，增加签名者被骗的风险。

图中展示的常见签名方式，是浏览器钱包扩展，例如 MetaMask、Rabby，连接 Ledger、Trezor 等硬件钱包。

浏览器钱包也可以直接保存私钥，但存在以下风险：

● 钱包口令泄露后，私钥可能被导出。

● 运行扩展的设备，通常是笔记本电脑，一旦被攻陷，浏览器与扩展展示的信息都可能不可信。额外使用硬件钱包时，可以借助硬件设备核验实际签署的信息。

这里主要讨论链下基础设施。但多签智能合约本身也可以实现策略检查、允许交互的合约与函数白名单、不同角色，以及不同角色的签名要求等。

中心化、MPC 和链上架构各有取舍、风险与信任边界。下一篇将深入讨论共同的核心问题：私钥如何存储，以及如何用于签署交易。

本篇总结

● 架构审查的关键问题是：攻陷哪个组件，就足以控制资金？

● 数据库里的白名单、地址簿和审批配置，都属于资金安全相关数据。

● 消息队列、内部微服务和节点返回的数据，也需要验证可信性。

● 结算系统的竞态可能导致重复提现，与私钥是否泄露无关。

● MPC 分散密钥材料，但其周边系统仍有信任边界。

● 链上多签仍依赖链下提案、前端展示和人工判断，这些都需要保护。