建站服務(wù)器

在生產(chǎn)環(huán)境中，一個最小的Fabric聯(lián)盟鏈網(wǎng)絡(luò)由4個結(jié)點組成，如下圖：

為了避免單點故障，進(jìn)行結(jié)構(gòu)冗余，每個節(jié)點的角色安排如下：

· 192.168.1.120 peer1, orderer1, zookeeper0, kafka0, ca1，

· 192.168.1.121 peer2, orderer2, zookeeper1, kafka1 ca2

· 192.168.1.122 peer3, zookeeper2, kafka2 ,ca3

· 192.168.1.122 peer4, kafka3 ca4, fabric瀏覽器

在Fabric中，本由一個節(jié)點處理的過程，在邏輯上被分解為不同的角色，每個角色承擔(dān)不同的功能；節(jié)點（Peer）分解為背書節(jié)點（Endorser peer）和提交節(jié)點（Committer peer），為了達(dá)到處理的順序性，提煉出排序（Orderer）角色，kafka是聯(lián)盟鏈中負(fù)責(zé)共享機制，zookeeper是個分布式應(yīng)用協(xié)調(diào)器，負(fù)責(zé)點到點數(shù)據(jù)傳輸，CA負(fù)責(zé)證書發(fā)放。 Fabric是應(yīng)用于聯(lián)盟鏈的場景，在處理每一筆交易時，每個環(huán)節(jié)上需要對交易信息進(jìn)行權(quán)限校驗。
Fabric交易流程圖如下所示：

交易過程詳細(xì)流程：
1) 應(yīng)用程序客戶端通過SDK調(diào)用證書服務(wù)（CA）服務(wù)，進(jìn)行注冊和登記，并獲取×××?xí)?br /> 2) 應(yīng)用程序客戶端通過SDK向區(qū)塊鏈網(wǎng)絡(luò)發(fā)起一個交易提案（Proposal），交易提案把帶有本次交易要調(diào)用的合約標(biāo)識、合約方法和參數(shù)信息以及客戶端簽名等信息發(fā)送給背書（Endorser）節(jié)點。

3) 背書（Endorser）節(jié)點收到交易提案（Proposal）后，驗證簽名并確定提交者是否有權(quán)執(zhí)行操作，同時根據(jù)背書策略模擬執(zhí)行智能合約，并將結(jié)果及其各自的CA證書簽名發(fā)還給應(yīng)用程序客戶端。

4) 應(yīng)用程序客戶端收到背書（Endorser）節(jié)點返回的信息后，判斷提案結(jié)果是否一致，以及是否參照指定的背書策略執(zhí)行，如果沒有足夠的背書，則中止處理；否則，應(yīng)用程序客戶端把數(shù)據(jù)打包到一起組成一個交易并簽名，發(fā)送給Orderers。
5) Orderers對接收到的交易進(jìn)行共識排序，然后按照區(qū)塊生成策略，將一批交易打包到一起，生成新的區(qū)塊，發(fā)送給提交（Committer）節(jié)點；
6) 提交（Committer）節(jié)點收到區(qū)塊后，會對區(qū)塊中的每筆交易進(jìn)行校驗，檢查交易依賴的輸入輸出是否符合當(dāng)前區(qū)塊鏈的狀態(tài)，完成后將區(qū)塊追加到本地的區(qū)塊鏈，并修改世界狀態(tài)。

還有一個關(guān)于Fabric聯(lián)盟鏈交易理解的說明：

這個示例中包含客戶A和B，在進(jìn)行蘿卜買賣。他們各自有一個網(wǎng)絡(luò)節(jié)點，通過節(jié)點他們發(fā)送交易并和賬本進(jìn)行交互。

首先，假設(shè)必要的條件：

該流程假設(shè)通道已建立并正常運行。用戶已注冊并使用組織認(rèn)證授權(quán)（CA）登記，同時獲得必要的加密材料來進(jìn)行網(wǎng)絡(luò)驗證。

