HashKey：技术解析欧央行和日本银行 Stella 项目进展

欧央行和日本银行对分布式账本技术的重点研究领域包括支付系统、证券结算系统、同步跨境转账、平衡机密性和可审计性。

原文标题：《欧央行和日本银行 Stella 项目进展分析》
撰文：郝凯，就职于 HashKey Capital Research
审核：邹传伟，万向区块链、PlatON 首席经济学家

欧央行和日本银行的 Stella 项目已经完成四个阶段的研究工作，研究领域包括支付系统、证券结算系统、同步跨境转账、平衡机密性和可审计性。本文对 Stella 项目的研究工作进行分析和总结，从中可以看出欧央行和日本银行对 DLT 的重点应用方向。Stella 项目的研究成果是欧央行和日本银行的重要技术积累。

Stella 是欧央行（ECB）和日本银行（BOJ）联合开展的研究项目，主要针对分布式账本技术（DLT，Distributed Ledger Technology）在支付系统（payment systems）、证券结算系统（securities settlement systems）、同步跨境转账（synchronized cross-border payments）、平衡机密性和可审计性（balancing confidentiality and auditability）等领域的适用性进行研究。目前，Stella 项目已经完成四个阶段的研究工作。

支付系统

Stella 项目第一阶段的目标是评估现有支付系统的特定功能，例如流动性节约机制（LSMs，Liquidity Saving Mechanisms），是否可以在 DLT 环境中安全有效地运行。金融机构之间的支付一般通过央行管理的实时全额结算系统（RTGS，Real Time Gross Settlement）。RTGS 的效率高，但对流动性的要求也高。LSMs 将付款与其他支付轧差后结算，能节约流动性。

研究设置

Stella 项目第一阶段是基于 Hyperledger Fabric 平台（0.6.1 版本）进行研究。

交易的业务逻辑通过两种智能合约实现，一种智能合约没有 LSMs 的设计，只是简单处理支付；另一种智能合约有 LSMs 的设计，欧央行和日本银行的 LSMs 智能合约分别基于 TARGET2 和 BOJ-NET 的排队和双边轧差机制设计。其中，TARGET2 的全称是泛欧实时全额自动结算系统（Trans-European Automated Real-time Gross Settlement Express Transfer System），是欧元的 RTGS 系统；BOJ-NET 的全称是日本银行金融网络系统（Bank of Japan Financial Network System），是日元的 RTGS 系统，也结算金融机构之间的日本国债交易。

研究方法

首先，程序在非 DLT 环境中进行，为 DLT 性能研究提供一个基准数据。然后，智能合约在没有共识机制的单个节点上运行，这是为了在没有分布式网络的影响的情况下测量切换到 DLT 的影响。最后，程序在具有共识机制的分布式环境中运行。

在性能方面，通过延迟来测量系统的性能。测量时用到的流量被设置为 RTGS 系统流量或最多每秒 250 个交易请求。为了估算延迟时间，记录每个节点上「正在被发送的交易请求」和「正在被执行和写入区块的交易」之间的时间。对于每笔交易，计算经过所有节点的时间，或者计算所有节点主体将区块加载至其账本的时间。

在安全性方面，评估以下三种情景对系统安全性的影响。一是一个或多个验证节点发生临时故障；二是 Fabric 中负责证书授权的特殊节点发生临时故障；三是部分交易以不正确的数据格式发送到系统。这些事件带来的额外延迟和恢复系统功能所需的时间是评估安全性的主要参数。

研究结论

1、基于 DLT 的解决方案可以满足 RTGS 系统的性能要求。在 DLT 环境中每秒可以处理的交易请求量与欧元区和日本的 RTGS 系统处理的交易请求量相当，欧元区和日本的 RTGS 系统的平均流量是每秒 10-70 个请求。当每秒交易请求量超过 250 时，需要在流量和性能之间的做出取舍。同时，研究还证明了在 DLT 环境中实施 LSMs 的逻辑可行性。

2、DLT 的性能受到网络规模和节点之间距离的影响。当网络节点的数量增加时，执行支付所需要的时间也会增加。同时，节点之间距离对性能的影响与网络结构有关：在达成共识的必要最小节点数是足够接近的前提下，网络其余部分的分散程度对延迟的影响有限；达成共识的必要最小节点数的分散程度越高，对延迟的影响将会越大。

