金融服务视角测验
本测验检查你对联盟链选型、隐私、密钥管理和审查委员会议题的理解。
选择题
- 应采用什么标准判断某个问题是否需要区块链？
- A) 数据量是否足够大
- B) 能否用一句话说明“为什么这个问题不能由仲裁方处理”；如果做不到，应先比较其他方案
- C) 参与机构是否达到五家或以上
- D) 是否要求实时处理
显示答案
答案：B) 能否用一句话说明“为什么这个问题不能由仲裁方处理”；如果做不到，应先比较其他方案
说明：本章从“无需可信仲裁方也能达成一致”这一问题出发，比较区块链的成本与收益。如果数据由一家组织控制，或各方都信任某个仲裁方，应先考虑数据库/审计日志等替代方案，并比较实际的独立验证和治理要求。不能仅凭机构数量推断区块链普遍毫无价值。如果主要需求是发现篡改，带签名的追加式日志、哈希链或 WORM 存储可能以更简单的运维方式满足要求。
- 在声称某种网络选型符合金融合规要求之前，必须评估什么？
- A) 吞吐量和费用
- B) 针对实际业务活动和司法辖区，评估交易对手身份识别及数据所在地义务
- C) 治理和错误处理
- D) 开发便利性和招聘
显示答案
答案：B) 针对实际业务活动和司法辖区，评估交易对手身份识别及数据所在地义务
说明：公有系统和许可型系统可以采用不同控制措施。仅有联盟成员身份既不能证明符合 KYC/AML，也不能证明符合隐私要求；应进行适当的法律/合规评估。
- 选择联盟链后还剩下什么实质性价值？为什么审查时应这样定义？
- A) 抗审查性，这是监管机构也认可的价值
- B) 降低机构之间的对账成本，因为“去中心化、无需信任地运行”会被“那么谁控制成员资格？”这个问题推翻
- C) 无许可参与，因为这能保证可扩展性
- D) 无需仲裁方，因为不再有运营方
显示答案
答案：B) 降低机构之间的对账成本，因为“去中心化、无需信任地运行”会被“那么谁控制成员资格？”这个问题推翻
说明：采用联盟模式后，公有链的许多价值（抗审查、无许可参与、无需仲裁方）都会减少，因为有一方控制成员资格，而该方实际上就是仲裁方。剩下的实质价值是“让各机构看到相同的数据，从而消除对账工作”，这是确有价值的。若从一开始就这样定义价值，在审查中更站得住脚。
- 在区块链上存储加密数据有什么特殊风险？
- A) 加密会降低性能
- B) 历史密文副本可能持续存在；密钥一旦泄露，就可能暴露由该密钥加密的记录
- C) 加密数据不参与共识
- D) 加密密钥也会一并存储在链上
显示答案
答案：B) 历史密文副本可能持续存在；密钥一旦泄露，就可能暴露由该密钥加密的记录
说明：重新加密新记录并不会删除旧副本。许可型系统中的私有数据清除有不同语义；验证保留策略、密钥生命周期和法律要求，而不要声称每条链的删除行为都相同。
- PoS 验证者的密钥管理在哪方面与一般 HA 经验相冲突？
- A) 必须将密钥复制到多个区域
- B) 未经协调的签名器可能为同一个验证者产生彼此冲突、会导致罚没的消息
- C) HSM 不支持多个实例
- D) 密钥轮换必须停机
显示答案
答案：B) 未经协调的签名器可能为同一个验证者产生彼此冲突、会导致罚没的消息
说明：应使用隔离保护并保留防止罚没的历史记录。分布式签名器需要经过验证的协调机制；重复相同的签名并不自动等同于会导致罚没的冲突。
- 对于“如何撤销错误交易”这一审查问题，应如何回答？
- A) 提出回滚区块链的技术流程
- B) 这是流程问题而非技术问题：保留原交易，再提交补偿交易来纠正结果，如同会计中的冲销分录
- C) 由联盟运营方删除区块
- D) 说明不可变性是优点，因此无需撤销任何内容
显示答案
答案：B) 这是流程问题而非技术问题：保留原交易，再提交补偿交易来纠正结果，如同会计中的冲销分录
说明：金融运维中，作为区块链优点宣传的不可变性也会成为问题。错误交易、误转账和系统错误都可能发生，机构有责任和流程去纠正。答案是提交补偿交易，而不是“回滚区块链”；审查时需要记录该流程及其审批权限。这也与区块链和现有基础设施集成时无法实现原子性相关（Saga/outbox 模式）。
- 金融服务审查中，哪两项最常准备不足？
- A) 性能测量和成本估算
- B) 错误纠正流程和退出策略
- C) 网络配置和防火墙策略
- D) 开发人员配置和培训计划
显示答案
答案：B) 错误纠正流程和退出策略
说明：在错误纠正方面，声称“无法撤销”会成为审查中的弱点；应准备补偿交易这一流程，而不是寄希望于技术方案。退出策略几乎从未准备：联盟解散、成员退出或系统关闭时，金融数据仍有保留义务，因此“我们关闭了区块链”并不意味着工作结束。账本导出格式、保留责任方、退出成员的数据处理方式和记录访问方式都必须写入联盟协议，并由技术设计提供支持。
- 与现有金融基础设施集成时，最实质的困难是什么？应如何应对？
- A) 吞吐量差距：通过增加链节点解决
- B) 缺乏原子性：现有数据库事务与链上交易无法绑定为一个原子单元，因此必须尽早在设计中采用 Saga/outbox 等最终一致性方案
- C) 时间同步：通过配置 NTP 解决
- D) 协议差异：通过网关转换解决
显示答案
答案：B) 缺乏原子性：现有数据库事务与链上交易无法绑定为一个原子单元，因此必须尽早在设计中采用 Saga/outbox 等最终一致性方案
说明：数据库写入和链上交易提交之间若发生故障，就会造成不一致；二者无法绑定在分布式事务中。需要采用 Saga 或 outbox 模式，并与补偿交易流程衔接。这属于架构决策，必须在设计早期解决；如果事后补上，数据一致性问题就会在生产环境暴露。增加完整节点副本不会自动提高基础链的写入/共识能力，虽然能提升 RPC/读请求的总容量和可用性。
- 在现实的采用路径中，技术验证之前必须完成哪一步？
- A) PoC 和试点
- B) 就参与方角色、治理，以及相较于更简单替代方案的可衡量收益达成一致
- C) 基础设施容量规划和成本估算
- D) 构建监控栈
显示答案
答案：B) 就参与方角色、治理，以及相较于更简单替代方案的可衡量收益达成一致
说明：不要声称某种机构安排普遍毫无价值或自动符合合规要求。审查关注的是明确的要求、信任假设和运维职责。