關於擴容新主張的研究：SPV 能支持十億數量級用戶的比特幣網路正常運行嗎？

編者按：Jameson Lopp 是 BitGo 的軟體工程師，也是 statoshi.info 和 bitcoinsig.com 的創始人。在他近日撰寫的一篇文章中，Loop 闡述了通過使用「簡單支付驗證」（simplified payment verification，SPV）的方法來移除比特幣區塊大小的限制是安全的這一觀點，並做了深入的分析和研究。

這是一個將會一直存在於比特幣擴容爭議之中的新主張

這個主張指出：通過「簡單支付驗證」（SPV）的方法，比特幣的區塊大小可以安全地移除上限限制，用以支撐十億數量級的用戶便捷地使用比特幣進行交易而不用擔心網路擁堵。據推測，由於 SPV 客戶端的存儲模式，用戶電腦需要接受和發送的數據非常少，所以 SPV 是一種高效的解決擴容爭議的方法。

現在，讓我們來深入研究一下這個說法，並從多個角度出發來看待這個問題。

SPV的工作原理

中本聰在比特幣白皮書中描述了 SPV 的高級設計原理，儘管直到兩年後 Mike Hearn 創造出了 BitcoinJ 才使得這一設計得以投入應用。

早期的 SPV 應用設計非常簡陋，這些 SPV 應用需要下載整個比特幣的區塊鏈，這使得使用 SPV 方式進行支付驗證時需要的帶寬並不比普通的維護節點更有效率。

通過去掉和 SPV 客戶錢包無關的交易，可以節省出大量的磁碟空間。之前被提出的 BIP37 方案需要 18 個月才能發布，這個方案會發布布隆過濾器（Bloom filtering）的交易規範。Bloom filtering 的工作原理是通過快速判斷出某檢索值一定不存在於某個指定的集合，從而可以過濾掉大量無關數據，減少客戶端不必要的下載量，大大減少了對帶寬的需求，這就是中本聰在比特幣白皮書里所描述的高級設計原理。

由於以往的比特幣系統協議中缺少對 SPV 的支持，在原有的協議中，可以通過「getheaders」命令來獲取 block headers，也可以通過「getdata」命令支持獲取指定的 block, 但這種協議不支持通過 tx_hash 反向查找關鍵信息所在的 block。為了定位 block，客戶端往往不得不下載整個區塊鏈，而 Bloom filter 則可以很好地解決這一問題。

一旦客戶端與比特幣網路同步之後，如果它能保持連接到完整的節點，就可以只接受 Bloom filter 載入出來的只與 SPV 錢包相關的交易信息。

SPV客戶端擴容

從客戶端的角度來看，布隆過濾器是在完整區塊鏈中檢索相關交易信息的一種非常有效的方式，在確認支付驗證的同時能保證客戶端佔用最少的 CPU 資源、帶寬和磁碟空間。

無論未來交易量有多大，每個比特幣 block header 的大小始終不變，只有 80 位元組。按照每小時 6 個的出塊速度，每年會產出 52560 個區塊。當 SPV 客戶端只保存 block header 時，每年新增的存儲需求約為 4 兆位元組，100 年後累計的存儲需求僅為 400M，即使用戶使用的是最低端的設備，在正常情況下也完全能夠達到數據的負載要求。

用於證明確保收錄與區塊中所有交易真實性的 Merkle 樹演算法也非常好用。因為添加到樹中的每一個新的「層」都可以用「葉子」總數翻倍來表示，所以並不需要特別「深」的樹枝分層來證明一次交易中所包含的信息，即使這些信息位於一個具有數百萬交易的區塊鏈中。

Merkle 樹的數據結構是非常高效的，它能夠包含 1600 萬次交易，使用 Merkle 樹演算法證明在如此數量龐大的交易僅需要佔據 1K 以下的磁碟空間。