3、基于 DLT 的解决方案有潜力增强支付系统的恢复能力和可靠性。研究表明，DLT 有承受验证节点故障和不正确的数据格式等问题的潜力。第一，只要维持共识算法所需数量的节点是可用的，系统的可用性就不会受到影响。第二，无论停机时间多长，验证节点都可以恢复。第三，如果唯一负责证书授权的特殊节点发生故障，这可能会导致系统发生单点故障。第四，不正确的数据格式不会影响系统的整体性能。

证券结算系统

Stella 项目第二阶段是研究两个关联偿付义务之间的结算，如券款对付（DvP，Delivery versus Payment），是否可以在 DLT 环境中进行概念设计和执行。

研究设置

Stella 项目第二阶段是基于三个平台进行研究：Corda、Elements 和 Hyperledger Fabric。研究内容是一个标准的、程序化的场景：两个交易对手方之间进行证券和资金的交易。

在 DLT 环境中执行 DvP 有两种不同的方法：单账本 DvP （single-ledger DvP）和跨账本 DvP （cross-ledger DvP）。

对于单账本 DvP，资金和证券记录在同一账本。在这种情况下，两个交易对手方各自确认交易指令之后，两种资产的交换会在同一个交易中进行处理。

对于跨账本 DvP，资金和证券记录在两个不同的账本，账本之间存在某种机制将两种资产的交易联系起来。跨账本 DvP 是非常复杂的，可以进一步细分为两种类型。

一是跨账本 DvP 的账本之间有连接。在 DLT 环境中，这种类型可能需要中介来促进和控制两个账本之间的协调。在 Stella 项目第二阶段，这种类型不做重点研究。

二是跨账本 DvP 的账本之间没有连接。在 DLT 环境中，跨链原子交易功能可以使没有连接或中介的账本之间实现 DvP。实现跨链原子交易的关键要素是数字签名和哈希时间锁合约（HTLC，Hashed Timelock Contracts）。在 Stella 项目第二阶段，这种类型的跨账本 DvP 是基于 HTLC 实现。

图 1：在 DLT 环境中实现 DvP 的方法

研究方法

如前文所述，Stella 项目第二阶段的研究内容是一个标准的、程序化的场景：两个交易对手方（银行 A 和银行 B）在 DLT 环境中进行商定数额的证券和资金之间的交易。

单账本 DvP 的流程

单账本 DvP 的设计理念是两个交易对手方商定交易指令的内容，然后在同一个交易中处理。两个交易对手方对交易指令达成一致后，两个关联偿付义务合并成一个交易，两个交易对手方直接使用加密签名进行处理，不需要 DLT 网络中的特定匹配函数。

图 2：单账本 DvP 的流程

如上图所示，两个交易对手方遵循以下步骤，可以成功进行单账本 DvP。

第一，银行 A （证券的原始持有人）创建证券指令（支付商定数额的证券），银行 B （资金的原始持有人）创建资金指令（支付商定数额的资金）。在这个阶段，两项指令都没有被签名。

第二，银行 A 将其没有签名的证券指令发送给银行 B。银行 B 核实证券指令的内容，并将证券指令与自己的资金指令结合起来，组成一套完整的指令。银行 B 签署资金指令，并将其发回银行 A。

第三，银行 A 验证全部指令，并签署证券指令，然后将双方签名过的全部指令提交给共识机制。

第四，DLT 环境中的共识机制对提交的指令进行验证和确认，并将结果写入账本。商定的资金和证券分别转移到银行 A 和银行 B。

如果上述某一个步骤未能完成，结算就会失败。此时，资金和证券由各自的原始持有人保管，并可立即用于其他交易。

使用 HTLC 的跨账本 DvP 的流程

跨账本 DvP 的设计理念是让两个交易对手方根据账本上记录的承诺就交易指令的内容达成一致，并使用 HTLC 进行跨账本 DvP。

在下图中，证券出售方（银行 A）和证券购买方（银行 B）已经对准备交易的数量、资产类型、锁定时间和哈希函数达成协议。协议的内容包括两个交易：在两小时内，8 个单位的证券由银行 A 转移给银行 B；在一小时内，6 个单位的资金由银行 B 转移给银行 A。

