織物的基本概念
最初，應用程序將選擇壹組對等方來生成帳簿更新建議。哪壹個對等體將被選擇基於簽署策略，該策略確定哪些組織需要在廣播賬簿更新提議之前簽署更新提議。這樣會影響理解的方式。任何關心更新提議是否被認可的組織將在向對等體廣播該提議並被對等體接受之前確認該提議是否被認可。
對等體對提議的響應的認可是將他的數字簽名添加到響應中，並用他的私鑰對整個響應進行簽名。然後，可以使用批註的內容來證明該響應是由組織的同行生成的。在我們的示例中，如果對等方P1屬於組織1(Org1)，則認可E1相當於證明事務T1和L1上的響應R1是由組織1的對等方P65438+做出的。
當應用程序獲得足夠多的簽名提案響應時，第壹階段就結束了。
我們註意到peer可能返回不同的信息，所以同壹個事務可能有不壹致的返回信息。這可能是因為響應是在不同的時間、不同的對等體和不同的帳簿上生成的。在大多數情況下，應用程序可以多次請求更新建議回應。另外更嚴重，但概率小因為鏈碼的不確定性導致響應不壹致。不確定性是鏈碼和賬本的大敵。如果出現這種情況，對於擬交易來說是非常嚴重的，不壹致的提議響應肯定不會提交到賬本上。獨立節點不可能知道事務結果是非確定性事務。在檢測非確定性事務之前，有必要對事務進行總結和比較(嚴格來說，即使這還不夠，我們也將這個討論推遲到事務部分，在事務部分不確定性有詳細討論)。
在第壹階段結束時，如果應用程序願意，它可以安全地丟棄不壹致的響應，以提前結束事務處理。我們將在後面看到，如果應用程序向分類帳提交的響應不壹致，它將被拒絕。
工藝2包裝
第二個交易過程是打包。訂購者節點是這個過程中的壹個關鍵點，它接收來自許多應用程序的認可的提議的事務響應。訂購方對交易進行排序，將大量交易打包成塊，並準備將塊分發給與訂購方連接的所有對等方，包括背書對等方。
訂購者的第壹個角色是打包賬簿更新建議。在上面的示例中，應用程序A1向訂購者O1發送由E1和E2背書的交易T1。同時，應用A2向訂購者O1發送由E1背書的交易T2。O1將來自A1的交易、來自A2的交易和其他交易打包到B2塊中。我們可以看到，塊B2中的事務順序是T1，T2，T3，T4，T6，T5，不壹定按照到達訂購者節點的順序(這個例子展示了壹個非常簡單的訂購者配置)。
訂購者節點還將接收由網絡信道中的不同應用發送的帳簿更新建議。訂購者節點的任務是按照預定義的順序整理這些更新建議，並將它們打包成塊，以準備下壹次分發。這些石塊將形成壹個區塊鏈。壹旦訂購者節點生成了具有預期大小的塊，或者超過了最大等待時間，訂購者將把該塊發送給連接到其特定通道的對等體。第三個過程將詳細介紹這個過程。
塊中事務的順序與事務到達order節點的順序之間沒有直接關系。事務可以在壹個塊中以任何順序排列，這個順序就是事務執行的順序。重點是有嚴格的交易排名，但排名多少並不重要。
塊中嚴格的事務順序使得Fabric不同於公共鏈中的事務可以被打包到多個不同的塊中的情況。在Fabric中，不可能出現這種情況，多order生成的塊就是最終的塊，因為事務寫入塊後，事務的位置順序就確定了。這意味著織物不會出現分叉。事務壹旦寫入塊中，就不能在以後重寫。
我們可以看到，peer存儲書籍和鏈碼，orderer根本不存儲。當每筆交易到達order時，order只是機械地將交易打包成塊，而不考慮交易的價值和額度。這是織物的壹個重要特征。所有事務都將按照嚴格的順序進行排序，不會丟棄任何事務。
到第二階段結束，我們可以理解訂購者的職責是收集必要且簡單的交易更新提議，對其進行排序，將其打包成塊並準備分發。
流程3認證
最後壹個事務工作流程是從訂購方到對等方分發和驗證塊。如果驗證成功，將提交到總賬。
特別地，在每個對等體中，塊中的每個交易在被更新到帳簿之前都被驗證，以確保所有交易都已被相關組織認可。失敗的交易將被保留以備將來審查，並且不會在賬簿中更新。
除了流程2中的打包角色，Orderer還負責將塊分發到流程3中的對等節點。在此示例中，O1將塊分發到P1和P2。P1處理Block 2，然後將Block 2添加到P1的賬簿L1。同時，P2處理塊2，然後將塊2添加到P2的賬簿L1。壹旦操作完成，賬簿L1在P1和P2中被更新，並且每個對等體可以將處理結果發送到連接到它們的應用程序。
訂購者將塊分發給連接到他的對等體，這是過程3的開始。連接到訂購者節點的信道的對等端將接收訂購者生成的新塊的副本。每個對等節點將獨立處理接收到的塊，但是所有對等節點都以相同的方式處理該塊。這樣，不同同行的賬本就可以達到* * *知識。不是所有的對等體都必須連接到orderer節點，塊可以通過gossip協議在對等體之間傳遞，這樣對等體也可以獨立處理相同的塊。
收到塊後，peer將按照塊中出現的順序處理事務。對於每筆交易，peer將根據生成交易的鏈碼認可策略檢查交易是否得到相關組織的認可。例如，某些交易可能只需要壹個組織背書，而其他交易則需要多個組織同時背書。該驗證過程驗證所有相關組織產生的結果或輸出是否壹致。同時請註意，第三階段驗證與第壹階段不同。在第壹階段，應用程序僅接收來自背書節點的響應，並判斷是否需要發送交易提議。如果應用程序發送了錯誤的交易並違反了背書策略，peer仍然可以在第三個驗證階段拒絕該交易。
如果交易的背書是正確的，peer將嘗試將交易提交到分類帳。為了編寫賬簿，peer必須檢查賬簿的壹致性，以確保當前賬簿與更新後的賬簿壹致。這種狀態並不總是壹致的，即使交易有完整的背書。例如，另壹項交易可能更新了分類賬中的同壹項資產，因此我們將要更新的交易將永遠不會寫入分類賬。在這種情況下，每個節點中的賬簿必須通過網絡保持通知，每個節點的驗證方法是相同的。
在peer核實每筆獨立交易後，分類賬將被更新。失敗的交易將作為審查材料保存。這意味著除了塊中指示事務成功或失敗的標誌之外，對等體中的塊與從訂購方接收的塊相同。
我們還要註意，鏈碼不是在第三階段執行的，這壹步只會在第壹階段完成，這壹點很重要。這意味著鏈碼只在背書節點可用，不在全網可用，保證了鏈碼在背書機構的安全性和私密性。這不同於接收鏈代碼的執行結果。執行結果將與通道中的所有對等體共享，而不管他是否可以簽署該事務。背書節點就是這樣設計的，方便擴展。
最後，每向對等體的賬本提交壹個塊，對等體就會生成壹個相應的事件。塊事件包含壹個塊的所有內容，而塊事務事件只包含簡短的信息，例如每個塊中的事務是否有效。鏈碼執行產生的鏈碼事件也可以在此時釋放。應用程序可以註冊這些事件，並在事件發生時接收通知。這些通知在事務工作流的第三個也是最後壹個階段完成。
壹般來說，我們可以知道第三階段orderer生成的塊是不斷同步到賬本中的。區塊鏈中交易的嚴格排序允許每個對等點壹致地驗證區塊鏈網絡中的交易，並將它們提交給分類帳。
訂購者和* * *知識
整個事務工作流被稱為* * *知識，因為所有的peer都同意事務的排序和內容，在執行過程中由orderer節點協調。* * * knowledge是壹個多步驟的過程，只有在* * * knowledge過程結束時才會通知應用程序，但通知時間在不同的對等體上可能會有所不同。
我們稍後將更多地討論訂購者。現在，我們只是把orderer看成是壹個從應用收集並分發賬本更新建議給對等端的過程，對等端會對賬本進行驗證和更新。