很明顯，從 SPV 客戶端的角度來看，即便比特幣的區塊大小擴大幾個 GB 的規模，SPV 客戶端仍能夠使用非常少的帶寬，CPU 和磁碟空間來處理這些數量巨大的交易數據，這使得普通的 3G 手機都可以安裝 SPV 客戶端。

但是，比特幣網路擴容卻並不簡單。

SPV伺服器擴容

雖然 SPV 對於客戶端來說是非常有效的，但對於伺服器來說卻並非如此，即 SPV 客戶端要求完整的節點，由於一些原因，在伺服器方面，該方法的展示出的可擴展性在非常差。

比特幣網路中的節點必須處理數量非常大的數據量才能證明一個交易，這樣工作量巨大的過程還必須在每個區塊產生的時候重複，因此，磁碟的輸出輸入速度的限制很快就是成為新區塊生成的瓶頸。

每個 SPV 客戶端必須與從上一次與網路的聯繫中同步整個區塊鏈，如果它在同步過程中發現其中錯過了一些交易，SPV 客戶端就必須從創建日起重新掃描整個區塊鏈的數據。在最壞的情況下，寫入磁碟時，大約要佔 150G 的大小。作為完整的節點，磁碟必須載入完整區塊鏈中的每一個區塊，將相關的信息過濾到客戶端並得出結果。

由於區塊鏈是一個帶有附加屬性的分散式賬本，新區塊會一直產生，所以節點磁碟要載入的數據只會越來越多。如果廣泛的協議不做出相應的更改，區塊擴容與 BIP 37 方案就不兼容—-該方案希望所有區塊在完整節點上都可用來通知 NODE_BLOOM。

BIP37 SPV 客戶端會被冗長的數據欺騙。為了解決這個問題，SPV 客戶端會連接到多個節點（通常為四個），這將使得整個節點的網路負載增加四倍。但這樣做也不能保證這個問題被完全解決，因為惡意性的主動攻擊可以將 SPV 客戶端和主網路隔開。

對於每個連接到主網路並和區塊鏈末端同步的 SPV 客戶端來說，每個區塊中傳入的交易數據都必須被單獨過濾。這涉及到不可忽略的 CPU 處理數據的時間量問題，該工作必須為每個連接到網路的 SPV 客戶端單獨完成。

精細的數據分析

在數據寫入磁碟時，大約有 8300 個完整的節點在運行以接受傳入的連接，這應該能夠滿足 SPV 客戶端的服務需求。但是，目前能夠監聽完整節點合理支持的 SPV 客戶端的數目有多少呢？

需要做些什麼才能比特幣網路可以支持十億日常用戶的需求，並能防止大量交易阻塞網路呢？

Bitcoin Core 默認最多傳入連接的最大值為 117，這將在網路創建最大值為 936000 的可用套接字上限，這些套接字中的大部分會被消耗。

默認情況下，每個完整的節點會連接到其他 8 個完整的節點。Bitcoin Core 的開發人員 Luke-Jr 粗略地估計出在寫入數據時約有 100000 個節點，其中有 92000 個節點不能為 SPV 客戶端提供套接字，這樣就會為完整的節點消耗 800000 個可用的套接字，只剩下 136000 個適用於 SPV 客戶端的套接字。

這使我得出這樣一個結論：大約有 85%的套接字會被完整的節點網路消耗（值得注意的是，Luke-Jr 的估計方法不能確定非監聽節點在線花費了多少時間；至少可以確定的是這些節點中的一部分會與網路斷開並定期重新連接）。

我的節點平均為 statoshi.info 的 100 個完整節點和 25 個 SPV 客戶端提供運行動力，其中 80%的可用套接字都被完整節點所消耗。

如果我們想要建立一個十億用戶數量的 SPV 客戶端能夠運行的比特幣系統，則需要足夠的完整節點資源來為網路套接字、CPU 周期、磁碟寫入和輸出等提供服務，那麼，使用數學的方法能夠解決這個問題嗎？

