作者：任之劼，荷蘭代爾夫特理工大學博士、博士後，唯鏈高階區塊鏈技術研究員最近，央行數字貨幣（DC/EP）正在農行內測，並將很快試點推廣的新聞讓「數字貨幣」以及「區塊鏈」又火了一把。然後，網上各種關於 DC/EP 的文章也紛至沓來。然而，其實這次 DC/EP 的內測訊息並不是官方放出的，所以其實關於 DC/EP 的所有技術特點分析都建立在 DC/EP 從去年開始放出來的一些新聞，包括央行數字貨幣研究所所長的訪談和文章，以及數字貨幣研究所申請的專利的基礎上。官方後來放出的新聞也沒有跟進任何關於 DC/EP 的技術方向之類的說明。因此，既然大家都沒有什麼內幕訊息，那麼我也根據之前放出的情報，對於 DC/EP 採用的技術方案做個無責任推測好了。首先 DC/EP 對於行內人士來說真的不是什麼新東西了：比如類似的分析我 17 年就做過一次，而且基本上大體的框架還是一致的。如何看待央行旗下媒體發文稱要加快推出主權數字貨幣？主權數字貨幣有哪些使用場景？這次推測的主要參考文獻：· 姚前：央行數字貨幣——對貨幣體系的最佳化及其發行設計· 姚前：基於區塊鏈的全新央行數字貨幣實現方案· 姚前：央行數字貨幣的技術考量· 範一飛：關於央行數字貨幣的幾點考慮· Chaum, David . "Blind Signatures for Untraceable Payments."Proc Crypto(1982):199-203.· George Danezis, Sarah Meiklejohn, "Centrally Banked Cryptocurrencies", 2015數篇央行數字貨幣研究所的專利，之前關於央行數字貨幣的新聞（之前看過懶得找了）和穆長春關於央行數字貨幣的課程（沒上過那個課，但是間接地瞭解了一下）。DC/EP 是否是區塊鏈 / 加密貨幣其實之前就透露過一個重要的資訊，就是「數字貨幣研發不預設技術路線，考慮區塊鏈或電子支付等」，其中，如果大家有一直關注過央行數字貨幣的發展和官方訊息，就會知道後半句話都是後來加上去的，最早的表態裡其實是明確說沒有采用區塊鏈的。實際含義就是：1，DC/EP 現階段不採用區塊鏈；2，將來可能考慮採用區塊鏈技術。而這個結論也和央行一直以來放出的訊息和技術方向相符。因此，考慮到上一次關於 DC/EP 的訊息是目前 DC/EP 僅考慮國內使用，不考慮跨境支付，我基本上可以推測出：1. DC/EP 基本上是一箇中心化系統。2. 它也許採用了一些區塊鏈的技術，但是不足以讓其稱之為「區塊鏈」，甚至連「私有鏈」都稱不上。因此嚴格上來說他和類似於比特幣的加密貨幣是不一樣的。那麼換言之這裡傳遞出的核心資訊就是——DCEP 不是拜占庭容錯的。3. 在未來，當 DC/EP 已經比較成熟之後，會考慮使用區塊鏈技術來應對跨境支付的需求。實際上，從個人的角度來看，DC/EP 不使用區塊鏈是理所當然的事情——首先，從央行傳遞出多次的資訊來看，它就是個中心化系統，而眾所周知，中心化系統用不到區塊鏈技術，也用不到拜占庭容錯。我之前看到很多區塊鏈行業的人對此表示失望，一些比特幣的支持者尤甚。其實，與他們相反，我對於 DC/EP 不使用區塊鏈技術一直都是非常欣慰的——這說明央行數字貨幣研究院的人並不急於去蹭區塊鏈技術的熱點，很清楚區塊鏈技術的侷限性，也很清楚自己在做什麼。有人可能會說：「為什麼 Libra 就採用了區塊鏈技術和拜占庭容錯？是不是說明 Libra 的技術更先進？」首先——Libra 的確更新，因為 DC/EP 和 Libra 處於完全不同的階段：DC/EP 都已經接近落地了，Libra 還停留在更改白皮書的階段。換句話說，DC/EP 啟動的時間遠早於 Libra，而在那個時候區塊鏈的技術還不成熟，因此在那個時候選擇不用區塊鏈這麼一個從理論和實踐上都不成熟的技術是正確的。而 Libra 作為是去年才出來的專案，如果採用的技術還停留在 DC/EP 啟動的時候那才是可笑的事情。其次，更新不代表更好更先進。的確 Libra 採用了 HotStuff BFT 這個我覺得算得上是區塊鏈共識演算法的某個「最終答案」的共識演算法，同時，在其之上改進的 Libra BFT 也是我覺得非常符合邏輯的共識機制，但畢竟這僅僅是理論層面，在實踐方面還沒有先例。同時，區塊鏈共識演算法發展至今在我看來仍舊沒有稱不上成熟和完善，所以即便是現在，我都不覺得 DCEP 採用區塊鏈演算法是個好主意，所以我認為 DC/EP 現在將區塊鏈技術定位為「未來可能採用的技術」是非常合適的。再次，Libra 和 DCEP 的定位完全不同——Libra 是個攪局者，是個非主權貨幣，換句話說，它如果不用區塊鏈技術，一沒有任何競爭力，二沒有任何話題性，它和主權貨幣競爭的願景（在 Libra2.0 裡這個願景已經改了）就完全不成立。而相反，DC/EP 是中心化的主權貨幣，從技術上和願景上都沒有用區塊鏈技術的必要。不用區塊鏈，DCEP 的匿名是怎麼實現的實際上，區塊鏈技術也不是用來匿名的，也並沒有 DC/EP 完全匿名的說法，官方的說法是「可控匿名」，我的理解是——對於中央銀行而言是可控的，而對於商業銀行和其他使用者而言是匿名的。換言之，央行應該有一個非實名的如同類似於比特幣的 DCEP 賬本，在需要的時候，可以追溯資金和交易，這是「可控」，而對於其他商業銀行和使用者而言，他們可以驗證每筆交易的安全性，但是並不知道交易者的身份，是為匿名。根據央行數字貨幣研究院的論文來看，DC/EP 的基本結構更像是數字貨幣先驅 David Chaum 的 Ecash 而非類似於比特幣的加密貨幣。但是，並沒有用到 Ecash 的盲簽名，取而代之的是央行這個可信中心。首先，在貨幣發行上 DC/EP 採用了和 Ecash 類似的方法——在 DC/EP 中，由央行負責發放貨幣。它對於每個貨幣給與一個獨一無二的編號，然後與面值資訊（例如 100 元，10 元）一起用央行的私鑰簽名，就生成了一個合法的數字貨幣。這個數字貨幣，實際上可以看成一個央行背書的一次性兌換券，任何人都可以憑藉這個兌換券換取等額的現金，或者一個新的兌換券。實際上，當然，對於數字貨幣稍有了解的人都知道，無論對數字貨幣進行加密的技術多麼高明，最難的地方始終在於如何防止雙重支付。這個時候，就需要有一個即時擁有全部賬本的中心，負責驗證每一筆兌換券是否已經用過。於是，當有人想要發起一筆交易的時候，接收者需要將收到的數字貨幣發給中心進行驗證，如果這個編號之前沒有使用過，那麼中心登出這個貨幣，並且重新發放一個等值的新兌換券給接收者——以上的這個步驟相當於驗鈔。這個方案的問題是可追蹤性——因為這個中心實際上將掌握所有交易的去向，因此 David Chaum 提出了盲簽名——一種可以讓某條訊息「盲化」，於是，讓中心可以在不知情的情況下對兌換券的編號簽名。這樣，中心在驗證交易的時候就只能：「嗯，這上面有我的簽名，是真的，而且這個編號是第一次見，所以沒有使用過。但是我不記得我是什麼時候籤的了，所以我不知道這張兌換券是我什麼時候發給了誰，我只能確認確實是我發的。」但是，DC/EP 應該是沒有用到盲簽名技術，因為對於央行而言，並沒有匿名和防止追蹤的需求。而對於央行而言的匿名，是不能讓商業銀行和機構透過這個賬本對資金進行追蹤或者破解出對應某筆資金所有者的資訊——這裡，就要提一下 DC/EP 的雙層運營體系了。簡單來說，DC/EP 的發行和使用是透過兩層進行的，央行負責把錢給到下屬商業銀行，下屬商業銀行用自己的系統搞出相應的錢包軟體，然後支援使用者把錢換成央行數字貨幣。換句話說，央行自己有一箇中心賬本，負責把錢發給商業銀行，商業銀行再負責透過整合到自己銀行客戶端的錢包軟體把錢發給個人，但是發到個人之後，這筆錢還是要去央行的賬本中登記。換句話說，DC/EP 的使用是肯定要透過商業銀行的。而央行需要考慮的是這個過程中的隱私性，或者說，部分隱私性，至少讓中間的商業銀行不能如同中央銀行一般對於 DC/EP 的去向進行追蹤——因此，使用者和 DC/EP 之間的通訊應該「盲化」，即收款者在驗鈔的時候提供的資料需要加密，然後只有央行才能解密。而在這中間，商業銀行的錢包僅僅負責建立通訊。但其中不可避免的是：1. 如果交易雙方來自同一銀行，那麼透過同一銀行的客戶端交易，很難保證隱私性，自然資金在同一銀行間的流動也是可以被追蹤的。2. 如果交易雙方不在同一銀行，那麼無法避免的交易中至少會洩露「資金來自 xx 銀行」這樣的資訊。但是，除此之外，這張鈔票對於中間的商業銀行而言確實達到了和 Ecash 一樣匿名的效果——假設銀行 A 的使用者從銀行 B 的使用者那裡收到一筆錢，那麼，當這位使用者再把錢轉給銀行 B 的使用者時，銀行 B 是無法看出這筆錢和之前那筆錢的關聯的，因為兩張錢除了面值一樣，其他資訊都不同也沒有任何關聯。DC/EP 真的和區塊鏈 / 加密貨幣沒有任何關係嗎？其實也未必——以上的方案有一個有一個巨大的瓶頸，即所有的交易都需要透過中央銀行。這裡，中央銀行需要維護一個賬本，賬本中歷史記錄的部分記錄每一筆已經花掉的錢，而現存部分記錄每一筆還沒有被花掉的錢，或者說，每一張還沒有被花掉的電子鈔票。這個賬本，有些類似比特幣的 UTXO 賬本，也被稱為基於 token 的或者基於價值的賬本形式，這和傳統的基於賬戶的賬本有所不同，也就是說，在賬本中記錄的不再是一個個賬戶的餘額，而是一筆筆交易。而兩個賬本中轉賬的過程是不一樣的：舉個例子，我們考慮小明想要轉 100 元給小紅。在大家比較熟悉的賬戶模型裡，這個過程是這樣的：1. 小明發出轉賬請求給系統。2. 系統檢查小明賬戶裡有沒有這麼多錢。3. 如果有，那麼從小明的賬戶里扣掉這些錢，然後加到小紅的賬戶上。而在這個基於價值的賬本里：1. 小明將一張 100 元的電子鈔票發給小紅，小紅向系統傳送驗鈔請求。2. 系統檢查 a）這筆交易的數額確實是 100；b）小明透過電子簽名授權了這筆交易；c）這筆錢還沒有被花過。3. 如果檢查透過，則系統銷燬這筆錢，然後發一張新的 100 元電子鈔票給小紅，並登記這張鈔票歸小紅所有。這裡，每筆交易中心都需要完成這樣的驗證步驟。可想而知，如果 DC/EP 得到大規模應用，那麼這個中心繫統的壓力甚至要超過支付寶和微信。而對於央行這樣的機構而言，更明智的選擇是將這些壓力分攤給原本就已經有條件的機構。而這點，我們也能在上文提到的許多相關人士的談話和文章中看出來。其中，在姚前的「基於區塊鏈的全新央行數字貨幣實現方案」的這段話中提到：其中，登記中心記錄 CBDC 及對應使用者身份，完成權屬登記，並記錄流水，完成 CBDC 產生、流通、清點核對及消亡全過程登記。其主要功能元件分為發行登記、確權釋出、確權查詢網站應用、分散式賬本服務幾個部分。發行登記進行 CBDC 的發行、流通、回籠過程及權屬記錄；確權釋出將發行登記的權屬資訊進行脫敏後非同步釋出到 CBDC 確權分散式賬本中；確權查詢網站依託分散式賬本面向公眾提供線上權屬查詢服務；分散式賬本服務保證中央銀行與商業銀行的 CBDC 權屬資訊的一致。通俗來說，可以理解為我們在登記中心利用分散式賬本不可篡改、不可偽造特性，構建了一個「網上驗鈔機」，即 CBDC 確權賬本，對外透過網際網路提供查詢服務。這種設計對當前分散式賬本技術而言，在中央銀行和商業銀行既集中又分散的二元模式下，提供了一種巧妙的應用思路，一方面將核心的發行登記賬本對外界進行隔離和保護，同時利用分散式賬本優勢，提高確權查詢資料和系統的安全性和可信度；另一方面，由於分散式賬本僅用於對外提供查詢訪問，交易處理仍由發行登記系統來完成，以細化原子交易顆粒度的方式來進行交易的分散式計算處理，這樣可以透過業務設計的方式有效規避現有分散式賬本在交易處理上的技術效能瓶頸。顯然，這樣的設計充分發揮了區塊鏈的技術優勢，保障 CBDC 驗鈔的可信，但並未影響中央銀行對 CBDC 的全域性管控。儘管，後來央行在「不預設路線」的表態中表示以上只是一種思路，未必是最終方案，並且央行數字貨幣不預設方案。但是從這個方案中，也能看出對於一箇中心進行交易處理的壓力是需要透過某種方式分攤的。此外，從關於央行數字貨幣意義（而非技術）的另一些談話和文章中看出，DC/EP 的最核心的意義還是巨集觀上降低發行成本，最佳化支付體系和提高貨幣政策有效性。因此，央行希望能夠在必要的時候追溯貨幣的流向，但是這個目的是統計上而並不需要實時性。從這個角度講，更理想的設計是——商業銀行自行完成交易，然後定期（比如每天）與中央銀行賬本彙總。這樣對於央行而言，就僅僅作為數字貨幣發行方和流通的監督方，而由商業銀行負責數字貨幣平時的使用——這點似乎對於商業銀行和中央銀行兩邊都更為有利。於是，很多人會發現——說到頭來，不還是需要所有的節點之間共享一個賬本嗎？於是，這不就還是要用到區塊鏈嗎？而且，這會產生更嚴重的效能瓶頸——原本只有中心需要記錄整個賬本處理所有交易，但現在每個銀行都需要實時處理所有交易了，這並不能達到將壓力分散給商業銀行的目的。實際上，我們不一定要用到真正意義上區塊鏈——區塊鏈考慮的是一個完全無信任的場景，而在 DC/EP 的場景中卻並不是這樣——實際上，2015 年倫敦大學學院提出的央行數字貨幣 RScoin 就描述了這樣一種結構。簡單地說，我們假設每個地址和銀行的對應關係對所有銀行已知。然後，考慮在 A 行的小明想要付 100 元給 B 行的小紅。1. 小明透過 A 行的地址將一張 100 元的電子鈔票發給小紅，小紅向 B 行的系統傳送驗鈔請求。2. 這個時候，B 行系統需要檢查 a）小明（根據地址判斷）是 A 行的使用者；b）小明透過電子簽名授權了這筆交易；c） A 行簽名確認這筆錢還沒有花過，並承諾將這筆錢標記為花過了。3. 如果檢查透過，則 B 行將這筆錢新增到小紅的指定地址，並且發給小紅一個簽字的收據。但這裡有一個問題——B 行要信任 A 行確實驗證了這筆錢存在並且誠實地將其標記並不再雙重支付。而這點，可以透過幾個方法來保證：1. 央行的仲裁：以上的步驟中，在交易的時候小明的客戶端提供了一個證明上有 A 行的簽名，因此如果 A 行有不當行為是可以由小明提供證明向央行申訴的。而同理，如果 B 行行為不當，也可以透過小紅提供證明被央行發現。2. 可以引入冗餘：以犧牲部分效率為前提，讓每個地址由多個銀行（例如 3 個）負責，然後獲得其中多數的簽名才被視為合法。3. 可以引入拜占庭容錯演算法：引入冗餘相當於將多個銀行視為一個只會出現一般錯誤的系統，我們也可以考慮其中有惡意的情況，於是採用拜占庭容錯演算法來保證輸出結果的一致。以上三種做法的實施就很靈活了——對於一些較為可信的機構，可以只用第一種，而對於較為不可信的機構，則可以採用第三種。而另一個可以靈活改動的地方是——其中的三個步驟：1）付款銀行檢查是不是有這筆錢；2）付款銀行將這筆錢標記為花過；3）收款銀行將這筆錢計入，是可以分開考慮的。而在姚前之前那段引文中，我們就看到了這樣的提案——檢查的步驟可以採用拜占庭容錯演算法來保證安全，而其他兩個步驟可以不透過拜占庭容錯演算法進行來保證效率。但這裡需要注意的一點是——即便需要參與驗證的是所有銀行，並且採用拜占庭容錯，這仍舊不是一個傳統意義上的區塊鏈系統，這點我下一節會詳細解釋。然後，在每天結束的時候，央行負責彙總所有的賬本，然後，重新發放新幣給各個使用者的地址。但以上這種做法引來的一個問題是隱私和匿名問題——因為不是每次交易都重新發放貨幣，一天之內貨幣的流動是可以被追蹤到的——這樣可能會導致隱私洩露。因此，可以採用的方法是類似比特幣「非實名」的方法。用同一個賬號生成不同的地址收款和付款，但只有所在銀行和中央銀行可以計算出這些地址屬於同一個人，而其他機構只能看到這些賬號來自同一個銀行。這種方法，可以在匿名性上新增另一層保護。DC/EP 的錢包 / 客戶端首先非常重要的一點——DC/EP 的錢包和如同比特幣一樣的加密貨幣的錢包非常不同！原因是，如上文所述的 DC/EP 的系統不是拜占庭容錯的，甚至不是一般容錯的，即便在交易驗證和錄入的時候採用了拜占庭容錯演算法也並不能使整個系統拜占庭容錯——這也就是為什麼說它不是個區塊鏈的原因。這個系統是完全可能出現單點故障的，而這個單點就在錢包 / 客戶端。上面這套系統的冗餘設定和央行的仲裁機制只能保證在商業銀行和央行這裡不出錯，而對於客戶端，我們的假設是使用者沒有理由去刻意製造不一致——比如小明付錢給小紅的場景，比如為了買東西，小明肯定希望想小紅證明付款成功，於是他有義務給小紅提供一個「我的 100 元是真鈔」的證明，而在提供這個證明的時候，這個錢就已經轉出了。而小紅收到了錢，自然是為了以後去用，那麼她也有動機去把這個證明發給自己擁有的地址所對應的機構，否則這筆錢她以後就花不了。但以上的這些步驟，肯定是會由銀行整合到一個錢包中的。從邏輯上講，商業銀行自然也不會刻意製造不一致，但是隻要是軟體就可能出 bug，而且在現實的網路中，有可能出現丟包或者訊號突然斷開的情況。而實際上，在以上的系統中這個錢包如果出現了問題是很容易引起整個賬本的不一致的。例如在讓所在的銀行開具合法的證明的時候，如果採用了冗餘機制有三個銀行負責驗證，如果客戶端只給其中一個發了合法證明的請求，然後斷網，然後由於系統 bug 在重連之後沒有給另兩個機構發請求，或者由於斷網時候的操作，在重連之後對另兩個賬本請求了不同的交易，那麼就會造成其中一個賬本和其他兩個賬本的不一致。類似這種情況造成的不一致是系統設計之外的，可能會導致非常難以預料和解決的後果。因此，錢包的安全性是至關重要的，因為與比特幣之類的傳統加密貨幣不同，錢包是整個系統安全性的一部分。比特幣的錢包出故障，丟的最多是使用者的錢，而不是影響到比特幣賬本的一致性，但 DC/EP 的錢包如果出了故障，可能會導致整個系統的賬本出錯或者癱瘓。而基於此，就有了接下來的推測：1，DC/EP 是人民幣的數字化，僅此而已——因為從技術路線上，這個系統是封閉的，而且即便到未來也是不可能完全開放的，也就是錢包和賬本都僅僅會開放給少數經過授權的機構才能開發，並且需要經過長時間的測試和授權機構的檢驗和認證——這代表了不可能使用 DCEP 開發 Dapp 或者進行 DeFi 這種金融創新，也不會是所謂的「可程式設計貨幣」，這點與 Libra 的願景以及許多類似的專案和虛擬貨幣相去甚遠。因為開發者最多隻能和用支付寶一樣，呼叫授權錢包給出的轉賬介面，而無法直接向賬本發出請求或者發起交易。2，這個錢包大概就是現在農行內測的重點。由於目前內測範圍僅限農行，我傾向於認為目前階段僅僅考慮央行和農行兩個機構，在驗證的部分也不考慮加入其他機構的冗餘設計。因此，未來能夠加入 DCEP 的，大概率在一開始僅有五大行。3，對於匿名性——由於錢包和銀行賬號繫結，因此採用 A 行錢包轉賬實際上無論從 DCEP 的邏輯上，還是從銀行內部實現的方式上，都應該十分類似於使用銀行賬戶進行轉賬，但兩者並不一定繫結在一起，也就是所謂的「松耦合」的概念。4，在技術上，DCEP 提供了框架，但是對於央行來說實際上重要的是：1，貨幣以中心賬本登記的為準，商業銀行僅是代管，賬本需定期向中央銀行彙總；2，商業銀行內部可以採用任何技術，例如賬本上重新建一個資料庫也好，採用已有的賬戶也好，交易驗證完全中心化靠信用背書也好，相互之間採用區塊鏈技術來提升溝通效率或者安全性也好都沒問題，央行歡迎你們嘗試各種技術，但是，彙總到總帳本的格式需要一致，資料要可靠，而且最終的賬本還是以央行彙總的為準。雙離線支付DC/EP 的一個與現在的支付寶 / 微信支付的一個重大不同是雙離線支付，其中一個被用來舉例的場景就是在連線狀態下，兩臺手機互相碰一碰就完成支付。其中，兩臺手機互相碰一碰的部分可以透過藍芽或者 NFC 進行資訊互換，但核心的雙離線的方式，根據數字貨幣研究所所申請的專利，可能會需要用到可信硬體。具體方法是：在支援 TEE （可信執行環境）的手機裡，規定離線支付需要透過 TEE 進行簽名並且檢查沒有進行過雙重支付，這個時候雙離線支付的安全性實際上交給支援 TEE 晶片的生產商進行擔保。這樣，首先破壞 TEE 的技術難度較大成本較高，其次，手機晶片也是實名的，如果 TEE 晶片安全性被破壞，則可以追責並且可以將該裝置列入黑名單。但根據專利中的內容來看，雙離線支付應該只適用於臨時和小額的場景，收到的錢需要透過上線同步到賬本之後才能再次使用——這點其實並不難理解，因為如果離線收到的錢可以一直在離線狀態使用，相當於同時存在了兩個賬本，或者說兩種數字貨幣。一種線上的數字貨幣安全性由央行擔保，而另一種離線的數字貨幣的安全性由各個 TEE 晶片生產商擔保。這不符合 DC/EP 的邏輯。而如果僅僅將雙離線支付作為一個臨時的手段的話，那麼 TEE 僅僅作為一個離線狀態下小額資金的一個臨時託管方，這樣即便 TEE 的安全性被破壞，也不對 DC/EP 的安全性造成影響，央行也在要求 TEE 的生產方補償損失的時候也更容易計算。然而，其實以上的邏輯不需要 TEE 也可以實現，比如把 TEE 換成一個實名的和手機繫結的銀行客戶端——這個客戶端在程式碼中寫死以上的邏輯，然後，如果發現客戶端被修改導致了資料錯誤，就把繫結的手機寫上黑名單並對持有者追責。實際上兩者的效果是一樣的，區別就在於 TEE 的安全性更高一些而已。但是，從邏輯上來講，雙離線支付單純透過錢包也是可以實現的——畢竟，按照之前的設計，從央行的角度講，所有當日的交易在未寫入總帳本之前都屬於銀行代管，本身就依託於雙方銀行的信用，而如果錢包軟體也由雙方銀行提供，那麼由錢包軟體暫時託管貨幣也相當於雙方銀行對貨幣的安全性負責。DCEP 的基本結構透過以上分析，我推測 DCEP 的基本結構如下：
其中，中央銀行擁有一個 DC/EP 的總帳本，賬本採用基於價值 / 基於代幣的結構，記錄所有已發行數字貨幣的使用和回收情況。如果正在流通，則記錄其當前所有者以及所在銀行。每隔一段時間（例如每天），央行從商業銀行和其他可信機構那裡透過中心化的方式彙總而成當日的賬本，然後進行檢查和比對，對於賬本出現不一致的情況，中央銀行擁有仲裁權。然後，對於所有還沒有在央行登記的交易（當日的交易），央行在總帳本上進行登記並收回已經使用過的貨幣，並將等額的新的匿名貨幣發給相應的地址。最後，將新的當日流通貨幣的編碼釋出給所有驗證機構。
同時中央銀行負責管理一個身份資料庫，記錄所有地址對應的身份。這個身份資料庫既不對內也不對外公開，僅僅在涉及犯罪行為的時候才可以查閱相關人員的地址資訊。
此外，中央銀行管理一個查詢介面和一個交易錄入介面，前者可供公開驗證（當日）賬本的正確性和完整性，和對每一筆貨幣進行有限的追溯（不過是非實名的地址），後者僅供認證的錢包接入用於更新交易賬本。商業銀行各自維護自己當日的賬本（總帳本不做要求，因為央行那裡有總帳本），要求保持安全性和可用性。這裡，這個賬本可能是該機構使用者的賬本，也可能包括該機構之外其他機構的賬本（冗餘設計）。但是賬本及整個圖中藍色方框部分都只有地址資訊，沒有使用者資訊。這部分賬本是匿名的——每筆交易除了當事人，涉及到的銀行，錢包提供方以外，沒人能夠從交易中得出任何關於交易雙方或者當日之前資金來源的資訊。
央行授權商業銀行或者其他可信機構開發錢包，並且需要透過認證和驗收。只有透過錢包可以獲得 DC/EP 和進行交易。這裡，DC/EP 的錢包是整個系統的重要部分，因此並不能任意開放給第三方。
對於使用者而言，在使用 DC/EP 的時候，可以將整個 DC/EP （綠色部分）看作黑盒子，僅僅透過錢包互動。但也可以透過第三方呼叫查詢介面查閱賬本和驗證自己的交易記錄是否和錢包提供的相符。在隱私方面，錢包是實名的，因此錢包提供方會在央行的監督下管理使用者資訊。使用者在註冊錢包的時候需要把個人資訊透過錢包存入身份資料庫。
於是，如果小明想要透過 A 行的錢包和 A 行的地址向 B 行的小紅髮一張 100 元的數字貨幣（簡便起見，我們考慮面對面付款），有如下的交易流程：
1. 小明與小紅使用的錢包間透過二維碼或者 NFC 通訊，獲知小紅在 B 行的一個收款地址。
2. 小明的錢包選擇一張在小明未花費過的在 A 行的地址，向交易介面釋出交易請求。
3. 交易介面按照索引找到該地址對應的 A 行（以及如果有冗餘設計的話的其他行），然後要求他們證明這張貨幣可用（在央行公佈的當前流通貨幣列表中，並且未被標註使用）。
4. 以上的記賬機構透過某演算法 a 返回可用證明並宣告已標記為使用。
5. 小明的錢包收到返回的證明之後，將證明與交易發給小紅的錢包。
6. 小紅的錢包向交易記錄介面提交交易，然後交易驗證介面根據索引找到相應的地址對應的 B 行。
7. 對應的機構根據演算法 b 將交易加入 B 行（以及如果有冗餘設計的話的其他行）的賬本，並返回一個交易已經加入賬本的證明發給小紅。
8. 交易完成。
這裡，如果僅涉及單個機構，演算法 a 和演算法 b 可以是簡單的讀寫，當涉及到多個機構的時候，可以是一般容錯演算法，也可以是拜占庭容錯演算法。
在賬本彙總中，如果出現不一致，中央銀行有裁決權。如果結果出現問題，使用者可以透過手中的證據向中央銀行要求遺失的錢，然後中央銀行可以根據證據調查流程中的過失責任方。
雙離線支付並沒有包含在這個流程中，但可以很容易看出來，雙離線支付的邏輯應該內嵌在錢包軟體裡，在斷網的時候觸發。於是，這筆交易不會傳遞到賬本，僅僅透過錢包軟體記錄交換資訊完成，暫時記錄在硬體中，並由 TEE 提供商（晶片製造商）或者是錢包提供方擔保交易完成，然後再聯網之後同步到賬本里。
這個結構其實也可以與姚前提的「一幣、兩庫、三中心」的說法對應起來，原文是：
筆者曾提出「一幣、兩庫、三中心」的央行數字貨幣體系。「一幣」即央行數字貨幣，是由央行擔保並簽名發行的代表具體金額的加密數字串。「兩庫」指數字貨幣發行庫和數字貨幣商業銀行庫，前者是中央銀行在 CBDC 私有云上存放 CBDC 發行基金的資料庫，按照中央銀行的現金運營管理體系進行管理，後者是商業銀行存放 CBDC 的資料庫，可以在商業銀行的資料中心也可以在 CBDC 私有云上，遵循商業銀行現金運營管理規範。「三中心」則包括認證中心、登記中心和大資料分析中心。
其中，登記中心記錄 CBDC 及對應使用者身份，完成權屬登記，並記錄流水，完成 CBDC 產生、流通、清點核對及消亡全過程登記。其主要功能元件分為發行登記、確權釋出、確權查詢網站應用、分散式賬本服務幾個部分。發行登記進行 CBDC 的發行、流通、回籠過程及權屬記錄；確權釋出將發行登記的權屬資訊進行脫敏後非同步釋出到 CBDC 確權分散式賬本中；確權查詢網站依託分散式賬本面向公眾提供線上權屬查詢服務；分散式賬本服務保證中央銀行與商業銀行的 CBDC 權屬資訊的一致。
通俗來說，可以理解為我們在登記中心利用分散式賬本不可篡改、不可偽造特性，構建了一個「網上驗鈔機」，即 CBDC 確權賬本，對外透過網際網路提供查詢服務。這種設計對當前分散式賬本技術而言，在中央銀行和商業銀行既集中又分散的二元模式下，提供了一種巧妙的應用思路，一方面將核心的發行登記賬本對外界進行隔離和保護，同時利用分散式賬本優勢，提高確權查詢資料和系統的安全性和可信度；另一方面，由於分散式賬本僅用於對外提供查詢訪問，交易處理仍由發行登記系統來完成，以細化原子交易顆粒度的方式來進行交易的分散式計算處理，這樣可以透過業務設計的方式有效規避現有分散式賬本在交易處理上的技術效能瓶頸。顯然，這樣的設計充分發揮了區塊鏈的技術優勢，保障 CBDC 驗鈔的可信，但並未影響中央銀行對 CBDC 的全域性管控。
尤其是，這種雙賬本包容性設計，既延續了傳統技術的成熟穩定性，又為新的分散式賬本技術留有空間，使得兩種分散式技術相互相容、並行不悖、優勢互補，並在演進過程中，競爭擇優。
這裡，一幣自然指的是 DC/EP，兩庫即是中央銀行賬本和商業銀行的賬本，前者放在央行的私有云上，後者既可以放在央行的私有云上，也可以放在商業銀行資料庫裡。然後，登記中心即為查詢介面接入之後的系統，而認證中心就是交易錄入系統接入之後的系統，大資料中心是一個單獨的介面，在圖上沒有畫出來。兩個介面可以採用不同的共識演算法，也就是之前交易流程中的演算法 a 和演算法 b，按照姚前的說法，演算法 a 可以採用拜占庭容錯演算法保證安全性，而演算法 b 可以用一般容錯演算法來保證效率。
總結
筆者的專業是區塊鏈共識演算法而非金融，對於央行數字貨幣的瞭解僅限新聞、公開資料和部分其他人對於 DC/EP 的解讀，因此本文純屬從技術角度做出的推測，主要有：
1. DC/EP 的匿名性採用了類似 Ecash 的結構，但是用中心替代了盲簽名，匿名主要體現每個「數字貨幣」對於所有除了使用者和央行之外的機構都是同質且匿名的。
2. DC/EP 的主體架構不是區塊鏈，但是可能採用了類似 RScoin 的框架。下屬商業銀行可以採用已有的基礎設施來處理交易，也可以用區塊鏈或者其他技術來實現跨行轉賬，只要保證每天彙總給央行總帳的賬本可靠就行。
3. 如果採用了類似 RScoin 的結構，實際上 DC/EP 的錢包在保證賬本一致性中起到了很重要的作用，因此 DC/EP 應該會是一個相對封閉和功能單一的系統，也就是僅有數字貨幣的功能，並且賬本僅對認證的錢包開放。
4. 雙離線認證僅僅作為一個臨時的支付手段，可以基於 TEE，或者僅僅基於軟體，然後靠事後追責的方式實現。
5. 最早推出的 DC/EP 可能是個最小可行性版本，也就是上圖中僅留下商業銀行 1 和該商業銀行推出的錢包。
6. DC/EP 沒有考慮過跨境支付場景，如果需要跨境支付可以透過下屬機構建立相關設施。
最後，以上純屬推測，對於於實施的偏差筆者不負任何責任，如轉載請全文轉載以防造成誤讀。
本文連結：https://www.8btc.com/article/586343
轉載請註明文章出處
