统一账本模型深度解析——功能、边界与实现难点

统一账本被频繁提及，但大多数讨论停在"原子结算"和"可编程"这几个词上。上篇文章就“统一账本”作了简要表述，为方便理解，本文将模型拆开讲清楚：它究竟能做什么、和现有体系有什么本质区别、真正难在哪里。

一、统一账本解决的是哪类问题

在进入功能细节之前，先厘清问题背景。

当前的全球支付基础设施，本质上是一张异步的消息网络。一笔跨境汇款的完成，不是因为钱在某个时刻"真正移动了"，而是因为一系列机构之间交换了足够多的消息，各自更新了各自的账本，最终通过人工或系统对账确认双方的记录一致。

这套体系在设计时面对的约束是：

• 没有全球统一的可信基础设施
• 各国货币由各国央行独立管辖
• 参与方彼此不信任，需要通过代理行关系建立间接连接
• 结算最终性（finality）的法律认定因国而异

BIS 统一账本模型的核心假设是：如果我们今天从零设计，会做一套根本不同的东西。它不是给现有系统打补丁，而是在新的技术条件下重新回答"货币结算的基础设施应该长什么样"这个问题。

---

二、统一账本的核心功能

2.1 原子结算

这是统一账本最根本的能力，也是与现有体系差异最大的地方。

原子性 (atomicity) 来自数据库理论：一组操作要么全部成功，要么全部回滚，不存在中间状态。在支付场景里，这意味着：

• 买家付款 → 卖家收款 → 资产过户，三个操作绑定在同一个事务里
• 任何一步失败，整个事务回滚，不会出现"钱出去了但资产没到"或"资产交割了但款项悬空"的情况
• 不需要托管账户、不需要第三方担保、不需要事后对账

对跨境支付而言，原子结算直接消灭了最主要的风险来源：赫斯塔特风险（Herstatt risk）——以 1974 年德国赫斯塔特银行倒闭时大量外汇结算悬空而得名，指在时区不同的两腿结算中，一腿已交割但另一腿尚未完成时对手方倒闭的风险。

2.2 可编程货币

可编程性意味着货币可以携带条件逻辑。传统支付只能指定"从 A 账户转 X 元到 B 账户"，而可编程货币可以表达更复杂的语义：

传统支付	可编程货币等价
转账后手动触发后续操作	收款确认后自动触发下游合约
到期日前人工划拨担保金	价格触及阈值时自动追加保证金
贷款发放与用途核查分离	贷款资金仅能支付符合条件的特定对象
利息手工计算、定期划拨	按秒累计、实时结算

这不只是自动化，而是把业务逻辑嵌进货币本身。现有的智能合约平台（以太坊等）虽然也能做到，但运行在没有主权背书的代币上；统一账本的可编程货币背后是央行储备，这是本质区别。

2.3 并行合规执行

现有跨境支付体系中，合规检查（AML 反洗钱、制裁筛查、KYC）是串行的：每一跳都要重新验一遍，因为下一个节点不信任上一个节点的结论。

统一账本的设计目标是把合规执行变成并行且一次性的：

• 身份验证结果附着在代币化资产或账户上，随转移传递
• 制裁筛查在支付发起时完成，不在每个中间节点重复
• 合规规则编码在共享账本的访问控制层，由平台统一执行

这不仅是速度问题——并行合规的更大价值是可审计性。每一笔交易的合规状态都记录在链上，监管机构可以实时查看，而不是等机构定期报告。

2.4 抵押品实时管理

这是一个在零售用户视角下不可见、但对金融市场影响巨大的功能。

当前，金融机构管理抵押品（如国债）面临严重的碎片化和时间错配：抵押品锁定在某个交易对手关系里，无法在不同资金池之间灵活调动；日内流动性不足时往往需要借用过夜资金。全球主要市场每天因抵押品调拨低效产生的隐性成本估计在数百亿美元规模。

统一账本把代币化国债和央行储备放在同一平台上，使得：

• 日内抵押品实时调拨：一笔交易的保证金可以在完成的瞬间释放，立即用于另一笔交易
• 跨境抵押品优化：A 国机构在 B 国市场的头寸可以用 A 国国债做抵押，无需把资金转到 B 国
• 动态保证金：市场波动时自动追加或释放，不需要人工操作

BIS 估算，仅跨境抵押品优化一项，就可以为全球金融市场释放数万亿美元的被锁定流动性。

2.5 货币政策的新传导机制

这是一个更长期的功能维度，目前处于实验阶段（Project Pine）。

可编程央行储备理论上可以承载更精细的货币政策工具：

• 定向流动性注入：央行可以把流动性精确导向特定行业或资产类别，而不是通过利率调整漫灌
• 负利率精确执行：当前负利率政策在实践中因现金持有成本低廉而效果有限；数字储备可以通过编程确保利率策略被真正执行
• 宏观审慎工具嵌入：把贷款上限、集中度限制等宏观审慎规则直接编码进货币流转逻辑

但这同时带来了政治敏感性：央行的权力边界在哪里？这些工具在威权政治场景下会被如何使用？这些问题超出了技术范畴。

