HashKey：技術解析歐央行和日本銀行 Stella 項目進展

免責聲明：本文旨在傳遞更多市場信息，不構成任何投資建議。文章僅代表作者觀點，不代表火星財經官方立場。

小編：記得關注哦

來源：HashKey Capital Research

原文標題：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 項目的大量研究成果是非常重要的技術積累。