Rosalind项目——为零售CBDC生态系统创新构建API原型

近日，国际清算银行（BIS）发布《Rosalind项目——为零售CBDC生态系统创新构建API原型》（Project Rosalind——Building API prototypes for retail CBDC ecosysteminnovation），对Rosalind项目进行介绍。Rosalind项目是一项探索零售央行数字货币（CBDC）应用程序编程接口（API）的实验。

1 引言

1.1 全球格局

各国央行正在加速对零售CBDC的探索。他们正试图了解CBDC如何支持更加数字化的经济，并在数字时代提高零售央行货币的可用性和效用，同时保持对货币和金融体系的信心和信任。

这些央行的探索得到了来自公共和私营部门的众多举措和项目的支持，涵盖了广泛的主题，如弹性、网络安全、离线支付、隐私保护和分类账设计。当局还在考虑对CBDC的运营、法律和监管框架的影响。

基于从批发CBDC项目中获得的知识，国际清算银行（BIS）创新中心现在正在带头进行与零售CBDC相关的几项技术实验。实验涵盖CBDC架构模型、网络安全、弹性、线下支付、隐私和跨境支付。

1.2 双层CBDC模型和API的使用

零售CBDC模式已经出现了两种选择：由中央银行运营的单层系统，以及中央银行提供核心基础设施的双层模式，由私营部门服务提供商提供面向用户的服务。两级模式的主要特征之一是需要明确定义且运作良好的公私伙伴关系。

双层零售CBDC系统有一系列可能的设计，私营和公共部门参与者之间有各种类型的互动，公共和私营部门基础设施之间的边界也不同。

Rosalind项目基于双层模型，它将使个人和企业能够管理其在中央银行持有并记录在中央银行分类账上的CBDC余额，并通过其私营部门服务提供商进行支付。这些提供商，包括支付接口提供商 （PIP） 和生态系统服务接口提供商 （ESIP），可能是银行、金融机构或非金融机构，前提是他们具有提供此类服务的适当监管地位和许可。所有交易都将在中央银行分类账上实时、一对一地结算，不与其他交易捆绑或净额结算，并且具有最终性。

该模型需要一个API层，该层将有助于将指令从服务提供商传递到中央银行分类账，并协调启动、验证、批准和完成付款的活动。API是一组定义的规则和协议，用于允许应用程序和系统相互通信。API可以充当不同系统之间的接口，以便处理执行特定任务或访问特定数据的请求。它们可以改善支付系统之间的功能和互操作性，同时抽象出各个系统的内部工作原理。

在过去的十年中，API的使用在支持创新和促进新产品和服务的开发方面越来越突出。英国的Open Banking方案就是这样一个例子。API也可以在跨境支付中发挥重要作用。

在G20路径图中，协调API协议进行数据交换的必要性被确定为加强跨境支付的基石之一。国际清算银行的CPMI在2022年向G20提交的报告还讨论了在支付系统中采用API的好处，并强调了API标准化的必要性。

2 Rosalind项目

2.1 项目宗旨和目标

Rosalind项目的目的是探索如何使用API来支持CBDC系统的功能、采用和创新，方法是在双层零售CBDC模型中为API层开发原型。该项目有以下目标：

1. 功能——探索API如何最好地使中央银行分类账与私营部门服务提供商互动，包括促进安全可靠的零售CBDC交易的不同选择；

2. 互操作性——探索如何实现不同系统和应用程序之间的互操作性，包括寻求对提供互操作性所涉及的不同设计选择、风险、机会和权衡的见解；

3. 采用——探索开发多样化和创新的CBDC用例所需的API功能；

4. 生态系统——深入了解公共和私营部门参与者如何共同努力进行创新、支持数字包容性、提供多样化的支付选项并提供良好的消费者成果。

图1 项目目标与双层CBDC模型的关联

2.2 协作方法

该项目是通过公共和私营部门的合作完成的。

在设计思维原则和方法论的指导下，该项目为生态系统参与创造了多个渠道，以及测试新想法和选择的空间。该项目分为两个阶段，以允许不同程度的生态系统参与。

第一阶段的重点是设计和开发API原型，并与开发人员（API用户组）和行业专家（顾问组）一起测试其功能。

第二阶段通过更广泛地参与生态系统来探索更多用例。2023年3月，Rosalind TechSprint推出，23个团队参与并展示了各种CBDC用例。2023年4月，选定的团队在演示日活动中向一组中央银行展示了他们的解决方案。

这种协作方法有助于确保API层原型的设计和构建考虑到了潜在的用户需求。在项目期间，Rosalind API使协作者能够为30多个潜在用例构建解决方案原型。

