節點
區塊鏈網絡主要由一組 Peer 節點（或者簡稱節點）組成。節點託管着賬本和智能合約，因此節點是網絡的基本成分。回想一下，賬本記錄着由智能合約（ Hyperledger Fabric 的智能合約儲存在鏈碼中，稍後將詳細介紹）生成的所有交易，並且不可篡改。智能合約和賬本分別用於封裝網絡中的共享進程和共享信息*。因此節點是瞭解 Fabric 網絡的良好開端。
區塊鏈網絡的其他元素也很重要：賬本和智能合約、排序節點、策略、通道、應用程序、組織、身份和成員，您可以在各元素的專屬章節中閱讀更多相關信息。本節主要討論節點及其與 Fabric 網絡中其他元素的關係。
區塊鏈網絡由節點組成，每個節點都可以保存賬本副本和智能合約副本。在本例中，網絡 N 由節點 P1、P2 和 P3 組成，它們各自維護分佈式賬本 L1 的副本。P1、P2 和 P3 使用相同的鏈碼 S1 來訪問各自的分佈式賬本L1的副本。
節點可以被創建、啓動、停止、重新配置甚至被刪除。節點公開了一組 API（Application Programming Interface 應用程序編碼端口），以供管理員和應用程序與 API 提供的服務進行交互。下文中將詳細談到這些服務。
術語
Fabric 通過一種叫做鏈碼的技術概念來實現智能合約，簡單來說，鏈碼就是一段訪問賬本的代碼，它是用網絡支持的編程語言編寫的。在本主題中，我們將使用鏈碼這個術語，但是如果您更習慣智能合約這個名字也可以把它看成智能合約。它們其實是一回事！如果您想了解更多關於鏈碼和智能合約的信息，請查看我們關於智能合約和鏈碼的文檔。
賬本和鏈碼
讓我們來更仔細地研究一下節點。我們可以看到，節點託管賬本和鏈碼。更準確地說，節點實際上託管着賬本和鏈碼的副本。注意，這是故意在 Fabric 網絡中造成副本冗餘，它避免了單點故障。下文中我們將瞭解更多關於區塊鏈網絡分佈式和去中心的特性。
節點託管賬本和鏈碼的副本。在本例中，P1 託管了賬本 L1 的副本和鏈碼 S1 的副本。單個節點上可以託管許多賬本和鏈碼。
因爲節點是賬本和鏈碼的宿主，所以應用程序和管理員必須與節點進行交互才能訪問賬本和鏈碼。這就是爲什麼節點被視爲構成 Fabric 網絡最基本的構件。首次創建節點時，節點上既沒有賬本也沒有鏈碼。稍後我們將看到如何在節點上創建賬本和安裝鏈碼。
多賬本
一個節點能夠保存多個賬本，這使得靈活的系統設計成爲可能，因此非常有幫助。最簡單的節點配置是一個節點只管理一個賬本，但是在有需要時，一個節點保存兩個或多個賬本是絕對合適的。
一個節點保存多個賬本。節點保存一個或多個賬本，並且每個賬本都具有零個或多個適用於它們的鏈碼。在這個例子中，我們可以看到節點 P1 保存着賬本 L1 和 L2。要訪問賬本 L1需使用鏈碼 S1 。而要訪問賬本 L2 可使用鏈碼 S1 和 S2 。
雖然節點只保存賬本副本而不保存訪問賬本的鏈碼副本的情況也存在，但是很少有節點是以這種方式配置的。絕大多數節點都會安裝至少一個鏈碼，以用來查詢或更新該節點上的賬本副本。值得一提的是，無論用戶是否安裝了供外部應用程序使用的鏈碼，節點始終都有特殊的系統鏈碼。本主題不詳細討論這些。
多鏈碼
一個節點所擁有的賬本數量和能夠訪問這些賬本的鏈碼數量之間沒有固定的關係。一個節點可能擁有許多鏈碼以及許多可供這些鏈碼訪問的賬本。
上面這個例子顯示的是一個節點保存了多個鏈碼。每個賬本可被多個鏈碼訪問。在這個示例中，我們可以看到節點 P1 保存着賬本 L1 和 L2，其中 L1 由鏈碼 S1 和 S2 訪問，而 L2 由 S1 和 S3 訪問。我們可以看到 S1 既可以訪問 L1 也可以訪問 L2。
稍後我們將簡單談到爲什麼 Fabric 中的通道概念對於在節點上保存多個賬本或多個鏈碼來說非常重要。
應用程序和節點
現在我們將展示的是應用程序如何與節點交互來訪問賬本。賬本查詢交互涉及了應用程序和節點之間簡單的三步對話；賬本更新交互稍微複雜一些，需要兩個額外的步驟。爲了幫助您開始使用 Fabric，我們稍微簡化了這些步驟，但是不要擔心——需要你理解的最關鍵點在於應用程序和節點之間進行賬本查詢和賬本更新的交易類型之間的區別。
當應用程序需要訪問賬本和鏈碼時，它們總是連接到節點上。Fabric 軟件開發工具包（SDK）讓程序員的上述工作變得簡單，首先，SDK 的應用程序編程接口（API） 讓應用程序連接到節點上，隨後調用鏈碼來生成交易，接着向網絡提交交易，網絡將對這些交易進行排序並將其提交到分佈式賬本上，最後當這一過程完成時，應用程序將接收到對應的事件。
通過與一個節點連接，應用程序可以執行鏈碼來查詢或更新賬本。賬本查詢交易的結果會立即返回，而賬本更新交易涉及了應用程序、節點和排序服務之間更復雜的交互。讓我們更詳細地研究一下。
節點與排序服務一起發揮作用，保證每個節點上的賬本都是最新的。在本例中，應用程序 A 連接到賬本 P1 上並調用鏈碼 S1 來查詢或更新 L1。 P1 調用 S1 來生成一個包含查詢結果或者賬本擬更新的提案響應。應用程序 A 接收到提案響應，對於查詢來說，流程到這裏就已經完成了。而對於更新來說，A 會基於所有響應生成一個交易，並將其發送到 排序服務 O1 進行排序。O1 將網絡上的所有交易收集到區塊中並分發給包括 P1 在內的所有節點。P1 對交易進行驗證，隨後將其提交到賬本 L1 上。一旦 L1 更新完畢，P1 會生成一個事件，隨後 A 收到這一事件，標誌着整個過程結束。
因爲節點的本地賬本副本中包含了賬本查詢所需的全部信息，所以節點可以立即將查詢結果返回給應用程序。節點從不通過與其他節點協商來響應應用程序發出的查詢。但是，應用程序可以連接到一個或多個節點上來執行查詢；例如，在多個節點之間驗證結果，或者如果懷疑信息不是最新的，可以從另一個節點上檢索最新的結果。在圖中，您可以看到賬本查詢是只需要三個步驟，非常簡單。
更新交易的開始方式和查詢交易的一樣，但是多了兩個額外的步驟。雖然賬本更新應用程序和賬本查詢應用程序一樣，也是連接到節點上來調用鏈碼的，但不同的是，單個節點無法執行賬本更新，這是由於其他節點必須首先同意這一改變，我們把這個過程稱爲共識。因此，節點嚮應用程序返回一個擬更新——該節點將在其他節點事先同意的情況下應用該更新。第一個額外步驟（步驟4）要求應用程序向全網絡中的所有節點發送一組適當的擬更新，以作爲向各自賬本提交的交易。該步驟是由應用程序實現的，排序服務將交易打包成區塊，並將這些交易區塊分發到網絡中所有的節點上，節點在將這些交易應用到各自本地賬本副本之前會對其進行驗證。如步驟5所示，由於整個排序服務需要一些時間（幾秒鐘）才能完成，因此應用程序不會同時收到通知。
下文中將繼續討論排序服務的詳細特性，想要深入瞭解此流程，請參閱交易流程主題。
節點和通道
雖然本節討論的是節點而不是通道，但還有必要花點時間來了解一下節點是如何通過通道來彼此交互以及與應用程序交互的，通道是區塊鏈網絡的一種機制，有了它區塊鏈網絡中的一組組件就能夠私下通信和交易。
這些組件通常是節點、排序節點和應用程序，通過加入一個通道，這些組件同意協作共享和管理與該通道關聯的相同的賬本副本。從概念上講，您可以將通道看作類似於朋友組（儘管通道的成員並不需要是朋友！）一個人可能有幾組朋友，每組朋友都有他們一起做的活動。這些羣體可能是完全獨立的（一羣工作上的朋友對比於一羣愛好上的朋友），或者他們之間可能有交叉。但不管怎樣，每個組都是自己的實體，具有某種“規則”。
通道允許一組特定的節點和應用程序在區塊鏈網絡中彼此通信。在本例中，應用程序 A 可以使用通道 C 直接與節點 P1和 P2通信。你可以把通道看成特定應用程序和節點之間通信的通道。（爲了簡單起見，此圖中沒有顯示排序節點，但是必須在一個正常運行的網絡中顯示排序節點。）
我們看到通道的存在方式與節點不同——將通道看作由物理節點集合形成的邏輯結構更合適。節點爲通道的訪問和管理提供控制點，理解這一點非常重要。
節點和組織
既然您已經清楚了節點及其與賬本、鏈碼和通道的各自關係，那您將能夠看到多個組織是如何組合在一起形成區塊鏈網絡的。
區塊鏈網絡的管理者是一系列組織，而不是單個組織。因爲節點屬於這些組織，並且是這些組織與網絡的連接點，所以它對於這種分佈式網絡的構建至關重要。
區塊鏈網絡中的節點和多個組織。區塊鏈網絡是由不同組織所擁有和提供的節點構建而成的。在這個例子中，我們看到四個組織貢獻了八個節點來組成一個網絡。通道 C 連接了網絡 N 中的五個節點—— P1、P3、P5、P7 和 P8。這些組織擁有的其他節點尚未連接到此通道，但它們通常至少連接到一個其他通道上。由特定組織開發的應用程序將連接到他們自己組織的節點以及不同組織的節點上。同樣，爲了簡單起見，此圖中沒有顯示排序節點。
務必瞭解區塊鏈網絡的形成過程，這一點十分重要。區塊鏈網絡是由多個向其提供資源的組織形成和管理的。節點是我們在本主題中討論的資源，但是組織提供的資源不僅僅是節點。這裏有一個原則——如果組織不向網絡貢獻自己的資源，那麼網絡根本就不會存在。此外，區塊鏈網絡隨着協作組織所提供資源的增減而增長和收縮。
您可以看到（除了排序服務之外）沒有集中的資源——在上面的示例中，如果組織沒有將自己的節點貢獻給網絡 N ，那麼N將不存在。這反映了以下事實：除非各組織把構成網絡的資源貢獻出來，否則網絡在任何意義上都不存在。此外，網絡並不依賴於任何一個單獨的組織——不管其他組織加入或離開，只要還有一個組織，網絡就還會繼續存在。這就是網絡去中心化的核心。
就像上邊的例子，不同的組織中的應用程序可能相同也可能不同。這是因爲一個組織完全取決於它的應用程序如何處理其節點的賬本副本。這意味着雖然各組織的節點保存着完全相同的賬本數據，但是應用程序和呈現邏輯都可能會因組織而異。
應用程序可以連接到其所在組織上的節點，也可以連接到另一個組織上的節點，這取決於所需賬本交互的性質。對於賬本查詢交互來說，應用程序通常連接到它們自己組織的節點上。對於賬本更新交互來說，下文中我們將談到爲什麼應用程序需要連接到代表每個必須對賬本更新背書的組織的節點上。
節點和身份
既然您已經清楚了來自不同組織的節點是如何聚集在一起形成區塊鏈網絡的，那麼有必要花一些時間來了解組織管理員是如何將節點分配到組織中去的。
節點會被分配一個身份，這一身份是由特定證書授權中心頒發給它們的數字證書賦予的。本指南的其他部分講解了更多關於 X.509 數字證書工作原理的信息，但是就目前而言，可以將數字證書看作是一個 ID 卡，它提供了大量關於節點的可驗證信息。網絡中的每個節點都由所屬組織的管理員分配一個數字證書。
當節點連接到通道時，節點的數字證書通過該通道的 MSP 識別其所屬組織。在這個例子中，P1 和 P2 的身份由證書授權中心 CA1 頒佈。通道 C 在其通道配置的策略中規定由 CA1 頒發的身份應該使用組織1的 MSP （ORG1.MSP） 來與 Org1 關聯。類似的，P3 和 P4 由 ORG2.MSP 識別爲 Org2 的一部分。
當一個節點使用通道連接到區塊鏈網絡時，通道配置中的策略使用節點的身份來確定其權限。身份與組織之間的映射是由一個名爲成員服務提供者（MSP）的組件建立的——它規定了如何在特定組織中將一個特定角色分配給一個節點，並讓節點相應地獲得對區塊鏈資源的適當訪問權。此外，因爲節點只能由單個組織擁有，所以它與單個 MSP 關聯。稍後我們將談到更多關於節點訪問控制的內容，本指南的其他部分有一整節是關於 MSP 和訪問控制策略的。但是現在，可以將 MSP 看作是在區塊鏈網絡中提供個人身份和特定組織角色之間的鏈接。
稍微討論一個額外的話題，節點以及所有與區塊鏈網絡交互的東西都從它們的數字證書和 MSP 中獲得它們的組織身份。如果節點、應用程序、最終用戶、管理員和排序服務想要與區塊鏈網絡進行交互，那麼它們必須具有身份和關聯的 MSP。我們爲使用身份與區塊鏈網絡交互的每個實體提供了一個名稱——主體（principal）。在其他章節中，您可以瞭解更多關於主體和組織的信息，但是現在你已經有足夠的知識來繼續學習節點了！
最後，要注意的是節點位於哪裏並不重要——它可以位於雲端，或者位於一個組織的數據中心中，又或者位於一個本地機器上-——決定節點所述組織的是與該節點相關的數字證書。在我們上面的例子中，P3 可以位於 Org1 的數據中心，但是隻要與 P3 相關聯的數字證書是由 CA2 頒發，那麼 P3 就屬於 Org2。
節點和排序節點
我們已經看到，節點構成了區塊鏈網絡的基礎，它承載着賬本和智能合約，與節點相連接的應用程序可以對賬本和智能合約進行查詢和更新。然而，應用程序和節點使用一種機制進行彼此交互以確保每個節點上的賬本始終都彼此一致，這一機制是由由名爲排序節點的特殊節點來協調的，現在我們就來討論這些節點。
更新交易與查詢交易有很大的不同，這是因爲光靠單個節點無法完成賬本更新（更新需要網絡中其他節點的同意）。一個節點需要等到其他節點對一項賬本更新交易表示同意之後才能將該交易實行到自己的本地賬本上。這個過程稱叫做共識，比起簡單的查詢，共識需要的時間更長。但是，當所有需要批准某交易的節點都已批准該交易，並且已將該交易提交到賬本上時，那麼各節點會把賬本已經更新的消息通知給與其連接的應用程序。下文將繼續詳細談論節點和排序節點是如何管理共識過程的。
具體來說，想要更新賬本的應用程序會涉及到三個步驟，這些步驟確保了區塊鏈網絡中的所有節點能保持彼此賬本始終一致。
- 第一步，應用程序與一組背書節點合作，每個背書節點都向該應用程序提供對擬賬本更新的背書，但是並不會把該擬更新應用到自己的賬本副本上。
- 第二步，把各背書節點做出的背書收集起來作爲交易打包成區塊。
- 最後一步，將這些區塊分發給每個節點，節點會對每項交易進行驗證，隨後將交易提交到各自賬本副本上。
正如下文中你將看到的，排序節點是上述過程的核心，所以讓我們來深入研究一下應用程序和節點如何使用排序節點生成賬本更新，而這些更新可被持續應用到一個分佈式、可複製的賬本上。
第一階段：提案
交易流程的第一階段涉及的是一個應用程序和一組節點之間的交互，並不涉及排序節點。階段一發生的只是：應用程序請求不同組織的背書節點對擬鏈碼調用的結果做出同意。
要開始第一階段，應用程序必須先生成一個交易提案，並將該提案發送給每個需要對交易做出背書的節點進行背書。隨後，每個背書節點都使用該交易提案獨立地執行一個鏈碼，以生成交易提案響應。背書節點不會將此更新應用到賬本上，它只是簡單地對交易進行簽名並將其返回給應用程序。一旦應用程序收到足夠數量的簽名提案響應，那麼交易流程的第一階段就完成了。讓我們來更詳細地研究一下這個階段。
返回已背書提案響應的各個節點會獨立執行交易提案。在本例中，應用程序 A1 生成交易 T1 提案 P，並將其發送給通道 C 上的節點 P1 和 P2。P1 使用交易 T1 提案 P 調用鏈碼 S1，以生成 交易 T1 響應 R1，並且 P1 通過 E1 對該響應進行背書。P2 獨立使用交易 T1 提案 P 來執行 S1，以生成交易 T1 響應 R2，該響應是由 E2 背書的。應用程序 A1 收到交易 T1 發來的兩個已背書的響應，即 E1 和 E2。
最初，應用程序選擇一組節點來生成一些擬賬本更新。應用程序會選擇哪些節點呢？這取決於背書策略（爲鏈碼定義的），背書策略定義了一羣需要在網絡接受某項擬賬本更新之前對其作出背書的組織。這就是達成共識的真正含義——在任何節點的賬本接受擬賬本更新之前，所有相關組織必須對該擬賬本更新進行背書。
節點通過添加自己的數字簽名來對提案響應進行背書，並使用自己的私鑰爲整體進行簽名。該背書隨後可被用於證明此組織的節點生成了一個特定響應。在我們的示例中，如果節點 P1 屬於組織 Org1，則背書 E1 對應了一個數字證明——“賬本 L1 上的交易 T1 響應 R1 是由 Org1 的 節點 P1 提供的！”。
節點通過添加其數字簽名，並使用其私鑰對整個有效負載簽名，來背書提案響應。此背書隨後可用於證明該組織的節點生成了特定的響應。在我們的示例中，如果節點 P1 屬於組織 Org1，則背書 E1 對應一個數字證明——“在賬本 L1 上的交易 T1 的反饋 R1 已經被 Org1 的 peer P1 提供了！”。
當應用程序收到足夠數量節點發來的簽名提案響應時，第一階段就結束了。我們注意到，對於相同的交易提案，不同的節點可能會嚮應用程序返回不同的，因此也就不一致的交易響應。這獲許只是因爲各節點生成交易響應的時間不同，賬本的世界狀態也不同，在這種情況下，應用程序只需請求一個更新版本的提案響應即可；又或許是因爲鏈碼是不確定的，這種情況發生的可能性不太大，但是一旦發生，後果極其嚴重。不確定性是鏈碼和賬本的敵人，如果發生這種情況，則表明提案的交易存在嚴重問題，因爲不一致的結果顯然不能適用於賬本。單個節點無法知道自己的交易結果是非確定性的——只有將所有交易響應收集在一起進行比較才能發現不確定性。（嚴格來說，這些依然不夠，不過我們暫且不繼續往下談，後續在交易模塊會深入探討非確定性的問題。）
在第一階段的最後，應用程序可以按照自己的醫院丟棄不一致的交易響應，從而有效地提前終止交易流程。稍後我們將看到，如果應用程序試圖使用一組不一致的交易響應來更新賬本，它將被拒絕。
第二階段：排序和把交易打包成區塊
交易流程的第二階段是打包階段。排序節點是該流程的關鍵——多個應用程序向排序節點發送交易，其中包含了已背書的交易提案響應，隨後排序節點將這些交易排序進區塊。有關排序和打包階段的更多細節，請查看排序階段的概念信息。
第三階段：驗證和提交
在階段二的末尾，我們看到排序節點負責的是對提案的交易更新進行收集、排序、打包進區塊，以便分發給各節點，這些任務雖簡單但卻十分關鍵。
交易流程的最後一個階段涉及到從排序節點到 Peer 節點的區塊的分發和隨後的驗證，節點可將這些交易應用到賬本上。具體來說，所有節點都會對一個區塊內的每一筆交易進行驗證，以確保這些交易在應用到賬本上之前已經得到所有相關組織的背書。未成功的交易會被留下來進行審計，但不會提交到賬本上。
排序節點的第二個角色是將區塊分發給 peer 節點。在本例中，排序節點 O1 將區塊 B2 分配給節點 P1 和 P2。節點 P1 處理區塊 B2，最終將一個新的區塊添加到節點 P1 的賬本 L1 上。同時，節點 P2 處理區塊 B2，最終將一個新的區塊添加到節點 P2 的賬本 L1 上。一旦這個過程結束，節點 P1和 P2 各自的賬本 L1 就已經一致更新了，並且 P1 和 P2 都會把交易已處理完畢的消息通知給與它們連接的應用程序。
階段三從排序節點將區塊分發給與其連接的所有 peer 節點開始。peer 節點和通道上的排序節點相連接，這樣一來，當生成一個新區塊時，連接到排序節點的所有 Peer 節點都將收到這個新區塊的副本。隨後每個 Peer 節點獨立地處理該新區塊，不過通道上各節點的處理方式完全相同。因此，我們將看到各節點的賬本依然保持一致。同樣值得注意的是，並不是每個 peer 節點都需要連接到一個排序節點上——peer 節點可以使用 gossip 協議將區塊信息發送給其他（未連接到排序節點的） Peer 節點，這些 Peer 節點在收到信息後也可以獨立地處理新區塊。不過我們下次再討論這個問題！
當接收到一個區塊時，節點將按照各交易在區塊中出現的順序依次進行處理。各節點將根據生成交易的鏈碼中的背書策略對每項交易進行驗證，以確保所有交易都已被相關組織背書。例如，某些交易可能只需要一個組織的背書，而另一些交易可能需要多個組織的背書才能被視爲有效。該驗證過程將驗證所有相關組織是否都已經產生了相同的結果。還要注意的是，此驗證與階段一中的背書檢查不同，在背書檢查中，是應用程序接收了背書節點發送的響應，並作出發送提案交易的決定。如果應用程序發送錯誤的交易，違反了背書策略，那麼節點在階段三的驗證環節依然能夠拒絕該交易。
如果一筆交易被正確地背書，節點將試圖把它應用於賬本。爲此，節點必須執行賬本一致性檢查，以驗證賬本的當前狀態與生成提案更新時的賬本狀態是否兼容。兩個狀態可能不總是兼容的，即便交易已經被所有相關組織背書了。例如，另一個交易可能更新了賬本中的相同資產，這就導致前一個交易更新不再有效，因此無法將其應用到賬本上。通過這種方式，每個節點的賬本副本在整個網絡中保持一致，這是因爲它們都遵循相同的驗證規則。
在節點成功地驗證每一筆交易之後，它將更新賬本。節點不會把失敗的交易應用到賬本上，但爲了審計會保留這些交易，就像成功的交易一樣。這意味着節點中的區塊與從排序節點接收到的區塊幾乎完全相同，唯一不同的是節點區塊中的每個交易上都存在有效或無效指示符。
我們還注意到，階段三不需要運行鏈碼，鏈碼運行只發生在階段一，這一點很重要。它意味着鏈碼只需存在於背書節點上，並不要求在整個區塊鏈網絡上都能使用鏈碼。這樣一來，只有參與背書的組織才能看到鏈碼的邏輯，因此這一點通常很有幫助。而鏈碼（交易提案響應）的輸出則與之相反，鏈碼輸出會在通道上的各節點間共享，無論這些節點是否參與了該交易的背書。這種背書節點的特殊設計旨在提升區塊鏈網絡的可擴展性和機密性。
最後，每次將一個區塊提交到節點的賬本上時，該節點都會生成一個適當的事件。區塊事件包括完整的區塊內容，而區塊交易事件只包含總結信息，例如區塊中的每個交易經驗證顯示有效還是無效。鏈碼執行產生的鏈碼事件也可以在這個時候發佈出去。應用程序可以註冊這些事件的類型，以便在這些事件發生時，它可以得到通知。這些通知標誌着交易流程最後一步結束了。
總之，第三階段中，排序節點生成的區塊都被一致地應用於賬本。將交易嚴格排序到區塊中，這使得每個節點都可以驗證交易更新是否在整個區塊鏈網絡中得到一致應用。
排序節點和共識
上述的整個交易流程叫做共識，這是因爲所有節點都已就交易的順序和內容達成一致，排序節點在這個流程中扮演調節者的角色。共識是一個多步驟的過程，只有當流程完成時，應用程序纔會收到賬本更新的通知——在不同的節點上，更新完成的時間可能略有不同。
我們將在以後的排序節點主題中更詳細地討論它，但是現在我們可以先這樣理解排序節點：它從應用程序那裏收集和分發提案的賬本更新，以供節點進行驗證並最終應用到賬本上。
就是這樣！現在我們已經完成了節點以及與 Fabric 相關的其他組件的學習。我們已經看到，節點在很多方面都是最基本的元素——它們組成網絡、託管鏈碼和賬本、處理交易提案和響應，並且與其他節點一致地把交易更新應用到賬本上，從而使賬本的狀態保持最新。