朱康辛Zane Zhu

← 全部文章

什么时候真的需要区块链？从 mBridge 看分布式账本的适用边界

区块链mBridge央行数字货币跨境支付数字化战略

经常有人问我：mBridge 能不能用传统数据库实现？

技术上的答案是：大部分功能可以。但正是“为什么它仍然选择了区块链”这个问题，最能说明区块链的真正价值在哪里，以及它为什么在绝大多数场景里并不必要。

一、mBridge 是什么

mBridge（多边央行数字货币桥）是一个由多国央行共同参与的跨境支付平台，让各国央行数字货币可以在同一个平台上实时、点对点地完成跨境支付和外汇兑换。

  • 起源：2021 年，由国际清算银行（BIS）创新中心香港中心、香港金管局、泰国央行、阿联酋央行和中国人民银行数字货币研究所共同启动，前身是香港与泰国合作的 Inthanon-LionRock 项目。
  • 进展：2022 年完成涉及真实价值交易的试点；2024 年年中进入最小可行产品（MVP）阶段。
  • BIS 退出：2024 年 10 月，BIS 宣布将项目移交给参与央行继续推进。时任总经理卡斯滕斯表示，退出并非出于政治考虑。
  • 成员变化：沙特央行 2024 年成为正式成员，2025 年 5 月完成概念验证后不再作为参与成员；澳门金管局 2026 年加入，6 月为 11 家本地银行开通交易。目前核心成员为中国内地、香港、泰国、阿联酋和澳门。
  • 规模：据报道，截至 2026 年 1 月，平台累计处理超过 4,000 笔交易，总额约 560 亿美元，其中大部分为数字人民币。

技术上，mBridge 运行在专门设计的许可链 mBridge Ledger 上，兼容以太坊虚拟机（EVM）。每个创始央行运行自己的验证节点，节点部署在各参与方境内、由各自管理；代码对所有参与方可见、可审计、可测试；交易由多方央行基于智能合约规则分布式验证，确保唯一、真实、终局。

二、大部分功能，传统数据库就能做

mBridge 的核心业务逻辑并不复杂：各国央行在平台上发行和销毁自己的数字货币，执行款款对付（PvP）的原子兑换，再加上合规审查。这些用传统分布式数据库完全可以实现：

  • 每个央行的货币余额就是一张表，发行和销毁是受控的写操作；
  • PvP 原子兑换要求“两条腿”同时成功或同时回滚，这正是关系型数据库事务（ACID）的基本能力，不需要智能合约；
  • 权限管理、审计日志，传统技术栈早已成熟。

如果 mBridge 只是一国央行的内部系统，或者参与各方已经完全互信、只关心系统稳定，传统数据库足够了，根本不需要区块链。

三、数据库给不了的：一个政治解决方案

现实是，mBridge 的参与者是多个互不隶属、彼此保持警惕的主权国家。它选择许可链，买的不是“记账功能”，而是“不把账本控制权交给任何单一参与方，同时还能互相验证对方没有作弊”。具体有四点：

1. “谁来运营中心数据库”在主权国家之间无解。 传统方案必须有一方，或一个中立的联合运营机构，持有主数据库、拥有最终写入权。没有哪个央行愿意把本国货币的余额记录托管在别国控制的服务器上，哪怕对方承诺绝不作恶。这不是技术信任问题，而是政治信任问题。mBridge 让每个央行的节点在物理上、法律上都位于本国境内，从架构上绕开了“由谁托管”这个问题。

2. 规则可以被每一方独立验证。 代码对所有参与方公开，任何一个央行都能自己确认平台执行的规则与约定完全一致、没有被悄悄修改。在中心化数据库里，业务逻辑跑在别人的服务器上，你只能选择相信。

3. 隐私与合规可以兼得。 据报道，mBridge 计划引入零知识证明（ZKP），在不披露账户余额、交易时间等敏感信息的前提下，证明一笔交易合规、资金充足。中心化方案的通常做法是运营方看到全部数据、其他人相信运营方的判断，这又回到了信任单一方的老问题。

4. 防的是“节点说谎”，不只是“节点宕机”。 传统主从复制数据库的容错设计处理的是崩溃故障；多方独立验证则是拜占庭容错：即使某个节点试图造假，其他节点的验证也会拒绝这笔交易。

反过来说，传统数据库要提供同样的保证，就必须演变成“每方各持一份、相互验证、代码公开可审计”的形态，而那本质上已经是一条许可链了。

四、另一条路：欧元模式

还有一种彻底的解法：参与国共同成立一个超国家机构，统一运营中心化系统。那样完全可以用数据库实现，政治带来的复杂性也随之消失。欧洲各国经过数十年协商建立欧盟和欧元，正是这条路；欧元区的跨境大额支付至今由欧洲央行体系统一运营的中心化系统完成。

这对人民币国际化也有启发：解决政治信任问题，未必只有提高人民币市场份额一条路，也可以考虑类似欧元的区域合作模式。当然，这是一条更长、更不确定的建立信任之路。