图2 两个阶段的结构和协作渠道

3 技术设计与构建

3.1 双层模型的项目体系结构

Rosalind架构由四层组成：中央银行分类账，分类账API，核心API和服务提供商。该项目的重点是核心API层，因为该层连接了公共和私营部门的基础设施。它在支持功能、实现互操作性和促进用例发现方面发挥了关键作用。有关这四层的详细信息如下。

中央银行分类账层：该层模拟中央银行分类账。模拟了基于账户和代币的账本，以测试核心API层是否可以简化和抽象出账本结构的差异。

基于账户的账本使用基于以太坊的Hyperledger Besu和代理合约模型来实现智能合约的可升级性。它包括数据存储和一系列实现该功能的智能合约。基于代币的账本使用了Hyperledger Fabric区块链，并实施了智能合约来模仿未花费的交易输出（UTXO）模型。

账本API层：该层将智能合约转换为API调用，并将API请求转换为中央银行分类账可以理解且可操作的格式。该项目使用Overledger技术加速了多个中央银行分类账模拟的开发，以便进行比较。它还使项目团队能够探索API如何与不同类型的中央银行分类账一起工作。

核心API层：该层是项目的重点，因为它通过项目期间开发的API端点编排消息和活动。它支持服务提供商之间的端到端加密，因此不会将个人身份信息（PII）传递给中央银行。所有 API 均符合金融级API（FAPI）标准和传输层安全（TLS）身份验证，以实现安全通信。这一层还包括Rosalind沙盒。沙盒是一个开发人员门户和技术文档的中央存储库，以支持私营部门的创新。在项目期间，沙盒提供了支持API用户和TechSprint参与者的环境。

服务提供商层：与核心API层交互，该层包括由API用户和TechSprint参与者开发和测试的前端CBDC用例。

图3 双层模型的项目体系结构

3.2 假设和设计决策

为了对双层模型的API进行原型设计，我们做出了以下假设和设计决策：

1. CBDC是对发行中央银行的直接债权。服务提供商不会发行自己的责任，也不会承担任何托管、仓储或发行“合成”CBDC。

2. CBDC将无偿、可以一对一地转换为商业银行货币。

3. 每个用户帐户中持有的或每笔支付交易中允许的CBDC数量没有限制，整个CBDC系统的总发行水平也没有限制。

4. 个人和企业的钱包将由PIP提供。这些临时处理人员将负责遵守相关的反洗钱和反恐融资要求。PIP还需要保留其用户交易历史记录的记录，因为Rosalind API不会提供这种记录。

5. 所有交易都将在中央银行分类账上实时、一对一地结算，不与其他交易捆绑或净额结算。

6. PII 和交易信息对 API 或中央银行分类账不可见。此信息将存储在 PIP 级别，并在通过 API 层时进行加密。

3.3 API设计原则与评估

在项目期间探索了一些API设计原则，下面详细介绍了项目针对这些原则采取的方法的评估。

表1 API 设计原则和评估

3.4 接口功能

对于核心API层，项目团队开发了六个功能类别的33个API端点。下面提供了这些类别的简短说明。在项目期间，进行了541865次API调用、7652次通知和1595次错误、发送和记录。该项目还实施了小数点后四位的CBDC，以实现小额支付。

账户管理（11个API）：使个人和企业能够管理他们的CBDC账户，例如开设新账户、禁用现有账户和检查账户余额。如果任何CBDC访问设备（例如电话或智能卡）丢失，用户可以通过暂时冻结他/她的CBDC帐户来请求停止付款。用户仍然可以接收付款。帐户管理API还包括别名。使用别名可以提高与现有支付基础设施的互操作性，支持隐私并增强用户对其个人数据的控制。

付款（6个 API）：启用付款人向一个或多个收款人发起的推送付款。为了确保向付款人提供对其付款交易的完全控制权，不支持拉取付款。相反，Rosalind API支持付款请求（RTP）和经过身份验证的付款请求（ARTP）。

RTP要求收款人向付款人发出付款请求，付款人必须通过其PIP进行交互来专门批准该请求，然后才能进行推送付款。

ARTP包含一个身份验证有效负载，以便收款人可以通过收款人的PIP将他或她的付款请求与有效负载一起发送到付款人的PIP进行验证。这使得请求可以自动获得批准并触发推送付款。ARTP可以支持第三方支付启动，例如ESIP。它还可以支持销售点（POS）交易，其中收款人有时有互联网连接，但付款人没有。

