區塊鏈開發專題(比特幣網路是如何構架起來的)__區塊鏈

區塊鏈愛好者（QQ：53016353） 

區塊鏈採用了基於國際互連網（Internet）的P2P（peer-to-peer）網路架構。P2P是指位於同一網路中的每台電腦都彼此對等，各個節點共同提供網路服務，不存在任何“特殊”節點。每個網路節點以“扁平（flat）”的拓撲結構相互連通。在P2P網路中不存在任何服務端（server）、中央化的服務、以及層級結構。P2P網路的節點之間互動運作、協同處理：每個節點在對外提供服務的同時也使用網路中其他節點所提供的服務。P2P網路也因此具有可靠性、去中心化，以及開放性。早期的國際互連網就是P2P網路架構的一個典型用例：IP網路中的各個節點完全平等。當今的互連網架構具有分層架構，但是IP協議仍然保留了扁平拓撲的結構。在區塊鏈之外，規模最大也最成功的P2P技術應用是在檔案分享領域：Napster是該領域的先鋒，BitTorrent是其架構的最新演變。 區塊鏈所採用的P2P網路架構不僅僅是選擇拓撲結構這樣簡單。區塊鏈被設計為一種點對點的數字現金系統，它的網路架構既是這種核心特性的反映，也是該特性的基石。去中心化控制是設計時的核心原則，它只能通過維持一種扁平化、去中心化的P2P共識網路來實現。
“區塊鏈網路”是按照區塊鏈P2P協議啟動並執行一系列節點的集合。除了區塊鏈P2P協議之外，區塊鏈網路中也包含其他協議。例如Stratum協議就被應用於挖礦、以及輕量級或移動端區塊鏈錢包之中。網關（gateway）路由伺服器提供這些協議，使用區塊鏈P2P協議接入區塊鏈網路，並把網路拓展到運行其他協議的各個節點。例如，Stratum伺服器通過Stratum協議將所有的Stratum挖礦節點串連至區塊鏈主網路、並將Stratum協議橋接（bridge）至區塊鏈P2P協議之上。我們使用“擴充區塊鏈網路（extended bitcoin network）”指代所有包含區塊鏈P2P協議、礦池挖礦協議、Stratum協議以及其他串連區塊鏈系統組件相關協議的整體網路結構。
6.2 節點類型及分工
儘管區塊鏈P2P網路中的各個節點相互對等，但是根據所提供的功能不同，各節點可能具有不同的分工。每個區塊鏈節點都是路由、區塊鏈資料庫、挖礦、錢包服務的功能集合。一個全節點（full node）包括如圖6-1所示的四個功能：
 
圖6-1 一個包含四個完整功能的區塊鏈網路節點：錢包、礦工、完整區塊鏈、網路路由節點
每個節點都參與全網路的路由功能，同時也可能包含其他功能。每個節點都參與驗證並傳播交易及區塊資訊，發現並維持與對等節點的串連。在圖6-1所示的全節點用例中，名為“網路路由節點”的橙色圓圈即表示該路由功能。
一些節點保有一份完整的、最新的區塊鏈拷貝，這樣的節點被稱為“全節點”。全節點能夠獨立自主地校正所有交易，而不需藉由任何外部參照。另外還有一些節點只保留了區塊鏈的一部分，它們通過一種名為“簡易支付驗證（SPV）”的方式來完成交易驗證。這樣的節點被稱為“SPV節點”，又叫“輕量級節點”。在如上圖所示的全節點用例中，名為完整區塊鏈的藍色圓圈即表示了全節點區塊鏈資料庫功能。在圖6-3中，SPV節點沒有此藍色圓圈，以示它們沒有區塊鏈的完整拷貝。
挖礦節點通過運行在特殊硬體裝置上的工作量證明（proof-of-work）演算法，以相互競爭的方式建立新的區塊。一些挖礦節點同時也是全節點，保有區塊鏈的完整拷貝；還有一些參與礦池挖礦的節點是輕量級節點，它們必須依賴礦池伺服器維護的全節點進行工作。在全節點用例中，挖礦功能如圖中名為“礦工”的黑色圓圈所示。
使用者錢包也可以作為全節點的一部分，這在案頭區塊鏈用戶端中比較常見。當前，越來越多的使用者錢包都是SPV節點，尤其是運行於諸如智能手機等資源受限裝置上的區塊鏈錢包應用；而這正變得越來越普遍。在圖6-1中，名為“錢包”的綠色圓圈代表錢包功能。
在區塊鏈P2P協議中，除了這些主要的節點類型之外，還有一些伺服器及節點也在運行著其他協議，例如特殊礦池挖礦協議、輕量級用戶端訪問協議等。
圖6-2描述了擴充區塊鏈網路中最為常見的節點類型。
 