為了說明 SPV 擴容主張的優點，我將做出一些保守性的假設，這十億用戶中的每一個都會：

每天發送和接受一筆交易

每天都會將他們的錢包和區塊鏈末端同步一次

在同步時會查詢四個不同的節點，以減少被遺漏的可能性

如果將每天 10 億次的交易平均分配到每個區塊中（實際上這根本不可能），每個區塊大約會包含 700 萬次交易。由於 Merkle 樹演算法具有極強的擴展性，它只需要 23 個哈希值來證明交易被包含在某個區塊中，每個區塊的大小為 736 個位元組的數據加上一個平均為 500 位元組大小的交易。

每天添加 12KB 大小的區塊頭文件，SPV 客戶端每天只需要載入大約 20KB 的數據就能完成工作。

然而，如果每天有 10 億次的交易，那麼完整的節點每天將需要存儲和處理 500GB 大小的新區塊數據。每當 SPV 客戶端連接到節點並要求在過去一天的數據中找到與其錢包相關的任何交易數據時，四個完整的節點就必須讀取 500GB 大小的數據並從中過濾出相關的信息。

現在我們回想一下，在擁有 8000 個 SPV 服務的完整節點的網路中，一般大約有 136000 個套接字可用於 SPV 客戶端。如果每個 SPV 客戶端使用四個套接字，那麼只有 34000 個客戶端可以在任何給定的時間內與整個網路同步。但如果在網路上的客戶端數量超出了這個範圍，那麼其他打開錢包嘗試與網路同步的用戶就會遇到連接錯誤的情況。

因此，為了使當前的網路能夠滿足 10 億用戶每天同步一次的規模需求，每個用戶就必須在不到 3 秒的時間內同步前一天的數據。

這就帶來了一個棘手的問題，因為這將要求每個完整的節點能夠持續寫入和過濾每個 SPV 客戶端 167G 的數據，並且整個過程要在 1 秒中內完成。在有 20 個 PSV 客戶端的節點，每秒需要處理的數據大小會是 3333GB。目前，不存在任何能夠達到這種處理速度的單個存儲設備，即使創建出一個巨大 RAID 0 陣列的高端固態磁碟，其能達到的最大處理速度也只有 600M/S。

這是需要 5555 個驅動器同時工作才能完成的吞吐量。理論上，如此規模龐大連接在一起的磁碟只能夠存儲兩天里產生的新區塊數據，那麼用在數據寫入時的成本花費為 400 美元。因此，你必須每隔兩天就添加一個這樣規模的磁碟列陣，每年花費在寫入和存儲數據上的金額將超過 4 億美元。

當然，我們也可以在假設中調整各項數據以便找到節點花費更節省的方法。

讓我們來試試吧：

如果我們有 10 萬個完整的節點都可以使用更便宜且容量更大的磁碟，且假設這些節點都接受 SPV 客戶端的連接請求，這樣會出現什麼情況呢？如果我們能設法修改完整節點的軟體來支持 1000 個 SPV 客戶端又會怎麼樣呢？

這將為我們提供 10 億可用於 SPV 客戶端的套接字以支持 2500 個在網路上同步的 SPV 客戶端。因此，每個 SPV 客戶端每天將會有 2160 秒的時間與網路同步。為了達到這一要求，必須保持每個完整節點能維持 231MB/S 的讀取速度，如果有 1000 個連接到網路的客戶端，則需要保證讀取速度為 231GB/S。

一個轉速為 7200 的硬碟其讀取速度約為 220MB/S，所以需要一個超過 1000 個硬碟的 RAID 0 陣列實現這種讀取吞吐量。

在寫入數據時，你可以購買 400 美元容量為 10TB 的驅動器，因此，如果花費 40 萬美元建立一個 RAID 陣列，它將能夠存儲 20 天的新區塊生成數據，這意味著一年花費 720 萬美元就能滿足磁碟讀取吞肚量的要求。

你每天都必須增加 2 個這樣的設備