可编程性（10 个 API）：为了提供一组基本的可编程功能，该项目开发了三种类型的锁定机制，即两方锁、三方锁和哈希时间锁合约（HTLC）锁。两方锁允许收款人指定要保留的金额，直到满足一组条件才能进行付款。条件将事先与付款人商定。收件人的PIP将负责确定是否满足条件。此锁假定两个交易方之间存在高度信任，并且可能不适用于所有用例。因此，该项目增加了一个三方锁，引入了一个受信任的第三方，该第三方确定何时应触发付款。HTLC锁将支持原子交换，并有可能与其他系统集成。所有锁都有到期日期和时间，以确保没有CBDC无限期锁定。

参与者（2个 API）：使服务提供商能够获取彼此的公钥以进行点对点加密，并在发送和接收API调用后拉取通知。

ESIP（2个API）：这组API使个人和企业能够将其CBDC帐户与第三方应用程序“连接”和“断开连接”。这可以支持许多用例，例如第三方支付启动，外部智能合约应用程序和预算应用程序。

离线（2个API）：使个人和企业能够离线使用CBDC进行离线支付，并在以后通过转移余额使CBDC在线。

3.5 基于账户和代币的中央银行分类账

为了评估API是否可以与不同的中央银行分类账一起使用，该项目测试了基于账户和代币的中央银行分类账的模拟。这种方法表明，几乎相同的API功能和端点适用于任一账本。

基于帐户的账本中的一些约束，例如无法检索交易历史记录和用户帐户，以及访问锁定信息的解决方法，也适用于基于代币的账本。

在基于账户和基于代币的分类账结构之间发现了两个差异。首先，账号和服务提供商ID的格式不同，反映了每个账本底层数据模型的差异。其次，在项目期间测试的离线支付解决方案是特定于以太坊的，因此它不适用于基于代币的分类账。

为每个账本结构实现几乎相同的API功能表明，通过与账本无关的API抽象账本结构是可行的，同时保持对服务提供商和更广泛的生态系统的兼容性。它还显示了API层与基于帐户和代币的分类账一起使用的潜力。这是很重要的，因为选择不同的分类账技术有多种原因，许多中央银行正在探索和试验一系列用于零售CBDC系统的分类账设计和技术。它还表明，在分类账设计之前可以实现API设计——决定支付功能——以确保用户需求而不是技术实现推动解决方案。

3.6 隐私模型

API 层假设了一个隐私模型，该模型不会为中央银行分类账和API层提供对PII和支付数据的任何可见性或访问权限。具体模型设计如下：仅创建了假名标识符。用户 PII 以及其他支付数据和交易历史记录由服务提供商存储；服务提供商的身份被假名化为中央银行；必要时，在用户许可的情况下，数据可以在服务提供商之间共享（但不与中央银行），在通过核心API层时采用端到端加密。

这种隐私模型假设最终用户的高度隐私是必不可少的，但交易不会完全匿名。该系统的参与者——无论是来自公共还是私营部门——应该只能获得发挥其既定角色和执行特定任务所需的最低限度的信息。

3.7 安全

API 层必须支持安全可靠的零售支付。该项目调查并将行业最佳实践应用于安全功能，例如授权、身份验证、不可否认性和反重播。

在用户授权方面，Rosalind API探讨了允许PIP代表个人和企业行事的技术可行性。个人和企业用户与PIP相关联，只有该PIP才能被授予进行API调用（例如支付和锁定资金）的权限，以传递账户所有者的指示，以更改中央银行分类账中的账户状态和余额。如果另一个PIP想要请求个人或企业付款，则必须与帐户所有者的PIP进行交互。这是通过将别名传递给查找别名服务来实现的，该服务返回该帐户的PIP ID。

此外，该项目还探讨了允许ESIP通过提前连接账户来查看账户余额的可行性。这要求帐户所有者向ESIP授予适当的权限。

为了验证支付交易，该项目应用了FAPI标准的要素。每个API调用都是通过HTTPS进行的，使用TLS1.2及更高版本。身份验证信息必须包含在所有API调用的HTTP标头中。这些标头是x-fAPI-financialid（调用 API 的服务提供商的ID）和 x-API-key（调用 API 的服务提供商的密钥）。

不可否认性是一项安全功能，可确保一方以后不会否认发送消息或付款。这在争议或欺诈案件中至关重要，因为它可以确保付款的完整性。Rosalind API使用JSON Web Signatures（JWS）对交易进行签名和验证，以实现不可否认性。用于对事务进行签名的签名是所有“写入”API调用所必需的。对于每个 API 调用，签名都包含在消息的x-jws签名标头中。在项目期间，此功能被关闭以加速用例开发，但它将是任何未来生产系统的关键安全功能。该项目还测试了这如何应用于离线用例，在该用例中，中央银行将被要求签署将资金从用户帐户转移到中央银行持有的托管帐户。离线设备将使用签名来验证消息是否来自中央银行，并且用于该特定设备。