图 3：使用 HTLC 的跨账本 DvP 的流程

如上图所示，两个交易对手方遵循以下步骤，可以成功完成使用 HTLC 的跨账本 DvP。

第一，银行 A （证券的原始持有人）生成一个原像 X 和对应的哈希值 Y （Y=H(X)）。银行 A 将 Y 分享给银行 B。银行 A 创建第一个证券指令（支付商定数额的证券）。在这个指令中，银行 A 规定了两种状态：如果银行 B 可以提供 X 满足 Y=H(X)，那么银行 B 是证券的接收人；如果时间超过两个小时，那么银行 A 是证券的接收人。银行 A 对这个指令签名，并将签名的指令提交给证券的共识机制。

第二，证券 DLT 网络中的共识机制对提交的第一个证券指令进行验证和确认，并将结果写入证券账本。

第三，银行 B （资金的原始持有人）核实银行 A 承诺的第一个证券指令的内容，然后银行 B 创建第一个资金指令（支付商定数额的资金）。在这个指令中，银行 B 规定了两种状态：如果银行 A 可以提供 X 满足 Y=H(X)，那么银行 A 是资金的接收人；如果时间超过一个小时，那么银行 B 是资金的接收人。银行 B 对这个指令签名，并将签名的指令提交给资金的共识机制。

第四，资金 DLT 网络中的共识机制对提交的第一个资金指令进行验证和确认，并将结果写入资金账本。

第五，银行 A 验证银行 B 承诺的第一个资金指令的内容，然后银行 A 创建第二个资金指令（获得商定数额的资金）并签名，并将签名的指令提交给资金的共识机制。同时，银行 A 在这个指令中提供原像 X。

第六，资金 DLT 网络中的共识机制对提交的第二个资金指令进行验证和确认，并将结果写入资金账本。此时，商定数额的资金从银行 B 转移到银行 A。

第七，银行 B 从第二个资金指令中获得原像 X。然后银行 B 创建第二个证券指令（获得商定数额的证券）并签名，并将签名的指令提交给证券的共识机制。同时，银行 B 在这个指令中提供原像 X。

第八，证券 DLT 网络中的共识机制对提交的第二个证券指令进行验证和确认，并将结果写入证券账本。此时，商定数额的证券从银行 A 转移到银行 B。

如果上述某一个步骤未能完成，结算就会失败。对于使用 HTLC 的跨账本 DvP，结算失败可能会导致两种不同的结果。

一是资金和证券被退还给各自原始持有人，两个交易对手方都不会承担太大风险，但会面临重置成本风险和流动性风险。

二是资金和证券都会被一个交易方获得，另一方会承担较大风险。例如，在银行 A 获得商定的资金后，银行 B 没有在约定的锁定时间（两小时）内完成第二个证券指令。最终，银行 A 将持有退还的证券和获得的资金，而银行 B 损失本金。在这个结算失败的场景中，没有实现跨账本 DvP，说明了 HTLC 技术目前还存在的弱点，需要进一步发展。

研究结论

第一，DvP 可以在 DLT 环境中进行概念设计和执行。资金和证券可以在同一个账本，也可以在不同的账本，DvP 的具体设计取决于 DLT 平台的特征。此外，根据实际用例，DvP 的设计可能受到一些因素的影响，包括 DvP 与其他交易后处理基础设施之间的相互作用。

第二，DLT 为实现跨账本 DvP 提供了一种新的设计方法，并且不需要账本之间有任何连接。概念分析和进行的实验已经证明，在账本之间没有任何连接的情况下，也可以实现跨账本 DvP。跨链原子交易有帮助不同账本之间实现互操作性的潜力，并且不需要账本之间有任何连接或特定排列。

第三，基于具体设计，在 DLT 环境中的实现跨账本 DvP 有一定的复杂性，并可能造成其他需要解决的问题。在账本之间没有连接的情况下，实现跨账本 DvP 需要两个交易对手方进行几次迭代和交互。这种设计可能会影响交易速度，并可能需要暂时阻塞流动性。从业务的角度来看，独立的账本之间可能会无意中互相影响；从风险的角度来看，使用 HTLC 的跨账本 DvP 失败，其中一个交易方可能会面临较大风险。

同步跨境转账