圖6-2 擴充區塊鏈網路的不同節點類型
6.3 擴充區塊鏈網路
運行區塊鏈P2P協議的區塊鏈主網路由大約7000-10000個運行著不同版本區塊鏈核心用戶端（Bitcoin Core）的監聽節點、以及幾百個運行著各類區塊鏈P2P協議的應用（例如BitcoinJ、Libbitcoin、btcd等）的節點群組成。區塊鏈P2P網路中的一小部分節點也是挖礦節點，它們競爭挖礦、驗證交易、並建立新的區塊。許多串連到區塊鏈網路的大型公司運行著基於Bitcoin核心用戶端的全節點用戶端，它們具有區塊鏈的完整拷貝及網路節點，但不具備挖礦及錢包功能。這些節點是網路中的邊緣路由器（edge routers），通過它們可以搭建其他服務，例如證券交易所、錢包、區塊瀏覽器、商家支付處理（merchant payment processing）等。
如前文所述，擴充區塊鏈網路既包括了運行區塊鏈P2P協議的網路，又包含運行特殊協議的網路節點。區塊鏈P2P主網路上串連著許多礦池伺服器以及協議網關，它們把運行其他協議的節點串連起來。這些節點通常都是礦池挖礦節點（參見第8章）以及輕量級錢包用戶端，它們通常不具備區塊鏈的完整備份。
圖6-3描述了擴充區塊鏈網路，它包括了多種類型的節點、閘道伺服器、邊緣路由器、錢包用戶端以及它們相互串連所需的各類協議。


圖6-3 具有多種節點類型、網關及協議的擴充區塊鏈網路
6.4 網路發現
當新的網路節點啟動後，為了能夠參與協同運作，它必鬚髮現網路中的其他區塊鏈節點。新的網路節點必鬚髮現至少一個網路中存在的節點並建立串連。由於區塊鏈網路的拓撲結構並不基於節點間的地理位置，因此各個節點之間的地理資訊完全無關。在新節點串連時，可以隨機播放網路中存在的區塊鏈節點與之相連。
節點通常採用TCP協議、使用8333連接埠（該連接埠號碼通常是區塊鏈所使用的，除8333連接埠外也可以指定使用其他連接埠）與已知的對等節點建立串連。在建立串連時，該節點會通過發送一條包含基本認證內容的version訊息開始“握手”通訊過程(見圖6-4)。這一過程包括如下內容：
▷ PROTOCOL_VERSION
常量，定義了用戶端所“說出”的區塊鏈P2P協議所採用的版本（例如：70002）。
▷ nLocalServices
一組該節點支援的本地服務列表，當前僅支援NODE_NETWORK
▷ nTime
目前時間
▷ addrYou
當前節點可見的遠程節點的IP地址
▷ addrMe
本地節點所發現的本機IP地址
▷ subver
指示當前節點啟動並執行軟體類型的子版本號碼（例如：”/Satoshi:0.9.2.1/”）
▷ BaseHeight
當前節點區塊鏈的區塊高度
（version網路訊息的具體用例請參見GitHub）
網路中的對等節點通過對verack訊息的響應進行確認並建立串連；有時候，如果接收節點需要互換串連並連回起始節點，也會傳回該對等節點的version訊息。
新節點是如何發現網路中的對等節點的呢。雖然區塊鏈網路中沒有特殊節點，但是用戶端會維持一個列表，那裡列出了那些長期穩定啟動並執行節點。這樣的節點被稱為“種子節點（seed nodes）”。新節點並不一定需要與種子節點建立串連，但串連到種子節點的好處是可以通過種子節點來快速發現網路中的其他節點。在區塊鏈核心用戶端中，是否使用種子節點是通過“-dnsseed”控制的。預設情況下，該選項設為1，即意味著使用種子節點。另一種方式是，起始時將至少一個區塊鏈節點的IP地址提供給正在啟動的節點（該節點不包含任何區塊鏈網路的組成資訊）。在這之後，啟動節點可以通過後續指令建立新的串連。使用者可以使用命令列參數“-seednode”把啟動節點“引薦”並串連到一個節點，並將該節點用作DNS種子。在初始種子節點被用於形成“引薦”資訊之後，用戶端會斷開與它的串連、並與新發現的對等節點進行通訊。
 
