Hyperledger Fabric的Transaction處理流程
在介紹Transaction處理流程之前，我們先來了解區(qū)塊鏈網(wǎng)絡(luò)的最重要的組成部分->peer節(jié)點。通過分析peer節(jié)點與其他組件之間的關(guān)系來逐步了解Fabric中transaction的處理流程。
我們通過一下幾個方面來進行了解：
- fabric的網(wǎng)絡(luò)結(jié)構(gòu)
- Peer節(jié)點和賬本和鏈碼的關(guān)系
- applications和peers的關(guān)系
- peers和channels的關(guān)系
- peers和organizations的關(guān)系
- peers和identity的關(guān)系
- peers和orderers的關(guān)系
Fabric的網(wǎng)絡(luò)結(jié)構(gòu)
區(qū)塊鏈網(wǎng)絡(luò)由賬本（ledger）、智能合約（smart contracts）昨悼、背書節(jié)點（orderers）捉腥、通道（channels）歼捐、應(yīng)用（applications）何陆、組織（organizations）、成員關(guān)系服務(wù)提供商（MSP）等部分組成豹储。
- 信息描述：client端的application通過sdk向被選成背書節(jié)的peer發(fā)送交易提案贷盲。peer節(jié)點調(diào)用鏈碼模擬執(zhí)行交易。生成讀寫集剥扣，返回給client端巩剖。client端接收返回結(jié)果，生成交易發(fā)送給排序節(jié)點進行排序钠怯。排序節(jié)點對交易進行排序佳魔，在達到配置閾值要求時生成區(qū)塊。并廣播到所有peer節(jié)點（實際過程是先發(fā)送給所有主節(jié)點晦炊，主節(jié)點在發(fā)送到各自對應(yīng)的所有peer節(jié)點）鞠鲜。peer節(jié)點對交易進行驗證，驗證通過更新世界狀態(tài)断国，將區(qū)塊追加到區(qū)塊鏈中贤姆。
Peer節(jié)點和賬本和鏈碼的關(guān)系
peer節(jié)點是區(qū)塊鏈網(wǎng)絡(luò)的基礎(chǔ)組成部分，peer存儲了區(qū)塊鏈賬本數(shù)據(jù)稳衬，智能合約也是在peer節(jié)點上運行的霞捡。下圖展示了peer節(jié)點、賬本和鏈碼這三者之間的關(guān)系薄疚。
- 信息描述：區(qū)塊鏈網(wǎng)絡(luò)包含三個peer節(jié)點碧信，分別是P1,P2,P3。三個peer節(jié)點都維護了一份相同的賬本數(shù)據(jù)L1街夭，都運行了同一個鏈碼S1.
當peer節(jié)點剛創(chuàng)建時砰碴，是不包含賬本和鏈碼的。當它加入到區(qū)塊鏈網(wǎng)絡(luò)中莱坎，安裝完鏈碼之后衣式，才會同步賬本數(shù)據(jù)寸士。
多賬本（Multiple Ledgers）
一個peer節(jié)點可以維護多套賬本檐什，如下圖：
- 信息描述：peer節(jié)點P1同時維護了兩套賬本L1和L2，其中L1賬本由鏈碼S1維護弱卡，L2賬本由鏈碼S1和鏈碼S2同時維護乃正。
多鏈碼（Multiple Chaincodes）
一個peer節(jié)點同時也可以維護多套鏈碼，如下圖：
- 信息描述：Peer節(jié)點P1同時維護兩套賬本L1和L2婶博。其中L1賬本由鏈碼S1和S2維護瓮具，賬本L2由鏈碼S1和鏈碼S3維護。其中鏈碼S1可以同時維護賬本L1和賬本L2。
結(jié)論：一個鏈碼可以適用于多個賬本名党，而一個賬本也可以同時由多個鏈碼來維護叹阔。
applications和peers的關(guān)系
在上面網(wǎng)絡(luò)結(jié)構(gòu)中，描述了交易執(zhí)行的流程传睹，客戶端發(fā)起交易提案耳幢，經(jīng)過背書后，生成交易發(fā)送給排序節(jié)點排序欧啤，并生成區(qū)塊睛藻，最后提交給提交節(jié)點進行校驗并提交。
注意事項：
其中鏈碼的執(zhí)行是由application通過sdk調(diào)用邢隧，通過peer節(jié)點執(zhí)行的店印。
交易通過排序節(jié)點提交到peer節(jié)點后，如果通過校驗會直接將讀寫集的寫集作為結(jié)果更新世界狀態(tài)倒慧，并不會再重新執(zhí)行一次鏈碼處理流程按摘。</br>
校驗失敗的交易會被標記成無效，區(qū)塊依舊會追加到區(qū)塊鏈中纫谅，但是不會更新世界狀態(tài)院峡。
查詢交易不會執(zhí)行上述圖片中的4、5步系宜。在提案結(jié)果返回后結(jié)束照激。
peers和channels的關(guān)系
上面已經(jīng)描述了application、peer盹牧、賬本俩垃、鏈碼之間的關(guān)系。但是它們之間的交互并不是沒有限制的汰寓。鏈與鏈之間通過通道來隔離口柳。只有加入到同一個通道的組件之間才能進行交互。如下圖：
- 信息描述：區(qū)塊鏈網(wǎng)絡(luò)N包含通道C有滑，包含兩個peer節(jié)點P1和P2跃闹，P1和P2都安裝了同一套鏈碼S1，維護同一套賬本L1.網(wǎng)絡(luò)外的應(yīng)用程序A毛好，通過加入到通道中望艺，與網(wǎng)絡(luò)進行通信，發(fā)起交易肌访。
channel并不是一個實體找默，它只是一個邏輯概念。
peers和organizations的關(guān)系
peer節(jié)點是區(qū)塊鏈網(wǎng)絡(luò)的最基礎(chǔ)的組成部分吼驶。但是區(qū)塊鏈網(wǎng)絡(luò)并不是按peer為單位進行管理的惩激，而是按組織店煞。如下圖：
- 信息描述：區(qū)塊鏈網(wǎng)絡(luò)N包含了8個peer節(jié)點，和一個通道C风钻。其中P1顷蟀、P2節(jié)點屬于組織1，P3骡技、P4衩椒、P5屬于組織2，P6哮兰、P7屬于組織3毛萌，P8屬于組織4.組織1中的peer節(jié)點P1、組織2中的peer節(jié)點P3 P4喝滞、組織3中的peer節(jié)點P7阁将、組織4中的peer節(jié)點P8都加入到了同一個通道C中。同時應(yīng)用程序A1右遭、A2做盅、A3、A4窘哈，分別加入了對應(yīng)的組織吹榴。
注意事項：一個組織中的peer節(jié)點可以加入到不同的通道中。一個peer節(jié)點屬于一個組織滚婉。應(yīng)用程序可以鏈接到所加入的組織中的其中一個節(jié)點图筹。
peers和identity的關(guān)系
關(guān)于加入到鏈中的peer的身份管理，如下圖：
當一個peer加入到一個通道让腹，它所屬的組織會通過MSP給這個peer分配一個數(shù)字證書远剩。在上面這個圖例中，P1骇窍、P2通過CA1分配證書瓜晤，P3、P4通過CA2分配證書腹纳。通道C通過配置的通道配置策略CP來確認peer節(jié)點和組織的關(guān)系痢掠。
一個peer只能屬于一個組織，所以一個peer也只是對應(yīng)一個MSP嘲恍，一個MSP可以給多個peer分配證書足画。
peers和orderers的關(guān)系
排序節(jié)點負責對交易進行排序，并負責生成區(qū)塊蛔钙。一個交易執(zhí)行的主要過程大致分成三部分锌云，第一部分：發(fā)起提案荠医，由背書節(jié)點對提案進行背書簽名吁脱。第二部分：發(fā)起交易桑涎，由排序節(jié)點進行排序，并聲稱區(qū)塊兼贡。第三部分：分發(fā)到所有peer節(jié)點進行校驗攻冷，然后更新賬本。排序節(jié)點處于交易的核心位置遍希。
接下來我們分別看這三部分的處理流程：
提案處理
- 信息描述：區(qū)塊鏈網(wǎng)絡(luò)N等曼，包含通道C、排序節(jié)點O1凿蒜、peer節(jié)點P1禁谦、P2，都安裝了鏈碼S1废封，維護同一套賬本L1州泊，由applicationA1，發(fā)起交易請求漂洋。A1發(fā)起交易提案遥皂，由P1、P2背書后刽漂，將結(jié)果返回至A1演训。其中P1、P2屬于不同的組織贝咙。
問題：一筆交易應(yīng)該由哪些背書節(jié)點進行背書样悟？
答：這個是由背書策略決定的，背書策略定義了需要經(jīng)過一組組織確認庭猩，交易才會被認可乌奇。背書策略可以手工指定。
問題：背書的過程是怎么樣的眯娱？
答：背書節(jié)點模擬執(zhí)行鏈碼生成結(jié)果之后礁苗，背書節(jié)點通過自身的私鑰對返回結(jié)果進行加密。這也是背書策略驗證是否收集到足夠背書的一個證明徙缴。
打包生成區(qū)塊
背書節(jié)點接收很多application的交易试伙，并對這寫交易進行排序，根據(jù)配置文件配置的區(qū)塊生成配置來生成區(qū)塊于样。
- 信息描述：區(qū)塊鏈網(wǎng)絡(luò)N疏叨，包含通道C、排序節(jié)點O1穿剖、peer節(jié)點P1蚤蔓、P2。這個網(wǎng)絡(luò)中有多個application發(fā)起了交易糊余，order接收這些交易秀又。對收集到的交易進行排序单寂，并生成區(qū)塊B2。排序結(jié)果與排序節(jié)點接收到交易的先后次序沒有關(guān)系吐辙。
在配置文件fabric/examples/e2e_cli/configtx.yaml中有兩個配置宣决，定義了區(qū)塊的生成策略。
BatchTimeout：從區(qū)塊的第一筆交易開始昏苏，創(chuàng)建一個計時器尊沸，當超過這個超時時間，還沒有足夠的交易贤惯，那么會將所有未打包的交易進行打包生成區(qū)塊洼专。
BatchSize：這個配置又主要包含三個部分。如下：MaxMessageCount：區(qū)塊包含的最大交易數(shù)量孵构。
AbsoluteMaxBytes：區(qū)塊最大的大小壶熏。（不包括交易頭部）
PreferredMaxBytes：每個區(qū)塊建議的大小。Kafka對于相對小的消息提供更高的吞吐量浦译；區(qū)塊大小最好不要超過1MB棒假。
打包生成的區(qū)塊是一定會被加入到區(qū)塊鏈中的，如果是無效交易精盅，會被標示成無效帽哑，但是交易依舊是存在于區(qū)塊中。區(qū)塊中的交易是不能修改的叹俏。
校驗區(qū)塊并更新賬本
- 信息描述：區(qū)塊鏈網(wǎng)絡(luò)N包含通道C妻枕、排序節(jié)點O1、peer節(jié)點P1粘驰、P2屡谐，排序節(jié)點O1將排序后生成的區(qū)塊B2，分發(fā)給P1蝌数、P2愕掏。P1、P2在對區(qū)塊中的交易進行過校驗之后顶伞，將區(qū)塊追加到鏈碼L1中饵撑。這個過程中是不需要執(zhí)行鏈碼的。