现行的跨境转账方案存在效率低、手续费高、无法实时收款等问题。如下图所示，付款人 A 和收款人 C 之间存在中间人 B，整个转账过程可以分为 A 转账给 B 和 B 转账给 C 两个步骤。如果 B 收到 A 的转账之后，没有完成给 C 转账，那么 A 将面临损失本金的风险。

图 4：跨境转账流程示意图

在跨境转账中，如果不同账本之间进行同步结算，那么信用风险就会大大降低。Stella 项目第三阶段的目标是为跨境转账提供新型解决方案，提高跨境转账的安全性。

研究设置

在 Stella 项目第三阶段的研究中，账本可以是中心化账本或分布式账本。研究实验分为两种：使用跨账本协议（ILP，the Interledger Protocol）和不使用 ILP。使用 ILP 的实验是用来研究两个中心化账本之间、两个分布式账本之间、一个分布式账本和一个中心化账本之间的转账；不使用 ILP 的实验是用来研究两个分布式账本之间的转账。

使用 ILP 的两个中心化账本之间的转账实验中，中心化账本采用 Five Bells Ledger。结果表明，使用 ILP 的两个中心化账本可以通过托管完成同步结算。

使用 ILP 的两个分布式账本之间的转账实验中，分布式账本采用 Hyperledger Fabric。结果表明，使用 ILP 的两个分布式账本可以通过带有 HTLC 的链上托管完成同步结算。

不使用 ILP 的两个分布式账本之间的转账实验中，分布式账本采用 Hyperledger Fabric。结果表明，不使用 ILP 的两个分布式账本可以通过链上托管完成同步结算。

使用 ILP 的分布式账本和中心化账本之间的转账实验中，分布式账本采用 Hyperledger Fabric，中心化账本采用 Five Bells Ledger。结果表明，ILP 与账本的类型无关。

研究方法

Stella 项目第三阶段的研究场景如下图所示，包括付款人、收款人和中间人。在转账过程中，各参与方采用的账本类型没有具体限制。各参与方之间的转账方法主要有五种：信任线（trustlines），使用 HTLC 的链上托管（on-ledger escrow using HTLC），第三方托管（third party escrow），简单支付通道（simple payment channels）和使用 HTLC 的条件支付通道（conditional payment channels with HTLC）。

图 5：Stella 项目第三阶段的研究场景示意图

信任线

信任线是交易双方在信任基础进行交易的一种方法。在信任线中，不会把每一笔交易都在账本上进行结算，只会将最终的结算状态记录在账本上。使用信任线的转账可以分为三个阶段：建立阶段、状态更新阶段和结算阶段。

• 建立阶段

付款人 A 和收款人 B 在同一账本上拥有账户，那么 A 和 B 之间可以建立信任线，并设定各自的信任线额度。在达到信任线额度之前，A 和 B 之间的交易无需结算。

• 状态更新阶段

当准备交易时，付款人向收款人发送哈希值和规定时间，只要收款人在规定时间之前提供哈希原像，那么双方的信任线状态会更新，收款人的账户余额增加，付款人的账户余额减少。未结算的交易总额或信任线的状态由交易双方保存在各自的数据库中。从技术上讲，只要不超过信任线额度，交易双方就可以一直使用信任线进行双向交易。

• 结算阶段

交易双方将总净额在账本上进行结算，并将最终状态记录在账本上。

使用 HTLC 的链上托管

在使用 HTLC 的链上托管方法中，付款人的资金由账本托管。付款人向收款人发送哈希值和规定时间，如果收款人在规定时间内提供哈希原像，那么收款人就可以收到转账资金；如果收款人不能在规定时间内提供哈希原像，那么转账资金退回给付款人。由于交易的传输和处理时间会被计算在规定时间内，所以这种方法更适合支持高速交易的账本系统。

第三方托管

第三方托管依赖于可信的第三方，在概念上与使用 HTLC 的链上托管类似。付款人将转账信息发送给交易双方都信任的第三方，并将资金转到第三方拥有的账户上。如果收款人在规定时间内提供哈希原像，那么第三方会将托管的资金转给收款人。如果收款人不能在规定时间内提供哈希原像，那么第三方会将托管的资金归还付款人。

支付通道