值得注意的是，由於單個驅動器發生故障會導致整個磁碟陣列的損壞，所以不會有人願意使用如此多的單個驅動器來組成這麼大的磁碟陣列，而擁有容錯率功能的磁碟陣列性能不佳且價格更貴。

另外同樣值得注意的是，以上這些保守的估計假設了 SPV 客戶端會以某種方式協調運作，以便在一天中均勻地分配其同步時間。實際上，網路上會有以一天和一周為周期的周期性的高峰和低谷，所以網路系統需要比估計中更大的容量才能適應高峰期的需求。

否則，許多 SPV 客戶端在網路高峰期時將無法完成網路同步。

有趣的是，事實證明，更改每個節點的套接字數量不會影響到給定的完整節點的總體負載，每個完整的節點仍需要處理海量的數據。在這個方程中真正重要的是完整節點和 SPV 客戶端的比例，當然，區塊鏈中的區塊大小同樣重要。

所以，這個最終得出的結論似乎是不可避免的：要運行並維持能夠滿足 10 億用戶 SPV 客戶端交易的完整節點的成本會是一個天文數字。

尋找一些折中的位置

到目前為止，上面計算出的情況在資金方面是無法實現的。

但是，如果我們翻轉這個計算過程，嘗試找到一個公式，通過增加區塊鏈上的交易吞吐量來確定網路增加負載的成本，又會得出什麼樣的結果呢？

為了讓比特幣網路能夠支持目標數量的每秒交易數（每日新增用戶為 86400 個），我們可以計算出每個節點的磁碟吞吐量要求：

上面的公式為我們提供了完整節點滿足 SPV 客戶端需求的每秒磁碟讀取吞吐量的最小值。利用現有的網路特徵和技術，我們可以通過使用磁碟吞吐量作為假設中的瓶頸來推斷滿足要求的完整節點的運行成本。需要注意的是，在運行節點的過程中肯定存在其他增加運行成本的因素，但我們暫時不考慮這些。

對於要進行的計算，我預先做出了一些假設：

基於 info. 的平均交易大小為 500 位元組

SPV 用戶每天交易一次

SPV 客戶端消耗的套接字數量為 4

每個完整節點上可用於 SPV 客戶端的套接字數量為 20

網路中可用於 SPV 客戶端的套接字的總數量為 136000

RAID 0 配置中的硬碟陳本 400 美元，其容量為 10TB，轉速為 7200/S

通過上圖，我們可以看到，在每秒處理的交易數量不超過 100 的情況下，系統對於磁碟吞吐量的要求非常合理。此時，只需要購買多個磁碟組成磁碟陣列就能達到相應的性能要求。

但隨著每秒交易數的持續增加，磁碟的吞吐量需求以及運行完整節點的成本會成二次方式的增加，因此，對應的成本很快又變成了無法實現的天文數字。

作為參考，Visa 系統每秒大約處理 2000 筆交易，這在比特幣系統中需要花費將近 20 萬美元的成本才能跟上 SPV 客戶端的需求。值得注意的一點是，在這些圖表中，整個系統中節點的總數保持在 8000 這個恆定值上，實際上，節點的數量會隨著成本的增加而減少，這會導致剩下的節點必須提高吞吐量，並擁有更快的處理速度。

這似乎是節點集中化複合力量的體現。

正如我在「如何避免比特幣節點集中化」中得出的結論所述，在比特幣擴容之爭中的一個根本性問題是節點運行和維護的成本。上述的計算讓我們看到了計算節點操作成本的複雜性，因為這個過程中涉及到了非常多的變數，所以在計算中我假定了大多數變數保持不變，只關注磁碟吞吐量對於節點操作成本的影響。

一年前，一份（不科學的）的民意調查顯示，98%的節點運營成本每月不會超過 100 美元，我敢打賭，增加比特幣的在線交易量會導致大部分的完整節點運營成本的增加，如果交易數量增加兩個數量級，會導致至少 90%的節點產生巨大虧損。