鏈碼（包含一組代表蘿卜市場初始狀態(tài)的鍵值對）被安裝在節(jié)點上并在通道上進(jìn)行實例化。鏈碼包含定義交易指令集合的邏輯和達(dá)成一致的蘿卜價格。設(shè)置一項針對鏈碼的背書策略，表明節(jié)點A和B都必須對任何交易進(jìn)行背書。

1. 客戶A發(fā)起交易

客戶A發(fā)出蘿卜購買請求。請求目標(biāo)節(jié)點A和B，分別代表客戶A和B。背書策略表明兩個節(jié)點必須為任何交易進(jìn)行背書，因而請求被發(fā)送到節(jié)點A和B。

接下來構(gòu)建交易提案。一個以可用SDK（node, java, python）為支撐的應(yīng)用利用有效的API來生成交易提案。這項提案作為調(diào)用鏈碼功能的請求來完成數(shù)據(jù)到賬本的讀取和/或?qū)懭耄礊橘Y產(chǎn)寫入新的鍵值對）。SDK有兩個作用：把交易提案包裝成合適架構(gòu)格式的庫（基于gRPC的協(xié)議緩沖）；使用用戶的加密證書來創(chuàng)建交易提案的唯一簽名。

2. 背書節(jié)點驗證簽名&執(zhí)行交易

背書節(jié)點使用MSP驗證簽名并確定請求者是否被合理授權(quán)進(jìn)行提案的操作（使用通道ACL）。背書節(jié)點以交易提案憑證為輸入，基于當(dāng)前狀態(tài)的數(shù)據(jù)庫執(zhí)行來生成交易結(jié)果，輸出包括反饋值、讀取集合和寫入集合。截止現(xiàn)在賬本還未進(jìn)行更新。這些值的集合，背書節(jié)點的簽名以及是/否的背書聲明一同作為“提案反饋”被傳輸回到SDK，SDK對應(yīng)用消耗的載荷進(jìn)行解析。

3. 審查提案反饋

應(yīng)用對背書節(jié)點簽名進(jìn)行驗證，比較提案反饋（鏈接到包含載荷代理的術(shù)語條款）來決定是否一致，指定的背書策略是否被執(zhí)行（即節(jié)點A和B都進(jìn)行了背書）。這種架構(gòu)可以保證即使一個應(yīng)用選擇不進(jìn)行反饋審查或者轉(zhuǎn)發(fā)了沒有背書的交易，背書策略依然會被節(jié)點執(zhí)行并在驗證提交階段維持。

4. 客戶組合交易背書

應(yīng)用對交易提案進(jìn)行廣播，以“交易信息”對訂購服務(wù)實現(xiàn)反饋。交易包含讀/寫集合，背書節(jié)點簽名和通道ID。訂購服務(wù)不讀取交易細(xì)節(jié)，只是從網(wǎng)絡(luò)中所有通道接收交易，根據(jù)每個通道按時間順序調(diào)用，創(chuàng)建每個通道的交易區(qū)塊。

5. 交易驗證和提交

交易區(qū)塊被發(fā)布到通道中的所有節(jié)點。區(qū)塊中的交易被驗證來確保背書策略被執(zhí)行并且賬本的讀取集合變量沒有發(fā)生變化，因為讀取集合是執(zhí)行交易生成的。區(qū)塊中的交易被標(biāo)記為有效或無效。

6. 賬本更新

每個節(jié)點都把區(qū)塊追加到通道的鏈中，對每項有效交易，寫入集合被提交到當(dāng)前狀態(tài)的數(shù)據(jù)庫。發(fā)出事務(wù)通知客戶端應(yīng)用，交易（調(diào)用）被永久追加到鏈中以及交易是有效或者無效的。

總結(jié)

以上是生活随笔為你收集整理的HyperLedger Fabric 交易流程的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。