圖6-4 對等節點之間的初始“握手”通訊
當建立一個或多個串連後，新節點將一條包含自身IP地址的addr訊息發送給其相鄰節點。相鄰節點再將此條addr訊息依次轉寄給它們各自的相鄰節點，從而保證新節點資訊被多個節點所接收、保證串連更穩定。另外，新接入的節點可以向它的相鄰節點發送getaddr訊息，要求它們返回其已知對等節點的IP地址清單。通過這種方式，節點可以找到需串連到的對等節點，並向網路發布它的訊息以便其他節點尋找。圖6-5描述了這種地址發現協議。
 
圖6-5 地址廣播及發現
節點必須串連到若干不同的對等節點才能在區塊鏈網路中建立通向區塊鏈網路的種類各異的路徑（path）。由於節點可以隨時加入和離開，通訊路徑是不可靠的。因此，節點必須持續進行兩項工作：在失去已有串連時發現新節點，並在其他節點啟動時為其提供協助。節點啟動時只需要一個串連，因為第一個節點可以將它引薦給它的對等節點，而這些節點又會進一步提供引薦。一個節點，如果串連到大量的其他對等節點，這既沒必要，也是對網路資源的浪費。在啟動完成後，節點會記住它最近成功串連的對等節點；因此，當重新啟動後它可以迅速與先前的對等節點網路重建立立串連。如果先前的網路的對等節點對串連請求無應答，該節點可以使用種子節點進行重啟動。
在運行區塊鏈核心用戶端的節點上，您可以使用getpeerinfo命令列出對等節點串連資訊：
$ bitcoin-cli getpeerinfo[    {        "addr" : "85.213.199.39:8333",        "services" : "00000001",        "lastsend" : 1405634126,        "lastrecv" : 1405634127,        "bytessent" : 23487651,        "bytesrecv" : 138679099,        "conntime" : 1405021768,        "pingtime" : 0.00000000,        "version" : 70002,        "subver" : "/Satoshi:0.9.2.1/",        "inbound" : false,        "startingheight" : 310131,        "banscore" : 0,        "syncnode" : true    },    {        "addr" : "58.23.244.20:8333",        "services" : "00000001",        "lastsend" : 1405634127,        "lastrecv" : 1405634124,        "bytessent" : 4460918,        "bytesrecv" : 8903575,        "conntime" : 1405559628,        "pingtime" : 0.00000000,        "version" : 70001,        "subver" : "/Satoshi:0.8.6/",        "inbound" : false,        "startingheight" : 311074,        "banscore" : 0,        "syncnode" : false    }]
使用者可以通過提供-connect=選項來指定一個或多個IP地址，從而達到複寫自動節點管理功能並指定IP地址清單的目的。如果採用此選項，節點只串連到這些選定的節點IP地址，而不會自動探索並維護對等節點之間的串連。
如果已建立的串連沒有資料通訊，所在的節點會定期發送資訊以維持串連。如果節點持續某個串連長達90分鐘沒有任何通訊，它會被認為已經從網路中斷開，網路將開始尋找一個新的對等節點。因此，區塊鏈網路會隨時根據變化的節點及網路問題進行動態調整，不需經過中心化的控制即可進行規模增、減的有機調整。
6.5 全節點
全節點是指維持包含全部交易資訊的完整區塊鏈的節點。更加準確地說，這樣的節點應當被稱為完整區塊鏈節點”。在區塊鏈發展的早期，所有節點都是全節點；當前的區塊鏈核心用戶端也是完整區塊鏈節點。但在過去的兩年中出現了許多新型用戶端，它們不需要維持完整的區塊鏈，而是作為輕量級用戶端運行。在下面的章節裡我們會對這些輕量級用戶端進行詳細介紹。
完整區塊鏈節點保有完整的、最新的包含全部交易資訊的區塊鏈區塊鏈拷貝，這樣的節點可以獨立地進行建立並校正區塊鏈，從第一區塊（創世區塊）一直建立到網路中最新的區塊。完整區塊鏈節點可以獨立自主地校正任何交易資訊，而不需要藉助任何其他節點或其他資訊來源。完整區塊節點通過區塊鏈網路擷取包含交易資訊的新區塊更新，在驗證無誤後將此更新合并至本地的區塊鏈拷貝之中。
運行完整區塊鏈節點可以給您一種純粹的區塊鏈體驗：不需藉助或信任其他系統即可獨立地對所有交易資訊進行驗證。辨別您是否在運行全節點是十分容易的：只需要查看您的非揮發性儲存體裝置（如硬碟）是否有超過20GB的空間被用來儲存完整區塊鏈即可。如果您需要很大的磁碟空間、並且同步區塊鏈網路耗時2至3天，那麼您使用的正是全節點。這就是擺脫中心化管理、獲得完全的獨立自由所要付出的代價。
儘管目前還有一些使用不同程式設計語言及軟體架構的其他的完整區塊鏈用戶端存在，但是最常用的仍然是區塊鏈核心用戶端，它也被稱為“Satoshi用戶端”。區塊鏈網路中超過90%的節點運行著各個版本的區塊鏈核心用戶端。如前文所述，它可以通過節點間發送的version訊息或通過getpeerinfo命令所得到的子版本字串“Satoshi”加以辨識，例如 /Satoshi: 0.8.6/。
6.6 交換“庫存清單”
一個全節點串連到對等節點之後，第一件要做的事情就是構建完整的區塊鏈。如果該節點是一個全新節點，那麼它就不包含任何區塊鏈資訊，它只知道一個區塊——靜態植入在用戶端軟體中的創世區塊。新節點需要下載從0號區塊（創世區塊）開始的數十萬區塊的全部內容，才能跟網路同步、並重建全區塊鏈。
同步區塊鏈的過程從發送version訊息開始，這是因為該訊息中含有的BestHeight欄位標示了一個節點當前的區塊鏈高度（區塊數量）。節點可以從它的對等節點中得到版本訊息，瞭解雙方各自有多少區塊，從而可以與其自身區塊鏈所擁有的區塊數量進行比較。對等節點們會交換一個getblocks訊息，其中包含他們本地區塊鏈的頂端區塊雜湊值。如果某個對等節點識別出它接收到的雜湊值並不屬於頂端區塊，而是屬於一個非頂端區塊的舊區塊，那麼它就能推斷出：其自身的本地區塊鏈比其他對等節點的區塊鏈更長。
擁有更長區塊鏈的對等節點比其他節點有更多的區塊，可以識別出哪些區塊們是其他節點需要“補充”的。它會識別出第一批可供分享的500個區塊，通過使用inv（inventory）訊息把這些區塊的雜湊值傳播出去。缺少這些區塊的節點便可以通過各自發送的getdata訊息來請求得到全區塊資訊，用包含在inv訊息中的雜湊值來確認是否為正確的被請求的區塊，從而讀取這些缺失的區塊。
在下例中，我們假設某節點只含有創世區塊。它收到了來自對等節點的inv訊息，其中包含了區塊鏈中後500個區塊的雜湊值。於是它開始向所有與之相連的對等節點請求區塊，並通過分攤工作量的方式防止單一對等節點被批量請求所壓垮。該節點會追蹤記錄其每個對等節點串連上“正在傳輸”（指那些它已經發出了請求但還沒有接收到）的區塊數量，並且檢查該數量有沒有超過上限（MAX_BLOCKS_IN_TRANSIT_PER_PEER）。用這種辦法，如果一個節點需要更新大量區塊，它會在上一請求完成後才發送對新區塊的請求，從而允許對等節點控制更新速度，不至於壓垮網路。每一個區塊在被接收後就會被添加至區塊鏈中，這一過程詳見第7章。隨著本地區塊鏈的逐步建立，越來越多的區塊被請求和接收，整個過程將一直持續到該節點與全網路完成同步為止。
每當一個節點離線，不管離線時間有多長，這個與對等節點比較本地區塊鏈並恢複缺失區塊的過程就會被觸發。如果一個節點只離線幾分鐘，可能只會缺失幾個區塊；當它離線長達一個月，可能會缺失上千個區塊。但無論哪種情況，它都會從發送getblocks訊息開始，收到一個inv響應，接著開始下載缺失的區塊庫存清單和區塊廣播協議如圖6-6所示。
 
