應用程序開發 - 流程和數據設計
本主題向你展示如何在 PaperNet 中設計商業票據流程及其相關的數據結構。我們的分析強調，使用狀態和交易對 PaperNet 進行建模可以提供一種精確的方式來了解正在發生的事情。現在，我們將詳細說明這兩個緊密相關的概念，以幫助我們隨后設計 PaperNet 的智能合約和應用程序。
1. 生命周期
如我們所見，在處理商業票據時，有兩個重要的概念與我們有關。狀態和交易。確實，對于所有區塊鏈用例都是如此。有一些以狀態為模型的值概念對象，其生命周期轉換由交易描述。對狀態和交易進行有效分析是成功實現的重要起點。
我們可以使用狀態轉換圖來表示商業票據的生命周期：
商業票據的狀態轉換圖。商業票據通過發行，購買和贖回交易在發行，交易和贖回狀態之間轉換。
查看狀態圖如何描述商業票據如何隨時間變化，以及特定交易如何控制生命周期轉換。在 Hyperledger Fabric 中，智能合約實現了交易邏輯，可以在不同狀態之間轉換商業票據。商業票據狀態實際上是在帳本世界狀態中保存的；因此，讓我們仔細看看它們。
2. 賬本狀態
回憶一下商業票據的結構：
商業票據可以表示為一組屬性，每個屬性都有一個值。通常，這些屬性的某種組合將為每張票據提供唯一的鍵。
查看商業票據 Paper 屬性的值是 00001，Face value 屬性的值是 5M USD。最重要的是，當前狀態屬性指示商業票據是已發行，交易還是已贖回。結合起來，全套屬性構成了商業票據的狀態。而且，這些單獨的商業票據狀態的整個集合構成了帳本 世界狀態。
所有帳本都共享此形式；每個都有一組屬性，每個屬性都有不同的值。狀態的這種多屬性方面是一個強大的功能 – 它使我們可以將 Fabric 狀態視為向量而不是簡單的標量。然后，我們將有關整個對象的事實表示為單獨的狀態，隨后這些狀態會受到交易邏輯控制的轉換。Fabric 狀態被實現為鍵/值對，其中值以捕獲對象的多個屬性 (通常為 JSON) 的格式對對象屬性進行編碼。帳本數據庫 可以支持針對這些屬性的高級查詢操作，這對于復雜的對象檢索非常有幫助。
查看 MagnetoCorp 的票據 00001 如何表示為狀態向量，該狀態向量會根據不同的交易驅動而轉變：
商業票據狀態由于不同的交易而存在并轉變。Hyperledger Fabric 狀態具有多個屬性，使其成為向量而不是標量。
請注意，每張票據都是從空狀態開始的，從技術上講，它是零狀態，因為它不存在！了解發行交易如何使票據 00001 產生，以及隨后由于購買和贖回交易而對其進行更新。
注意每個狀態如何自我描述；每個屬性都有一個名稱和一個值。盡管目前我們所有的商業票據都具有相同的屬性，但并非總是如此，因為 Hyperledger Fabric 支持具有不同屬性的不同狀態。這允許同一帳本世界狀態包含同一資產的不同形式以及不同類型的資產。它還可以更新狀態的結構；想象一個需要附加數據字段的新規則。靈活的狀態屬性支持隨時間推移數據演變的基本要求。
3. 狀態鍵
在大多數實際應用中，狀態將具有屬性的組合，這些屬性可以在給定的上下文中唯一地標識它 - 這是關鍵。 PaperNet 商業票據的鍵是由 Issuer 和 paper 屬性的串聯形成的。因此對于 MagnetoCorp 的第一份票據，是 MagnetoCorp00001。
狀態鍵使我們能夠唯一地識別票據。它是通過發行交易創建的，隨后通過購買和贖回進行更新。 Hyperledger Fabric 要求賬本中的每個狀態都有唯一的鍵。
如果在可用屬性集中沒有唯一鍵，則將應用程序確定的唯一鍵指定為創建狀態的交易的輸入。此唯一鍵通常帶有某種形式的 UUID，盡管可讀性較差，但它是標準做法。重要的是，帳本中的每個狀態對象都必須具有唯一的鍵。
注意：應避免在鍵中使用 U+0000 (無字節)。
4. 多狀態
如我們所見，PaperNet 中的商業票據作為狀態向量存儲在帳本中。能夠從賬本查詢不同的商業票據是一項合理的要求；例如：查找由 MagnetoCorp 發布的所有票據，或：查找處于贖回狀態的 MagnetoCorp 發布的所有票據。
為了使這些搜索任務成為可能，將所有相關票據歸為一個邏輯列表會很有幫助。PaperNet 的設計結合了商業票據清單的概念 – 一個邏輯容器，每當發行商業票據或進行其他更改時，邏輯容器都會更新。
4.1 邏輯表示
將所有 PaperNet 商業票據都放在一個商業票據列表中會很有幫助：
MagnetoCorp 新創建的商業票據 00004 已添加到現有商業票據列表中。
發行交易可以將新票據添加到列表中，并且可以使用購買或贖回交易來更新列表中已有的票據。查看列表如何使用描述性名稱：org.papernet.papers；使用這種 DNS 名稱是一個非常好的主意，因為精心選擇的名稱將使你的區塊鏈設計對其他人來說很直觀。這個想法同樣適用于 智能合約名稱。
4.2 物理表示
雖然在 PaperNet 中只考慮一個文件列表是 org.papernet.papers 是正確的，但最好將列表實現為一組單獨的 Fabric 狀態，其組合鍵將狀態與其列表相關聯。這樣，每個狀態的組合鍵都是唯一的，并支持有效的列表查詢。
將 PaperNet 商業票據的列表表示為一組不同的 Hyperledger Fabric 狀態。
請注意，列表中的每篇票據如何用向量狀態表示，并具有由 org.papernet.paper，Issuer 和 Paper 屬性串聯而成的唯一復合鍵。此結構很有用，其原因有兩個：
- 它使我們能夠檢查帳本中的任何狀態向量，從而確定其在哪個列表中，而無需參考單獨的列表。這類似于看一組體育迷，然后根據所穿襯衫的顏色來確定他們支持的球隊。體育迷們自稱忠誠。我們不需要粉絲列表。
- Hyperlegder Fabric 在內部使用 并發控制機制 來更新帳本，這樣將票據保持在單獨的狀態向量中就大大減少了共享狀態沖突的機會。這樣的沖突需要重新提交交易，使應用程序設計復雜化，并降低性能。
第二點實際上是 Hyperledger Fabric 的關鍵要素。狀態向量的物理設計對于優化性能和行為非常重要。讓你的狀態分開！
5. 信任關系
我們已經討論了網絡中的不同角色 (例如發行人，交易者或評估機構) 以及不同的商業利益如何決定誰需要簽署交易。在 Fabric 中，這些規則由所謂的 背書策略 捕獲。可以在鏈碼粒度以及各個狀態鍵上設置規則。
這意味著在 PaperNet 中，我們可以為整個命名空間設置一個規則，該規則確定哪些組織可以發布新票據。之后，可以為各個票據設置和更新規則，以捕獲購買和贖回交易的信任關系。
在下一個主題中，我們將向你展示如何結合這些設計概念來實現 PaperNet 商業票據智能合約，然后在其中進行應用！
Reference
- Docs ? Developing Applications ? Process and Data Design, https://hyperledger-fabric.readthedocs.io/en/release-1.4/developapps/architecture.html
- Docs ? Key Concepts ? Ledger, https://hyperledger-fabric.readthedocs.io/en/release-1.4/ledger/ledger.html#world-state
- Docs ? Developing Applications ? Application design elements ? Contract names, https://hyperledger-fabric.readthedocs.io/en/release-1.4/developapps/contractname.html
- Docs ? Architecture Reference ? Architecture Origins, https://hyperledger-fabric.readthedocs.io/en/release-1.4/arch-deep-dive.html#the-endorsing-peer-simulates-a-transaction-and-produces-an-endorsement-signature
- Docs ? Developing Applications ? Application design elements ? Endorsement policies, https://hyperledger-fabric.readthedocs.io/en/release-1.4/developapps/endorsementpolicies.html
項目源代碼
項目源代碼會逐步上傳到 Github，地址為 https://github.com/windstamp。
Contributor
- Windstamp, https://github.com/windstamp