我相信，沒有人願意構建成本高昂的磁碟陣列來運行完整的節點。在這種情況下，聲稱交易量的增長對一般用戶有利是一種毫無依據的說法，因為網路中將不會有足夠的節點和符合要求的磁碟吞量為 SPV 客戶端提供其需求的套接字。

SPV的其他缺陷

SPV 對於不需要完全驗證節點安全性和隱私性的終端用戶再好不過了。然而，忽略其可擴展行，基於 SPV 的比特幣網路中仍然存在很多需要認真考慮的因素。

SPV 假設的條件使其安全性和隱私性都比運行完整節點要差的多：

SPV 客戶端信任礦工會正確驗證和執行比特幣規則；他們認為具有最大累積工作量證明的區塊鏈也是有效的。關於這些，你可以在這篇文章中了解 SPV 與完整節點安全模式之前的區別。

SPV 客戶端假設完整節點不會因為遺漏對其欺詐。一個完整的節點不能捏造出一個不存在區塊中的交易，但是節點仍舊可以聲稱在節點中的交易未發生來進行欺詐行為。

由於 SPV 客戶端追求的是效率，所以它們只需要跟自己交易相關的數據信息，這將導致隱私性信息的大量丟失。

有趣的是，BIP 37 方案的合作者 Matt Corallo 為此還向外界道了歉，稱後悔創造了它：

今天我發現了系統中存在巨大的用戶隱私泄露問題，這就是 BIP 37 方案中的布隆過濾器設計存在的缺陷，很抱歉，是我寫了這個程序的代碼。

使用 BIP 37 方案中布隆過濾器的 SPV 客戶端的用戶幾乎沒有隱私，Jonas Nick（Blockstream 的安全工程師）發現，只要給定一個公鑰，他就可以確定屬於給定錢包地址 70%的相關信息。

雖然用戶可以通過分配布隆過濾器在不同的節點上來解決隱私泄露的問題，但這大大增加了網路節點中的負載，也使得 SPV 的擴展性大大降低。

同時，BIP 37 方案也容易遭受微小瑣碎的拒絕服務性攻擊。這裡提供的演示代碼，可以通過特殊構造的過濾器進行大量快速庫存請求，這將導致連續的磁碟搜索和較高的 CPU 使用率，從而使得整個節點癱瘓。

攻擊概念驗證的作者，Core 的開發人員 Peter Todd 解釋道：

根本問題是，你可以使用非常低的網路帶寬來消耗不成比例的磁碟吞吐量。

即使到今天，中本聰在比特幣白皮書中描述的欺詐情況仍舊沒有被真正實施過。事實上，關於這方面的研究表明，一些輕量級的欺詐警報可能都無法實施。

例如，欺詐警報只有在實際獲得證明欺詐所需數據的情況下才會起作用，如果沒有礦工提供該項數據，則無法實施欺詐警報，因此，SPV 客戶端並沒有中本聰預想中的那麼不安全。

從高層次的角度來看，一個主要由 SPV 節點組成的系統會使共識發生變化，例如改變比特幣數量上限，使得編輯分類賬目更加容易。更少的完全驗證節點意味著更集中地執行通過一致協商的規則，從而減少變化的因素對共識的抵制。有人認為這將會是 SPV 節點系統的特色，但另一些人卻認為這根本就是一個缺陷。

潛在的改進

理論上，SPV 的安全性和擴展性都可以通過欺詐證明、欺詐提示、輸入證明和花費證明等多種方式得以改善，但據我所知，目前這些方法都還處於概念性階段，人們對於實際應用方面並沒有做多少充足的準備。

布隆過濾器承諾能夠通過改進來改變隱私泄露的狀況，但是在過濾器大小和錯報率之間存在一種有效性的參數：粗率的過濾使得錯報率會非常高，而過於精細的過濾使得過濾器變得非常巨大，普通用戶的 SPV 客戶端根本無法運行。雖然它會減少完整節點磁碟吞吐量的負擔，但由於整個區塊必須通過網路傳輸，SPV 客戶端和完整節點將會增加交易所需的帶寬。