---

三、与现代支付体系的本质区别

3.1 消息传递 vs. 状态变更

这是理解两种体系根本差异的关键概念。

现有体系（SWIFT + RTGS）的本质：

SWIFT 是一个加密消息网络，它传递的是支付指令，而不是货币本身。一条 SWIFT 报文的意思是"我（A 银行）指令你（B 银行）从你在我行的账户里扣款，同时通知 C 银行做相应记录"。

资金的"移动"发生在各国央行的实时全额结算系统（RTGS）里——美国的 Fedwire、欧元区的 TARGET2、英国的 CHAPS——每个系统只处理本币，跨境支付需要在不同 RTGS 之间协调，通过代理行关系传递。

整个过程是：消息触发账本更新，账本更新触发下一条消息，直到所有相关账本都更新完毕。

统一账本的本质：

统一账本里的货币是状态，不是消息。转账操作是一个状态转换函数：账本状态从（A 持有 X，B 持有 Y）变为（A 持有 X-n，B 持有 Y+n）。这个状态变更是原子的、即时的、不可逆的。

不存在"消息在传递中"的中间状态，不存在"已发出但未确认"的悬空付款。

3.2 串行 vs. 并行处理

现有跨境支付流程是天然串行的：

每一跳都是同步等待：合规审查不过，下一步不启动。这解释了为什么一笔跨境汇款需要 2-5 个工作日——这不全是技术限制，而是流程设计的必然结果。

统一账本把合规检查前置并并行化：

从架构上看，这是把"n 跳串行处理"压缩为"1 次并行预检 + 1 次原子结算"。

3.3 信任模型的根本差异

现有体系的信任建立在双边关系和法律合约上：代理行关系、往来账户、协议条款。每个参与方信任的是对手方而不是系统本身。

统一账本的信任建立在共享技术基础设施上：规则编码在平台里，所有参与方都执行同一套逻辑，不需要双边协议，也不需要信任对手方，只需要信任平台本身及其治理机构。

这一转变的意义是：把信任从"我信任你"转变为"我们都信任这套规则"。这在全球多主权环境下是一个巨大的治理挑战，但一旦建立，理论上可以把参与方数量从有限扩展到无限。

3.4 结算终局性的不同定义

在 SWIFT+RTGS 体系下，"最终结算"是一个法律概念，各国定义不同。欧盟有《结算终局性指令》（SFD），美国有《联邦电汇法规》（Regulation J），各国法律对何时结算不可撤销的判定时点不同。

跨境支付的结算终局性问题因此极为复杂：A 国法律认定已完成，B 国法律认定尚未生效，这在破产场景下会引发严重的法律纠纷。

统一账本试图提供一个技术上的结算终局性定义：原子事务完成的时刻，就是各方共识认可的结算时点。然后再通过国际条约和法律修订让各国法律认可这个技术定义。这反转了传统路径——从"技术配合法律"变为"法律承认技术"。

---

四、实现难度：三重障碍

4.1 主权障碍：谁控制什么

这是最深层的挑战，也是 Project Agorá 设计双层架构的根本原因。

核心矛盾：统一账本的价值来自"统一"——参与方越多、资产类别越全，网络效应越大。但"统一"意味着要在某个共享平台上运行跨境结算逻辑，这触碰到央行最敏感的神经：谁运行这个平台？谁可以看到我的储备数据？谁可以暂停或回滚交易？

没有一家央行愿意接受由另一家央行、商业机构或 BIS 本身来控制本国货币储备。

Agorá 的解法是双层隔离：

• 共享的统一账本只处理商业银行层面的代币化存款
• 每个货币区的央行储备运行在独立的司法管辖账本上，只有本国央行有控制权
• 统一账本可以"请求"司法管辖账本执行某个操作，但不能直接写入

这解决了主权问题，但也引入了新的复杂性：两层账本的同步和状态一致性如何保证？"请求-执行"模式如何实现原子性？

理论上的解决方案是HTLC（哈希时间锁合约）：跨账本事务通过密码学锁保证"要么都执行、要么都回滚"，但在实际的多司法管辖、多时区、多机构场景下，HTLC 的活锁问题和超时处理是真实的工程挑战。

4.2 法律障碍：框架不匹配

技术实现只是故事的一部分，法律框架的重构难度不亚于技术。

挑战一：代币化资产的法律地位

代币化国债是"真的"国债吗？代币化存款是"真的"银行存款吗？当前大多数国家的法律框架没有明确答案。如果代币化资产持有方的权利在破产场景下不受法律保护，机构不会真正采用它。

挑战二：跨境结算的法律认可

即使技术上实现了原子结算，各国法律需要明确认可这个技术时刻作为法律意义上的结算终局。这需要修改或新增相关法律，而不同法律传统（普通法 vs. 大陆法）的协调本身就是一个多年工程。

挑战三：数据本地化与监管访问

欧盟 GDPR、中国数据安全法等要求某些数据不得离境存储。但共享账本的运行需要各参与方能够访问相关交易数据。如何在满足数据主权要求的同时维护账本的共享性，是一个尚无标准答案的问题。

