分散式賬本 Corda

bluepeach發表於2021-09-09

最近在專案中用到了分散式賬本 Corda,本文介紹一下 Corda 的基本概念和程式設計模型。

Corda 是區塊鏈嗎?

Corda 開發文件的第一句話是這麼寫的:

is a blockchain-inspired open source distributed ledger platform.

翻譯:“Corda 是受區塊鏈啟發的開源分散式賬本平臺。”

在 Corda 究竟是不是區塊鏈技術這件事情上存在爭議,原因是與比特幣,以太坊等典型區塊鏈平臺相比,Corda 捨棄了每一個節點都要驗證和記錄每一筆交易的賬本全網廣播模式,僅僅要求每一筆交易的參與方對交易進行驗證和記錄:

圖片描述

圖中,在 Alice 和 Bob 之間發生了 fact 1,那麼只有 Alice 和 Bob 需要驗證 fact 1 的合法性,並且記錄下來,Carl,Demi 和 Ed 對相關資訊一無所知。

這樣做的好處主要是解決了分散式賬本技術在商業化應用中非常敏感的兩個問題:

  • 極大地提高了交易的吞吐能力;

  • 避開了共享賬本能否保證交易資料私密的爭議。

同時也帶來了問題,即如何避免“雙花”。在比特幣和以太坊等區塊鏈平臺上,由於每個節點都擁有整個賬本的複製,所以要解決雙花問題很容易。Corda 為解決雙花問題,引入了 notary 機制,簡單來說就是在 notary 節點之間形成更廣泛的共識,而 Corda 上的每一筆交易都需要透過至少一個 notary 節點的驗證。

回到開始的問題,Corda 是區塊鏈嗎?其實這個問題的答案並不重要,重要的是 Corda 使用了分散式賬本技術,並且做了針對性的改良,使 Corda 非常適用於企業對企業的交易應用場景。

Corda 的程式設計模型

接下來講一下 Corda 開發當中的幾個核心概念——state,transaction,contract,flow。

1. State

1.1. State 的資料結構

簡單來說 state 就是不可篡改的鏈上資料,一個 state 的資料結構如下圖所示:


圖片描述


圖中主要有3個部分:

  1. 右邊是資料本身,例如圖中描述了 Alice 欠 Bob 的10美元的情況;

  2. 左上是這條資料所關聯的 contract,這部分會在 中詳細介紹;

  3. 左下是 participants,這是 Corda 當中特別重要以及特別需要設計的一個概念,上文提到 Corda 不會在每個節點上記錄每筆交易,participants 表示哪些節點需要記錄這條 state 資料,同時也意味著哪些節點能夠看到併發起對相應 state 資料的修改。

State 是不可篡改的,當真實世界中的事實發生變化時,Corda 會將已經成為歷史的 state 標記為 consumed。


圖片描述

2. Transaction

Transaction 表示一筆交易,交易由所有發生變化的 state,造成 state 變化的 command,交易參與方的簽名,時間戳以及交易相關附件組成。


圖片描述


上文中我們提到儲存在鏈上的資料是 state,但是實際上真正儲存在鏈上的原始資料是這一筆筆 transaction。State 是 transaction play 的結果。

3. Contract

Contract 用來驗證 transaction。一筆交易一定發生在多個不同的對手方之間,通常來講一筆交易由一方構建,另外的參與方驗證交易有效。所以交易構建方要在 state 上指明這筆交易是透過哪個 contract 的哪個 command 生成的。驗證方透過呼叫對應 contract 上的 verify 方法驗證交易有效。


圖片描述


通常來講一筆交易要驗證的部分包括交易參與方的簽名,以及 state 的轉化是否是合理兩個部分。

4. Flow

剛才提到一筆交易由一方構建,其餘參與方驗證並簽字。在 Corda 中,我們用 flow 來管理這個過程:


圖片描述


圖中 initiator 和 responder 分別是交易雙方執行的 flow,雙方的互動透過 flow 來控制。Corda 還把很多有用的小步驟封裝成了 flow,以便開發者呼叫,比如 CollectSignaturesFlow。

傳統交付模式在區塊鏈交付中面臨的挑戰

Trust, but VERIFY

Verify 是區塊鏈開發中非常重要的一個部分。上面我們提到在 Corda 的程式設計模型中由一方構建交易,其他參與方驗證交易的模式。那麼驗證是否足夠健壯就成為了開發過程當中很重要的一環,每一個合約安全漏洞,都會造成數額巨大的直接經濟損失。

另一方面,對 verify 邏輯的驗證又很難融入到我們的傳統開發流程中。在傳統開發中,我們以功能開發為主,安全往往是被我們放在第二優先順序的需求。但是在區塊鏈開發中,即便我們完全不進行 verify,功能也可以正常完成。所以 verify 邏輯是否足夠健壯就完全成為了開發人員自己的事情。

為了解決這個問題,業界提出了用"形式化證明"的方式來驗證智慧合約的安全性,目前已經有大量創業公司投入在這個方向上,預計未來將會出現一些智慧合約驗證工具出現在區塊鏈開發的工具鏈上。

區塊鏈和 DevOps

區塊鏈開發面臨的另一個挑戰是 DevOps。以往 DevOps 的目標是將程式部署在一個環境裡,不管這個環境是資料中心,還是雲端。在區塊鏈開發中,我們希望不同的節點部署在不同參與方的環境中。

例如,A 可能希望部署一個節點在他們的 AWS 環境上,B 希望部署在他們的資料中心裡,C 希望部署在 Aliyun 環境上,如何快速地將這些環境打通並形成 P2P 網路就成了一個問題。這個問題並不難以解決,但是還遠遠談不上可以高效解決。未來也可能會出現一批針對區塊鏈開發的 DevOps 工具幫助我們解決這些問題。



作者:曲小哲
連結:


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/2558/viewspace-2811986/,如需轉載,請註明出處,否則將追究法律責任。

相關文章