最近提出的緊湊型客戶端過濾消除了隱私問題，但如果與過濾器匹配，它仍舊需要下載完整的區塊鏈。

UTXO 承諾可以使 SPV 客戶端同步其當前的 UTXO 集，即便不掃描整個區塊鏈也能知道電子錢包的實時餘額，當然，這種方式必須向 SPV 客戶端提供現有的 UTXO 證明。

通過要求 SPV 客戶端提交工作量證明或基於通道的微支付可以提防布隆過濾器受到 DoS 攻擊，但是這兩者都沒有提出直截了當的解決方案。

完整節點的磁碟讀取量需求可能會通過改進數據索引 SPV 客戶端對所有請求的批量處理等多種方式來減少。

Ryan X Charles 指出，使用 BIP 70 方案的付款協議直接告訴某人你要發送的付款人的 UTXO ID，這樣他們可以直接從完整的節點請求相關的數據信息，消除他們使用布隆過濾器的需求，如果你願意接受泄露隱私的風險，這種方法將是非常有效的。

可以說，目前的方案有很多的改進餘地，但這需要克服許多挑戰才能正在改善在線網路的可擴展性。

合適的擴容方案

如果我們忽略大量的其他問題，例如區塊傳播延遲、UTXO 集縮放、初始區塊同步時間、安全性和隱私權衡，將區塊擴大，則可以從技術上將比特幣系統擴大成日用戶數十億級別的交易系統，前提是有人願意投入大量的資金和資源來開發並改進維持這個系統運行的基礎設施和軟體。

但是，比特幣似乎不可能以這樣的方式發展，因為現實中存在更加有效的擴容方式。其中最有效並且已經實施了的擴容方案是：集中並整合 API 供應商。在選取擴容方案時，人們傾向於那些可信任且隱私性高的方案，但是許多此類方案中的交互涉及到一些能夠淡化某些危險的合同協議。

在以不可完全信任的方式擴容方面，例如閃電網路之類的第二層協議則提供了更為有效的擴容方案，因為大量的交易可以在主鏈之外進行。你可以將其視為廣播帶乙太網通信層與路由 IP 層之間的區別—-互聯網無法在無路由的情況下擴展，價值互聯網也是如此。

雖然這種擴容方法在技術層面上比傳統的集中式擴展更為複雜，並且還要克服一些獨特的挑戰，但是用於研究和開發這些路由協議的前期投資將會為系統帶來巨大的長期收益，因為這些方案能夠減少整個網路負載的數量級。

除了以上介紹的之外，還有其他一些方案可以進行探索：

利用 Chaum 代幣採用具有完美隱私性的中心化管理方案，例如 HashCash

中心化非監禁零知識證明系統，例如 TumbleBit

聯合（非完全信任的多重簽名）側鏈

礦工擔保安全（非完全信任）的驅動鏈

我相信，從長遠來看，比特幣區塊鏈需要更大的區塊。

但是我們仍舊需要儘可能有效地進行系統擴容，與此同時必須保證系統的安全性和隱私性，對此我們必須有耐心並且要以睿智長遠的眼光來考慮問題。

如果從一般用戶的角度來看，Paypal 的實用性當然更高，但是它並不能像比特幣系統一樣讓用戶享受完整的財務主權。

粹客網是國內首個關注前沿科技領域的科技新媒體和創業服務平台。我們提供最貼近商業化的前沿科技創業報道、最新最全的科技動態資訊以及深刻獨到的行業觀點。堅持挖掘有價值的創新創業項目，致力於成為創新創業者的前沿陣地。

每月精彩評論將有機會獲得神秘禮品，線下活動 or 商業合作請私信微信公眾號（cheekrnews）或發郵件到粹客網官方郵箱。

點擊展開全文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！