圖6-6 節點通過從對等節點讀取區塊來同步區塊鏈
6.7 簡易支付驗證 （SPV）節點
並非所有的節點都有能力儲存完整的區塊鏈。許多區塊鏈用戶端被設計成運行在空間和功率受限的裝置上，如智能電話、平板電腦、嵌入式系統等。對於這樣的裝置，通過簡化的支付驗證（SPV）的方式可以使它們在不必儲存完整區塊鏈的情況下進行工作。這種類型的客端被稱為SPV用戶端或輕量級用戶端。隨著區塊鏈的使用熱潮，SPV節點逐漸層成區塊鏈節點（尤其是區塊鏈錢包）所採用的最常見的形式。
SPV節點只需下載區塊頭，而不用下載包含在每個區塊中的交易資訊。由此產生的不含交易資訊的區塊鏈，大小隻有完整區塊鏈的1/1000。SPV節點不能構建所有可用於消費的UTXO的全貌，這是由於它們並不知道網路上所有交易的完整資訊。SPV節點驗證交易時所使用的方法略有不同，這個方法需依賴對等節點“按需”提供區塊鏈相關部分的局部視圖。
打個比方來說，每個全節點就像是一個在陌生城市裡的遊客，他帶著一張包含每條街道、每個地址的詳細地圖。相比之下，SPV節點就像是這名陌生城市裡的遊客只知道一條主幹道的名字，通過隨機詢問該城市的陌生人來擷取分段道路指示。雖然兩種遊客都可以通過實地考察來驗證一條街是否存在，但沒有地圖的遊客不知道每個小巷中有哪些街道，也不知道附近還有什麼其他街道。沒有地圖的遊客在“教堂街23號”的前面，並不知道這個城市裡是否還有其他若干條“教堂街23號”，也不知道面前的這個是否是要找的那個。對他來說，最好的方式就是向足夠多的人問路，並且希望其中一部分人不是要試圖搶劫他。
簡易支付驗證是通過參考交易在區塊鏈中的深度，而不是高度，來驗證它們。一個擁有完整區塊鏈的節點會構造一條驗證鏈結，這條鏈是由沿著區塊鏈按時間倒序一直追溯到創世區塊的數千區塊及交易組成。而一個SPV節點會驗證所有區塊的鏈（但不是所有的交易），並且把區塊鏈和有關交易連結起來。
例如，一個全節點要檢查第300,000號區塊中的某個交易，它會把從該區塊開始一直回溯到創世區塊的300,000個區塊全部都連結起來，並建立一個完整的UTXO資料庫，通過確認該UTXO是否還未被支付來證實交易的有效性。SPV節點則不能驗證UTXO是否還未被支付。相反地，SPV節點會在該交易資訊和它所在區塊之間用merkle路徑（見“7.7 Merkle 樹”）建立一條連結。然後SPV節點一直等待，直到序號從300,001到300,006的六個區塊堆疊在該證券交易所在的區塊之上，並通過確立交易的深度是在第300,006區塊~第300,001區塊之下來驗證交易的有效性。事實上，如果網路中的其他節點都接受了第300,000區塊，並通過足夠的工作在該塊之上又產生了六個區塊，根據代理網關協議，就可以證明該交易不是雙重支付。
如果一個交易實際上不存在，SPV節點不會誤認為該交易存在於某區塊中。SPV節點會通過請求merkle路徑證明以及驗證區塊鏈中的工作量證明，來證實交易的存在性。可是，一個交易的存在是可能對SPV節點“隱藏”的。SPV節點毫無疑問可以證實某個交易的存在性，但它不能驗證某個交易（譬如同一個UTXO的雙重支付）不存在，這是因為SPV節點沒有一份關於所有交易的記錄。這個漏洞會被針對SPV節點的拒絕服務的攻擊或雙重支付型攻擊所利用。為了防禦這些攻擊，SPV節點需要隨機串連到多個節點，以增加與至少一個可靠節點相串連的機率。這種隨機串連的需求意味著SPV節點也容易受到網路磁碟分割攻擊或Sybil攻擊。在後者情況中，SPV節點被串連到虛假節點或虛假網路中，沒有通向可靠節點或真正的區塊鏈網路的串連。
在絕大多數的實際情況中，具有良好串連的SPV節點是足夠安全的，它在資源需求、實用性和安全性之間維持恰當的平衡。當然，如果要保證萬無一失的安全性，最可靠的方法還是運行完整區塊鏈的節點。
 
