金融服务视角
最后更新：2026 年 9 月 13 日
本文涵盖内容
- 金融服务为什么会选择联盟链而非公有链，以及这一选择实际会失去什么
- 隐私要求与“所有人都能看到同一份账本”的前提在哪里冲突，以及可以怎样解决
- 密钥管理、监管以及与现有基础设施集成中，哪些问题会成为实际的评审事项
首先：排除区块链不适用的情况
金融服务领域评估区块链时，最常见的问题是技术不适用于问题却仍然推进。本文从这一判断开始。
如基础知识所述，区块链的本质是“在没有可信仲裁方的情况下达成一致”。为此付出的代价是吞吐量和复杂度。因此：
| 情况 | 区块链是否合适？ |
|---|---|
| 数据由单个组织拥有并控制 | 通常先考虑数据库/审计日志等替代方案，并明确比较验证和治理要求 |
| 存在仲裁方，且所有人都信任它 | 不合适：使用该仲裁方的数据库就足够了 |
| 只需要检测篡改 | 通常不合适：哈希链、签名日志或 WORM 存储即可满足需求 |
| 多家彼此不信任的机构需要更新共享状态 | 值得评估 |
| 必须让第三方能够独立验证 | 值得评估 |
| 机构之间的对账成本确实很高 | 值得评估 |
“只需要检测篡改”是一个尤其常见的误解。如果目标是建立审计跟踪或完整性证明，可以不用区块链，而采用带签名的追加写入日志、哈希链或对象存储的 WORM（一次写入、多次读取）功能，运维也会简单得多。
Amazon QLDB 的案例很有启发性。QLDB 提供的正是“由中央可信方管理、且可以通过密码学验证的账本”，其前提是很多问题只需要这样就能解决。服务虽然已结束，但问题定义仍然成立：许多需求并不需要完整的去中心化共识。
实际建议：如果你无法用一句话说明“为什么这个问题必须没有仲裁方”，请先比较非区块链方案。
为什么选择联盟链
一些金融应用选择许可型网络，以便控制成员资格、治理和数据存放位置。另一些应用则在公有网络上采用额外控制措施。仅凭网络类型，不能证明满足 KYC/AML、隐私或其他合规要求；应根据实际司法管辖区、业务活动、参与方和数据流进行评估。
| 限制 | 公有链中的问题 | 联盟链中的情况 |
|---|---|---|
| 参与者身份识别（KYC/AML） | 仅凭公有地址无法识别法定交易对手；应用层控制取决于具体活动 | 成员资格控制有所帮助，但本身不能证明合规 |
| 数据主权和数据位置 | 数据会复制到全球各地的节点 | 仅存放在参与机构控制的节点上 |
| 吞吐量和延迟 | 吞吐量及概率性/经济最终性因协议而异 | 取决于共识机制和工作负载；许可机制不保证性能 |
| 治理 | 无法控制协议变更 | 由联盟决定 |
| 费用模式 | 网络费用加运营/集成成本 | 网络特定费用、治理和基础设施成本；并非自动只有基础设施成本 |
| 错误处理 | 错误交易无法撤销 | 可以通过治理流程响应 |
必须针对具体业务活动和司法管辖区设计交易对手识别与客户数据处理。公有地址不会自动提供法律意义上的匿名性，联盟成员资格也不会自动满足身份识别或数据位置义务。请与具备资质的合规/法律负责人一起审查这些事项。
选择联盟链后实际还剩下什么
这里需要坦诚说明：选择联盟链会削弱区块链原本大部分价值主张。
| 公有链的价值 | 联盟链中的情况 |
|---|---|
| 抗审查 | ✗ 有一方控制成员资格 |
| 无需许可即可参与 | ✗ 需要审批 |
| 无需仲裁方 | △ 联盟运营方实际上成为仲裁方 |
| 抗篡改 | △ 成员中的串通多数可以篡改 |
| 独立验证 | ○ 在联盟成员范围内有效 |
| 降低机构间对账成本 | ○ 保留 |
| 形成同一份共享状态 | ○ 保留 |
因此，联盟链的实质价值会缩小为“让各机构看到相同数据，从而消除对账工作”。这是真实价值，但它与“去中心化”或“无需信任”不是一回事。
这一差异在评审中很重要。如果提案写着“去中心化、无需信任地运行”，评审方就会问“那谁控制成员资格？”，而如果答案是“联盟秘书处”，原来的论证就站不住脚。从一开始就把价值定义为“降低机构间对账成本”，更有说服力。
隐私：最棘手的问题
根本冲突
区块链的前提是“每个人都能看到同一份账本并自行验证”。金融交易的要求则是“非交易对手的第三方不能看到我的交易”。
两者直接冲突。要验证就必须查看数据；要保护隐私就不能让其被看到。
可以采用多种方法解决这一矛盾，但各自都有代价。
方法与权衡
| 方法 | 原理 | 代价 |
|---|---|---|
| 通道隔离（Fabric） | 为每个交易组使用独立账本；只有通道成员持有数据 | 每个通道都会增加运维复杂度。跨通道原子交易很困难 |
| 私有数据集（Fabric） | 账本上只存哈希；实际数据仅保存在授权节点上 | 增加数据分发和生命周期管理负担 |
| 零知识证明（ZKP） | 不泄露内容也能证明某个陈述为真 | 计算成本、电路设计难度、可验证性评审 |
| 链下存储 | 敏感数据存放在链下，链上仅存哈希/指针 | 链下存储的可用性和完整性会成为新的依赖 |
| 加密存储 | 在链上存放密文 | 密钥管理成为访问控制；密钥泄漏会暴露全部历史数据 |
如何选择
通道隔离是最常见的起点。概念简单，Fabric 原生提供此功能，并且“谁能看到什么”定义明确，容易在评审时解释。
其局限是跨通道交易。例如同时有 A-B 通道和 B-C 通道时，很难原子化处理将价值从 A 转移到 C 的交易。如果业务流程属于这种情况，就需要重新考虑设计。
追加写入/公有账本上的加密记录可能会留在历史副本中；之后重新加密也不会擦除这些副本。密钥泄漏可能暴露使用该密钥加密的记录。许可型网络中的私有数据清除机制语义不同，因此应核实实际保留策略和密钥模型，不要笼统地声称任何区块链都无法删除数据。
ZKP 功能强大，但很难通过评审。向评审人员解释“无需泄露内容即可证明其真实性”，与确保实现正确是两项不同的挑战。如果方案需要可信设置，该设置是否值得信任也会成为问题。
与被遗忘权的冲突
隐私法规的删除要求与区块链的不可变性存在冲突。
通常的做法是“不要将个人数据放到链上”：链上仅保留标识符或哈希，个人数据放在链下以便删除。但知道原始内容的人仍可能通过哈希查找数据（彩虹表攻击），因此还要配合删除盐值或密钥，使恢复数据在实际上无法实现（密码学销毁，crypto-shredding）。
需要核实
各司法管辖区和具体案件对隐私法规（韩国 PIPA、GDPR 等）的删除要求与区块链不可变性如何适用，解释可能不同；本文不构成法律建议。
哈希或密文是否构成个人数据、密码学销毁是否满足删除义务，必须咨询法律/合规职能部门并核对监管机构的解释。在进行技术设计之前就应得到确认。
密钥管理：金融服务中最重要的事项
基础知识指出“密钥即权限，丢失后果不可逆”。以下说明为什么这个问题在金融服务中格外重要。
相互矛盾的要求
| 要求 | 与之冲突的要求 |
|---|---|
| 密钥必须在线才能签署交易 | 密钥必须隔离 |
| 可用性：签名延迟意味着服务中断 | 多方审批：任何单一参与方都不能独自签名 |
| 必须备份：丢失后无法恢复 | 备份本身是泄漏途径 |
| 必须可审计：谁签了什么 | 密钥本身不能泄漏 |
在金融服务区块链中，这一矛盾是最难设计的部分。
可用机制
| 机制 | 提供什么 | 局限 |
|---|---|---|
| HSM（CloudHSM、本地 HSM） | 硬件保护的签名和可配置的密钥保护 | 核实所选模块支持的算法、密钥是否可导出/封装以及备份策略 |
| AWS KMS | 托管密钥、IAM 集成、CloudTrail 审计 | 确认其是否支持区块链所需的签名算法 |
| MPC（多方计算） | 密钥以分布式份额保存，组合份额进行签名；任何地方都不存在完整密钥 | 实现复杂、依赖供应商 |
| 多重签名 | 协议层面要求 N 个签名中的 M 个 | 需要链/合约支持，且交易成本更高 |
| 冷/热隔离 | 大部分资产离线，只有少量资产在线 | 增加运维流程负担 |
按曲线区分支持情况：差异发生在不同层
密钥管理设计中最常见的问题就是这里的假设。基于“我们会使用 KMS”构建的方案，可能会因算法支持不足而失败；关键是以太坊的两个层使用不同的椭圆曲线。
| 层 | 曲线 | 用途 | AWS KMS / CloudHSM |
|---|---|---|---|
| 执行层（账户、交易） | secp256k1 | 交易签名、EOA 账户 | ✅ 支持：KMS key spec 为 ECC_SECG_P256K1，用途限于 SIGN_VERIFY |
| 共识层（验证者） | BLS12-381 | 区块提议和证明签名 | ❌ 不支持 |
使用 SIGN_VERIFY 的 KMS ECC_SECG_P256K1 可以支持经过适配的以太坊 ECDSA 签名流程。仅支持曲线还不够：还要验证摘要处理、DER 到链上签名的转换、low-S/恢复要求以及确切交易格式。比特币签名方案不同；支持 secp256k1 不代表支持所有 Schnorr/Taproot 流程。请勿使用真实资金进行测试。
共识层才是问题所在。BLS12-381 不在 KMS 的密钥规格中，CloudHSM 也不支持它。因此，将验证者签名密钥放进 KMS/HSM 的设计无法工作。
AWS 提出的替代方式是 Nitro Enclaves：在隔离的执行环境中运行 Web3Signer 之类的签名器，使密钥不会离开 Enclave。密钥生成（EIP-2335 格式的 BLS12-381 keystore）也需要另行解决。
设计影响：除前文讨论的验证者密钥矛盾（必须持续在线、隔离保存且不能重复签名）外，还多了一个限制：常见的“用 HSM 保护密钥”方案不适用。如果你正在评估验证者运维，这就是从基于 KMS 的设计转向其他方案的第一个分叉点。
需要核实
上述支持状态截至研究时为准；业界长期讨论过 HSM 对 BLS12-381 的支持情况，因此可能发生变化。对于以太坊之外的协议（例如使用 Ed25519 的链），也需要单独确认其曲线支持情况。
设计前请检查最新的 KMS key spec 参考，并始终通过 PoC 验证实际签名能在目标链上通过验证。
验证者密钥的特殊情况
运行 PoS 验证者会引入一个额外问题。
- 签名密钥必须持续在线，因为每个 slot 都可能出现签名机会。
- 同一验证者的冲突签名可能导致罚没。多个未协调的签名者/密钥副本会产生这种风险；重复的同一签名并不一定会被罚没。
- 因此，“为提高可用性而增加冗余”本身会带来风险。
普通部署应使用单个活动签名者，并采用具有隔离令牌的故障切换，同时保留罚没保护历史记录。任何 active-active/分布式签名者都需要经过验证的共享罚没保护设计。不要仅为了提高可用性，就启动一个复制了正在使用的验证者密钥的第二签名者。
监管与评审事项
金融服务评审中实际会提出的问题：
| 事项 | 问题 | 应准备的回答 |
|---|---|---|
| 必要性 | 为什么不能使用普通数据库？ | 用一句话说明“为什么必须没有仲裁方” |
| 参与方控制 | 谁控制成员资格，如何控制？ | 治理结构以及加入/退出流程 |
| 数据位置 | 数据会复制到哪里？ | 节点位置和区域控制措施 |
| 访问控制 | 谁能看到什么？ | 通道/PDC 设计、加密策略 |
| 删除请求 | 如何响应个人数据删除请求？ | 确保个人数据存放在链下的设计 |
| 密钥管理 | 密钥存放在哪里，谁能访问？ | HSM/KMS/MPC 结构及职责分离 |
| 错误纠正 | 如何撤销错误交易？ | 治理流程。必须以流程而非技术回答 |
| 可用性 | 节点或联盟发生故障时怎么办？ | 故障域、成员各自独立运行的能力 |
| 审计 | 审计人员检查什么，如何检查？ | 审计访问方式、日志 |
| 升级 | 谁决定协议变更？ | 联盟治理 |
| 终止计划 | 服务关闭后如何处理数据？ | 退出策略 |
| 供应商/服务锁定 | 托管服务终止时怎么办？ | 标准协议、抽象层（参见 AMB 文档） |
最常准备不足的两个事项
① 错误纠正：“无法撤销”在评审中会成为弱点。
被宣传为区块链优势的不可变性，在金融运维中也会形成问题。错误交易、误转账和系统故障确实会发生；金融机构有义务，也有既定流程来纠正这些问题。
答案是流程，而不是技术。标准做法不是“回滚区块链”，而是“发起一笔补偿交易”：保留原始交易，再增加一笔用于纠正结果的抵销交易。这与会计中的冲销分录概念相同。应记录该流程及其审批权限，以便评审。
② 退出策略：几乎从未准备。
联盟解散、成员退出或系统关闭时，数据和义务如何处理？金融数据有保留义务，因此“我们关闭了区块链”并不代表工作已经结束。
需要准备：账本的导出格式、由谁保留数据、如何处理退出成员的数据，以及如何访问记录。这些内容应写入联盟协议，并且技术设计必须支持它们。
与现有金融基础设施集成
现实中，区块链通常是与现有系统并行运行，而不是取代它们。实际问题常出现在集成边界。
| 集成问题 | 内容 |
|---|---|
| 最终性不匹配 | 现有系统将数据库提交视为最终结果；区块链需要确认深度 → 边界状态管理 |
| 缺少原子性 | 现有数据库事务和链上交易无法绑定为一个原子单元 |
| 吞吐量差距 | 现有系统快得多 → 区块链成为瓶颈；需要排队/批处理 |
| 可逆性差异 | 现有系统可以回滚，区块链不行 → 两边的故障场景设计不对称 |
| 时间同步 | 需要协调区块时间和现有系统时间 |
“缺少原子性”是实质影响最大的问题。如果数据库写入与提交链上交易之间发生故障，就会产生不一致。由于两者不能绑定到一个分布式事务中，需要采用 Saga 或 outbox 模式等最终一致性方法，并与上文的补偿交易流程衔接。
这是一个架构决策，因此应尽早在设计阶段处理。如果后期才补上，数据一致性问题会在生产环境中暴露。
切合实际的采用路径
| 阶段 | 内容 |
|---|---|
| 1. 验证问题 | 确认确实需要区块链。比较其他方案（普通数据库、签名日志、WORM） |
| 2. 确认参与机构 | 确定目标参与方及其角色；结合共享账本、验证和治理收益，与更简单的方案比较，不能假设机构数量有统一的最低要求 |
| 3. 达成治理协议 | 在技术选型前确定成员资格、决策方式、争议处理和退出流程 |
| 4. 设计隐私 | 与评审人员共同确定通道/PDC 结构 |
| 5. 确认法律/合规要求 | 删除请求、数据位置和审计要求 |
| 6. 概念验证（PoC） | 技术验证以及性能和运维负担测量 |
| 7. 试点 | 在有限范围内处理真实交易 |
| 8. 运维 | 节点运维、监控、证书续订、硬分叉/升级 |
这张表要强调的是，第 2 和第 3 阶段先于技术选型。如果没有参与机构或治理协议，即使技术验证成功也无法推进。实际上，许多金融服务区块链项目都停在了这个阶段。
总结
- 首先排除区块链不适用的情况。如果无法用一句话解释“为什么必须没有仲裁方”，就先比较替代方案。如果只需要篡改检测，签名日志或 WORM 就够了。
- 金融服务选择联盟链的决定性原因是KYC/AML 义务和数据主权。吞吐量和治理属于次要收益。
- 选择联盟链会削弱区块链原本的大部分价值。实质保留下来的价值是“降低机构间对账成本”；如此定义价值，在评审中有据可依。
- 根据实际数据模型选择隐私机制。历史密文副本可能在密钥轮换后仍然存在；应明确核实数据保留、私有数据清除和法律义务。
- 密钥管理必须在隔离性和签名可用性之间取得平衡。对于 PoS 验证者，未协调的签名者可能生成相互冲突且可罚没的消息；相同签名的重复副本并不自动导致罚没。应使用保留罚没历史的隔离故障切换，或经验证的协调式分布式签名设计。
- 评审中最常准备不足的是错误纠正（答案是补偿交易流程，不是技术）和退出策略（有数据保留义务，因此“我们关掉了”不是终点）。
- 与现有基础设施集成的核心难点是缺少原子性。应及早在设计中采用 Saga/outbox 等最终一致性方法。
- 在采用路径中，先确认参与机构并达成治理协议，再进行技术选型。
参考资料
- Hyperledger Fabric：私有数据
- Hyperledger Fabric：通道
- AWS CloudHSM 文档 / AWS KMS 文档
- AWS KMS 密钥规格参考：包括
ECC_SECG_P256K1 - 使用 AWS KMS 安全管理以太坊账户（AWS Web3 博客）
- 使用 AWS Nitro Enclaves 运行以太坊验证者（AWS Web3 博客）：BLS12-381 不受支持时的替代方案
- Amazon Managed Blockchain：停服风险及缓解措施
- 区块链基础知识：共识和最终性
- 在 EKS 上运行区块链节点：运维
- EKS 安全 / 安全：通用安全控制