支付通道的特点是交易双方可以合并多个交易而只结算最终账户的净轧差。在支付通道中，交易双方需要在同一账本拥有账户。交易分为以下三个阶段：建立阶段、状态更新阶段以及清算阶段。

• 建立阶段

交易双方或其中一方将一定数量的资金托管在一个临时、共享的支付通道中。

• 状态更新阶段

在交易开始前，双方先签署一个状态声明，用以表示支付通道中双方资金分配。之后，每个新的状态声明都是双方资金分配的更新版本。交易双方可以直接发出状态声明，不需要有任何资金转入或转出账本上的共享账户。只要交易双方的余额为正值，便可持续在支付通道中进行双向交易。

• 结算阶段

一旦有一方参与者想停止使用支付通道，可以执行退出操作。将最后的状态声明更新提交至账本，结算后的余额会退给发起支付通道的交易双方。账本可以通过核实签名和最后结余来验证状态更新的有效性，防止参与者使用无效状态来退出支付通道。

支付通道还可以细分为简单支付通道和使用 HTLC 的条件支付通道，两者之间的主要区别在于，HTLC 是条件支付通道的状态声明的一部分，当状态声明被提交至账本时，HTLC 也会被提交至账本。

研究结论

Stella 项目第三阶段研究的几种转账方法的比较如下表所示。

表 1：转账方法的对比

对于安全性，链上托管、第三方托管和条件支付通道都有强制性机制，可以确保在交易过程中完全履行自己责任的交易方不会面临损失本金的风险。

