（1）客戶端應用程序發送交易請求（即提出議案proposal）
（1-1）客戶端發出請求，根據背書策略把交易請求發給相應的peer節點（背書節點）。（Q：背書策略是在一開始就定義好的？）
（1-2）構建交易提案（proposal），客戶端應用程序利用支持的SDK（Go, Java, Python）中的API生成proposal，提案是帶有確定輸入參數的調用鏈碼方法的請求，該請求可能是讀取或更新賬本。
（1-3）SDK作用：1. 將交易提案打包成合適的格式（gRPC）；2. 根據用戶的密鑰對交易提案生成簽名。
（2）背書節點驗證簽名並執行交易
（2-1）背書節點驗證：1. 交易提案的格式是否正確；2.交易提案之前沒有被提交過；3. 簽名是有效的（使用MSP）；4. 請求發起者（即客戶端）是否已經被授權在該通道上執行該操作（即，每個背書節點確保發起者滿足通道 Writers 策略）。
（2-2）背書節點將交易提案輸入作爲調用的鏈碼函數的參數。然後針對當前狀態數據庫執行鏈碼，生成交易結果，包括響應值、讀集和寫集。（Q：怎麼理解讀集合寫集）
（2-3）響應值以及背書節點簽名作爲“提案響應”傳回給SDK，SDK爲客戶端應用程序解析“提案響應”中的信息。
（3）客戶端應用程序檢查“提案響應”
（3-1）客戶端應用程序驗證背書節點簽名，比較多個“提案響應”，確定“提案響應”是否相同，當客戶端收到足夠數量的相同的“提案響應”後纔會執行下一步。
（3-2）查詢請求：客戶端應用程序只查看響應結果，通常不會將交易提交給排序節點。
（3-3）更新請求：客戶端應用程序先確定響應信息是否滿足指定的背書策略；若滿足，將交易提交給排序節點（Order）。
（4）排序服務進行排序並將交易封裝成區塊
（4-1）客戶端應用程序將交易發送給排序服務（Order節點），交易包括讀/寫集，背書節點簽名和Channel ID。
（4-2）排序服務從所有的channel中接收交易，利用排序算法（如solo，kafka等）按時間和通道進行排序，並將每個channel中的交易打包成區塊。
（5）驗證和提交交易
（5-1）排序節點（Order）將交易區塊發送給channel上所有的peer節點（包括commit peer，endorsing peer等）。
（5-2）peer節點對區塊內的交易進行驗證：1. 確保滿足背書策略；2. 確保自交易執行生成讀集以來，沒有對讀集變量的賬本狀態進行更改。驗證完之後對區塊中的交易進行標記爲：有效或無效。
（6）賬本更新
（6-1）peer節點將區塊添加到區塊鏈上。
（6-2）peer節點將每個有效交易寫入各自的賬本中以及世界狀態（world state）。
（6-3）系統會發出一個事件，通知客戶端應用程序本次交易（調用）已被不可更改地附加到區塊鏈上，同時還會通知交易驗證結果是有效還是無效。