Hyperledger Fabric 專題 - Peers
區(qū)塊鏈網(wǎng)絡主要由一組對端節(jié)點 (peer nodes, or simply, peers) 組成。對端節(jié)點是網(wǎng)絡的基本元素钾菊，因為它們托管帳本和智能合約樊诺∫ё睿回想一下邮辽，賬本一成不變地記錄了智能合約生成的所有交易 (Hyperledger Fabric 中的交易包含在鏈碼中履肃，稍后會詳細介紹)仔沿。智能合約和賬本分別用于封裝網(wǎng)絡中的共享過程 (shared process) 和共享信息 (shared information)。對端節(jié)點的這些方面使它們成為了解 Fabric 網(wǎng)絡的良好起點尺棋。
區(qū)塊鏈網(wǎng)絡的其他元素當然很重要：帳本和智能合約封锉，交易排序器，策略膘螟，通道成福，應用程序，組織荆残，身份標識和成員資格服務提供商奴艾，你可以在其專用部分中閱讀有關它們的更多信息。本節(jié)重點介紹對端節(jié)點及其與 Fabric 網(wǎng)絡中其他元素的關系内斯。
區(qū)塊鏈網(wǎng)絡由對端節(jié)點組成畅蹂，每個對端節(jié)點可以保存賬本的副本和智能合約的副本。在此示例中啊胶，網(wǎng)絡 N 由對端節(jié)點 P1肃拜，P2 和 P3 組成，每個對端節(jié)點 P1真朗，P2 和 P3 維護自己的分布式賬本 L1 實例此疹。 P1，P2 和 P3 使用相同的鏈碼 S1 來訪問其分布式賬本的副本。
可以創(chuàng)建蝗碎，啟動湖笨，停止，重新配置甚至刪除對端節(jié)點蹦骑。它們公開了一組 API慈省，使管理員和應用程序可以與其提供的服務進行交互。我們將在本節(jié)中詳細了解這些服務眠菇。
1. 術語
Fabric 通過稱為鏈碼 (chaincode) 的技術概念來實現(xiàn)智能合約(smart contract) - 只是訪問賬本的一段代碼辫呻，以受支持的編程語言中的任一種編寫。在本主題中琼锋，我們通常使用術語“鏈碼”放闺，但是如果你更習慣智能合約這個術語，可以隨時將其作為智能合約來閱讀缕坎。這是同一件事怖侦！如果你想了解有關鏈碼和智能合約的更多信息，請查看我們關于智能合約和鏈碼的文檔谜叹。
2. 分布式賬本和鏈碼
讓我們再詳細一點匾寝。我們可以看到，同時托管帳本和鏈碼的是對端節(jié)點荷腊。更準確地說艳悔，對端節(jié)點實際上是托管帳本實例和鏈碼實例的宿主。請注意女仰，這在 Fabric 網(wǎng)絡中提供了有意的冗余 - 避免了單點故障猜年。在本節(jié)的后面，我們將詳細了解區(qū)塊鏈網(wǎng)絡的分布式和去中心化性質疾忍。
[圖片上傳失敗...(image-4d3467-1573120639360)]
對端節(jié)點托管賬本實例和鏈碼實例乔外。在此示例中，P1 承載帳本 L1 的實例和鏈碼 S1 的實例一罩。單個對端節(jié)點主機上可以托管許多帳本和鏈碼杨幼。
由于對端節(jié)點是帳本和鏈碼的宿主，因此應用程序和管理員如果要訪問這些資源聂渊，必須與對端節(jié)點進行交互差购。這就是為什么將對等方視為Fabric網(wǎng)絡的最基本組成部分。首次創(chuàng)建同位體時汉嗽，既沒有分類帳欲逃，也沒有鏈碼。稍后我們將介紹如何在同級上創(chuàng)建分類帳以及如何安裝鏈碼诊胞。
2.1 多個賬本
對端節(jié)點可以承載多個帳本暖夭，這很有用，因為它允許靈活的系統(tǒng)設計撵孤。最簡單的配置是讓對端節(jié)點管理一個帳本迈着，但是對端節(jié)點在需要時托管兩個或多個帳本絕對是合適的。
承載多個帳本的對端節(jié)點邪码。對端節(jié)點主機托管一個或多個帳本裕菠，每個帳本具有應用于它們的零個或多個鏈碼。在此示例中闭专，我們可以看到對端節(jié)點 P1 承載帳本 L1 和 L2奴潘。使用鏈碼 S1 訪問帳本 L1。另一方面影钉，可以使用鏈碼 S1 和 S2 訪問帳本 L2画髓。
盡管對端節(jié)點完全有可能托管一個賬本實例，而不托管任何訪問該賬本的鏈碼平委，但很少有對端節(jié)點是以這種方式配置的奈虾。絕大多數(shù)對端節(jié)點將至少安裝一個鏈碼，可以查詢或更新對等點的分類帳實例廉赔。值得一提的是肉微，無論用戶是否安裝了供外部應用程序使用的鏈碼，對端節(jié)點也都始終存在著特殊的系統(tǒng)鏈碼 (system chaincode)蜡塌。在本主題中不會詳細討論這些內容碉纳。
2.2 多個鏈碼
對端節(jié)點擁有的賬本數(shù)量與可以訪問該賬本的鏈碼數(shù)量之間沒有固定的關系。一個對端節(jié)點可能有許多可用的鏈碼和帳本馏艾。
上圖是一個對端節(jié)點托管多個鏈碼的示例劳曹。每個帳本可以有許多訪問它的鏈碼。在此示例中琅摩，我們可以看到對端節(jié)點 P1 承載帳本 L1 和 L2厚者，其中 L1 由鏈碼 S1 和 S2 訪問，而 L2 由 S1 和 S3 訪問迫吐。我們可以看到 S1 可以訪問 L1 和 L2库菲。
我們稍后將看到當在對端節(jié)點上托管多個帳本或多個鏈碼時，F(xiàn)abric 中的通道概念為什么如此重要的原因志膀。
3. 應用程序和對端節(jié)點
現(xiàn)在我們將解釋應用程序是如何通過與對端節(jié)點交互來訪問賬本的熙宇。賬本查詢交互涉及一個應用程序和一個對端節(jié)點之間簡單的三步對話。賬本更新交互稍微復雜一點溉浙，需要兩個額外的步驟烫止。我們將簡化這些步驟一點點地幫助你開始使用 Fabric，但不要擔心 - 最重要的是理解應用程序和對端節(jié)點交互在賬本查詢和賬本更新之間的差異戳稽。
當應用程序需要訪問帳本和鏈碼時馆蠕，它們總是連接到對端節(jié)點期升。Fabric 的軟件開發(fā)套件 (Software Development Kit, SDK) 使程序員可以輕松實現(xiàn)它 - 其 API 使應用程序可以連接到對端節(jié)點，調用鏈碼以生成交易互躬，將交易提交到網(wǎng)絡 (該交易將被排序并提交到分布式帳本) 以及當此過程完成時接收事件播赁。
通過與一個對端節(jié)點連接，應用程序可以執(zhí)行鏈碼來查詢或更新帳本吼渡。帳本查詢交易的結果將立即返回容为，而帳本更新涉及應用程序，對端節(jié)點和交易排序器之間更復雜的交互寺酪。讓我們更詳細地研究一下坎背。
上圖顯示，對端節(jié)點通過與交易排序器連接以確保每個對端節(jié)點上的賬本都是最新的寄雀。在此示例中得滤，應用程序 A 連接到 P1 并調用鏈碼 S1 以查詢或更新帳本 L1。P1 調用 S1 以生成包含查詢結果或帳本更新提案的響應盒犹。應用程序 A 收到提案響應耿戚，并且對于查詢該過程現(xiàn)在已完成。為了進行更新阿趁，A 根據(jù)所有響應構建一個交易膜蛔，然后將其發(fā)送給 O1 進行交易排序。 O1 將整個網(wǎng)絡中的交易收集到多個區(qū)塊中脖阵，并將其分配給所有的對端節(jié)點皂股，包括 P1。 P1 在將交易應用到 L1 之前先進行驗證命黔。一旦 L1 更新呜呐，P1 就會生成一個事件，該事件由 A 接收悍募，表示整個流程已經(jīng)完成蘑辑。
對端節(jié)點可以立即將查詢結果返回給應用程序，因為滿足查詢所需的所有賬本信息都在對端節(jié)點的本地副本中坠宴。對端節(jié)點從不需要與其他對端節(jié)點協(xié)商以響應來自應用程序的查詢洋魂。但是，應用程序可以連接到一個或多個對端節(jié)點以發(fā)出查詢喜鼓。例如副砍，以在多個對端節(jié)之間證實其結果，或如果懷疑信息有可能過時則可以從不同的對端節(jié)點獲取最新結果庄岖。在上圖中豁翎，你可以看到帳本查詢是一個簡單的三步過程。
更新交易以與查詢交易相同的方式啟動隅忿，但有兩個額外的步驟心剥。盡管更新帳本的應用程序也連接到對端節(jié)點以調用鏈碼邦尊，但與帳本查詢應用程序不同，單個對端節(jié)點此時無法執(zhí)行帳本更新优烧，因為其他對端節(jié)點必須首先同意更改蝉揍，這一過程稱為共識。因此匙隔，對端節(jié)點向應用程序返回了一項提案 (proposed) 的更新 - 該對端節(jié)點將在其他對端節(jié)點事先同意的情況下應用該更新。第一個額外的步驟 (第四步) 要求應用程序將一組適當?shù)钠ヅ涞奶岚父录l(fā)送到整個網(wǎng)絡熏版，以作為對端節(jié)點對各自賬本的承諾的交易纷责。這是通過應用程序使用交易排序器將交易打包成區(qū)塊并將其分發(fā)到整個網(wǎng)絡來實現(xiàn)的，在將它們應用于每個對端節(jié)點的本地帳本副本之前撼短，可以在其中進行驗證再膳。由于整個交易排序器過程需要一些時間 (幾秒鐘) 才能完成，因此將異步通知應用程序曲横，如步驟 5 所示喂柒。
在本節(jié)的后面，你將了解有關此交易排序器過程的詳細特性的更多信息 - 有關此過程的詳細信息禾嫉，請參見 交易流 主題灾杰。
4. 對端節(jié)點和通道
盡管本節(jié)的重點是對端節(jié)點而不是通道，但值得花一些時間來了解對端節(jié)點如何通過通道與彼此以及與應用程序進行交互熙参。通過通道艳吠，區(qū)塊鏈網(wǎng)絡中的一組組件可以進行私下通信和交易。
這些組件通常是對端節(jié)點孽椰，交易排序器節(jié)點和應用程序昭娩，并且通過加入通道，它們同意協(xié)作以共同共享和管理與該通道關聯(lián)的帳本的相同副本黍匾。從概念上講栏渺，你可以將通道視為與朋友組相似 (盡管通道的成員當然不需要成為朋友！)锐涯。一個人可能有幾組朋友磕诊，每組都有他們一起做的活動。這些小組可能是完全獨立的 (一群工作朋友纹腌，而不是一群愛好朋友)秀仲，或者它們之間可能會有一些交叉。但是壶笼，每個組都是其自己的實體神僵，具有某種“規(guī)則”。
上圖顯示覆劈，通道允許一組特定的對端節(jié)點和應用程序在區(qū)塊鏈網(wǎng)絡內相互通信保礼。在此示例中沛励，應用程序 A 可以使用通道 C 直接與對端節(jié)點 P1 和 P2 通信。你可以將通道視為特定應用程序和對端節(jié)點之間進行通信的路徑炮障。 (為簡單起見目派，交易排序器未在此圖中顯示，但必須存在于正常運行的網(wǎng)絡中胁赢。)
我們發(fā)現(xiàn)通道的存在方式與對端節(jié)點不同企蹭，因此將通道視為由一組物理對端節(jié)點形成的邏輯結構更為合適。理解這一點至關重要 - 對端節(jié)點提供訪問和管理通道的控制點智末。
5. 對端節(jié)點和組織
既然你了解了對端節(jié)點及其與帳本谅摄，鏈碼和通道的關系，現(xiàn)在你將能夠看到多個組織如何一起組成一個區(qū)塊鏈網(wǎng)絡系馆。
區(qū)塊鏈網(wǎng)絡由組織的集合而不是單個組織管理送漠。對端節(jié)點對于這種分布式網(wǎng)絡的構建至關重要，因為對端節(jié)點網(wǎng)絡由這些組織擁有由蘑，并且是這些組織的網(wǎng)絡連接點闽寡。
上圖顯示了，具有多個組織的區(qū)塊鏈網(wǎng)絡中的對端節(jié)點尼酿。區(qū)塊鏈網(wǎng)絡是由擁有不同的對端節(jié)點的組織建立和貢獻的爷狈。在此示例中，我們看到四個組織貢獻了八個對端節(jié)點組成一個網(wǎng)絡裳擎。通道 C 連接網(wǎng)絡 N 中的五個對端節(jié)點 - P1淆院，P3，P5句惯，P7 和 P8土辩。這些組織擁有的其他對端節(jié)點尚未加入此通道，但通常已加入至少一個其他通道抢野。由特定組織開發(fā)的應用程序將連接到其各自組織的對端節(jié)點以及不同組織的對端節(jié)點拷淘。同樣，為簡單起見指孤，該圖中未顯示交易排序器節(jié)點启涯。
了解區(qū)塊鏈網(wǎng)絡的形成過程非常重要。網(wǎng)絡由向其貢獻資源的多個組織組成和管理恃轩。對端節(jié)點是我們在本主題中討論的資源结洼，但是組織提供的資源不僅僅是對端節(jié)點。這里有一個原則在起作用 - 如果組織沒有將各自的資源投入到集體網(wǎng)絡中叉跛，那么網(wǎng)絡實際上就不存在松忍。而且，網(wǎng)絡隨著這些協(xié)作組織提供的資源而增長和收縮筷厘。
在上面的示例中鸣峭，你可以看到 (除了交易排序器服務之外) 沒有集中式資源 - 如果組織不提供對端節(jié)點資源宏所，則網(wǎng)絡 N 將不存在。這反映了這樣一個事實：除非有組織提供構成該網(wǎng)絡的資源摊溶，否則該網(wǎng)絡不存在任何意義爬骤。此外，網(wǎng)絡不依賴于任何單個組織莫换，只要一個組織存在霞玄，它就會繼續(xù)存在，無論其他組織可能來去去去拉岁。這是網(wǎng)絡去中心化意味著什么的核心坷剧。
如上例所示，不同組織中的應用程序可能相同也可能不同膛薛。那是因為這完全取決于組織的應用程序如何處理其對端節(jié)點的帳本副本听隐。這意味著應用程序和表示邏輯在組織之間可能會有所不同补鼻，即使它們各自的對端節(jié)點托管的賬本數(shù)據(jù)完全相同哄啄。
應用程序可以連接到其組織中的對端節(jié)點，也可以連接到另一個組織中的對端節(jié)點风范，具體取決于所需的賬本交互的性質咨跌。對于賬本查詢交互，應用程序通常會連接到其組織的對端節(jié)點硼婿。對于賬本更新交互锌半，我們將在后面看到為什么應用程序需要連接到代表背書 (endorse) 賬本更新所需的每個組織的對端節(jié)點。
6. 對端節(jié)點和身份標識
既然你已經(jīng)了解了來自不同組織的對端節(jié)點如何組成一個區(qū)塊鏈網(wǎng)絡寇漫，那么值得花一些時間來了解如何將其對端節(jié)點由管理員分配給組織刊殉。
對端節(jié)點具有通過特定證書頒發(fā)機構通過數(shù)字證書分配給他們的身份標識。你可以在本指南的其他地方閱讀有關 X.509 數(shù)字證書如何工作的更多信息州胳，但就目前而言记焊，數(shù)字證書就像是 ID 卡，可以提供有關對端節(jié)點的大量可驗證信息栓撞。網(wǎng)絡中的每個對端節(jié)點都由其所屬組織的管理員分配了數(shù)字證書遍膜。
當對端節(jié)點連接到一個通道，它的數(shù)字證書通過通道 MSP 標識其所屬的組織瓤湘。在此示例中瓢颅，P1 和 P2 是由有 CA1 頒發(fā)的身份標識。通道 C 根據(jù)其通道配置中的策略弛说，確定應該使用 ORG1.MSP 將來自 CA1 的身份標識與 Org1 關聯(lián)挽懦。同樣，P3 和 P4 被 ORG2.MSP 標識為 Org2 的一部分木人。
每當對端節(jié)點使用通道連接到區(qū)塊鏈網(wǎng)絡時巾兆，通道配置中的策略都會使用對端節(jié)點的身份標識來確定其權利猎物。身份標識到組織的映射由稱為成員資格服務提供商 (Membership Service Provider, MSP) 的組件提供 - 它確定如何將對端節(jié)點分配給特定組織中的特定角色，并因此獲得對區(qū)塊鏈資源的適當訪問角塑。此外蔫磨，對端節(jié)點只能由單個組織擁有，因此與單個 MSP 關聯(lián)圃伶。我們將在本節(jié)的后面部分詳細了解對端節(jié)點訪問控制堤如，并且在本指南的其他部分中將有一個完整的關于 MSP 和訪問控制策略的部分。但就目前而言窒朋，可以將 MSP 視為在區(qū)塊鏈網(wǎng)絡中的個人身份和特定組織角色之間提供鏈接搀罢。
離題一會兒，對端節(jié)點以及一切從他們的數(shù)字證書和 MSP 與區(qū)塊鏈網(wǎng)絡交互獲取其組織的身份侥猩。對端節(jié)點榔至，應用程序，終端用戶欺劳，管理員和交易排序器唧取，必須有一個身份標識和相關的 MSP，如果他們想與區(qū)塊鏈網(wǎng)絡交互划提。我們將使用身份標識與區(qū)塊鏈網(wǎng)絡交互的每個實體命名為主體 (principal)枫弟。你可以在本指南中的其他地方了解更多有關主體和組織的信息，但是到目前為止鹏往，你所了解的知識還遠遠不夠淡诗，可以繼續(xù)理解對端節(jié)點！
最后伊履，請注意韩容，對端節(jié)點的物理位置并不重要 - 它可以位于云中，也可以位于組織之一擁有的數(shù)據(jù)中心中唐瀑，也可以位于本地計算機上 - 與之相關聯(lián)的身份標識將其標識為由特定組織擁有群凶。在上面的示例中，P3 可以托管在 Org1 的數(shù)據(jù)中心中介褥，但是只要與它關聯(lián)的數(shù)字證書由 CA2 頒發(fā)座掘，那么它就由 Org2 擁有。
7. 對端節(jié)點和交易排序器
我們已經(jīng)看到柔滔，對端節(jié)點構成了區(qū)塊鏈網(wǎng)絡溢陪，托管帳本和智能合約的基礎，可以由對端節(jié)點連接的應用程序查詢和更新睛廊。但是形真，應用程序和對端節(jié)點彼此交互以確保每個對端節(jié)點的帳本保持一致的機制是由稱為交易排序器 (orderer) 的特殊節(jié)點來確保的，現(xiàn)在我們轉向這些節(jié)點。
更新交易與查詢交易完全不同咆霜，因為單個對端節(jié)點自身無法更新帳本 - 更新需要網(wǎng)絡中其他對端節(jié)點的同意邓馒。對端節(jié)點要求網(wǎng)絡中的其他對端節(jié)點批準帳本更新，然后才能將其應用于對端節(jié)點的本地帳本蛾坯。此過程稱為共識光酣，與簡單查詢相比，此過程需要更長的時間才能完成脉课。但是救军，當所有需要批準交易的對端節(jié)點都批準了該交易并將交易提交到帳本時，對端節(jié)點將通知其連接的應用程序帳本已更新倘零。在本部分中唱遭，你將獲得有關對端節(jié)點和交易排序器如何管理共識過程的更多詳細信息。
具體來說呈驶，想要更新賬本的應用程序涉及 3 個階段的過程拷泽，這確保了區(qū)塊鏈網(wǎng)絡中的所有對端節(jié)點都保持其賬本彼此一致。在第一階段袖瞻，應用程序與背書對端節(jié)點 (endosring peer) 的子集一起工作司致，每個背書對端節(jié)點都向應用程序提供對賬本更新提案的背書，但不將提案的更新應用于其賬本副本虏辫。在第二階段蚌吸，將這些單獨的背書 (endorsement) 作為交易收集在一起锈拨，并打包成區(qū)塊砌庄。在最后階段，這些區(qū)塊被分配回每個對端節(jié)點奕枢，在將每個交易應用于該對端節(jié)點的帳本副本之前娄昆，都已經(jīng)對其進行了驗證。
正如你將看到的缝彬，交易排序器節(jié)點是此過程的核心萌焰，所以讓我們更詳細地研究一下應用程序和對端節(jié)點如何使用交易排序器來生成賬本更新，這些更新可以一致地應用于分布式復制賬本谷浅。
7.1 第 1 階段 - 提案
交易工作流程的第 1 階段涉及應用程序和一組對端節(jié)點之間的交互 - 它不涉及交易排序器扒俯。第 1 階段僅涉及一個應用程序，這個應用程序請求不同組織的背書對端節(jié)點 (endorsing peer) 同意提案的鏈碼調用結果一疯。
從第 1 階段開始撼玄，應用程序會生成一個交易提案，然后將其發(fā)送給每個必需的對端節(jié)點組以進行背書墩邀。然后掌猛，這些背書對端節(jié)點中的每一個都使用交易提案獨立執(zhí)行鏈碼以生成交易提案響應。它不會將此更新應用于帳本眉睹，而只是對其進行簽名并將其返回給應用程序荔茬。一旦應用程序收到了足夠數(shù)量的已簽名提案響應废膘，交易流程的第 1 階段便完成了。讓我們更詳細地研究這個階段慕蔚。
交易提案由返回提案響應背書的對端節(jié)點獨立執(zhí)行丐黄。在此示例中，應用程序 A1 生成交易 T1 提議 P孔飒，并將其發(fā)送到通道 C 上的對端節(jié)點 P1 和對端節(jié)點 P2孵稽。P1 使用交易 T1 提案 P 執(zhí)行 S1 生成交易 T1 響應 R1 并由 E1 背書。P2 獨立地使用交易 T1 提案 P 執(zhí)行 S1十偶，并生成交易 T1 響應 R2菩鲜，并由 E2 背書。應用程序 A1 收到兩個對交易 T1 的響應背書惦积，即 E1 和 E2接校。
在初始化階段，應用程序選擇一組對端節(jié)點以生成一組提案的賬本更新狮崩。應用程序選擇了哪些對端節(jié)點蛛勉？好吧，這取決于背書策略 (為鏈碼定義)睦柴，背書策略 (endorsement policy) 定義了需要在網(wǎng)絡接受之前對提案的賬本更改進行背書的組織集合诽凌。從字面上看，這就是達成共識的意思 - 每個重要組織都必須已批準提案的帳本更改坦敌，然后才能將其接受到任何對端節(jié)點的帳本中侣诵。
對端節(jié)點通過添加其數(shù)字簽名并使用其私鑰對整個有效負載進行簽名來背書提案響應。此背書可以隨后用于證明該組織的對端節(jié)點產生了特定的響應狱窘。在我們的示例中杜顺，如果對端節(jié)點 P1 由組織 Org1 擁有，則背書 E1 對應于一個數(shù)字證明蘸炸，即 “由 Org1 的對端節(jié)點 P1 提供了賬本 L1 上的交易 T1 的響應 R1躬络！”。
當應用程序收到足夠的對端節(jié)點簽署的提案響應時搭儒，第 1 階段結束穷当。我們注意到，對于同一個交易提案淹禾，不同的對端節(jié)點可以向應用程序返回不同的因此不一致的交易響應馁菜。可能只是結果是在不同時間使用不同狀態(tài)的帳本在不同的對端節(jié)點上生成的稀拐，在這種情況下火邓，應用程序可以簡單地請求更新的提案響應。雖然出現(xiàn)這種結果的可能性較小，但更嚴重的是結果可能會有所不同铲咨，因為鏈碼是不確定的躲胳。非確定性是鏈碼和賬本的敵人，如果發(fā)生纤勒，則表明提案的交易存在嚴重問題坯苹，因為顯然不能將不一致的結果應用于賬本。單個對端節(jié)點無法知道他們的交易結果是不確定的摇天，因此必須先收集交易響應以進行比較粹湃，然后才能檢測到不確定性。(嚴格來說泉坐，這還不夠为鳄，但是我們將討論推遲到交易部分，在此部分將詳細討論不確定性腕让。)
在第 1 階段結束時孤钦，應用程序可以隨意丟棄不一致的交易響應，從而有效地盡早終止交易工作流纯丸。稍后我們將看到偏形，如果應用程序嘗試使用一組不一致的交易響應來更新帳本，則它將被拒絕觉鼻。
7.2 第 2 階段 - 將交易排序和打包成區(qū)塊
交易工作流程的第 2 階段是打包階段俊扭。交易排序器對于此過程至關重要 - 它從許多應用程序接收包含交易提案響應背書的交易，并將交易排序進區(qū)塊坠陈。有關排序和打包階段的更多詳細信息萨惑，請查看我們有關 排序階段的概念性信息。
7.3 第 3 階段 - 驗證和提交
在第 2 階段結束時畅姊，我們看到交易排序器負責簡單但至關重要的過程咒钟，這些過程包括收集提案的交易更新吹由，進行排序并將它們打包成區(qū)塊若未，以便分發(fā)給對端節(jié)點。
交易工作流程的最后階段涉及從交易排序器到對端節(jié)點的區(qū)塊分發(fā)和后續(xù)驗證倾鲫，在這里可以將它們應用于帳本粗合。具體來說，在每個對端節(jié)點乌昔，對一個區(qū)塊中的每個交易都進行驗證隙疚，以確保在將其應用于賬本之前，所有相關組織都一致認可該交易磕道。失敗的交易將保留以進行審核供屉，但不會應用于帳本。
交易排序器節(jié)點的第二個作用是將區(qū)塊分配給對端節(jié)點。在該示例中伶丐，交易排序器 O1 將區(qū)塊 B2 分配給對端節(jié)點 P1 和對端節(jié)點 P2悼做。對端節(jié)點 P1 處理區(qū)塊 B2，從而將新區(qū)塊添加到 P1 上的帳本 L1哗魂。并行地肛走，對端節(jié)點 P2 處理區(qū)塊 B2，導致將新區(qū)塊添加到 P2 上的帳本 L1录别。一旦該過程完成朽色，賬本 L1 就已在對端節(jié)點 P1 和 P2 上進行了一致更新，并且每個賬本可以通知連接的應用程序交易已被處理组题。
第 3 階段從交易排序器將區(qū)塊分配給與其連接的所有對端節(jié)點開始葫男。對端節(jié)點通過通道連接到交易排序器，以便在生成新區(qū)塊時崔列，將向連接到交易排序器的所有對端節(jié)點發(fā)送新區(qū)塊的副本腾誉。每個對端節(jié)點將獨立地但與通道上的每個其他對端節(jié)點以完全相同的方式處理此區(qū)塊。這樣峻呕，我們將看到帳本可以保持一致利职。還值得注意的是，并非每個對端節(jié)點都需要連接到交易排序器瘦癌，對端節(jié)點可以使用 gossip 協(xié)議將區(qū)塊級聯(lián)到其他對端節(jié)點猪贪，后者(?)也可以獨立處理它們。但是讯私，讓我們將討論留給其他時間热押！
收到區(qū)塊后，對端節(jié)點將按照它出現(xiàn)在區(qū)塊中的順序處理每個交易斤寇。對于每筆交易桶癣，每個對端節(jié)點將根據(jù)生成交易的鏈碼的背書策略，驗證該交易是否已被所需的組織背書娘锁。例如牙寞，某些交易可能只需要由單個組織背書，而其他交易可能需要多次背書才能被視為有效莫秆。此驗證過程將驗證所有相關組織均已產生相同的輸出或結果间雀。還要注意，此驗證與第 1 階段中的背書檢查不同镊屎，在第 1 階段中惹挟，應用程序是從背書對端節(jié)點接收響應并做出發(fā)送提案交易的決定。如果應用程序通過發(fā)送錯誤的交易違反了背書策略缝驳，則對端節(jié)點仍然可以在第 3 階段的驗證過程中拒絕交易归苍。
如果交易已正確背書驳规，則對端節(jié)點將嘗試將其應用于帳本。為此，對端節(jié)點必須執(zhí)行帳本一致性檢查，以驗證生成提案更新時帳本的當前狀態(tài)與帳本的狀態(tài)兼容。即使交易已得到完全認可，這也不總是可能的。例如，另一筆交易可能已更新賬本中的同一資產脓恕，因此該交易更新不再有效史简，因此無法再應用。這樣，由于每個對端節(jié)點遵循相同的驗證規(guī)則暂雹，因此它們在整個網(wǎng)絡中保持一致。
對端節(jié)點成功驗證了每個單獨的交易后，它將更新帳本庄蹋。失敗的交易不應用于帳本，但保留它們以進行審核倦西，與成功的交易一樣能真。這意味著對端節(jié)點區(qū)塊幾乎與從交易排序器接收到的區(qū)塊完全相同，除了該區(qū)塊中每個交易的有效或無效指示符扰柠。
我們還注意到粉铐，第 3 階段不需要運行鏈碼 - 僅在第 1 階段已經(jīng)完成，這很重要卤档。這意味著鏈碼僅在背書節(jié)點上可用蝙泼，而不是在整個區(qū)塊鏈網(wǎng)絡上可用。這通常很有用劝枣，因為它可以使鏈碼的邏輯對背書組織保密汤踏。這與鏈碼的輸出 (交易提案響應) 相反织鲸，鏈碼的輸出與通道中的每個對端節(jié)點共享，無論他們是否背書交易溪胶。支持對端節(jié)點的這種專業(yè)化旨在幫助實現(xiàn)可伸縮性搂擦。
最后，每次將一個區(qū)塊提交給對端節(jié)點的帳本時哗脖，該對端節(jié)點都會生成一個適當?shù)氖录偬摺^(qū)塊事件包括完整的區(qū)塊內容，而區(qū)塊交易事件僅包含摘要信息才避，例如區(qū)塊中的每個交易是否已驗證或無效橱夭。鏈碼執(zhí)行產生的鏈碼事件也可以在此時發(fā)布。應用程序可以注冊這些事件類型工扎，以便在事件發(fā)生時得到通知徘钥。這些通知結束了交易工作流的第 3 階段即最后階段。
總而言之肢娘，第 3 階段將看到由交易排序器生成的區(qū)塊始終應用于帳本呈础。嚴格按順序將交易劃分為區(qū)塊，每個對端節(jié)點都可以驗證交易更新是否在整個區(qū)塊鏈網(wǎng)絡中得到一致應用橱健。
7.4 交易排序器和共識
交易流程的整個過程稱為共識而钞，因為在交易排序器的調解下，所有對端節(jié)點都已就交易的順序和內容達成了共識拘荡。共識是一個多步驟的過程臼节，僅當過程完成時才通知應用程序賬本更新，這可能在不同的對端節(jié)點上略有不同珊皿。
我們將在以后的交易排序器主題中更詳細地討論交易排序器网缝，但現(xiàn)在，將交易排序器視為從應用程序收集和分發(fā)提案的賬本更新以供對端節(jié)點驗證并包含在賬本中的節(jié)點蟋定。
就是這樣粉臊！現(xiàn)在，我們已經(jīng)完成了對對端節(jié)點及其與 Fabric 相關的其他組件的瀏覽驶兜。我們已經(jīng)看到扼仲，在許多方面，對端節(jié)點是最基本的元素 - 它們形成網(wǎng)絡抄淑，托管鏈碼和帳本屠凶，處理交易提案和響應，并通過始終向其應用交易更新來使帳本保持最新肆资。
Reference
- Docs ? Key Concepts ? Peers, https://hyperledger-fabric.readthedocs.io/en/release-1.4/peers/peers.html
- Docs ? Key Concepts ? Smart Contracts and Chaincode, https://hyperledger-fabric.readthedocs.io/en/release-1.4/smartcontract/smartcontract.html
- Docs ? Architecture Reference ? Transaction Flow, https://hyperledger-fabric.readthedocs.io/en/release-1.4/txflow.html
- Docs ? Key Concepts ? The Ordering Service, https://hyperledger-fabric.readthedocs.io/en/release-1.4/orderer/ordering_service.html#phase-two-ordering-and-packaging-transactions-into-blocks
項目源代碼
項目源代碼會逐步上傳到 Github矗愧，地址為 https://github.com/windstamp。
Contributor
- Windstamp, https://github.com/windstamp