完整的區塊鏈節點是通過檢查整個鏈中在它之下的數千個區塊來保證這個UTXO沒有被支付，從而驗證交易。而SPV節點是通過檢查在其上面的區塊將它壓在下面的深度來驗證交易。
SPV節點使用的是一條getheaders訊息，而不是getblocks訊息來獲得區塊頭。發出響應的對等節點將用一條headers訊息發送多達2000個區塊頭。這一過程和全節點擷取所有區塊的過程沒什麼區別。SPV節點還在與對等節點的串連上設定了過濾器，用以過濾從對等節點發來的未來區塊和交易資料流。任何目標交易都是通過一條getdata的請求來讀取的。對等節點產生一條包含交易資訊的tx訊息作為響應。區塊頭的同步過程如圖6-7所示。
 
圖6-7 SPV節點同步區塊頭
由於SPV節點需要讀取特定交易從而選擇性地驗證交易，這樣就又產生了隱私風險。與全區塊鏈節點收集每一個區塊內的全部證券交易所不同的是，SPV節點對特定資料的請求可能無意中透露了錢包裡的地址資訊。例如，監控網路的第三方可以跟蹤某個SPV節點上的錢包所請求的全部交易資訊，並且利用這些交易資訊把區塊鏈地址和錢包的使用者關聯起來，從而損害了使用者的隱私。
在引入SPV節點/輕量級節點後不久，區塊鏈開發人員就添加了一個新功能：Bloom過濾器，用以解決SPV節點的隱私風險問題。Bloom過濾器通過一個採用機率而不是固定模式的過濾機制，允許SPV節點只接收交易資訊的子集，同時不會精確泄露哪些是它們感興趣的地址。
6.8 Bloom過濾器
Bloom過濾器是一個允許使用者描述特定的關鍵片語合而不必精確表述的基於機率的過濾方法。它能讓使用者在有效搜尋關鍵詞的同時保護他們的隱私。在SPV節點裡，這一方法被用來向對等節點發送交易資訊查詢請求，同時交易地址不會被暴露。
用我們之前的例子，一位手中沒有地圖的遊客需要詢問去特定地方的路線。如果他向陌生人詢問“教堂街23號在哪裡”，不經意之間，他就暴露了自己的目的地。Bloom過濾器則會這樣問，附近有帶‘堂’字的街道嗎。”這樣的問法包含了比之前略少的關鍵詞。這位遊客可以自己選擇包含資訊的多少，比如“以‘堂街’結尾”或者“‘教’字開頭的街道”。如果他問得越少，得到了更多可能的地址，隱私得到了保護，但這些地址裡面不乏無關的結果；如果他問得非常具體，他在得到較準確的結果的同時也暴露了自己的隱私。
Bloom過濾器可以讓SPV節點指定交易的搜尋模式，該搜尋模式可以基於準確性或私密性的考慮被調節。一個非常具體的Bloom過濾器會產生更準確的結果，但也會顯示該使用者錢包裡的使用的地址；反之，如果過濾器只包含簡單的關鍵詞，更多相應的交易會被搜尋出來，在包含若干無關交易的同時有著更高的私密性。
首先，SPV節點會初始化一個不會匹配任何關鍵詞的“空白”Bloom過濾器。接下來，SPV節點會建立一個包含錢包中所有地址資訊的列表，並建立一個與每個地址相對應的交易輸出相匹配的搜尋模式。通常，這種搜尋模式是一個向公開金鑰付款的雜湊指令碼、，該指令碼是一個會出現在每一個向公開金鑰雜湊地址付款的交易中的鎖定指令碼。如果SPV節點需要追蹤P2SH地址餘額，搜尋模式就會變成P2SH指令碼。然後，SPV節點會把每一個搜尋模式添加至Bloom過濾器裡，這樣只要關鍵詞出現在交易中就能夠被過濾器識別出來。最後，對等節點會用收到的Bloom過濾器來匹配傳送至SPV節點的交易。
Bloom過濾器的實現是由一個可變長度（N）的位元組（N位位元構成一個位域）和數量可變（M）的一組雜湊函數組成。。這些雜湊函數的輸出值始終在1和N之間，該數值與位元組相對應。並且該函數為確定性函數，也就是說任何一個使用相同Bloom過濾器的節點通過該函數都能對特定輸入得到同一個的結果。Bloom過濾器的準確性和私密效能通過改變長度（N）和雜湊函數的數量（M）來調節。
在圖6-8中，我們用一個小型的十六位元組和三個雜湊函數來示範Bloom過濾器的應用原理。