实现不可否认性功能可能会影响性能。对消息进行签名和验证签名可能会显著增加系统中的活动数量和消息大小，从而降低处理事务的速度和容量。

探索的最后一个安全功能是反重播。重播请求对中央银行分类账进行写入访问权限的API调用，无论是恶意还是意外，都可能导致账户被收取两次费用。Rosalind API要求每个“写入”API调用都包含一个唯一的幂等性ID。不接受与前一个幂等ID相同的API调用。

3.8 标准

作为开发API的起点，该项目探讨了如何实施相关的行业标准以及是否需要任何调整。例如，该项目试图在少量API上实施ISO 20022消息传递标准。这包括将用于请求锁定和锁定API、用于RTP API的pain.013和用于支付API的pacs.008进行了修改，以确保这些消息适用于 Rosalind API，并保持一致性。为了减小消息大小并提高互操作性，该项目还使用了ISO 20022缩写作为标记名称。为了进行身份验证，该项目应用了FAPI标准（见第3.7节）。还实施了法人机构识别编码（LEI）格式的使用，以帮助识别服务提供商。

3.9 服务提供商

CBDC生态系统将受益于服务提供商的多样性，通过这些服务提供者，可以产生新的创意并将其转化为创新的产品和服务。因此，API需要提供相关功能以支持不同类型的服务提供商。该项目试验了API功能，以支持两种可能的服务提供商类型：PIP和ESIP。

PIP将成为零售CBDC生态系统的门户。预计他们将为个人和企业提供数字“直通”钱包来管理他们的CBDC账户和余额。他们还将被期望管理与这些客户的关系，执行他们的付款指示，要求其他人付款并接受来自他人的付款请求。他们将负责遵守反洗钱、了解你的客户 （KYC）和CTF法规。在Rosalind API 中，PIP是默认的服务提供商类型，能够使用所有API。

ESIP不会提供钱包。他们将专注于其他增值服务，例如提供业务分析、预算和欺诈监控工具。ESIP还将与PIP合作，提供额外的可编程性服务，例如在三方锁中充当决策方或作为第三方发起付款。

4 用例和用户反馈

4.1 探索的用例

在项目期间，公共和私营部门的合作者开发了30多个零售CBDC用例的原型并测试了功能，并展示了Rosalind API的功能。下面介绍了有关用例的主要观察结果：

1. 用例组合包括一系列想法，从解决支付中的现有痛点、增强用户体验和简化流程到实现与现有支付轨道、卡网络和POS界面的集成。一些用例探索了新的支付方式，另一些用例则使用新兴技术测试了应用程序。所有人都调查了CBDC系统在更加数字化的经济中支持用户需求的潜力。

2. 部分用例涵盖了个人和企业的广泛领域，例如点对点转账、商品和服务的零售支付以及小额商业交易，包括收取佣金、支付工资和支持贸易融资。

3. 一些用例探索了使用近场通信（NFC）以及通过与POS、二维码、手机、智能卡、生物识别设备和智能助手的交互进行在线、商店和离线支付。RTP和ARTP API已经解锁了几个有趣的电子商务解决方案，以简化消费者的支付体验。

4. 一些用例还探讨了私营部门的可编程性。该API可以使个人和企业为特定用途存放一定数量的CBDC，并在事先商定的条件下触发付款。锁定和拆分付款的结合使许多创造性用途成为可能，可以同时结算多个付款段。一个用例还探索了富内容收据的使用，其中将向消费者提供付款详细信息以及消费者或商家触发付款所需的条件。

5. 一些用例通过测试许多离线支付解决方案来探索数字包容性。一个用例通过原型化父子钱包来探索数字包容性。还开发了实现小额支付的解决方案。一些用例测试了如何使用分散标识符（DID）和可验证凭据（VC）来最大限度地减少存储和传输的数据，用于不同类型的支付，以及如何使用银行验证的用户信息来快速跟踪入职流程。

4.2 用户反馈和未来对Rosalind API的改进

对用例的探索为Rosalind API提供了宝贵的反馈。关于功能，用户反馈表明，该API相对简单易用，并提供了对多个支付分支的强大处理。一些成员建议，为了提高效率和性能，可以探索异步API模型。

为了支持互操作性，分层架构有可能使零售支付服务无缝运行并支持更复杂的用例。此外，用例可以在API上以多种方式开发，为开发人员提供选择。一些用户建议，API可以从进一步的工作中受益，以更好地与安全行业标准保持一致。在创新和生态系统建设方面，结合使用一些基本功能，例如拆分支付、锁定和解锁以及 Rosalind 中允许的小数点后四位，有可能支持许多潜在的创新用例。