对于流动性效率而言，五种支付方法的排序是信任线、链上托管和第三方托管、简单支付通道和条件支付通道。信任线的流动性效率优于其他支付方法。链上托管和第三方托管（只需要托管本次转账所需的资金) 的流动性效率一般优于简单支付通道和条件支付通道 (要托管支付通道中所有需要支付的资金）。

从技术角度来看，通过使用同步支付和锁定资金的方法可以提高跨境转账的安全性。需要指出的是，实施这种新方法之前需要进一步思考法律政策、技术成熟度和成本效益等问题。

平衡机密性和可审计性

业内的研究人员提出很多方案来解决分布式账本中交易信息的机密性和隐私保护问题。这些解决方案会限制未经授权的用户获取交易信息，通常被称为增强隐私技术（PETs，Privacy-Enhancing Technologies）。同时，为了确保基于 DLT 的金融市场基础设施的可审计性，经过授权的第三方审计机构需要获得必要的交易信息。在一定程度上，机密性和可审计性存在矛盾。

Stella 项目第四阶段的目标是平衡交易信息的机密性和可审计性。具体来讲，Stella 项目第四阶段将应用在 DLT 中的 PETs 进行介绍和分类，并评估交易信息是否可以被经过授权的审计机构进行有效审计。

应用在 DLT 中的 PETs

Stella 项目第四阶段根据增强隐私的基本方法将 PETs 分为三类，这些增强隐私的技术方法并不是相互排斥的，它们可以合并应用，进一步增强机密性。

隔离技术

隔离技术可以增强 DLT 网络的机密性，即交易信息在交易参与者范围内隔离，只在「有必要知道」的基础上进行共享。使用隔离 PETs 时，网络中不存在所有参与者都能访问的、包含所有交易信息的公共账本，每个参与者只能访问到与自己相关的交易信息。

图 6：隔离技术示意图

• Corda 的隔离技术

Corda 的参与者在网络中进行特定通信，交易信息只在获得授权参与者之间共享，而网络中的其他参与者不能访问交易信息。同时，Corda 网络中还设置了公证人角色，以防止出现双花。

• Hyperledger Fabric 的隔离技术

Hyperledger Fabric 为参与者提供频道功能，这些频道将整个网络分成若干子网络，参与者只能访问子网络的账本，不能访问全网账本。参与者必须经过认证和授权才能处理和维护特定子网络的账本，因此，参与者只能访问自己参与的交易。

• 链下支付通道

通过链下支付通道，资金可以在主网之外进行交易。参与者不需要将所有交易信息在全网进行广播，从而增强交易信息的机密性。

隐藏技术

在交易层面上，可以通过隐藏技术来防止未经授权的参与者访问交易信息，从而增强交易信息的机密性。

图 7：隐藏技术示意图

• Quorum 的隐私交易

Quorum 平台提供隐私交易的功能，参与者可以对未经授权的第三方隐藏他们的交易信息。在执行交易之前，交易者可以指定隐私交易的参与方。隐私交易的详细交易信息存储在隐私账本，公开账本只记录交易信息和发送方的哈希值。

• Pederson 承诺（Pedersen commitment）

Pederson 承诺是指发送方创建一个交易量的承诺来进行全网广播，但不向全网透露实际交易量。Pederson 承诺是通过网络定义的参数和发送方选择的参数创建的。交易参与者可以使用 Pedersen 承诺将账本上的交易金额替换为第三方不能破译的承诺。

• 零知识证明（ZKP，zero-knowledge proof）

零知识证明是指在不向验证者提供任何实际信息的情况下，使验证者相信某个论断是正确的。在 DLT 网络中，ZKP 可以用来增强交易信息的机密性。

切断联系技术

PETs 可以用于切断公共账本上可见的发送方、接收方信息与实际交易信息之间的关系。未经授权的第三方可以查看交易参与者和交易金额，但无法确定交易关系，即无法确定哪个参与者是发送方或接收方。

图 7：切断联系技术示意图

• 一次性地址

参与者可以对每个交易使用不同的化名或地址（一次性地址），以防止身份与参与的交易关联起来。一次性地址技术广泛应用于各种方案和项目中，增强了交易信息的机密性。对于参与者需要管理大量地址而引起的操作复杂性问题，HD 钱包（hierarchical deterministic wallet）可以解决。一次性地址之间没有明显的关联，第三方很难将这些地址联系在一起。

• 混币

混币原理就是多个参与者混合参与多个交易，单个交易中的发送方和接收方的地址被分离，未经授权的第三方很难从中找到一一对应的映射关系，增强了交易信息的机密性。

• 环签名

环签名技术可以用来证明签字人属于一组签字人，而不透露具体是哪个签字人。简单来讲，就是环签名所形成的群组里面，未经授权的第三方仅能知道参与环签名的人是这个组里面的人，却不能知道具体是组里的哪个人。

交易信息的可审计性

对交易信息的审计方法和审计有效性在很大程度上取决于网络中采用的 PETs。

评估可审计性的角度

Stella 项目第四阶段从三个维度来评估交易信息的可审计性：即获得必要信息、所获得信息的可靠性、审计过程的效率。

• 获得必要信息

审计机构是否能获得进行审计活动的必要信息是评估可审计性的第一个维度。当 DLT 网络中应用 PETs 时，审计机构不能查看和解析所有交易信息。因此，审计机构需要其他可信的数据源。可信的数据源可以是 DLT 网络中设计的角色（如 Corda 的公证人）或信誉良好的第三方（如混币服务商）。在可信的数据源向审计机构提交必要信息的过程中，必须确保审计机构能够对必要信息进行访问。

• 所获得信息的可靠性

审计机构获得必要信息后，评估可审计性的重点是所获得信息的可靠性。如果审计机构通过所获得的信息可以得到原始交易信息，那么所获得的信息被认为是可靠的。

• 审计过程的效率

审计过程的效率也是评估可审计性的重要因素。效率可以由资源的消耗来衡量（例如计算能力、数据存储和通信带宽）。如果审计过程消耗了过多的计算能力，或者网络和审计框架的设置方式使得审计机构和交易参与者必须为每个交易进行通信，那么可以认为审计过程的效率太低。

对每种 PETs 的可审计性进行评估

• Corda 的隔离技术

在 Corda 网络中，审计机构可以通过公证人获得所有必要信息，进行有效审计。

• Hyperledger Fabric 的隔离技术

在 Hyperledger Fabric 网络中，所有频道的交易都会发送到排序服务机构，审计机构可以将排序服务机构作为可信数据源进行审计。审计机构也可以在 Hyperledger Fabric 网络中部署观察者节点，从而获得必要信息进行审计。

• 链下支付通道

对于链下支付通道，审计机构可以对开通或关闭链下支付通道进行审计，但是无法审计链下支付通道发生的每一笔交易。如果网络中存在链下支付通道的 hub，那么这个 hub 中会记录每一笔交易信息，审计机构可以将其作为可信数据源进行审计。

• Quorum 的隐私交易

在 Quorum 网络的隐私交易中，发送方和交易信息的哈希值记录在公共账本上。审计机构可以解析发送方的信息，但它需要发送方提交交易信息，以验证记录在账本上的哈希值。因此，审计机构和参与者之间需要频繁通信，对审计效率产生负面影响。提高效率的可行方案是审计机构在网络中部署观察者节点。

• Pederson 承诺（Pedersen commitment）

在 Pederson 承诺中，实际的交易金额被隐藏。为了解析承诺，审计机构需要交易参与方提供他们选择的参数或交易金额。如果审计机构能同时获得选择的参数和交易金额，那么审计机构解析承诺所需的计算资源最小，审计过程的效率足够高。如果审计机构只获得选择的参数，没有获得交易金额，那么审计机构解析承诺所需的计算资源会大大增加，审计过程的效率会大受影响。

• 零知识证明（ZKP，zero-knowledge proof）

ZKP 的可审计性与具体实施方案有关。当发送方和接收方的信息被 ZKP 隐藏时，审计机构无法从公共账本记录的信息中识别交易方，因此无法完成审计。

• 一次性地址

审计机构需要参与者提供每笔交易使用的一次性地址，但审计机构无法确保参与者提供信息的真实性，因此无法完成审计。

• 混币

如果使用的混币技术存在中间服务商，那么审计机构可以将中间服务商作为可信数据源，完成审计。如果使用的混币技术是基于 P2P 网络，审计机构需要参与者提供交易信息，但无法确保参与者提供信息的真实性，因此无法完成审计。

• 环签名

审计机构无法确定环签名中具体的签名人，因此无法完成审计。

研究结论

每种 PETs 的机密性总结如下表所示。表中概述了未经授权的第三方是否可以查看和解析发送方、接收方和交易金额的信息。同时，多种 PETs 的组合使用可以达到更高级别的机密性。

表 2：各种 PETs 的机密性对比表

表 3：各种 PETs 的可审计性对比表

在很多情况下，有效审计依赖于网络中存在的中心化可信数据源。但过度依赖中心化可信数据源可能会导致审计过程中的单点故障。多种 PETs 的组合使用可以达到更高级别的机密性，但同时会影响交易信息的可审计性，因此需要在机密性和可审计性之间做出取舍。

PETs 的具体实施方案会影响可审计性。不同类型的 PETs 在可审计性方面存在一般性的特征。对于隔离技术，没有共享的公共账本记录所有的交易信息，因此审计机构依赖于拥有所有交易信息记录的可信数据源。对于隐藏技术，隐藏的交易信息以可验证的形式记录在公共账本上，因此，实现有效审计的关键是获得必要的交易信息。对于切断联系技术，它们主要特点是很难从公共账本记录的信息中确定交易关系，因此，需要建立一种机制来存储关于发送方、接收方身份以及交易关系的原始信息集，并与审计机构共享这些信息。

需要指出的是，当前对每种 PETs 可审计性的评估结果并不是最终结论，评估结果可能会随着技术的发展而发生变化。欧央行和日本银行对可审计性的关注程度很高，未来各国央行采用的隐私增强技术肯定会兼具可审计的特点。

思考和总结

Stella 项目由欧央行和日本银行进行联合研究，探究 DLT 技术是否可以实现更安全，更快速和更便宜的金融交易。Stella 项目有助于促进关于 DLT 在金融市场基础设施的可用性方面的更广泛的讨论。

Stella 项目着重于支付系统、证券结算系统、同步跨境转账等金融市场基础设施的研究，同时也对交易信息的机密性和可审计性做了大量研究。从这里可以看出欧央行和日本银行未来对 DLT 的重点应用方向。

Stella 项目并不是用来复制或挑战现有系统，官方的研究报告中也多次强调 DLT 的实际应用会面临法律政策的监管。同时，DLT 的应用成本也是一个必须考虑的问题。

数字货币除了用于支付场景，也会用于金融交易场景。而金融交易场景离不开数字资产、金融交易后处理。不研究金融交易后处理，就不能完整地理解数字货币和数字资产。因此，Stella 项目对金融交易后处理进行了很多对研究实验。

目前，欧央行和日本银行并没有官方宣布发行央行数字货币的计划，但如果未来欧央行和日本银行发行央行数字货币，Stella 项目的大量研究成果是非常重要的技术积累。