圖6-8 一個由16位元組和三個雜湊函數組成的簡易Bloom過濾
Bloom過濾器數組裡的每一個數的初始值為零。關鍵詞被加到Bloom過濾器中之前，會依次通過每一個雜湊函數運算一次。該輸入經第一個雜湊函數運算後得到了一個在1和N之間的數，它在該數組（編號依次為1至N）中所對應的位被置為1，從而把雜湊函數的輸出記錄下來。接著再進行下一個雜湊函數的運算，把另外一位置為1；以此類推。當全部M個雜湊函數都運算過之後，一共有M個位的值從0變成了1，這個關鍵詞也被“記錄”在了Bloom過濾器裡。
圖6-9顯示了向圖6-8裡的簡易Bloom過濾器添加關鍵詞“A”。


圖6-9 向簡易Bloom過濾器中增加關鍵詞“A”
增加第二個關鍵是就是簡單地重複之前的步驟。關鍵詞依次通過各雜湊函數運算之後，相應的位變為1，Bloom過濾器則記錄下該關鍵詞。需要注意的是，當Bloom過濾器裡的關鍵詞增加時，它對應的某個雜湊函數的輸出值的位可能已經是1了，這種情況下，該位不會再次改變。也就是說，隨著更多的關鍵詞指向了重複的位，Bloom過濾器隨著位1的增加而飽和，準確性也因此降低了。該過濾器之所以是基於機率的資料結構，就是因為關鍵詞的增加會導致準確性的降低。準確性取決於關鍵字的數量以及數組大小（N）和雜湊函數的多少（M）。更大的數組和更多的雜湊函數會記錄更多的關鍵詞以提高準確性。而小的數組及有限的雜湊函數只能記錄有限的關鍵詞從而降低準確性。
圖6-10顯示了向該簡易Bloom過濾器裡增加第二個關鍵詞“B”。


