R3 Corda 的設計思路全面解析
Corda 是怎麼設計的？為什麼能普遍獲得金融業的接受，迅速發展應用案例？
前言
Corda 是一個為企業打造的分散式帳本（Distributed Ledger），由 R3 開發、維護並於 2016 年正式開源，是與企業以太坊和 Hyperledger Fabric 齊名的知名聯盟鏈。Corda 相當獨特 — — 首先，它的設計思路與其他兩者相當不同，例如它使用的是「未花費交易輸出」（Unspent Transaction Output, UTXO）模型而非「帳戶模型」（Account Model）；其次，Corda 也有截然不同的目標：「易於監管、注重脈絡、反映現實」 是它的設計哲學。
究竟 Corda 是怎麼設計的？又為什麼會這樣設計？在本文中，筆者將會簡述 Corda 的運作流程，並探討 Corda 的設計思路與設計哲學，同時介紹 Corda 獨具的「可監管性」。
筆者所在的公司 BSOS，為 Corda 官方技術夥伴，具開發 Corda 的實務經驗。為了與下文所提及的技術做出區分，筆者暫且把起源於比特幣／以太坊的區塊鏈技術體系稱為「中本區塊鏈」（Nakamoto Blockchain）。
*特別感謝 Daniel Huang 的修訂與回饋
Corda 的起源
Corda 是針對金融業協作效率，進行升級改進的一種技術方案。相對於中本區塊鏈「建立去中心化金融體系」這樣橫空出世又帶有密碼龐克（Cypherpunk）色彩的激進方案，它顯得溫和平穩地多。R3 認為當今的金融業之間的協作模式不僅缺乏效率，而且成本高昂 — — 原因是每個銀行都各自維護自己的帳本，為了追求嚴謹，彼此驗證帳本是個耗資費時的工作；不僅如此，每個不同的協作場景都需要重複一遍驗證流程，這也讓協作變得沒有效率。對此，R3 提出的解決思路很直觀：把帳本從銀行「之內」，放到銀行「之間」，讓銀行共同維護一份帳本，並降低建立信任的成本。
簡單來說，Corda 可以讓兩家甚至多家銀行能夠共享同一個帳本，形成對帳本的「共識」，並且能彼此驗證帳本內容，降低信任成本。那麼該如何降低成本呢？降低成本幾乎可以等同於降低人為因素，讓過程自動化。Corda 能夠讓帳本依照雙方事先締結的「合約」與「流程」自動化地執行交易。
在金融業協作的大背景之下，Corda 的設計除了受到中本區塊鏈很大的啟發，亦注重「易於監管、注重脈絡、反映現實」的設計哲學，這賦予 Corda 一個很鮮明的立場。以中本區塊鏈為基底，Corda 在帳本、共識與合約的設計上都發展出獨具特色的架構。在本文中，筆者將針對這三者的設計思路進行更詳細的說明。
在此之前，我們先來看一下 Corda 的基本組件與運作流程。
Corda 概觀
Corda 是一個對等網路（Peer-to-peer Network），參與節點（Participant）—— 或簡稱 Corda 節點，是 Corda 網路的主要成員，它們可以依照場景自由組成不同的商業網路（Business Network）。
除了 Corda 節點，還有一些必要的服務節點，例如負責檢查交易雙花（Double Spending）的公證服務；負責身份與權限控管的身份服務（Idneitity Service）；負責節點查詢的網路映射服務（Network Map Service）；以及負責引入真實世界資訊的預言機（Oracle）。
Corda 節點
Corda 節點的架構如上圖，其中包含：服務節點所需的模組，例如公證模組與身份模組；與交易執行與儲存相關的模組，例如 Java 虛擬機（JVM）、交易資料庫（Rows）與金庫（Vault）；以及一個或多個運行於 Corda 之上的分散式應用程式：CorDapp。
Corda 節點內的「金庫」與開源專案 Hashicorp Vault 是不同的東西
CorDapp 簡介
CorDapp 是運行於 Corda 之上的分散式應用程式，所有的 Corda 節點皆需透過 CorDapp 來發出交易、形成共識、以及更新帳本。
概念上來說，CorDapp 是對業務邏輯的封裝，這使複雜的金融業務能夠比較容易地在不同機構之間重現或轉移。Corda 節點也可以同時運行多個 CorDapp，同時參與不同協作場景。
具體來說，這些業務邏輯指的是「流程」、「狀態」與「合約」：
- 流程（Flow）：每個 CorDapp 皆會對應一個唯一的、由開發者依實際需求制定的「流程」，通常與業務流程相關，它是在交易的發起者（Initiator）與回應者（Responder）之間從發起交易到確認交易所需的步驟集合，類似於協定（Protocol）。特別的是，「公證服務」的身份也是在流程中被指定。
- 狀態（State）：每個 CorDapp 都有「狀態」，以表達比單純的帳戶餘額更豐富的資訊。然而這裡的狀態僅定義了交易的狀態「格式」，其本身並不實際保存數值，只有在發起交易時才會依照此格式將實際「數值」記錄到交易上。
- 合約（Contract）：每個 CorDapp 的「狀態」皆會對應一份「合約」，它是一組驗證交易有效性的約束規則集合 —— 也就是真實世界對「合約」的定義。值得一提的是，CorDapp 「合約」與中本區塊鏈的「智能合約」是兩個截然不同的概念 。
實作上來說，CorDapp 是一個 JAR 檔，其內包裝了 Java 類別，並運行於 JVM。上述的「流程」、「狀態」與「合約」皆各有其相應的 Java 類別，Corda 官方也提供了基本的模板讓開發者能於其上開發 CorDapp。
Corda 交易的四大階段
儘管 CorDapp 可以設計「流程」以因應不同的業務邏輯，交易流程的大致上仍可以分為四大階段：
- 發起交易：發起者根據 CorDapp「狀態」與「輸入」求出新狀態的值；接著產生帶有新狀態的交易並對其簽章；
- 驗證交易：回應者根據交易指向的「合約」進行驗證，若交易有效則對交易簽章，關於「合約」的功能將在下文詳述；
- 公證交易：由指定的「公證服務」再次驗證交易，若交易有效則「公證服務」會對交易簽章；
- 更新帳本：發起者、回應者檢驗交易是否附有「公證服務」的簽章，若有則更新帳本。
值得注意的是：Corda 交易僅在交易雙方驗證、執行，交易內容也不會廣播給所有節點，這樣的交易流程更符合在真實世界發生的交易流程，這有別於中本區塊鏈的「排序 — 執行」共識模型；另一方面，Corda 對維護帳本共識採取的作法也與中本區塊鏈截然不同 — — Corda 無需維護全局唯一的交易順序、也不以去中心化的範式決定「記帳權」，它僅需維護所有節點對交易「獨一性」（Uniqueness）的共識，而這個工作可以透過一個能觀測全局的「公證服務」來完成。關於共識與「公證服務」的細節，筆者將於下文詳述。
接下來，我們就來深入探討 Corda 的設計思路。
Corda 的設計思路
如前言所述，Corda 是受中本區塊鏈啟發的技術，究竟在「帳本」、「共識」與「合約」的設計上，它向中本區塊鏈借鏡了什麼？又發明了什麼？
1. 帳本：擴充 UTXO，並將帳本「局部化」
「未花費交易輸出」（Unspent Transaction Output, UTXO）是一個經典的發明，也是比特幣使用的模型。相對於帳戶模型（Account Model），UTXO 的狀態並不集中在一個單一的巨大樹狀資料結構 —— 或稱為「世界狀態」（World State），而是分散地被記錄在每一筆交易中。
在 UTXO 模型中，每個交易都會有「輸入」與「輸出」：
輸出即是新的狀態；輸入則是其他交易的輸出。
例如上圖中，右側的交易「TRANSACTION Hash=1ba0ce7a71…」具有兩個「輸入」，分別對應左側交易「TRANSACTION Hash=95fd065cb0…」的第二個「輸出」與左側交易「TRANSACTION Hash=0dbfcf6665…」的第一個「輸出」。
輸出具有兩種狀態：「已花費」（Spent）與「未花費」（Unspent）。若某「輸出」已被其他交易當成「輸入」，則該「輸出」就是「已花費」的，同時不能再次作為其他交易的「輸入」。UTXO 模型中必須防止「雙重花費」（Double Spending），以保證帳本的安全性。
UTXO 模型能夠表現狀態演變的完整歷程，讓每個過程都清清楚楚，這樣的特性對注重原始單據的金融業來說更加適合。同時， UTXO 模型之下的交易順序是自然確立的，這也有利於更輕量的共識機制設計。
Corda 也在 UTXO 的基礎之上進行諸多擴充，例如引入「指令」（Command）與「附件」（Attachment）的設計等等，以上再搭配 CorDapp 的「狀態」，豐富了 UTXO 的表達能力，以實現更複雜的價值轉移。值得一提的是，「附件」可以是具有效力的合約法律文本，即使出現非預期的交易結果，也能依循實際合約的文本採取後續行動。
UTXO 模型之下的帳本即為由所有交易組成的有向無環圖（DAG）之邊緣（Edge）的狀態集合。如概觀所述，Corda 的交易只會由相關各方保存，並不會被廣播至全網，因此 Corda 節點維護的是一個僅與自身相關的「局部」帳本，而非帶有所有交易的「全局」帳本，如上圖所示：Alice 的帳本有交易 2、6、5、4、1；而 Bob 的帳本僅有交易 2、6。這樣的結果是所有：交易都不再被所有節點驗證，因此任何節點只能自行獲取及驗證與該交易與該交易上游的所有交易，一路追朔到源頭。事實上，這種「惰性驗證」（Lazy Validation）的範式對整個網路的算力來說是比較輕量的。
2. 共識：無需「區塊鏈」，使用更輕量的共識機制
Corda 是一個分散式帳本，它同樣需要維護「共識」以確保帳本運作，它把共識的兩種屬性：有效性與獨一性，分別交由不同的機制來維護。
交易的有效性由交易相關各方確保；交易的獨一性由「公證服務」驗證，而這兩者其實都未必要使用區塊鏈，為什麼呢？首先，「公證服務」是相對中心化的設計，無需藉由區塊輔助記帳權的決定過程；其次，由於 UTXO 模型的交易順序是自然確立的，因此共識的形成無需考慮交易的全局排序，也就無需利用區塊來確立順序。
「公證服務」藉由保存多個來自不同節點的交易來檢查交易是否有被「雙花」（Double Spending）以確認交易的「獨一性」。公證服務皆具有實名制的身份，只有具足夠公信力的公證服務會被指定。每個交易即將被送往的公證服務都是被直接指定的，這裡沒有如「工作證明」這般的賽局。
事實上，雖然這種公證的作法與現今的商業運作邏輯相去不遠，然而與現有的作法相比，公證服務還具有以下兩點特性：
- 所有操作皆為自動化執行，並且公開透明；
- 公證服務可以是由不同組織組成的叢集，每個公證節點先各別驗證再透過拜占庭容錯（BFT）或故障容錯（CFT）的共識演算法形成共識，彼此監督制衡。
3. 合約：需與「流程」搭配以實現可程式化的價值
Corda 合約正如同我們在真實世界已然習慣的各種合約 — — 它們提供的是板上釘釘的、用來檢驗「狀態」的規範，而違背合約的交易將會是無效的。
舉例來說，租屋時的「租賃契約」具有房屋狀態的規範，例如牆壁不能打洞、傢俱保持完整等等。若是違反契約，則租屋的交易就會無效化，輕則直接終止租賃交易，重則必須承擔違約罰金。
Corda 合約與真實世界合約的映射關係緊扣「反映現實」的設計哲學，非常便於將原本在金融業已運行多年的各種合約照搬到 Corda 上面。
如果拿 「Corda 合約」跟「以太坊智能合約」做概念上的比較，我們會得到下面的結果：
也就是說，Corda 的「合約」與中本區塊鏈的「智能合約」並非同等的概念，它們具有不同的目的與功能：
- 智能合約：是可執行的程式碼，其中含有多個可呼叫的函式，且具有價值轉移的能力，實現「可程式化的價值」（Programmable Value），把中本區塊鏈變成一個通用計算平台；
- Corda 合約：是映射於帳本的真實世界規範，更貼近合約的原始定義。它雖然同是可執行的程式碼，但是僅有一個事先制定好的介面，除了驗證交易之外，沒有其他功能。
儘管「Corda 合約」本身的表達力有限，Corda 仍可以透過「流程」與「交易」的設計來實現「可程式化的價值」，例如把多個交易串成「流程」。關於實作細節，官方文件有提供詳細的範例，筆者就暫不贅述。
讓 Corda 更易監管的設計：觀察節點與緊急通道
與其他兩大聯盟鏈相比，為金融業而生的 Corda 可以說是最了解監管、也最易於監管的分散式帳本。從整合公鑰基礎設施（PKI）以便於控管與追蹤的節點實名制，到能顯示完整狀態歷程與交易脈絡的 UTXO 模型，都相當適合利用在監管的執行。
除此之外，Corda 有一些特別的設計，能讓監管更積極介入：
- 觀察節點（Observer）：「觀察節點」是可以觀察交易過程的特殊節點。雖然 Corda 只允許交易相關各方保存交易資料，但是不實際參與交易的「觀察節點」卻可以獲取其觀察對象的交易內容。
- 緊急通道（Emergency Access）：Corda 還具有「緊急通道」這樣的機制作為特殊情況的逃生門，讓某些「特殊節點」可以進行如：暫停交易、修正錯誤交易等等的操作。雖然它看起來有點違反分散式帳本本身的定義，但對於 Corda 所要處理的金融業場景來說，大概有其必要性。
結語
在這篇文章中，筆者對 Corda 的設計思路進行了全面解析：它擴充 UTXO，並將帳本「局部化」；它無需「區塊鏈」，使用更輕量的共識機制；它同樣可以實現「可程式化的價值」。
有趣的是，在其他分散式帳本中也能發現類似 Corda 的設計。例如：Holochain 同樣僅透過交易相關各方驗證交易。這些在中本區塊鏈之外的技術居然可以彼此參照、相互補足，讓我們對分散式帳本技術有更完整的認識。