在项目范围内，以下项目被确定为可以从未来改进中受益的特定API功能：

1. 关于 ESIP，可以通过 API 实现基于角色的规则和权限，以定义 ESIP 满足用户需求所需的访问级别和类型。

2. 可编程性功能可以进一步开发，以支持有条件的分期付款。例如，当满足付款条件时，允许在交付商品或服务的同时向供应链中的多方付款。这可以通过增强锁定通信流来实现，使个人和企业能够同时为多个收款人预留资金并向其付款。

3. 在Rosalind中实现的别名和加密是初步的，如果它们最终部署在生产系统中，则需要进行大量开发。

4. 在Rosalind API中，HTLC锁是使用标准SHA256哈希算法和机密的编码32字节十六进制值实现的。此功能可以扩展为提供不同的哈希算法和机密长度。

5. 该项目的重点是设计正流量，假设CBDC支付交易顺利完成。这对于支付系统来说是不够的，在支付系统中，负流量或“不愉快的路径”（列出错误状态、替代路径和恢复过程）对于良好的用户体验至关重要。

6. Rosalind沙盒可以通过增强文档、为开发人员提供测试脚本和多媒体内容来进一步改进。

5 见解、经验教训和进一步探索的领域

该项目提供了以下见解和学习：

1. 设计良好的API层可以促进CBDC的零售支付。这通过项目期间探索的各种前端用例得到了证明。

2. 一组简单而核心的API功能可以支持广泛而多样的用例。它还有可能建立一个强大的生态系统，以促进产品和服务的创新，从而帮助满足更加数字化社会的未来需求。

3. 这些API可以与不同的中央银行分类账技术一起使用。在该项目中，测试了基于账户和代币的中央银行分类账的模拟，几乎相同的API功能和端点将适用于任何一个分类账。

4. API层的设计必须与CBDC更广泛的隐私模型的要求保持一致并实现。这是设计和构建Rosalind API的基础。隐私模型是在项目开始时和做出任何 API 设计决策之前确定的。

5. API可以支持CBDC中的离线支付，但在提供离线功能方面存在一系列挑战。离线支付需要强大的安全性和反重播保护。项目中测试的具体设计——将CBDC转移回中央银行分类账，用严格的安全控制以防止伪造、双重支出或资金损失——在离线支付设备和核心分类账之间建立了比项目期间测试的其他支付用例更紧密的耦合。这种紧密耦合将限制Rosalind API支持不同类型的离线支付解决方案的能力。

项目工作还提出了可以进一步探索的领域：

1. Rosalind隐私模型要求每个私营部门服务提供商捕获，存储和管理用户数据。它允许通过点对点加密在两个服务提供商之间共享许可信息。这引发了关于API如何允许生态系统在用户许可的情况下以隐私保护的方式共享用户和支付数据的进一步考虑。

2. 在API设计方面，需要在可扩展性和一致性之间进行权衡。该项目旨在使API尽可能简单和标准化，并允许服务提供商更灵活地为其特定用例构建定制功能。这种方法将有助于最大限度地提高可扩展性并支持创新，但可能会降低用户体验的一致性。更高的一致性需要更高水平的API功能标准化，因此服务提供商添加定制元素的灵活性较低。

3. 由于该项目测试了能够连接系统、协调活动和促进支付的API层的技术可行性，因此确定了定义生态系统中所有参与者的操作角色和责任的必要性。例如，该项目探讨了个人和企业如何将多个服务提供商链接到同一帐户，以及他们如何能够快速轻松地切换服务提供商。虽然这是一项重要的功能，但这种类型的安排可能会带来复杂性。例如，存在关于默认接收服务提供商可能是谁的问题，应信任哪个（哪些）服务提供商代表用户发起事务，以及当出现问题时，哪个提供商应承担责任。

6 结论

Rosalind项目表明，设计良好的API层可以使中央银行分类账与私营部门服务提供商进行交互，以安全地提供零售CBDC支付。

API 层可以与账本无关，因此可以抽象中央银行分类账选择。API 层也可以与应用程序无关，一组核心 API 功能可以支持广泛而多样的用例。通过与生态系统的合作，该项目还展示了CBDC系统的潜力，该系统可以使强大的生态系统促进创新，并帮助满足更加数字化社会的未来需求。

该实验提供了对零售CBDC系统许多重要方面的见解和研究，例如API设计、隐私、基于帐户和代币的分类帐、安全性、标准、互操作性、可编程性以及生态系统角色和责任。