五、更普遍的判断：四个必要条件

把 mBridge 的逻辑推广开，一个业务真正需要区块链，必须同时满足四个条件，缺一不可：

  1. 存在两个或以上相互独立、互不信任的主体；
  2. 各方都需要保留同一份历史记录，且任何一方都不能单方面篡改或抹除；
  3. 不存在天然、公认的权威中心（如果有，直接信任这个中心加审计日志就够了）；
  4. 业务收益大于分布式治理、运维、审计和合约安全带来的额外成本与新增风险。

拿常见场景对照一下：

  • 跨部门政务共享：通常有主管单位作为权威中心，不满足第 3 条。
  • 企业供应链溯源：很多场景只有生产商单方填报，缺少独立第三方核验，不满足第 2 条，源头造假问题解决不了。
  • 知识产权存证：公证处本身就是可信权威，中心化时间戳存证就能做到，区块链只是可选的增强手段。

这里要分清两个概念：“可使用”不等于“必须使用”。大量示范项目属于“可以上链、上链也能跑”；而“不用区块链就无法实现业务目标”的场景，现实中极少。绝大多数情况下，“中心化存储 + 文件哈希 + 权威时间戳 + 审计日志”就能低成本实现同样效果，而且攻击面更小、审计手段更成熟。

mBridge 恰恰是少数四个条件同时成立的案例：多个主权国家、需要共同账本、没有超国家权威、跨境结算的收益足以覆盖治理成本。

六、公共区块链基础设施：价值与风险

既然刚需场景这么少，为什么“十五五”规划仍然提出建设区块链基础设施？更现实的理由有四类：

  1. 战略储备：跨境多方协作（如境内外机构之间）缺少共同上级，很难建立单一权威中心。这类场景现在体量小，但值得提前布局。
  2. 降低多方对接成本：统一协议和存证接口，避免每两家机构单独开发一套对接、验签和时间戳。不过这是标准化的价值，中心化网关理论上也能提供。
  3. 积累工程能力：多方密钥管理、跨机构身份、隐私计算等能力，可以迁移到数据要素流通等领域。
  4. 产业与示范目标：部分项目的驱动力是产业扶持和示范工程，也就是常说的“为链而链”。

真正需要警惕的是落地方式。如果整套基础设施由一家公司总包承建，而甲方没有独立的技术能力和多方分权治理机制，名义上的分布式可信系统，实质上会变成承建商掌控的“伪联盟链”：

  • 私钥和共识配置在承建商手里：名义上的多方节点实际都跑在承建商的云上，承建商可以悄悄调整共识阈值、增加受控节点。
  • 入口和出口都由承建商控制：上链网关可以在数据上链前替换内容；链浏览器是审计和监管查看数据的唯一窗口，修改其后端就能对外展示假记录，而链上账本本身完全不动。
  • 审计容易流于形式：开发和审计由同一方或关联方完成，甲方无力独立复核。
  • 概念掩盖风险：人们默认“区块链 = 不可篡改”，对承建商的监督反而比对传统系统的 DBA 更松。

传统外包数据库至少有一点好处：数据库实例和审计日志通常归甲方所有，甲方可以独立部署堡垒机和日志审计。总包托管式区块链的风险性质变了：出事的概率未必更高，但出事之后更难发现、更难取证、责任更难界定，甚至可能被“区块链不可篡改”的说法掩盖。

七、三个检验问题和一份清单

判断一套区块链基础设施有没有踩坑，可以问三个问题：

  1. 共识节点的私钥，是否由不同参与机构分别保管，承建商拿不到？
  2. 协议是否完整公开，监管和第三方能否独立部署全节点核验数据，而不依赖承建商的浏览器？
  3. 原始业务数据是否留在业务部门自己的系统里？

任何一个答案为“否”，单一承建商的隐蔽风险就会显著上升。

适合放上公共区块链基础设施 不适合
跨机构电子证据存证（合同、文书、知识产权） 单一主体的内部业务（OA、人事、ERP）
跨部门资质、证照的验真与状态变更记录 高频、高吞吐的实时交易核心库
有多方独立记录的供应链流转（不能解决源头造假） 规则频繁变化的核心业务主库
公益资金、补贴拨付审批事件的审计存证 原始敏感个人数据（多副本、难删除）
物联网设备事件日志的防篡改校验 只有单一采集源、无交叉核验的“溯源”

适合的场景有一个共性：链只是“可信历史存证层”，只存哈希、时间戳和事件记录，原始数据和业务逻辑都留在各方自己的系统里，智能合约尽量简单。

结语

区块链不是万能工具，而是一种代价高、带有额外风险的多方可信协作工具，适用面天生很窄。mBridge 之所以需要它，不是因为技术上非它不可，而是因为参与者之间缺少一个大家都愿意信任的中心。

判断一个项目要不要上链，最该问的不是“技术能不能实现”，而是：有没有一个各方都愿意信任的中心？如果有，用数据库；如果没有，再看四个条件是否都成立。

参考资料