挑战四：隐私保护与监管需求的平衡

监管机构需要能够查看交易数据以执行反洗钱和制裁规则。但参与方（尤其是商业机构）希望交易信息对竞争对手保密。零知识证明（ZKP）是理论上的解决方案——可以证明"这笔交易满足合规要求"而不暴露交易细节——但在大规模、高并发场景下的性能和实用性仍在验证中。

4.3 技术障碍：规模与可靠性

吞吐量

全球外汇市场日均交易量约 7.5 万亿美元，SWIFT 每天处理约 5000 万条报文。任何替代性基础设施必须能够在峰值压力下保持稳定——而且要比现有系统更稳定，因为它将成为全球金融系统的核心基础设施。

当前公链（以太坊主网约每秒 15-30 笔）显然不够。联盟链或许可链理论上可以达到所需吞吐量，但实际上还没有任何系统在类似规模下经过实战验证。

时区与可用性

全球金融市场几乎 24 小时运转，统一账本必须做到接近零停机时间。传统金融基础设施（如 Fedwire）有明确的维护窗口，但在全球化场景下，任何计划内停机都会在某个时区造成业务中断。

系统升级如何进行？谁可以推送代码变更？热升级（不停机更新）对智能合约平台是极高的技术挑战。

互操作性

统一账本不太可能是"一个"系统，而是多个系统的组合。欧元体系、英镑体系、日元体系将各自运行基础设施，再通过标准接口互联。这些接口的设计和标准化需要多年国际协调，类似于 ISO 20022 报文标准的推广历程。

密钥管理与灾难恢复

在代币化货币体系中，私钥丢失意味着资产永久锁定。央行和大型金融机构的密钥管理需要达到军事级别的安全标准，同时还要保证可操作性（有权限的人能在需要时快速访问）。这是安全与可用性之间永恒的张力。

---

五、实现路径：阶段与优先级

基于 Project Agorá 的经验，可以勾勒出一条相对务实的实现路径：

第一阶段（当前）：原型验证

• 在受控环境下测试核心技术假设
• 验证原子结算、双层架构、合规并行执行的可行性
• 识别关键法律和技术障碍
• Agorá 原型机在 2026 年 5 月完成了这个阶段

第二阶段（1-3 年）：真实价值试点

• 少数货币对、少量机构、受限规模的真实资金测试
• 建立跨司法管辖的法律框架原型
• 开发和测试密钥管理、灾难恢复方案
• 与 ISO 20022 等现有标准的互操作性测试

第三阶段（3-7 年）：有限运营部署

• 特定资产类别（如 G10 货币外汇结算）的生产部署
• 逐步扩展参与机构和货币种类
• 建立治理机构和运营规范

第四阶段（7 年以上）：系统性基础设施

• 成为与 SWIFT/RTGS 并存甚至部分替代的基础设施
• 与零售 CBDC 系统对接
• 完整的跨境抵押品管理生态

关键路径上的不可绕过项：

1. 至少两个主要货币区（如欧元+美元）的法律框架对齐
2. 有真正法律约束力的治理协议（不是谅解备忘录）
3. 通过压力测试的技术平台
4. 达到现有系统可靠性水平（99.99%+）

---

六、最容易被忽视的难点

很多分析聚焦在技术层，但统一账本最难的部分其实在治理。

一旦进入生产，谁来决定：

• 系统出现 bug 时，谁有权紧急暂停？
• 某个国家因违反制裁被踢出系统，谁来做这个决定？
• 系统升级需要哪个比例的参与方同意？
• 某笔交易引发争议，仲裁机制是什么？

这些问题没有技术答案，只有政治答案。而在一个主权国家参与的体系里，政治答案必须通过条约、协议和长期谈判来达成。

这可能是整个项目最长的关键路径——不是因为答案不存在，而是因为在主权林立的国际体系里，各方利益协调本身就需要十年量级的时间。

---

小结

统一账本模型在技术层面的逻辑是清晰且自洽的：原子结算消灭结算风险、可编程货币降低交易摩擦、并行合规提升效率、共享基础设施压缩信任成本。

与现有体系的区别不只是"更快的 SWIFT"，而是一次从消息网络到状态机、从双边信任到规则信任、从串行处理到原子事务的架构级重构。

但实现路径上的三重障碍——主权、法律、技术——各自都是真实且艰难的。Project Agorá 原型机证明了技术可行性，但可行性和可部署性之间的距离，取决于参与国的政治意愿和国际协调能力。

这是一个需要用"十年"而不是"季度"来衡量的工程。但它所对准的问题——让全球货币体系的运作效率匹配 21 世纪的数字经济——足够重要，值得这个量级的投入。

---

延伸阅读

• 统一账本：货币体系的下一次进化 — 本站关于 BIS 统一账本蓝图和 Project Agorá 原型机的综述
• BIS Working Paper No. 1178: Tokenisation in the context of money and other assets
• BIS Annual Economic Report 2023, Chapter III: Making the monetary system work better: the promise of unified ledger
• Project Agorá Technical Report, May 2026
• BIS Working Paper: HTLC and the design of cross-ledger settlement protocols