圖6-10 向簡易Bloom過濾器中增加第二個關鍵詞“B”
為測試某一關鍵詞是否被記錄在某個Bloom過濾器中，我們將該關鍵詞逐一代入各雜湊函數中運算，並將所得的結果與原數組進行對比。如果所有的結果對應的位都變為了1，則表示這個關鍵詞有可能已被該過濾器記錄。之所以這一結論並不確定，是因為這些位元組1也有可能是其他關鍵詞運算的重疊結果。簡單來說，Bloom過濾器正匹配代表著“可能是”。
圖6-11是一個驗證關鍵詞“X”是否在前述Bloom過濾器中的圖例。相應的位元位都被置為1，所以這個關鍵詞很有可能是匹配的。


圖6-11 驗證關鍵詞“X”是否存在於Bloom過濾器中。若結果為或然正匹配，則表示“可能是”。
另一方面，如果我們代入關鍵詞計算後的結果某位為0，說明該關鍵詞並沒有被記錄在過濾器裡。負匹配的結果不是可能，而是一定。也就是說，負匹配代表著“一定不是”。
圖6-12是一個驗證關鍵詞“Y”是否存在於簡易Bloom過濾器中的圖例。圖中某個結果欄位為0，該欄位一定沒有被匹配。


圖6-12 驗證關鍵詞“Y”是否存在於Bloom過濾器中。若結果為必然負匹配，則表示“一定不是”。
BIP0037裡已經對Bloom過濾器的實現有所描述。請參見附錄2或訪問GitHub。
6.9 Bloom過濾器和存貨更新
Bloom過濾器被用來過濾SPV節點從對等節點裡收到的交易資訊。SPV會建立一個只能和SPV節點錢包裡的地址匹配的過濾器。隨後，SPV節點會向對等節點發送一條包含需在該串連中使用的過濾器的filterload訊息。當過濾器建好之後，對等節點將每個交易的輸出值代入過濾器中驗證。那些正匹配的交易會被傳送回SPV節點。
為回應來自SPV節點的getdata資訊，對等節點會發出一條只含有和過濾器匹配的區塊的區塊頭資訊，以及與之相匹配的交易的merkle樹。這一對等節點還會發出一條相匹配的交易的tx訊息。
這個節點能夠通過發送一條filteradd資訊來向它的Bloom過濾器增加關鍵詞，也能夠發送filterclear資訊來清除整個過濾器。因為不能直接從過濾器裡刪除關鍵詞，所以如果某關鍵詞不再需要，節點必須通過清除和增加來替換原有的過濾器。
6.10 交易池
區塊鏈網路中幾乎每個節點都會維護一份未確認交易的臨時列表，被稱為記憶體池或交易池。節點們利用這個池來追蹤記錄那些被網路所知曉、但還未被區塊鏈所包含的交易。例如，儲存使用者錢包的節點會利用這個交易池來記錄那些網路已經接收但還未被確認的、屬於該使用者錢包的預支付資訊。
隨著交易被接收和驗證，它們被添加到交易池並通知到相鄰節點處，從而傳播到網路中。
有些節點的實現還維護一個單獨的孤立交易池。如果一個交易的輸入與某未知的交易有關，如與缺失的父交易相關，該孤立交易就會被暫時儲存在孤立交易池中直到父交易的資訊到達。
當一個交易被添加到交易池中，會同時檢查孤立交易池，看是否有某個孤立交易引用了此交易的輸出（子交易）。任何匹配的孤立交易會被進行驗證。如果驗證有效，它們會從孤立交易池中刪除，並添加到交易池中，使以其父交易開始的鏈變得完整。對新加入交易池的交易來說，它不再是孤立交易。前述過程重複遞迴尋找進一步的後代，直至所有的後代都被找到。通過這一過程，一個父交易的到達把整條鏈中的孤立交易和它們的父級交易重新結合在一起，從而觸發了整條獨立交易鏈進行級聯重構。
交易池和孤立交易池（如有實施）都是儲存在本地記憶體中，並不是儲存在非揮發性儲存體裝置（如硬碟）裡。更準確的說，它們是隨網路傳入的訊息動態填充的。節點啟動時，兩個池都是閒置；隨著網路中新交易不斷被接收，兩個池逐漸被填充。
有些區塊鏈用戶端的實現還維護一個UTXO資料庫，也稱UTXO池，是區塊鏈中所有未支付交易輸出的集合。“UTXO池”的名字聽上去與交易池相似，但它代表了不同的資料集。UTXO池不同於交易池和孤立交易池的地方在於，它在初始化時不為空白，而是包含了數以百萬計的未支付交易輸出條目，有些條目的曆史甚至可以追溯至2009年。UTXO池可能會被安置在本地記憶體，或者作為一個包含索引的資料庫表安置在非揮發性儲存體裝置中。
交易池和孤立交易池代表的是單個節點的本地視角。取決於節點的啟動時間或重啟時間，不同節點的兩池內容可能有很大差別。相反地，UTXO池代表的是網路的突顯共識，因此，不同節點間UTXO池的內容差別不大。此外，交易池和孤立交易池只包含未確認交易，而UTXO池之只包含已確認交易。
6.11 警告訊息
警告訊息並不經常使用，但在大多數節點上都有此功能。警告訊息是區塊鏈的“緊急廣播系統”，區塊鏈核心開發人員可以藉此功能給所有區塊鏈節點發送緊急簡訊。這一功能是為了讓核心Team Dev將區塊鏈網路的嚴重問題通知所有的區塊鏈使用者，例如一個需要使用者採取措施的的嚴重bug。警告系統迄今為止只被用過幾次，最嚴重的一次是在2013年，一個關鍵的資料庫缺陷導致區塊鏈區塊鏈中出現了一個多區塊分叉。
警告訊息是通過alert訊息來傳播的。警告訊息包含幾個欄位，包括：
▷ ID 
警告訊息序號，用於檢測重複警告
▷ Expiration 
警告到期的時間點
▷ RelayUntil 
在此時間點之後，警告不再被中繼
▷ MinVer,MaxVer 
此警告所適用的區塊鏈協議版本範圍
▷ subVer
此警告適用的用戶端軟體版本
▷ Priority 
警告訊息的優先順序（暫未使用）
警告通過公開金鑰進行加密簽名。對應的私密金鑰是由核心Team Dev的一些特定成員所持有。這樣的數位簽章可以確保虛假警告不會在網路中傳播。
收到警告訊息的節點會驗證該訊息，檢查是否到期，並傳播給其所有對等節點，從而保證了整個網路中的快速傳播。除了傳播警告之外，節點也可能會實現一個向使用者推送警告的使用者級介面函數。
在區塊鏈核心用戶端，警告是與命令列選項alertnotify一起設定的，該選項指定了收到警告時需要執行的命令。警告訊息作為參數被傳遞給alertnotify命令。最常見的應用是，alertnotify命令被設定為產生一個包含該警告訊息的電子郵件並發送給節點管理員。警告也會以彈出對話方塊的形式顯示在圖形化使用者介面（如有運行）上（bitcoin-Qt）。
其他區塊鏈協議的實現可能以不同的方式來處理警告。許多硬體嵌入式區塊鏈挖礦系統由於沒有使用者介面，並沒有實現警告訊息功能。我們強烈建議運行這類挖礦系統的礦工訂閱警告訊息，既可以通過礦池運營方來訂閱、也可以通過運行一個單獨以警告為目的的輕量級節點來訂閱。